Subject: RE: [Ietf-behave] Requiring NATs to process Out-of-orderfragmente d TCP packets

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Mar 2005 16:23:51 -0800 (PST)

Exactly. This is something for the Application
document.

I really don't see the "big NAT/router vendors" changing
the current practice on fragments, with all the
security holes it has created.

It may be different for a small residential NAT.

In either case, it is something the applications
have to be able to deal with.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Cullen Jennings
> Sent: Wednesday, March 16, 2005 16:17
> To: Senthil Sivakumar
> Cc: Mark Allman; Behave
> Subject: Re: [Ietf-behave] Requiring NATs to process 
> Out-of-orderfragmented TCP packets
> 
> 
> 
> Sounds like we are saying about the same thing. If the amount 
> of memory is set to 0 then one thing happens, if it is set 
> above that, then something else happens. I think the end 
> story for the applications is going to be they can't make 
> assumptions about what will happen to out of order fragments.
> 
> 
> On 3/16/05 2:42 PM, "Senthil Sivakumar" <ssenthil@xxxxxxxxx> wrote:
> 
> > At 05:09 PM 3/15/2005 -0800, Cullen Jennings 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. This would 
> be exactly 
> >> the sort of non deterministic behavior that we are trying to stop.
> > 
> > Conversely, if you don't recommend NATs to process out of order 
> > fragments, some NATs will store the fragments until the 
> first fragment 
> > is received, some might drop them,  some might just forward 
> them (if 
> > they can). This causes non-deterministic
> > behavior as well.
> > 
> > Now the solution for preventing NATs from DoS attacks could be that 
> > there is a threshold for the number of fragments that can be queued 
> > and the time it can be queued. I believe
> > these thresholds will vary based on the memory, CPU and 
> network latency.
> > 
> > Senthil
> > 
> > 
> >> 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
> >> _______________________________________________
> >> 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: "Francois Audet" <[email-masked]>
Date: Sat, 19 Mar 2005 12:56:22 -0800 (PST)

Agree.

Those are operational nightmares. I'd rather it just plain doesn't
work and you have to buy a new NAT. It's a lot cheaper
than paying people to figure out why it fails
unpredictably.

> Sent: Friday, March 18, 2005 17:38
> To: Bryan Ford; Melinda L Shore
> Cc: Behave
> On 3/17/05 7:18 AM, "Bryan Ford" <baford@xxxxxxx> wrote:
> 
> >>> 1. NATs MUST at the very minimum be able to handle a 
> datagram whose 
> >>> fragments appear in an arbitrary order on the wire but "all 
> >>> together", not intermixed
> >>> with fragments of other datagrams.
> 
> This sounds like a very contrived sort of scenario - image I 
> had a application that worked when it was the only 
> applications, but then periodically failed when other 
> applications where behind the same NAT. This does not sound 
> like a good situation.
> 
> I'm not really in agreement with requirements that make NATs 
> do something that helps some of the time but don't solve any 
> problem for the application a bunch of the time.
> 
> Cullen (not as chair) _______________________________________________
> Ietf-behave mailing list

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 17 Apr 2005 07:55:50 -0700 (PDT)

--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
> On 3/24/05 6:41 PM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:
> 
> > --- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
> >> 
> >> Ok, that proposal is concrete and I get it. Thank you.
> >> 
> >> Now the application developer that is trying to write a client that will
> >> work through a NAT that does this can not make any assumptions about how
> the
> >> NAT has been configured. So I don't see how behave specifying this one way
> >> or another makes any difference to what applications can work or not.
> >> 
> > 
> > [suresh] When applications send large chunks of data with no reverence to
> MTU
> > size, the NAT devices along the traversal will not block the fragments from
> > traversing. For example, aplication like NFS can work across a NAT device.
> > 
> > cheers,
> > suresh
> 
> What size packets can the application send before it stops working because
> the flow has exceeded the buffer allocated by the NAT for that flow? Of
> course it is impossible to answer this question which is exactly my point.
> Specifying this type of behavior, while reasonable and good, will not in
> anyway help design algorithms that reliably work through NATs that have to
> operate in the real world. Not knowing the size of buffers on a configured
> NAT simply contributes to the non deterministic behavior of the NAT. I'm not
> against implementations deciding to do the type of behavior you suggested -
> I'm just pointing out that applications can not rely on the buffer size be
> anything greater than zero.
> 
[suresh] The buffer size is configurable. The default read/write buffer size
for nfsv2 is 8192 bytes. NFS/UDP relies on IP fragmentation support in the
network, NAT or not.

> Cullen - not as chair

cheers,
suresh