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

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

Hi Mike,

I said a while back that Mark's proposal is fine for transport mode applications,
but for tunnels we still need something like SEAL. I will replay my message from
an off-list discussion below:

Fred
[e-mail]

"Hi, I am not exactly sure where tunnels fit with this discussion but here is my
thinking on tunnels:

1) Tunnels absolutely require some form of fragmentation/reassembly of the
encapsulated packet, as established in 'draft-generic-6man-tunfrag'. This applies
to all tunnels over both IPv4 and IPv6.

2) Since in-the-network fragmentation/reassembly is painful, the tunnel ingress
needs some way of knowing when it is OK to turn it off. For that purpose, we
need RFC4821 for tunnels.

3) RFC4821 probing needs to occur in-band within the ordinay tunneling protocol
messages; otherwise, the probes might take a different path than the ordinary
messages. (The same is true of RFC4821 applied to TCP.)

4) In order to probe the path in-band, the tunneling protocol encapsulation needs
(at a minimum) a "probe" bit and a probe acknowledgement message. That means
that the tunneling protocol needs either a new encapsulation format or a new
version number.

5) Since the same probing process applies to all forms of tunnels (IP/IP, GRE,
IPsec, etc) it would be best to have a generic encapsulation format that applies
equally to all.

6) This new encapsulation format can reuse the bulk of the IPv6 fragment header
format as well as the vast majority of the IPv6 fragmentation and reassembly code.

7) While defining a new fragmentation header format for tunnels, change the
fragment offset field to 8 bits (down from 13) which encodes an integer multiple
of 256 byte segments, i.e., the minimum fragment size is 256 bytes.

We were discussing tunnels several weeks ago before the discussion vectored
off into transport mode considerations. Do we want to start discussing tunnels
again under this thread, or should it be a separate thread?"

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> C. M. Heard
> Sent: Monday, August 26, 2013 9:38 PM
> To: IPv6
> Subject: RE: UDP+Fragmentation (was: "Deprecate")
> 
> Greetings,
> 
> Upon reflection, I have come to the conclusion that the proposal in
> draft-andrews-6man-fragopt (or a variant thereof) is a much better
> solution to the problems with IPv6 fragmentation than the UDP
> segmentation scheme I proposed.
> 
> The huge advantage of putting a skippable IPv6 option with
> higher-layer header information into IPv6 fragments is that it is
> much easier to deploy incrementally than the UDP segmentation
> scheme.  New end systems could begin inserting the option as soon
> the format is standardized, and they would still be able to
> communicate with older end systems that comply with existing IPv6
> specifictions, at least on paths where fragments are not discarded
> by firewalls.  That's not true of the UDP segmentation scheme (or of
> more complex alternatives such as SEAL).
> 
> A second advantage of the proposal in draft-andrews-6man-fragopt,
> or more specifically of a variant that I proposed in
> http://www.ietf.org/mail-archive/web/ipv6/current/msg18849.html,
> is that it can be made to work with any upper-layer protocol,
> present or future.  The UDP segmentation scheme works for one
> protocol only.  (SEAL would work with any upper-layer protocol, but
> since it hides the upper-layer headers, it could well be blocked by
> firewalls for that reason.)
> 
> It is true that firewalls will need to be updated to make the option
> scheme achieve its objective of getting fragments through.  It
> seems, however, that the same is true of the UDP segmentation scheme
> that I proposed; Google for "UDP packet length and the size on the
> wire do not match" for some examples.  (SEAL, being a new
> upper-layer protocol, would also require firewall updates).
> 
> The main lesson I draw from draft-taylor-v6ops-fragdrop is that IPv6
> fragmentation, as currently specified, does not meet the
> requirements of certain operators because upper-layer header
> information is absent from non-initial fragments.  The option scheme
> directly addresses that problem.  Given that the 6man WG is not
> ready to deprecate IPv6 fragmentation, it seems to me that it should
> be rehabilitated to the extent possible, and I think the option
> scheme would do that.
> 
> Thanks and regards,
> 
> Mike Heard
> 
> On Wed, 7 Aug 2013, Ronald Bonica wrote:
> > 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 [b)].
> >
> > 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
> --------------------------------------------------------------------