Re: [secdir] Secdir last call review of draft-ietf-anima-constrained-join-proxy-09

[Peter van der Stok <[e-mail]>]

  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.
> ==>