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

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

On 26-Apr-22 19:02, Peter van der Stok wrote:
> HI,
> 
> To add to the discussion, below the text that I adapted for Graps discovery in contrsined-join-proxy draft.
> 
> Comments are welcome, Corrections are encouraged.

Are you intending to define a new GRASP objective "AN_REGISTRAR"? If so, you must be consistent (you have "AN_registrar" elsewhere) and you need an entry in IANA Considerations.

Or are you just extending "AN_join_registrar" as defined in RFC8995? That 
seems easier.

Same points for "AN_JOIN_PROXY" (RFC8995 defines "AN_Proxy").

I think that each place you have "the objective name is...", you mean "the objective value is...".

Regards,

     Brian


> 
> Peter
> ______________________________________________________________________________
> 
> 6.1.  Join Proxy discovers Registrar
> 
>     In this section, the Join Proxy and Registrar are assumed 
to
>     communicate via Link-Local addresses.  This section describes the
>     discovery of the Registrar by the stateless Join Proxy.  The
>     statefull Join Proxy discovers the Registrar as a Pledge.
> 
> 
> 6.1.2.  GRASP discovery
> 
>     This section is normative for uses with an ANIMA ACP.  In the context
>     of autonomic networks, the Registrar announces itself to a stateless
>     Join Proxy using ACP instance of GRASP using M_FLOOD messages.
>     Section 4.3 of [RFC8995] discusses this in more detail.  The
>     following changes are necessary with respect to figure 10 
of
>     [RFC8995]: * The transport-proto is IPPROTO_UDP * the objective is
>     AN_REGISTRAR * the objective name is "BRSKI_RJP".  The Registrar
>     announces itself using ACP instance of GRASP using M_FLOOD messages.
>     Autonomic Network Join Proxies MUST support GRASP discovery of
>     Registrar as described in section 4.3 of [RFC8995] . Here 
is an
>     example M_FLOOD announcing the Registrar on example port 5685.
> 
>        [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
>        [["AN_registrar", 4, 255, "BRSKI_RJP"],
>        [O_IPv6_LOCATOR,
>        h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 
5685]]]
> 
>              Figure 5: Example of Registrar announcement message
> 
>     The Registrar uses a routable address that can be used by 
enrolled
>     constrained Join Proxies.
> 
> 
> 6.2.  Pledge discovers Registrar
> 
>     In this section, the Pledge and Registrar are assumed to communicate
>     via Link-Local addresses.  This section describes the discovery of
>     the Registrar by the Pledge.  Once the Pledge is enrolled and
>     functions as a stateful Join Proxy, it continues with the 
same
>     Registrar port and address.
> 
> 6.2.2.  GRASP discovery
> 
>     This section is normative for uses with an ANIMA ACP.  In the context
>     of autonomic networks, the Registrar uses the DULL GRASP M_FLOOD
>     mechanism to announce itself.  Section 4.1.1 of [RFC8995] discusses
>     this in more detail.  The following changes are necessary with
>     respect to figure 10 of [RFC8995]: * The transport-proto is
>     IPPROTO_UDP * the objective is AN_REGISTRAR * the objective name is
>     "BRSKI_JP" The Registrar announces itself using ACP instance of GRASP
>     using M_FLOOD messages.  Autonomic Network Join Proxies MUST support
>     GRASP discovery of Registrar as described in section 4.3 of [RFC8995]
>     .
> 
>     Here is an example M_FLOOD announcing the Registrar at fe80::1, on
>     standard coaps port 5684.
> 
>          [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
>          [["AN_Registrar", 4, 1, "BRSKI_JP"],
>          [O_IPv6_LOCATOR,
>          h'fe800000000000000000000000000001', IPPROTO_UDP, 5684]]]
> 
>              Figure 6: Example of Registrar announcement message
> 
> 
> 6.3.  Pledge discovers Join Proxy
> 
>     In this section, the Pledge and Join Proxy are assumed to 
communicate
>     via Link-Local addresses.  This section describes the discovery of
>     the Join Proxy by the Pledge.
> 
> 
> 6.3.2.  GRASP discovery
> 
> This section is normative for uses with an ANIMA ACP.  In the context
>     of autonomic networks, the constrained Join Proxy uses the DULL GRASP
>     M_FLOOD mechanism to announce itself.  Section 4.1.1 
of [RFC8995]
>     discusses this in more detail.  The following changes are necessary
>     with respect to figure 10 of [RFC8995]: * The transport-proto is
>     IPPROTO_UDP * the objective is AN_JOIN_PROXY * the objective name is
>     empty The constrained Join Proxy announces itself using ACP instance
>     of GRASP using M_FLOOD messages.  Autonomic Network Registrars MUST
>     support GRASP discovery of constrained Join Proxies as described in
>     section 4.3 of [RFC8995] .
> 
>     Here is an example M_FLOOD announcing the constrained Join Proxy at
>     fe80::2, on standard coaps port 5684.
> 
>          [M_FLOOD, 12340815, h'fe800000000000000000000000000002', 180000,
>          [["AN_JOIN_PROXY", 4, 1, ""],
>          [O_IPv6_LOCATOR,
>          h'fe800000000000000000000000000002', IPPROTO_UDP, 5684]]]
> 
>              Figure 7: Example of Join Proxy announcement message
> 
> ________________________________________________________________________________________
> 
> Toerless Eckert schreef op 2022-04-26 02:16:
> 
>> 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 <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] <mailto:[e-mail]> http://www.sandelman.ca/ <http://www.sandelman.ca/>        | 
  ruby on rails    [
>>>
>>>
>>> --
>>> Michael Richardson <[e-mail] <mailto:[e-mail]>>, Sandelman Software Works
>>>  -= IPv6 IoT consulting =-
>>
>> _______________________________________________
>> Anima mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>