Subject: [BEHAVE] Handling fragments in the stateful NAT64

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Dec 2009 10:41:36 +0100

Hi,

after the discussion in hiroshima, I have updated the draft.
The current 03 version reads:

   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 a NAT64 handle fragments arriving out-of-order.
   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.

   Implementors of NAT64 should be aware that there are a number of
   well-known attacks against IP fragmentation; see [RFC1858] and
   [RFC3128].

   Assuming it otherwise has sufficient resources, a NAT64 MUST allow
   the fragments to arrive over a time interval of at least 10 seconds.
   A NAT64 MAY require that the UDP, TCP, or ICMP header be completely
   contained within the first fragment.

Let me know if you have issues witht eh current text. I hope it reflects 
the received feedback.

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 09:23:58 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Tuesday, December 01, 2009 1:42 AM
> To: Behave WG
> Subject: [BEHAVE] Handling fragments in the stateful NAT64
> 
> Hi,
> 

That sentence above says "requires that a NAT64 handle fragments arriving
out-of-order", yet ... (see "A", below)

>    well-known attacks against IP fragmentation; see [RFC1858] and

RFC4963 might be useful to cite, as well.

>    the fragments to arrive over a time interval of at least 

"A":  The sentence below does *not* require the NAT64 to handle out-of-
order fragments.  The sentence below contains a RFC2119 keyword, so
I guess it is normative and overrides the non-RFC2119 sentence above,
but it would be better if the descriptive text above matched the 
RFC2119 keyworded sentence below.  Or remove one or the other.

>    contained within the first fragment.

-d

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 1 Dec 2009 12:43:51 -0500

Comments inline...

> out-of-order", yet ... (see "A", below)

I agree with what was stated by Dan (If I understand it properly).  After
the first paragraph above (which pretty much leaves the mechanism open),
using normative text in other paragraphs is confusing and might lead to
interpretation issues.

On the other hand, if you NAT64 needs to handle out of order fragments
through whatever mechanism (as stated in the first paragraph), then that's
where you need to use normative text such as the one in RFC487.

Something like from 4787

"   REQ-14:  A NAT MUST support receiving in-order and out-of-order
      fragments, so it MUST have "Received Fragment Out of Order"
      behavior.

      a) A NAT's out-of-order fragment processing mechanism MUST be
         designed so that fragmentation-based DoS attacks do not
         compromise the NAT's ability to process in-order and
         unfragmented IP packets.
"

Thanks,

Reinaldo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 1 Dec 2009 18:50:53 +0100

>  the fragments to arrive over a time interval of at least 10 seconds.

The first clause makes the requirement meaningless. Someone could always claim lack of resources.

Also, is this 10 seconds between all fragments (so 30 seconds in the case of 4 fragments) or 10 seconds from the first fragment to arrive until the last?

I'm not very happy about the 10 seconds, in practice all fragments will arrive within a few hundred milliseconds. But I guess if we assume a worst case network speed of 8 kbps (really slow GPRS link) and packet size (64k) then it can take more than a minute for all fragments to arrive...

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 1 Dec 2009 13:20:18 -0500

I agree that 10 seconds in Internet today is a long time for fragments to
arrive. Should we optimize for the common case or the worst case?

Although there will always be exceptions as mention by Iljitschv, providers
should be allowed to optimize for the their common case. So, I would suggest
to include text to say that the the interval MAY be configurable.

Thanks,

Reinaldo

On 12/1/09 9:50 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> Also, is this 10 seconds between all fragments (so 30 seconds in the case of 4
> fragments) or 10 seconds from the first fragment to arrive until the last?
> 
> I'm not very happy about the 10 seconds, in practice all fragments will arrive
> within a few hundred milliseconds. But I guess if we assume a worst case
> network speed of 8 kbps (really slow GPRS link) and packet size (64k) then it
> can take more than a minute for all fragments to arrive...