Subject: Re: Fragmentation-related security issues

From: Vishwas Manral <[email-masked]>
Date: Sun, 1 Jan 2012 15:21:46 -0800

Hi Fernando,

I did qyuite some work on "Tiny Fragments" for IPv6 a while back. We seem
to be having the same set of discussions over again.
http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-03

The draft seemed to have been well received, but never got back to taking
it to completetion. Let me know what you think of the work.

Thanks,
Vishwas
On Sun, Dec 25, 2011 at 6:14 PM, Fernando Gont <[email-masked]> wrote:

> Hi, Brian,
>
> On 12/24/2011 05:06 PM, Brian E Carpenter wrote:
> >>>> 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.
> >>
> >> Why?
> >
> > MTU <1280 is a complete breach of the IPv6 standard, so it is by
> > 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,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 2 Jan 2012 22:10:55 +0000

On 20. Dec 2011, at 11:44 , [email-masked] wrote:

Hey,

I guess I should follow-up on this one.

>>>   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".
>> 
>> Does such traffic actually occur in the wild, or would it only be used
>> in attacks?
> 
> 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.

and I know of a couple of more people who have seen it and have ways to
trigger it with legitimate servers.  I have never tracked things down
in more detail at some point back.

> Dec 16 14:04:04 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.

And given I am responsible for both committing the original "block" and
the relaxed version let me elaborate a bit on this:

Contrary to how a lot of people seem to read RFC 2460, especially the last
paragraph of section 5 (also subject to Florian's Errata 2843), I basically
read (in) the past:

4.5 "The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination."  

``You shall not add a fragment header unless you really need to''.

The only way you must add a fragment header for a packet size below 1280 is
when it is a packet going to a v4 destination (i.e. say through NAT64 these
days).  How you can track this (if you can) and how you get that information
is beyond the scope of 2460 but you need to know to be able to.  Otherwise
you shall not.

This is the reason ipfw originally dropped what people now seem to call
"atomic fragments".

When I PR started to look at the PR I consulted briefly with Bob and the
outcome of the short exchange for me was:

- the "atomic frags" do not seem to hurt in this particular filtering case
  and could possibly be allowed.
- I prepared an errata text suggesting that the text in 4.5 was clarified
  allowing "atomic frags" but discouraging their usage, especially given
  aforementioned errata threatens to remove the paragraph from section 5,
  which is the only real reason people seem to think they are valid.

While I still feel that these "atomic frags" should be sent to the packet
shredder on first sight it seemed to match reality (and especially
operational impact) better.  However I left a sysctl for individuals to
control their preference.

Another thing on the "atomic frags" I was (partly) shown was that they seemed
to have a length in the 50 octets size which would even be way below other
minimums.  So I am really not feeling too confident that it's not just silly
stacks or software bugs and it would really be thrilling if people could figure
out OS and version and reason why some systems send them.

On the entire "fragmentation related security issues" topic, I feel we are
seriously heading into wrong directions to just more complications rather than
simplifications.

The idea of having the fragment offset to stay compatible the way things worked
in IPv4 certainly was a great idea and has later proven to be a PITA.  What I'd
really like to have is a silly fragment counter 1..n, so no overlapping possible
(and not just not allowed on paper anymore as that does not remove that code
to check from the stacks), simple handling of duplicate fragments, and no
"atomic frags" allowed.
Luckily the fragment header still has a lot of spare space that could allow
to indicate which scheme is used and dropping a packet unless a bit is set
(not being set indicating the old scheme) is really easy to implement, esp.
after a transition period and ripping the old code out would be as well then;-)
I 'd really not want to add even more complicated house keeping and stuff
long term.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!

---

From: [email-masked]
Date: Mon, 02 Jan 2012 23:16:16 +0100 (CET)

> in more detail at some point back.

If anybody would like to track down this, I can supply pcap data.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 2 Jan 2012 22:48:55 +0000

> If anybody would like to track down this, I can supply pcap data.

You'd need to go to the origins most likely and get into touch with them,
ask them, work with them to identify things and see if you can find a
common denominator...

It might really be worth doing so; in case we are hunting misconfigurations
or bugs here and discussing the merits on how to handle other than drop;-)

/bz

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jan 2012 15:02:38 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: Sunday, December 25, 2011 6:14 PM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: Fragmentation-related security issues
> 
> Hi, Brian,
> 
> (and hence, that violates the standard). 

It is not a violation to send PTB of less then 1280.  Never has been,
even going back to RFC1883 when the IPv6 minimum MTU was 576, 
http://tools.ietf.org/html/rfc1883#section-5 says:

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 576.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   576, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 528 octets (576 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

        Note: Path MTU Discovery must be performed even in cases where a
        host "thinks" a destination is attached to the same link as
        itself.

and the current IPv6 specification also allows PTB < 1280,
http://tools.ietf.org/html/rfc2460#section-5 says:

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

> However, that's irrelevant as

-d

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jan 2012 15:09:32 -0800

> Bjoern A. Zeeb
> Sent: Monday, January 02, 2012 2:11 PM
> To: [email-masked]
> Cc: [email-masked]
> paragraph of section 5 (also subject to Florian's Errata 2843),

Errata 2843, http://www.rfc-editor.org/errata_search.php?eid=2843, 
will break stateless IPv6/IPv4 translation, which was originally defined
in RFC2765 and superseded by RFC6145 (published April 2011).

> I basically read (in) the past:
> 
> in IPv4 certainly was a great idea and has later proven to be a PITA.

Agreed, it's a PITA.  Fragmentation is a PITA, though, not just this
one aspect of it.

> What I'd

We're sortof in the middle of the IPv6/IPv4 transition now, though..

-d

---

From: Fernando Gont <[email-masked]>
Date: Mon, 02 Jan 2012 20:23:23 -0300

> http://tools.ietf.org/html/rfc1883#section-5 says:

The violation would be that of not support an MTU >= 1280, rather than
the sending of the ICMPv6 PTB.

>    additional extension headers are used.

Exactly. And my question was about whether the "atomic fragments" that
were found in the wild were the result of translators, or of IPv6
networks that "violate" the standard and do not support an MTU of >= 1280.

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 02 Jan 2012 20:26:53 -0300

> If anybody would like to track down this, I can supply pcap data.

I'd be interested. Please tar, gz and send to [email-masked] (or
provide an URL).

Thanks,

---

From: Florian Weimer <[email-masked]>
Date: Tue, 03 Jan 2012 08:42:02 +0000

* Fernando Gont:

> Hi, Florian,
>
> On 12/23/2011 07:46 AM, Florian Weimer wrote:

What Brian said---IPv6 is supposed to have a lower bound on the MTU.
I just don't think it's a good idea to through that out of the window
because there are genuine advantages.

>> In my opinion, we need
>> more evidence that these fragments actually serve a useful purpose.
>> 
>>> That aside, there's the proposal by Mark Andrews which would add yet
>>> another use case for these atomic fragments.
>> 
>> Not really.  It's a workaround so that stateless IPv6 services are
>> possible, despite this protocol weiredness.
>
> Not sure what you mean.

Without the API change in draft-andrews-6man-force-fragmentation, it is
flat out impossible to server IPv6 traffic in a stateless fashion.  The
stack is required to keep a per-destination cache which records the
necessity of a fragment extension header, even if the application never
sends any packets larger than 1280 bytes.

> Sorry, I cannot see why some packets would require going through a
> translator, while others wouldn't.

The joy of packet switching. 8-)

> 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.

If the target is a v4 node, surely the network can just fragment as
needed, and reassemble using the v4 fragmentation information?  That's
why I assumed the actual use case has to be more complicated (such as
translation back to v6).

I'm attempting a reductio ad absurdum here---trying to show that for all
potential use cases of atomic fragments, there are much simpler
alternatives, and the remaining ones are utterly bizarre and not worth
supporting.

-- 
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, 03 Jan 2012 10:55:26 +0100 (CET)

> ask them, work with them to identify things and see if you can find a

Pcap files have now been supplied to two persons who expressed interest
in following up on this.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Jan 2012 09:09:00 -0800

Hi Brian, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Saturday, December 24, 2011 12:07 PM
> To: Fernando Gont
> Cc: [email-masked]
> On 2011-12-24 18:34, Fernando Gont wrote:
> > Hi, Florian,
> > 

