In message <2134f8430051b64f815c691a62d983180e2...@xch-blv-504.nw.nos.boeing.co
m>, "Templin, Fred L" writes:
> Hi Mark,
>
> > -----Original Message-----
> > From: Mark Andrews [mailto:ma...@isc.org]
> > Sent: Wednesday, August 07, 2013 4:56 PM
> > To: Templin, Fred L
> > Cc: Doug Barton; ipv6@ietf.org
> > Subject: Re: UDP+Fragmentation
> >
> >
> > In message <2134F8430051B64F815C691A62D983180E1E06@XCH-BLV-
> > 504.nw.nos.boeing.co
> > m>, "Templin, Fred L" writes:
> > > Hi Mark,
> > >
> > > > -----Original Message-----
> > > > From: Mark Andrews [mailto:ma...@isc.org]
> > > > Sent: Wednesday, August 07, 2013 2:54 PM
> > > > To: Templin, Fred L
> > > > Cc: Doug Barton; ipv6@ietf.org
> > > > 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:ma...@isc.org]
> > > > > > Sent: Tuesday, August 06, 2013 7:32 PM
> > > > > > To: Templin, Fred L
> > > > > > Cc: Doug Barton; ipv6@ietf.org
> > > > > > Subject: Re: UDP+Fragmentation
> > > > > >
> > > > > >
> > > > > > 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
> > > > > > > fred.l.temp...@boeing.com
> > > > > > > -------------------------------------------------------------
> > ----
> > > > ---
> > > > > > > IETF IPv6 working group mailing list
> > > > > > > ipv6@ietf.org
> > > > > > > Administrative Requests:
> > > > https://www.ietf.org/mailman/listinfo/ipv6
> > > > > > > -------------------------------------------------------------
> > ----
> > > > ---
> > > > > >
> > > > > > There are several issues with getting fragments through
> > > > > > firewalls.
> > > > > > My draft addresses one of them.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Making fragment sizes more even is yet another part of the
> > > > > > issue.
> > > > > >
> > > > > > 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?
> >
> > Fred, you are missing the point. You don't need a single ominbus
> > draft. One can have multiple drafts that address different points.
>
> You know, I was thinking pretty much the same thing on my way
> into work today. SEAL didn't set out to address transport mode,
> and until the most recent version left it as "out of scope".
> I'm willing to believe that an incrementally deployable approach
> such as what you are describing could address transport-specific
> requirements.
>
> > Your arguement is that it is not a omnibus draft. It didn't set
> > out to be a omnibus draft.
>
> OK.
>
> > Today legitimate IPv6 nodes send fragments no smaller than 1280
> > unless the first hop is being mapped to IPv4 at the sending node
> > and the IPv4 mtu is less than 1280. 1280 bytes contains the full
> > header chain unless someone is launching a attack.
> >
> > Today firwalls drop fragments that don't have enough information
> > in them to work out if the non-initial fragment can pass without
> > passing all fragments. The initial fragment is dropped because the
> > firewall operator knows it is pointless to send it despite there
> > being enough information.
> >
> > If attackers sends tiny fragments they will continue to be dropped
> > with or without this option as the firewall doesn't have enough
> > information to make the decision in the initial fragment. Legitimate
> > initial fragment however can now be let through as the firewall
> > knows that the other fragments will have the necessary information.
> > Other fragments can be let through with this option as the firewall
> > will pass the legitimate initial fragment.
>
> But, is the firewall going to do any bounds checking on the
> fragmentation offset? Asked another way, is there still an
> overlapping fragment attack profile to be concerned with?
If you only pass initial fragments which contain a complete header
chain RFC 2460 behaviour in the node should be sufficient.
The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may
differ. Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets
arrive, prior to queueing the fragments for reassembly. Only
those headers in the Offset zero fragment packet are retained in
the reassembled packet.
> > Attackers now have to find the slot/pinhole to send attack traffic
> > through instead of just letting through all fragments.
> >
> > Mark
> >
> > > > 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.
>
> This is one part that still concerns me a bit. Sure, the
> application can simply fragment everything larger than 1280
> but wouldn't it be better to have an assured path MTU so it
> knows whether it can suspend the fragmentation process? I'm
> thinking of RFC4821 applied to UDP and/or to specific app's.
If it is worth it to the application they can still do it.
For things like DNS, PMTUD isn't worth the effort. Just fragment
/ segment for a 1280 MTU and be done with it. Named does that today
though it is still a mess to enable because IPV6_USE_MIN_MTU is not
part of POSIX. Named deals with stupid firewalls by sending different
sized EDNS UDP buffer sizes in the requests. Named has to deal
with a effective MTU of 512 + headers as some firewalls still think
DNS/UDP requests can only have a 512 octet payload. Additionally
DNS is sometimes anycasted so PTB's can go to the wrong instance.
> Thanks - Fred
> fred.l.temp...@boeing.com
>
> > > 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
> > > fred.l.temp...@boeing.com
> > >
> > > > Mark
> > > >=20
> > > > > Thanks - Fred
> > > > > fred.l.temp...@boeing.com
> > > > >
> > > > > > Mark
> > > > > > --
> > > > > > Mark Andrews, ISC
> > > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > > > --
> > > > Mark Andrews, ISC
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
