On Wed, Nov 22, 2023 at 08:57:41AM +1300, Brian E Carpenter wrote:
> Front posting for simplicity:
>
> constrained-join-proxy says:
>
> > 5.2.2. GRASP discovery
> >
> > This section is normative for uses with an ANIMA ACP.
Yes, this sentence is one i was wondering about, e.g.: whether to say this or to
say something beyond this. But ultimately, its easier to have the discussion
about
this point for brski-discovery...
> So really, is there a natural scenario where constrained-join-proxy is used
> in a region of the network where an ANIMA ACP is established? And on balance,
> I have to extend the question to constrained-voucher. Certainly, GRASP was
> not designed for constrained nodes. There is no logic in using GRASP
> discovery for its own sake.
With constrained-voucher/constrained BRSKI we do reduce the protocol footprint
with an RFC8994 ACP "somewhat": Those "constrained" devices do not need HTTPs
(for BRSKI),
but replace it by COAP/DTLS. They still need TCP/TLS for the ACP GRASP security
and transport substrate.
they also may only need to support DTLS for secure channels and hence do not
need to
support ESP. This is all expanding on what RFC8994 and RFC8995 promise.
"constrained" devices here may primarily mean devices that are somewhat
constrained,
but not down to "256kbyte of memory - can not have TCP/TLS at all", as well as
devices with constrained links (e.g.: slower and more difficult than WiFi).
I don't see a reason why GRASP should not work well on even further constrained
devices.
> To me, the conclusion is fairly obvious. Possibly the GRASP work done in both
> drafts should be combined into a new draft, if you can describe a scenario
> where constrained nodes participate in a full ANIMA ACP.
draft-eckert-brski-discovery-01 does already include the GRASP functionality
as discussed here. If the explanations/justifications from above paragraph make
sense (and missing nothing that would be queried), then i'll check that i do
have them represented well in the drafts text.
Of course, it would make sense to replace the use of TCP/TLS with just DTLS
(which
interestingly is reliable because of retransmissions), but that is a step we
did not
want to take in RFC8994 because it would have been a requirement against all
RFC8994
nodes. Aka: This would have to be taken when such DTLS centric deplouments where
successful enough to justify such a requirement. And this would be beyond the
scope
of mere discovery work.
Thanks!
Toerless
>
> Regards
> Brian Carpenter
>
> On 22-Nov-23 04:14, Toerless Eckert wrote:
> > Thanks Esko,
> >
> > inline
> >
> > On Tue, Nov 21, 2023 at 01:12:45PM +0000, Esko Dijk wrote:
> > > A first comment / question here: in IETF 118, it was proposed to focus
> > > the discovery methods for Constrained BRSKI
> > > (draft-ietf-anima-constrained-voucher) only on a single mechanism and
> > > leave further alternatives to future work (like GRASP and mDNS).
> > >
> > > We didn't specifically discuss this aspect for the Constrained Join Proxy
> > > draft - do we need to do the same thing here and so take out the GRASP
> > > discovery text?
> > > Or are we sufficiently confident the GRASP definition is okay and
> > > valuable to have already now included in a draft? In that case we may
> > > leave it in.
> > >
> > > Esko
> >
> > Check the GRASP text in both drafts, i think the text in
> > constrained-join-proxy is more
> > harmfull to move forward than the one in constrained-voucher. So i would
> > definitely
> > like to see it removed, or i would want to raise concerns about it (which i
> > think we
> > don't need to spend time on to get the constrained docs out the door):
> >
> > draft-ietf-anima-constrained-voucher proposes:
> > discover (stateful) registrar by proxy: AN_join_registrar/BRSKI_JP
> > discover proxy by pledge: AN_Proxy/DTLS
> >
> > The two objective-values proposed are not what we would logically end up
> > with when
> > using the more systematic approach from brsi-discovery, instead, both
> > could be
> > empty strings - because both are defaults for use with CoAPs, which we
> > declare to
> > be assumed by use of IPPROTO_UDP. But both values would not matter, but
> > could be
> > defined easily for backward compatibility into brski-discovery if we
> > would keep
> > the text.
> >
> > draft-ietf-anima-constrained-join-proxy proposes:
> >
> > discover stateless registrar by proxy: AN_join_registrar/BRSKI_RJP
> > discover proxy by pledge: AN_Proxy/DTLS-EST
> >
> > The use of AN_join_registrar objective-name would forfeit the
> > transparent operation
> > of join-proxies as described in brski-discovery, because it moves the
> > choiceof
> > incompatible proxy<->registrar transport (stateful vs. stateless) into
> > the objective-value
> > element. Aka: this choice would block the way forward with
> > brski-discovery unless
> > brski-discovery would declare this specification invalid.
> >
> > brski-discovery instead proposes to use objective-name
> > AN_join_registrar_rjp to
> > indicate a stateless join registrar service. Hence allowing for all the
> > different
> > objective-value we want to use to be still available (and not occupied
> > by the
> > "BRSKI_RJP" value).
> >
> > Discovery of the proxy by the pledge vi DTLS-EST is also incompatible
> > with what
> > constrained-voucher writes (DTLS), aka: it could not automatically be
> > created by
> > a transparent proxy as proposed by brski-discovery (which would simply
> > keep "DTLS").
> >
> > In addition, constrained-join-proxy also includes one nice inspirational
> > line:
> >
> > h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443],
> > ["AN_join_registrar", 4, 255, "CMP"],
> >
> > To discover a CMP registrar, but without any explanations.
> >
> > Aka: i'd have to go through the whole GRASP discovery text and see that its
> > not
> > wrong, and i'd rather spend that effort writing brski-discovery correctly...
> >
> > Aka: pls. remove is my preferred option.
> >
> > Lets see that we do check the CoAP text to be correct though with what we
> > want to
> > have going forwardg.
> >
> > Thanks!
> > Toerless
> > > -----Original Message-----
> > > From: Anima <anima-boun...@ietf.org> On Behalf Of Michael Richardson
> > > Sent: Monday, November 6, 2023 15:24
> > > To: anima@ietf.org
> > > Subject: Re: [Anima] I-D Action:
> > > draft-ietf-anima-constrained-join-proxy-15.txt
> > >
> > >
> > > internet-dra...@ietf.org wrote:
> > > > Title: Join Proxy for Bootstrapping of Constrained Network
> > > Elements
> > > > Authors: Michael Richardson Peter van der Stok Panos Kampanakis
> > > Name:
> > > > draft-ietf-anima-constrained-join-proxy-15.txt Pages: 26 Dates:
> > > > 2023-11-06
> > >
> > > ...
> > > > A diff from the previous version is available at:
> > > >
> > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-join-proxy-15
> > >
> > > This is a repost of the I-D, because it expired.
> > > This version includes partial work on the IoT-Directorate review comments
> > > received in August, and which are still issues:
> > >
> > > https://github.com/anima-wg/constrained-join-proxy/issues
> > >
> > > So the work is just not done yet.
> > > There are a number of pull requests, some rather old, which I need to
> > > clean
> > > up and/or merge:
> > > https://github.com/anima-wg/constrained-join-proxy/pulls
> > >
> > > Your comments are of course, very welcome.
> > > It probably the case that there is need for some additional review/text
> > > based upon the
> > > new conversations about the discovery draft. It would be great if there
> > > are
> > > new eyes reading this document if they notice the mismatches.
> > >
> > > --
> > > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> > > -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
> > >
> > >
> > >
> >
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
