Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 18 Jul 2001 09:03:18 -0700

Hi Michael,

A lot of people are looking for solutions (now!) for allowing a home or
office user (often protected by some simple type of firewall or NAT) to
connect to a server service (calling card, conference bridge, whatever). It
would be logical for the service provider to place the server at globally
reachable location. This covers a lot of cases. [Jonathan Rosenburg's SIP
draft on residential/enterprise firewall traversal phrases this much more
eloquently.]

As you said yourself in your "tail-wagging-the-dog" email, how do initiate a
connection from outside the firewall (eg, the double NAT case) - it can
really only be done with assistance from the firewall. This assistance
either needs to be directly through an ALG or indirectly by providing the
application with the mapping that will be used. In latter case, at least one
side of the application-layer will still need to know one of the globally
reachable addresses involved, right? 

Not every firewall/NAT will have the same capabilities and the nat problem
is hard enough already, so I think it is a lot better to only require
assistance from one of the firewalls in the double NAT case (as covering the
no-assistance/public-server case). Don't you agree?

[Things are more complicated for UDP because of its connectionless nature.]

Obviously the SCTP solution is not going to help in the near future but I
think the comedia paradigm is still quite a good first step until things
like midcom are widely deployed in firewall/nats

Robert.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 4:05 PM
> To: Fairlie-Cuninghame, Robert
> Cc: 'Leonid Rosenboim'; Ross Finlayson; [email-masked]
> Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP
> 
> 
> Fairlie-Cuninghame, Robert writes:
>  > 	c) only one endpoint needs to have a globally reachable 
> address for
>  > guaranteed bidirectional transport
> 
>    This seems like it defers the harder problem for about
>    10e-9s. If Valhala is gone and the ascendency NATs
>    asured, then double NAT's will be the norm.
> 
>    Then what?
> 
> 		Mike
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Jul 2001 12:54:28 -0400

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 12:03 PM
> To: 'Michael Thomas'
> Cc: [email-masked]'

Well, I would separate firewalls from nats. If the firewall disallows all
UDP, you're SOL and need some ugly, ugly solutions.

In the case of NAT, yes - you need to have one side at least have a public
address. In our latest version of the entfw draft, coming soon, we provide a
means for the host to discover a usable binding on the public side of the
nat. It uses a "pre-midcom" approach, if you will, that talks to something
sitting behind the nat on the public side, rather than talking to the nat
directly. This approach allows us to midcom-ify existing nats without
changing them.

> like midcom are widely deployed in firewall/nats

By the time SCTP is finished, deployed, stable, and implemented in nats,
they'll all already have midcom and then it'll be a moot point.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 18 Jul 2001 13:15:55 -0700

By the way, I have published two related drafts:

http://search.ietf.org/internet-drafts/draft-huitema-natreq4udp-00.txt
And
http://search.ietf.org/internet-drafts/draft-huitema-sdp4nat-00.txt

The second one deals with the problem of port mappings by NAT, which
will break the 2n, 2n+1 rule of RTP. I believe that we have to relax
this rule, and that we have to find a way to document both the RTP & the
RTCP ports in SDP (that is, if they are separate.) We should spend some
time on the subject in London.

-- Christian Huitema

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, July 18, 2001 9:19 AM
> To: 'Michael Thomas'; Fairlie-Cuninghame, Robert
> > Sent: Wednesday, July 18, 2001 11:05 AM
> Then you read draft-rosenberg-sip-entfw-02.txt, due out this 
> week, which explains how to handle this case.... :) The 
> mechanism in there uses bidirectional streams (which we call 
> symmetric) whenever only one side its natted, and otherwise 
> uses a network intermediary outside of the firewall when both 
> are behind nats that don't support Christian's 
> http://search.ietf.org/internet-drafts/draft-huitema-natreq4ud
p-00.txt. When contacting this network intermediary, its still useful to
use symmetric RTP.

-Jonathan R.

---

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 23 Jul 2001 09:35:43 -0700

Henning,

