On 03-May-22 05:22, Michael Richardson wrote:
Toerless Eckert <t...@cs.fau.de> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
