Subject: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments

From: Brian Haberman <[email-masked]>
Date: Thu, 13 Dec 2012 13:57:12 -0500

All,
      I have performed my initial AD review of this draft.  The 
following are my comments on the content.  I am open to discussing these 
in order to move this document forward...

Substantive
----------------

* It would be quite useful to explicitly define "atomic fragment" prior 
to using it in the document.  This could be done in the Introduction in 
a formal manner and the use of "atomic fragments" in the Abstract can be 
re-worded.

* The Introduction needs to provide more motivation as to why we should 
allow these atomic fragments to exist.  Please provide the rationale 
discussed on the mailing list about how v4/v6 translators use the 
fragmentation information.

* The core source of this attack is that some implementations have 
predictable algorithms for generating the Fragmentation ID, allowing 
attackers to launch these types of attacks.  It would be good to 
reference that work in this draft as well.

* What is the purpose of the indented paragraph within the first bullet 
of the list in section 2?  Is it a quote from one of the two referenced 
RFCs?

* It is not clear to me why the document spends much time on discussing 
ICMP-based attacks on the source of traffic, especially ones that ignore 
existing RFCs, when the issue is really with devices that don't do the 
right thing on the receiving end.

* I am rather disappointed with the Security Considerations section 
given that this draft is addressing a perceived security vulnerability. 
  In fact, I would like to ask the WG if the solution actually creates 
an attack vector on receiving hosts.  An on-device path could modify 
packets with Fragmentation headers by setting Offset=0 and M=0.  This 
would cause the receiver to blindly treat the packet as an atomic and 
pass it up to the upper-layer protocol.  Is this an acceptable risk? 
Obviously, packets protected by IPsec would be immune to this attack. 
At a minimum, the Security Considerations should spend some time 
discussing the potential new attacks based on these rules.

Editorial
------------

- Abstract
      * s/IPv6 specification allows/IPv6 specifications allow/

- Introduction
      * s/[RFC2460] allowed/[RFC2460] allows/
      * s/[RFC5722] forbid/[RFC5722] forbids/
      * Provide a forward pointer to Appendix A in paragraph 4

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Dec 2012 12:54:22 -0300

Hi, Brian,

Thanks so much for your feedback! -- Please find my comments inline...

> Substantive

How about this:

* Change the first sentence of the Abstract to:
  "The IPv6 specification allows packets to contain a Fragment Header
   without the packet being actually fragmented into multiple pieces
   (we refer to these packets as "atomic fragments")."

* Change the last sentence of the third para of "1. Introduction" to:
"The resulting packets
   will thus *not* be actually fragmented into several pieces, but just
   include a Fragment Header with both the "Fragment Offset" and the "M"
   bit set to 0 (we refer to these packets as "atomic fragments")."

* Have a new new section right after "Introduction", with the following
contents:

---- cut here ----
2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   IPv6 atomic fragments
        IPv6 packets that contain a Fragment Header with the Fragment
        Offset set to 0 and the M bit set to 0.
---- cut here ----

> fragmentation information.

How about incorporating this text as a parenthetical note (indented
text) right after the third para of Section 1:

"IPv6/IPv4 translators employ the Fragment Identification information
found in the Fragment Header to select an appropriate Fragment
Identification value for the resulting IPv4 fragments".

> reference that work in this draft as well.

draft-gont-6man-predictable-fragment-id is referenced as
"[PREDICTABLE-ID]" throughout this document. Is there anything I'm missing?

> of the list in section 2?  Is it a quote from one of the two referenced

The bullet notes that some implementations fail to validate the ICMPv6
error messages. The indented text notes that it may be virtually
impossible to do so (i.e., a clarification).

> right thing on the receiving end.

Because by means of ICMPv6-based attacks an attacker can *trigger* the
use of IPv6 atomic fragments. Without such ability, an attacker could
only leverage atomic fragments for communication flows that legitimately
employ them.

> given that this draft is addressing a perceived security vulnerability.

Well, the Sec Cons section is "as simple as it can be". I could
certainly make it longer, if deemed appropriate... But I personally
think that it says what it needs to say: this document eliminates the
aforementioned attack vector.

>  In fact, I would like to ask the WG if the solution actually creates an
> attack vector on receiving hosts.  An on-device path could modify
> pass it up to the upper-layer protocol.  

If the attacker is on path -- and essentially a man in the middle -- why
would he bother to do this if he can simply blackhole the legtimate
atomic-fragment, and create/send a new one?

