Subject: Fragmentation-related security issues

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Dec 2011 11:25:06 -0300

Folks,

We have published two new IETF I-Ds about fragmentation related security
issues.

The first I-D is entitled "Security Implications of Predictable Fragment
Identification Values"
(http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-00.txt).
Its abstract is:

---- cut here ----
   IPv6 specifies the Fragment Header, which is employed for the
   fragmentation and reassembly mechanisms.  The Fragment Header
   contains an "Identification" field which, together with the IPv6
   Source Address and the IPv6 Destination Address of the packet,
   identifies fragments that correspond to the same original datagram,
   such that they can be reassembled together at the receiving host.
   The only requirement for setting the "Identification" value is that
   it must be different than that of any other fragmented packet sent
   recently with the same Source Address and Destination Address.  Some
   implementations simply use a global counter for setting the Fragment
   Identification field, thus leading to predictable values.  This
   document analyzes the security implications of predictable
   Identification values, and updates RFC 2460 specifying additional
   requirements for setting the Fragment Identification, such that the
   aforementioned security implications are mitigated.
---- cut here ----

The second I-D is entitled 'Processing of IPv6 "atomic" fragments'
(http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments-00.txt).
Its abstract is:

---- cut here ----
   IPv6 allows packets to contain a Fragment Header, without the packet
   being actually fragmented into multiple pieces.  Such packets
   typically result from hosts that have received an ICMPv6 "Packet Too
   Big" error message that advertises a "Next-Hop MTU" smaller than 1280
   bytes, and are currently processed by hosts as "fragmented traffic".
   By forging ICMPv6 "Packet Too Big" error messages an attacker can
   cause hosts to employ "atomic fragments", and the launch any
   fragmentation-based attacks against such traffic.  This document
   discusses the generation of the aforementioned "atomic fragments",
   the corresponding security implications, and formally updates RFC
   2460 and RFC 5722 such that the attack vector based on "atomic
   fragments" is completely eliminated.
---- cut here ----

Any feedback will be very appreciated.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2011 12:19:29 +1100

When thinking about this draft please consider the following:

http://tools.ietf.org/html/draft-andrews-6man-force-fragmentation-00
http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 16 Dec 2011 12:42:14 -0300

Hi, Mark,

> http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00

I've just read both of them. The relationship I've found with these two
and the two I've authored is that your I-D's will lead to an increase of
IPv6 "atomic fragments". This means that:

