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 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
> 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.
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.
>
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
