Subject: Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt

From: Bob Briscoe <[email-masked]>
Date: Mon, 2 Nov 2015 06:05:52 +0000

Joe,

Before starting measurements, I would recommend searching the Web for 
the manuals of middleboxes that might block such packets.

For instance, with a quick search of "UDP header length inconsistency" I 
found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such 
packets.

Whether or not there is a buffer overflow vulnerability in any host, 
there will be firewalls and IDSs that block these packets in case 
someone is probing for such vulnerabilities.

bob

On 14/08/15 19:35, C. M. Heard wrote:
> On 7/22/2015 09:52 AM, Joe Touch wrote:
>> On 7/21/2015 11:22 PM, Brian Trammell wrote:
>>> hi Joe,
>>>
>>> Thanks for this draft; I appreciate the elegant redundancy-reducing
>>> length hack. :)
>>>
>>> Data in this case is, I know, hard to come by, but would you have
>>> any feel for how much stuff out there will just break when they see an
>>> inconsistency between IP and UDP length information?
>> I have students starting this fall who will look into this and do some
>> tests. We have no information yet.
> In an off-list e-mail exchange with Joe a couple of weeks ago, I noted
> that every host stack implementation whose code I have inspected simply
> ignores bytes that are past the UDP length but within the IP payload
> length.  The BSD-derived stacks trim the excess bytes before the data
> is passed to the application via the sockets interface.  However, one
> embedded stack I have seen (which does not use a sockets API) makes
> all data available to the application, including the UDP header, and
> lets the application deal with excess bytes as it sees fit.
>
> I have zero information on the behavior of middleboxes (NAT/NAPT).
>
> Assuming that Joe's tests confirm these observations for both end
> systems and middleboxes, then the proposed UDP option trailer should be
> incrementally deployable as long as all options therein can be safely
> ignored if not understood.  The degree of utility (or, at least, the
> length of time needed to make them useful) will of course depend
> strongly on whether middleboxes trim the trailer or leave it intact;
> if the prevalent middlebox practice is to trim it, then they won't be
> useful without updating middleboxes as well as end systems.
>
> Also, Joe, if you and your students have the time and resources to look at
> what middleboxes do with UDP packets where the IP header indicates a
> shorter length than the UDP header, that would be useful information, as it
> could open up a possible means to incorporate fragmentation in the UDP
> layer, independent of whether or not an options trailer is present.
>
> Mike Heard
>
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Nov 2015 15:43:40 +0900