*
<http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments-00.txt>
is even more desirable, as it would completely mitigate
fragmentation-related attacks against DNS traffic that is not really
split into several packets (but still contains a Fragment Header.

* Implementation of
<http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-00.txt> at
the sending node would help mitigate some fragmentation-related attacks
against receivers that do not yet implement the "atomic packets"
behaviour described above, or in scenarios in which DNS traffic is
really fragmented (i.e., packets are split into multiple pieces).

Does this agree with your assessment? Am I missing something?

P.S.: I'll be sending feedback about your I-Ds in separate e-mails.

Thanks!

Best regards,

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Dec 2011 10:45:24 +1100

> P.S.: I'll be sending feedback about your I-Ds in separate e-mails.

The real worry is the amount of state that busy authoritative servers
will be maintaining.  At 13K+ mostly unique clients a second to answer
that's a lot of state.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 16 Dec 2011 21:43:25 -0300

> will be maintaining.  At 13K+ mostly unique clients a second to answer

Well, that's assuming the queries are really fragmented into more than
one packet. Is there any data about this? (i.e., size of requests)

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Dec 2011 13:03:06 +1100

> one packet. Is there any data about this? (i.e., size of requests)

It's the state on the sending side I'm worried about.  You are
adding ~13K entries a second to the destination cache it will
soon get large as *every* DNS/UDP response has a fragmentation
header.

Instead of maintainin a counter on a per-destination basis, hash
the source and destination and use a pool of fragment counters
possibly using differently seeded lsfr.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 17 Dec 2011 00:12:04 -0300

> soon get large as *every* DNS/UDP response has a fragmentation

Well, the problem you mention with the destinations cache is not really
introduced by this algorithm -- the Destinations Cache is there anyway
(it is not created because of this).

If the Destinations Cache gets too big, you prune part of the entries,
and then the worst thing that can happen is that when the Fragment ID is
reinitialized with a random number for a future communication instance,
there's a Fragment ID collision, and the corresponding fragments get
discarded.

However,since the Identification field of the IPv6 Fragment Header is
much larger than that of IPv4, I'd argue that collisions are rather
unlikely (for instance, the reason for which we're proposing the
algorithm we¿re proposing rather than simply randomizing the Fragment ID
for each packet is to avoid collisions when two systems are transferring
a lot of data, at a high rate.... since in those scenarios, and with the
ever increasing data rates, there might be collisions)

> possibly using differently seeded lsfr.

FWIW, Linux and Solaris have already implemented this algorithm.

IIRC, an earlier version of this document proposed something along the
lines of what you mention. But IIRC we abandonded the idea because
implementers were concerned about computing a hash for each outgoing
packet.

That aside, one should be careful with the approach you're describing.
Unless the number of counters is really large, then it wouldn't be hard
to learn the current value of all counters -- after all, you have 64
bits in the Interface ID to play with, which could possibly let you
learn the current value of all the "Fragment ID" counters (i.e., not as
bad as a global counter, but still not good enough).

All the above said, take this as "brainstorming"... if we conclude that
it would be best to provide a number of alternative algorithms, or even
change the currently recommended algorithm, I'd have no problems with that.

(the current one is the result of discussions with the v6 developers of
a number of OSes... but there's always room for improvement)

Thanks!

Best regards,

---

From: Florian Weimer <[email-masked]>
Date: Tue, 20 Dec 2011 10:00:56 +0000

>    bytes, and are currently processed by hosts as "fragmented

Does such traffic actually occur in the wild, or would it only be used
in attacks?

>    fragments" is completely eliminated.

My feeling is that such atomic fragments should be dropped from the
protocol.

Per previous WG discussion, when reassembling such atomic fragments,
IPv6 implementations must ignore the upper 16 bits of the fragment ID
(otherwise the stateless v4/v6 gateways won't work).  Clearly, this is
not desirable.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: [email-masked]
Date: Tue, 20 Dec 2011 12:44:58 +0100 (CET)

> Does such traffic actually occur in the wild, or would it only be used

Such traffic absolutely occurs in the wild. I have three reasonably
busy name servers where this is logged as an error from the ipfw code,
e.g.

Dec 16 14:04:04 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 17 00:27:20 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 18 07:53:10 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 18 23:21:37 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 19 03:07:43 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 19 05:09:45 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 19 21:47:46 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 20 08:10:59 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 20 08:59:21 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
Dec 20 11:25:59 slem kernel: IPFW2: IPV6 - Invalid Fragment Header

This is because these name servers haven't (yet) been upgraded to a
FreeBSD version where bug report kern/145733 haven't been fixed. It
*is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Dec 2011 18:36:31 -0300

Hello, Florian,

> Does such traffic actually occur in the wild, or would it only be used

They have been seen in the wild. That aside, I don't know whether e.g.
NAT64 or the like used this (.e.g, whether they are used for transition
technologies as envisioned in RFC 2460). However, it might also be the
case that such "atomic fragments" are generated when communicating
through networks that do not really have a MTU >= 1280. In such
scenarios there might be some for of gateway that sends the ICMPv6 PTB
advertising a Next-Hop MTU smaller than 1280, thus resulting in atomic
fragments (such that it's easier for the "gateway" to fragment the IPv6
packets).

BTW, I seem to recall that when doing some testing, Linux doesn't react
to ICMPv6 PTB < 1280 as indicated in the specs. Can you confirm this?
ANd, if so, if this a bug, or "intented" behavior?

> My feeling is that such atomic fragments should be dropped from the

There seems to be stuff relying on them....

That aside, there's the proposal by Mark Andrews which would add yet
another use case for these atomic fragments.

> (otherwise the stateless v4/v6 gateways won't work).  Clearly, this is

I may be missing something, but: when sending from the v6 side to the v4
side, we can probably assume that only the low order 16 bits of the
Fragment Identification field are used (whether you set the rest of the
bits or not, it doesn't matter -- particularly if the Fragment
Identification for each destination is a linear function (as e.g. in the
algorithm proposed in the I-D)). That is, you don't really need to do
anything special with the high order bits.

Am I missing something?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Dec 2011 01:02:41 +1100

> *is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE.

Not yet.
http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log
 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 21 Dec 2011 16:16:07 +0100 (CET)

> http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log

Sorry, you're right. I had patched it on my own 8.2-STABLE servers and
forgotten all about it (since the error messages stopped).

Hopefully this will be merged to 8.2-STABLE soon.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Dec 2011 13:40:11 -0300

Hi, Mark,

>> Dec 17 00:27:20 slem kernel: IPFW2: IPV6 - Invalid Fragment Header
[....]
> http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log

Is the aforementioned traffic the result of an implementation of your
proposal for for DNS/UDP?

If that's the case, what's the interface that you use for forcing the
atomic fragments?

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Dec 2011 09:39:16 +1100

> proposal for for DNS/UDP?

No. I haven't fiddled with any kernel code to do this.  I could do
it with raw sockets but I havn't done so.  The following should
work.  Bind to a socket so reply traffic is handled then use that
socket's port and address to construct a packet with a fragment
header to send using the raw socket.

My main worry is getting DNS/UDP fragmented at IPv6 minumum MTU as
that is not being done today despite the being a API to do it and
as a result I'm seeing lookup failures.  Forcing the addition of a
fragment header is dotting the i's and crossing the t's.

The above fix should have been merged by now if the MFC in 2 weeks
had been heeded.  8-stable is still FreeBSD's latest stable branch.
9.0 is still at release candidate.

Mark

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Dec 2011 20:44:18 -0300

On 12/21/2011 07:39 PM, Mark Andrews wrote:
> No. I haven't fiddled with any kernel code to do this.

So,,, any idea about what is actually producing these atomic packets?

> fragment header is dotting the i's and crossing the t's.

Sorry: I understand the potential problem with sending packets >1280.

But doesn't sending 1280-sized packets solve the problem? i.e., what are
the boxes that currently implement the RFC2460-specified behavior of
"translating devices wshi leverage the IPv6 fragment header to fragment
an IPv6 packet into the ipv4 world"?

NAT64? The link-radios that RJA mentioned? Anything else?

For the most part, I'm curious about what is generating them....

Thanks!

Best regards,

---

From: Florian Weimer <[email-masked]>
Date: Fri, 23 Dec 2011 10:46:46 +0000

* Fernando Gont:

> They have been seen in the wild.

Yuck.

> That aside, I don't know whether e.g. NAT64 or the like used this
> (.e.g, whether they are used for transition technologies as envisioned
> in RFC 2460). However, it might also be the case that such "atomic
> fragments" are generated when communicating through networks that do
> not really have a MTU >= 1280. In such scenarios there might be some
> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU
> smaller than 1280, thus resulting in atomic fragments (such that it's
> easier for the "gateway" to fragment the IPv6 packets).

Yes, this seems a plausible explanation.  I wouldn't consider this
actual use, rather network misconfiguration.  In my opinion, we need
more evidence that these fragments actually serve a useful purpose.

> another use case for these atomic fragments.

Not really.  It's a workaround so that stateless IPv6 services are
possible, despite this protocol weiredness.

>> Per previous WG discussion, when reassembling such atomic fragments,

I think I meant to write "any fragments".

> anything special with the high order bits.

Actually, atomic fragments aren't the problem, but the technology that
serves as a justification for them.  If there are sub-1280 links which
require network fragmentation and which fail to preserve the entire
fragment ID, this happen to a packet which has already been fragmented
by the sending host: One fragment is delivered over a regular IPv6 link
and not fragmented further.  Another fragment is sent over a different
link involving some v4 transition technology, causing further
fragmentation and loss of the upper 16 bit of the fragment id.  The
receiving node can reassemble the original packet only if it disregards
the upper 16 bits in all those fragments.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Dec 2011 02:34:51 -0300

Hi, Florian,

On 12/23/2011 07:46 AM, Florian Weimer wrote:
> actual use, rather network misconfiguration.  

Why?

> In my opinion, we need

Not sure what you mean.

> the upper 16 bits in all those fragments.

Sorry, I cannot see why some packets would require going through a
translator, while others wouldn't. That is, if the intended destination
is really a v4 node, all packets meant to it will go through a
translator, If it's not, none will.

Am I missing something?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Dec 2011 09:06:30 +1300

>> actual use, rather network misconfiguration.  

MTU <1280 is a complete breach of the IPv6 standard, so it is by
definition a misconfiguration.

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.  On any link that cannot convey a 1280-octet
   packet in one piece, link-specific fragmentation and reassembly must
   be provided at a layer below IPv6. [RFC 2460, sectioin 5].

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Dec 2011 23:14:24 -0300

Hi, Brian,

> definition a misconfiguration.

Well, as long as communication does work without requiring the sending
node to fragment packets to < 1280, the standard is not being "broken".

In the scenario I was describing, the underlying reason for receiving an
ICMPv6 PTB <1280 might be a network that doesn't support an MTU >= 1280
(and hence, that violates the standard). However, that's irrelevant as
long as the sending host is not required to fragment to <1280 for
communication to work.

That aside, from my perspecitive std violation != misconfiguration. A
misconfiguration is probably the result of an error (probably on the
side of the administrator), while an std violation such as the one that
we're possibly talking about is most likely the result of a deliverate
action (which is probably not going to be fixed even if it's reported).

Thanks,