Subject: [tsvwg] Middlebox Treatment of UDP Surplus Area (was: Checksums in UDP options)

From: "C. M. Heard" <[email-masked]>
Date: Thu, 6 Sep 2018 10:37:45 -0700

On Thu, 6 Sep 2018 09:19:50 -0700 Tom Herbert wrote:
> On Thu, Sep 6, 2018 at 8:35 AM, Gorry Fairhurst wrote:
> > Welcome to my world: Some middleboxes will strip the UDP options field. I
> > don't like that. However, it will happen. Fortunately,iIt's easy enough to
> > spot this if your app sends an option!
>
> Don't forget, they're not stripping UDP options field, they're
> stripping UDP slack space. Honestly, I'm surprised that firewalls
> don't commonly do this. You would think they'd see this as an obvious
> covert channel.

Are there measurements like those done for IPv6 extentsion headers
that show how likely it is that UDP packets with a surplus area will
either be dropped or have the surplus area stripped, or is this all
speculation at this point? I have seen firewall product literature
indicating that they have a capability to alarm/filter when the
UDP length and the amount of data in the IP payload don't
agree, but I could not determine what the default was.

Earlier in the thread I saw a message from Gorry stating:

> We're planning tests with various options for the OCS across various
> networks with middleboxes and expect to have results by the next IETF
> that shed some light on what OCS works in the wild and what doesn't.
> We're hoping to be able to present the results to map-rg if there is time
> at the next meeting.

Hopefully this work will address the general question of whether
UDP options have a reasonable chance of working at all.

Mike Heard

P.S.: I took the following editorial liberty

s/slack space/surplus area/

in order to conform to the terminology in the draft.