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

["Templin, Fred L" <[e-mail]>]

Hi Ron,

> -----Original Message-----
> From: Ronald Bonica [mailto:[e-mail]]
> Sent: Tuesday, August 06, 2013 6:46 PM
> To: Templin, Fred L; C. M. Heard; IPv6
> Subject: RE: UDP+Fragmentation (was: "Deprecate")
> 
> 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.

SEAL solves the problem too. Transport-mode SEAL took me 15 minutes
to write, and is really just a couple of paragraphs. In addition to
providing a universal sublayer that can handle any transport protocol
'X', SEAL also provides an RFC4821 path MTU probing facility. And, if
ingress filtering is thought to be a problem, it also provides a data
origin authentication facility.

It seems Ron that you are trying to avoid a closer examination of SEAL.


Thanks - Fred
[e-mail]
 
>                                                       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
> > > -------------------------------------------------------------------
> -
> >
>