Subject: RE: [Ietf-behave] NAT behave draft

From: "Francois Audet" <[email-masked]>
Date: Tue, 10 Aug 2004 16:40:20 -0700 (PDT)

Hi Geoff,

I fully agree with your comments: the reason we said "outbound only" is based
on what we feel is the proper safe behavior for UDP.

We haven't put much tought on TCP so far, and clearly we need to add more
information on the requirements.

I don't know what current NATs "outbound" versus "inbound" behavior is for TCP.
We didn't even cover it in the first version of the draft. Certainly something to
investigate.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
> Sent: Tuesday, August 10, 2004 16:22
> To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: RE: [Ietf-behave] NAT behave draft
> 
> 
> This is good data, and is certainly worth bearing in mind, but the 
> underlying exercise is to document what the WG-to-be believes is the 
> _right_ action.
> 
> For UDP there is the issue of pinhole extension that argues 
> strongly in 
> favour of outbound-only refresh, and it appears that in 
> general NATs are 
> using this mechanism.
> 
> But for TCP its not so clear to me that an outbound only is 
> so necessary. 
> Cullen's survey was UDP-based, and I've not seen any other 
> data here. Have 
> you surveyed NAT implementations regarding the refresh time 
> trigger for 
> TCP? Do they differ from UDP?
> 
> I was quietly thinking to myself that in the case of TCP a 
> bidrectional 
> timer refresh trigger would make more sense than outbound 
> only, and I was 
> wondering if that happens in NATs today.

---

From: Harald Welte <[email-masked]>
Date: Sun, 15 Aug 2004 07:26:21 -0700 (PDT)

> I don't know what current NATs "outbound" versus "inbound" behavior is for

At least for all the linux-2.4 (netfilter/iptables) based NAT devices
out there (quite a lot, across all vendors): They do full TCP state
tracking.  

So any non-FIN/non-RST packet either inbound or outbound will update the
timeout.

In the linux 2.4/2.6 netfilter/iptables implementation, this is the case
with any layer 4 protocol.

-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
Attachment:
signature.asc

---

From: Geoff Huston <[email-masked]>
Date: Sun, 15 Aug 2004 15:27:03 -0700 (PDT)

At 12:26 AM 16/08/2004, Harald Welte wrote:
At least for all the linux-2.4 (netfilter/iptables) based NAT devices
out there (quite a lot, across all vendors): They do full TCP state
tracking.
So any non-FIN/non-RST packet either inbound or outbound will update the
timeout.
In the linux 2.4/2.6 netfilter/iptables implementation, this is the case
with any layer 4 protocol.
Does this imply that an external third party entity can keep a NAT TCP
binding open by injecting out of sequence packets into the TCP stream?
Geoff

---

From: Harald Welte <[email-masked]>
Date: Sun, 15 Aug 2004 16:14:38 -0700 (PDT)

> binding open by injecting out of sequence packets into the TCP stream?

As with default 2.4/2.6 kernels: yes.  But only until a FIN/RST teardown
is noticed.   We have numerous different timeouts in the lifetime of a
TCP session, similar to the TCP state machine at the two connection
endpoints.

netfilter/iptables NAT is closely tied to our TCP state tracking code.
In fact, the NAT transformations (source/destination/payload/...) are
stored within the 'connection tracking entry' that resembles the state
of one TCP session.

Also, we offer a patch for full tcp window tracking since about three
years.  This will finally make it in mainline linux-2.6.9.