Some tunnels may not be able to provide a 1280 MTU as-seen
by the inner packet, since the outer encapsulating headers
may cause the packet to exceed the path MTU. Especially for
nested encapsulations, a tunnel ingress may be required to
use IPv6 fragmentation in order to convey 1280 and smaller
packets to the tunnel egress. This is effectively a "link-
specific fragmentation and reassembly ... at a layer below
IPv6." IPv6 tunnel fragmentation and reassembly is explained
in RFC2473, and also in draft-templin-intarea-seal:

http://tools.ietf.org/html/draft-templin-intarea-seal-42

SEAL in particular solves the tunnel path MTU problem for
both IPv4 and IPv6 as the outer encapsulation layer.

>    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].

You stopped short quoting the final paragraph of Section 5:

   "In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280."

Thanks - Fred
[email-masked]

>      Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Jan 2012 09:33:15 -0800

Hi Fernando, 

> Behalf Of Fernando Gont
> Sent: Thursday, December 15, 2011 6:25 AM
> To: [email-masked]
> Subject: Fragmentation-related security issues
> 
> 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 ----

IPsec AH/ESP provide a monotonically-incrementing
per-packet sequence number. However, each packet also
includes a digital signature that is used to reject
spoofed packets. The same is also true of SEAL:

The IPv6 Identification value could similarly be run in
a monotonically-incrementing fashion also if each packet
includes a digital signature. So, outer IPv6 fragmentation
when IPsec or SEAL encapsulation is used should have no
problems with a monotonically-incrementing Identification.

Thanks - Fred

> 
> The second I-D is entitled 'Processing of IPv6 "atomic" fragments'
> (http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragment
> s-00.txt).
> Its abstract is:
> 
> ---- cut here ----
>    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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jan 2012 09:48:38 -0800

> Florian Weimer
> Sent: Tuesday, December 20, 2011 2:01 AM
> To: Fernando Gont
> Cc: [email-masked]
> > (http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments-
> 00.txt).
> > Its abstract is:
> >
> > ---- cut here ----
> 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). 

Stateless IPv6/IPv4 translators set the upper 16 bits to 0 when 
translating from IPv4 to IPv6; IPv6 hosts do not need to ignore 
the upper 16 bits of the Identification field.

http://tools.ietf.org/html/rfc6145#section-4.1, "Translating IPv4 
Headers into IPv6 Headers",

   ...
      Identification:  The low-order 16 bits copied from the
         Identification field in the IPv4 header.  The high-order 16
         bits set to zero.

-d

> Clearly, this is
> not desirable.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jan 2012 11:02:23 -0800

...
> networks that "violate" the standard and do not support an MTU of >=

Dunno.

I am only trying to point out that IPv6 hosts need to handle receiving
ICMP packet-too-big of less than 1280, because we are going to see 
more stateless IPv6/IPv4 translators.  If IPv6 hosts don't handle
ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators 
won't work with sub-1280 MTU IPv4 paths.

And Ran has pointed out other deployments where sub-1280 MTUs are
being used on IPv6.  (An aside comment:  I wonder if those networks 
can use LFI (link fragmentation and interleaving), which allows 
preserving the layer 3 MTU and should also provide the smaller
packets needed by the layer 1 or 2 network).

So, I don't think we can just wish away packet-too-big < 1280.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jan 2012 09:24:03 +1300

> So, I don't think we can just wish away packet-too-big < 1280.

Sadly, that seems to be true unless we make a much more radical change,
because of translators.

  Brian

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jan 2012 12:43:03 -0800

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2012 12:24 PM
> To: Dan Wing
> Cc: 'Fernando Gont'; 'Fernando Gont'; [email-masked]
> >>>    1280, but must include a Fragment header in those packets so
> that
> >> the

Or, we declare a new restriction that translators are not expected to 
work if the IPv4 network has an MTU less than 1260 (1260=1280-20, 
because IPv6 header is 20B bigger than IPv4 header).  I don't know if there 
is consensus for such a restriction.  To date, both RFC2765 and RFC6145 
avoided such a restriction.  However, if there are widespread IPv6 
host implementations or firewalls that erroneously filter or ignore 
ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to 
accept that restriction, and modify their IPv4 networks to have
MTU>=1260.  Such IPv4 network modifications would add to further 
pain to IPv6 coexistence.  MTU research by Ben Stasiewicz and 
Matthew Luckie (WAND), published and presented at RIPE and
other conferences, shows a 2-3% failure rate to various popular
web sites.  They did additional testing during World IPv6 Day,
but I haven't dug into those results yet.

-d

---

From: Jared Mauch <[email-masked]>
Date: Tue, 3 Jan 2012 15:53:48 -0500

> Sadly, that seems to be true unless we make a much more radical change,

Sometimes presenting broken networks and hosts a non-working solution is
the proper signaling mechanism to inform them they need to take corrective
action.

This is done by placing infected hosts in a walled-garden in some cases, or
perhaps here, if they can't handle anything lt 1280, they need to repair
or patch their host/stack.  At some point these legacy networks need to be
taken off life-support.

- Jared

---

From: Doug Barton <[email-masked]>
Date: Tue, 03 Jan 2012 12:59:39 -0800

On 01/03/2012 11:02, Dan Wing wrote:
> If IPv6 hosts don't handle

... and this is not a feature because? And no, don't quote the
robustness principle. The floor for MTU has been hard-coded since day 1,
so anyone who breaks that deserves what they get.

Doug

-- 

	You can observe a lot just by watching.	-- Yogi Berra

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Jared Mauch <[email-masked]>
Date: Tue, 3 Jan 2012 16:00:48 -0500

> so anyone who breaks that deserves what they get.
+1

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 3 Jan 2012 22:52:44 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing (dwing)
 
> So, I don't think we can just wish away packet-too-big < 1280.
 
Rather than dropping those ICMP PTB, let's accept them but let the OS decide which is the minimum size path MTU that it can accept/tolerate... 
 - For a server, this min path MTU should be large (to avoid DoS)
 - For a host, this min path MTU could be small

Of course, if the path is symmetric, the path MTU will be the same on both direction (assuming everything is well configured).

OTOH, as written by Jared, let's fail it hard so it is noticeable by the user is another technique... but with a dual-stack and happy eye-ball, the end-user will notice nothing and will stay happy with IPv4.

-éric

---

From: Doug Barton <[email-masked]>
Date: Tue, 03 Jan 2012 14:45:17 -0800

> Rather than dropping those ICMP PTB, let's accept them but let the OS decide which is the minimum size path MTU that it can accept/tolerate... 

As someone who works for a router company I can see why the "punt it to
the OS" option seems attractive. :)

As an OS person my response is that having a well-enforced minimum makes
code simpler. Simple is good.

Doug

--

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 02:04:02 -0300

Hi, Bjoern,

> ``You shall not add a fragment header unless you really need to''.

Well, it's supposedly (specs-wise) also used to help translating devices
in the fragmentation of packets...

> is beyond the scope of 2460 but you need to know to be able to.  Otherwise

That's not what the specs state. The specs say that if you receive an
ICMPv6 PTB advertising an MTU <= you need not fragment, but should
include a fragment header.

> This is the reason ipfw originally dropped what people now seem to call

Well, it's a useful short-hand for "packets that hace a fragment offset
of zero and for which the M bit is not set".. ;-)

>   and could possibly be allowed.

Atomic fragments could be safely processed as if they were not
fragmented traffic at all... see the I-D we published...

> control their preference.

ANy comments regarding processing them as non-fragmented traffic, as
noted in draft-gont-6man-ipv6-atomic-fragments ?

> out OS and version and reason why some systems send them.

Well I'm certainly am after that. However, the point is that we need not
over-engineer this one: these atomic fraggments could be safely
processed without running into the typical IP fragmentation issues...

> to check from the stacks), simple handling of duplicate fragments, and no

That makes a bunch of IP fragmentation attacks (mostly DoS) trivial...
-- we should have learnt the leason from IPv4, shouldn't we?

> I 'd really not want to add even more complicated house keeping and stuff

You're already in a complicated position as a result of predictable I-Ds

