Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

[Toerless Eckert <[e-mail]>]

On Tue, Apr 26, 2022 at 04:07:13PM +1200, Brian E Carpenter wrote:
> Toerless,
> 
> > I am asking because if/where there are gaps in supported discovery mechanisms,
> > we might be able to suggest GRASP without ACP. Which would be somewhat of another
> > draft..
> 
> The only standards-track requirement for that is that GRASP can run over a secure substrate.

Exactly. And that can be relatively simple with a lightweight substrate.

> Been there, done that: https://www.ietf.org/archive/id/draft-carpenter-anima-quads-grasp-03.html

Yes, was thinking of that, but instead of trying to invent what i'd call a new lightweight
crypto header just use DTLS and TLS. So some similar or rewrite of that proposal.

> That work is not ready for the standards track but it shows proof of concept, if you accept the need for a shared secret.

Given how we would be pitching it to networks where devices are enrolled with a certificate,
we would get zero-touch deployment by using that certificate. And we given how we wouldn't
want to do address assignment, we might get away with non-enhanced certificates.

Its really the question where/how those constrained vouchers would be used in mesh networks and what
gaps those mesh networks might have.

6TISCH for example seems like not having something useful for discovery right now if i correctly
extrapolate MichaelR's last reply here.

CHeers
    Toerless

