Hi Mark, > -----Original Message----- > From: Mark Andrews [mailto:[email protected]] > Sent: Wednesday, August 07, 2013 2:54 PM > To: Templin, Fred L > Cc: Doug Barton; [email protected] > Subject: Re: UDP+Fragmentation > > > In message <2134F8430051B64F815C691A62D983180E170A@XCH-BLV- > 504.nw.nos.boeing.co > m>, "Templin, Fred L" writes: > > Hi Mark, > > > > > -----Original Message----- > > > From: Mark Andrews [mailto:[email protected]] > > > Sent: Tuesday, August 06, 2013 7:32 PM > > > To: Templin, Fred L > > > Cc: Doug Barton; [email protected] > > > Subject: Re: UDP+Fragmentation > > >=20 > > >=20 > > > In message <2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- > > > 504.nw.nos.boeing.com>, "Templin, Fred L" writes: > > > > > On 08/06/2013 03:07 PM, Templin, Fred L wrote: > > > > > > 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. > > > > > > > > > > So in other words let's make all the same mistakes we made with > the > > > > > design of IPv6? :) > > > > > > > > Not even. This is about fixing and atoning for mistakes; not > > > > introducing new ones. > > > > > > > > Thanks - Fred > > > > [email protected] > > > > ----------------------------------------------------------------- > --- > > > > IETF IPv6 working group mailing list > > > > [email protected] > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > ----------------------------------------------------------------- > --- > > >=20 > > > There are several issues with getting fragments through firewalls. > > > My draft addresses one of them. > > >=20 > > > Putting all the headers into the initial fragment is another part > > > of fix / reducing the issue. If you don't do something like that > > > firewall will drop initial fragments because that can't be expected > > > to reassemble unless they are doing DPI. > > >=20 > > > Making fragment sizes more even is yet another part of the issue. > > >=20 > > > Allowing tunnel entry points to re-fragment fragments is yet > another > > > part of the solution space. > > > > In these points, you are making a good case for SEAL. > > And all those changes are independent of a SEAL header. They are > changes to the fragmentation algorithm.
But, an attacker does not need to implement the changes to the fragmentation algorithm in order to be compliant with the specs. > SEAL has a big drawback. SEAL requires then tunnel endpoint / > destination node to understand SEAL. Right that the destination needs to understand SEAL. > My draft does not require any other node to understand the option. > You can start sending packets with the option immediately and they > should be passed by nodes that are not aware of what it does. > Destination nodes can process the fragments without knowning the > contents. This is no more dangerous than processing fragmented > traffic without the option if you are already passing fragments. But, does it address the tiny fragment attack profile that Ron's draft is concerned with? And will it be robust as more and more operators unconditionally drop IP fragments? > The key difference is HEADER vs OPTION. That's right, but without a new header there is no means to probe the path MTU or even to ping the destination to see if it is up as part of the protocol. Plus, we need a multiple-part solution that not only addresses transport-mode UDP fragmentation but also tunnel-mode operation for tunnels that would otherwise be susceptible to MTU issues. Thanks - Fred [email protected] > Mark > > > Thanks - Fred > > [email protected] > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: [email protected] > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
