Subject: Re: RFC5722 and network packet duplication

From: "C. M. Heard" <[email-masked]>
Date: Mon, 31 Aug 2015 10:52:15 -0700

Fernando Gont wrote:

> I believe the point Dennis is raising (which seems valid to me) is that

> RFC5722 only wants to tackle the case of partial overlaps (see e.g., the

> cases we test in

> <
http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html
>).

> Full overlaps (resulting from packet duplication) shouldn't really be an

> issue. (Me thinking out loud) It would seem that RFC5722 is

> underspecified in this respect.

While I definitely agree that RFC 5722 is underspecified in this respect,

I also think Dennis’s point about the amount of state that a reassembly

engine should be required to keep deserves further discussion.  His point

(as I understand) is that the following case (involving a duplicate

fragment, specifically Frag #3)

Frag. #1:*  AAAAAAAAAA*

Frag. #2:*                                DDDDDDDDDD*

Frag. #3:*                      CCCCCCCCCC*

Frag. #4:*            BBBBBBBBBB*

Frag. #3:*                      CCCCCCCCCC*

Frag. #5:                                          *EEEEEEEEEE*

cannot be distinguished from the case below, which involves overlapping

fragments, unless the reassembly engine keeps a complete history of the

start and end offsets of all of the fragments it has received, in

addition to the locations of the holes:

Frag. #1:*  AAAAAAAAAA*

Frag. #2:*                           CCCCCDDDDDDDDDD*

Frag. #3:*            BBBBBBBBBBCCCCC*

Frag. #4:*                      CCCCCCCCCC*

Frag. #5:                                          *EEEEEEEEEE*

Admittedly the only reassembly engines that I've inspected or

implemented were for IPv4 not IPv6, but modifying any of them to

keep a complete history of the offsets of all fragments received

would have been a very significant complication (none of them did

so, of course, since there is no reason to do so in IPv4).  It

would be no surprise to me if a mandate for IPv6 implementations to do
so were widely ignored.   Fortunately, the security issue that concerns
the NIDS folks –- namely, the problem of different implementations
yielding different reassembly results data owing to different policies
regarding how to handle overlapping data -- can be largely solved much
more simply: just mandate that a fragment that is (or appears to be) a
duplicate of one that was already received MUST be silently discarded.
In cases where the network causes packets to be received in a different
order at different delivery points, it is still possible for a NIDS
device to get a different result than the systems it’s trying to
protect, but that is not something over which an attacker has control.

I notice that RFC 5722 section 4, “Node Behavior”, does seem leave some

wiggle room, and at the same time seems to impose another potentially

onerous requirement.  It says:

   When reassembling an IPv6 datagram, if one or more of 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.

A question for the authors: were the words "is determined to be" actually

intended to allow an implementation some discretion in how much effort it

makes to detect overlapping fragments?

Also, the words "including those not yet received" imply that a

reassembly engine must maintain some state for each 3-tuple (source

addr, dest addr, ID) for some time after a reassembly is abandoned;

how much time is enough?  This seems be another place where RFC 5722

appears to be underspecified.

Mike Heard

---

From: Bob Hinden <[email-masked]>
Date: Mon, 31 Aug 2015 22:00:34 +0300

Hi,

Skipping to the end:

>    fragments is determined to be an overlapping fragment, the entire
>    datagram (and any constituent fragments, including those not yet
>    received) MUST be silently discarded.
> 

See the accepted Errata on RFC5722:

  https://www.rfc-editor.org/errata_search.php?rfc=5722

It removes the "including those not yet received” text.  As it says that isn’t implementable.

Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 Aug 2015 17:16:25 -0400

> It removes the "including those not yet received” text.  As it says that isn’t implementable.

+1. I personally implemented it with a fixed number of state entries 
with the oldest entries being cleared when full or when a timeout 
expires. For the timeout I used the value I read from 
/proc/sys/net/ipv6/ip6frag_time which defaults to 60 seconds. As the 
errata says this requirement is not meetable if there is attack traffic 
that fills the state entries before the oldest entries timeout.

Thanks
Suresh