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

[Joe Touch <[e-mail]>]

On 11/1/2015 10:44 PM, Jana Iyengar wrote:
> What Bob said.
> Also, what problem is this draft seeking to solve, especially given that
> 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 <[e-mail]
> <mailto:[e-mail]>> 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.
> 
>     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/
> 
> 
>     _______________________________________________
>     Spud mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spud
> 
>