Subject: Re: [Ietf-behave] Requiring NATs to process Out-of-order fragmentedTCP packets

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 25 Mar 2005 05:51:26 -0800 (PST)

--- Spencer Dawkins <spencer@xxxxxxxxxxxxx> wrote:
> > 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 

[suresh] I am saying that the applications should be able to rely on the NAT
devices doing the fragment processing correctly. However, that is not to say
that there are no situations where the NAT device will not drop IP datagrams.
Yes, Packets may be dropped during DoS attacks. 

> applications can't always rely on MUST-strength behavior during a DOS 
> attack whether we're talking about a NAT or not.
> 
[suresh] Yes indeed.

> Did I understand your point, Suresh?
> 
[suresh] I think so. Thanks.

> Spencer 
cheers,
suresh