Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt

From: [email-masked]
Date: Thu, 05 Jul 2007 11:15:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: The evaluation of different NAT traversal Techniques for media controlled by Real-time Streaming Protocol (RTSP)
	Author(s)	: M. Westerlund
	Filename	: draft-ietf-mmusic-rtsp-nat-evaluation-00.txt
	Pages		: 36
	Date		: 2007-7-5
	
   This document describes several NAT traversal techniques that could
   be used by RTSP.  Each technique includes a description on how it
   would be used, the security implications of using it and any other
   deployment considerations it has.  There are also disussions on how
   NAT traversal techniques relates to firewalls and how each technique
   can be applied in different use cases.  These findings where used
   when selecting the NAT traversal for RTSP solution to standardize in
   the MMUSIC WG.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mmusic-rtsp-nat-evaluation-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 6 Jul 2007 09:43:21 +0300

Hello,

The "embedded STUN" case is currently defined to use two SETUPs... Couldn't 
the server authenticate the client directly from the USERNAME and 
MESSAGE-INTEGRITY parameter of the incoming STUN Binding Discovery (much like 
ICE does, in fact)?

Also, it is noted that it mostly does not work for multi-homed NATs. Though 
first, multi-homed NATs would normally use the mapped source address toward a 
given external address (otherwise just about how many web application using 
IP address has part of their session authentication would already break?). 
Secondly, the RTSP server will need to be modified to embed a STUN server 
anyway, so it should not be too much to ask that when STUN is used, different 
IP addresses can be used for different media streams.

That being said, I suppose the Symmetric RTP *variant* looks better anyway.

Regards,

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 6 Jul 2007 09:55:33 -0700

> That being said, I suppose the Symmetric RTP *variant* looks 

The Symmetric RTP Variant does look better, but it doesn't 
work if the media server (RTSP server) is behind its own NAT --
such as, for example, you are visiting Grandma's house (which 
has its own NAT) and you want to interact with your media 
player at your house (which has its own NAT).

The Symmetric RTP Variant is very similar to ICE-Lite, as
defined in the last few iterations of ICE.

I would really like the RTSP NAT Evaluation document to include
an additional requirement for 'both RTSP server and RTSP client
behind their own NATs' to its matrix in section 6, "Comparision 
of NAT traversal techniques".

-d

---

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 6 Jul 2007 23:54:14 +0200

Som few comments:

Section 3. Requirements :
- The requirements section should also briefly mentions media
transport, possibly with a requirement like: "the solution MUST allow
delivery of data over TCP as well as data over UDP". Otherwise, if
RTP/UDP is not required, a compelling solution with regards to the
current requirements is probably the TCP tunneling solution.
- I also support Dan's request to add a requirement where "both the
RTSP client and RTSP server are behind their own NAT"

Section 4.2. ICE :
- The abstract of draft-ietf-mmusic-ice mentions that "ICE can be used
by any protocol utilizing the offer/answer model". The direction taken
by this section shows that RTSP specifications would end-up with a
sort of 2nd offer/answer model very similar to RFC3264. The
similarities will be that candidates will be exchanges in controlling
messages... However, there will be some slight differences: for
example in SIP all media are advertised within the same message,
whereas in RTSP one message will be needed per media. Another drawback
for 4.2.3 is thus ICE will need to be extended to discuss this
specificities.
- I also anticipate that if we go towards this direction in the
future, an RTSP "server" located behind a NAT will probably need to
register to a public proxy and maintain an outbound connection.

Section 4.X. New Section?
- Based on what I've said before, I think we need to at least mention
the solution "SIP+ICE+RTSP". We know there are some drawbacks with the
current version of RTSP (transport parameters carried within some RTSP
messages ...), but there are also some advantages:
  - no need to redefine another offer/answer, another outbound-connection ...
  - allow for the requirement where "both RTSP client and RTSP server
    are behind their own NAT"
- If such a new 4.X section is added, rename section 4.2 "ICE" into
"ICE in RTSP".

Section 6:
- Add TCP tunneling in the table

