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

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

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
> --------------------------------------------------------------------