Subject: Re: Fragmentation-related security issues

From: RJ Atkinson <[email-masked]>
Date: Tue, 20 Dec 2011 12:07:24 -0500

Earlier, Florian Weimer wrote, in part:
> Does such traffic actually occur in the wild, 
> or would it only be used in attacks?

It does occur in the wild in situations where
it is functionally required and is NOT any
kind of attack.

I think there are at least 2 circumstances for
this.  

I believe that scenario relates to DNS/UDP packets 
-- and one might want to read the recent I-Ds (plural)
from Mark Andrews for more details -- see this
email to the IPv6 list for example:

<http://www.ietf.org/mail-archive/web/ipv6/current/msg15078.html>

Another scenario relates to several kinds of
RF/wireless links that only support smaller
link MTUs and are relatively low bandwidth.

Other legitimate deployment scenarios for these
IPv6 packets are likely to exist.

Also, Steinar Haug wrote, in part:
> 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.

Multiple shipping OSs understand the legitimacy
of IPv6 packets with a Fragment Header without
multiple fragments.  So FreeBSD-current is not 
alone in handling these correctly.

MORE GENERALLY:

We need to AVOID falling into the trap that things 
not explicitly allowed are always security 
vulnerabilities and lack legitimate reasons to exist.  
IPv6 is not "done" -- any useful deployed protocol 
will evolve over time.

So it is not helpful to publish documents that 
advise firewall/middlebox/router vendors to filter out 
"unknown" behaviour or "curious" packet patterns or 
unrecognised options.  

For example, if a firewall doesn't recognise
(e.g. due to lack of firewall firmware update) 
some new IPv6 option (e.g. carried in an IPv6 
Destination Header), the firewall ought NOT
filter/drop packets with that new/unrecognised 
option.

Over time, probably slowly, new IPv6 options
(i.e. inside existing IPv6 headers) will be 
defined that have legitimate (often new) uses.  

We do NOT want to close the door on IPv6 (or IPv4 
or TCP or UDP or ...) evolution.  Proscriptive and
paranoid recommendations to implementers WILL and
DO close the door on evolution -- and hence can be
harmful to the Internet.

Yours,

Ran

PS:  Many people here are already on holiday, or will 
     begin their holiday soon.  So I hope we will avoid 
     drawing any conclusions prior to early January 2012.  
     I'll be very substantially offline starting in 
     a few hours, until early January, for example.

---

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

Hi, Ran,

> IPv6 is not "done" -- any useful deployed protocol 

FWIW, draft-gont-6man-ipv6-atomic-fragments avoid the security
implications while still allowing the use of the aforementioned packets.
Actually, one might even argue that trying to "reassemble" an atomic
packet with any other fragment is rather non-sensical...

> filter/drop packets with that new/unrecognised 

While I understand your concern, from the firewall perspective things
generally are "whatever I have not explicitly allowed, is blocked".

There are understandable arguments both ways. From a networking point of
view, the aforementioned behaviour hurts protocol evolution and
extensibility. From a security point of view, you only allow what you
really need (i.e. "need to pass" basis ;-) ).

> DO close the door on evolution -- and hence can be

Just to clarify on this point, I don't think any of these 6man I-Ds I've
published last week fall into this category. In particular, the
fragmentation-related ones aim at mitigating security implications
without any impact on protocol evolution.

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