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

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

Hi 
Medhavi,
<FONT face=Arial color=#800000 
size=2> 
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.).
<FONT face=Arial color=#800000 
size=2> 
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.
<FONT face=Arial color=#800000 
size=2> 
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.
<FONT face=Arial color=#800000 
size=2> 
For a 
bi-directional communication, this shouldn't be a problem in the first 
place.
<FONT face=Arial color=#800000 
size=2> 
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.
<FONT face=Arial color=#800000 
size=2> 
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 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: 
  ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
  [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Medhavi 
  BhatiaSent: Tuesday, August 10, 2004 04:54To: 
  ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: [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: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 10 Aug 2004 11:16:11 -0700 (PDT)

<span
style='font-size:12.0pt;color:navy'>Francois,

<span
style='font-size:12.0pt;color:navy'> 

<span
style='font-size:12.0pt;color:navy'>In your analysis, did you see any Firewalls
which allows only outbound refresh ?

<span
style='font-size:12.0pt;color:navy'> 

<span
style='font-size:12.0pt;color:navy'>-Medhavi.

<span
style='font-size:12.0pt;color:navy'> 

<font size=3
face="Times New Roman">

<span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:<font size=2
face=Tahoma> Francois Audet
[mailto:audet@xxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, August 10, 2004
1:33 PM
To: 'mbhatia@xxxxxxxxxxx';
'ietf-behave@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [Ietf-behave] NAT
behave draft

<span style='font-size:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>Hi Medhavi,

<span style='font-size:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>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:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>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:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>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:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>For a bi-directional communication, this
shouldn't be a problem in the first place.

<span style='font-size:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>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:
12.0pt'> 

<span style='font-size:
10.0pt;font-family:Arial;color:maroon'>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:none;border-left:solid maroon 1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----
From:
ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] <span style='font-weight:
bold'>On Behalf Of Medhavi Bhatia
Sent: Tuesday, August 10, 2004
04:54
To:
ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: [Ietf-behave] NAT behave
draft

<span style='font-size:
12.0pt'>Some comments/questions:

<span style='font-size:
12.0pt'> 

 <font size=3
     face="Times New Roman">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 size=3
     face="Times New Roman">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:
12.0pt'> 

<span style='font-size:
12.0pt'>-Medhavi.

<span style='font-size:
12.0pt'> 

<span style='font-size:
12.0pt'>Medhavi Bhatia

<span style='font-size:
12.0pt'>Chief Architect

<span style='font-size:
12.0pt'> 

<span style='font-size:
12.0pt'>NexTone Communications

<span style='font-size:
12.0pt'>****Pioneering Global Communications with Excellence, Integrity and
Flawless Execution****

<span style='font-size:
12.0pt'>

---

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

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

Similarly for music-on-hold, the inside device will have to keep
the binding alive.

> For a bi-directional communication, this shouldn't be a problem
> in the first place.
>
> 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.

Right, except then you're not recvonly anymore -- you're transmitting.  You
might not always even know where to transmit packets to (you might not have
enough SDP).  This violates the meaning of recvonly.

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

Agreed.

But we don't have an agreed-upon way of sending these NAT-keepalive packets:
it could be STUN, RTP No-Op (draft-wing-avt-rtp-noop-00.txt) which is only
an individual submission, 'silence suppression' packet for G.729, or an NSE
that is hoped to be silently dropped by the remote end.

I believe we need an agreement on this NAT keepalive packet - perhaps this
should be brought up in AVT (for packet format) and/or MMUSIC (for issue
around transmitting while SDP says 'recvonly').

-d