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

[Brian E Carpenter <[e-mail]>]

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. Been there, done that: https://www.ietf.org/archive/id/draft-carpenter-anima-quads-grasp-03.html

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

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
>