OpenBSD randomized them, OpenSolaris implemented the scheme that is
descrivbed in the I-D I published... what's the big deal about it?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 02:05:31 -0300

> or bugs here and discussing the merits on how to handle other than drop;-)

Why should you drop in this case, when it's trivial to process these
fragments safely, with no side effects??
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 3 Jan 2012 23:51:54 +0000

> fragments safely, with no side effects??

Because a fragment header that's not needed a) heats the planet, b-z) does
all the things what that means.  The more we can force that not to happen
the better we are off.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 17:52:26 -0300

Florian,

> because there are genuine advantages.

Again: the v6 core spec mentions a possible scenarion in which you might
legitimately receive CIMP PTBs that advertise an MTU smaller than 1280
bytes.

In that case, you're not required to split your packets into fragments
smaller or equal to 1280 bytes, but *are* required to react by including
a Fragment Header in subsequent packets.

> sends any packets larger than 1280 bytes.

The stack is required to have a Destination Cache, anyway.

> The joy of packet switching. 8-)

If a packet is actually destined to the IPv4 world (and hence needs to
go through a translator), it will need to cross one translator, or
another... but *some* translator.

> why I assumed the actual use case has to be more complicated (such as

Then you'd need the translator to be stateful, such that it can selecct
appropriate Identification values (i.e., not reuse them too quickly).

> alternatives, and the remaining ones are utterly bizarre and not worth

We're not designing for the future. We're *currently* using/seeing
atomic fragments. If you plan to ban them, that comes at the cost of
breaking stuff.

That aside, atomic fragments can be handled as safely as non-fragmented
traffic: *that* was the motivation of the publication of
draft-gont-6man-ipv6-atomic-fragments

Thanks,

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 4 Jan 2012 00:22:35 +0000

> -- we should have learnt the leason from IPv4, shouldn't we?

More than knowing all the fragment offsets upfront with the first packet
for almost all implementations?  Seriously?  Who implements packet size
randomizations for fragments to avoid that?

> OpenBSD randomized them,

Yeah and so do other BSDs derived from KAME...
( http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c#rev1.397 )

> OpenSolaris implemented the scheme that is

... but the above was not about the Identification field.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Jan 2012 11:55:09 +1100

In message <[email-masked]>, "Bjoern A
> all the things what that means.  The more we can force that not to happen

Atomic fragments > 1280 should not appear in the network.  Atomic fragments
<= 1280 are a expected part of the IPv6 landscape.  For TCP they should be
rare.  For UDP it depends on the protocol running on top of UDP.  PMTUD
relying on PTB is just not reliable.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jan 2012 17:22:39 -0800

> From: Doug Barton [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2012 1:00 PM
> To: Dan Wing
> Cc: 'Fernando Gont'; [email-masked]; 'Brian E Carpenter'
> robustness principle. The floor for MTU has been hard-coded since day
> 1, so anyone who breaks that deserves what they get.

Yes, I agree, the last paragraph of 
http://tools.ietf.org/html/rfc2460#section-5 has been around
a long time, and IPv6 hosts should follow it.

If there is consensus otherwise, we (the collective "we") need
to acknowledge what that breaks.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jan 2012 17:23:42 -0800

> From: Eric Vyncke (evyncke) [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2012 1:53 PM
> To: Dan Wing (dwing)
> Cc: [email-masked]
> Subject: RE: Fragmentation-related security issues
> 
> Rather than dropping those ICMP PTB, let's accept them but let the OS
> decide which is the minimum size path MTU that it can
> accept/tolerate...
> Of course, if the path is symmetric, the path MTU will be the same on
> both direction (assuming everything is well configured).
> 
> OTOH, as written by Jared, let's fail it hard so it is noticeable by
> the user is another technique... but with a dual-stack and happy eye-
> ball, the end-user will notice nothing and will stay happy with IPv4.

Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox,
and I think also as implemented by Apple, will _not_ fail nicely
on Path MTU Discovery problems.  It will only fail nicely if 
connectivity fails (that is, unable to establish the TCP 
connection).

-d

---

From: Jared Mauch <[email-masked]>
Date: Tue, 3 Jan 2012 21:15:10 -0500

Broken and misconfigured network elements will always exist. We needn't create solutions for everyone's problems that should be addressed otherwise. 

Jared Mauch

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jan 2012 21:27:05 -0800

> From: Jared Mauch [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2012 6:15 PM
> To: Dan Wing
> Cc: Eric Vyncke (evyncke); [email-masked]
> Broken and misconfigured network elements will always exist. We needn't
> create solutions for everyone's problems that should be addressed
> otherwise.

Ok.  So what of the IPv6/IPv4 translators which are placed in front
of existing, operational IPv4 networks.

-d

> Behalf
> >> Of Dan

---

From: Florian Weimer <[email-masked]>
Date: Wed, 04 Jan 2012 08:19:58 +0000

> fragments safely, with no side effects??

Do we really know that adding a fragment header to all outgoing packets
does not cause them to be rejected?  Could this be deployed at large DNS
servers in a risk-free fashion, for instance?

---

From: Jared Mauch <[email-masked]>
Date: Wed, 4 Jan 2012 07:23:03 -0500

> of existing, operational IPv4 networks.

If the translator can't talk at some larger MSS, it can reduce that,
one does this on cisco with 'ip tcp adjust-mss' on the interface for TCP.
I assume nobody forgot to create a comparable command for ipv6 :)

For UDP, there are silent drops/blackholes today.  Translation technologies
are a bandaid and expected to have tradeoffs.  This will be one of them
that may make going native more attractive. 

Expecting the ICMP messages that may be dropped already to be propagated and
translated properly isn't ideal, but this is something that doesn't need lots
of attention.

- Jared

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jan 2012 08:14:39 -0800

> From: Rémi Després [mailto:[email-masked]]
> Sent: Wednesday, January 04, 2012 1:44 AM
> To: Dan Wing
> Cc: 'Brian E Carpenter'; [email-masked]
> Hi Dan,
> As you rightly reminded, the current specification permits PTB<1280 for
> a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids it
> for an IPv6 DST.
> 
> Rather than changing this, what about clarifying that a host SHOULD
> treat a received PTB>1280 as:
> - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 of
> RFC6147)

That only helps in half of the RFC6144 scenarios, where the IPv6
host is behind the translator (e.g., "Scenario 1: an IPv6 network to the
IPv4 Internet").  It would not help in the other half of the RFC6144
scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4:
an IPv4 network to the IPv6 Internet").  It is RFC6144's Scenario 4
where stateless IPv6/IPv4 translators, where the IPv4 network has a
small MTU, that there is a reliance on the last paragraph of Section
5 of RFC2460.

-d

> - an ERROR otherwise.
> 
> This would at least dissuade from tolerating IPv6 paths with PMTU <
> 1280.
> 
> RD
> 
> 
> 
> Le 2012-01-03 à 21:43, Dan Wing a écrit :
> >> ...

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jan 2012 08:19:20 -0800

> Sent: Wednesday, January 04, 2012 4:23 AM
> To: Dan Wing
> Cc: 'Eric Vyncke (evyncke)'; [email-masked]

We can clamp TCP MSS on our various translator devices.

(Oh, Cisco did forget to create a comparable command for IPv6, helpful
for tunnels and what-not on IPv4 and IPv6 because ICMP is so often
borked or filtered.  That oversight is being fixed.)

> that may make going native more attractive.

Unfortunately a broken network is just that:  broken.  It does not
encourage users to move, just to demand a fix.

-d

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 23:41:19 -0300

Bjoern,

> randomizations for fragments to avoid that?

Sorry, it seems that the discussion got mixed up. Trying to clear up the
mess:

*I* am arguing in favor of:
a) Fragment ID randomization
b) Processing of atomic fragments as non-fragmented traffic.

Any arguments against that?

> ( http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c#rev1.397 )

But this wasn't the case for Linux (they've now patched, though) or
OpenSolaris (partially).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 23:43:37 -0300

> all the things what that means.  The more we can force that not to happen

Huh? If there was no way to avoid, problems, I'd agree. However, there
is (see my I-D on IPv6 atomic fragments). Regarding the usefulness/need
for atomic fragments, it had been described already by Ran Atkinson,
Mark Andrews, and others. You want to filter them out? -- You break
stuff. It's that simple.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Jan 2012 23:45:23 -0300

> to acknowledge what that breaks.

It would be pretty dumb to break stuff with no gains. -- Particularly
when there are lots of things to tighten up (which *do* have security
implications).

Thanks,

---

From: Doug Barton <[email-masked]>
Date: Wed, 04 Jan 2012 14:12:12 -0800

On 01/03/2012 18:45, Fernando Gont wrote:
> It would be pretty dumb to break stuff with no gains.

Completely aside from the intrinsic value of "People who follow the spec
get the benefits of interoperability; people who don't, don't."

Not having to deal with an MTU of less than the minimum for IPv6 keeps
code simple. Simple is good. IMO that's a pretty big gain, and an
enormous loss if everyone who's ever deployed IPv6 code has to go back
and reexamine that fundamental assumption.

Doug

--

---

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 14:35:14 -0300

On 01/04/2012 05:19 AM, Florian Weimer wrote:
> does not cause them to be rejected? 

Are you arguing that IPv6 fragmentation does no work at all, or what?

My take is that packets won't be rejected simply for having a Fragment
Header. They *will* probably be rejected if the initial fragment does
not contain all the relevant headers, though (IPv6+transport).

> Could this be deployed at large DNS

What's the specific question you're asking, and what is your concern,
specifically?

Thanks,

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 4 Jan 2012 16:37:23 -0600

Perhaps we should go back to what 576 bytes really was, in IPv4, and apply the same rules to IPv6.

576 bytes is NOT the smallest MTU allowable in an IPv4 path. It refers to the smallest packet that must be able to be de-fragmented, in IPv4. Why can't we apply a similar rule to IPv6?

>From RFC 791:

    Every internet module must be able to forward a datagram of 68
    octets without further fragmentation.  This is because an internet
    header may be up to 60 octets, and the minimum fragment is 8 octets.

    Every internet destination must be able to receive a datagram of 576
    octets either in one piece or in fragments to be reassembled.

The minimum MTU for IPv4 is 68 bytes. Similarly, in IPv6, PMTU *should* be allowed to be as small as 40 bytes + 8 bytes for the fragmentation header + any more required by other options, as determined by the source host.

I know RFC 2460 doesn't read this way, but I believe this issue could be resolved by going back to what RFC 791 really said.

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Wednesday, January 04, 2012 11:15 AM
To: 'Rémi Després'
Cc: [email-masked]; 'Brian E Carpenter'
Subject: RE: Fragmentation-related security issues

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Jan 2012 18:45:30 -0800

> Sent: Wednesday, January 04, 2012 9:47 AM
> To: Dan Wing
> Le 2012-01-04 à 17:14, Dan Wing a écrit :
> 
> You are right, refusing PTB<12810 if IPv6 DST was not recognized as
> IPv4-embedded would break scenarios 3 and 4.
> Will these scenarios be as typical as those where an IPv6-only host
> reaches an IPv4-only server is unclear, and even IMHO doubtful.
> Yet, I agree they must be considered.
> 
> - One approach would be to REQUIRE that IPv4 networks having IPv6-only
> access to the Internet have MTU >= 1240 (requiring this ONLY for these
> networks shouldn't be a big deal).

Yep.

That seems a reasonable statement for an "operational consideration" 
document to make.  It might be reasonable for a NAT64 "operational 
considerations" document in either BEHAVE or V6OPS.  
Draft-chen-v6ops-nat64-cpe could be that document; although, as I 
stated at the microphone in IETF82, draft-chen-v6ops-nat64-cpe needs 
to more clearly separate itself into the various scenarios for 
a NAT64 device (that is, if the IPv6 network is "the Internet" 
(not operated by any one entity) or if the IPv6 network is 
"a network" (operated by the same entity operating the NAT64).
That is the same difference between RFC6144's Scenario 1 and 4.)

CC'ing authors of draft-chen-v6ops-nat64-cpe.

> - Another, non exclusive, would be that IPv4-embedded addresses of such
> networks would be REQUIRED to have a specific format. (A V octet a la
> 4rd-U, instead of the u octet of RFC6052, could for instance do the
> job).

RFC6052 didn't define the "u" octet; rather, RFC6052 is merely 
preserving the "u" bit's meaning as originally defined in RFC4291.

-d

> >>> because IPv6 header is 20B bigger than IPv4 header).  I don't know
> if
> >> there

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Jan 2012 09:32:50 +0000

> b) Processing of atomic fragments as non-fragmented traffic.

Is this even possible?  The presence of an additional extension header
necessarily triggers additional packet processing, doesn't it?

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Jan 2012 09:40:59 +0000

> 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.

>> Could this be deployed at large DNS servers in a risk-free fashion,
>> for instance?
>

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".)

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.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Jan 2012 10:10:02 +0000

* Albert E. Manfredi:

> The minimum MTU for IPv4 is 68 bytes. Similarly, in IPv6, PMTU
> *should* be allowed to be as small as 40 bytes + 8 bytes for the
> fragmentation header + any more required by other options, as
> determined by the source host.

RFC 791 does indeed say that, but some of us have been working on
pushing the IPv4 MTU to some saner value, above 500-something bytes.
Many implementations follow that now.

> I know RFC 2460 doesn't read this way, but I believe this issue could
> be resolved by going back to what RFC 791 really said.

Supporting small fragments has high hidden costs.  Some of them are
addressed by the larger fragment ID in IPv6, but not all of them.  There
is still no way to authenticate an incoming ICMPv6 PTB message, so you
have to be very conservative when processing them.  Fragmenting down to
48 bytes is certainly not a good idea (and the current specs don't
permit that, anyway).

---

From: [email-masked]
Date: Thu, 05 Jan 2012 11:26:31 +0100 (CET)

> (I think we have to assume the answer is "yes".)

The answer is clearly yes, since (for instance) FreeBSD 7.4 with
ipfw will drop such packets.

---

From: [email-masked]
Date: Thu, 05 Jan 2012 11:32:28 +0100 (CET)

> ipfw will drop such packets.

Atomic fragments, that is.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 05 Jan 2012 10:45:06 +0000

> a Fragment Header in subsequent packets.

And the only way to achieve that reliably in certain existing
deployments appears to be to send a fragment header unconditionally.
(And with increasing IPv6 adoption, this will be only option for every
large DNS operator---right now, PMTUD in the IPv6 stack appears to work
because the number of clients is small compared to the size of the
destination cache in the servers.)

Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might
be others, of course).  Not sending them breaks important transition
technology.

> The stack is required to have a Destination Cache, anyway.

Could you elaborate on that?  For some operators, the ability to serve
stateless protocols statelessly over IPv6 is quite important.  I'm not
aware of any fundamental requirement for per-destination bookkeeping in
IPv6 nodes.

> another... but *some* translator.

Couldn't it be translated back to IPv6?  Then there could be an
IPv6-only path between sender and recipient.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 5 Jan 2012 11:25:38 +0000

> necessarily triggers additional packet processing, doesn't it?

What he means is remove the fragment header in this case without any other
fragment code processing and continue handling the packet as if you'd have
received it without the ext hdr.

That this is still an expensive operation for a silly packet does not seem to
trickle down so avoiding these cases whenever possible should be the rule.

/bz

---

From: Tina TSOU <[email-masked]>
Date: Thu, 05 Jan 2012 17:58:33 +0000

Sent from my iPad

> IPv6-only path between sender and recipient.
I'm deploying it. It's hard to find.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 17:21:05 -0300

Florian,

> 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...

> (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.

> 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,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 18:21:47 -0300

> necessarily triggers additional packet processing, doesn't it?

Well, in your Fragment Header processing routine, the first thing you
should do is check whether the Fragment Offset is 0 *and* the M bit is
also 0. If that's the case, remove the Fragment Header, fix the Payload
Length, and that's it "the fragment has been reassembled".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 19:16:35 -0300

> is still no way to authenticate an incoming ICMPv6 PTB message, so you

RFC 5927 is your friend. Check for "progress" on the corresponding
connections on which you've received the packet.

For UDP, forget it. Actually, the idea of using state (as the PMTU
information) with a state-less protocol (such as UDP) should (by itself)
raise concerns.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 19:54:45 -0300

> be others, of course).  Not sending them breaks important transition

Looks like FreeBSD should patch. :-)

