Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-order fragment edTCP packets

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Mar 2005 09:57:15 -0800 (PST)

The MUST in the first paragraph is contradicted by the second
paragraph which implies it should be a SHOULD.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Pyda Srisuresh
> Sent: Thursday, March 24, 2005 08:40
> To: Behave
> Subject: Re: [Ietf-behave] Requiring NATs to process 
> Out-of-order fragmentedTCP packets
> 
> 
> 
> Here is what I would sugegst.
> 
> A NAT device MUST be capable of processing all fragments of 
> an inbound IP datagram. These fragments cannot be assumed to 
> arrive in order. The NAT device must retain the assembly 
> state pertaining to a fragmentation ID until all fragments of 
> the IP datagram are processed. By doing this, NAT is able to 
> process all fragments pertaining to an IP datagram using the 
> same NAT Session the IP datagram belongs to. 
> 
> As with any stateful processing, there may be exceptions and 
> limitations on how long a state can be retained and how many 
> simultaneous states a NAT device  can retain at once. Thsi 
> depends on the design and memory limitations of a NAT 
> device and is not within the scope of this document.
> 
> cheers,
> suresh
> 
> 
> --- Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:
> > At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote:
> > >My suggestion is:
> > >
> > >"NATs should handle IP fragments that are seen in order and out of 
> > >order. When an in order fragment is seen NAT should store the L4 
> > >information of the first fragment so that it can match the 
> subsequent 
> > >fragments that do not carry L4 headers. No buffering of 
> the fragments 
> > >is required in case of in order fragments. For out of order 
> > >fragments, NAT must store the fragment until the first fragment is 
> > >seen. The fragments should be stored for a period of N 
> seconds before 
> > >discarding them. NATs must not store more than X fragments 
> per flow 
> > >and must not store more than fragments for Y flows at any point of 
> > >time"
> > >
> > >The values of N, X and Y are to be determined by the network 
> > >administrator who best knows the latency of his/her network, 
> > >capability of the box.
> > 
> > Given the definition of SHOULD from RFC 2119 (which is normatively
> > referenced in the drafts), a different wording might be:
> > 
> > NATs SHOULD handle IP fragments that are seen in order and out of 
> > order. When an in order fragment is seen, a NAT SHOULD store the L4 
> > information of the first fragment so that it can match the 
> subsequent 
> > fragments that do not carry L4 headers. No buffering of the 
> fragments 
> > is required in case of in order fragments. For out of order 
> fragments, 
> > a NAT SHOULD store the fragment until the first fragment is 
> seen. The 
> > fragments SHOULD be stored for an administrator-assigned period of 
> > time before discarding them. A NATs SHOULD allow the 
> administrator to 
> > assign the number fragments to be stored per flow, and SHOULD allow 
> > the administrator to assign the number of total fragmented 
> flows being 
> > held.
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Mar 2005 10:41:24 -0800 (PST)

At 12:56 PM -0500 3/24/05, Francois Audet wrote:
The MUST in the first paragraph is contradicted by the second
paragraph which implies it should be a SHOULD.
Agree.

--Paul Hoffman, Director
--VPN Consortium