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

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 27 Mar 2005 11:36:14 -0800 (PST)

--- Dan Wing <dwing@xxxxxxxxx> wrote:
> 
> 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.
> 

[suresh] You are abolutely right. The NAT device is not a regular router.
Regular routers donot route between address realms. Unlike the regular routers,
NATs do and NATs are also stateful. NATs must retain the assembly state
pertaining to a fragmentation ID until all fragments of the IP datagram are
processed. Only then is NAT able to process all fragments pertaining to an IP
datagram using the same NAT Session the IP datagram belongs to. 

The packetId overlap on the outbound pkts outfrom NAPT is an issue in two
cases. a) when NAPT fragments them on the way out, or b) when an intermediate
node between NAPT and external server fragments thackets on the way out.  The
receiving node is confused when assembling pakcets from overlapped pkt Ids.  

> >> 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.
> 

[suresh] Yup. Ideally speaking, NAPTs ought to further translate all outgoing
PktIDs from itself so the tuple of (SrcIP, DestIp, Protocol, PktId) for all
outgoing packets is unique and distinguishable across packets coming out of the
NAPT device. This will ensure there is no pktID overlap issue for the external
servers. I am in favor making this pktID non-overlap requirement a SHOULD.  

> -d

cheers,
suresh

---

From: Dan Wing <[email-masked]>
Date: Mon, 28 Mar 2005 06:38:17 -0800 (PST)

We're both describing a slightly different problem with IP fragments.  
You're describing a problem where an IP packet is fragmented (in the 
network, or by the sending host) into several fragments and when it 
arrives at the NAT there are already identical fragment IDs from 
another IP packet that arrived earlier, which could confuse the NAT if 
it's only using the fragment ID to reassemble the IP fragments.

I'm describing a problem where a defective IP stack in a 
host/router/NAT sends an IP packet as fragmented IP packets, and those 
fragments have overlapping payload segments.  I expect you'd see this 
only with a really buggy IP stack, or in certain kinds of attacks.

I think both problems with IP fragments are worth describing in an I-D.

-d

On Mar 27, 2005, at 11:36 AM, Pyda Srisuresh 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.

[suresh] You are abolutely right. The NAT device is not a regular 
router.
Regular routers donot route between address realms. Unlike the regular 
routers,
NATs do and NATs are also stateful. NATs must retain the assembly state
pertaining to a fragmentation ID until all fragments of the IP 
datagram are
processed. Only then is NAT able to process all fragments pertaining 
to an IP
datagram using the same NAT Session the IP datagram belongs to.

The packetId overlap on the outbound pkts outfrom NAPT is an issue in 
two
cases. a) when NAPT fragments them on the way out, or b) when an 
intermediate
node between NAPT and external server fragments thackets on the way 
out.  The
receiving node is confused when assembling pakcets from overlapped pkt 
Ids.

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.
[suresh] Yup. Ideally speaking, NAPTs ought to further translate all 
outgoing
PktIDs from itself so the tuple of (SrcIP, DestIp, Protocol, PktId) 
for all
outgoing packets is unique and distinguishable across packets coming 
out of the
NAPT device. This will ensure there is no pktID overlap issue for the 
external
servers. I am in favor making this pktID non-overlap requirement a 
SHOULD.

-d

cheers,
suresh