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

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Aug 2004 11:01:48 -0700 (PDT)

If the "full TCP window tracking" option is used, does this mean
that the vulnerability that an external third party can keep a NAT
TCP binding open goes away?

Any recommendation on what the draft *should* say for TCP?

> -----Original Message-----
> From: Harald Welte [mailto:laforge@xxxxxxxxxxxxx] 
> Sent: Sunday, August 15, 2004 16:15
> To: Geoff Huston
> Cc: Audet, Francois [SC100:9T51:EXCH]; 
> 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: Re: [Ietf-behave] NAT behave draft
> 
> 
> On Mon, Aug 16, 2004 at 08:03:34AM +1000, Geoff Huston 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?
> 
> 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.
> 
> > Geoff
> 
> -- 
> - 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
>

---

From: Harald Welte <[email-masked]>
Date: Mon, 16 Aug 2004 11:32:36 -0700 (PDT)

> TCP binding open goes away?

There is no 'vulnerability' what so ever in the TCP case.  A fully
established TCP session has a timeout of five days.  If somebody wants
to spoof packets into this TCP session, the five day timeout will be
refreshed, but hey, then it's six days instead of five.  This _only_
works as long as the real endpoints did not start a connection teardown
(RST / FIN) in some way.  If yes, the timeout is reduced and cannot be
refreshed by any further spoofed packets.

So in our implementation the 'vulnerability' with regard to inbound
packets exists only in the UDP case.

> Any recommendation on what the draft *should* say for TCP?

I would say a draft on NAT behave should not try to require NAT devices
to provide security features.  Let it up to the implementors and users.
It should require behaviour to enable higher level protocols and
applications, but not require some kind of security.  On the other hand,
it should not require implementors to make the devices insecure, to ;)

As I see it, whether or not inbound packets will refresh the nat binding
(in addition to the required outbound packets) does not affect the
functionality of any application on a higher level.  I cannot see how
this would negatively effect any SIP/STUN/... operation.

So from my point of view, the draft should require oubound packets to
refresh the NAT binding (since it is important for functionality), but
only give recommendations on inbound packets. 

-- 
- 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: "Dan Wing" <[email-masked]>
Date: Mon, 16 Aug 2004 18:07:14 -0700 (PDT)

> this would negatively effect any SIP/STUN/... operation.

Then let me provide two examples:  

1. Your VoIP phone implements VAD, you're on mute, and dialed your bank.
   Your bank has placed you into a queue and is playing 1 minute of
   music-on-hold followed by a "please wait, calls will be answered in
   the order received" message.

   We could argue about how SIP would Do This Differently, but if your 
   VoIP phone dialed a PSTN number, the only RTP traffic will be 
   incoming.

2. you're receiving multicast audio or multicast video.

> only give recommendations on inbound packets. 

I'm feeling we're going to need a companion BEHAVE document for how
voice over IP and video over IP endpoints need to behave in face of 
a BEHAVE-compliant NAT.  For example, in case (1), above, we might
need to require the VoIP endpoints leak occasional RTP traffic (or
STUN traffic?), such as Silence Suppression packets or RTP No-Op
packets.  By having a companion document for VoIP endpoint behavior,
we may be able to reduce, as much as possible, having BEHAVE specify
things that are too complex or too hard to achieve consensus on,
such as if incoming UDP packets should keep a binding alive.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Aug 2004 21:37:01 -0700 (PDT)

> it should not require implementors to make the devices insecure, to ;)

Completely agree. We really don't want to try and specify firewalls here
other than the trivial stuff we have to talk about to describe the NAT
behavior.

---

From: Harald Welte <[email-masked]>
Date: Wed, 18 Aug 2004 14:12:07 -0700 (PDT)

On Mon, Aug 16, 2004 at 06:07:10PM -0700, Dan Wing wrote:
> [...]

Sorry, again I'm fighting with my own wording.

Given the current draft's spirit that only outbound packets should
refresh the NAT binding, I see no way how a NAT implementation that also
refreshes for inbound packets could break anything (that wasn't already
broken by the draft's requirement).

So independent of the (important) policy question whether inbound or
bidirectional packets should refresh (which I'm not even trying to
answer):  If the draft is in favour of incoming-only as requirement, it
should leave bidirectional as a possibility to the implementor.

> a BEHAVE-compliant NAT.  

Sounds reasonable to me.

Maybe accompany it by another draft on terminology?  I really dislike
the cofusion mostly caused by equipment vendors calling their devices
'access routers' if they really are fully-fledged NAT/NAPT + Stateful Packet
Filter devices.. 

NAT
NAPT
Masquerading
Firewall
Packet filter
Stateful Packet Filter
Stateless Packet Filter
Router
Gateway
Bridge

(where the last three are most likely quite well-defined already, so it
oculd just reference them).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Aug 2004 14:55:59 -0700 (PDT)

> answer):  If the draft is in favour of incoming-only as requirement, it

(I believe you intended to write "outgoing-only" in the line above.)

> should leave bidirectional as a possibility to the implementor.

Okay, I now understand what you're saying.

My point is that if the BEHAVE document is silent and only requires
outbound NAT binding refresh, two applications (multicast and music-
on-hold) won't work.  I believe we can workaround music-on-hold so
that it works with outbound-only NAT refresh (the workaround is to
leak packets in violation of recvonly), but I don't believe we can
workaround multicast.

> > voice over IP and video over IP endpoints need to behave in face of

Is this group's consensus that we allow multicast to be broken by BEHAVE-
compliant NATs?  If so, we could have a separate specification
that describes how a BEHAVE-compliant NAT could also support
multicast.  In my opinion a separate document for multicast, IPsec,
and other oddball things (Router Alert Option) might be the best
way to allow BEHAVE to process quickly around UDP and ICMP without
being held back with more complicated and less-common protocols.

> 'access routers' if they really are fully-fledged NAT/NAPT +
> Stateful Packet Filter devices..
>
> NAT
> NAPT
> Masquerading
> Firewall
> Packet filter
> Stateful Packet Filter
> Stateless Packet Filter
> Router
> Gateway
> Bridge
>

We could define those terms, but I don't anticipate that changing
product packaging or advertising.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Aug 2004 22:59:54 -0700 (PDT)

> oculd just reference them).

Oh the difference between a Router, Switch, and Bridge is something that can
consume many beers :-)