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

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 23 Mar 2005 06:49:44 -0800 (PST)

Cullen,

DoS attacks can occur in many ways - IP fragment based attacks, ICMP attacks,
TCP SYN attacks, UDP flooding etc.. I believe, NATs SHOULD defend themselves
against trivial DoS attacks. The subject of defending against trivial DoS
attacks shoudl be discussed as a separate thread, and not be tied to IP
fragmentation support or TCP support etc. I will be happy to start a new thread
to discuss the requirement on NATs to defend against trivial DoS attacks. 

However, we should have a closure on the fragmentation support issue prior to
hopping on the DOS thread. I believe, Requiring NATs to support IP
fragmentation will be the way to close this. By doing this, apps can expect a
deterministic behavior from NATs. 
 
cheers,
suresh
--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
> 
> There are several mentions on the thread of alternatives that no client
> software can count on so they don't help much. There are also alternatives
> that have a trivial DOS attack against the NAT. If you have an alternative
> that solves this problem and does not have the trivial DOS attacks against
> the NAT, I think people would be interested in it but as far as I can tell
> from the list traffic, people don't get what that proposal is yet.
> 
> On 3/21/05 6:09 AM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:
> 
> > 
> > The alternative is to make NAT predictable and work with IP fragments
> > irrespective of the order in which the fragments arrive.
> > 
> > cheers,
> > suresh  
> > 
> > --- Francois Audet <audet@xxxxxxxxxx> wrote:
> >> 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.
> >> 
> >>> -----Original Message-----
> >>> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> >>> Cullen Jennings
> >>> Sent: Friday, March 18, 2005 17:38
> >>> To: Bryan Ford; Melinda L Shore
> >>> Cc: Behave
> >>> Subject: Re: [Ietf-behave] Requiring NATs to process
> >>> Out-of-orderfragmented TCP packets
> >>> 
> >>> 
> >>> 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
> >>> 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, 23 Mar 2005 16:47:06 -0800 (PST)

On 3/23/05 6:49 AM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:

> I believe, Requiring NATs to support IP
> fragmentation will be the way to close this.

Can you provide a concise explanation of how NATs should behave on this.
Then provide a sample of idea of one way that they might protect themselves
from the using up all the memory problem. As a pointed out in my previous
email, you keep asserting there is a solution to this problem. I am unaware
of what it is so it makes me concerned to say that everyone must do
something that I don't know how they can do it.

Cullen (not as chair)

---

From: Senthil Sivakumar <[email-masked]>
Date: Wed, 23 Mar 2005 18:30:12 -0800 (PST)

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.

Senthil

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Mar 2005 19:17:57 -0800 (PST)

At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote:
My suggestion is:

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

---

From: Kaushik Biswas <[email-masked]>
Date: Wed, 23 Mar 2005 21:05:54 -0800 (PST)

To add to this: these configurable values of N, X & Y will give attempt 
towards providing a deterministic behavior of the NAT under fragmentation.

One more observation. DOS attacks can even occur at the endpoint and one 
can argue that reachability to this endpoint is not deterministic (or 
guaranteed) even when there is no NAT in picture.

Kaushik

At 06:30 PM 3/23/2005 -0800, Senthil Sivakumar wrote:
My suggestion is:

---

From: Dan Wing <[email-masked]>
Date: Thu, 24 Mar 2005 13:09:26 -0800 (PST)

On Mar 23, 2005, at 7:17 PM, Paul Hoffman wrote:

"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.
If you receive a fragment, you don't know which flow it belongs to 
because a fragment only contains the source and destination IP 
addresses, but you need the full 5-tuple (src/dest IP, protocol, 
src/dest port) to know the flow associated with a fragment.  You can't 
identify the "flow" - you can only identify the source IP address that 
(purportedly) sent you the fragment.

There are lots of ways a vendor could provide for protection while 
trying to avoid interfering with a valid flow, and the vendor might 
have cool techniques to do so.  How about instead of your last two 
sentences we just say:

    A NAT SHOULD allow out-of-order fragment behavior to
    be adjusted by the administrator, such as the number,
    duration, or source IP address of fragments kept by
    the NAT or a combination of these parameters.
We need to explain if it's important for the NAT to reassemble the 
packets before sending to the internal host; that's missing from your 
proposed text.

What do we want to say about overlapping IP fragments?

-d

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Mar 2005 13:14:46 -0800 (PST)

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.

---

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

