Subject: [BEHAVE] handling packet with fragments, second try

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 02 Dec 2009 10:44:51 +0100

So, based on the comments from Dan, Iljitshc and Reinaldo, I have 
rewritten the text as follows:

   If the incoming IP packet contains a fragment, then more processing
   may be needed.  This specification leaves open the exact details of
   how a NAT64 handles incoming IP packets containing fragments, and
   simply requires that the external behavior of the NAT64 is compliant
   with the following conditions:

      The NAT64 MUST handle fragments arriving out-of-order conditioned
      to the following:

         The NAT64 MUST limit the amount of resources devoted to the
         storage of fragmented packets in order to prevent from DoS
         attack.

         The NAT64 MUST allow the fragments to arrive over a time
         interval.  The time interval MUST be configurable and the
         default value MUST be of at least 10 seconds.

         The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the first fragment.

      A NAT64 MAY elect to queue the fragments as they arrive and
      translate all fragments at the same time.  Alternatively, a NAT64
      MAY translate the fragments as they arrive, by storing information
      that allows it to compute the 5-tuple for fragments other than the
      first.  In the latter case, the NAT64 will still need to handle
      the situation where subsequent fragments arrive before the first.

      Implementers of NAT64 should be aware that there are a number of
      well-known attacks against IP fragmentation; see [RFC1858] and
      [RFC3128].  Implementers should also be aware of additional issues
      with reassembling packets at high rates, described in [RFC4963]

The basic idea is that the NAT64 must handle fragments as long as the 
conditions hold. does that makes sense? Or should i change if for a 
SHOULD and qualify it with the conditions?

About the timer, i have required it to be configurable, still not 
convinced we shoudl propose a lower defualt value with the existent 
qualifications of the must.

---

From: Zhen Cao <[email-masked]>
Date: Thu, 3 Dec 2009 21:58:44 +0800

On Wed, Dec 2, 2009 at 5:44 PM, marcelo bagnulo braun
<[email-masked]> wrote:
> So, based on the comments from Dan, Iljitshc and Reinaldo, I have rewritten
> the text as follows:
>

I would like to know why you defined 10 seconds as the lower bound.

I do not think this value is needed in the document. For a flow that
has few fragments (e.g. just two fragments), the low bound may delay
the processing efficiency.

> conditions hold. does that makes sense? Or should i change if for a SHOULD
> and qualify it with the conditions?
>
> About the timer, i have required it to be configurable, still not convinced
> we shoudl propose a lower defualt value with the existent qualifications of
> the must.
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 3 Dec 2009 22:03:34 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, December 02, 2009 1:45 AM
> To: Behave WG
> Subject: [BEHAVE] handling packet with fragments, second try
> 

Grammar: 
Either s/from/a/
Or s/prevent/protect/

>          default value MUST be of at least 10 seconds.

Not sure how this MUST interacts with the previous paragraph.
If you're under attack it may not be feasible to allow fragments
to arrive over a 10 second period, since doing so may exhaust all
memory.  Clarify.

>          completely contained within the first fragment.

Presumably "first" means the first to arrive, as opposed to first in
byte order, yes?  Since "first" is used in the other sense in the 
next paragraph, switching uses is confusing.

In addition, why is this sentence present at all?  This seems dangerous.

>       the situation where subsequent fragments arrive before the first.

The last sentence above looks good, although it seems to contradict the
MAY I questioned above.

-Dave

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Dec 2009 16:38:55 -1000

Hi,

a few minor comments:

>         storage of fragmented packets in order to prevent from DoS

I'd add an "under overload conditions" somewhere. While not overloaded, limiting storage doesn't really serve any purpose but lowers reassembly chances.

>         default value MUST be of at least 10 seconds.

Similar to the above comment: a short timeout doesn't really save you anything unless there's an overload condition. But then you'd use something else to shed load.

I'm wondering if we should simply say "use a good sized fixed buffer that doesn't drive you into overload when full, and use an oldest-first (or LFU?) replacement scheme"?

>         completely contained within the first fragment.

The NAT can't really require that. I think what you want to say is that NATs MAY drop fragment chains where the header is split over multiple fragments.

Lars

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 Dec 2009 09:01:15 +0000

First of all I agree with comments already stated WRT:

1) 10sec interval or any min value cannot be mandated since the
primary purpose of this advice seems to be to protect NAT64 from
fragmentation attacks, which means that the NAT64 implementation
should be free to drop fragments if it feels threatened.

