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

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 24 Mar 2005 19:02:02 -0800 (PST)

Francois,

I believe, the requirement is a MUST, not a SHOULD. The second parapgraph is
not written to dilute the first into a SHOULD.

The second paragraph indicates that there can be resource limits in a NAT
device that might not permit the NAT device to retain state forever. For
example, one of the fragments could have been lost in the network  and may
never arrive. So, NAT device would not want to hold the reassemply state
forever. There may be also be situations where the device is unable to create a
state for a certain datagram when it is out of memory resource. Essentialy,
these reflect the operational aspects in real-time, but does not change the
requirement in the first paragraph.

cheers,
suresh

--- Francois Audet <audet@xxxxxxxxxx> wrote:
> 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
> > 
> > 
> > _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 25 Mar 2005 03:19:17 -0800 (PST)

I believe, the requirement is a MUST, not a SHOULD. The second 
parapgraph is
not written to dilute the first into a SHOULD.

The second paragraph indicates that there can be resource limits in 
a NAT
device that might not permit the NAT device to retain state forever. 
For
example, one of the fragments could have been lost in the network 
and may
never arrive. So, NAT device would not want to hold the reassemply 
state
forever. There may be also be situations where the device is unable 
to create a
state for a certain datagram when it is out of memory resource. 
Essentialy,
these reflect the operational aspects in real-time, but does not 
change the
requirement in the first paragraph.
This is actually the way I read Suresh's previous e-mail - NATs MUST 
do this, if they do anything, but a NAT that has crashed (for example) 
is allowed to treat this as a SHOULD, since no device that has crashed 
will be doing anything of the sort :-)

What I think the proposal is saying is that applications can rely on 
this behavior unless the NAT is is being DOS-attacked, and 
applications can't always rely on MUST-strength behavior during a DOS 
attack whether we're talking about a NAT or not.

Did I understand your point, Suresh?

Spencer