Subject: Re: 6MAN WG Last Call:draft-ietf-6man-overlap-fragment-01.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 20 May 2009 14:19:56 -0400

All,
      This Last Call concluded with exactly one public comment.  We 
cannot advance this document without support of the working group. 
Please review this draft and state whether you support or disagree with 
advancing it.

Regards,
Brian

Brian Haberman wrote:
> All,
>      This message starts a 2-week 6MAN Working Group Last Call on 
> advancing:
> 
>         Title     : Handling of overlapping IPv6 fragments
>         Author(s) : S. Krishnan
>         Filename  : draft-ietf-6man-overlap-fragment-01.txt
>         Pages     : 7
>         Date      : 2008-11-4
> 
> as a Proposed Standard.  Substantive comments and statements of support 
> for advancing this document should be directed to the mailing list. 
> Editorial suggestions can be sent to the document editor.  This last 
> call will end on March 16, 2009.
> 
> Regards,
> Brian & Bob
> 6MAN co-chairs
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Arnaud Ebalard <[email-masked]>
Date: Wed, 20 May 2009 21:31:58 +0200

Hi,

Brian Haberman <[email-masked]> writes:

> cannot advance this document without support of the working
> group. Please review this draft and state whether you support or
> disagree with advancing it.

I support advancing the document. The content of section 4 should have
been the default in 2460, IMHO. Nonetheless, some minor comments on an
inline version of the document (version 02). Those may have already been 
discussed, I did not look at the archives.

> 3.  The attack
> 
>    This attack describes how a malicious node can bypass a firewall
>    using overlapping fragments.  Consider a sufficiently large IPv6
>    packet that needs to be fragmented.
> 
> 
>    +------------------+--------------------//-----------------------+
>    |  Unfragmentable  |                 Fragmentable                |
>    |       Part       |                     Part                    |
>    +------------------+--------------------//-----------------------+
> 
>                         Figure 1: Large IPv6 packet
> 
>    This packet is split into several fragments by the sender so that the
>    packet can fit inside the path MTU.  Let's say the packet is split
>    into two fragments.
> 
>    +------------------+--------+--------------------+
>    |  Unfragmentable  |Fragment|       first        |
>    |       Part       | Header |      fragment      |
>    +------------------+--------+--------------------+
> 
>    +------------------+--------+--------------------+
>    |  Unfragmentable  |Fragment|       second       |
>    |       Part       | Header |      fragment      |
>    +------------------+--------+--------------------+
> 
>                      Figure 2: Fragmented IPv6 packet
> 
>    Consider the first fragment.  Let's say it contains a destination
>    options header (DOH) 80 octets long and is followed by a TCP header.
> 
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
>  |NextHdr=DOH(60)|   Reserved    |   FragmentOffset = 0    |Res|1|
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                Identification=aaaabbbb                        |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==DOH
>  |NextHdr=TCP(6) | HdrExtLen = 9 |                               |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
>  |                                                               |
>  .                                                               .
>  .                            Options                            .
>  .                                                               .
>  |                                                               |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
>  |        Source Port            |       Destination Port        |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                       Sequence Number                         |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                    Acknowledgment Number                      |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Offset| Reserved  |U|A|P|R|S|F|           Window              |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                          Figure 3: First Fragment
> 
>    The TCP header has the following values of the flags S(YN)=1 and
>    A(CK)=1.  This makes an inspecting stateful firewall think that it is

     I would say "This may make". If the initial rule for the creation
     of the state specifically require S=1 and A=0, that trick will not
     work. It basically depends on the default behavior of the firewall
     for the creation of the state and on the specific content of the
     ruleset. Netfilter (Linux fw) allows to specify that.

>    a response packet for a connection request initiated from the trusted
>    side of the firewall.  Hence it will allow the fragment to pass.  It
>    will also allow the following fragments with the same Fragment
>    Identification value in the fragment header to pass through.
> 
>    A malicious node can form a second fragment with a TCP header that
>    changes the flags and sets S(YN)=1 and A(CK)=0.  This would change

                                                      This may change

     Here, It depends on the behavior of the remote host: if it consider
     prefers first data, this will not work.

>    the packet on the receiving end to consider the packet as a
>    connection request instead of a response.  By doing this the
>    malicious node has bypassed the firewall's access control to initiate
>    a connection request to a node protected by a firewall.

     I am not arguing on the fact this kind of attack may work depending
     on the environment, devices and configuration.

