Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #110 - 7 msgs

From: [email-masked]
Date: Wed, 03 Dec 2003 20:05:47 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP (SourceForge.net)
   2. [ rtspspec-Bugs-853178 ] Security reisk with changing transport parameters (SourceForge.net)
   3. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP (SourceForge.net)
   4. [ rtspspec-Bugs-853178 ] Security risk with changing transport parameters (SourceForge.net)
   5. [ rtspspec-Bugs-853184 ] How to learn servers multicast capabilities (SourceForge.net)
   6. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net)
   7. [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 02:00:50 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP

Bugs item #853175, was opened at 2003-12-03 11:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Dest_addr needs indicator for using RTSP IP

Initial Comment:
The transport header parameters dest_addr and src_addr
that has been introduced to cope with non-adjacent
ports and same IP address for media transport protocols
like RTP that requries multiple streams to work. 

There seem to be motivated to ensure that previously
allowed behavoir to exclude giving a destination
address and instead have the server to deliver the
media to the source ip of the RTSP carrying TCP
connection. To enable this with the new paramters some
changes are required, the 05 version requries you to
put in some address. So either we change this, or
define a indicator for this behavior. 

This will allow that clients in private address spaces
using some addesstranslation techniuqes to use them
without being  requried to learn their external
address. Examples of such translation are realm
specific IP and NAT's without port translation. Please
do also note that for these translations the usage of
public STUN server works. 

However it should be noted the lack of destination
address is not without its consideration. IF an RTSP
proxy is used, it will be requried to add the
destination address, before forwariding any SETUP
request. There are also need to furhter review if any
furhter security considerations are needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 02:07:53 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-853178 ] Security reisk with changing transport parameters

Bugs item #853178, was opened at 2003-12-03 11:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Security reisk with changing transport parameters

Initial Comment:
To allow that transport parameters are changed during a
session will make hi-jacking attacks increadibly
simple, unless furhter protection mechanisms are used. 

The Attack: The client has established a RTSP session
with some media stream to a server. The attack is
capable to read the RTSP messages between client and
server. Thus gaining the session ID. When the session
is playing the attack can be simply sending SETUP
messages change the delivery to the attacker instead. 

Prevention techniques:
Encrypting RTSP messages will prevent the attacker from
easily learning the RTSP session ID, thus providing a
protection equal to the randomness of the session ID.

The real fix, requiring authentication of client when
performing  these changes to the session.  

Discussion need to determine what required security
protection that are needed. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 02:10:32 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP

Bugs item #853175, was opened at 2003-12-03 11:00
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Dest_addr needs indicator for using RTSP IP

Initial Comment:
The transport header parameters dest_addr and src_addr
that has been introduced to cope with non-adjacent
ports and same IP address for media transport protocols
like RTP that requries multiple streams to work. 

There seem to be motivated to ensure that previously
allowed behavoir to exclude giving a destination
address and instead have the server to deliver the
media to the source ip of the RTSP carrying TCP
connection. To enable this with the new paramters some
changes are required, the 05 version requries you to
put in some address. So either we change this, or
define a indicator for this behavior. 

This will allow that clients in private address spaces
using some addesstranslation techniuqes to use them
without being  requried to learn their external
address. Examples of such translation are realm
specific IP and NAT's without port translation. Please
do also note that for these translations the usage of
public STUN server works. 

However it should be noted the lack of destination
address is not without its consideration. IF an RTSP
proxy is used, it will be requried to add the
destination address, before forwariding any SETUP
request. There are also need to furhter review if any
furhter security considerations are needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 02:10:54 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-853178 ] Security risk with changing transport parameters

Bugs item #853178, was opened at 2003-12-03 11:07
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: Security risk with changing transport parameters

Initial Comment:
To allow that transport parameters are changed during a
session will make hi-jacking attacks increadibly
simple, unless furhter protection mechanisms are used. 

The Attack: The client has established a RTSP session
with some media stream to a server. The attack is
capable to read the RTSP messages between client and
server. Thus gaining the session ID. When the session
is playing the attack can be simply sending SETUP
messages change the delivery to the attacker instead. 

Prevention techniques:
Encrypting RTSP messages will prevent the attacker from
easily learning the RTSP session ID, thus providing a
protection equal to the randomness of the session ID.

The real fix, requiring authentication of client when
performing  these changes to the session.  

Discussion need to determine what required security
protection that are needed. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 02:16:09 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-853184 ] How to learn servers multicast capabilities

Bugs item #853184, was opened at 2003-12-03 11:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853184&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: How to learn servers multicast capabilities

