WGLC: 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?

[gorryfair]

(see TSVWG list for full mail)

On Tue, Apr 9, 2024 at 5:01 PM touch wrote:

On Apr 9, 2024, at 3:31 AM, Zaheduzzaman Sarker  wrote:

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? 
//Zahed 

We can prevent that if/when we proceed with the UDP encryption option or using IPsec.

I wanted to make sure we have a consensus here that it is good enough to do so. ... But all this talk about transport protocols and their vulnerability to on-path mods strikes me as hollow. We have had such protections for TCP for a generation (over 25 yrs) with TCP-MD5 and its successor TCP-AO. Neither one protects packets from on-path tampering with IP options, but we’ve had that for just as long too.

What we don’t have is a widely enough deployed key infrastructure. Until that happens, it’s difficult to understand how raising these issues obligates protocol designers.

(I am not sure why that is not widely deployed yet :-).)

The obligation here is that we have thought about the possibilities, understand the pros and cons, made the right choice, and well describe them on what we published.
I am not AD reviewing the document now, but I would not like wait till my AD review to express what I would be looking for. Now you know and can just tell me yes we have done those thoughts and in section XXX we have described it well.

However, there’s a second point I have not seen raised. Saying these options MUST NOT be modified in transit isn’t just for implementers - it’s also for those seeking to standardize such behavior and for those in the IETF who might assess those standards. What we’re saying, besides “don’t do it”, is “don’t standardize it”.

The doc can make that point more clear in the doc, but I don’t see any other action coming from this discussion for the core doc.

Please, do that!!.

I also would suggest we move these discussions off to GITHUB as soon as possible so we can trace them more easily (chairs - what’s the procedure for that? Do you? Does the doc shepherd? Do I?).

I am late to respond and I am not sure I am supposed to respond, but have we created the issue.. It would be great for the record to share the issue link in this email thread.

Joe

---

Request: "The obligation here is that we have thought about the possibilities, understand the pros and cons, made the right choice, and well describe them on what we published."

[gorryfair]

Consensus call comments for:

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

--- Comments follow --- 1) Q3: This one is less clear. Section 9.9 from version 18 defines an Auth option, this was carried over to 11.9 of version 32. However, the Auth option is not fully specified. There are some preliminary requirements that Auth is a SAFE option and should be ignored by default-- it is an open issue as to whether these requirements are acceptable for an Auth option. Since authentication isn't being fully specified at this time, I suggest simply removing section 11.9 without loss of useful content. It is sufficient to say that UDP options are extensible and an Auth option could be specified in the future.

Note: Already discussed - and was included as issue #58.

2) Q1/3 See 3. below, unless we find a way for the receiver to assert that a packet was not modified, I would think it more pragmatic to go for 'SHOULD NOT'...

The consequence of 1 and 3 seems to be that the only defence against on-path manipulations is the wording "UDP Options MUST NOT be modified in transit" and IMHO even more tricky the receiver has no way to actually detect such changes. This should not stand, either we allow on-path changes (no need to endorse them thjough) or we make UDP options sufficiently complete to detect them.

Note: There is a suggested improvement.

3) Q2: The text in #2 is weaker than the requirement in #1 (MUST NOT), as the IETF seems to now accept that NAT and ALGs are part of the Internet and so there are obviously portions of the transport datagram that get modified in-transit.  I think my comment here is similar to Sebastian's mentioning MSS clamping.  I don't know if a good solution to this discrepancy might be to weaken the "MUST NOT" to a "SHOULD NOT", and trust that the rest of the text is discouraging enough to carry the WG's intention.

Either way, realistically, I think that option additions and modifications on-path are likely to happen, so the question is probably whether we want to leave the door a little bit open (via "SHOULD NOT") to make sure the IETF can properly specify how those special cases are least-harmfully done (i.e. similar to the old BEHAVE WG goals), or to just stick with the "MUST NOT" and insist that it is not valid behavior (in which case, the text in question 2 is too weak).

I am fine either way, just want to point out the discrepancy between #1 and #2.

Note: There is a suggested improvement.

4) Q3: Kinda. It is a bit too weak.

I will rather say "Mechanisms to support encryption/authentication will separately be added at a later stage (see section 9.9,9.10)." This will establish the expectation that intermediaries should definitely not attempt to modify the content of options, and should not rely on being able to understand that content.

Note: This is a suggested improvement.

[Mike-Heard]

I do not think that any of the proposed text changes add value.

[Mike-Heard]

To resolve Issue #43, an 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]).

The editor believes that the update proposed above should suffice to address Issue #45 as well.

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