NITS:
- replace TURN by STUN Relay within the document
- page 3: s/evualation/evalution/
- page 3: s/shoulb/should/
- page 13: s/frist/first/
- page 20: Section Symmetric RTP: add ref on draft-wing-behave-symmetric-rtprtcp
- page 29: s/RTSP is may/RTSP may/

Xavier

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 9 Jul 2007 09:54:39 +0300

> of NAT traversal techniques".

I might be pessimistic, or I might perceive a distortedly bad reality of NATs 
(due to having only Linux-based symmetric NATs around me). Still, I really 
doubt RTSP will fly if both sides are behind different NATs. I do think the 
success rate will be too low - without relays nor UPnP-ICD/NAT-PMP. But only 
time will tell.

*However*, even if UDP traversal turns out to work, how do you get the TCP 
control connection through in the first place, if the server is NATed? So, 
you end up requiring some kind of port forwarding: manual port-triggering, 
UPnP-ICD or NAT-PMP on the server's NAT anyway; or (IPv6) tunneling: Teredo, 
AYIYA, etc. Note that SOCKS5 or TURN will not work since they disallow 
servers by design.

In that perspective, I'd much rather see a simple NATed client to non-NATed 
server traversal scheme. Quick.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Jul 2007 08:28:26 -0700

> I might be pessimistic, or I might perceive a distortedly bad 
> reality of NATs (due to having only Linux-based symmetric NATs 
> around me).  Still, I really doubt RTSP will fly if both sides 
> are behind different NATs.  I do think the success rate will 
> be too low - without relays nor UPnP-ICD/NAT-PMP. But only 
> time will tell.

Yes, that could well be true.  But if you can purchase a UPnP-
or NAT-PMP-capable NAT, you could (in theory) also purchase 
a non-filtering NAT.  And ICE doesn't _require_ you learn
all of your addresses using STUN -- you could learn your 
address via UPnP, NAT-PMP, MIDCOM, SIMCO, or a variety of
other techniques, too.

I would certainly find it reasonable that anyone wanting
to serve RTSP content, from behind their NAT, is required
to have only a non-symmetric and non-address-filtering NAT.

> *However*, even if UDP traversal turns out to work, how do 
> you get the TCP control connection through in the first 
> place, if the server is NATed? 

If you're behind a NAT that doesn't do any filtering, you 
can poke a hole in that NAT, learn your IP address and TCP
port, and advertise that (via DNS SRV records in Dynamic
DNS).

But you are right that if you're behind a NAT doing address 
filtering (or, worse, 'symmetric'), you won't be able to
successfully serve RTSP content unless something on the 
Internet proxies the RTSP messages for you (and you maintain
a TCP connection to that proxying device).  In that same case,
for media, if the other peer is also behind a 'symmetric' 
NAT or an 'address and port filtering' NAT, the media will 
have to be relayed, too.

> So, you end up requiring some kind of port forwarding: 
> manual port-triggering, UPnP-ICD or NAT-PMP on the 
> server's NAT anyway; or (IPv6) tunneling: Teredo, 
> AYIYA, etc. Note that SOCKS5 or TURN will not work since 
> they disallow servers by design.
> 
> In that perspective, I'd much rather see a simple NATed 
> client to non-NATed server traversal scheme. Quick.

I believe everyone interested in IPTV wants that, too.  
I am interested in IPTV.

However, I would like to understand the difference between 
the "Symmetric RTP Variant" (discussed in the draft) and
ICE-lite.  I think they are similar, but I admit that I 
don't fully grasp what all "symmetric RTP variant" might 
be doing when it is fully specified.

If ICE-Lite and "Symmetric RTP Variant" are similar, would
you still want "Symmetric RTP Variant"?

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 10 Jul 2007 11:45:29 +0300

> you still want "Symmetric RTP Variant"?

I suspect ICE-Lite requires a bunch of state be kept and intricate processing 
be done on both sides. That's really overkill when all we need for NATed 
client to public server is a three-way handshake, à la TCP (though likely 
with more entropy), and client-to-server keep-alives (RTCP RRs, I suppose).