> 
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
>  |NextHdr=DOH(60)|   Reserved    |   FragmentOffset = 10   |Res|0|
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                Identification=aaaabbbb                        |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
>  |        Source Port            |       Destination Port        |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                       Sequence Number                         |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                    Acknowledgment Number                      |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Offset| Reserved  |U|A|P|R|S|F|           Window              |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                          Figure 4: Second Fragment
> 
>    Note that this attack is much more serious in IPv6 than in IPv4.  In
>    IPv4 the overlapping part of the TCP header did not include the
>    source and destination ports.  In IPv6 the attack can easily work to
>    replace the source or destination port with an overlapping fragment.
> 
> 
> 4.  Recommendation
> 
>    IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
>    create overlapping fragments.  IPv6 nodes that receive a fragment
>    that overlaps with a previously received fragment MUST cease the
>    reassembly process and MUST discard the previously received fragments
>    with the same IPv6 Source Address, IPv6 Destination Address and
>    Fragment Identification.

Simple, efficient. Should have been the default in RFC 2460.

Cheers,

a+

---

From: Christian Vogt <[email-masked]>
Date: Fri, 22 May 2009 17:30:00 -0700

Suresh and all -

I have read the document and support it being progressed as a Proposed
Standard.  The document identifies a security vulnerability that ought
to be mitigated, and this document is a necessary step in doing so.

One comment:  Is there data on how common overlapping fragments are in
the real world?  Obviously, the more common overlapping fragments are,
the less appropriate it would be for firewalls to enforce
non-overlapping in the near term.  After all, firewalls shouldn't drop
legitimate sessions that happen to include overlapping fragments.  It
would take some time for existing IPv6 implementations to be updated
before it would be safe to add such enforcement in firewalls.  Hence,
it may be good to add a cautionary note about this to the document.

- Christian

On May 20, 2009, Brian Haberman wrote:

> All, This Last Call concluded with exactly one public comment.  We
> Regards, Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 25 May 2009 10:17:03 -0400

Hi Arnaud,
   Thanks for your comments. Please find responses inline.

>      ruleset. Netfilter (Linux fw) allows to specify that.

Sounds good. I will make this change.

>      prefers first data, this will not work.

OK.

> Simple, efficient. Should have been the default in RFC 2460.

Sounds good.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 25 May 2009 10:32:10 -0400

Hi Christian,

OK.

> the real world?  Obviously, the more common overlapping fragments are,

As far as I know, there are no legitimate applications for overlapping 
fragments (please send in a note if you see any). I am not aware of any 
stack that generates these either under normal conditions either.

> it may be good to add a cautionary note about this to the document.

If there are no known legitimate applications of overlapping fragments, 
would you still like this cautionary note to be included?

Thanks
Suresh

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 May 2009 14:52:45 -0700 (PDT)

Hi Brian,
  I've read this draft. I support it and agree with advancing it.

Regards,

Behcet

----- Original Message ----
From: Brian Haberman <[email-masked]>
To: [email-masked]
Cc: Bob Hinden <[email-masked]>
Sent: Wednesday, May 20, 2009 1:19:56 PM
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-overlap-fragment-01.txt

All,
     This Last Call concluded with exactly one public comment.  We cannot advance this document without support of the working group. Please review this draft and state whether you support or disagree with advancing it.

Regards,
Brian

Brian Haberman wrote:
> All,
>      This message starts a 2-week 6MAN Working Group Last Call on advancing:
> 
> as a Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the document editor.  This last call will end on March 16, 2009.
> 
> Regards,
> Brian & Bob
> 6MAN co-chairs

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 26 May 2009 09:09:13 -0700

Hi,

The document version now is 02 and not 01. I support the document.

That said I think the below could be clarified further about what
needs to be done to the current fragment (it does talk about all
previous fragments):

   IPv6 nodes that receive a fragment
   that overlaps with a previously received fragment MUST cease the
   reassembly process and MUST discard the previously received fragments
   with the same IPv6 Source Address, IPv6 Destination Address and
   Fragment Identification.

Thanks,
Vishwas

On Wed, May 20, 2009 at 11:19 AM, Brian Haberman
<[email-masked]> wrote:
> All,
>     This Last Call concluded with exactly one public comment.  We cannot
> advance this document without support of the working group. Please review
> this draft and state whether you support or disagree with advancing it.
>
> Regards,
> Brian
>
> Brian Haberman wrote:
>>
>> All,
>> Editorial suggestions can be sent to the document editor.  This last call
>> will end on March 16, 2009.
>>
>> Regards,
>> Brian & Bob
>> 6MAN co-chairs