On Mon, Nov 2, 2015 at 3:05 PM, Bob Briscoe <[email-masked]> wrote:
> Joe,
>
> Before starting measurements, I would recommend searching the Web for the
> manuals of middleboxes that might block such packets.
>
Please look at NIC offloads also. I am pretty certain that the most
common flavor of checksum offload will break in this proposal since
devices use the value in the UDP length field as the length of the
payload to compute the checksum over. UDP Fragmentation Offload would
similarly be broken, although we can probably live without that (but
we can't live without checksum offload!).

Tom

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 2 Nov 2015 15:44:30 +0900

What Bob said.
Also, what problem is this draft seeking to solve, especially given that
there's no negotiation of options support possible?

- jana

On Sun, Nov 1, 2015 at 10:05 PM, Bob Briscoe <[email-masked]> wrote:

> Whether or not there is a buffer overflow vulnerability in any host, there
> will be firewalls and IDSs that block these packets in case someone is
> probing for such vulnerabilities.
>
>
>
> bob
>
>
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 2 Nov 2015 07:23:44 +0000

On Mon, Nov 02, 2015 at 03:43:40pm +0900, Tom Herbert wrote:
> payload to compute the checksum over.

I had assumed that is what was intended, i.e. that the bytes within
the 'option area' were not protected by the UDP checksum; so I don't
see how that would break NIC checksum offload.

> UDP Fragmentation Offload would similarly be broken,

How?

DF

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 07:24:30 -0800

We did find a few vendors that don't block those packets.

> found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such

Well, since "that which isn't prohibited ought to be permitted", IMO
that' an error in their code.

> Whether or not there is a buffer overflow vulnerability in any host,

This would be an underflow issue, not an overflow one, FWIW.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 07:28:22 -0800

> payload to compute the checksum over. 

That is the intended behavior.

> UDP Fragmentation Offload would

We need to live without broken offloads because offloads are part of the
protocol stack. They can't simply jump in and try to help without being
very careful about corner cases like this.

E.g., we've already seen an offload that merges TCP packets with
different options, which ought to be clearly inappropriate.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 07:35:43 -0800

> there's no negotiation of options support possible?

See Section 3 of the doc.

There is also interest in using this mechanism to allow UDP-Lite (or
something very close thereto) to share the same transport protocol
number as UDP.

Joe

> - jana
> 
> On Sun, Nov 1, 2015 at 10:05 PM, Bob Briscoe <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Joe,
> 
>     Before starting measurements, I would recommend searching the Web
>     for the manuals of middleboxes that might block such packets.
> 
>     For instance, with a quick search of "UDP header length
>     inconsistency" I found Alcatel-Lucent's "Brick" Intrusion Detection
>     System blocks such packets.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Mon, 2 Nov 2015 16:17:45 -0000

Sorry I wasn't at the meeting yesterday in Japan

- Block packets (perhaps firewalls, for instance), but also truncate
(which may be more common on devices doing incremental checksum update).
- I expect the default behaviour is either to copy UDP-L; which means you
lose the options (i.e., truncate - sad but not disaster) or IP-L; which
means you get all (the same as UDP-Lite).

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 2 Nov 2015 16:28:06 +0000

Joe,

The point of my post was in response to:

On 7/22/2015 09:52 AM, Joe Touch wrote:

> I have students starting this fall who will look into this and do some tests. We have no information yet.
so they could go looking for the most likely place where there might be 
problems. A little manual reading could give clues on where to look, to 
save searching loads of Internet paths.

You might even find someone has already probed for this supposed 
'vulnerability' (whether for research or for nefarious puposes), then 
your student wouldn't have to do any work other than get their data, or 
even just cite their paper.

They could also search for phrases like "UDP Length Error" to find 
source code that checks for this, then see what the code does and what 
it is used in.

I am just trying to make their job easier, so they can finish early and 
perhaps do something more useful.

Here's some more links found in a few minutes of searching:

These two show that by default checkpoint firewalls (very common) check 
for consistency betw the two lengths.
Re: [FW-1] UDP length error 
<https://www.mail-archive.com/search?l=[email-masked]&q=subject:%22Re%5C%3A+%5C%5BFW%5C-1%5C%5D+UDP+length+error%22&o=newest>
Malformed Packet & UDP length error 
<https://www.cpug.org/forums/showthread.php/5387-Malformed-Packet-UDP-length-error?s=ffa052f56a7ef3059307123c94f4ac02>

This one shows that a cisco router checks the UDP length of HSRP Hello 
packets is consistent before accepting it:
<https://www.cpug.org/forums/showthread.php/5387-Malformed-Packet-UDP-length-error?s=ffa052f56a7ef3059307123c94f4ac02>Cisco 
Bug: CSCsc13766 - Both HSRP routers are active - UDP length error

I'm not expecting comment on whether you think the alleged 
vulnerabilities these firms are preventing exist, or whether they ought 
to block such packets. I'm just saying they do.

Bob

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 08:43:15 -0800

> (which may be more common on devices doing incremental checksum update).

Sure, which ought to be safe.

> means you get all (the same as UDP-Lite).

For end systems, the only behavior we've seen so far is to copy the UDP
portion (i.e., in legacy mode) and ignore the extension area.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 08:43:54 -0800

> perhaps do something more useful.

Absolutely - thanks for the suggestion and pointers.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Nov 2015 10:15:29 +0900

> different options, which ought to be clearly inappropriate.
Checksum offload conforms to the requirements for host checksum field
processing and Length field handling in RFC768 and RFC1122-- if this
change maintains those requirements then there is no issue.

It is not clear from the draft what the effect on checksum processing
will be. My questions are:

1) What is the UDP payload length for number of bytes to checksum over?
2) What value is in the UDP length field when the checksum is performed?
3) What is the on-the-wire value of the UDP length field?

If the use of UDP options is treated as a "truncation" of the UDP
payload before the checksum calculation is performed then the answers
to the above questions are the same and there is no incompatibility.
The option bytes would not be covered by the UDP checksum however.

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Nov 2015 17:48:55 -0800

> 1) What is the UDP payload length for number of bytes to checksum over?

The udp payload indicated by the udp length field, and the usual IP pseudoheader. 

> 2) What value is in the UDP length field when the checksum is performed?

The length before the trailer.  

> 3) What is the on-the-wire value of the UDP length field?

Same as #2 above.  

> payload before the checksum calculation is performed

It is. 

> then the answers

> The option bytes would not be covered by the UDP checksum however.

Correct. A separate "trailer checksum" would be required to protect the trailer. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 3 Nov 2015 11:04:53 +0900

> Correct. A separate "trailer checksum" would be required to protect the trailer.
That's great. Can you add this description to the draft?

One other question. In this model the options are really part of the
IP payload and not the UDP payload (so presumably this solution is not
UDP specific but can be applied to any protocol). Essentially this
another way to extend IP and so it seems conceivable that these TLVs
could alternatively be put into an IPv6 extension header to accomplish
the same effect (at least for IPv6). Have you considered the tradeoffs
for doing that?

Thanks,
Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Nov 2015 07:45:09 -0800

Hi, Tom,

> On Tue, Nov 3, 2015 at 10:48 AM, Joe Touch <[email-masked]> wrote:
...
> That's great. Can you add this description to the draft?

Will do.

> IP payload and not the UDP payload 

Yes, basically.

> (so presumably this solution is not
> UDP specific but can be applied to any protocol). 

It requires a protocol that has a redundant length field. E.g., TCP does
not, in fact few transport protocols do.

> Essentially this
> another way to extend IP 

I don't see that; IP declares a payload size and a protocol type. As far
as IP is concerned the entire payload area belongs to the protocol type
indicated. It's the protocol's decision how to handle that - for TCP,
there's no separate length field (only a header length). For UDP,
there's a *UDP payload* length, which means we can set it smaller than
what IP has set aside and let *UDP* use the rest.

> and so it seems conceivable that these TLVs

See above. Putting TLVs in the endpoint protocol is already commonly
supported (TCP options are common). TLV parsing support for IPv6 has
been much more difficult to come by in core routers.

Joe