headers
Thomas Zeng | 1 Mar 2003 01:14

Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Magnus:

I have a comment on 3.2 Symetric RTP.

As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server
normally uses a single RTP port (let's call it X) to send RTP packets to
many (potentially hundreds) of clients. Now Symetric RTP asks these clients
to send an RTP packet with their individual client SSRC in the payload to
this port X on the server host. Since each client randomly generates client
SSRC, there is some chance (as high as 10^-4 according to RFC1889, section
8.1) that two clients may end up with same SSRC, in which case the server
may send RTP packets to wrong clients. I did study the SSRC collision
detection scheme in RFC1889 and found it irrelevant because it only applies
to multicast RTP sessions. I don't think destination IP can help here since
prior to the establishment of binding  our server doesn't know clients
public IPs. Besides, the two collided clients may well be behind the same
NAT and hence probably share public IP.

I hereby suggest that the binding RTPs to add, in a fashion defined below,
client's RTSP sessionID in addition to client's SSRC in those binding RTP
packets. Notice RTSP sessionIDs are generated by the server and hence can be
made unique amongst all clients of that server.

The session ID happens to provide other niceties:

1. One client only has to make sure that its client SSRCs are unique amongst
the RTP tracks it has in the session (if it happens to have more than one
track)
2. Since RTSP session ID can be 64 bytes or longer, it offers added
protection against stream hijacking or brute force attacks (since now the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Magnus Westerlund | 3 Mar 2003 10:13
Picon
Picon

Re: Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Hi Thomas,

Comments below:

Thomas Zeng wrote:

>Magnus:
>
>I have a comment on 3.2 Symetric RTP.
>
>As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server
>normally uses a single RTP port (let's call it X) to send RTP packets to
>many (potentially hundreds) of clients. Now Symetric RTP asks these clients
>to send an RTP packet with their individual client SSRC in the payload to
>this port X on the server host. Since each client randomly generates client
>SSRC, there is some chance (as high as 10^-4 according to RFC1889, section
>8.1) that two clients may end up with same SSRC, in which case the server
>may send RTP packets to wrong clients. I did study the SSRC collision
>detection scheme in RFC1889 and found it irrelevant because it only applies
>to multicast RTP sessions. I don't think destination IP can help here since
>prior to the establishment of binding  our server doesn't know clients
>public IPs. Besides, the two collided clients may well be behind the same
>NAT and hence probably share public IP.
>  
>

My first comment is that the easiest way of solving this problem, is for 
the server to send from different ports for each client. That way you 
reduce the probability of collisions and ensures maximum security in 
respect to hijacking.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Yon | 3 Mar 2003 14:38

draft-ietf-mmusic-sdp-comedia-05.txt available

I have submitted draft-ietf-mmusic-sdp-comedia-05.txt to the IETF in prep 
for the 56th meeting.  A draft copy is available now from:

http://www.rfdsoftware.com/ietf/draft-ietf-mmusic-sdp-comedia-05.txt

I have removed all references to the source address and the 
firewall-related security considerations.  What I did not have time to do 
is incorporate the security issues raised by comedia-fix, but I think those 
are worthy of at least a brief discussion at the 56th.

Please look over the draft and let me know whether there are any remaining 
concerns.
Permalink | Reply | 0 comments |
headers
Tom Marshall | 3 Mar 2003 18:52
Picon
Favicon

Re: Comments on draft-ietf-mmusic-rtsp-nat-00.txt

On Mon, Mar 03, 2003 at 10:13:52AM +0100, Magnus Westerlund wrote:
> Hi Thomas,
> 
> Comments below:
> 
> Thomas Zeng wrote:
> 
> >Magnus:
> >
> >I have a comment on 3.2 Symetric RTP.
> >
> >As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server
> >normally uses a single RTP port (let's call it X) to send RTP packets to
> >many (potentially hundreds) of clients. Now Symetric RTP asks these clients
> >to send an RTP packet with their individual client SSRC in the payload to
> >this port X on the server host. Since each client randomly generates client
> >SSRC, there is some chance (as high as 10^-4 according to RFC1889, section
> >8.1) that two clients may end up with same SSRC, in which case the server
> >may send RTP packets to wrong clients. I did study the SSRC collision
> >detection scheme in RFC1889 and found it irrelevant because it only applies
> >to multicast RTP sessions. I don't think destination IP can help here since
> >prior to the establishment of binding  our server doesn't know clients
> >public IPs. Besides, the two collided clients may well be behind the same
> >NAT and hence probably share public IP.
> > 
> >
> 
> My first comment is that the easiest way of solving this problem, is for 
> the server to send from different ports for each client. That way you 
> reduce the probability of collisions and ensures maximum security in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Zeng | 4 Mar 2003 00:37

RE: Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Magnus, Tom:

Another reason that ports are precious resource on the server is that, a
well designed
streaming server may be able to scale up to 10000 simultaneous clients
(which Microsoft's Windows Media server claims to support... I know
Microsoft today doesn't use RTSP but it may in the future). If each has 6
RTP tracks then there will not be enough ports to go around with Magnus
proposal.

Therefor I still think we must be prepared to resolve client SSRC conflict.
Someone suggested that we can put in the "contributing SSRC" field the
server's SSRC for that session. The combination of client SSRC and server
SSRC in the binding RTP packets would be certainly possible to ensure
uniqueness (since the server can choose its SSRC with no collision).

What do people think?

- thomas

-----Original Message-----
From: Tom Marshall [mailto:tmarshall <at> real.com]
Sent: Monday, March 03, 2003 9:52 AM
To: Magnus Westerlund
Cc: Thomas Zeng; mmusic <at> ietf.org
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt

On Mon, Mar 03, 2003 at 10:13:52AM +0100, Magnus Westerlund wrote:
> Hi Thomas,
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 4 Mar 2003 10:34
Picon
Picon

Re: Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Hi Thomas and Tom,

I understand your performance considerations. I know we have discussed 
this before on the teleconference. One reason raised for poor port 
performance was the lack of optimized implementations. For example 
linear search that of course give works performance as the number of 
ports increase.

Should we fix this problem I think we should design something that are a 
general mechanism that actually help us in other cases. Therefore my 
suggestion is still to construct a RTP payload format and a RTCP packet 
type that can carries challenge and responses containing security tags.

Thomas Zeng wrote:

>Magnus, Tom:
>
>Another reason that ports are precious resource on the server is that, a
>well designed
>streaming server may be able to scale up to 10000 simultaneous clients
>(which Microsoft's Windows Media server claims to support... I know
>Microsoft today doesn't use RTSP but it may in the future). If each has 6
>RTP tracks then there will not be enough ports to go around with Magnus
>proposal.
>

At least not with only a single IP address.

>
>Therefor I still think we must be prepared to resolve client SSRC conflict.
(Continue reading)

Permalink | Reply | 0 comments |
headers
philippe.gentric | 4 Mar 2003 14:31
Picon

Re: Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Magnus,

Would not this look an awfull lot like STUN then ?

regards,

Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric <at> philips.com
http://www.platform4.philips.com

                                                                                                                                              

                                                          To:   Thomas Zeng <zeng <at> packetvideo.com>                                            
                                                          cc:   "'Tom Marshall'" <tmarshall <at> real.com>                                         
                                                           mmusic <at> ietf.org                                                                    
                                                           (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
               Magnus Westerlund                          Subject:    Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt              
               <magnus.westerlund <at> era.ericsson                                                                                                
               .se>                                       Classification:                                                                     

               Sent by:                                                                                                                       
               mmusic-admin <at> ietf.org                                                                                                          

               04/03/2003 10:34                                                                                                               

Hi Thomas and Tom,

I understand your performance considerations. I know we have discussed
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 4 Mar 2003 15:05
Picon
Picon

Re: Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Hi, Phillipe,

My proposal:

Should we fix this problem I think we should design something that are a
general mechanism that actually help us in other cases. Therefore my
suggestion is still to construct a RTP payload format and a RTCP packet
type that can carries challenge and responses containing security tags.

philippe.gentric <at> philips.com wrote:

>Would not this look an awfull lot like STUN then ?
>  
>
In some sense yes, but mostly no. The goal of this mechanism is to 
identify the intention of sending media and authorizing it. What it 
shares with STUN is the possibility to use it for NAT traversal.

The comparison with STUN would give the following advantages:
- Being integrated into RTP/RTCP it will not have the multiplexing 
problems of STUN.
- It can be used for the general DESTINATION problem of RTSP.

Disadvantage:
- Not being general, only useful with RTP. To solve the multiplexing the 
solution needs to be part of the media protocol. Problem for any 
solution that handles symmetric NAT. 

What this solution will not provide that STUN has is:
- Mechanism to learn the external mapping.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 4 Mar 2003 16:02
Picon
Picon

RTSP: Agenda telecon 5th March 18.00-19.30 CET.

Hi,

Sorry being this late. Here is the proposed agenda for tomorrow's telecon.

1. Follow up:
    - draft-ietf-mmusic-rfc2326bis-03.txt
    - Interleave: Aravind to write text and post to MMUSIC to address 
all four bugs.
    - Everybody reads on offer/answer (RFC 3264) and meet in next IETF 
meeting to take next step.

2. What to discuss during the IETF and the MMUSIC session.
    -  What to take up to the whole WG:
        + The last changes
        + Open issues that need input?
    - Off line session
        + Offer Answer for RTSP?
        +
3. New Issues:
* Unclarities when doing resetup
  http://rtsp.org/bug513737

* Conference header underspecified
  http://rtsp.org/bug539040

* "Clarify Range Where t0 <= t1" & "How to use Range when Scale is 
negative"
  http://rtsp.org/bug533691
  http://rtsp.org/bug513880
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 4 Mar 2003 16:09
Picon
Picon

New Core RTSP draft: draft-ietf-mmusic-rfc2326bis-03.txt

Hi,

Rob and I manage to submit a new version of the RTSP updated draft. Most 
of the given comments has found its way into the version. However due to 
lack of time I am not sure I managed to edit all the comments given on 
this draft. So please let me ask forgiveness already now. Please send 
any comments on the draft to the list. I am also sorry that the draft 
has managed to get even thicker. It is now 138 pages in the text version.

To fetch it before being announce, see:

http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.txt
http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.ps
http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf

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: magnus.westerlund <at> era.ericsson.se
Permalink | Reply | 0 comments |

Gmane