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

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

On 03-May-22 05:22, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> 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.
> 
> We may be using different terminology, and being in violent agreement.
> 
> I am saying that the existing GRASP M_FLOOD specified in RFC8995,
> 
> RFC8995 4.1.1 says:
> 
>     flood-message = [M_FLOOD, session-id, initiator, ttl,
>                      +[objective, (locator-option / [])]]
> 
>     objective = ["AN_Proxy", objective-flags, loop-count,
>                                            objective-value]
> 
> ...
>     locator-option    = [ O_IPv6_LOCATOR, ipv6-address,
>                         transport-proto, port-number ]
>     ipv6-address      = the v6 LL of the Proxy
>     $transport-proto /= IPPROTO_TCP   ; note that this can be any value
>                                      ; from the IANA protocol registry,
>                                      ; as per RFC 8990, Section 2.9.5.1,
>                                      ; Note 3.
> 
> and I'm saying that we'd have:
>     $transport-proto /= IPPROTO_UDP  ; ...

Or you could invent a new value outside the IANA range to indicate CoAPS,
as the second sentence in Note 3 suggests:
https://www.rfc-editor.org/rfc/rfc8990.html#section-2.9.5.1-6


> to indicate to use CoAPS (UDP/DTLS).  That's in the latest draft in section
> 6.1.2 (for AN_Registrar) and 6.2.2 (AN_Proxy).  But section 6.2/6.3 is wrong, and
> I'm fixing it at:
> 
>     https://github.com/anima-wg/constrained-join-proxy/pull/20
> 
> Brian, in RFC8995, we leave "objective-value" empty, while this document
> wants to set it to "BRSKI_JP", and I don't think that does anything useful.

That's a design choice you're free to make, of course.

    Brian

> 
>      > (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..
> 
> GRASP DULL is easy.
> In some sense, for IoT networks, there is *only* the ACP :-)
> 
>      >> 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".
> 
> No, that's not at all what we said.
> 
>      > 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.
> 
> I think that we did exactly this.
> 
>      >> 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).
> 
> I don't think that we need to have a document that says read 8995 in a dozen places.
> 
>      > 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
> 
> Nope, never. Just like in BRSKI.
> 
>      >> > 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.
> 
> You can bikeshed the names. I don't really care.
> 
>      >> 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 ?
> 
> What does "what does that mean"?  I wrote an explanation, that I don't think
> you read.
> 
> The "standard" interface from a join proxy to the pledge (if it's DTLS) 
is to
> use CoAP over DTLS, on the port given.  The details of how it gets back 
to
> the Registrar is irrelevant to the pledge.
> (If it's TLS, then it's RFC8995.
> (If it's OSCORE/EDHOC, then it's TBD)
> 
>      >> (Except for CoAP/OSCORE vs CoAPS above)
> 
>      > OSCORE = ?
> 
> OSCORE. RFC8613.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>