Subject: [Last-Call] Secdir last call review of draft-ietf-anima-constrained-join-proxy-09

From: Mališa Vučinić via Datatracker <[email-masked]>
Date: Fri, 08 Apr 2022 06:23:38 -0700

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?

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.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 8 Apr 2022 18:49:26 +0200

Malisa,

Thanks a lot for the review.

Just quick feedback on one of your points

On Fri, Apr 08, 2022 at 06:23:38AM -0700, Mališa Vučinić via Datatracker wrote:
> network node.

I disagree with this assessment. The stateful join proxy  is a new element
establishing a distributed machinery between three components, the pledge, the
proxy and the registrar, which requires interoperability between the three.

> The Registrar processes the packet from the Join Proxy as any
> other packet.

The fact that the DTLS state machinery of registrar and pledge do not have to
change over a proxy-free operation is the result of the miticulous, packet by
packet forwarding specified in 5.1. Rather a proof of the opposite of what you
claim. For example: i can easily see how i could build a proxy that would break the
connection by working differently.

> The language that describes the operation of a Stateful Join
> protocol.

It describes packet forwarding based on flow lookup, network header rewrite/recreate
and delivery to new destination. If that isn't a standard demanding protocol operation, then
we should have prohibited single-router-hop rfc791 networks, bcause this is already sso
much more interoperable machinery than what is described in that rfc.

Btw: Nobody says you can't build a multi-proxy-hop-network, its just not
the desire of this spec to standardize it.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 8 Apr 2022 19:41:04 +0200

Toerless,

Thanks for the prompt feedback. See inline.

Mališa

> On 8 Apr 2022, at 18:49, Toerless Eckert <[email-masked]> wrote:
> 
> Malisa,
> 

The following sentence attracted my attention:

"The Pledge initiates its request as if the Join Proxy is the intended Registrar."

My line of thinking was that if the pledge were specified to contact any node it discovers through the discovery mechanism, be it a Registrar or a Join Proxy, and sends to its link-local address, the processing would still be the same on the pledge and on the Registrar. But, as you say, there would still need to be a component implemented in each node to handle the Join Proxy functionality to make it work multiple hops away from the Registrar. So, indeed, text that describes that is needed from the interop point of view, so I acknowledge that my initial assessment was wrong.

> connection by working differently.

I see your point and thanks for elaborating on it. 

> much more interoperable machinery than what is described in that rfc.

I was referring to the following text in the normative 5.1 section:

"Assume that the Pledge does not know the IP address of the Registrar it needs to contact. The Join Proxy has been enrolled via the Registrar and learns the IP address and port of the Registrar, for example by using the discovery mechanism described in Section 6. The Pledge first discovers (see Section 6) and selects the most appropriate Join Proxy. (Discovery can also be based upon [RFC8995] section 4.1). For service discovery via DNS-SD [RFC6763], this document specifies the service names in Section 9.2. The Pledge initiates its request as if the Join Proxy is the intended Registrar. The Join Proxy receives the message at a discoverable join-port.”

I am not arguing to *remove* this text, rather to separate it from the rest of the paragraph, which clearly describes the processing at the Stateful Join Proxy. Is this text also applicable to the Stateless Join Proxy case, or I got that wrong?

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 11 Apr 2022 09:35:14 +0200

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:

> I have reviewed this document as part of the security directorate's 
> ongoing
> protocol. I would consider moving this text outside the "Join Proxy
> Specification" section, perhaps into Section 4, which contains 
> informational
> text.
> 
> the Join Proxy. In that sense, I don't understand the need to specify 
> the inner
> by the Registrar, it should be ignored. But then, the protocol simply 
> won't be
> "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.
> ==>
> 
> it. This is all discussed in RFC8974 and RFC9031 so I don't understand 
> why none
> 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.
> ==>
> 
> 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.
> ==>