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

[Michael Richardson <[e-mail]>]

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

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.

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