Subject: [MMUSIC] RTSP & NAT: Symmetric RTP

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2003 13:50:06 +0100

Hi,

During the last RTSP telecon we discussed symmetric RTP as a traversal 
mechanism for NATs, especially symmetric ones.

Basic idea behind symmetric RTSP: A for each media stream the server 
ports are defined as both send and receive ports. The client sends RTP 
and RTCP on respective port. The server upon reception of the IP/UDP/RTP 
packet takes that packets sender port and address as clients ports. 
Thereby ignoring what has been said in the signaling.

RTSP updates needed: Server support is needed and they must be able to 
indicate this. Therefore a client request symmetric RTP behavior through 
the use of a new transport header parameter. There are also need for a 
feature tag to be able to detect this feature prior to setup.

Security risks: Hi-jacking of media streams. The basic problem is that 
any RTP/RTCP traffic arriving to the sender port prior to the clients 
message will result in redirection of the media stream to the sent 
packets address and port. This allows an attacker to spoof the sender 
IP/port number to that of a target of an Distributed DOS attack. This 
can basically be done without being on the path between client and 
server by simple guessing port numbers.

Good Solution: Create a RTP payload format that carries session 
identifier and a sufficient large random tag that prevents guessing. 
However due to NATs and the setup this can never be ensured against 
attackers located on the path between client and server.

Maybe adequate solution: Only allow RTP messages from same IP as control 
session arrives from. The SSRC must also be correct as signaled through 
an new client_SSRC parameter in Transport header. This would force an 
attacker to: 1) be behind the same NAT and receive the same IP from the 
NAT as the legitimate client. 2) Require the attacker to be able to read 
the RTSP control traffic. Guessing will be at one per 2^31 probability 
unless bad random values are used.

The maybe adequate solution does have the restriction that a NAT must 
ensure to use the same IP address for both the RTSP control binding and 
the media flows bindings.

Problems: The client does normally not send RTP traffic to server. May 
create problems with RTSP aware proxies. They should however be 
corrected to not interfere as this will also be a problem for RECORD 
streams. More important is that there is lack of mechanism to negotiate 
what RTP payloads that will be used in direction client->server. This 
will be a problem independent if we use a authentication payload or any 
other payload. To allow the adequate security to work we need at least a 
RTP header in the upstream traffic on the RTP channel carrying a SSRC. A 
default behavior of reusing a downstream RTP payload type with an empty 
payload could be used. The RTCP streams has no problems of this kind.

Conclusion:
Symmetric RTP can be used with a minimal change to allow servers to 
create bindings based on incoming RTP/RTCP packets. The stream will 
always be possible to hijack by a man in the middle on the path between 
server and client.

basic security: Use SSRC as secret identifier of client. Gives 1/2^31 
probability of guessing. Requires extra transport header parameter 
"client_ssrc".

basic+ security: Requires media flow bindings IP address to have same 
address as RTSP connection. Both requires at least default rule on how 
to send RTP packets to server.

best possible: Create special payload for identification and binding of 
symmetric RTP ports. Can use any size of random tag. Creates problem 
with what RTP payload type to use. Or could be sent on plain UDP.

This presents my view on how symmetric RTP could be used with RTSP 
sessions.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Feb 2003 08:11:53 -0500

I agree that symmetric RTP is clearly the best solution for RTSP as it 
is used today. I do not believe that relying on source IP being the same 
  between the RTSP and RTP sessions is a good idea. This won't work in 
enterprises which may be natting into a multiplicity of IP addresses.

I would also strongly advise not to mandate that as the one and only one 
solution for nat traversal. A client should be allowed to do other 
things, and you want to leave the door open for better solutions down 
the road.

As for the random identifiers, I will note that I recently proposed such 
a mechanism in support of connection oriented media. This draft also 
discusses the attack you are talking about:

http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt

-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: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2003 16:04:17 +0100

Hi Jonathan,

Comments:

Jonathan Rosenberg wrote:

> is used today. I do not believe that relying on source IP being the 
> same  between the RTSP and RTP sessions is a good idea. This won't 
> work in enterprises which may be natting into a multiplicity of IP 
> addresses.

I agree that requiring IP address to be same may be to restrictive and 
create a lot of problems. I think that a sufficiently strong solution of 
identifying the end-point anyway is enough.

>
> I would also strongly advise not to mandate that as the one and only 
> one solution for nat traversal. A client should be allowed to do other 

