[BEHAVE] handling packet with fragments, second try
marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 02 December 2009 09:45 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4B028C185 for <behave@core3.amsl.com>; Wed, 2 Dec 2009 01:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xofx2s4o83f9 for <behave@core3.amsl.com>; Wed, 2 Dec 2009 01:45:01 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C097528C17B for <behave@ietf.org>; Wed, 2 Dec 2009 01:45:01 -0800 (PST)
Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp03.uc3m.es (Postfix) with ESMTP id 395DB7F3F3D for <behave@ietf.org>; Wed, 2 Dec 2009 10:44:51 +0100 (CET)
Message-ID: <4B163713.8070001@it.uc3m.es>
Date: Wed, 02 Dec 2009 10:44:51 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Behave WG <behave@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003
Subject: [BEHAVE] handling packet with fragments, second try
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2009 09:45:02 -0000
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.
- [BEHAVE] handling packet with fragments, second t… marcelo bagnulo braun
- Re: [BEHAVE] handling packet with fragments, seco… Zhen Cao
- Re: [BEHAVE] handling packet with fragments, seco… Dave Thaler
- Re: [BEHAVE] handling packet with fragments, seco… Lars Eggert
- Re: [BEHAVE] handling packet with fragments, seco… George Tsirtsis
- Re: [BEHAVE] handling packet with fragments, seco… Simon Perreault
- Re: [BEHAVE] handling packet with fragments, seco… marcelo bagnulo braun
- Re: [BEHAVE] handling packet with fragments, seco… marcelo bagnulo braun
- Re: [BEHAVE] handling packet with fragments, seco… marcelo bagnulo braun
- Re: [BEHAVE] handling packet with fragments, seco… Lars Eggert
- Re: [BEHAVE] handling packet with fragments, seco… Dave Thaler
- Re: [BEHAVE] handling packet with fragments, seco… marcelo bagnulo braun