tsvwg / draft-ietf-tsvwg-udp-options

1 stars 1 forks source link

Various: Commentry on options being opt-in #44

Closed gorryfair closed 2 months ago

gorryfair commented 7 months ago

On 4/9/2024 9:09 AM, Tom Herbert wrote:

I believe that processing of the options is already opt-in. Accepting UDP surplus area (at least ignoring it and not dropping packet) and the checksum processing I described are currently mandatory.

On Tue, Apr 9, 2024 at 10:16 AM Christian Huitema wrote: And that's probably what need to change before this draft is published. Using the surplus area without the explicit consent of the application is an attack. The proper way to stop such attacks is to drop the whole packet, because only that inflicts a cost to the attacker.

Mike Heard: I disagree that use of the surplus area without the explicit consent of the receiver automatically constitutes an attack, as long as the surplus area is ignored by default.

The attitude of dropping whatever you don't have a predetermined use for is exactly what has made IPv4 options and IPv6 extension headers essentially unusable in the open internet.

(see TSVWG list)

Mike-Heard commented 7 months ago

On Tue, Apr 9, 2024 at 10:16 AM Christian Huitema wrote:

On 4/9/2024 9:09 AM, Tom Herbert wrote:

Christian,

I believe that processing of the options is already opt-in. Accepting UDP surplus area (at least ignoring it and not dropping packet) and the checksum processing I described are currently mandatory.

And that's probably what need to change before this draft is published. Using the surplus area without the explicit consent of the application is an attack. The proper way to stop such attacks is to drop the whole packet, because only that inflicts a cost to the attacker.

In case it was not clear, when Tom says "currently mandatory" in the passage above, he is referring to current standards, i.e., RFC 768 as it now stands. He is not referring to the current contents of the UDP Options spec. The change that you are proposing here would thus be a change to current standard behaviour, which is explicitly out of scope for the UDP Options spec.

What the UDP Options spec could do to improve the situation would be to have an API option (or a configuration option that applies to selected listening ports) to drop all packets that contain a non-empty surplus area (i.e., that contain any UDP options at all). This would not address all of the security problems that you raise, but it result in an improvement over the current situation if the UDP Options spec were to be published and adopted.

huitema commented 7 months ago

In short, do not drop by default, but make the dropping behavior "opt in" if the use of option is not desirable. That would certainly alleviate a lot of the perceived security issues.

Mike-Heard commented 3 months ago

Text has been added to Sections 14 and 15 of -33 to stipulate that receivers can drop all packets with UDP options.

Mike-Heard commented 3 months ago

Text has been added to Sections 14 and 15 of -33 to stipulate that receivers can drop all packets with UDP options.

Note: the updated text stipulates that the API setting to do this must default to accepting packets with UDP options and processing them normally.