We are not planning to require any one solution. It is planned to make a 
draft about RTSP and NAT traversal. This will document and write up 
rules how to use the different mechanism and what to consider. Also what 
to think when writing firewall ALGs will be documented. The solution 
that the draft currently will discuss is:
1. STUN
2. Symmetric NAT
3. TCP tunneling
4. ALG (not recommended)

>
> As for the random identifiers, I will note that I recently proposed 
> such a mechanism in support of connection oriented media. This draft 
> also discusses the attack you are talking about:
>

I will further discuss this in a reply to David Yon's reply.

Best Regards

Magnus Westerlund

---

From: David Yon <[email-masked]>
Date: Mon, 10 Feb 2003 09:43:20 -0500

As Jonathan points out in his reply, a similar attack is being discussed in 
the context of comedia/comedia-fix.  The proposed solution in comedia-fix 
is to window the protocol by always starting the stream with a unique ID 
prior to sending packets using the protocol that has been signalled in the 
SDP.  My discontent with this mechanism is well documented in that email 
thread.

If there is to be some sort of session correlation embedded in the media, I 
would greatly prefer the approach you are suggesting.  I.e., make the 
endpoint ID be something derived from the protocol proper, rather than 
inserting the ID out-of-band in relation to the signalled protocol.

As evidenced by this RTSP discussion, this need exists outside the scope of 
connection-based media, so perhaps comedia isn't the place to document a 
generic media/session correlation mechanism.

If one accepts the notion that connectionless media has this need for 
session correlation, then it becomes clear that the comedia-fix proposal is 
not equipped to address the problem in this larger scope.  What immediately 
comes to my mind is how to window the protocol when the media is carried 
over unreliable transport (i.e., UDP).  Since there is no guarantee of 
ordering or delivery, the sender cannot simply just send the first packet 
with the endpoint ID.  The packet may never arrive at the receiver, or it 
may arrive after other media packets.  So the receiver has no reliable way 
of parcelling out the endpoint ID from the in-band media, unless of course 
the endpoint ID is encoded within the framework of the media itself.

This is sounding more and more to me like endpoint ID is a standalone 
topic.  Perhaps a short I-D that documents the need and the SDP syntax, 
plus globbing together a few of the more obvious protocol extensions (i.e., 
the RTP suggestion discussed below).

At 07:50 AM 2/10/2003, Magnus Westerlund wrote:

>Security risks: Hi-jacking of media streams. The basic problem is that any 
>RTP/RTCP traffic arriving to the sender port prior to the clients message 
>will result in redirection of the media stream to the sent packets address 
>and port. This allows an attacker to spoof the sender IP/port number to 
>that of a target of an Distributed DOS attack. This can basically be done 
>without being on the path between client and server by simple guessing 
>port numbers.
>
>Good Solution: Create a RTP payload format that carries session identifier 
>and a sufficient large random tag that prevents guessing. However due to 
>NATs and the setup this can never be ensured against attackers located on 
>the path between client and server.
>
>Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2003 16:52:28 +0100

Hi David,

For RTSP and RTP usage it seems possible to make the whole process work 
using the RTP SSRC. In RTP flows that is present in the RTP header 
making it simple to handle. For RTCP it becomes even more important that 
it can be sent in the context of RTCP. RTCP traffic will flow through 
out the whole session. Therefore a special demultiplexing between RTCP 
and binding messages will be difficult.

Using SSRC requires a simple parameter addition to the transport header. 
The client simple tells the server what to use. However the big question 
is if a 32 bit SSRC value is unique enough to function well. A RTSP 
server at least has the advantage that it can use multiple sending 
ports. If a client SSRC proposal already is in use on some port this can 
simple be sent to a different sender port.

Using other methods of transporting this ID on top of UDP or other 
transport protocols create problems. Defining a general format that is 
simple used creates multiplexing problems for all use cases. For RTP it 
could be possible to define both a RTP payload format and a RTCP packet 
type that can be sent containing a general type of ID.

Best Regards

Magnus

David Yon wrote:

