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.
==>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
