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

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 28 Mar 2005 08:24:35 -0800 (PST)

--- Dan Wing <dwing@xxxxxxxxx> wrote:
> We're both describing a slightly different problem with IP fragments. 

[suresh] Ah, I see.
 
> 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.
> 
[suresh] I dont see  any confusion for the NAT in sortign out the
sequence/assembly of the incoming fragments, because the the tuples of (SrcIP,
DestIP, PktId, Protocol) are different for these packets. 

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

[suresh] I see.
> 
> I think both problems with IP fragments are worth describing in an I-D.
> 

[suresh] Sounds good.

cheers,
suresh

> -d
> 
> 
> On Mar 27, 2005, at 11:36 AM, Pyda Srisuresh wrote:
> 
> >
> > --- 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 08:40:25 -0800 (PST)

On Mar 28, 2005, at 8:24 AM, Pyda Srisuresh wrote:

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.
[suresh] I dont see  any confusion for the NAT in sortign out the
sequence/assembly of the incoming fragments, because the the tuples of 
(SrcIP,
DestIP, PktId, Protocol) are different for these packets.
Sure, but the DestIP is the same (it's the IP address of the NAT), and 
we're
assuming the Fragment ID and Protocol are the same.  So the only thing 
that
could be different in the two fragments is the SrcIP.  But if the sender
is transmitting two UDP streams, both of which are being fragmented by
the time our NAT is receiving the two streams, I see how a NAT (or a 
host)
could get confused.  I'll dig up some FreeBSD sources and see how 
FreeBSD
handles this, because I don't understand how it could do this well.

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

[suresh] Sounds good.

cheers,
suresh
-d

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.

-d

cheers,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 28 Mar 2005 09:41:27 -0800 (PST)

> handles this, because I don't understand how it could do this well.

[suresh] Dan - Essentially my point is that there is no issue in NAPT
assembling fragments coming from multiple private hosts even if directed to the
same external destination, because tuple of (SrcIP, DestIp, Prot, PktId) are
different for these IP pkts in the private realm.

Now, if you talk about IP datagrams coming in from an external server to the
NAPT external IP address, Once again, I dont see why the NAPT shoudl get
confused. Even if the same external node is sending multiple UDP streams to the
NAPT external address, the individual IP datagrams should have a unique tuple
of (SrcIP, DestIP, Protocol, PktId).

cheers,
suresh

---

From: nagendra modadugu <[email-masked]>
Date: Mon, 28 Mar 2005 22:17:27 -0800 (PST)

> handles this, because I don't understand how it could do this well.

The problem of the IP ID field colliding appears a bit contrived--especially
when packets are originating from one host (barring, of course, a buggy IP 
stack).
Or are there other circumstances under which this is a issue worth 
consideration?  
If it does somehow happen, then there's no further information the recipient 
has 
in order to distinguish the fragments as belonging to two seperate IP packets, 
or 
is there?

nagendra