I may have gotten ICE-Lite wrong though.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Jul 2007 17:56:32 +0200

> I may have gotten ICE-Lite wrong though.

Thanks for the comments.

I will try to incorporate the comments in the next version. However, I 
do like to point out two things. There exist a consensus on using ICE 
type of mechanism. It simply is that we haven't come to the point where 
we actually have specified the mechanism. So if you like to tear up 
this, you better have good arguments.

Secondly, is that ICE really helps with the DDoS security issue we do 
have with RTSP today. Utilizing public streaming servers to deliver 
content to an attackers target get substantially harder with checks in 
the server to client direction. Sure, you could define mechanism that 
include these checks also. But, then in reality I don't see them being 
easier than ICE in any sense. Also please remember that streamin server 
with a public IP address only needs a single candidate. That cuts down 
the number of checks and everything substantially. While still having a 
mechanism that can be made to work when deploying servers behind NATs. 
It also leverage the existing specifications rather than rewriting things.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 11 Jul 2007 10:21:38 +0300

Hello,

> this, you better have good arguments.

Using full ICE on the server only makes sense if you specify some traversal 
mechanism for the control connection in the first place.

Using ICE-Lite will indeed make the whole thing "relatively" simple on the 
server. On the client side, it will only simplify things if clients are 
allowed to only support ICE-Lite servers: In that case, the client can assume 
it is the controlling node. Most importantly, there is no need for the client 
to signal its candidates to the server (they'd be ignored anyway), so I would 
assume there is no need to "extend" the encoding already specified in ICE: 
server uses SDP encoding, client does not use any encoding at all...

I am only worried that people may want to use ICE -particularly full ICE- with 
unrealistic hopes (such as a satisfactory success rate for NATed RTSP 
servers). In that case, we may end up with something overly complex with 
little benefits. If the RTSP client happens to be a SIP client too, using ICE 
is surely good. But many RTSP clients are media players rather than 
softphones, and they surely do not have SIP.

> have with RTSP today.

I totally agree. I was trying to point out that any three-way handshake (with 
a pseudo-random ID into it) solves this too.

> Utilizing public streaming servers to deliver content to an attackers target
> get substantially harder with checks in the server to client direction.

I do hope that non-ICE RTSP servers refuse to stream to a destination address 
that does not match the source of the control connection (so it can leverage 
the TCP three-way handshake as a basic security check), unless there is some 
other reason to trust the client.

> Sure, you could define mechanism that 
> easier than ICE in any sense.

If the mechanism that is to be proposed is that easy, I am fine with it. If 
it's ICE-based, all the better for those who ship both SIP and RTSP (such as 
my employer's devices) :-)

> Also please remember that streamin server 

[To me, specifications reuse/factorization is of very little value compared to 
sound design and ease of implementation. I believe implementation and 
operational costs to be largely superior to specification ones. That's a 
personnal view though.]

Best regards,

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Jul 2007 09:40:32 +0200

Hi,

I hear your arguments, and I think ICE for RTSP will not in reality 
become too complex. I think there are a number of ways to cut down the 
percieved complexities of ICE in an RTSP case.

Using STUN for the connectiviy checks seems to me be beneficial from the 
point of not specifying yet another alternative. Implementations can be 
reused, etc. Also it has the benefit of being more media transport 
protocol agnostic than most alternatives, like building something into 
RTP or RTCP.

However, the only node I am willing to make assumptions about knowing 
where they really are deployed are servers. A server with public IP 
address can have a configuration option that makes them cut down the 
croft. I see two benefits from them. A single candidate and the 
possibility to only use triggerd checks. If the server indicates this 
the client can basically utilzie a single candidate itself. The main 
issue with this is the signalling flow for RTSP that makes the 
specification of such optimzations more difficult.

However, we currently are at a stage where we need to flesh out ICE for 
RTSP into something that actually will work.

Cheers

Magnus

-- 

Magnus Westerlund