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

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

On 27-Apr-22 09:01, Toerless Eckert wrote:
> 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.

TLS for the GRASP TCP sessions should be fine. The reason I did QUADS was because people told me that multicast DTLS was not a thing, but GRASP depends on multicast UDP.

    Brian

> 
>> 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
>>>
>