The NGTRANS group is working on the issue of IPv6 behind NAT. I recently
submitted a draft (draft-huitema-shipworm-00.txt) that proposes a
solution for getting IPv6 addresses from behind a NAT. This is a rough
first draft, that will be discussed in the NGTRANS group, and that will
certainly have to be perfected. However, it provides a credible solution
for making IPv6 available everywhere.

-- Christian Huitema

> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, July 21, 2001 9:53 AM
> To: Michael Thomas
> Cc: Jonathan Rosenberg; Fairlie-Cuninghame, Robert; 'Leonid
> Rosenboim'; Ross Finlayson; [email-masked]
> Subject: Re: [AVT] Re: RTP/RTCP Port Sharing -> SCTP
> 
> Michael Thomas wrote:
> >
> > Jonathan Rosenberg writes:
> week, which
> >  > explains how to handle this case.... :) The mechanism in there
> uses
> >  > bidirectional streams (which we call symmetric) whenever only one
> side its
> >  > natted, and otherwise uses a network intermediary outside of the
> firewall
> >  > when both are behind nats that don't support Christian's
> >  > http://search.ietf.org/internet-drafts/draft-huitema-natreq4udp-
> 00.txt. When
> >  > contacting this network intermediary, its still useful to use
> symmetric RTP.
> >
> >    Sigh. If the end result of most media sessions is a rendezvous
> >    to a intermediary, then our bragging rights over the IN will
> >    be nullified. I know that this is the implication of NAT's, but
> >    it still depresses me.
> 
> It would be nice if all the effort expended on fixing the NAT stuff
> would be matched by people deploying IPv6 applications (enabling IPv6
> on
> recent Solaris and Linux boxes, as well as routers, seems pretty
> trivial, from our experience) or dispelling the notion that you can't
> get addresses, which seems to often be perpetuated by people who have
> other agendas (such as making it difficult to use more than one
> computer
> on a home DSL/cable modem).
> 
> That said, I wonder if it wouldn't be easier to just have the client
> set
> up one secure tunnel to this outside entity with a real IP address,
> for
> all applications that are stymied by NATs, rather than inventing a new
> mechanism for each application. This does mean two relaying points,
> but
> avoids all the negotiation and myriad special cases. Can this be done
> with the typical VPN setups in some of the more recent OSs?
> 
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2001 12:22:07 -0400

> Sent: Thursday, July 19, 2001 9:48 AM
> To: Colin Perkins
> Cc: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg'; 
> 'Michael Thomas';
> [email-masked]'
> Colin Perkins writes:
>  > --> "Fairlie-Cuninghame, Robert" writes:
>  > >Hi Jonathan,
>  > >
>  > >> 
>  > >A firewall may allow the application (SIP, H.323, etc) 
> through but not allow
>  > >"random" UDP packets to come from outside to "random" RTP 
> ports (since the
>  > >RTP ports are dynamically negotiated by the 
> application-layer). It may
>  > >require that the RTP flow initiate from within the 
> firewall and open a
>  > >five-tuple hole in the firewall as you suggest. I'm only 
> guessing but it
>  > >seems reasonable. 
>  > >
>  > >Of course we could define set of a "standard" RTP port for single
>  > >user-machines which might help  that problem but this is 
> not a general
>  > >solution and perhaps even encouraging undesirable behavior.
>  > 
>  > Section 7 of RFC1890 registers ports 5004 and 5005 for 
> this purpose.
> 
>    Oh. Cool. As I've mentioned to Jonathan before, I think
>    it's an OS/daemon implementation issue whether use of a
>    well known port RTP can be multiplexed for multiple users.
>    Clearly it's not going to be as clean of a design as free
>    floating RTP ports, but a daemon camping on 5004,5005 with
>    a message passing API for users to select SSRC's of interest
>    would probably be doable. The ability to express this in
>    SDP might be problematic though (I haven't looked at what
>    Christian cooked up though...)

Yeah, but the 5004/5005 is just a recommendation, the ports still float for
multi-session machines, like gateways. Anyway, my experience is that people
aren't even using these as the starting points for single session devices.

