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

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

Toerless,

Needless to say, I like this:

>    And a small GRASP daemon using the same DTLS as BRSKI is equally simple to develop
>    (i claim) as a proxy daemon. Certainly a completely different ballpark than
>    trying to get network layer IP multicast

However, in fairness, the part of GRASP that relays discovery multicasts
from one L2 segment to another is probably the most complex bit of the
GRASP core. My code is 5 years old, and I've fixed two bugs in it during
2022 already (thanks to Bill Atwood and his student Parsa Ghaderi).

That said, the main program of my gremlin for nodes that only do
relaying is essentially:

grasp._initialise_grasp()
while True:
     time.sleep(60)

Regards
    Brian Carpenter

On 03-May-22 12:22, Toerless Eckert wrote:
> Peter, Michael *:
> 
> Wrt to seervice discovery in general: I am happy to help with the text,
> but lets first agree on the functionality.
> 
> Here is what i think, please reject points if you have arguments against them,
> otherwise i'd assume you agree ;-):
> 
> 1. "AN_join_registrar" and "AN_Proxy" where defined in RFC8995 for use with ANI.
> To me that means those objectives indicate that by default those objectives
> will provide ANI/ACP certificates.
> 
> 2. There is no need to introduce new objective values just because we use a new
> protocol (EST-coaps instead of EST-tls). Instead, that should be done via
> the objective-value. RFC8995 already nicely uses "EST-TLS" for "AN_join_registrar".
> I have no idea why we did not also do this for "AN_Proxy", but we just left it
> blank there. But we can easily assume that Empty ("" as in the RFC8995 example)
> is the same as "EST-TLS".
> 
> 3. I think the GRASP announcements MUST indicate what mode the Registrar
> supports. Stateful or stateless. Or if it supports both, then just have
> GRASP announcements for both and let the Proxy pick.
> 
> 4. I think by using explicit objective-values to indicate the protocol we are
> also future proof when we come up with even more protocols like CMP or the like.
> 
> 5. The constrained proxy draft describes three discovery options:
>     (a) Proxy Discovers Registrar
>     (b) Pledge discovers Proxy
>     (c) Pledge discovers Registrar.
>     In ANI/ACP, we do not have case (c). I do not see how it could ever happen,
>     so we should not introduce it.
> 
> 6. To me, this means the ANI/ACP service discovery for use with constrained proxy are:
> 
>     Proxy Discovers Registrar:
>       objective-name:  "AN_join_registrar", protocol UDP, objective-value: "EST-COAPS"
>       objective-name:  "AN_join_registrar", protocol UDP, objective-value: "EST-COAPS-JPY"
>     Pledge Discovers Proxy:
>       objective-name:  "AN_Proxy", protocol UDP, objective-value: "EST-COAPS"
> 
>     EST-COAPS-JPY is stateless with JPY header. EST-COAPS is stateful. There is no
>     need for the AN_Proxy objective to distinguish here, because to the Pledge,
>     it does not matter how the Proxy talks to the Registrar.
> 
> 7. Until there is sufficient proof of the opposite, i will claim that multihop
>     ASM IP Multicast in support of admin-scope COAP group communication via ff05::fd
>     will not exist in the mayority of target deployments of constrained proxy.
> 
>     And this can simply render constrained BRSKI to become undeployable. So its IMHO
>     not to be taken lightly.
> 
>     Therefore i think it is very prudent to also explicitly define how to use GRASP
>     outside of ANI/ACP context as an option. We still have to close the gap of suggesting/
>     writing down an easy draft how to do GRASP just via DTLS, but should be IMHO
>     similarily simple as Brians draft-carpenter-anima-quads-grasp (i just wouldn't want
>     to invent new crypto when we already have DTLS as a dependency for constrained BRSKI anyhow.
>     And a small GRASP daemon using the same DTLS as BRSKI is equally simple to develop
>     (i claim) as a proxy daemon. Certainly a completely different ballpark than
>     trying to get network layer IP multicast even if it's RPL MPL (not under the same
>     control in most platforms as the BRSKI code..).
> 
> 9. In result, i would suggest:
> 
>     1) Pledge (or Proxy) Discovers Registrar:
>       objective-name:  "brski-rjp", protocol UDP, objective-value: "EST-COAPS"
>     2) Proxy Discovers Registrar (stateless):
>       objective-name:  "brksi-rjp", protocol UDP, objective-value: "EST-COAPS-JPY"
>     3) Pledge Discovers Proxy:
>       objective-name:  "brski-jp", protocol UDP, objective-value: "EST-COAPS"
> 
>     Logic for Pledge is simple: If it can discover a registrar via "brski-rjp"/"EST-COAPS",
>     then it uses that. Else it has to look for "brski-jp"/"EST-COAPS"
> 
> 10. IMHO, the text for 1) should be in constrained voucher, not constrained proxy,
>      because this is the option that can work without any brski proxy in networks where
>      discovery works across multiple hops. No need for this to depend on proxy.
>      Only 2) and 3) are specific to proxy. This would make constrained voucher more logically
>      standalone.
> 
> 11. For use with DNS-SD, we would encode the same parameters as in 9. according to
>      how we do things in DNS-SD:
> 
>     1) Proxy or Pledge Discovers Registrar:
>        service-name:    "brski-rjp", protocol UDP, TXT key: proto=EST-COAPS
>     2) Proxy Discovers Registrar (stateless):
>        objective-name:  "brksi-rjp", protocol UDP, TXT key: proto=EST-COAPS-JPY
>     3) Pledge Discovers Proxy:
>        objective-name:  "brski-jp",  protocol UDP, TXT key: proto=EST-COAPS
> 
> Cheers
>      Toerless
>     
> On Tue, Apr 26, 2022 at 09:02:51AM +0200, 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.
>>
>> 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,
> 
> Please replace with:
> 
>       6.1.2 ANI/GRASP discovery
> 
>       This section is normative for the use with Autonomous Network
>       Infrastructures (ANI) based on an Autonomous Control Plane (ACP, [RFC8994])
>       
>       
>       
> 
> 
>>      the Registrar announces itself to a stateless
> 
> NIT: s/In the context of autonomic networks, /When it is used, /
> 
> Aka: we don't need a full autonomic network, just ACP with (constrained)
> BRSKI. We call this ANI, but i don't think we need to introduce the term
> ANI here (surplus).
> 
>>     Join Proxy using ACP instance of GRASP using M_FLOOD messages.
> 
> Q: I am unclear right now why the draft claims it does not need discovery
> for the Registrar when the Proxy is stateful. This is a question i have
> independent of use of ACP. I think the constrained Jon Proxies always need
> to be able to discover the Registrar. And i wouldn't know how the Proxy
> would know whether it can talk stateful or stateless with the Registrar
> unless the Registrar would announce what mode it supports (or this is
> implied by the service name).
> 
>>     Section 4.3 of [RFC8995] discusses this in more detail.  The
>>     following changes are necessary with respect to figure 10 of
>>     [RFC8995]:
> 
> Not figure 10. The formal definition is in Figure 13, the example is in
> Figure 12.
> 
>>     [RFC8995]: * The transport-proto is IPPROTO_UDP
> 
> Maybe add: instead of IPPROTO_UDP for BRSKI,
> 
>>     * the objective is   AN_REGISTRAR
> 
> The objective name should IMHO stay unchanged "AN_registrar" as it is
> defined for RFC8995, but the draft would claim to be updating RFC8995
> by introducing additional objective-values ("BRSKI_RJP"...).
> 
>>     * the objective name is "BRSKI_RJP".
> 
> I am personally actually not very happy with those brski.* URL names.
> It would be nice if those names would be consistent across discoveries,
> but technically there is no need. So let me propose the names i
> would prefer:
> 
>     "EST-COAP-DTLS"
>     "EST-COAP-DTLS-SL"
> 
> Reason: The RFC8995 name was not "BRSKI", but "EST-TLS". The logical
> equivalent is therefore "EST-COAP-DTLS". This would be for the stateful
> proxy. For the stateless proxy option, we add "-SL".
> 
> (Brian was pointing out the objective value could be a structure, but
>   i think there is simplicity in a simple list of numeric/string objective-values
>   Afaik, TLS itself also uses that simple approach of enumeration to select
>   the crypto option to pick between initiator and responder. )
> 
>>     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] .
> 
> I would just write that ... "The Registrar performs announcements
> as described in RFC8995, section 4.3 except for the new objective-values
> and resulting use of IPPROTO_UDP in the locator option.
> 
>>     Here is an
>>     example M_FLOOD announcing the Registrar on example port 5685.
>>
>>        [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
>>        [["AN_registrar", 4, 255, "EST-COAP-DTLS-SL"],
>                                    ^^^^^^^^^^^^^^^^^^
>>        [O_IPv6_LOCATOR,
>>        h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]
>>
>>              Figure 5: Example of stateless Registrar GRASP message
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>>        [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
>>        [["AN_registrar", 4, 255, "EST-COAP-DTLS"],
>                                    ^^^^^^^^^^^^^^^
>>        [O_IPv6_LOCATOR,
>>        h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5686]]]
>>
>>              Figure 5: Example of stateful Registrar GRASP message
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> Aka: simply provide both announcement examples if thats what we agree upon.
> 
>>     The Registrar uses a routable address that can be used by enrolled
> 
> s/address that/address (fda3:79a6:f6ee:0000:0200:0000:6400:0001 in the example) that/
> 
>>     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
> 
> remove autonomic networks (as note above)
> 
>>     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]
>>     .
> 
> As for the Registrar announcements i would suggest:
> 
> - Objective name stays unchanged, "AN_Proxy"
> - Ideally, the same new objective-value is used as for the registrar: "EST-COAP-DTLS"
>    ... and we would not need to distinguish between "EST-COAP-DTLS" and
>    "EST-COAP-DTLS-SL", because there should be no difference for the Pledge.
>    ... except that for that to be true we would need to agree on the same
>    time for state maintenance / expiry for stateful/stateless proxies. Which
>    is an open discuss IMHO. E.g.: one of the benefits of the stateless proxy is
>    that the Registrar could keep registration state much longer than a stateful
>    proxy might want to do. In this case, "EST-COAP-DTLS" for just the stateful
>    proxy would be an indicator to send state-refresh messages (i hope they do
>    exist on COAP as in HTTP) much more often).
> 
>>     Here is an example M_FLOOD announcing the Registrar at fe80::1, on
>>     standard coaps port 5684.
>>
>>          [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
>>          [["AN_Proxy", 4, 1, "EST-COAP-DTLS"]
>>          [O_IPv6_LOCATOR1G,
>>          h'fe800000000000000000000000000001', IPPROTO_UDP, 5684s]]
>>
>>              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
>>>>
>>>>> 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
>