> As Jonathan points out in his reply, a similar attack is being 
> discussed in the context of comedia/comedia-fix.  The proposed 
> solution in comedia-fix is to window the protocol by always starting 
> the stream with a unique ID prior to sending packets using the 
> protocol that has been signalled in the SDP.  My discontent with this 
> mechanism is well documented in that email thread.
>
> If there is to be some sort of session correlation embedded in the 
> media, I would greatly prefer the approach you are suggesting.  I.e., 
> make the endpoint ID be something derived from the protocol proper, 
> rather than inserting the ID out-of-band in relation to the signalled 
> protocol.
>
> As evidenced by this RTSP discussion, this need exists outside the 
> scope of connection-based media, so perhaps comedia isn't the place to 
> document a generic media/session correlation mechanism.
>
> session correlation, then it becomes clear that the comedia-fix 
> proposal is not equipped to address the problem in this larger scope.  
> What immediately comes to my mind is how to window the protocol when 
> the media is carried over unreliable transport (i.e., UDP).  Since 
> there is no guarantee of ordering or delivery, the sender cannot 
> simply just send the first packet with the endpoint ID.  The packet 
> may never arrive at the receiver, or it may arrive after other media 
> packets.  So the receiver has no reliable way of parcelling out the 
> endpoint ID from the in-band media, unless of course the endpoint ID 
> is encoded within the framework of the media itself.
>
> topic.  Perhaps a short I-D that documents the need and the SDP 
> syntax, plus globbing together a few of the more obvious protocol 
> extensions (i.e., the RTP suggestion discussed below).
>
>> Security risks: Hi-jacking of media streams. The basic problem is 
>> that any RTP/RTCP traffic arriving to the sender port prior to the 
>> clients message will result in redirection of the media stream to the 
>> sent packets address and port. This allows an attacker to spoof the 
>> sender IP/port number to that of a target of an Distributed DOS 
>> attack. This can basically be done without being on the path between 
>> client and server by simple guessing port numbers.
>>

-- 

Magnus Westerlund

---

From: David Yon <[email-masked]>
Date: Mon, 10 Feb 2003 12:15:17 -0500

Using SSRC was mentioned a long time ago, although at the time dismissed as 
too protocol-specific.  But the context of the discussion has changed, and 
if that works then I have no problem with it in principle.  That said, 
there was at least one other concern voiced about whether 32 bits is 
sufficient.  It also begs the question of what format to use for an 
endpoint-ID, and whether this format is to be fixed or variable.  One 
approach would be to make the endpoint-ID format specific on a per-protocol 
basis, with a limited number of choices (it seems like string and integer 
would cover most needs).

I'm not sure I followed you exactly, but I read your first paragraph to 
mean that using a windowed protocol approach for endpoint ID is even more 
of a problem in the context of RTCP.  Is that a fair interpretation?

At 10:52 AM 2/10/2003, Magnus Westerlund wrote:
>using the RTP SSRC. In RTP flows that is present in the RTP header making 
>it simple to handle. For RTCP it becomes even more important that it can 
>be sent in the context of RTCP. RTCP traffic will flow through out the 
>whole session. Therefore a special demultiplexing between RTCP and binding 
>messages will be difficult.
>
>is if a 32 bit SSRC value is unique enough to function well. A RTSP server 
>at least has the advantage that it can use multiple sending ports. If a 
>client SSRC proposal already is in use on some port this can simple be 
>sent to a different sender port.
>
>>As Jonathan points out in his reply, a similar attack is being discussed 
>>in the context of comedia/comedia-fix.  The proposed solution in 
>>comedia-fix is to window the protocol by always starting the stream with 
>>a unique ID prior to sending packets using the protocol that has been 
>>signalled in the SDP.  My discontent with this mechanism is well 
>>documented in that email thread.
>>
>>If there is to be some sort of session correlation embedded in the media, 
>>I would greatly prefer the approach you are suggesting.  I.e., make the 
>>As evidenced by this RTSP discussion, this need exists outside the scope 
>>of connection-based media, so perhaps comedia isn't the place to document 
>>a generic media/session correlation mechanism.
>>
>>session correlation, then it becomes clear that the comedia-fix proposal 
>>is not equipped to address the problem in this larger scope.
>>What immediately comes to my mind is how to window the protocol when the 
>>media is carried over unreliable transport (i.e., UDP).  Since there is 
>>no guarantee of ordering or delivery, the sender cannot simply just send 
>>the first packet with the endpoint ID.  The packet may never arrive at 
>>the receiver, or it may arrive after other media packets.  So the 
>>receiver has no reliable way of parcelling out the endpoint ID from the 
>>in-band media, unless of course the endpoint ID is encoded within the 
>>framework of the media itself.
>>
>>plus globbing together a few of the more obvious protocol extensions 
>>(i.e., the RTP suggestion discussed below).
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Feb 2003 23:56:50 -0500

