ZS/CMH: Backwards compatibility with UDP

[gorryfair]

         The backwards compatibility with UDP was considered important in the development of this Spec.

    This point is absent, AFAIK in Section 16 of the draft now.

Adding such a discussion is a reasonable request; IMO the best place would be Section 6 (Design Principles).

[Mike-Heard]

After further review, it seems to me that the following text now in Section 6 adequately addresses this issue:

6. The UDP option mechanism and UDP options themselves should default to the same behavior experienced by a legacy receiver.

   By default, even when option checksums (OCS, APC), authentication, or encryption fail, every received packet is passed (possibly with an empty data payload) to the user application. Options that do not modify user data should (by default) result in the user data also being passed, even if, e.g., option checksums or authentication fails. It is always the user's obligation to override this default behavior explicitly.

Does this address the request in https://mailarchive.ietf.org/arch/msg/tsvwg/xC4M6R0nAmSLgjC-2yGgffk37YI/?

[gorryfair]

I wonder if section 16 might just benefit from a cross-reference to section 6, relating to the interaction with legacy receivers?

[zaheduzzaman]

Yes, ref to section 6 would be helpful here.

[jtouch]

Not sure I have a new response to add here, esp. if we go with the original 1,2,3 proposal posted on the WG:

1. UDP Option are ONLY set and modified by the sender when it decides to add the Options to a packet. Routers ought to forward packets with UDP Options without modification, the current text includes: "UDP Options MUST NOT be modified in transit".

   Is 1 OK for the WG?

2. Since the Options data is not encrypted, a device on the network path might read this option information. Regarding this, the current text includes: "UDP options are intended for use only by the transport endpoints. They are no more (or less) appropriate to be modified in-transit than any other portion of the transport datagram."

   Is 2 OK for the WG?

3. UDP Options does not by itself provide any mechanism for a device to authenticate the format or contents of the options data, or to detect if the surplus area has been removed from a packet. Mechanisms to support encryption/authentication could separately be added (see section 9.9,9.10).

   Is 3 OK for the WG?