That said, it's simple: Since atomic-fragments are... atomic :-), you
don't really need to wait for anything else to process them. This means
that you do not need to mix atomic fragments with any other queued
fragments, you do not need to queue the atomic fragments waiting for
anything else, etc. This simplifies the processing, isolates
atomic-fragment processing from any other packets, etc. I cannot really
see how this could introduce a new attack vector.

> Is this an acceptable risk?
> Obviously, packets protected by IPsec would be immune to this attack. At
> a minimum, the Security Considerations should spend some time discussing
> the potential new attacks based on these rules.

I fail to see the attack vector you're describing. i.e., this behaviour
doesn't allow an attacker to do anything he couldn't do already...

Am I missing something? And, if so, could you please elaborate?

>      * Provide a forward pointer to Appendix A in paragraph 4

Will do.

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 18 Dec 2012 11:32:46 -0500

>          Offset set to 0 and the M bit set to 0.

The above sounds reasonable.

> Identification value for the resulting IPv4 fragments".

I am fine with adding the above text.  Not sure that it needs to be 
indented though.

> "[PREDICTABLE-ID]" throughout this document. Is there anything I'm missing?

After re-reading the portions containing the above reference, I don't 
think there are any needed changes for this point.

> impossible to do so (i.e., a clarification).

I would suggest just making that text a part of the bulleted text. 
Typically, indented text is a quotation.

> only leverage atomic fragments for communication flows that legitimately

The point of this draft is to fix the re-assembly behavior at the 
receiver. There are a variety of ways for an attack to be launched that 
do not involve anything being sent to the sender, ICMP or not.

> atomic-fragment, and create/send a new one?

No, these are not legitimate atomic fragments.  Let's say that a source 
fragments a packet into three packets.  The attacker sees one of these 
packets and changes the offset and/or M to 0 in order to make that one 
fragment look like an atomic.

The receiver processes the modified fragment as atomic and passes it up 
to the upper-layer protocol.  My question to the WG is whether or not 
people see that as an issue.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Dec 2012 11:13:29 -0800