inline.

> identifying the end-point anyway is enough.

I would like to see the ability to specify the client IP/port for rtp 
and rtcp so as to allow RTSP to work with stun, turn and other related 
protocols, even if there is a separate endpoint id mechanism.

-Jonathan R.

---

From: Tom Marshall <[email-masked]>
Date: Mon, 10 Feb 2003 22:46:00 -0800

> protocols, even if there is a separate endpoint id mechanism.

It would seem to me that a new parameter is appropriate.  client_port
implies that only a port number is given.  Perhaps something like this could
serve as an endpoint specifier with addresses?

"client_addr" "=" addr_list
addr_list -> addr_list "/" addr || addr  
addr      -> ip4addr || ip6addr  
ip4addr   -> ip4host || ip4host ":" port  
ip6addr   -> ip6host || ip6host ":" port   
ip4host   -> hostname || ip4literal  
ip6host   -> hostname || ip6literal  
port      -> <digits>            
hostname  -> <standard dns hostname>  
ip4literal-> <digits and dots>  
ip6literal-> "[" <hex quads with colons> "]"  

.. and perhaps a note saying that client_addr is mutually exclusive with
client_port, source, and destination parameters.

Comments?

-- 
Happiness isn't something you experience; it's something you remember.
        -- Oscar Levant

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Feb 2003 12:08:57 +0100

Hi David,

David Yon wrote:

> Using SSRC was mentioned a long time ago, although at the time 
> dismissed as too protocol-specific.  But the context of the discussion 
> has changed, and if that works then I have no problem with it in 
> principle.  That said, there was at least one other concern voiced 
> about whether 32 bits is sufficient.  It also begs the question of 
> what format to use for an endpoint-ID, and whether this format is to 
> be fixed or variable.  One approach would be to make the endpoint-ID 
> format specific on a per-protocol basis, with a limited number of 
> choices (it seems like string and integer would cover most needs).

My feeling is that 32 bits are enough for this. Because a brute force 
attack is not possible without the receiving end-point notice it. If 
good random numbers are used then it seem difficult enough to guess 
within a few message the correct one out of the 4.2 billion ones possible.

>
> I'm not sure I followed you exactly, but I read your first paragraph 
> to mean that using a windowed protocol approach for endpoint ID is 
> even more of a problem in the context of RTCP.  Is that a fair 
> interpretation?

Yes, the problem as I see it to safely demultiplex between ordinary 
traffic and the endpoint ID message.

Best Regards 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Feb 2003 12:21:38 +0100

Hi Tom,

I think this is a good idea, however we will still have the DOS attack 
problems when specifying addresses other then the ones the RTSP 
connection uses. I don't have a good way of solving this.

As you used a description format that is not the ABNF of RFC 2234 I 
converted it below.

>serve as an endpoint specifier with addresses?
client_addr = "client_addr" "=" addr_list
addr_list = addr  *("/" addr)
addr = ip4addr / ip6addr
ip4addr = ip4host [":" port]
ip6addr = ip6host [":" port]
ip4host = hostname / ip4literal
ip6host = hostname / ip6literal
port = 1*DIGIT
ip4literal = <digits and dots>  
ip6literal = "[" <hex quads with colons> "]"

Some small detail questions:
- Should the port range be limited to 16 bit values?
- What are the rules when it would be optional to specify port numbers?

Cheers

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Tue, 11 Feb 2003 08:50:55 -0800

> connection uses. I don't have a good way of solving this.

Unfortunately, I don't either.  Is it mandatory to solve it in the spec?  It
seems to me that the best solution is to have a challenge/response mechanism
for each transport.  But that is beyond the scope of RTSP.  Perhaps it would
be sufficient to say that the possibility for abuse exists and some form of
cryptographically secure challenge/response mechanism should be used if the
server allows sending to a different address than the client RTSP endpoint.

The most troublesome scenario is a NAT that maps the RTSP and transport
flows to different IP addresses.  How common is this?

> As you used a description format that is not the ABNF of RFC 2234 I 

[...]

Thank you.

> - Should the port range be limited to 16 bit values?

For UDP with IPv4 and IPv6, yes.  For others (non-UDP or IPv7+), who knows?

> - What are the rules when it would be optional to specify port numbers?

Perhaps a transport can have an implied or well-known port number, or a port
number is not applicable to it, etc.

-- 
A lot of people are afraid of heights.  Not me.  I'm afraid of widths.
        -- Steven Wright