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

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 16 Mar 2005 07:53:18 -0800 (PST)

Cullen,

I think, there are two parts to this. 

First, the processing of IP fragments (In-order or out-of-order). Should NATs
support IP fragments?
Second, the processing of out-of-order IP fragments. Should, NATs support
out-of-order IP fragments?

I believe, IP fragment support is a MUST because this is a fundamental aspect
of IP, and NATs providing transparancy to IP should support transparant
traversal of IP fragments. Once IP fragment traversal is supported, the memory
issues remain the same no matter whether frgaments come in order or out of
order. So, I believe, the answer is YES to both.

Please see my responses inline.

cheers,
suresh
 
--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
> 
> Not as chair 
> 
> I look forward to getting the TCP folks input on this but I believe one of
> the issues in trying to say that devices should process out of order packets
> is what to do about the DOS attacks this creates if lots of out of order
> packets are sent. 
> 
> Right now I don't see how we could recommend that a NAT process out of order
> packets because we would need to say that if you got lots of them, then the
> NAT would need to stop doing the out of order processing or else it would
> run out of memory. 

[suresh] Yes, there can be lots of frgaments - no matter whether they came in
order of out of order. Are you saying, NATs should not support IP fragments at
all?

As for memory requirements, a NAT perhaps needs to set aside a percentage of
in-flight packet buffers for fragment reassembly. When NAT runs out of memory,
it will drop unassembled fragments. Else, it will forward the assembled
packets. Why is this a problem? NATs have to do this to fight various types of
DoS attacks.

>                    This would be exactly the sort of non deterministic
> behavior that we are trying to stop.
> 
[suresh] I disagree. Packets are often dropped in the network for various
reasons - such as devices not having receive buffers at a certain bursty
instance. But, IP is resilient to deal with this type of occasional
non-deterministic behavior (i.e., packet drops). Packets will be dropped with
or without IP fragment support on a NAT under some bursty instances or DoS
scenarios. 

cheers,
suresh

> Cullen
> 
> 
> On 3/7/05 5:57 PM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:
> 
> > 
> > --- Spencer Dawkins <spencer@xxxxxxxxxxxxx> wrote:
> >> My understanding from this morning's meeting was that we were leaning
> >> toward not requiring Behave-conformant NATs to process out-of-order
> >> TCP fragments, with the expectation that endpoints would be doing Path
> >> MTU discovery anyway, so fragmentation shouldn't be an issue.
> >> 
> > [suresh] If you are talking about processing out of order IP fragments in
> > general, I believe, the chairs said we would take this to the list. If NATs
> do
> > not handle IP fragments correctly, it is a major problem for applications
> that
> > use IP fragments (ex: NFS over UDP). I believe, this is a MUST for NATs.
> > 
> > regards,
> > suresh
> > 
> >> I ran into Mark Allman this afternoon and asked him if he had an
> >> opinion on the robustness of Path MTU discovery on the Internet. He
> >> does, and has recently co-authored a paper that discusses this
> >> (available at http://www.icir.org/mallman/papers/tcp-evo-submit2.ps).
> >> In section 4.3 of the paper, he's seeing that about one-third of the
> >> 85,000 servers identified by the NLANR Web Caching project don't
> >> attempt Path MTU discovery at all, and another 17 percent attempt it
> >> and fail. The failure rate is even higher for a list of 500 popular
> >> web server (35%).
> >> 
> >> So I'm wondering if we need to think about this a little more?
> >> 
> >> Spencer
> >> 
> >> p.s. I copied Mark, just in case I'm misunderstanding the paper...
> >> 
> >> 
> >> _______________________________________________
> >> 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: Cullen Jennings <[email-masked]>
Date: Wed, 16 Mar 2005 11:23:31 -0800 (PST)

inline (not as chair)

> out-of-order IP fragments?
agree on these two questions

> traversal of IP fragments.
ok - perhaps 

> Once IP fragment traversal is supported, the memory
not sure I agree on your logic that only way to forward in order fragments
is to store and reassemble them. If the fragments arrive in order, you can
save the port forward state for the flow when the first one arrives then
forward each fragment as it arrives without storing any of the fragments. I
think there are NATs today that have implemented this both ways. For the
NATs that do reassemble out of order packets, clearly they can only do this
with a limited number - so the question is can an endpoint rely on that
behavior.

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 16 Mar 2005 22:51:01 -0800 (PST)

> with a limited number - so the question is can an endpoint rely on that
[suresh] Cullen - You do bring up a clever way in which NATs do not have to
reassemble the fragments when they come in order. But, what sort of determinism
does in-order-fragment support alone provide to the apps? Apps have no way to
know how the underlying stack orders the fragments. Some send in order and some
send out of order. Worse yet, apps certainly have no control over the network
that can also reorder the fragments. It woudlnt be right for the apps to say
they wont work on the hosts and networks that will order fragments out of
sequence. So, the only logical conslusion woudl be for the apps to assume no
fragment support in the network that involves NAT traversal. That would be BAD.

As for memory constraints, there are several things in a NAT box that memory
constraints could make it non-deterministics. NAT box could be short of packet
buffers to process packets at line rate and drop packets. NAT box could be
short of memory to process large number of NAT sessions as well, and so on...
where do you draw the line on nonpdeterministic behavior from memory
constraints.  

cheers,
suresh