(I'll let the chairs post the results of that)

[Mike-Heard]

On 2024-04-22 Gorry wrote:

I wonder if section 16 might just benefit from a cross-reference to section 6, relating to the interaction with legacy receivers?

On 2024-04-22 Zahed replied:

Yes, ref to section 6 would be helpful here.

Section 16 is entitled "UDP Options are for Transport, Not Transit," and when I went to add the requested cross-reference to Section 6, I found that I could not do it in a sensible way -- such a cross-reference IMO would be out of place in Section 16. This makes me suspect that the section where the backward compatibility text was requested was misidentified in the original comment. As I said in an earlier comment, the matter is addressed in Section 6, and that is where the discussion belongs.

Zahed, Gorry: if this response is unsatisfactory and you really want a cross-reference to the backward compatibility text in Section 6 to be added to Section 16, I need some help in crafting it.

[gorryfair]

I don't have a strong opinion: this approach could work. Zahed?

[zaheduzzaman]

In that email thread, I was more focusing on recording the motivations of having UDP options in clear text and it was noted by Gorry that section 16 does not talk about the legacy receivers. Here the legacy receiver can be a transit node, in that case it would need to consider the section 6. That is the link to the section 6. That means section 16 is missing some text to remind on how a legacy receiver in transit should behave.

is this the correct context?

//Zahed

On Thu, Aug 1, 2024 at 2:30 AM Gorry Fairhurst @.***> wrote:

I don't have a strong opinion: this approach could work. Zahed?

— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/43#issuecomment-2261711631, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMTKZBYSZCRJMEBR6AHGHLZPF6SRAVCNFSM6AAAAABGDY277OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRG4YTCNRTGE . You are receiving this because you commented.Message ID: @.***>

[gorryfair]

I think this sounds correct: let's be clear about why clear text is OK - and that this means we can have rules at endpoints, but lack of encryption means we can't prevent reading on the network path - although we can specify these are not allowed to be mutable. I think this just need tidied and simplified. By the way I think we need to eliminate the words /transit node/, that's not a commonly used term - I suggest we use the word "router" to mean something that is not an endpoint (host). Routers that are forwarding do not terminate UDP, unless they act as a tunnel endpoint.

[jtouch]

Routers are very specific devices (RFC1812, and L3 device that decrements TTL by at least 1), but not the only devices that operate on-path. Others include DPI filters (DPIFs), on-link tunnel ingress/egress, and firewalls. The term "transit node" should be defined, but is more inclusive than just routers.

[Mike-Heard]

Quoting Zahed:

In that email thread, I was more focusing on recording the motivations of having UDP options in clear text and it was noted by Gorry that section 16 does not talk about the legacy receivers. Here the legacy receiver can be a transit node, in that case it would need to consider the section 6. That is the link to the section 6. That means section 16 is missing some text to remind on how a legacy receiver in transit should behave. is this the correct context? //Zahed

To re-establish context, here is what was in the initial message of that thread:

Putting my AD hat on, if we specify protocol features only for endpoints to consume and not for endpoints to network, then we should make sure that is case when we design and describe it. We cannot expect all the intermediaries are well behaved or features are used as intended when designed. From that point of view it is not good enough to send information in clear and just say "UDP Options are for Transport, Not Transit". With the current, well placed, scrutiny of privacy and security on all the protocols that IETF is producing- It would require a huge exception to get it published.

The questions I would like to get answer is -

Is it OK for the endpoints to send information in UDP options which can be read (only) by the transit nodes and react to it? if NO,  then how to prevent that to happen? 

It was subsequently determined that there is WG consensus that it is OK for the endpoints to send information in UDP options without encryption, thus allowing them to be read by the transit nodes. Reading between the lines, I think what is being asked for in Section 16 is a justification for this decision. If that is the case, I think I can craft some text to that effect; that text should also address Issue #45. Please let me know, and if the answers are favorable, I will post the proposed text here for further discussion.

[gorryfair]

I agree there can be other devices. Clarity is what is important. Perhaps, instead of defining a new term 'transit node' you could simply just explain 'routers or other on-path devices that can read UDP headers'? ... I'd be happy with anything clear.

[jtouch]

how about "routers or other on-path devices that can read UDP headers, including firewalls, tunnel ingress/egress, and deep-packet inspection filters (DPIFs)"

[zaheduzzaman]

Quoting Zahed:

In that email thread, I was more focusing on recording the motivations of having UDP options in clear text and it was noted by Gorry that section 16 does not talk about the legacy receivers. Here the legacy receiver can be a transit node, in that case it would need to consider the section 6. That is the link to the section 6. That means section 16 is missing some text to remind on how a legacy receiver in transit should behave. is this the correct context? //Zahed

To re-establish context, here is what was in the initial message of that thread:

Putting my AD hat on, if we specify protocol features only for endpoints to consume and not for endpoints to network, then we should make sure that is case when we design and describe it. We cannot expect all the intermediaries are well behaved or features are used as intended when designed. From that point of view it is not good enough to send information in clear and just say "UDP Options are for Transport, Not Transit". With the current, well placed, scrutiny of privacy and security on all the protocols that IETF is producing- It would require a huge exception to get it published. The questions I would like to get answer is -

Is it OK for the endpoints to send information in UDP options which can be read (only) by the transit nodes and react to it? if NO,  then how to prevent that to happen? 

It was subsequently determined that there is WG consensus that it is OK for the endpoints to send information in UDP options without encryption, thus allowing them to be read by the transit nodes. Reading between the lines, I think what is being asked for in Section 16 is a justification for this decision. If that is the case, I think I can craft some text to that effect; that text should also address Issue #45. Please let me know, and if the answers are favorable, I will post the proposed text here for further discussion.

I think you read is correct, please propose the text.

[Mike-Heard]

Quoting Zahed:

I think you read is correct, please propose the text.

The proposed update in the editor's copy of -33 changes the last paragraph in Section 16 as follows:

OLD:

Unless protected by encryption (e.g., UENC or via other layers, e.g., IPsec), UDP options remain visible to devices on the network path.

NEW:

Unless protected by encryption (e.g., UENC or via other layers, e.g., IPsec), UDP options remain visible to devices on the network path. The decision not to require mandatory encryption for UDP options to prevent such visibility was made because the key infrastructure necessary to support such encryption does not exist in many of the deployment scenarios of interest, notably those that use UDP directly as a stateless and connectionless transport protocol (see, e.g., [He24]).

Kindly let me know whether the proposed resolution is satisfactory or still needs work.

[jtouch]

Looks OK to me...

[zaheduzzaman]

Quoting Zahed:

I think you read is correct, please propose the text.

The proposed update in the editor's copy of -33 changes the last paragraph in Section 16 as follows:

OLD:

Unless protected by encryption (e.g., UENC or via other layers, e.g., IPsec), UDP options remain visible to devices on the network path.

NEW:

Unless protected by encryption (e.g., UENC or via other layers, e.g., IPsec), UDP options remain visible to devices on the network path. The decision not to require mandatory encryption for UDP options to prevent such visibility was made because the key infrastructure necessary to support such encryption does not exist in many of the deployment scenarios of interest, notably those that use UDP directly as a stateless and connectionless transport protocol (see, e.g., [He24]).

Kindly let me know whether the proposed resolution is satisfactory or still needs work.

Looks good to me, thanks!