I have a question about this document. Is a middlebox permitted
to fragment an "atomic" fragment before forwarding the packet
on to the next hop? If not, why not - after all, that's why the
host inserted the fragment header in the first place. If so,
then shouldn't the draft say something about the permissible
behavior of middleboxes when forwarding an "atomic" fragment
(e.g., "a middlebox is permitted to perform fragmentation on
an "atomic" fragment before forwarding to the next hop")?

Thanks - Fred
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 17:00:00 -0300

Hi, Fred,

On 12/18/2012 04:13 PM, Templin, Fred L wrote:
> host inserted the fragment header in the first place. 

My take is that an *IPv6* middle-box is not permitted to fragment the
packet. The IPv6/IPv4 translator is, from an IPv6 point of view, a
host/end-point/end-system (that's where the v6 world ends for that packet).

As to the "why not", I'd guess the reason is "only IPv6 hosts fragment
packets"

> If so,

Why should there be a difference between fragmenting an atomic fragment
and e.g. re-fragmenting a non-atomic fragment?

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 17:16:12 -0300

Hi, Brian,

>>> a formal manner and the use of "atomic fragments" in the Abstract can be
[....]
> The above sounds reasonable.

I will apply these changes to the next rev.

> I am fine with adding the above text.  Not sure that it needs to be

The way I use indented text is to include info that is essentially a
"clarification" of something, but that you don't need to read to
understand the document.

> Typically, indented text is a quotation.

OK, will do.

> do not involve anything being sent to the sender, ICMP or not.

That note is meant to be a warning along the lines of "look, the trouble
here s not just attacks against existing atomic-fragment traffic, since
an attacker can actually trigger the generation of such atomic-fragments
for any communication flow.". i.e., it notes that, at the end of the
day, this change benefits not only communication flows already employing
atomic fragments, but rather *all* communication flows, since it is
trivial to trigger generation of atomic fragments.

I guess one might argue that part of this could be moved to the Sec Cons
section... but I thought it was too important/central to comment on it
only at the Sec Cons section.

> fragment look like an atomic.

What would be the difference between this, and simply removing the
fragments from the net, and re-send the packets as e.g., non-fragmented
traffic?

i.e., the bottom-line is that once the attacker becomes on-path (not to
mention "man in the middle"), this is kind of "game over". Things become
pretty much "IPsec or death".

> people see that as an issue.

Me, I don't see any issues here. For instance, it is very likely that,
as a result of this, some upper layer checksum will fail, and end the
packet will be drooped by the destination system. Also, as noted above,
if I was an attacker and for some reason wanted a legitimate fragment to
be "passed up" without any further processing/reassembly, I'd simply
re-encapsulate such contents in a non-fragmented packet (e.g., rather
than clearing the M and FO bits, I'd simply remove the Frag header). In
any case, I wonder what the "goal" that you think the attacker would
have in mind... because if the attacker is a MITM or is simply on-path,
and the goal is DoS, he can simply drop packet or corrupt them, rather
than playing with this particular issue.

Thanks!

Best regards,

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Dec 2012 09:41:32 -0800

Hi Fernando,

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2012 12:00 PM
> To: Templin, Fred L
> Cc: [email-masked]; 6man WG
> Subject: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments
> 
> Hi, Fred,
> 

I am thinking of the case of links (e.g., tunnels) in the middle
of the network that must perform link adaptation in order to meet
the 1280 byte minimum IPv6 MTU. For example, if a tunnel is
configured over a link that has an MTU less than (1280+HLEN), the
tunnel ingress will see an MTU smaller than 1280. In that case,
RFC2473 says that the tunnel ingress should perform fragmentation
on the encapsulated packet and the tunnel egress gets to do the
reassembly. But, that can amount to a lot of extra work for the
tunnel egress.

To save the egress from this burden then, it would be great if
there were a way to get the source host to perform fragmentation
so that the destination gets to do the reassembly. In lieu of
that, it would be preferable for the tunnel ingress to perform
fragmentation on the inner packet before encapsulation provided
the inner packet includes an IPv6 fragment header.

I talk about this in my draft on "IPv6 Path MTU Updates":

http://www.ietf.org/id/draft-generic-6man-tunfrag-06.txt

This document talks about taking care of packets that are in
the "red zone" size between 1280 and 1500 bytes when there
is a link in the path (e.g., a tunnel) that must perform
link adaptation to meet the minimum size. And, it seeks to
update RFC2460 by allowing the middlebox to signal the host,
and to perform fragmentation on the inner packet when the
packet includes an IPv6 fragment header. It would be good
to get your feedback on this document.

> and e.g. re-fragmenting a non-atomic fragment?

Based on the above draft, a host that is clued into the link
adaptation requirements will produce non-atomic fragments that
are sufficiently small so that they will not trigger the link
adaptation. A host that is not clued into the requirements will
send atomic fragments, which the middlebox should be permitted
to split into multiple fragments.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Dec 2012 10:04:00 -0800

Hello again, Fernando,

> host/end-point/end-system (that's where the v6 world ends for that

On further thought, I don't fully accept the notion that the
translator is a host/end-point/end-system. The IPv6 host provides
the translator with an Identification value, and that value carries
forward into the IPv4 world. So, while the IPv6 packet itself does
not carry forward, IPv6 information does.

> As to the "why not", I'd guess the reason is "only IPv6 hosts fragment

I think there would need to be an asterisk next to that statement
saying that IPv6/IPv4 translators are exempt from this requirement.
And, if the translator can be exempt then so also should an IPv6
middlebox that connects to a link that would otherwise be obliged
to perform burdensome link adaptation.

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Dec 2012 02:03:34 -0300

Hi, Fred,

> the inner packet includes an IPv6 fragment header.

That sounds sensible -- although I guess this would require

> to get your feedback on this document.

I'd be glad to review it. Will do it during these seasons.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Dec 2012 02:09:24 -0300

On 12/20/2012 03:04 PM, Templin, Fred L wrote:
> translator is a host/end-point/end-system.

>From the pov of the IPv6 network that's where the packet "ends".

> The IPv6 host provides

Yes and no -- e.g., you cannot use the full 32-bit Frag ID.

> to perform burdensome link adaptation.

This does not only apply to tunnels. One could think of some radio
devices, embedded systems, etc., for which an adaptation layer would
possible be overkill. -- So you're idea sounds, at least in principle,
sensible to me.

I will review your I-D and will come back with some feedback.

Thanks!

Best regards,

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Dec 2012 08:49:30 -0800

Hi Fernando,

> Sent: Thursday, December 20, 2012 9:09 PM
> To: Templin, Fred L

Right, with an asterisk next to "ends" (*). IPv6 information does
carry forward beyond the translator the same as IPv4 information
carries forward for IPv4 packets from a private network transiting
an IPv4 translator to the public IPv4 network.

> Yes and no -- e.g., you cannot use the full 32-bit Frag ID.

Right, but the lower 16 bits does come from IPv6-land.

> possible be overkill. -- So you're idea sounds, at least in principle,

I agree, and constrained radio links are a key area of interest.

> I will review your I-D and will come back with some feedback.

Thanks for the further analysis, and I look forward to your
thoughts on the draft.

Fred