Hello all,
I read the document again and have provided my comments below. This version
does not yet look ready to leave our WG, however. As an example, we have a
CDDL field name mismatch and Appendix A that doesn't conform to the CDDL. And a
reference that needs to become normative.
Still the updates that were made since the past review round are quite good.
Best regards
Esko
Review Comments
===============
5.2
A Join Proxy MUST implement both. A Registrar MUST implement the
stateful mode and SHOULD implement the Stateless mode.
-> Maybe I missed the discussion on this new statement, sorry! Why can't the
unconstrained Registrar always implement both modes too? (Code size isn't an
issue.)
Or do we mean it is always implemented but the operator has to be able to
disable it for the given network? I supposed the motivation for this
MUST/SHOULD combination is that we really want a network operator to be able to
select which mode(s) can be used.
Otherwise, if the Registrar would support both modes as always-available then
each Join Proxy could just choose to implement only one mode, saving on
embedded code size, memory, complexity, etc. Which is also attractive for
Pledge vendors. But maybe not for the operator.
In short, we don't have to change anything here but some motivation / reasoning
in the text would be helpful to understand it.
5.3.1
pledge_content field
-> the field is named "content" in the CDDL, not pledge_content.
6.1.1
The scheme remains coaps
-> Seems not? The scheme is coaps+jpy://
The coaps+jpy scheme is registered is defined in Section 9.2, as per
[RFC7252], Section 6.2
-> the "as per ... " part is unclear. Shouldn't we say that the scheme is
registered with syntax identical to [RFC7252] Section 6.2 ? Now it's rather
fuzzy what is meant.
6.2.1
Discoverable port numbers are
usually returned for Join Proxy resources in the <URI-Reference> of
the payload (see section 5.1 of [RFC9148]).
-> reference seems wrong - no section 5.1 there? No <URI-Reference> mentioned
also.
7.
In the comparison table, the row "Specification complexity" seems not so
relevant anymore given that the Join Proxy must implement both modes.
A "Security" row could be useful - in stateful mode, the Join Proxy is more
vulnerable to resource exhaustion attacks. E.g. attacker uses multiple LL
addresses and pretends to be N Pledges joining at the same time.
That seems like a more important consideration for the network operator than
"Specification complexity". But if people want to leave it as is, I won't
object further.
8.
It is also pointed out
that the encryption in the source is a local matter. Similarly to
[RFC8974], the use of AES-CCM [RFC3610] with a 64-bit tag is
recommended, combined with a sequence number and a replay window.
-> a bit unclear; "the source" - is that the Join Proxy, and is the encryption
that of the header data? (Not DTLS payload.) If possible let's name the
entities here and what is encrypted.
In some installations, layer 2 protection is provided between all
member pairs of the mesh. In such an environment encryption of the
CBOR array is unnecessary because the layer 2 protection already
provide it.
-> I disagree here. (Or maybe I don’t understand the issue.) If the JP does
not encrypt the header data here, then all the (authenticated) mesh nodes on
the path can read the data and may modify it too. If the JP encrypts the header
data, these mesh nodes can modify but the JP will detect it. That seems more
secure so it still helps in this case. Depends on whether you consider an
attacker to be possible "on-mesh". Given that malicious programs get delivered
nowadays in software updates or downloaded scripts, an on-mesh attacker is
certainly possible.
13.2
[RFC6690]
-> This should be a normative reference. Without it, the discovery (CoAP) can't
be implemented.
Appendix A
The payload examples do not conform to the CDDL definition. (They are based on
the old, pre WG last call format.)
Nits
===
General
-> consistency of capitalization of terms - this is not yet applied. E.g.
"pledge" vs "Pledge", "JOIN Proxy" vs "Join Proxy" vs "join Proxy" vs
"Join-Proxy", "CoAP" vs "coap" and perhaps others. This can also be updated in
the future editing phase of course but to me it looks a bit sloppy if the WG
doesn't address this. Some other WGs do this at least ;-)
2.
The term "installation network" refers to all devices in the
installation and the network connections between them. The term
"installation IP_address" refers to an address out of the set of
addresses which are routable over the whole installation network.
-> both terms are never used again in the document. So suggest to remove this
text - it is not needed.
5.3.1
any kind of of per session
-> typo 'of of'
6.1.1
The coaps+jpy scheme is registered is defined
-> is registered and defined ?
6.1.2
Figure 6: Example of Registrar announcing two services
-> isn't it 3 services here? 3 ports are advertised.
9.2
The text contains "{{stateless-jpy}}" which should be a section reference.
13.1
[RFC9032] is not a normative reference as far as I can see. It is only
mentioned in 6.3.2 and this says that 6tisch is not even using the present
protocol.
-----Original Message-----
From: Anima <[email protected]> On Behalf Of Toerless Eckert
Sent: Tuesday, September 6, 2022 19:13
To: Anima WG <[email protected]>; [email protected]; [email protected];
[email protected]
Subject: [Anima] 2nd WGLC for draft-ietf-anima-constrained-join-proxy-12, ends
September 20th 2022
Dear ANIMA WG
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". The WGLC
ends after September 20th, or when all comments received are discussed.
This document had a prior WGLC in October 2021 against revision -04,
which resulted in significant feedback and changes to the document, as seen by
the significant number of updates since them. The authors think
they have addressed all known comments and think the document is ready for WGLC.
Due to the significant changes, we are now doing a second WGLC.
If you had read the document only before or for that last WGLC, please also
read again -12 and provide your feedback to this email thread by
September 20th, 2022. If you do not feel this document should advance,
please state your reasons why.
This document's intended status is Standards Track. At present,
there is no IPR file against this document. If you are aware
of any (new) IPR, please file it (or tell us WG-chairs about
it so we can help file if necessary).
Sheng JIANG is the assigned document shepherd.
Cheers
Toerles, for the chairs
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