> aware of any fundamental requirement for per-destination bookkeeping in

The Destinations Cache is described in the IPv6 specs themselves
(RFC4861?), and is not a requirement of PMTUD.

Typically, if you maintain PMTUD information, you already have a PMTUD
cache in place, and you'd sort of had to patch the kernel if you wanted
to eliminate that.

> IPv6-only path between sender and recipient.

Huh? If any packet of that communication instances crossed a translator
is because it was an IPv6 packet destined to an IPv4 node (i.e., the
packets is ultimately destined to an IPv4 address). That will remain
true for the life of that communication instance.

So if one packet needed a translator, so will the others.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 19:45:02 -0300

> trickle down so avoiding these cases whenever possible should be the rule.

Huh? What's your threat model?

If you're concerned about being subject of... what? CPU-consumption
attacks? -- guess what: an attacker would send you non-atomic fragments,
just that you not only have to remove fragment headers, but also need to
glue all the fragments together.

Do you really think of atomic fragments as an attack vector? --
Attackers are much more clever than that...

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jan 2012 13:06:54 +1100

> 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.

---

From: Doug Barton <[email-masked]>
Date: Fri, 06 Jan 2012 01:08:55 -0800

> Looks like FreeBSD should patch. :-)

FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released
almost a year ago. It's scheduled to EOL in a little more than a year.

