Subject: RE: [MMUSIC] RTSP: Transport negotiation

From: Thomas Zeng <[email-masked]>
Date: Tue, 16 Sep 2003 11:15:30 -0700

Hi Magnus:

First off, I think you mis-understood me. I was not suggesting that the
client chooses SSRC in SETUP request,
I was just presenting arguments to support including RTP-Info header in a
re-SETUP response. The server then has the
option to specify a new SSRC, along with the seqnum and TS at the point of
switching to new transport as requested by the client in the re-SETUP
request. Since some client, such as PacketVideo's, performs packet filtering
based on SSRC, we would have less a chance to get mixed up at the switching
point.  This is also a defensive measure towards DoS attacks, in that less
CPU-cycles are expended on furthur processing the RTP packets -- simply
filter them out by SSRC.

Hence my argument about security advantage.

In pseudo code, this is:

If (seqnum < swithcing_point_seqnum)
   filter_with_old_ssrc
else
   filter_with_new_ssrc

Come to think about it, the rtp_timestamp in the RTP-Info is less useful in
the re-SETUP scenario. The purpose of 
including RTP-Info in re-SETUP response is to assist client in switching to
new Transport end-point, rather than
timing syncronization.

I hope this is more clear, and would present the case to insert in
rfc2326bis-04, the text such as: 
"A SETUP response in  re-SETUP scenario that changes Transport parameters,
SHOULD include RTP-Info in the SETUP response to assist client to know
exactly what is the time to use new Transport end-point".

Thanks,
thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Tuesday, September 16, 2003 12:36 AM
To: Thomas Zeng
Cc: [email-masked]
Subject: Re: [MMUSIC] RTSP: Transport negotiation

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

Thomas Zeng wrote:

> 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
> 
-- 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Sep 2003 11:16:32 +0200

Hi,

Yes, I did mis-understood you. So you desire is that if the server would 
switch SSRC to a new one you have the necessary information. Such a 
switch has also impact on the synchronization, as a new SSRC means a new 
RTP sequence and timestamp space, which needs synchronization. This 
means that both the Range and the RTP-Info header MUST be sent in such 
case.

The advantage of including RTP-Info with seq. information is that is 
allows the client to know if he has lost packets on the old interface or 
the new one.

Based on this it seems to be a good idea to include the two headers 
(Range and RTP-Info) always in a re-SETUP. My only question is that if 
we could write MUST or if that will have any backwards compatibility 
problems? Are there any clients or servers that support re-SETUP today?

See more comments below.

> CPU-cycles are expended on furthur processing the RTP packets -- simply

I hope you are aware of the implications of doing this filtering is that 
your client can't handle multi SSRC scenarios. If no SSRC is present in 
the Transport header, do you lock down on the first SSRC received?

Using this as a defence against a DOS attack does not seem especially 
good, it only prevents other traffic from ending up in the streaming 
application, it will still have negative effect it the traffic overloads 
the network or network interface. Do not interpret this as I am against 
protecting the client from stray packets entering on the receiving port. 
This is the reason why a RTP stack should have probation mechanism for 
SSRC not received RTCP or sufficiently many consecutive packets. However 
this mechanism is mostly a protection from random packets. The only true 
and not application hurting mechanism against planned packet insertion 
into a stream is to use authentication.

> new Transport end-point, rather than

No, if the SSRC switches the TS parameter and Range header must be there 
for synchronization.

> exactly what is the time to use new Transport end-point".

Lets see if it would be acceptable to make it mandatory together with 
the Range header.

Cheers

Magnus Westerlund