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

From: "Francois Audet" <[email-masked]>
Date: Tue, 10 Aug 2004 15:49:38 -0700 (PDT)

In the 
ones that we tested (at Nortel), ALL NAT except one used the Outbound only 
refresh (which is good, and secure). 
<FONT face=Arial color=#800000 
size=2> 
The 
bad NAT was an old discontinued product witch worked with inbound only (which is 
bad).
<FONT face=Arial color=#800000 
size=2> 
We 
only tested a small number of NATs however.
<FONT face=Arial color=#800000 
size=2> 
Cullen 
may have more data from his own more extensive testing.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Medhavi Bhatia 
  [mailto:mbhatia@xxxxxxxxxxx] Sent: Tuesday, August 10, 2004 
  11:15To: Audet, Francois [SC100:9T51:EXCH]; 
  ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: RE: [Ietf-behave] NAT 
  behave draft
  
  <SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy">Francois,
  <SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy"> 
  <SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy">In your analysis, did you see any 
  Firewalls which allows only outbound refresh ?
  <SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy"> 
  <SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy">-Medhavi.
  <SPAN 
  style="FONT-SIZE: 12pt; COLOR: navy"> 
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  
  <FONT 
  face="Times New Roman" size=3>

  <SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:<FONT 
  face=Tahoma size=2> 
  Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx] <SPAN 
  style="FONT-WEIGHT: bold">Sent: Tuesday, August 10, 2004 1:33 
  PMTo: '<st1:PersonName 
  style="BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x" 
  w:st="on">mbhatia@xxxxxxxxxxx'; 
  'ietf-behave@xxxxxxxxxxxxxxxxxxx'<SPAN 
  style="FONT-WEIGHT: bold">Subject: RE: [Ietf-behave] NAT behave 
  draft
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">Hi 
  Medhavi,
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">REQ-3 is based on 
  the fact that too short of a UDP timeout binding will cause problems. We've 
  seen NATs with very short timers (like 30s), but there are 2 problems 
  associated with those NATs: (1) the timer is so short that a short term 
  problem may cause the NAT binding to change, and (2) it causes a very 
  significant rate of refresh packets to be sent which can affect the 
  scalability of the servers receiving them (SIP proxy/registrars, STUN servers, 
  RTP media receivers, RTCP, etc.).
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">The exact value of 
  course is something that can be examined, and if you have any input, please 
  share it with us. As long as it it not too short, I think we can be quite 
  flexible.
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">REQ-4 is because if 
  it were refreshed by the inbound traffic, a termination "outside" the NAT 
  could keep the pinhole opened for as long as it wished, which would be a 
  security concern. I.e., you could phone somebody, then hang-up, and they could 
  keep the pinhole opened by sending packets to you. For the voicemail server, 
  yes, it would mean that the inside device would need to keep the binding 
  alive.
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">For a 
  bi-directional communication, this shouldn't be a problem in the first 
  place.
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">For uni-directional 
  communication (sdp=recvonly), what it means is that if you are behind a NAT, 
  you need to keep the receiving NAT binding open. In practice, it means that 
  when you do your STUN request to find your address binding, you need to keep 
  it alive (by sending packets from the media port: STUN packets or other) 
  during the session.
  
  <SPAN 
  style="FONT-SIZE: 12pt"> 
  
  <SPAN 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">This is STUN or SIP 
  client behavior, and is outside the scope of the BEHAVE document. However, the 
  BEHAVE document is drafted so that it would support such client 
  behavior.
  <BLOCKQUOTE 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: maroon 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
    <FONT face=Tahoma 
    size=2>-----Original 
    Message-----From: 
    ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
    [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] <SPAN 
    style="FONT-WEIGHT: bold">On Behalf Of Medhavi Bhatia<SPAN 
    style="FONT-WEIGHT: bold">Sent: Tuesday, August 10, 2004 
    04:54To: 
    ietf-behave@xxxxxxxxxxxxxxxxxxx<SPAN 
    style="FONT-WEIGHT: bold">Subject: [Ietf-behave] NAT behave 
    draft
    <SPAN 
    style="FONT-SIZE: 12pt">Some 
comments/questions:
    <SPAN 
    style="FONT-SIZE: 12pt"> 
    
      <FONT 
      face="Times New Roman" size=3>REQ-3 comes up 
      with a min-timeout of 2 minutes for UDP dynamic bindings. Is there data 
      somewhere on the internet which can back this up ? 
      
      <FONT 
      face="Times New Roman" size=3>REQ-4 suggests 
      that refreshes MUST be based outbound traffic only. This seems to be 
      linked to REQ-1, since for symmetric firewalls, the security problem cited 
      as reason is not quite valid. Also, inbound refreshes pose a problem with 
      setting and maintaining the session. For example, a voice mail server 
      which is outside the firewall cannot assume that simply sending traffic is 
      good enough. For the offer/answer model, the sdp attribute of recvonly in 
      an offer coming from behind the firewall is inapplicable, so this 
      requirements affects how SIP sessions would be setup (or any other 
      protocol...). 
    <SPAN 
    style="FONT-SIZE: 12pt"> 
    <SPAN 
    style="FONT-SIZE: 12pt">-Medhavi.
    <SPAN 
    style="FONT-SIZE: 12pt"> 
    <SPAN 
    style="FONT-SIZE: 12pt">Medhavi Bhatia
    <SPAN 
    style="FONT-SIZE: 12pt">Chief Architect
    <SPAN 
    style="FONT-SIZE: 12pt"> 
    <SPAN 
    style="FONT-SIZE: 12pt">NexTone Communications
    <SPAN 
    style="FONT-SIZE: 12pt">****Pioneering Global Communications with 
    Excellence, Integrity and Flawless 