It would be much more interesting to know if the bug is still present in
the stable/8 branch (which will see at least one more release) or more
importantly, in the about-to-be-released 9.0.

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jan 2012 20:25:57 +1100

> the stable/8 branch (which will see at least one more release) or more

The bug is still in 8 stable:
http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log

> importantly, in the about-to-be-released 9.0.

It's fixed in 9 stable.

---

From: [email-masked]
Date: Fri, 06 Jan 2012 10:54:56 +0100 (CET)

> > importantly, in the about-to-be-released 9.0.

Agreed. I said it was fixed in 8.2-STABLE, I was wrong. The FreeBSD
bug id is kern/145733, see r1.63 in

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ipfw/ip_fw2.c

I have patched my 8.2-STABLE with this patch, and it works well.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Jan 2012 00:14:35 -0300

On 01/05/2012 11:06 PM, Mark Andrews wrote:
> I'm more about making DNS work reliably.  

Yes, sorry. The point I tried to make was that none of my I-Ds on
fragmentation argued in favour of an increased use of fragmentation.

That said, at least to the extent that I have studied your proposal, I
agree with it (support it).

Thanks,

---

From: Doug Barton <[email-masked]>
Date: Fri, 06 Jan 2012 14:22:13 -0800

> I have patched my 8.2-STABLE with this patch, and it works well.

Well that's good news. :)

Bjoern owns that PR, perhaps he can comment on his plans for merging the
fix to stable/8.

Doug

--

---

From: "ChenGang" <[email-masked]>
Date: Mon, 9 Jan 2012 11:03:28 +0800

Hello Dan and Remi,

Thanks for providing this information to us.
I have a glance on the discussion.
As an author of draft-chen-v6ops-nat64-cpe, I think it's valuable to state
that as one of NAT64 experiences.
I will bring my comments to the list after my second reading.
Many thanks

Gang

-----Original Message-----
From: Rémi Després [mailto:[email-masked]] 
Sent: Thursday, January 05, 2012 5:09 PM
To: Dan Wing
Cc: 'Brian E Carpenter'; [email-masked];
[email-masked]
Subject: Re: Fragmentation-related security issues

> That is the same difference between RFC6144's Scenario 1 and 4.)

Agreed.

> CC'ing authors of draft-chen-v6ops-nat64-cpe.

Good idea.

> preserving the "u" bit's meaning as originally defined in RFC4291.

Well, RFC6052 does include in sec. 2.3 '... insert the null octet "u"...'
and '... remove the "u" octet...'.
I agree that, in view of the privacy option that pre-existed, this didn't
add a new value of this octet (the point you make if I get it right).

Yet, RFC6052 did introduce an interpretation of the u bit that, from a
puristic point of view, would conflict with that of RFC4291: 
- RFC4291 says: "the "u" bit is set to one (1) to indicate universal scope,
and it is set to zero (0) to indicate local scope". 
- In RFC6052, 64:ff9b::X.X.X.X means IPv4 address X.X.X.X whose scope is
universal despite its u=0.
In my understanding, another RFC that would introduce a V octet using the
u=v=1 escape combination wouldn't conflict with RFC4291 more than RFC4291
does, i.e. acceptably little.

RD

---

From: Florian Weimer <[email-masked]>
Date: Fri, 27 Jan 2012 10:27:06 +0000

* Florian Weimer:

> Actually, atomic fragments aren't the problem, but the technology that
> serves as a justification for them. [...]

This argument turns out to be entirely wrong.  Sorry about that.

I'm still extremely bothered by atomic fragments.  Their use case seems
to be something like this:

  (1) A router receives a sufficiently large IPv6 packet for a
      destination which lies behind a link with a sub-1280 MTU.

  (2) The router sees that the packet lacks a Fragment extension header.
      It sends a Packet Too Big ICMP message to the source address and
      discards the original packet.

  (3) The source retransmits the packet, this time with an extension
      header describing it as an atomic fragment.

  (4) It arrives at the router of step (1).  The device now fragments
      the atomic fragment packet into actual fragmented packets, and
      forwards it over the sub-1280 link.

This is contrary to the IPv6 design because the network is not supposed
to fragment.  But it has to, due to the sub-1280 link, or there wouldn't
be any IPv6 connectivity at all.  Once you accept this deviation from
the IPv6 specification, why can't the router jump from step (1) to step
(4), after synthesizing a Fragment extension header locally?  It's not
that the header contains valuable application data or something like
that.

It seems to me that this results in superior interoperability: it works
with nodes which do not support atomic fragments gracefully, and it
doesn't require updates to significant parts of the network, to generate
atomic fragments more reliably *and* to deal with the resulting increase
in atomic fragments.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Jan 2012 12:13:07 +0100

In your letter dated Fri, 27 Jan 2012 10:27:06 +0000 you wrote:
>to fragment.  

The original use case was slightly different. It was about IPv6/IPv4
translators. The translator tries to forward an IPv6 packet or fragment over
IPv4 where it requires fragmentation. Now we need a unique identifier for
the IPv4 packet. Solution: require the host to insert a fragment header which
contains a unique id.

Given the current trends, just a random number would be good enough. But the
old RFCs assumed that a sequence number was used to maintain uniqueness.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 27 Jan 2012 11:36:26 +0000

> the IPv4 packet. Solution: require the host to insert a fragment header which

And I see no functional difference between the gateway and the host
generating the fragment ID, except that the latter approach seems to
require network-wide software updates currently.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jan 2012 09:01:46 -0300

> require network-wide software updates currently.

Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by
inserting a Fragment Header in subsequent packets, or what? (last time I
checked, I think this was the case)

As noted by Dan Wing, there's stuff that would break.

In any, please note the difference between *accepting* atomic fragments,
generating ICMPv6 PTB when the MTU of the constricting link is < 1280,
and reacting to ICMPv6 PTB by generating atomic fragments.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 27 Jan 2012 12:14:29 +0000

> checked, I think this was the case)

There are existing deployments which effectively filter ICMPv6 traffic.
Some of them do so explicitly, others simply to do not broadcast
incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to
make this work with behind a per-packet load balancer).  Naked host
behavior does not matter in such scenarios.

As soon as IPv6 traffic levels increase, all busy UDP sources will stop
generating atomic fragments reliably because at the time of retry, the
fact that an atomic fragment is required has expired from the
destination cache (if there is one in the first place, that is).
That's why Mark proposes to send atomic fragments unconditionally
and *that* is known to break stuff for sure.

> and reacting to ICMPv6 PTB by generating atomic fragments.

True, but why would it be important to accept atomic fragments, when the
system as a whole does not actually generate them properly?

I'm worried that we're imposing updates on significant parts of the
network to address an issue that could also be fixed locally,
maintaining full interoperability with the rest of the network as it
exists now.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Jan 2012 13:23:14 +0100

