Subject: RE: [Ietf-behave] New draft on UDP unicast behavior

From: Kaushik Biswas <[email-masked]>
Date: Wed, 20 Oct 2004 17:50:59 -0700 (PDT)

In addition, couple of points:

(1) Why should hairpinning be a must:
REQ-9: A NAT MUST support "Hairpinning"
behavior. Hairpinning allows two endpoints on the internal side of
the NAT to communicate even if they only use each other's external IP
addresses    and ports. 

This may be a nice-to-have support in a NAT, but why should it be a
must.

The inside host A should be trying to reach the inside host B, via the
private-address and not via the NAT'd address of B. Why come through NAT
and add an extra-hit in processing-time.

(2) Also, why don't we mandate the RTP/RTCP port-allocation to be
successive. For eg: if the request is for the embedded media-port =
20000, then NAT should allocate n-successive ports. If NAT is supporting
port-preservation then 20000, 20001,..., should be allocated. If it is
not supporting port-preservation then the next n-successive free ports in
the range 1024 - 65535.

Thanks,
Kaushik

At 07:50 PM 10/20/2004 -0400, Francois Audet wrote:

OK, I think we have concensus on
the following. 

11 - Requirements 

   REQ-3c:  If the host's source port was in
the range 0-1023, 
               
the NAT's source port must also be in the same range. 

If the host's source port was in the range 1024-65535,

the NAT's source port must also be in that range.

REQ-10:  If a NAT includes ALGs, all of those ALGs MUST be 
         disabled by default. 
  
    REQ-10a:  If a NAT includes ALGs, it is RECOMMENDED that 
              the NAT allow the user to enable or disable each 
              ALG separately.  

11.1 - Requirements discussion 

   REQ-3c:  Certain applications expect the source UDP port to be 
            in the well-known range. See RFC 2623 for an example. 

REQ-10:  NAT ALGs may interfere with UNSAF methods. 
  
    REQ-10a:  This requirement allows the user 
              to enable ALGs which are necessary to aid operation 
              of some applications without enabling ALGs which 
              interfere with operation of other applications. 
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Saikat Guha <[email-masked]>
Date: Wed, 20 Oct 2004 18:12:49 -0700 (PDT)

On Wed, 2004-10-20 at 20:50, Kaushik Biswas wrote: 
> REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows
> two endpoints on the internal side of the NAT to communicate even if
> they only use each other's external IP addresses    and ports. 
> 
> private-address and not via the NAT'd address of B. Why come through
> NAT and add an extra-hit in processing-time.

1) Rendezvous services located upstream from the NAT cannot help A and B
discover each other's private addresses. This is the case with online
gaming networks, P2P networks etc. ICE tries to help by, in some sense,
probing for rendezvous services inside the NAT'ed network but it does
not solve all possible scenarios.

2) Consider the scenario with NATs N,M,O and hosts A, B
                +--- O ---- B
global  -- N --|
internet        +--- M ---- A

A and B cannot communicate without hairpinning through N since their
bindings at M/O cannot, in general, be determined.

-- 
Saikat Guha
https://www.guha.cc/~saikat

Attachment:
signature.asc

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2004 19:29:18 -0700 (PDT)

<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Tahoma 
  size=2>-----Original Message-----From: Kaushik Biswas 
  [mailto:kbiswas@xxxxxxxxx]Sent: Wednesday, October 20, 2004 5:51 
  PMTo: Francois AudetCc: 'Senthil Sivakumar'; 'Dan Wing'; 
  'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast 
  behavior 
  In addition, couple of points:(1) Why should hairpinning be a 
  must:REQ-9: A NAT MUST support "Hairpinning" behavior. 
  Hairpinning allows two endpoints on the internal side of the NAT to 
  communicate even if they only use each other's external IP 
  addresses    and ports. This may be a nice-to-have 
  support in a NAT, but why should it be a must.The inside host A should 
  be trying to reach the inside host B, via the private-address and not via the 
  NAT'd address of B. Why come through NAT and add an extra-hit in 
  processing-time.<FONT face=Verdana 
  color=#0000ff size=2> 