At 1:09 PM -0800 3/24/05, Dan Wing wrote:
There are lots of ways a vendor could provide for protection while 
trying to avoid interfering with a valid flow, and the vendor might 
have cool techniques to do so.  How about instead of your last two 
sentences we just say:

Sounds fine.

We need to explain if it's important for the NAT to reassemble the 
packets before sending to the internal host; that's missing from 
your proposed text.
It's missing because I don't particularly believe it. To the internal 
host, the NAT looks like the upstream router. Routers don't normally 
reassemble packets, do they?

What do we want to say about overlapping IP fragments?
If by "overlapping IP fragments" you mean multiple fragmented flows, 
why should we say anything in particular about them.

--Paul Hoffman, Director
--VPN Consortium

---

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

At 1:14 PM -0800 3/24/05, Cullen Jennings wrote:
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.
It doesn't, but it doesn't need to. The WG charter says "This working 
group proposes to generate requirements documents and best current 
practices to enable NATs to function in as deterministic a fashion as 
possible." It also says "The behavior that will be considered 
includes IP fragmentation...". Having IP fragmentation work in as 
deterministic a fashion as possible fits squarely into the charter, 
yes?

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan Wing <[email-masked]>
Date: Fri, 25 Mar 2005 08:48:02 -0800 (PST)

On Mar 24, 2005, at 1:48 PM, Paul Hoffman wrote:

We need to explain if it's important for the NAT to reassemble the 
packets before sending to the internal host; that's missing from your 
proposed text.
It's missing because I don't particularly believe it. To the internal 
host, the NAT looks like the upstream router. Routers don't normally 
reassemble packets, do they?
Correct, they don't.  However, routers don't hold onto packets, either, 
which is what we're asking the NAT to do with out-of-order packets.  
See below, because my question about reassembly is related to my 
question about overlapping fragments.

What do we want to say about overlapping IP fragments?
If by "overlapping IP fragments" you mean multiple fragmented flows, 
why should we say anything in particular about them.
No, I mean overlapping IP fragments.  For example, if I receive two 
fragments like this:

  src=1.2.3.4, dest=4.5.6.7, offset=100, length=200
  src=1.2.3.4, dest=4.5.6.7, offset=150, length=200
notice that the lengths and offsets overlap.  Should the NAT allow the 
second one to overlap the first, or discard the whole set of them, or 
should it store each of them separately and let the host handle the 
overlap (and retain the exact order they were received from the 
network), or what.  I ask this because it happens with unacknowledged 
TCP segments in normal operation, but can happen with IP fragments in 
certain crafted attacks and we may want to say something about it.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Mar 2005 07:07:56 -0800 (PST)

Now, have no problem saying that a device MAY store out of order fragments.
However, I will be very against any text which implies that an application
can depend on them doing this because clearly we can't depend on it in a
wide variety of cases. Because of this, saying MUST does not help any
developers and just means that less NATs will be behave compliant with no
real gain. This is an all round loose in my mind.

So let me sketch a counter proposal ....

We say that devices MUST forward fragments that arrive in order.

We say that device MAY forward packets out of order and describe how if they
do this they may want to limit the number of stored packets per session and
how long they store them.

Cullen (not as chair)

PS. We need clear requirements that help residential style NATs. No
administrator adjustment are likely to happen on these.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 26 Mar 2005 11:34:57 -0800 (PST)

My confusion is rising slightly :-)

Now, have no problem saying that a device MAY store out of order 
fragments.
However, I will be very against any text which implies that an 
application
can depend on them doing this because clearly we can't depend on it 
in a
wide variety of cases. Because of this, saying MUST does not help 
any
developers and just means that less NATs will be behave compliant 
with no
real gain. This is an all round loose in my mind.

This would be lovely.

We say that device MAY forward packets out of order and describe how 
if they
do this they may want to limit the number of stored packets per 
session and
how long they store them.
I thought we were discussing whether this should be a MUST or a SHOULD 
(hence my confusion).

Is the point that there are enough ways that something can go wrong 
that an application couldn't count on out-of-order fragments being 
forwarded anyway?

If this IS the case, we should be headed towards advising applications 
that care about packet delivery to turn on DF, because sudden fragment 
reordering MAY cause a fragmented stream of packets to disappear in a 
puff of smoke.

Not that P-MTU discovery works particularly well in the open Internet, 
but if you are persistent, you can probe for common MTU sizes until 
something works.

Cullen (not as chair)

PS. We need clear requirements that help residential style NATs. No
administrator adjustment are likely to happen on these.
It is interesting to conjure about the expected service life of 
residential NATs/DSL modems/cable modems...