Re: Fragmentation-related security issues

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Fernando Gont writes:
> Florian,
> 
> On 01/05/2012 06:40 AM, Florian Weimer wrote:
> >>> Do we really know that adding a fragment header to all outgoing packets
> >>> does not cause them to be rejected? 
> >>
> >> Are you arguing that IPv6 fragmentation does no work at all, or what?
> > 
> > I fear that it might work as well as in IPv4, that is, you can only get
> > there with some effort, and for some nodes, it will never work.
> 
> But that's an entirely different question. If you're thinking about e.g.
> banning all fragmentation from IPv6, that's certainly completely
> unrelated to the two I-D's that I've published on the subject...
> 
> 
> 
> >>> Could this be deployed at large DNS servers in a risk-free fashion,
> >>> for instance?
> >>
> >> What's the specific question you're asking, and what is your concern,
> >> specifically?
> > 
> > If DNS servers started sending either atomic fragments or fragmented
> > responses today (i.e., all generated packets carry an IPv6 extension
> > header), would these servers become unreachable for some clients?
> > (I think we have to assume the answer is "yes".)
> 
> Because some clients ignore atomic fragments, because fragments would be
> dropped in the path to the client, or what?
> 
> Note: I'm interested on the topic, but this one has to do more with Mark
> Andrews' proposal than with mine. -- Mine is about how to improve the
> state of affairs of IPv6 fragmentation. Mark's is about increasing its use.

I'm more about making DNS work reliably.  We have forced fragmentation
of DNS/UDP/IPv6 datagrams, using IPV6_USE_MIN_MTU, since Jun 2000.

Some other vendors havn't and that does result in operational
problems as PMTUD is not reliable.  Which can be seen when you
repeatedly send the same DNS query to the same server but only
get the last fragment when there is a tunnel in the reply path.

Additionally, even if the PTB message gets through it is usually
server to client traffic that gets dropped and servers don't keep
a history of the responses they have sent over UDP so it requires
a client timeout and requery to get the response resent.

If you have a several of servers for a zone it can be several seconds
before client retries the query to the first server, even with sub
second timeouts, as the client assumes the server is *dead* and
moves on to the next server.

IPV6_USE_MIN_MTU works for clients that have a MTU path 1280 or greater.
IPV6_USE_MIN_MTU does NOT work for clients that have a MTU path < 1280,
which is a gap in spec.  draft-andrews-6man-force-fragmentation is
about filling in that gap.

IPV6_USE_MIN_MTU was developed to deal with the issue of PMTUD being
bad for DNS.  draft-ietf-ipngwg-bsd-frag was the early work that
eventually became IPV6_USE_MIN_MTU.

> > IPv4 is different in this regard because clients can opt out from
> > fragmented responses by requesting 512 byte responses (even if it's
> > technically a DNS protocol violation).  This is just not possible with
> > IPv6---unless the server keeps per-client state, which is a non-starter
> > for large DNS server deployments.
> 
> Strictly speaking, that's not correct. Requesting 512-byte responses
> does not necessarily avoid fragmentation. The IPv4 MTU is 68 bytes, not
> 576. For instance, OpenBSD's imposes a lower limit of 296 (rather than
> 576 or the like) because such low-MTU technologies exist.
> 
> Thanks,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]