[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.