Subject: [MMUSIC] Minutes RTSP Teleconf Feb 19, 2003

From: Thomas Zeng <[email-masked]>
Date: Mon, 24 Feb 2003 10:40:01 -0800

RtspTaskforceTelConMinutesFeb19-2003

= Attendees =
Anders Klements, Joerg Ott, Sean Sheedy, Tom Marshall, Rob Laphier, Aravind
Narasimhan, Magnus Westerlund, Colin Perkins, Andrea Basso, Thomas Zeng
= Agenda = 
1. Follow up on last meeting
- Redirect, waiting for new text from Tom
- Proxy-require, no comments seems okay to edit into spec. See message:
http://www.ietf.org/mail-archive/working-groups/mmusic/current/msg01167.html
- Update on Range header text in regards to Live streams. Need text 
proposal (Thomas Zeng).
-  Restriction text on usage of destination (Aravind Narasimhan)
- Move NAT & FW to separate draft, update intro of core draft to point 
this out (Magnus W).

2. Administrative
- Document Editor(s)!!!

3. Today's new Issues:
 
3.1 RTSP and NATs revisited:
   3.1.1 Discussion on MMUSIC WG list on how and when you can use STUN and 
Symmetric RTP. STUN for cone NATs which only uses single IP. Symmetric 
RTP requires RTSP and server changes + rules on how to prevent attacks 
using RTP.
   3.1.2  Security problems. RTSP as Denial of Service tool. Hijacking and 
interception attacks.
   3.1.3  Destination secure challenge mechanism?

3.2 Use of transport connection interleaved data
   http://rtsp.org/bug507408
   http://rtsp.org/bug556589
   http://rtsp.org/bug662436
   http://rtsp.org/bug672160

3.3 Using option tags for features not related to RTSP

4. Next meeting

== Minutes ==

== 1. Follow up on last meeting ==

 * Aravind: I sent the restriction text on usage of destination 10 minutes
ago. May want to add some best practise guidelines.
 * Magnus:  The restricted use of destination also relates to NAT traversal.
On NAT subject, I am trying to publish a separate draft on NAT and FW as a
new WG work item.
 * Joerg:   That seems to be a good plan.

== 2. Administrative ==
 * Rob: Is next week the due date to submit drafts to San Francisco IETF?  
 * Magnus: Monday after the next for verion 01 and beyond.
 * Joerg:  Magnus, how much time do you need during next meeting to discuss
RTSP revision?
 * Magnus: Between 30 to 60 minutes.

== 3. Today's New Issues ==

=== 3.1  MMUSIC WG list discussion on how and when you can use STUN and
Symmetric RTP ===
  *  Magnus: STUN only useful for Cone NATs. Can use any public STUN
servers. Symetric RTP is not limited to Cone NAT but requires server
modifications.'
  *  Thomas: Even for STUN server must be modified to accomodate new
client_port spec, therefore STUN and Symetric RTP both require server
changes.

  *  Rob: Are we talking about adding more core requirements?
  *  Magnus: Just in the sense of both RTP and RTCP ports in transport.

  *  Andrea (?): How to make it backwards compatible?

  *  Magnus: The client can still choose old syntax, when play.basic option
tag is not present. For symetric RTP will have a new option tag.

  *  Tom: How important is man-in-the-middle vs DOS? Is it necessary to
design RTSP to be robust against man-in-the-middle attacks? TCP itself is
NOT robust to man-in-the-middle. 

  *  Magnus: It's important to describe security implications WRT
man-in-the-middle.
      
  *  Tom: How about simply recommend running RTSP over SSL?

  *  Magnus: SSL is not sufficient.

  *  Sean (?): The only thing secure is to combine SSL and authentication.

  *  Tom:  If the attacker has the ability to redirect the packets to client
then all bets are off. If the attacker is only able to tap the wire, then we
can protect ourselves.

  *  Rob:  SSL can protect security even if the bad guy takes over the
router.

  *  Thomas: What impact does SSL have on RTSP ?

  *  Rob: little things like a different URL starting with "rtsps", similar
to "https".

  *  Anders: A while ago I reserved 322 as RTSP over SSL in IANA.

  *  Sean:  We already have such an implementation.

  *  Magnus: can you write a draft to advice people how to implement RTSP
over SSL?

  *  Sean: I'll see what I can do.

  *  Thomas: If I want to run RTSP over UDP, then can't use SSL.
  *  Jorg:   That's a different can of worms.

  *  Magnus: My guess is RTSP over UDP will no longer be part of core RTSP