> 
> Regards
>    Brian
> 
> On 26-Apr-22 12:16, Toerless Eckert wrote:
> > On Wed, Apr 13, 2022 at 01:19:21PM -0400, Michael Richardson wrote:
> > 
> > (1)
> > 
> > > Yes, you are right, we need to have a new objective to announce.
> > > I guess that we don't really think about the constrained-join-proxy really
> > > being used in an ACP context, but we really should that right.
> > 
> > I don't think this is true. As soon as EST-COAPS proliferates as an RFC,
> > the choice of TLS vs. COAPS becomes not only a necessity for constrained
> > devices, but also a preference choice by solution designers. Less code
> > modules etc.
> > 
> > Also, RFC8995 promised the COAPS solution as part of ANI (the way i see it).
> > 
> > I always imagined in-ceiling network switches that do full ACP but
> > are also gateways to IoT edge networks as a good size candidate market example.
> > 
> > (2)
> > 
> > Separate question: Do we have a good understanding which solution
> > that needs the constrained proxy will use which discovery mechanism ?
> > 
> > I am asking because if/where there are gaps in supported discovery mechanisms,
> > we might be able to suggest GRASP without ACP. Which would be somewhat of another
> > draft..
> > 
> > > https://github.com/anima-wg/constrained-join-proxy/issues/17
> > > 
> > >      > Note that it is not sufficient to delta RFC8995 and mention
> > >      > "EST-COAPS", because the GRASP objective also needs to indicate UDP
> > >      > instead of TCP. Even though it is longer, it would IMHO be prudent to
> > >      > copy the whole GRASP objectives and examples from RFC8995 and
> > >      > accordingly modify them, so that the constrained-proxy draft is
> > >      > "standalone" in this respect (even if a page longer).
> > > 
> > > I think you are asking us to show an example that advertises both RFC8995,
> > > and the constrained version, correct?
> > 
> > (3)
> > 
> > No. The example does not need to show both. Just constrained version as a
> > standalone GRASP objective IMHO. I would suggest to clone the text from
> > RFC8995 and accordingly modify it.
> > 
> > >      > Isn't there the thought that some other variations of BRSKI will use
> > >      > protocol variations, such as not CBOR+JSON ? some other "CMP" encoding
> > >      > ?
> > > 
> > > We decided that Registrars will be responsible for interoperation, and will
> > > support all protocols the operator expects to use.   If you buy a Registrar
> > > that does not do X and a pledge that only does X, then it fails, and you were
> > > stupid.
> > 
> > (4)
> > 
> > In the first place this needs to be written down.
> > 
> > But i'd rather like to argue it away because i think it is an unnecessary
> > constraining "hack".
> > 
> > Why have all this discovery mechanisms when they are not even used correctly.
> > Underspecifying the exact service(s) a Registrar offers is like announcing
> > "Oh, go to google for the WHATEVER services".
> > 
> > I don't see that implementations would get more complex, but rather
> > simpler if we simply are able to distinguish the different protocol options
> > by their service name/parameters and have proxies/clients be able to select
> > them.
> > 
> > At least thats my opening offer, lets discuss ;-) But see below.
> > 
> > >      > I am asking, because it seems to me we need to be aware, that the
> > >      > constrained-proxy is logically "just" a DTLS proxy, but once we have
> > >      > more than one DTLS BRSKI variation, we still need to be able for
> > >      > pledges to connect to registrar(s) that talk the BRSKI variation that
> > >      > the pledge supports. What we define here initially is effectively
> > >      > proxy/registrar for EST-COAPS. So let's assume, we get another
> > >      > protocol, OTHER1-DTLS. The constrained proxy continues to work, but it
> > >      > would now need to discover the OTHER1-DTLS Registrar, allocate a new
> > >      > UDP port number on which to offer proxy services for OTHER1-DTLS and
> > >      > announce that to pledges.
> > > 
> > > You aren't wrong, but you also aren't right.
> > > Pledges are expected to try all options (possibly concurrently if they have
> > > CPU/ram) until they find one that works.    There is no reason the join proxy
> > > needs to know the details of the Registrar supports, only that they support a
> > > way to talk to it.
> > 
> > (5)
> > 
> > That "trial&error" too should be described if its here to stay. Even if just
> > through a reference to an appropriate section in 8995 (if its in there, not sure).
> > 
> > (6)
> > 
> > How about cert renewal, did you folks discuss if this would ever be something
> > pledges would want to do through the proxy ? In the case of ACP we did
> > discuss this, and i thinkit's in 8994 as well. E.g.: when cert is expired, so
> > the enrolled device can not wield its cert for secure network access, but its
> > still good enough for renewal.
> > 
> > >      > I wonder if the names choosen for est-coaps discovery, brski.jp and
> > >      > brski.rjp are ideal indicative of the fact that we're rather defining
> > >      > brski-est-coaps.jp and brski-est-coaps.rjp. I guess beauty/explicitness
> > > 
> > > Fair point.
> > 
> > (7)
> > 
> > I guess a compromise for (4) would be new text that leaves the decision for
> > how to deal with the next enrollment protocol/encoding to such a followu draft:
> > 
> > IF implementers of a new variant feel that all existing/deployed registrars
> > will and should be able to support the new protocol variant (e.g.: brski-xmp-xyz),
> > then that protocol option does not need to come up with a new variation.
> > 
> > IF implementers feel that is not appropriate, then:
> > a) A new set of service names is required (brski-xmp-xyz.jp/rjp or the like)
> > b) constrained proxies supporting both the new and the old will have to
> >     effectively run separate instances for them, e.g.: each instance having
> >     a separate UDP port number towards the pledge and using separate
> >     service names from registrar and to proxy.
> > 
> > >      > 3. 6tisch discovery
> > > 
> > >      > [I-D.ietf-6tisch-enrollment-enhanced-beacon] is now RFC9032, please
> > >      > update draft accordingly.
> > > 
> > >      > Upon quick browse of RFC9032 i fail to see how/where RFC9032 would be
> > >      > able to deal with more than one discovery protocol. E.g.: How would we
> > >      > discover BRSKI-EST-COAPS-REGISTRAR BRSKI-EST-COAPS-PROXY
> > >      > OTHER1-DTLS-REGISTRAR OTHER1-DTLS-PROXY
> > > 
> > > Yes, are you right.
> > > RFC9032 does not support DTLS at all.
> > > It supports RFC9031 only.
> > > Perhaps we should simply indicate that we don't support 6TISCH.
> > 
> > No opinion. Sounds like the easiest solution, unless you do want some
> > way to support 6TISCH ?
> > 
> > >      > 4. Stateful vs. stateless proxy discovery
> > > 
> > >      > How do i know as a customer of equipment know that all my
> > >      > pledges/proxies/registrars will interoperate in the face of those
> > >      > devices seemingly being able to freely pick stateful and/or stateless
> > >      > mode of operations ?
> > > 
> > > Because, we defined the proxy to have a standard interface.
> > 
> > What does that mean ? Do all proxies need to support both modes, or
> > is there only the requirement for one mode, but some undefined entity has to
> > figue out what registrar/proxies in some network should decide to use ?
> > 
> > > (Except for CoAP/OSCORE vs CoAPS above)
> > 
> > OSCORE = ?
> > 
> > > How the join proxy keeps state (in memory or in the network) is a private
> > > matter between the JP and the Registrar, and does not concern the pledge.
> > 
> > Cheers
> >      Toerless
> > 
> > > --
> > > ]               Never tell me the odds!                 | ipv6 mesh networks [
> > > ]   Michael Richardson, Sandelman Software Works        | network architect  [
> > > ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> > > 
> > > 
> > > --
> > > Michael Richardson <[e-mail]>, Sandelman Software Works
> > >   -= IPv6 IoT consulting =-
> > 
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> > 

-- 
---
[e-mail]