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?

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.

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.