Execution****
    <SPAN 
    style="FONT-SIZE: 12pt">

---

From: Geoff Huston <[email-masked]>
Date: Tue, 10 Aug 2004 16:21:40 -0700 (PDT)

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.

At 08:45 AM 11/08/2004, Francois Audet wrote:
In the ones that we tested (at Nortel), ALL NAT except one used the 
Outbound only refresh (which is good, and secure).

The bad NAT was an old discontinued product witch worked with inbound only 
(which is bad).

We only tested a small number of NATs however.

Cullen may have more data from his own more extensive testing.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 11 Aug 2004 03:21:22 -0700 (PDT)

At 01:21 AM 8/11/2004, Geoff Huston wrote:
>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.
>
>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 am not aware of such a survey.

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

Does bidirectional mean in&&out or in||out?

I haven't looked at what's today NATs criteria for keeping TCP bindings alive.
The question to me is whether we would like to go beyond a minimalistic set of 
requirements. It may be that minimalistic requirements (keep binding alive based
on outbound packets) will work for TCP too. All in all, if an inbound TCP 
packet 
comes in, it will cause an outbound TCP packet sent out.

-jiri

>>In the ones that we tested (at Nortel), ALL NAT except one used the Outbound 
>>only refresh (which is good, and secure).
>>
>_______________________________________________
>Ietf-behave mailing list
>Ietf-behave@xxxxxxxxxxxxxxxxxxx
>https://list.sipfoundry.org/mailman/listinfo/ietf-behave

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Geoff Huston <[email-masked]>
Date: Wed, 11 Aug 2004 15:16:24 -0700 (PDT)

Bidirectional, as I understand it in the context of the draft, means that
an inbound packet or an outbound packet will refresh the binding expiration
timer.
You are right that in must circumstances TCP follows a packet in one direction
with a packet in the other, so in the case of TCP the three options produce
a very similar outcome.
On thinking about this some more, the circumstances where this would _not_ 
happen
are when one end has closed its connection but the other has not. In this case
I guess that the safest action for the NAT is to use outbound as the
binding expiration timer trigger for TCP. i.e. the binding will expire once the
'internal' host has closed its TCP state, even if the external end continues
to direct packets to the closed session.

   Geoff

At 08:18 PM 11/08/2004, Jiri Kuthan wrote:
>
>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 haven't looked at what's today NATs criteria for keeping TCP bindings alive.
The question to me is whether we would like to go beyond a minimalistic 
set of
requirements. It may be that minimalistic requirements (keep binding alive 
based
on outbound packets) will work for TCP too. All in all, if an inbound TCP 
packet
comes in, it will cause an outbound TCP packet sent out.

-jiri

>>
>>The bad NAT was an old discontinued product witch worked with inbound 
only (which is bad).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Aug 2004 16:13:32 -0700 (PDT)

> I haven't looked at what's today NATs criteria for keeping TCP
> bindings alive. The question to me is whether we would like to go
> beyond a minimalistic set of requirements. It may be that minimalistic
> requirements (keep binding alive based on outbound packets) will work
> for TCP too. All in all, if an inbound TCP packet comes in, it will
> cause an outbound TCP packet sent out.

The end of a TCP session is indicated with FIN (from either end) or
RST (from either end).  Except for the odd case of both TCP peers
forgetting about an active session, a NAT can expect to see a FIN
or RST from one of the TCP peers (most likely from both of the TCP 
peers).

The NAT can safely destroy its NAT binding after seeing the 3-way 
FIN teardown (in the case of FIN) or the 2-way RST teardown (in the 
case of RST).  To handle the case of the TCP peer being unreachable
the NAT needs a timeout for when only peer attempts a RST or FIN 
but isn't receiving a response -- the binding should eventually
be destroyed even without a normal TCP close.

I expect the BCP should include requirements related to 
draft-ietf-tcpm-tcpsecure-01.txt which describe middlebox (NAT)
behavior around the recently-announced TCP RST and SYN attacks.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Aug 2004 16:15:39 -0700 (PDT)

Geoff Huston wrote:

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

Multicast needs inbound-only.  Or are we going to declare multicast
out-of-scope for this BCP?

-d

---

From: Geoff Huston <[email-masked]>
Date: Wed, 11 Aug 2004 17:43:19 -0700 (PDT)

At 09:17 AM 12/08/2004, Dan Wing wrote:

Multicast needs inbound-only.  Or are we going to declare multicast
out-of-scope for this BCP?
The draft I've been working from attempts to look at this on a
per-protocol basis, and my "in general" comment was about
the observation  that has been made that _for UDP_ NATS use
outbound-only refresh in general.
Multicast does need different treatment and this should be flagged
with the Multicast considerations, I did not see an out-of-scope for
multicast in the IETF session, and, in the contrary, I though it
had been accepted as needing consideration.
Geoff