search

tsvwg / draft-ietf-tsvwg-udp-options

0 stars 0 forks source link

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? #45

Open gorryfair opened 2 months ago

gorryfair commented 2 months ago

(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 commented 1 month ago

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.