HI Malisa,
thanks for the review.
Toerless having reacted to the first pargraph, I will react to the last part.
Plese, see below.
Peter
Mališa Vučinić via Datatracker schreef op 2022-04-08 15:23:
Reviewer: Mališa Vučinić
Review result: Has Issues
I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.
The document standardizes the functionality of a Join Proxy, which is a node
that relays the traffic between the joining node, Pledge, and the network
Registrar, at the time of the network join. The document defines two modes of
operation of a Join Proxy: Stateful Join Proxy and Stateless Join Proxy.
I have reservations on the progress of this document in its current state from
the interoperability and security points of view.
Interoperability-wise, the operation of a Stateful Join Proxy does not seem to
necessitate a standardization effort as the processing is contained on a single
network node. The Registrar processes the packet from the Join Proxy as any
other packet. The language that describes the operation of a Stateful Join
Proxy in Section 5.1 is informational and describes the process rather than the
protocol. I would consider moving this text outside the “Join Proxy
Specification” section, perhaps into Section 4, which contains informational
text.
Stateless Join Proxy specification in Section 5.3 defines the message format
that the Registrar and the Join Proxy agree on, which is necessary from the
interoperability point of view. The message is split into Header and Content
parts, where Header is opaque to the Registrar and just returned verbatim to
the Join Proxy. In that sense, I don’t understand the need to specify the inner
structure of the Header part. I believe this will only introduce
interoperability issues with future version of the specification. In the last
paragraph in Section 5.3, you argue that if any (new) field is not recognized
by the Registrar, it should be ignored. But then, the protocol simply won’t be
backwards compatible because Stateless Join Proxy will have expected the
Registrar to echo the new fields. Why complicate this and not leave the whole
“Header” struct as an opaque byte string that is just echoed by the Registrar?
pvds==>
Yes, I think you are right. The header structure should be opaque.
If the Registrar needs information stored in the header, then IMO a new draft shoudl]
address this.
I will change the text accordingly if my co-authors agree.
==>
Security-wise, document is incomplete. Without protection of the Header field,
an on-path attacker can easily alter the return address of the pledge to DoS
it. This is all discussed in RFC8974 and RFC9031 so I don’t understand why none
of those concerns are addressed, given the similarity of the topic. Security
considerations or Figure 5 do not elaborate on DoS considerations of either
approach.
pvds==>
I see. The text of RFC8974 seems the most appropriate one. I will refer to it
in the security consideration, taking over the recommended encryption algorithm.
==>
In general, I think that the document would use an editorial pass as there seem
to be many small inconsistencies. For example, Security Considerations talk
about a “CBOR map” while the normative message structure uses CBOR arrays.
pvds==>
Very good. Apologies. This mistake reflects the hitory traject of the document.
==>
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