I would expect that the way to do muxing within a port, using SSRC for
demux, would be to treat the SSRC as a "sub-port". So, when A calls B, the
SDP from A indicates the port it will receive media on, and the SSRC it
needs B to send with. Similarly, the SDP in the 200 OK indicates the port B
would like to receive on, the the SSRC it needs A to send with.

So, all we need is an SDP attribute like:

a=ssrc:7659

With this mechanism, the SSRC selection moves from the sender (where it is
today) to the receiver (where it has to be to avoid collisions on a port).
Obviously this only works for unicast.

Backwards compatibility is a bit of a pain, though. Near as I can tell you
would need to rely on SIP Require for this, and back off to floating ports
if the INVITE fails. 

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Jul 2001 15:43:11 -0400

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 8:38 AM
> To: Jonathan Rosenberg
> Cc: 'Henning G. Schulzrinne'; Michael Thomas; Fairlie-Cuninghame,
> Robert; 'Leonid Rosenboim'; Ross Finlayson; [email-masked]
> > We looked at that as a possible solution. The problems are:
> > 
> > 1. its not very viable for standalone devices, like phones, 
> residential
> > gateways, etc. which are not going to be doing vpn 
> protocols in general
> 
> I don't see that ESP or IP-in-IP are particularly difficult.

VPN is more than tunneling, of course. Its also the allocation of an
address. I'm sure there are other aspects to it.

An additional point is this - how would the phone know that it needs to
connect to a vpn? Presumably it should do this only if its behind a nat. I'd
rather not require the user to manually configure this.

> 
> > 
> > 2. since it works at the ip layer (providing a virtual 
> interface), and since
> > you need to send your RTP out over this interface always, 
> you effectively
> > need to set this up as a default interface, so that it gets all your
> > traffic, not just the voip stuff
> 
> This wouldn't matter for IP phones, since they are not likely 
> to do lots
> of non-RTP applications.

True, but the provider doesn't know that.

> 
> > 
> > 3. Its TCP and always uses an intermediary, bad for voice quality.
> 
> Heh? Since when do you need to do VPNs or tunneling using TCP?

Some vpns are over TCP, some arent. The bigger problem is the network
intermediary (the VPN server within the provider network). As a result, you
get triangle routed media at best, triangle routed TCP media in the worst
case.

The mechanism in draft-rosenberg-sip-entfw-02 is a sort-of-vpn kind of
thing. With VPN, you would allocate an address that appears as a virtual
interface, and send things over that interface. The interface addres is
placed into the SDP/SIP by the client directly. With our proposed solution,
there is still an address allocation, with the resulting address placed into
the SIP/SDP by the client, but its not allocating an address for all
traffic, just an address and port for writing into the SDP. The source
IP/port for sending media are still local interfaces. The result is that we
avoid the triangle routing that I really want to avoid.

> > I'll note that our proposed solution in draft-rosenberg-sip-entfw-02
> > effectively has clients allocating addresses off of a 
> server in the voip
> > providers network. This is really a form of vpn, but happens at the
> > application layer, so its focused on a particular 
> application usage (fixing
> > problem 2 above), and is based on udp (fixing 3). Other 
> than that the idea
> > is quite similar to using a vpn server.
> 
> Another reason not to invent a special-case solution if we 
> can identify
> a suitably lightweight tunneling solution. The term 'VPN' is 
> probably a
> misnomer in this case. What we need is basically an IP-in-IP tunnel
> initiated by the inside to the outside box, with periodic refreshes to
> keep up the NAT binding. I suspect that some of the multicast 
> tunneling
> approaches discussed in this neighborhood might be draftable. You need
> that in any event if you want to be able to receive incoming calls.

The proposed solution is not specific to sip; the mechanism described in the
draft is a pre-midcom approach for discovering and then allocating bindings
on all of the nats between you and a public network. It has many of the
properties of the VPN solution, except that it allows direct communication
between hosts, rather than using a network middleman. Its no more
specialized than midcom is.

-Jonathan R.

---