2) the requirement (even as a MAY) for the full header to be in the
first fragment seems unreasonable. Lars's suggestion on this reads
better.

Also, I brought up the following  in my detailed review.

Is it not also an option for the NAT64 to reassemble the incoming
packet before translating it? Two options are mentioned in the draft
already:
- "queue fragments and translate all fragments together"...presumably
fragments are still translated and transmitted one by one
- "translate each fragment as it comes"....presumably by maintaining
appropriate state from the full header

The state that has to be maintained for either of the above, and
especially if the NAT64 decides to deal with the case of the full
header arriving out of order, seems to be very similar to the state
required for packet reassembly.

This, combined, with the fact that the IPv4 and IPv6 sides of the
NAT64 might have different MTUs anyway, possibly requiring further
fragmentation after translation, reassembling before translation seems
like a reasonable option.

Has this been discussed  before?

George

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 Dec 2009 07:24:11 -0500

>From an implementor's point of view, this is too fuzzy. What exactly are
"overload conditions"? What behavior would be different from just a hard
threshold? Do you mean "put the threshold as high as you can without causing
overload"?

> I'm wondering if we should simply say "use a good sized fixed buffer that doesn't drive you into overload when full, and use an oldest-first (or LFU?) replacement scheme"?

No. That's crossing into the implementor's land. Only specify
externally-observable behavior.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 04 Dec 2009 15:30:51 +0100

> to arrive over a 10 second period, since doing so may exhaust all
Right, what about:

As long as the NAT64 has available resources, the NAT64 MUST allow the 
fragments to arrive over a time interval.
> byte order, yes?

No, it means the first packet in byte order. (so yes, it needs 
clarification)

So, i will add:

The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the first fragment (first fragment meaning the fragment that contains OFFSET equal to zero).

The reason for this is that the tiny fragments attack rely on sending 
the TCP header fragmented.

>   Since "first" is used in the other sense in the 
the goal of this is to allow to deal with tiny fragments attacks, If 
people feel we shoudl drop this, i don't have a strong preference.

> The last sentence above looks good, although it seems to contradict the
I hope with the clarification i made, there is no longer a contradiction

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 04 Dec 2009 15:34:06 +0100

> I'd add an "under overload conditions" somewhere. While not overloaded, limiting storage doesn't really serve any purpose but lowers reassembly chances.
not sure about this one, i will wait to see the output of the disucssion 
with Simon.

> Similar to the above comment: a short timeout doesn't really save you anything unless there's an overload condition. But then you'd use something else to shed load.
well, we state that there at least 10 seconds, so having the nat having 
a higher timer when it can is allowed. I will wait for the output of the 
discussion about the overload and see

> The NAT can't really require that. I think what you want to say is that NATs MAY drop fragment chains where the header is split over multiple fragments.
Right, i will change it to this.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 04 Dec 2009 15:37:29 +0100

> should be free to drop fragments if it feels threatened.
Right, this has been captured by stating that if the nat64 has the 
resoruces, then it does this...

> first fragment seems unreasonable. Lars's suggestion on this reads
done

> Has this been discussed  before?
yes, and it seems it will be discussed in the next interim meeting.
So far, i heard that this should be open for the implementers to do what 
they preffer and that is what is captured in the draft.

Regards, marcelo

---

From: Lars Eggert <[email-masked]>
Date: Fri, 4 Dec 2009 12:30:59 -1000

Hi,

> threshold? Do you mean "put the threshold as high as you can without causing

well, overload is an implementation-specific event. If you want a definition, I'd say "a state in which fragmentation handling is negatively impacting overall performance and operation."

> externally-observable behavior.

I fail to see how a 10-second timeout is any different.

Lars

---

From: Dave Thaler <[email-masked]>
Date: Sat, 5 Dec 2009 00:16:00 +0000

[...]
> fragments to arrive over a time interval.

Ok.

>          completely contained within the first fragment (first fragment
> meaning the fragment that contains OFFSET equal to zero).

Ok that answers the rest of my comments.
(So rest of discussion on this omitted)

However I'd suggest wordsmithing for brevity:
> completely contained within the fragment that contains 
> OFFSET equal to zero.

[...]
> I hope with the clarification i made, there is no longer a

Right.

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Dec 2009 14:04:12 +0100

done

thanks, marcelo