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

[Mališa Vučinić <[e-mail]>]

Toerless,

Thanks for the prompt feedback. See inline.

Mališa

> On 8 Apr 2022, at 18:49, Toerless Eckert <[e-mail]> wrote:
> 
> 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:
>> 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.
> 
> 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 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.

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

I see your point and thanks for elaborating on it. 

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

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?

> 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
> 
>> 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.
>> 
> 
> -- 
> ---
> [e-mail]