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

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 27 Mar 2005 10:38:57 -0800 (PST)

Dan,

You raise several good points. Please see my comments inline below.

cheers,
suresh
 
--- Dan Wing <dwing@xxxxxxxxx> wrote:
> On Mar 23, 2005, at 7:17 PM, Paul Hoffman wrote:
> 
> > At 6:30 PM -0800 3/23/05, Senthil Sivakumar wrote:
> >> 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.
> >
> > 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.
> 

[suresh] Why do you believe, this is a SHOULD and not a MUST? When this is a
SHOULD, there is no guarantee that the behave compliant NATs would support 
fragments. Apps that use fragments (including several VPN tunnels) cannot count
on the intermediate NATs to support fragmented IP datagrams. I donot
understand, why we would want to make this a SHOULD. 

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

[suresh] Yup, I agree. The NAT device 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. Fragment reassembly is a
way to retain the assemby state. But, there may be alternatives. That is why
the text I  suggested above avoids suggesting "reassembly" as the only means.

> What do we want to say about overlapping IP fragments?
> 
[suresh] You do raise a good point with overlapping IP fragments in the case of
NAPT implementations. After all, IP datagrams are disntiguished from each other
by the tuple of (SrcIP, DestIp, Protocol, PktId). When datagrames from multiple
source IP addresses directed to the same external dest address are translated
into a single IP address (as with NAPT) , there is a possibility of pktId
overlap when multiple private hosts endup using the same pkt ID. Many NAPT
implementations do not deal well with overlaping IP pkt IDs during fragment
processing. As an FYI, this shortcoming is identified in section 6.3 of RFC
3022. 

Any thoughts from the list on whether we should make a recommendation on how
NAPTs should deal with overlapping fragment IDs? 

> -d

cheers,
suresh

---

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

On Mar 27, 2005, at 10:38 AM, Pyda Srisuresh 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:
     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.
[suresh] Why do you believe, this is a SHOULD and not a MUST? When 
this is a
SHOULD, there is no guarantee that the behave compliant NATs would 
support
fragments. Apps that use fragments (including several VPN tunnels) 
cannot count
on the intermediate NATs to support fragmented IP datagrams. I donot
understand, why we would want to make this a SHOULD.
My suggested text only discusses the administrator's ability to adjust 
the behavior.  I don't see an interoperability requirement to require 
the administrator to adjust the out-of-order behavior.

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.
[suresh] Yup, I agree. The NAT device 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. Fragment 
reassembly is a
way to retain the assemby state. But, there may be alternatives. That 
is why
the text I  suggested above avoids suggesting "reassembly" as the only 
means.

[suresh] You do raise a good point with overlapping IP fragments in 
the case of
NAPT implementations. After all, IP datagrams are disntiguished from 
each other
by the tuple of (SrcIP, DestIp, Protocol, PktId). When datagrames from 
multiple
source IP addresses directed to the same external dest address are 
translated
into a single IP address (as with NAPT) , there is a possibility of 
pktId
overlap when multiple private hosts endup using the same pkt ID. Many 
NAPT
implementations do not deal well with overlaping IP pkt IDs during 
fragment
processing. As an FYI, this shortcoming is identified in section 6.3 
of RFC
3022.
Sorry, I hadn't even considered Fragment ID overlap.  I was only 
considering a defective IP stack sending fragments, or an attacker 
sending fragments, which have their fragmentation offsets overlap.

Reading section 6.3 of RFC3022, this same problem with overlapping 
fragment IDs from different flows is experienced by host IP stacks.  
Have you looked at Linux or FreeBSD sources to see what they do around 
identical fragment IDs?

Any thoughts from the list on whether we should make a recommendation 
on how
NAPTs should deal with overlapping fragment IDs?
-d

-d
cheers,
suresh