>and reacting to ICMPv6 PTB by generating atomic fragments.

My strong preference would be to kill this whole atomic fragment stuff before
it goes any further.

The sole purpose of atomic fragments seems to be to be able to copy a random
number generated by the host instead of generating one locally in a
gateway/translator. (I assume that any server, certainly bigger DNS servers,
will have trouble maintaining destination cache entries long enough to ensure
that there will be no collissions. Thus reducing id generation to just random)

---

From: Florian Weimer <[email-masked]>
Date: Fri, 27 Jan 2012 13:06:44 +0000

> My strong preference would be to kill this whole atomic fragment stuff before

In case this isn't obvious, this is my feeling as well.

I'm still looking for a justification for the complexity of preserving
this protocol aspect, but I doubt there is one.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jan 2012 13:07:38 -0300

Florian,

> There are existing deployments which effectively filter ICMPv6 traffic.

They should know better.. what can I say?

> behavior does not matter in such scenarios.

How does this make a special case for atomic fragments? If they do this,
they also break PMTUD -- not just the generation of atomic fragments.

> and *that* is known to break stuff for sure.

Regarding Mark's proposal, yes, some stacks need to patch their bugs
(this was required by RFC 2460, not by a brand new RFC).

> system as a whole does not actually generate them properly?

So that you have only one bug instead of two?

No kidding, as noted a a while ago, you can process atomic fragments as
securely as non-fragmented traffic. So I don't understand why you're
making a big deal. -- This is the sort of thing that, since you can do
the right thing easily with no security implications, you simply do it.

> maintaining full interoperability with the rest of the network as it

Not sure what you mean by "fixes locally". (That said, the cat is out of
the bag, already -- there's stuff that depends on this).

That said, I wouldn't call this an "update". I'd call this a bug fix...
and you fix many of these, so... what's the big deal?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jan 2012 13:19:24 -0300

> old RFCs assumed that a sequence number was used to maintain uniqueness.

May I ask what the "current trends" are? And no, just a random number is
not good enough, particularly if you're talking about the IPv4 IP ID.
(talk about collisions).

(For IPv6, I suggest that you talk with davem@, which noted that we
would not even want such a scheme for the IPv6 (i.e., 32-bit long)
fragment ID).

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Jan 2012 18:36:26 +0100

>would not even want such a scheme for the IPv6 (i.e., 32-bit long)

For avoiding collissions, a single global counter is optimal. To avoid traffic
analysis, a counter per destination is proposed. But how do you initialize
that counter? From a random number. 

So any system that is too busy to keep destination cache entries for a long
time will effectively send fragments with a random number.

Now for IPv4, to get a reasonable chance of a collision, you have to have 
256 fragmented packets in flight at the same time between a source/destination
pair (ignoring protocol for the moment). Then you also need those packets to
either suffer the loss of a fragment (all at the same time) or you need
sufficient reordering that 256 packets somehow overlap during fragmentation.
And when that happens, the normal TCP/UDP checksum is likely to throw out
all but one in 65535 packets. And anythingh encrypted will just see a loss of a 
connection.

To improve on that, an IPv6 fragment header has to have a counter in the lower
16 bits (the part that gets copied to the IPv4 header).

That means that if the sender deletes to destination cache entry before all
unassembled packets have been deleted or in flight packet have arrive, you are
back in trouble.

And that also assumes that the IPv4/IPv6 translator will never map two IPv6
source addresses to one IPv4 source address, because then the whole thing 
also falls over.

So, as far as I can tell, the risk that something goes wrong if you don't send
the fragment header is something very close to zero. The chance that sending
the fragment header is actually beneficial is also very small.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jan 2012 16:18:28 -0300

Hi, Philip,

> time will effectively send fragments with a random number.

There are always tradeoffs in the IP-ID generation algorithms. If you
don't like any of the forementioned approaches, you may have a set of
counters (say, 1024, 2048, or 65K, if you will), using an approach
similar to that of algorithm 2 in my flowlabel I-D.

Note, however, that if you cannot maintain a destinations cache, you may
also have issues with PMTUD, etc.

I'd argue that the scenario that you're describing, while not uncommon,
probably does not apply for the general case. So it would not be unfair
to have, at least for those scenarios, some specialized policy such as
the one described above.

> pair (ignoring protocol for the moment).

You need to have sufficient packet loss. at which point, the IP ID gets
trashed.

> Then you also need those packets to

Not sure what you mean. As long as one packet gets lost, the IP ID space
will get trashed. If another packet reuses the same ID, then it's very
likely that the reassembly process will fail, and it may be even
possible that some of the legitimate fragments remain in the fragment
reassembly buffer, trashing the IP ID space.

> unassembled packets have been deleted or in flight packet have arrive, you are

Well, yes, there's no such a thing as a "free lunch".

> the fragment header is actually beneficial is also very small.

So... you're essentially relying on guesswork because:

a) You consider that requiring the translator to send an ICMPv6 PTB is
way too much, (which is already a requirement for PMTUD), and,

b) You consider that processing atomic fragments as described in
draft-gont-6man-ipv6-atomic-fragment is... what?

I'd rather patch what needs to be patched (see OpenBSD's patch for the
atomic-fragments thing), and be done with it, rather than relying on
guesswork/assumptions.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Jan 2012 22:08:12 +0100

>similar to that of algorithm 2 in my flowlabel I-D.

I'm not really keeping track of flowlabel stuff. Do you have a more specific
reference? draft-gont-6man-flowlabel-security-02 doesn't seem to have an
algorithm 2. And I couldn't find any other flowlabel draft with your name on 
it.

>to have, at least for those scenarios, some specialized policy such as

PMTUD is just a mess.

For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on
pmtud gives a bad user experience.

For IPv6, the situation is not any better. But there is new option, servers
may simply set their mtu to 1280 and no more pmtu problems.

PMTU blackhole detection is surprisingly uncommon. IPv6 also lacks NAT, so
either CPEs will have to do mss clamping on the fly or lots of servers will end
up with just setting the mtu to 1280.

>reassembly buffer, trashing the IP ID space.

With random IDs, every packet that arrives has a 1/65536 chance of colliding
with a packet that is awaiting reassembly. Total chance depends on the
reassembly timeout and the packets rate.

Needless to say this only applies to IPv4 hosts that are behind a link smaller
than 1280.

>way too much, (which is already a requirement for PMTUD), and,

I don't particularly care about the translators.

>draft-gont-6man-ipv6-atomic-fragment is... what?

One option is that hosts behind such translators will have mss clamping because
PMTU doesn't work anyhow. This is very likely, because you need that on the
current IPv4 network.

Most likely many servers will just break PMTU for this case, which requires
translators to just insert a random ID and forward the packet. Effectively
changing the protocol.

However, there is a small chance that server operators will actually follow
the RFC and start always including fragment headers.

And that's not only very annoying, but also an enormous waste of resources.
Effectively, we are saying that it was an enormous mistake to not include
fragmentation in the IPv6 header and that we removed it from the routers.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 27 Jan 2012 19:13:46 -0300

> algorithm 2. And I couldn't find any other flowlabel draft with your name on 

Please see pages 9-11 of
<http://tools.ietf.org/id/draft-gont-6man-flowlabel-security-02.txt>.
Page 11 contains a sample output of the double-hash algorithm, which you
can compare with the sample output of algorithm #1 in page 9.

If you wanted to keep say, 1K or 65K counters (as a tradeoff between
security and "avoiding excessive state"), you could select the FL as:

Flow Label = table[G(Source Address, Destination Address, Secret Key1)]

and use the following pseudo code:

        /* Initialization at system boot time */
        for(i = 0; i < TABLE_LENGTH; i++)
            table[i] = random();

        /* Flow Label selection function */
        index = G(local_IP, remote_IP, secret_key2);
        count = 1048576;

        do {
            flowlabel = table[index] % 1048576;
            table[index]++;

            if(three-tuple is unique)
                return flowlabel;

           count--;

        } while (count > 0);

        /* Set the Flow Label to 0 if there is no
           unused Flow Label                      */

        return 0;

