RE: UDP+Fragmentation (was: "Deprecate")

[Ronald Bonica <[e-mail]>]

Fred,

We should probably be clear about which problem we are trying to solve. The following are possibilities:

a) Remove network administrators' motivation for blocking IPv6 fragments. To this end, we assume that the network administrators' primary motivation is the tiny fragment problem. So, we solve the tiny fragment problem by changing the way that IPv6 fragmentation works. In the new fragmentation scheme, each fragment contains parsable information regarding the payload protocol and port.

b) Make UDP-based applications work in a world where network administrators block IPv6 fragments. We do this by either modifying UDP so that it supports fragmentation and reassembly of long payloads or creating a new UDP-like protocol that supports the fragmentation and reassembly of long payloads.

Draft-andrews-6man-fragopt solves the problem posed in draft-bonica-6man-frag-deprecate by solving problem a). Mike's proposal solves the problem posed in draft-bonica-6man-frag-deprecate by solving problem a).

IMHO, both proposals address the problem. We are currently trying to figure out which will work best.

                                                      Ron


> -----Original Message-----
> From: Templin, Fred L [mailto:[e-mail]]
> Sent: Tuesday, August 06, 2013 6:36 PM
> To: Ronald Bonica; C. M. Heard; IPv6
> Subject: RE: UDP+Fragmentation (was: "Deprecate")
> 
> Ron,
> 
> One other thing for now is that Mike's proposal doesn't even address
> the attack vector that 'draft-bonica-6man-frag-deprecate'
> is concerned about. To address the tiny fragment concern, the protocol
> must ensure that tiny fragments cannot ever be created.
> 
> Thanks - Fred
> [e-mail]
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Templin, Fred L
> > Sent: Tuesday, August 06, 2013 3:07 PM
> > To: Ronald Bonica; C. M. Heard; IPv6
> > Subject: RE: UDP+Fragmentation (was: "Deprecate")
> >
> > Hi Ron,
> >
> > > -----Original Message-----
> > > From: Ronald Bonica [mailto:[e-mail]]
> > > Sent: Tuesday, August 06, 2013 2:54 PM
> > > To: Templin, Fred L; C. M. Heard; IPv6
> > > Subject: RE: UDP+Fragmentation (was: "Deprecate")
> > >
> > > Fred,
> > >
> > > If that's the case, we have a good argument for changing Mike's
> > > proposal ever so slightly, so that it uses a new protocol ID. But
> > > still, Mike's proposal is elegant because:
> > >
> > > a) It solves the problem at the right layer
> > > b) It reuses UDP transport machinery. (The only exception is the in
> > > LENGTH field)
> > > c) It reuses IP fragmentation machinery (moving it to the transport
> > > layer)
> > > d) Aside from b) and c), it introduces no new protocol machinery.
> > > So, it can be described in a few short pages. This is in stark
> > > contrast
> > to
> > > SEAL (draft-templin-intarea-seal-61) whose protocol machinery
> > requires
> > > 41 pages to describe
> >
> > There is a lot of boiler plate in the draft that is not required to
> > describe the protocol machinery. Plus, there are many things that
> need
> > to be described in a functional specification beyond just posting a
> > concept in an e-mail thread.
> >
> > > which required 61 draft versions to get right.
> >
> > The best things in life are worth investing the time and energy to
> get
> > right. Plus, SEAL is a universal format that handles both
> > tunnel- and transport-mode requirements for all manners of existing
> > protocols.
> >
> > If we are going to define a new protocol type, let's define one that
> > addresses everything we are currently struggling with and has the
> > extensibility to address additional requirements moving forward into
> > the future.
> >
> > Thanks - Fred
> > [e-mail]
> >
> > >                                                  Ron
> > >
> > >
> > > > -----Original Message-----
> > > > From: Templin, Fred L [mailto:[e-mail]]
> > > > Sent: Tuesday, August 06, 2013 2:58 PM
> > > > To: Ronald Bonica; C. M. Heard; IPv6
> > > > Subject: RE: UDP+Fragmentation (was: "Deprecate")
> > > >
> > > > With a protocol as ossified as UDP, I have a hard time imagining
> > all
> > > > middleboxes passing the packets with what they would see as a
> > > corrupted
> > > > length field.
> > > >
> > > > Thanks - Fred
> > > > [e-mail]
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > > > > Of Ronald Bonica
> > > > > Sent: Tuesday, August 06, 2013 11:49 AM
> > > > > To: C. M. Heard; IPv6
> > > > > Subject: RE: UDP+Fragmentation (was: "Deprecate")
> > > > >
> > > > > Mike,
> > > > >
> > > > > The proposal sounds elegant. I will try to paraphrase it to
> make
> > > sure
> > > > > that I understand.
> > > > >
> > > > > When originating a UDP datagram, the host always queries it
> > > > underlying
> > > > > IP stack to determine the PMTU for the destination. If the PMTU
> > > > > greater than or equal to the size of the payload plus the UDP
> > > header
> > > > > plus the IP header, plus all IP extension headers, the
> > originating
> > > > > host emits a conventional UDP packet which is characterized as
> > > > follows:
> > > > >
> > > > > - Protocol = 17
> > > > > - Length <= L4 length from IP
> > > > >
> > > > > If the PMTU less than the size of the payload plus the UDP
> > > > > header
> > > > plus
> > > > > the IP header, plus all IP extension headers, the originating
> > host
> > > > > emits an unconventional UDP packet which is characterized as
> > > follows:
> > > > >
> > > > > - Protocol = 17
> > > > > - Length > L4 length from IP
> > > > > - Segment Offset, M-bit and Identification fields added to UDP
> > > header
> > > > > before the payload
> > > > >
> > > > > If an unconventional UDP packet arrives a destination that
> > supports
> > > > > unconventional packets, it is reassembled at the transport
> layer.
> > > If
> > > > > an unconventional UDP packet arrives a destination that does
> not
> > > > > support unconventional packets, it is  discarded.
> > > > >
> > > > > Do I have this much right?
> > > > >
> > > > >                           Ron
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]] On
> > > > Behalf
> > > > > Of
> > > > > > C. M. Heard
> > > > > > Sent: Monday, August 05, 2013 11:53 PM
> > > > > > To: IPv6
> > > > > > Subject: Re: UDP+Fragmentation (was: "Deprecate")
> > > > > >
> > > > > > On Thu, 1 Aug 2013, C. M. Heard wrote:
> > > > > > > On Thu, 1 Aug 2013, RJ Atkinson wrote:
> > > > > > > > I agree that C.M. Heard's ideas should be explored in
> more
> > > > > > > > detail
> > > > > > by
> > > > > > > > the IETF.
> > > > > >
> > > > > > The idea was essentially UDP with segmentation fields, which
> > > would
> > > > > > require a new protocol number.
> > > > > >
> > > > > > In an offline discussion with Mark Smith and I kicked around
> > > > > > an
> > > > idea
> > > > > > for an alternate version not requiring a new protocol number,
> > but
> > > > > > relying instead on the redundancy of the UDP Length field.
> > > > > > The
> > > UDP
> > > > > > Length field is not actually needed; TCP does not have one
> but
> > > > > > rather relies on the length reported by the IP layer.  Under
> > > > current
> > > > > > standards, the UDP Length field must be at least 8 and cannot
> > > > exceed
> > > > > > the IP payload length minus the combined length of any
> > extension
> > > > > > headers -- let's call this the L4 length from IP.  Existing
> > > > > > implementations are supposed to drop UDP datagrams that fail
> > this
> > > > > > check, and all the ones I know of do so.
> > > > > >
> > > > > > The question then arises whether it might reasonably be
> > possible
> > > to
> > > > > re-
> > > > > > purpose the case UDP Length > L4 length from IP to mean a
> > > segmented
> > > > > UDP
> > > > > > datagram.
> > > > > >
> > > > > > In that case 8 <= UDP Length <= L4 length from IP would be
> > > > > > intepreted as a standard unsegmented UDP datagram, as is it
> > now.
> > > > > > That's the case pictured below.  Note that if the L4 length
> > > > > > indicated by the IP layer exceeds the UDP Length, then the
> > extra
> > > > > > octets would
> > > > > be
> > > > > > discarded and are not delivered to the application; that is
> > > > > > the behavior of the implementations I know of.
> > > > > >
> > > > > >      0                            15 16
> > > > 31
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |         Source Port           |      Destination Port
> > > > |
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |   Length <= L4 length from IP |            Checksum
> > > > |
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |                          data octets               ...
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    ...
> > > > > >
> > > > > > Now suppose that we have a long UDP datagram that we want to
> > send
> > > > in
> > > > > > segments.  We set the Length and Checksum fields as usual,
> and
> > > then
> > > > > cut
> > > > > > the datagram into segments, each of which looks like this:
> > > > > >
> > > > > >      0                            15 16
> > > > 31
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |         Source Port           |      Destination Port
> > > > |
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |  Length > L4 length from IP   |            Checksum
> > > > |
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |        (reserved = 0)         |       Segment Offset
> > > > |Res|M|
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |                         Identification
> > > > |
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-
> +-
> > +-
> > > +-
> > > > +-+
> > > > > >     |                          data octets               ...
> > > > > >     +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    ...
> > > > > >
> > > > > > We put the same UDP header in each segment, so (if we take
> > > > > > some
> > > > care
> > > > > in
> > > > > > how we choose the length of the segments) each one will have
> a
> > > UDP
> > > > > > Length field that is greater than the IP payload length minus
> > the
> > > > > > combined length of any extension headers.  Implementations
> > > > > > that
> > > > > conform
> > > > > > to the current specifications should discard these segments,
> > and
> > > so
> > > > > > should not mistakenly consider the segmentation fields as
> part
> > of
> > > > > > the application data.  That should make it possible for
> > segmented
> > > > > > UDP datagrams to safely coexist with conventional unsegmented
> > > one,
> > > > > without
> > > > > > getting a new protocol number.
> > > > > >
> > > > > > Possible downsides: some middleboxes may filter such
> > "erroneous"
> > > > > > datagrams, and some existing erroneous implementations may
> > > > > > fail
> > > to
> > > > > > do the checks they should and might mistake these segments
> for
> > > > > > ordinary UDP datagrams.
> > > > > >
> > > > > > Note that this idea does not work with UDP-lite, which
> > > > > > replaces
> > > the
> > > > > > Length field with a Checksum Coverage field.  That could
> > > > > > easily
> > > be
> > > > > too
> > > > > > short to exceed the L4 length from IP.
> > > > > >
> > > > > > Mike Heard
> > > > > > -------------------------------------------------------------
> -
> > > > > > -
> > --
> > > --
> > > > -
> > > > > > IETF IPv6 working group mailing list [e-mail]
> > Administrative
> > > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > > > -------------------------------------------------------------
> -
> > > > > > -
> > --
> > > --
> > > > -
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> -
> > > > > -
> > --
> > > -
> > > > > IETF IPv6 working group mailing list [e-mail]
> > > > > Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > > > > ---------------------------------------------------------------
> -
> > > > > -
> > --
> > > -
> > > >
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>