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 fred.l.temp...@boeing.com > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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:rbon...@juniper.net] > > 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 > fred.l.temp...@boeing.com > > > Ron > > > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] > > > 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 > > > fred.l.temp...@boeing.com > > > > > > > -----Original Message----- > > > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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 ipv6@ietf.org > Administrative > > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > --------------------------------------------------------------- > -- > > -- > > > - > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > -- > > - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > ----------------------------------------------------------------- > -- > > - > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
