Subject: [MMUSIC] Minutes from Feb 5 RTSP telecon

From: Thomas Zeng <[email-masked]>
Date: Tue, 11 Feb 2003 11:43:24 -0800

RtspTaskforceTelConMinutes05Jan2003

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

   1. Attendees <#section1>
   2. Minutes <#section2>
         1. Follow up on last meeting <#section2.1>
         2. Administrative <#section2.2>
         3. Issues <#section2.3>
               1. RTSP and NAT: Bug 513888 
               2. Use of destination parameter in Transport header:
bug507347
         4. Next meeting <#section2.3>

  1 Attendees
    * Aravind Narasimhan	
    * Jorg Ott
    * Magnus Westerlund
    * Colin Perkins
    * Rob Lanphier
    * Tom Marshall
    * Thomas Zeng

  2 Minutes

    2.1 Follow up on last meeting
      1. Re-direct, waiting for new text from Tom
	 Tom Marshall:   Not done yet.

      2. Update on Range header text in regards to Live streams.

	 Magnus: We have not published, to MMUSIC WG, Range header change
proposal that we agreed upon last time.
	 Thomas Zeng:  I can try to write something up.

      3. Extension mechanism, have support as SIP. 
	 Jorg:  Seems reasonable to me.
	 
      4. Registration of feature tags, and anything not basic shall be
written as extensions.
         * nobody has comments
   
    2.2 Administrative
      Jorg:   Would like to set a milestone in WG charter: Oct 2003 to
submit a new RTSP RFC to GW last call then IESG. This RFC will unlikely (due
to lack of time for interop tests) to bring RTSP to next maturity level
(Draft Standards) but will still obsolete RFC2326.
      
      Magnus: Does not hurt to have such a goal to work with. 
      Magnus: Regarding document editors, any volunteer?
      Thomas: I thought the plan is divide and conquer?
      Magnus: That's right, but still need an editor-in-chief. Nobody seems
to have time for that.
      Colin:  We can move in a slow pace, as people have time.
      Jorg:   If resolutions to open issues are well-documented in
SourceForge including section numbers (and perhaps page numbers) then the
final editor can pull things together relatively easily.

      Magnus: Should use draft 02 (i.e.,
draft-ietf-mmusic-rfc2326bis-02.txt) as baseline and document changes in
that context.

      Thomas: Perhaps you can send out an example.

  2.3. Issues:
    2.3.1  RTSP and NAT: Bug 513888 <#section2.2.1>
      - What solutions exist to make RTSP traverse NATs without ALG.
          http://rtsp.org/bug513888
      - STUN? See
        <http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-05.txt>
      - NAT, ALG and Firewall recommendations in relation to RTSP?      

    Magnus:  We should change Transport parameter syntax to use
"client_port" to specify both RTP and RTCP ports
    Tom:     Should make it a generic parameter, not specific to RTP/RTCP.

    Colin:   Old server may not allow this new syntax.
    Tom:     Recommend if client ports are in fact contiguous, please use
old "-" syntax so can still work with old servers.
    Magnus:   Volunteer to change BNF accordingly?
    <silence>
    Magnus:   I may take a shot at it later. 

    Magnus:  As to STUN, I'll propose a change to "client_port" as well. 
             Let's discuss then Symetric RTP for RTSP.

    Magnus:  Sending RTP packets from client to server leaves doors open for
"hijacking", because it's much easier '	  to spoof RTP packets than do TCP
streams. Therefor we need RTP authentication.

    Thomas:  Could require the use of SessinID and/or SSRC in back RTP
packets as a crude authentication.
    Tom:     I prefer using SessionID in this case.

    Magnus:  We should document different NAT mechanisms in relation to
RTSP.

    Magnus:  How can server and client know that Symetric RTP is the
protocol?
  
    Tom:     Use Transport header to signal Symetric RTP.

    Magnus:  Yes, client can use a "symetric" parameter in Transport header
in its Setup request to indicate the
             intention to use symetric RTP for NAT traversal, and server can
use option tag in its Support header to             indicate whether the
server supports symetric RTP.
	    
    CONCLUSION: Add a parameter ("symetric"?) to Transport parameters. Add a
option tag for Symetric RTP feature.

    Magnus:  Moving on to ALG (Application Level Gateway), I think ALGs will
not work with RTSP because:
             1. ALGs have deployment issues 2. ALGs are not up to date   3.
People writing ALGs are generally not familiar with RTSP.

    Magnus:   On the other hand, do we need to write a draft to recommend
how to write ALG for RTSP?

    Rob:     RTSP support has already been added to some application level
firewalls (e.g., ipchain rules in Linux
             Firewalls). NATs and FWs  may need RTSP core spec's support,
but we can early on find those dependencies and address them in core RTSP
spec.

    Magnus:  The section on NATs/FWs could go into a separate draft, which
would also be easier to maintain.

    CONCLUSION: Move NAT/FW section from current rfc2326bis draft 02 to a
separate draft, but make sure the
             core RTSP spec has the right features to support NAT/FW
tranversals schemes, including ALGs, STUN, UPnP or MidComm and Symetric RTP.
Option tags are to be created to extend core RTSP.

    Magnus:  This extension draft should be published at the same time as
the core RTSP spec.

    ACTION ITEM: Magnus to change current text to refer to the separate
draft.

    2.3.2   Use of destination parameter in Transport header: bug507347
     (See http://rtsp.org/bug507347)

     Magnus: I don't think we should remove this parameter, because it seems
to be useful to NAT tranversal.
             We should clearly document the security danger of its use,
though.

     Rob:    Could suggest that the server authenticate receiver using some
out-of-band authentication schemes.

     Mangus: So the wording can be: "One shall not allow destination set to
a different IP unless the receive authorizes it".

     Rob:    The working has to be clear as to which node is sending
credentials... There are three entities: the server, the RTSP client and the
RTP receipient. What the server needs to do is ti make sure RTSP client has
the permission from the RTP receipient to blast packets to it.

     Magnus:   Is it not an issue with multicast RTP?

     Rob:    Should allow "destination" for Multicast ... I can describe a
use case for it...

     Jorg:   It is useful to have the control entity somewhere else than the
conference participants.

     Aravind: I can volunteer to write a proposal. We currently disable
"destination" header by default but
            customers can turn it on using a config parameter.

    2.3.4: Next meeting
	   Magnus:  Next meeting in two weeks?

           Everybody: sounds good.

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