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"
->PvdS DONE!
*** Sections 1-6
Nit "togther"
-> together
-> Pvds Done.
"The content fields are DTLS encrypted."
-> there is only one content field; make this singular.
->PvdS adapted.
Figure 5: "it includes additional IP-addresses" -> rephrase,
"additional data fields" or so. There's only one ip address inside.
->PvdS adapted
" 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)
-Pvds adapted; an extension is meant.
*** 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."
->PvdS Restructured the text and lay-out
" threa" -> "three"
->PvdS Done.
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."
->PvdS added three times.
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.
-> Pvds Section 7 is a bit of a mess.; section 7 is restructured and
rephrased
*** 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"
-->PvdS done
" 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.
-> PvdS clarified this section
*** Section 9
->PvdS Your section 9 comments are a bit difficult to follow for me.
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.
->PvdS What CBOR map? Do you mean the CBOR array sent between J-P and
R? Completely at a loss here.
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.
->PvdS I really don't see why we need the additional complexity of
registering the protocol.
- We do not propose it to be used for new specifications
- We do not need it to protect magic numbers. RT values are registered,
ports are discovered.
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.
-> PvdS Here follows my rant.
There is no such thing as a convention for rt values. I have asked two
or three times on core ML if people are interested to author or
co-author such a document. I even approached people individually, but
no one sees the necessity.
So, there is no convention to adhere to.
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".
-> PvdS I am completely lost by the text above. Apologies. My view:
The Join-Proxy is a standard coap server with the additional service to
propagate messages to the Registrar without any connection to a
resource.
The registrar can receive messages from Join-Proxy on its join-proxy
port, but these are not coap messages as you have pointed out;
Resources come into play after removing the header.
Many thanks ,
Peter
-----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