spec.

  *  Adlers: If you interleaved RTP over RTSP, there maybe performance
issues by using SSL. If RTP is over UDP, then RTSP over SSL may break
firwalls, since firewalls won't be able to figure out what UDP ports to
open.

  *  Magnus: then we need midcom --- that's also future topic. 
  *  Magnus: Switching to a different topic: how to deal with proxies in
this context?

  *  Tom: Tranparent proxy will not work when RTSP has security protections
such as SSL.

  *  Joerg: With HTTP proxy, if client requests secure page, then proxies
will simply switch to transpartent forward. 

  *  Tom: But if you are using proxy as ALG or cache UDP, then it will not
work.  With secured RTSP, masqurade FWs will not work, but STUN and symetric
RTP will.

 === 3.1.2 Security problems. RTSP as Denial of Service tool. Hijacking and
interception attacks ===
  *  Magnus: NAT traversal opens up security holes. I don't know there's
much more to say about this.

 === 3.1.3 Destination secure challenge mechanism? ===
  * Magnus: defintely for the future, I don't know whether people have time
to do it.
  * Rob: must clarify security implications b/w normal traust relationship
vs trusting client to request different different destination IP.

  * Aravind: if the RTP receipient does not speak RTSP, then we need to make
authentication out-of-band
  * Magnus: or in-band in RTP stream.
 === 3.2  Use of transport connection interleaved data  ===
      * [ http://rtsp.org/bug507408 ]
  *  Magnus:  For this bug, need to claify that it is required to have
either interleave=n or intervleave = n-m. The former means RTCP is not used
at all.
  *  Tom: should allow interleave=n/m to mean n for RTP, m for RTCP
  *  Magnus: play.basic means n-m

  *  Resolution: the client can use "interleave" without channel id, but
server must indicate channel.
  *  Action: Aravind to write text and post to MMUSIC to address all four
bugs.

  * [http://rtsp.org/bug556589 ]

  *  Aravind: To address this bug, shouldn't we change the default to
unicast?
  *  Magnus: No. If you use interleave, you should specifiy UNICAST. If
client requests interleave with MULTICAST, server should ignore it. We must
make sure no bad example in draft wrt interveave and unicast.

  * [http://rtsp.org/bug662436 ]

  * Magnus: this one's from John Lazzaro. "RTP/AVP/TCP w/o interleaved". 

  * Joerg: John's draft is not official work item yet.

  * Magnus: it would be a separate draft.

  * Resolution: table it until the dependencies are ready.

  * [http://rtsp.org/bug672160 Link to bug in source forge ]
 
  * Tom: Proxies may need to re-assign  channel IDs.

  * Rob: Channel id assignment is modelled after UDP, server is to allocate
server channels, client is responsible to allocate client channel IDs. We
don't have a lot more lattitude because of proxies.

  * Adlers: I thought client is not required to specify channels. There used
to be a channel parameter. The extra channel key word was removed. Cleint
was to use "interleave=n" to specify channel.

  * Resolution: clarify that interleave channels are symetric. If the server
uses channel n as down link RTCP SR, client uses channel n for uplink RTCP
RR.

=== 3.3 Using option tags for features not related to RTSP ===

 * Magnus: client uses option tag to signal codec.
 * Joerg:   Not wise, 'cause it would become open ended. A bad example would
be the CONNECT spec 
 * Adlers: get and set parameters seem to be better for negotiate.
 * Magnus: But this is in DESCRIBE.
 * Thomas: how about fixing SDP?

 * Magnus: you'll see a proposal from Nokia to propose this negotiation for
the client to choose a subset of options in SDP. Part of the reason is so
that SDP will not contain  extremely long list of optional tracks.

* Rob: what is the status of Offer/Answer? would it make sense to add to
RTSP?

* Joerg: It would pose backwards compatibility issue. 

* Rob: I think this is the most sensible things to do: propose a option tag
to indicate whether or not Offer/Answer is  supported.

* Jorg: need to careful evaulate offer / answer semantics. 

* Resolution: No to using option tags for Non RTSP features . Should explore
the history of offer/answer for RTSP as a better solution.
* Action Item: Everybody reads on offer/answer and meet in next IETF meeting
to take next step.  
* [ftp://ftp.rfc-editor.org/in-notes/rfc3264.txt This is the link to
RFC3264]

=== 4 Next meeting ===
* Magnus:  Two weeks from now: March 5.  

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