---

From: Christian Vogt <[email-masked]>
Date: Tue, 26 May 2009 10:40:29 -0700

Suresh -

> stack that generates these either under normal conditions either.

In addition, there doesn't seem to be a reason, other than malicious,
for generating overlapping fragments.

> would you still like this cautionary note to be included?

Yes, the document should contain more explicit guidance for firewall
builders on how the document affects their products.  Given the apparent
absence of overlapping fragment for legitimate traffic, it would be
safe, and even recommended, for firewall builders to directly apply the
conclusions from the document in their products.  This should be made
explicit in a short extra paragraph in my opinion.

- Christian

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 27 May 2009 18:45:11 -0400

Hi Vishwas,

OK.

>    with the same IPv6 Source Address, IPv6 Destination Address and

Does the following change work for you? If so, I can make the change.

Replace

"MUST discard the previously received fragments"

with

"MUST discard all received fragments"

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 27 May 2009 18:47:20 -0400

Hi Christian,

> explicit in a short extra paragraph in my opinion.

Firewalls may or may not reassemble fragments, and I am not sure what to 
put in here. If you can suggest some text to put in this paragraph, I 
will be glad to add it to the document.

Thanks
Suresh

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 27 May 2009 16:27:57 -0700

Hi Suresh,

Sounds good to me.

Thanks,
Vishwas

---

From: Christian Vogt <[email-masked]>
Date: Thu, 28 May 2009 10:43:00 -0700

Suresh -

My suggestion is not about fragment reassembly in firewalls, but rather
about adding guidance to the document of when it is safe for a firewall
to drop overlapping fragments.

Given the apparent absence of overlapping fragments in legitimate
traffic, it would be safe, hence recommended, for firewalls to drop
overlapping fragments.

Hope this helps.

- Christian

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 28 May 2009 10:47:57 -0700

Hi Chritian,

The draft already contains the below:

"   IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
   create overlapping fragments.  IPv6 nodes that receive a fragment
   that overlaps with a previously received fragment MUST cease the
   reassembly process and MUST discard the previously received fragments
   with the same IPv6 Source Address, IPv6 Destination Address and
   Fragment Identification."

What more are you suggesting?

Thanks,
Vishwas

---

From: Christian Vogt <[email-masked]>
Date: Thu, 28 May 2009 10:55:00 -0700

On May 28, 2009, Vishwas Manral wrote:

>  "IPv6 nodes transmitting datagrams that need to be fragmented MUST  
> NOT

Vishwas -

The above text relates to the sender and the receiver of
fragmented packets, as far as I can tell.  My suggesting relates to
firewalls between that sender and receiver.

- Christian

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 28 May 2009 10:58:40 -0700

Hi Christian,

Ok. I think to make it more generic we can call it a middlebox instead
of a firewall alone.

The text could be :

"IPv6 nodes or middleboxes that receive a fragment that overlaps with
a previously received fragment MUST cease the reassembly process and
MUST discard the previously received fragments  with the same IPv6
Source Address, IPv6 Destination Address and Fragment Identification."

Thanks,
Vishwas

On Thu, May 28, 2009 at 10:55 AM, Christian Vogt
<[email-masked]> wrote:
>>  "IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT

---

From: Christian Vogt <[email-masked]>
Date: Thu, 28 May 2009 11:05:07 -0700

Looks very good, Vishwas.

You may consider softening this from a "MUST" to a "SHOULD", though,
given that hosts are at this stage not guaranteed to always produce
non-overlapping fragments.

- Christian

---

From: Thomas Narten <[email-masked]>
Date: Thu, 28 May 2009 16:06:24 -0400

> Source Address, IPv6 Destination Address and Fragment

Except now it can be read to apply to devices that shouldn't be
required to do this, i.e., those that are not attempting to reassemble
anything...

How about something like:

    When reassembling an IPv6 datagram, if one or more its constituent
    fragments is determined to be an overlapping fragment, the entire
    datagram (and any constituent fragments -- including those not yet
    received), MUST be silently discarded.

Thomas

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 29 May 2009 08:56:16 +0900

Hi

>     received), MUST be silently discarded.

I think this phrase is really good, but does it need to be silent?

I also support advancing this document as well.

Regards,
Seiichi

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 May 2009 10:12:41 -0400

Hi Thomas,

>     received), MUST be silently discarded.

Sounds great. I will make this change.

Thanks
Suresh