Subject: RE: [MMUSIC] RTSP: Transport negotiation

From: Thomas Zeng <[email-masked]>
Date: Mon, 15 Sep 2003 08:22:37 -0700

Hi Magnus, Aaron:

The need for RTPInfo in the SETUP response in this case (i.e., re-setup to
change transport parameters) also comes from security.

Imagine a senario where the client suspects that some hacker has figured out
the SSRC, seqnum, TS, ip and port etc. and  is spoofing RTP traffic, it may
send a SETUP to change to a different port. To make it harder for that
hacker to do damage again, allowing packets to new traffic to use new seqnum
and TS offsets is consistent with
RFC1889's security philosophy.

More, server SSRC is actually an optional paramater in Transport header,
judging by above scenario there is a use case to allow using RE-SETUP to
request server to use new SSRC -- it should be allowed for server to use new
SSRC if it wants to do it for security purposes. If so, the server should
indicate the seqnum and RTP TS from which the new SSRC becomes effective, to
assist clients that filter out packets based on SSRC ( which our clients
do).

THanks,
thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Monday, September 15, 2003 12:22 AM
To: Aaron Colwell
Cc: [email-masked]
Subject: Re: [MMUSIC] RTSP: Transport negotiation

Hi Aaron,

Aaron Colwell wrote:

> I think RTP-Info will be needed if the transport changes and the
> new transport uses a different timestamp offset than the original 
> transport. In this case you would need an RTP-Info with an rtptime field. 
> You may also want to include a seq field so the client knows the
> sequence number of the first packet with the  new offset. 
> 

Yes, I agree that if one allows the TS to change, however is that 
necessary to allow. Unless one switches media protocol I don't see a 
reason of changing the timeline when one changes lower layer transport 
protocol or simply moves the delivery address. So are there any need for 
this?

I guess getting the sequence number will only help to determine when the 
last packet has arrived on the previous transport. However this will 
also be clear when the first packet on the new transport arrives.

I think that we can specify that Range and RTP-Info shall be included, 
however from my point of view that would simply be for completeness and 
future safety. I don't see that there are any real need for this as long 
as we require the server to keep the timeline over transport changes.

> I also have a question about the RTP-Info fields in a SETUP response. Will

> the rtptime value map to the range header that was in the PLAY request or 
> response, just like the RTP-Info in the PLAY response? Doing that makes 
> the most sense to me and simplifies the implementation.
> 

I would say that it shall map to the Range header in the SETUP response 
the same way it is for PLAY. However lets see if it is needed at all.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Sep 2003 09:35:39 +0200

Hi Thomas,

I don't know if what you describe provides any real security 
enhancement. The real protection against this attack is to use 
authentication of each packet, that way one can ensure that no spoofed 
packets are used. Otherwise it seems that an attacker capable of the 
attack you describe most likely have access either to the signalling 
channel or the media stream itself. Therefore moving the session will 
not provide you with any improved security.

Neither do you understand how what you describe relates to RFC 1889 or 
RFC 3550 described security features. RFC 3550 talks about either 
relying on exterior means for confidentiality and authentication, i.e. 
IPSec or SRTP, or the old RTP DES method for confidentiality which is 
rather unsafe.

In regards to the usage of Range and RTP-Info, I think that they MAY be 
used, but it is RECOMMENDED to not change the timing unless necessary. 
If one changes the timing then the server MUST include Range and RTP-Info.

When it comes to the SSRC in SETUP requests I don't know if this 
motivates this. Allowing the client to force the server to use a SSRC is 
also a security risk in that case. The current resolution of this issue 
is documented in source forge bug 663715, see
https://sourceforge.net/tracker/?group_id=23194&atid=377744&func=detail&aid=663715
I am not willing to tear up this without better motivation and agreement 
by other people.

Cheers

Magnus

-- 

Magnus Westerlund