Re: [BEHAVE] Handling fragments in the stateful NAT64

Comments inline...

On 12/1/09 9:23 AM, "Dan Wing" <dwing@cisco.com> wrote:

>> -----Original Message-----
>> From: behave-bounces@ietf.org
>> [mailto:behave-bounces@ietf.org] 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,
>> 
>> 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.
> 
> That sentence above says "requires that a NAT64 handle fragments arriving
> 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

> 
>>    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].
> 
> RFC4963 might be useful to cite, as well.
> 
>>    Assuming it otherwise has sufficient resources, a NAT64 MUST allow
>>    the fragments to arrive over a time interval of at least
>> 10 seconds.
> 
> "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.
> 
>>    A NAT64 MAY require that the UDP, TCP, or ICMP header be completely
>>    contained within the first fragment.
> 
> -d
> 
> 
>> 
>> Let me know if you have issues witht eh current text. I hope
>> it reflects 
>> the received feedback.
>> 
>> Regards, marcelo
>> 
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave