Dear WG, authors, Sheng,
Below my review comments for the draft. Based on this it looks to me not yet
ready for publication. Also, the document has had little review from the WG so
far I could see.
But it has clearly improved since my last review and it looks like it could be
ready on the next iteration.
Regards
Esko
*** Entire document
- Terminology should be made consistent: "Join Proxy", "Join-Proxy",
"Join_Proxy" - with same capitalization also.
- And also if possible make consistent the wording '"join" port' vs 'join port'
vs '"Join" port'.
- "cbor" -> "CBOR"
*** Sections 1-6
Nit "togther"
-> together
"The content fields are DTLS encrypted."
-> there is only one content field; make this singular.
Figure 5: "it includes additional IP-addresses" -> rephrase, "additional data
fields" or so. There's only one ip address inside.
" In particular this section replaces section 4.1 of [RFC8995]."
-> does this mean it formally updates RFC 8995? If so we have to mark this
draft as "updates RFC 8995" in the header. If not, why not? (Maybe someone in
the WG can explain this well)
*** Section 7
the 2 steps are both numbered "1." Step 1. should have a descriptive short
title also, now it is just called "Two alternatives".
It could be clarified how the Pledge would choose between the two alternatives.
For example, it typically doesn't know whether case 1a or case 1b applies. So
will the Pledge first try 1a? Or first 1b? And if the first attempt fails, try
the other (1a/1b) ?
Maybe we can say this is left to implementation. I have a suggestion in
Section 9.1 (see below) to make this simpler: the Pledge will only discover for
rt=brski and will find either a true Registrar or a Join Proxy that "appears"
to be a Registrar even though it isn't itself.
This will make the procedure simpler and is even correct in the rt sense (see
below 9.1 comments).
In step 2, " Once enrolled, the Join Proxy discovers the join port of the
Registrar." I'm a bit confused about what "Once enrolled" means here. Once the
Pledge is enrolled? Or do we mean once the Join Proxy is enrolled? (Given that
a Pledge could become Join Proxy after its enrollment.)
I would clarify this to "The Join Proxy discovers the join port of the
Registrar. The Join Proxy may do this at the moment it needs to relay a DTLS
message to the Registrar, or it may do this discovery already in advance."
" threa" -> "three"
7.2.1 " The Pledge MUST listen for GRASP M_FLOOD [RFC8990] announcements" ->
this MUST requirement is only for a Pledge that uses GRASP / ACP.
We could formulate that in a similar way as in RFC 8995, e.g. "This section is
normative for uses with an ANIMA ACP."
Nit: I would keep the order of the 3 technologies the same in Section 7.1.* and
7.2.* . For example always do the subsections in the order as announced in 7.2:
" coap discovery, 6tisch discovery and GRASP discovery".
7.2.3: text says " Not applicable." Why would a 6tisch Pledge have no need to
discovery the Join Proxy? Surely there is something, maybe only sending a
802.15.4 beacon request or so to get a response from a neighbor Join Proxy?
Maybe briefly explain why not applicable. E.g. in that case how does the Pledge
know which of multiple networks/Join Proxies to contact.
7.3: title of section seems wrong? In Section 7 we announce the following 3
cases:
Three discovery cases are discussed: Join_proxy discovers Registrar,
Pledge discovers Registrar, and Pledge discovers Join-proxy.
So I would suggest we have these titles approximately, and set in the right
order as announced:
7.1 Join proxy discovers Registrar
7.2 Pledge discovers Registrar
7.3 Pledge discovers Join Proxy
7.3.1: "The discoverable port numbers are usually returned for Join Proxy
resources in the <href> of the payload (see section 5.1 of
[I-D.ietf-ace-coap-est])."
-> I don't see href mentioned in Section 5.1. So this statement isn't clear
enough. Note that the part between angle brackets, if you mean this, is called
URI-Reference in Core Link Format. That contains the port number. We can also
mention
that the string "join-port" in the example above will be the port number.
*** Section 8
" communication is between the Proxy and a known registrar are over the
already secured portion of the network, so are not visible to
eavesdropping systems"
-> should be a little bit more specific: only the L2 encryption of the (mesh)
network protects this traffic, usually with a shared key that has a rather wide
distribution over many nodes. There's no DTLS or other one-to-one protection.
On-network eavesdroppers and attackers can access this header information.
Typo " communicatione"
" If the communicatione between Join-Proxy and Registrar passed over an
unsecure network, then an attacker could change the cbor array,
causing the Pledge to send traffic to another node."
-> true, if the mesh is not L2-secured then an off-mesh attacker could sniff it
and possibly modify it.
We have to consider also that the attacker could be on-mesh; and then a similar
consideration applies.
*** Section 9
This section seems incomplete! The CBOR map elements registry should be given
its own subsection 9.x. And it should be clearly explained what the Registry
defines including initial values.
I'm also missing here the registration of the "JPY protocol" in the "Service
Name and Transport Protocol Port Number Registry" since it really is a new
protocol with own particular format.
9.1: the registered resource types (rt) would typically use some hierarchy in
naming with dots to denote hierarchy. See the current entries in the registry:
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value
For constrained-BRSKI we have defined "brski", "brski.vs", "brski.rv", etc.
So to stay with existing conventions we could use such names. One observation
is that the Join Proxy in fact offers *all* BRSKI functions that the Registrar
offers, but then proxied.
Such a case can be readily advertised using the "brski" resource type (rt).
This type is defined in draft-ietf-anima-constrained-voucher . There's no need
to differentiate the name here from "brski" because it just advertises generic
BRSKI functionality and that is what the Join Proxy offers, simply put.
So that means the Join Proxy makes it appear as if BRSKI functions are being
offered on its Join Port, so it appears to be itself the Registry offering all
these functions. The Pledge may be completely unaware whether it's talking to a
Join Proxy or to a real Registrar, and it wouldn't even care.
In case this loss of transparency (not knowing whether we have a case of
real-Registrar vs proxy-to-Registrar) is a problem (if so I would be glad to
find out why!), we can adapt the naming to say "brski.jp" or "brski.proxy" to
denote a Join Proxy that is offering generic BRSKI functionality by relaying to
a Registrar.
Furthermore, on the Registrar side (Stateless "Join" port for receiving JPY
protocol messages) we can have "brski.rjp" or so (rjp = "Registrar Join Port")
or "brski.jpy".
-----Original Message-----
From: Anima <[email protected]> On Behalf Of Brian E Carpenter
Sent: Sunday, October 3, 2021 06:01
To: Sheng Jiang <[email protected]>; Anima WG <[email protected]>
Cc: [email protected]
Subject: Re: [Anima] WGLC for draft-ietf-anima-constrained-join-proxy-04, ends
October 14th 2021
Hi,
I've looked at this from the GRASP point of view and it all seems fine.
It's perhaps worth noting that GRASP DULL discovery is quite independent
of both CoAP and DTLS. As far as I know, DTLS still can't protect
multicast, so there is no alternative to DULL.
(Something the WG should perhaps consider at some point is GRASP over
CoAP, but that is a very separate discussion.)
Nits:
There are multiple occurrences of "Autonomous Network". In ANIMA, we're
using "Autonomic Network".
Regards
Brian Carpenter
On 01-Oct-21 23:03, Sheng Jiang wrote:
> Hi all,
>
>
>
> This message starts the two-week ANIMA Working Group Last Call to advance
> draft-ietf-anima-constrained-join-proxy-04,Constrained Join Proxy for
> Bootstrapping Protocols. This document's intended status is Standards Track.
> At present, there is no IPR file against this document. This document
has been ANIMA WG document since September, 2018 and have received a few good
review. The authors have addressed all known comments and think the document is
ready for WGLC.
>
>
>
> Please send your comments by October 14th, 2021. If you do not feel this
> document should advance, please state your reasons why.
>
>
>
> Sheng JIANG is the assigned document shepherd.
>
>
>
> Regards,
>
>
>
> Sheng
>
>
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