<FONT face=Verdana color=#0000ff 
size=2>Because it's not always possible for host A to learn host B's private 
address (that is, the address behind the NAT), because both A and B are using a 
server on the public side of the NAT to find each other.  A good example 
are two people playing a realtime game, in the same house, with an 
Internet-based server -- unless the game's signaling protocol supports two hosts 
behind the same NAT finding each other, the game won't work.
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>ICE provides this functionality for SIP, and of course the ideas in ICE 
could be used by other applications such as online games.  But instead of 
requiring the applications have this extra overhead, it's easy for the NATs to 
simply handle hairpinning -- and in the last 2-3 years most NATs support 
hairpinning.
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>So, to get such applications to work we either need all of the 
applications to do something akin to ICE (that is, signal both the private IP 
address and UDP port as well as the public IP address and UDP port), or we need 
NATs to handle hairpinning and the applications can continue advertising just 
the public IP address and UDP port.  Obviously it's more _efficient_ for 
applications to not route packets through the NAT, but it's best to get things 
to work first and then optimize.
<FONT face=Verdana color=#0000ff 
size=2> 
<SPAN 
class=087140802-21102004><FONT face=Verdana color=#0000ff 
size=2> 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
   (2) Also, why don't we 
  mandate the RTP/RTCP port-allocation to be successive. For eg: if the request 
  is for the embedded media-port = 20000, then NAT should allocate n-successive 
  ports. If NAT is supporting port-preservation then 20000, 20001,..., should be 
  allocated. If it is not supporting port-preservation then the next 
  n-successive free ports in the range 1024 - 65535.<SPAN 
  class=087140802-21102004><FONT face=Verdana color=#0000ff 
  size=2> 
<FONT face=Verdana color=#0000ff 
size=2>It's impossible for the NAT to determine if a UDP packet is an RTP packet 
and will want the associated port+1.  Also, both RFC3550 (RTP) and 
draft-ietf-mmusic-anat-01.txt no longer require that RCTP=RTP+1 -- primarily to 
make it easier for RTP to traverse NATs.
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>-d
<FONT face=Verdana color=#0000ff 
size=2> 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=087140802-21102004> Thanks,KaushikAt 07:50 
  PM 10/20/2004 -0400, Francois Audet wrote:
  OK, I think we have concensus 
    on the following. 11 - Requirements 
       REQ-3c:  If the host's source port 
    was in the range 0-1023, 

                    
    the NAT's source port must also be in that range. 
    REQ-10:  If a NAT includes ALGs, all of those ALGs 
    MUST be <FONT 
    size=2>         disabled by 
    default.   <FONT 
    size=2>    REQ-10a:  If a NAT includes ALGs, it is 
    RECOMMENDED that <FONT 
    size=2>              
    the NAT allow the user to enable or disable each <FONT 
    size=2>              
    ALG separately.  11.1 - Requirements 
    discussion    REQ-3c:  Certain 
    applications expect the source UDP port to be <FONT 
    size=2>            in 
    the well-known range. See RFC 2623 for an example. <FONT 
    size=2>REQ-10:  NAT ALGs may interfere with UNSAF methods. 
          
    REQ-10a:  This requirement allows the user <FONT 
    size=2>              
    to enable ALGs which are necessary to aid operation <FONT 
    size=2>              
    of some applications without enabling ALGs which <FONT 
    size=2>              
    interfere with operation of other applications. 
    _______________________________________________Ietf-behave mailing 
    listIetf-behave@xxxxxxxxxxxxxxxxxxx<A 
    href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
    eudora="autourl">https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Oct 2004 06:59:07 -0700 (PDT)

On 10/20/04 8:50 PM, "Kaushik Biswas" <kbiswas@xxxxxxxxx> wrote:

> 
> (2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive.
> For eg: if the request is for the embedded media-port = 20000, then NAT should
> allocate n-successive ports. If NAT is supporting port-preservation then
> 20000, 20001,..., should be allocated.

We have talked about this a few times. No NATs today that I am aware of do
this and it is only needed for RTP. The endpoints that do RTP are going to
have to change anyways to do things like STUN and ICE to work with the
behave compliant NATs. It seems very easy for them to also signal the RTCP
port they are going to use. (It's well defined how to do this).

I viewed it as far more likely that the RTP devices would bother to make the
changes to signal RTCP ports that the likelihood that NAT vendors would do
consecutive allocations.

Cullen (with an individual contributor hat on)

---

From: Kaushik Biswas <[email-masked]>
Date: Mon, 25 Oct 2004 18:01:04 -0700 (PDT)

At 06:39 AM 10/25/2004 -0700, Cullen Jennings wrote:

> (2) Also, why don't we mandate the RTP/RTCP port-allocation to be 
successive.

We have talked about this a few times. No NATs today that I am aware of do
this
Couple of NATs do this, and this is one of the overheads which NATs had to 
incur in packet-processing path so as to ensure that the allocated RTP/RTCP 
ports are consecutive. It would be a welcome change for NATs if this 
restriction is gone -- I mean the end-points not mandating these ports to 
be consecutive.

Thanks,
Kaushik
 and it is only needed for RTP. The endpoints that do RTP are going to

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2004 23:31:07 -0700 (PDT)

> restriction is gone -- I mean the end-points not mandating these ports to

BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT"
document, which would provide guidance.  For example, it could explain
things such as:

  - use symmetric UDP behavior (for RTP applications, this would be
    draft-wing-mmusic-symmetric-rtprtcp-01).
  - use RFC3605 ("Real Time Control Protocol (RTCP) attribute in Session
    Description Protocol (SDP)")
  - keep NAT bindings alive by sending UDP messages from inside-to-
    outside
  - learn public NAT bindings using STUN
  - know when STUN isn't necessary (for example, many folks think
    STUN is necessary for SIP signaling itself, but STUN is for the
    media stream).
  - leak RTP and RTCP packets early (either RTP No-Op packets, silence
    packets, STUN packets to the peer, STUN packets to the STUN server)
  - when on hold or silence suppression, leak media to keep NAT
    binding open

many of these apply to VoIP applications, but many also apply to any
other application behind a BEHAVE NAT that wants to use UDP as its
transport.

I would like to see such a document added to the WG's agenda.

-d

---

From: Robert Sanders <[email-masked]>
Date: Tue, 26 Oct 2004 01:39:11 -0700 (PDT)

Dan Wing wrote:

BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT"
document, which would provide guidance.  

If this usage differs from how the UDP application might use a 
non-BEHAVE-capable NAT, or from the scenarios described in 
draft-ietf-sipping-nat-scenarios et cetera, it would also be useful to 
show how an application might *detect* a well-BEHAVEd NAT.

I know that NAT type detection has been deprecated in RFC3489bis, and 
that the problem of detection has become more complex than originally 
estimated.  Requiring more than one internal IP address to fully 
disambiguate the behavior of "non-deterministic" NATs is problematic.  
So perhaps precise detection is not feasible in many cases.

The question I have is whether the purpose of BEHAVE is to specify an 
ideal NAT's behavior and then to provide usage guidelines for 
applications working through a compliant set of NATs, or to recommend 
NAT behaviors that increase the efficiency or reliability of existing 
techniques.  If it's the latter case then BEHAVE shouldn't need its own 
usage document.  Any application which wishes to function through non 
well-BEHAVEd NATs, or through non-traditional NAT scenarios such as 
twice NAT, couldn't limit itself to techniques dependent upon BEHAVE 
compliance.

regards,
 -- Robert

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2004 17:58:24 -0700 (PDT)

> show how an application might *detect* a well-BEHAVEd NAT.

draft-ietf-sipping-nat-scenarios discusses all the scenarios; a BEHAVE
NAT isn't applicable to many of them.  Perhaps all that's needed is an 
update to draft-ietf-sipping-nat-scenarios to describe which sections 
apply to BEHAVE NATs.

> I know that NAT type detection has been deprecated in RFC3489bis,

Right.

> and 

I agree.  

What's useful is for product datasheets on NATs to say "this is a 
BEHAVE-compliant NAT for UDP, multicast, and TCP", and for a SIP
phone to say "works behind a BEHAVE-compliant UDP NAT", and for
a multiplayer game to say "works behind a BEHAVE-compliant UDP 
and TCP NAT", for example.

> usage document. 

I'm not sure which case it is, honestly.  For example, BEHAVE won't
allow Symmetric NATs (as defined by RFC3489) because such NATs don't
allow peer-to-peer UDP connectivity and require a media relay.  

I don't know the BEHAVE requirement which outlaws Symmetric NATs
would be considered 'ideal behavior' or 'increased efficiency'.

> Any application which wishes to function through non 

-d

---

From: Bryan Ford <[email-masked]>
Date: Mon, 28 Feb 2005 07:14:33 -0800 (PST)

On Thursday 21 October 2004 02:50, Kaushik Biswas wrote:
> REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows two
> endpoints on the internal side of the NAT to communicate even if they only
> use each other's external IP addresses    and ports.
>
> This may be a nice-to-have support in a NAT, but why should it be a must.
>

Because that optimization is only possible with single-level NAT.  Without 
hairpinning support, hole punching is not possible at all under 
increasingly-common multi-level NAT scenarios in which the endpoints share 
one level of NAT but reside behind two different "second-level" NATs.  This 
issue is discussed more extensively in draft-ford-behave-top-00.txt (Section 
2) and draft-ford-behave-gen-00.txt (Section 6).

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Mon, 28 Feb 2005 08:07:16 -0800 (PST)

> show how an application might *detect* a well-BEHAVEd NAT.

I'm not at all sure that such detection is really necessary: for the most part 
I think we should just be recommending that apps assume that NATs are 
well-BEHAVEd going forward, and perhaps make a few specific exceptions as 
necessary to account for particularly common forms of "bad" legacy behavior.

On the other hand, if it is useful for applications to be able to distinguish 
reliably between BEHAVE NATs and non-BEHAVE NATs, then I can think of at 
least one relatively simple technical solution to this problem, which would 
operate completely "in-band" and is both transport-independent and require no 
explicit communication with NAT (e.g., MIDCOM, NSIS, etc.).  Basically, we 
could define a new IP header option, which applications can attach to the 
initial packets in a new transport session they're establishing if desired.  
The application places in this IP option a copy of its source IP address and 
transport-level port number.  Non-BEHAVE NATs will (hopefully) just ignore 
this option, translating only the IP address and port number in the main 
IP/TCP/UDP headers.  BEHAVE NATs would first compare the address/port in the 
option against the address/port in the main headers, translate the option too 
if they match, and zero or remove the option if they don't match.  The 
application at the receiving end can then determine what's on the path as 
follows:

1. If the IP option was preserved and has the same address/port as in the main 
IP/TCP/UDP headers, then ALL of the NATs in the path (if any) are 
well-BEHAVEd.
2. If the IP option disappeared or arrived with an address/port number that 
doesn't match the info in the main IP/TCP/UDP headers, then there is at least 
one NAT in the path that is not BEHAVE-compliant.

A variant of this idea was discussed in one of the early P2P-over-NAT drafts I 
wrote with Pyda Srisuresh, draft-ford-midcom-p2p-00.txt.

Anyway, to reiterate what I said above, I'm not at all convinced that 
"well-BEHAVEd NAT detection" is really necessary or even a good idea, but I 
at least wanted to lay this option on the table in case it seems useful.

> twice NAT, couldn't limit itself to techniques dependent upon BEHAVE

I think the purpose of BEHAVE is some combination of these goals.  We need to 
specify "ideal NAT behavior" strongly and coherently enough so that 
applications have a definite, practical design path they can take and be 
certain of working reliably over future BEHAVE-compliant NATs in all typical 
deployment scenarios.  At the same time, it is important that this "ideal NAT 
behavior" be consistent and compatible with existing widespread techniques 
whenever possible.  Ultimately, we have to live with the fact that with 
legacy NATs, all bets are off - applications may or may not work, and there's 
no way an application can make itself 100% reliable with existing NATs, so 
that cannot be our goal.  But our goal can be to make sure that future 
applications can be (at least pretty darn close to) 100% reliable with future 
BEHAVE-compliant NATs; that should be our goal.  And to do that it's clearly 
important for us to specify exactly how applications can best take advantage 
of the more predictable behavior of well-BEHAVEd NATs.

Cheers,
Bryan