Initial Comment:
If a media session is delivered through the usage of
multicast, the session description, to indicate that
delviery will be done to assigned multicast address. So
this is evident as long as you can put the multicast
address into the SDP and distribute it. 

However how does a client learn that a session can be
distributed as multicast, but no multicast address is
pre-assigned to the session when the SDP is published?
It seems that we can't quite express this case. Or does
someone see a possiblity? Is it something that needs to
be solved.

Another interesting use case is if a multicast
conference invites a RTSP server into the session and
the controlling entity request the server to play to
the already used multicast addresses. Does the server
needs to be able to announce this support, or is it
something the client simply ask for and the server
either succeds or fails?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853184&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 10:28:23 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1

Bugs item #533691, was opened at 2002-03-22 09:36
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: Clarify Range Where t0 <= t1

Initial Comment:
If the server receives a PLAY range from t0-t1, where
t0 < t1, should it reject the PLAY, or should the 
server play backwards as if the timescale is -1?

If t0 = t1, should the server send any media data 
after responding 200 OK?  
We've seen different servers behave differently in 
this scenario.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-12-03 10:28

Message:
Logged In: NO 

you should put pictures of scale bugs on this site, the life 
cycle of the bugs, the breeding  season of them, the 
geographic location, visual evidence of the damage the pests 
can do, the names of the plants or crops that the bugs go 
after, pesticides that can be used to kill the bugs, info about 
how to safely apply the pesticide, the dangers of the 
pesticide to the environment, and suggestions for ways to 
control the pest beside pesticides.

----------------------------------------------------------------------

Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 08:16

Message:
Logged In: YES 
user_id=437699

The following text has been added to the spec with regards
to this bug:

By default, range intervals increase, where the second point
is larger than the first point.

   Example:

       Range: npt=10-15

However, range intervals can also decrease if the Scale
header (see section  13.34) indicates a negative scale
value. For example, this would be the case when a playback
in reverse is desired.

   Example:

       Scale: -1
       Range: npt=15-10

Decreasing ranges are still half open intervals as described
above.  Thus, For range A-B, A is closed and B is open. In
the above example, 15 is closed and 10 is open. An exception
to this rule is the case when B=0 in a decreasing range. In
this case, the range is closed on both ends, as otherwise
there would be no way to reach 0 on a reverse playback.

   Example:

       Scale: -1
       Range: npt=15-0

   In this range both 15 and 0 are closed.

A decreasing range interval without a corresponding negative
Scale header is not valid.

----------------------------------------------------------------------

Comment By: Thomas M Zeng (zengtm)
Date: 2003-03-05 09:53

Message:
Logged In: YES 
user_id=20397

If scale positive, t1 must >= t0.

Otherwise, t1 must <= t0

----------------------------------------------------------------------

Comment By: Thomas M Zeng (zengtm)
Date: 2002-03-22 09:41

Message:
Logged In: YES 
user_id=20397

I just came across 513880, which is closely related.
That is to say, if timescale is positive, should the play 
range to be required to have t1 > t0?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 03 Dec 2003 10:30:03 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification

Bugs item #493265, was opened at 2001-12-14 03:55
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Pause - Play behaviour clarification

Initial Comment:
The scenario is the following:
A media stream is ready to start playing when the client does the following A-C

A: PLAY range npt:10-30
B: @npt:22-> PAUSE
C: PLAY (no range)

This will result in resuming playing at npt:22. 
The unclearity is which of the following behaviour is the correct one?
1. Play until 30, i.e the second play is equal to PLAY range:22-30.
2. Play until end of media, i.e. the second play is equal to PLAY range:22-

The RFC states the following in Section 10.6 third paragraph:
  "A PAUSE request discards all queued PLAY requests. However, the pause
   point in the media stream MUST be maintained. A subsequent PLAY
   request without Range header resumes from the pause point."

The main unclarity is in what resumes means when also taking the first sentence into account.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-12-03 10:30

Message:
Logged In: NO 

make the website more interesting and easier to understand, 
you'll get a lot more visitors

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 07:29

Message:
Logged In: YES 
user_id=302620

This comment has been addressed by the general clarification
of PLAY and PAUSE handling plus some furhter
clarificiations. The specification text indicates that
unless the second play request specify a range the server
will play from the pause point of 22 second until the end of
media. 

----------------------------------------------------------------------

Comment By: Rob Lanphier (robla)
Date: 2001-12-17 12:32

Message:
Logged In: YES 
user_id=3796

I would be inclined toward the 22-end interpretation (your option 2).  Won't change the spec until it's been 
covered by the group, though.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&group_id=23194

End of Rtspspec-bugs Digest

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