Greetings,
Chiming in a bit late, I have a few things to add to the thread:
1.) Ron's paraphrase below captures my intent precisely.
2.) As Fred points out (and as I mentioned in my original post), it
is possible that some middleboxes will filter UDP datagrams with
UDP Length > L4 length from IP. However, it would not be
difficult to code up some test scaffolding to get at least some
empirical data on how frequent this might be. I am thinking now
of something along the lines of the data in Section 5.3 of
http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
for IP fragment filtering. Are any operators out there
interested in commissioning/supporting such an effort?
3.) If it turns out that such filtering is common, I agree with Ron
that using a new protocol number is the right way to go. In
that case I would further modify the proposal to make the
transport header format the same in all cases, in order to
simplify implementations (and thereby make them more reliable).
4.) Assuming that such filtering is not common, there are some
aspects of the proposal sketched below that may be worthy of
further discussion and comment:
a.) Segments with partial overlap should not be allowed, for
reasons that are well known to readers of this list (and
implementors of IPv4 fragmentation). A complete overlap can
happen if the network duplicates a segment and should
probably be allowed.
b.) A datagram that gets segmented in the manner proposed below
would need to have at least 16 transport data bytes pushed
into the second and succeeding segments, in order to ensure
that the initial segment has UDP Length > L4 length from IP.
c.) It would need to be clearly specified whether Segment Offset
does or does not include headers. For definiteness I assume
henceforth that it refers to transport data bytes only.
d.) If padding beyond UDP Length is disallowed in segmented
datagrams, then the More Segments bit (M) is not needed,
since in that case the condition
UDP Length = (Segment Offset)*8 + (L4 length from IP - 8)
is equivalent to M=0. In any case this condition must be
satisfied when M=0. Note that padding cannot be allowed in
segments with M=1 (as is the case with all TCP segments).
e.) We may want to re-consider whether to allow padding beyond
UDP Length in non-segmented datagrams. Existing UDP
implementations known to me are liberal on this score --
they ignore padding -- but it may be desirable to eliminate
the potential covert channel. Note that specifying this
behavior for non-segmented datagrams would be an update to
RFC 768 and RFC 1122, which are silent on the matter.
f.) Having the datagram length in every segment tells the
receiver how big a reassembly buffer to allocate, even in
the presence of segment reordering. This has the potential
to simplify the implementation and could partially mitigate
certain classes of reassembly buffer exhaustion attacks.
Mike Heard
On Tue, 6 Aug 2013, Ronald Bonica wrote:
> 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 which required 61 draft versions to get right.
>
> Ron
>
>
> > -----Original Message-----
> > From: Templin, Fred L [mailto:[email protected]]
> > 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
> > [email protected]
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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
> > > > [email protected]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > > >
> > >
> > >
> > >
> >
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