You could even include only the remote prefix (rather than the full
remote IPv6 address) in the hash function, such that you can reduce the
attacker chances of searching the entire "counter" space.

> pmtud gives a bad user experience.

Since IPv4 MTUs can be as low as 296, and since I doubt you clamp the
MSS to such a low value, you still rely on PMTUD. (Hopefully you system
imlements PMTUD + PLPMTUD for blackhole detection).

> PMTU blackhole detection is surprisingly uncommon. 

It is implemented in OpenBSD, I recall it bein implemented in Windows...
so I don't think it is uncommon.

> IPv6 also lacks NAT, 

Well, it doesn't:
<http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html>

> reassembly timeout and the packets rate.

And most importantly, the loss rate. Add a bad combination of reassembly
timeout + loss rate + data rate, and you're toast.

See e.g. <http://www.rfc-editor.org/rfc/rfc4963.txt>

> I don't particularly care about the translators.

There are other sources of this traffic. It has been reported on the
list that this traffic has been found on the wild.

Since such traffic is already there, you need to support atomic
fragments. And if you're going to support it (which you should), the
then IMO the most sensible way to do it is as indicated in the atomic
fragments I-D.

> PMTU doesn't work anyhow. This is very likely, because you need that on the

As noted above:
1) Why value would you use for clamping? (if it's anything >296, then it
doesn't relieve you from relying on PMTUD)
2) As noted, there are other sources of atomic fragments.

> fragmentation in the IPv6 header and that we removed it from the routers.

That's a completely different discussion. Me, I'm just trying to improve
what we have (which does not necessarily mean that I love the current
state of affairs). Even if you wanted to, it's probably way too late to
start from a clean slate.

Thanks,

---

From: Florian Weimer <[email-masked]>
Date: Sat, 28 Jan 2012 14:26:55 +0000

> They should know better.. what can I say?

These people generally know what they are doing.

> they also break PMTUD -- not just the generation of atomic fragments.

Currently, you can set DF=0 on IPv4 packets you sent, and fragment IPv6
at 1280 bytes.  Then you don't need to implement PMTUD.

If you want to deal with atomic fragments in the same way, you have to
add a fragment header to all outgoing packets smaller than 1280 bytes,
creating atomic fragments.  However, this doesn't work on the current
network because there are nodes which cannot process atomic fragments,
and you really, really need to support them.  Generating conforming
packets just isn't sufficient here, the recipient must actually be able
to process them.

You can work around that by broadcasting incoming ICMP packets
internally and provision a large enough destination cache on every node,
as I said before.  But this is an insane amount of complexity for very
little gain.

> So that you have only one bug instead of two?

Well, I think the gateway issue is actually fixable (because it's
local).  Pervasive atomic fragment support requires kernel, client and
server software updates in a certain order, something which is unlikely
to happen soon.  So the gateways will need those local workarounds
anyway, otherwise they will have trouble using DNS over IPv6.

> securely as non-fragmented traffic.

Except when you need to drop traffic with extension headers.  From time
to time, there are compelling reasons to do this.

> and you fix many of these, so... what's the big deal?

I think it's misleading to publish an RFC which implicitly suggests that
atomic fragments work on the current network, or somehow can be made to
work.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Jan 2012 04:59:56 -0300

> security and "avoiding excessive state"), you could select the FL as:

Let me clarify this a bit, and add a few more bits...

With the hash-based approach, you essentially have two elements: the
hash function, and the counter. The hash function adds the randomness,
while the counter produces the monotonically increasing sequence.

>From a FL frequency-reuse perspective, you'd have one counter per
destination, such that if flow #1 gets, say, FL 1000, flow #2 will get
1001, and so on.

This approach is possible to implement if you keep the counter in the
Destinations Cache (which is the obvious place to store it, since
there's one Destinations Cache entry per destination IPv6 address).

On the other extreme, you might have a single global counter (which
you'd keep somewhere in the IPv6 code, but not in any particular
Destination Cache entry. The two problems with this approach are:

1) If you keep a single counter, an attacker could possibly count the
number of new flaws established by a target system
2) Some FL values will be unnecessarily skipped (see the sample output
for algorithm #1 in draft-gont-6man-flowlabel-security)

A middle-ground would be to have an array of counters (neither one
global counter, nor one counter per destination). -- This is algorithm
#2 in the flowlabel-security I-D.

With this algorithm, even if you were to discard entries from the
Destinations Cache, it would still work (the counters are kept in the
IPv6 code, but not in any Destinations Cache entry -- and the counters
are shared between different flows).

A similar approach could be implemented for the generation of Fragment
Identification values.

Thus, even if you needed to empty the Destinations Cache, you'd still
have the benefit that the algorithm:
* Makes the IDs (either FL or Fragment ID) difficult to guess by an
off-path attacker
* Minimize the reuse frequency of the corresponding IDs.

Hope this one helps to clarify things a bit...

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Jan 2012 20:41:18 -0300

Florian,

> These people generally know what they are doing.

TCP relies on PMTUD, so how can you possibly state that "they know what
they are doing"?

Those are generally the same people that broke IPv4's PMTUD, that lead
to non-working 6to4 and Teredo, etc.

I have seen quite a few of those hard-to-debug issues which ended up in
the culprits removing the filters that they had.

> network because there are nodes which cannot process atomic fragments,

There are many bugs in current IPv6 implementations, and there are many
more to be found, because most of them are still very immature.

If you take the stance of "we know of a buggy implementation that does
not support this, and hence this mechanism is forbidden", I wonder where
we'd end up.

Fix the bug, and move on.

> as I said before.  B

Or just use the setsockopt() that Mark proposed if you're not going to
rely on PMTUD.

> to happen soon.  

It is unlikely to happen as long as people invest more time in arguing
in favour of bugs, rather than in fixing them. Look at OpenBSD's patch.
They did it in a couple of days.

That said, nobody is *introducing* atomic fragments.They should have
been supported for more than 15 years, and there is other stuff
(mentioned by Dan Wing at others) that would break without this.

My I-D is about improving their handling... not about introducing
support of atomic fragments to the IPv6 world.

> to time, there are compelling reasons to do this.

There are times in which you also need to drop TCP traffic. SHould we
ban TCP, too?

> atomic fragments work on the current network, or somehow can be made to

It doesn't imply anything. It just improves the handling of such packets
when compared with the current specs. That's it. If you think the
document should note that some systems do not support this packets, or
the like, I'd have no problem in doing so.

For instance, I will try to include a list of working vs. broken
implementations in the next rev of the I-D, and also note which ones
implement the proposed behaviour.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jan 2012 08:46:14 +1300

On 2012-01-28 20:59, Fernando Gont wrote:

...
> * Minimize the reuse frequency of the corresponding IDs.

I think it's a mistake to draw a strong analogy between the flow label
and the fragment ID.

When the flow label is used for any form of load distribution, it
really doesn't matter if occasional flows share the same label value,
as long as this is statistially rare. It just means that the two flows
might happen to follow the same path - so what? Thus, a completely
stateless algorithm is fine and the counter brings no benefit.

OTOH surely we need to completely avoid overlapping fragment IDs.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jan 2012 01:28:16 -0300

On 01/29/2012 04:46 PM, Brian E Carpenter wrote:
>> A similar approach could be implemented for the generation of
>> Fragment Identification values.
>> 
>> Thus, even if you needed to empty the Destinations Cache, you'd
>> still have the benefit that the algorithm: * Makes the IDs (either
>> FL or Fragment ID) difficult to guess by an off-path attacker *
>> Minimize the reuse frequency of the corresponding IDs.
> 
> I think it's a mistake to draw a strong analogy between the flow
> label and the fragment ID.

Well, both of the algorithms I was describing had the same goals --
hence the comment.

> really doesn't matter if occasional flows share the same label
> value, as long as this is statistially rare. It just means that the
> two flows might happen to follow the same path - so what? Thus, a
> completely stateless algorithm is fine and the counter brings no
> benefit.

I don't quite understand why you tag the hash based-algorithm as
stateful, or, put another way, why you don't tag as "stateful" your
algorithm as well.

The second variant in draft-gont-6man-flowlabel-security requires a set
of e.g. 256 (or more) system-wide counters. That's it. If you flag the
algorithm as stateful just because of that, you may as well tag any
algorithm that uses a PRNG as "stateful", because the PRNG usually
implies internal state, too.

That said, picking a random number is seen by some as "expensive" (as
opposed to just increment a counter). So there you have a trade-off,
too. (e.g., the hash-based approach may be cheaper CPU-wise).

Thanks,

---

From: Tore Anderson <[email-masked]>
Date: Mon, 30 Jan 2012 10:43:54 +0100

* Florian Weimer

>> require network-wide software updates currently.

A stateless translator does not keep track of the PMTU for the IPv4
destinations. That means that for it to work, it would have to clear the
Don't Fragment flag and generate a Fragment ID for every single packet
it translates to IPv4 that ends up smaller than 1260 bytes. I don't
believe this is desirable.

Also, RFC 2460 would have to be amended in order to allow hosts to
outright ignore ICMPv6 PTB w/MTU<1280, and the IPv6 host stacks would
also have to be updated accordingly. It seems to me, therefore, that the
approach of having the translator generate the Fragment ID is the one
that requires the most network-wide software updates.

* Fernando Gont

> checked, I think this was the case)

