Subject: [tsvwg] Security section of UDP options draft

From: Christian Huitema <[email-masked]>
Date: Sun, 3 Apr 2022 13:44:07 -0700

I am reading the security section of the UDP option draft, and I think 
it needs some work. The security section delineates some attacks, 
concentrating on usage of malformed option trailers as a way to create 
problems at the receiver, but does not analyze possible misuse of UDP 
options in other forms of attacks. The draft includes the initial 
definition of a number of options, but does not include specific 
security analysis of these options. I think it should do that -- or 
maybe reduce the number of options defined in this draft, and rely on 
specific per-option drafts to separately analyze each of the option. It 
should also analyze the increased attack surface opened by UDP options, 
such as possible misuse of UDP option by transit providers, including 
also consequences of possible stripping of the option field.

For example, the draft defines an "UDP echo" option. That seems 
redundant with the ICMP Ping option, and also with the previously 
defined UDP ECHO protocol, and could very well be used in attacks. Such 
options have indeed been used by a variety of attacks in the past, such 
as exploring available addresses and ports on a remote network, or using 
echoes to launder attacks against unsuspected third parties. That's a 
great example of an option that either should be defined in its own 
draft allowing for complete analysis. Barring that, there should be a 
specific analysis of such potential abuses and prescription of the 
corresponding mitigations.

I did not analyze all the potential options, but I am pretty sure that 
attackers can find creative use of maximum datagram sizes, timestamp and 
authentication. Application level protocols, IPSEC and various 
"transports over UDP" already define similar services. Having alternate 
definitions inside UDP surely has potential for mischief, and that 
should be analyzed. Or, maybe, we should wait until there are actual 
application driven use cases before defining such options.

The draft states that UDP options are for transport, not transit, but I 
don't see a foolproof mechanism to prevent transit node from rewriting 
the option field. Yes, the Option Checksum protects the values, but we 
know that NAT routinely rewrite such checksums, so I can only assume 
that attackers could rewrite such options and rewrite the OCS and APC 
fields. For example, we have seen attacks in the past with network 
providers adding "supercookies" to HTTP headers. They could easily add 
such cookies as UDP options, leaking information from the network to the 
endpoint. Similarly, UDP options could be used to leak information from 
the endpoint to the network. They could also provide a hidden channel 
for exfiltration of information, bypassing the controls of local 
firewalls. I do not see a discussion of these issues in the security 
section.

Another obvious option for transit nodes is to completely strip the 
option field, truncating the IP packets to just fit the UDP payload 
length. This might be a popular behavior if local administrators are 
concerned with potential attacks through UDP options. Option stripping 
is bound to have effects on applications that rely on UDP options. that 
too should be discussed in the Security section.

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Sun, 3 Apr 2022 15:45:19 -0700

> On Apr 3, 2022, at 1:44 PM, Christian Huitema <[email-masked]> wrote:
> 
> I am reading the security section of the UDP option draft, and I think it needs some work.

It does. All your points will be addressed after we finish convergence on the rest of the spec. 

It’s worth noting that no UDP option generates a direct response; all that include replies occur only with other user traffic. 

But these and other points will be addressed.

Joe.