I can confirm that Linux will react to an ICMPv6 PTB<1280 by including a
Fragment header. There are a couple of bugs in its implementation, but I
expect these to be fixed shortly (patches are already available).

https://bugzilla.kernel.org/show_bug.cgi?id=42572
https://bugzilla.kernel.org/show_bug.cgi?id=42595

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

---

From: Florian Weimer <[email-masked]>
Date: Mon, 30 Jan 2012 10:06:41 +0000

Why?

You should generate the fragment ID anyway because some networks will
fragment DF=1 packets.

> that requires the most network-wide software updates.

Affected translators are in the minority.  Their vendors will implement
the change (i.e., fragment IPv6 packets without fragment headers)
because that's what's required to get them working with the currrent
network.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 30 Jan 2012 12:18:21 +0100

* Florian Weimer

>> believe this is desirable.

Because the network ends up second-guessing the host. RFC 2460 allows
IPv6 nodes to act on ICMPv6 PTBs w/MTU < 1280 by simply lowering the
Path MTU for the destination to the indicated value. In other words, an
IPv6 node can perform Path MTU Discovery for translated IPv4
destinations behind IPv4 links that have smaller MTU than 1260.

I actually prefer this approach to the "lower MTU to exactly 1280 and
include Fragment headers" alternative. However, if the translator is
clearing the DF flag when translating o IPv4, the IPv6 host cannot
perform PMTUD anymore.

> You should generate the fragment ID anyway because some networks will

I'm okay with generating the Fragment ID, I think. RFC 6145 section 5.1
says a translator MAY do so. What I'm not okay with is clearing the DF flag.

> because that's what's required to get them working with the currrent

I'm running a stateless translator (a Cisco ASR1K) in front of our
corporate homepage as we speak. It handles «atomic fragments» originated
by the IPv6-only web server perfectly in the way RFC 6145 mandates.
Absolutely *nothing* is required to change in order "to get it working
with the current network".

In any case, changing the translators won't stop RFC 2460-compliant
nodes from generating these atomic fragments. If you want to make that
happen, you need to change the host stacks so that they discard ICMPv6
PTB w/MTU<1280 (or, alternatively, implement them by lowering the PMTU
to whatever MTU value indicated in the PTB, even if it's <1280).

Best regards,

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Jan 2012 22:20:52 +0100

>From RFC-2460:
"In response to an IPv6 packet that is sent to an IPv4 destination
"(i.e., a packet that undergoes translation from IPv6 to IPv4), the
"originating IPv6 node may receive an ICMP Packet Too Big message
"reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
"is not required to reduce the size of subsequent packets to less than
"1280, but must include a Fragment header in those packets so that the
"IPv6-to-IPv4 translating router can obtain a suitable Identification
"value to use in resulting IPv4 fragments.  Note that this means the
"payload may have to be reduced to 1232 octets (1280 minus 40 for the
"IPv6 header and 8 for the Fragment header), and smaller still if
"additional extension headers are used.

Yes, it is allowed. But what do you do with hosts that do not do this?

And what do you do with the resulting denial of service attack if you allow 
anybody to lower your mtu to very small values?

You want to import all the bad things of IPv4?

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Jan 2012 22:28:04 +0100

>(mentioned by Dan Wing at others) that would break without this.

Currently, atomic fragments are rare.

You can easily see that many DNS servers are not doing any kind of PMTUD.
They just fragment at 1280.

What RFC-2460 effectively says is that if you are not doing PMTUD, then each
and every outgoing packet has to be an atomic fragment.

I'm not seeing that on todays IPv6 network. So that would be completely
new.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Jan 2012 22:49:59 +0100

>imlements PMTUD + PLPMTUD for blackhole detection).

The whole point of MTU clamping is you set it to whatever is the lowest on
paths between you host and the first IX, transit or what not, where the MTU
is at least 1500.

So if you have 296 locally somewhere, then yes, you would have to set the mss
that low.

The reason is that too many sending systems are broken. If you don't set the
mss, then may up with failing tcp connection in too many cases.

>so I don't think it is uncommon.

Maybe there is just too much Linux around then :-) Does implemented in Windows
also mean that it is enabled in just about all cases? Otherwise, we're back
to square one.

>See e.g. <http://www.rfc-editor.org/rfc/rfc4963.txt>

There is an interesting calculation there. Effectively, above 20 Mbit/s
you are toast anyhow.

And let me repeat, this is only an issue for IPv4 links with an mtu smaller
than 1280 and where there is also a one-to-one correspondance between IPv6 and
IPv4 address in the stateless-NAT box. 

This gets into the exceedingly rare territory.

>list that this traffic has been found on the wild.

I tried to find that message but I can't. Do you have a message ID?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jan 2012 20:42:27 -0300

> Currently, atomic fragments are rare.
[...]
> I'm not seeing that on todays IPv6 network. So that would be completely

See this:

And this:

http://article.gmane.org/gmane.ietf.ipv6/22728

And there are others...

Thanks,

---

From: Tore Anderson <[email-masked]>
Date: Tue, 31 Jan 2012 02:03:13 +0100

* Philip Homburg

> Yes, it is allowed. But what do you do with hosts that do not do this?

An IPv6 node conforming to the language above must either A) allow PMTUD
to work even if the PMTU is <1280, or B) create atomic fragments in
order to indicate that it wants the DF flag cleared and IPv4 routers to
perform fragmentation.

Either approach is valid, and work well today.

> anybody to lower your mtu to very small values?

Nothing in particular. I haven't had any problems with this in neither
IPv4 nor in IPv6, so I can't say I'm terribly concerned about it. In any
case, the atomic fragment approach is available for anyone who is
concerned about allowing the IPv6 PMTU to drop to IPv4 levels.

> You want to import all the bad things of IPv4?

Appeal to ridicule / straw man

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Jan 2012 12:12:27 +0100

>> I'm not seeing that on todays IPv6 network. So that would be completely

Let's say that my thesis is that all atomic fragments are directly or
indirectly caused by the support for stateless NAT in RFC-2460. Then what do

>https://bugzilla.kernel.org/show_bug.cgi?id=42572

"An IPv4 client behind a link with a MTU of 1259 downloading a file from an IPv6
server"

So yes.

>https://bugzilla.kernel.org/show_bug.cgi?id=42595

"If the allfrag feature has been set on a host route (due to an ICMPv6 Packet
Too Big received indicating a MTU of less than 1280)"

Again yes.

>http://article.gmane.org/gmane.ietf.ipv6/22728

"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."

Inconclusive. We don't know why that traffic is there.

So, just remove that requirement from RFC-2460, and the problem is gone.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Jan 2012 15:58:55 -0300

> So, just remove that requirement from RFC-2460, and the problem is gone.

If you're meaning to remove support for some feature from the standard
on the basis that it is not used, then the *you* should prove that is
not being used.

So far, you're arguments have been based on guesswork. People have
reported that this feature is used, and have even provided packets
traces showing that.

I personally believe it is very dangerous to think about removing
something without bothering to consider what might break, and without
bothering whether there's stuff (such as translators) that depend on
that feature.

Fix the bug, and be done with it.

Thanks,