From mailnull@www1.ietf.org Mon Feb 3 11:25:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12180 for ; Mon, 3 Feb 2003 11:25:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13GUDg01582 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 11:30:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GUDJ01579 for ; Mon, 3 Feb 2003 11:30:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12164 for ; Mon, 3 Feb 2003 11:24:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GTfJ01536; Mon, 3 Feb 2003 11:29:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GSLJ01465 for ; Mon, 3 Feb 2003 11:28:21 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12107 for ; Mon, 3 Feb 2003 11:22:46 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h13GQMKV007277 for ; Mon, 3 Feb 2003 17:26:22 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5JHNDW; Mon, 3 Feb 2003 17:26:22 +0100 Message-ID: <3E3E982E.2010706@era.ericsson.se> Date: Mon, 03 Feb 2003 17:26:22 +0100 X-Sybari-Trust: fc0fbb27 9ffcebbb af2b1b25 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP and NATs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here is a proposal to the RTSP spec for how to handle NATs using STUN. Please read and comment. It is planned to discuss NAT's on wednessday's RTSP telecon. Cheers Magnus --------------------------------------- 15 RTSP through Firewalls & NATs 15.1 Introduction Today there is Network Address Translators (NAT) [32] everywhere and a protocol must make sure that it can work through them in some fashion. The problem with RTSP is that it carries information about network addresses and ports inside itself. It is primarily the media streams that are being blocked by NAT, as the given address to send to is a local one. Firewalls are also middle boxes that needs to be considered. They are deployed to prevent non-desired traffic/protocols to be used or reach the protected network. RTSP is designed to allow a firewall to let RTSP controlled streams through, if chosen to, with minimal implementation problems. 15.2 NAT Today there exist a number of different NAT types and usage areas. The different NAT types, cited from STUN [31]: Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. Port Restricted Cone: A port restricted cone NAT is like a res- tricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. NAT's are used on both small and large scale. The normal small scale user is home user that has a NAT to allow multiple computers share the single IP address given by their Internet Service Pro- vider (ISP). The large scale users are the ISP's themselves that gives there users private addresses. This is done both for control and lack of addresses. 15.2.1 STUN The STUN [31] protocol allows a client to discover the type of NAT(s) he is behind and also discover a mappings public address and port number. The protocol also allows discovery of the mappings timeout period and can be used as keep alive mechanism. How useful this protocol is depends on the type of NAT(s) the client is behind. If the user is behind a full cone NAT, STUN allows the RTSP client to traverse the NAT with some simple client side adaptations. For restricted cone NATs STUN is still useful but require some more adaptations. For symmetric NATs STUN requires such severe server adaptations that it is not practical to use. A RTSP client using RTP transport can use STUN to traverse a full cone NAT in the following way: 1. Use STUN to discover the type of NAT, if any, and the timeout period for any UDP mapping on the NAT. This is RECOMMENDED to be performed in the background as soon as IP connectivity is established. If this is performed prior to the attempt to establish a streaming session the possible delays in the ses- sion establishment will be reduced. If no NAT is present, use the normal SETUP behavior. 2. The RTSP client determines the number of UDP ports needed by the RTP sessions part of the multi-media presentation. This information is available in the media description protocol used, e.g. SDP. In general each RTP session will require two UDP ports, one for RTP, and one for RTCP. Ensure that the same public IP address is used for each RTP/RTCP port pair esta- blished. 3. For each UDP port required, establish a mapping and discover the public IP address and port number with use of STUN. if successful this results in that the client now knows for each port know the mapping: clients local address/port Leftrightar- row public address/port. 4. Perform the RTSP SETUP for each media. In the transport header the following parameters SHOULD be included with the given values: "destination" with the public IP address, "client_port" with the public port of the mapping determined to be used for RTP, "client_rtcp_port" with the port number of the mapping to be used for RTCP. The parameter "client_rtcp_port" needs to be used unless the client has managed to establish a mapping with two consecutive numbers starting with an even one. To allow this to work servers MUST allow a client to setup the RTP stream on any port, not only even ports. The server SHALL respond with a transport header containing the source IP address of the media streams. 5. To keep the mappings alive the client SHOULD periodically send UDP traffic over all mappings needed for the session. STUN can be used to determine the timeout period of the NAT(s) UDP map- pings. For the mapping carrying RTCP traffic the periodic RTCP traffic may be sent frequently enough. If not or for RTP car- rying mappings, empty IP/UDP messages SHOULD be sent to the streaming servers discard port (port number 9). If a UDP mapping is lost above process is required to be performed again and the media stream effected SETUP again. To allow the UDP packets to arrive from the server to a client behind a restricted NAT, any UDP messages must be sent to the server. Therefore SHOULD the client, before sending a RTSP PLAY request send an empty UDP message, on each mapping, to the IP address given as the servers source address and its discard port (port number 9). Otherwise no difference in procedure compared with a full cone NAT is needed. For a port restricted NAT the client must send messages to the exact ports used by the server to send messages. This makes it pos- sible to use the above described process with the following addi- tions: For each port mapping, a UDP message needs to be sent to the servers source address/port. To minimize potential effects on the server from these messages the following type of messages MUST be sent. RTP: An empty UDP message with out any payload. RTCP: A correctly formed RTCP message. Unless enough bandwidth is assigned to RTCP it might not be possible to keep the UDP mapping open. These messages SHOULD be sent before sending a PLAY request and then periodically according to the determined timeout time of the NAT. To be able to use STUN to traverse symmetric NATs the STUN server needs to be co-located with the streaming server media distribution ports. As this will create implementations difficulties and possi- bly security problems this SHOULD NOT be done. 15.2.2 Application Level Gateways An Application Level Gateway (ALG) reads the application level mes- sages and perform necessary changes to allow the protocol to work through the middle box. However this behavior has some problems in regards to RTSP: 1. Does not work when protocol is used with end-to-end security. As the ALG can't inspect and change the application level mes- sages the protocol will fail over the middle box. 2. Needs to be updated if extensions to the protocol are added. Due to deployment issues with changing ALG's this may also break the end-to-end functionality of RTSP. Due to the above reasons it is RECOMMENDED to not use ALGs in NATs. This is especially important for NAT's targeted to home users and not ISPs. In that case it is recommended that NATs are full cone and that the RTSP client instead used STUN or the planned MIDCOM protocols. An ALG for the this specification would need to perform the follow- ing tasks and changes to RTSP: 1. Detect a SETUP request. Create UDP mappings (client given IP/port Leftrightarrow public IP/port) where needed for all possible transport specification in the transport header of the request found in (1). Enter the public address and port(s) of these mappings in transport header. Mappings SHALL be created with consecutive public port number starting on a even number for RTP each stream. Mappings SHOULD also be given a long timeout period, at least 5 minutes. 2. When the response is received from the server the ALG MAY remove the unused UDP mappings, i.e. the ones not present in the transport header. The session ID SHOULD also be bound to the UDP mappings part of that session. 3. The ALG SHOULD keep alive the UDP mappings belonging to the an RTSP session as long as: RTSP messages with the session's ID has been sent in the last RTSP session timeout interval, or UDP messages are sent on any of the UDP mappings during the last RTSP timeout interval. 4. The ALG MAY remove a mapping as soon a TEARDOWN response has been received for that media stream. 15.2.3 TCP Tunneling TCP tunneling is the final fallback to get any RTSP controlled streaming to work through a NAT. As it is the client that establish the TCP connection to the server it will automatically create a binding through the NAT. This connection can then be used by the server to send media packets in. Using TCP tunneling has the drawback on real-time properties that TCP has with "head of line" blocking. It may also have large varia- tions in through put due to the congestion control algorithm. TCP tunneling must also be supported by both server and client. See section 10.11 for how to perform TCP tunneling. 15.3 Firewalls Firewalls exist for a purpose to protect a network from traffic not desired by the firewall owner. Therefore it is a policy decision if a firewall will let RTSP and its media streams through or not. RTSP is designed to be as easy as possible to process for a firewall with a policy to let the traffic pass through. The firewall will need to allow the media streams associated with a RTSP session pass through it. Therefore the firewall will need an ALG that reads RTSP SETUP and TEARDOWN messages. By reading the SETUP message the firewall can determine what type of transport and from where the media streams will use. Very common will be the need to open UDP ports for RTP/RTCP. By looking at the source and desti- nation addresses and ports the opening in the firewall can be minimized to the least necessary. The opening in the firewall can be closed after a teardown message for that session or the session itself timesout. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 13:14:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15563 for ; Mon, 3 Feb 2003 13:14:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13IJOc11070 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 13:19:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IJOJ11067 for ; Mon, 3 Feb 2003 13:19:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15551 for ; Mon, 3 Feb 2003 13:13:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IIrJ11042; Mon, 3 Feb 2003 13:18:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IHKJ10963 for ; Mon, 3 Feb 2003 13:17:20 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15511 for ; Mon, 3 Feb 2003 13:11:45 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18fl7m-0006tk-00; Mon, 03 Feb 2003 10:15:18 -0800 Date: Mon, 3 Feb 2003 10:15:18 -0800 From: Tom Marshall To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs Message-ID: <20030203181518.GA26315@real.com> References: <3E3E982E.2010706@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <3E3E982E.2010706@era.ericsson.se> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote: > Hi, >=20 > Here is a proposal to the RTSP spec for how to handle NATs using STUN.=20 > Please read and comment. It is planned to discuss NAT's on wednessday's= =20 > RTSP telecon. I believe that a viable NAT traversal protocol should not require changes to the protocols that it supports. If it is desired that RTSP and STUN work well together, I think the proper course of action is to modify the STUN draft to allow requests for consecutive blocks of mapped UDP ports required by RTSP and RTP. Regardless of STUN, it may be useful to have a mechanism for non-contiguous UDP port mappings. I would argue in favor of a list based approach that has general applicability instead of an approach that is specific to RTP. For example, the client_port attribute could use '/' to separate non-contiguous ports: Transport: rtp/avp/udp;unicast;client_port=3D7834/23478 Having said that, here are my thoughts on STUN in general: I am not in favor of STUN. There are other NAT traversal protocols[1] which are already deployed and adding support for this one just muddies the waters further. If someone were to propose a simple and complete solution for all NATs that everyone could get behind, that would be worth supporting. STUN is, by its own admission, not a complete solution[2]. The major focus of STUN seems to be the rapidly growing "NAT in a box" class of router devices that have proliferated around broadband and wireless.=20 Given the current lack of support for RTSP, why would we assume that vendors will be any more willing to support STUN? If the vendors won't support it, then adding more Transport attributes creates more implementation headaches for ourselves with little or no benefit. I think the best solution is to find out how to persuade the vendors to properly support RTSP. It is really not much more difficult to support than, say, FTP. [1] Another example (with heavy industry backing) is http://www.upnp.org/ . [2] From STUN draft: "STUN does not enable incoming UDP packets through symmetric NATs ..., which are common in large enterprises." --=20 Windows 2000: Designed for the Internet. The Internet: Designed for UNIX. --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+PrG2qznSmcYu2m8RAhLEAJsHK0uBP4SQKk/nAUuFUNQKb6ssbQCfecfE vCh1Rd2Y7wFOvaPMI591pNY= =hddF -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 15:10:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19778 for ; Mon, 3 Feb 2003 15:10:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13KFXo22138 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 15:15:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KFXJ22135 for ; Mon, 3 Feb 2003 15:15:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19738 for ; Mon, 3 Feb 2003 15:09:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KFGJ22125; Mon, 3 Feb 2003 15:15:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KE5J22033 for ; Mon, 3 Feb 2003 15:14:05 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19600 for ; Mon, 3 Feb 2003 15:08:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h13KC2YH014634; Mon, 3 Feb 2003 15:12:02 -0500 (EST) Message-ID: <3E3ECD0D.8010601@dynamicsoft.com> Date: Mon, 03 Feb 2003 15:11:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: <3E3E982E.2010706@era.ericsson.se> <20030203181518.GA26315@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Tom Marshall wrote: > On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote: > >>Hi, >> >>Here is a proposal to the RTSP spec for how to handle NATs using STUN. >>Please read and comment. It is planned to discuss NAT's on wednessday's >>RTSP telecon. > > > I believe that a viable NAT traversal protocol should not require changes to > the protocols that it supports. If it is desired that RTSP and STUN work > well together, I think the proper course of action is to modify the STUN > draft to allow requests for consecutive blocks of mapped UDP ports required > by RTSP and RTP. No, that is impossible. You have misunderstood how STUN works. STUN does not allocate the addresses. It merely tells the client what a regular, off the shelf NAT has allocated to a user. Since regular, off-the-shelf NATs do not know anything about RTP port pairings, two separate STUN requests will result in a nat allocating two bindings which are most likely not consecutive (or follow the odd/even rule). THis is dealt with through an SDP extension that allows a client to provide a specific address and port for SDP (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt). > > Regardless of STUN, it may be useful to have a mechanism for non-contiguous > UDP port mappings. I would argue in favor of a list based approach that has > general applicability instead of an approach that is specific to RTP. For > example, the client_port attribute could use '/' to separate non-contiguous > ports: > > Transport: rtp/avp/udp;unicast;client_port=7834/23478 Well, I will take this opportunity to once more complain, as I have done at IETF meetings in the past, of the continued cost of repeating protocol development related to session initiation twice - once for SIP, and once for RTSP. We already have a way to do this representation in SDP for SIP. Seems like we need to repeat such design now for RTSP. > > Having said that, here are my thoughts on STUN in general: > > I am not in favor of STUN. There are other NAT traversal protocols[1] which > are already deployed and adding support for this one just muddies the waters > further. There are many topologies in which UPnP will not work. These icnlude: * cases where the residential nat doesnt support it * cases where there are multiple nats in tandem, such as cable operators that nat their networks * enterprises with multiple access points to the public Internet > If someone were to propose a simple and complete solution for all > NATs that everyone could get behind, that would be worth supporting. STUN > is, by its own admission, not a complete solution[2]. Heh. How about world peace while you are at it. The problem is this. Experience has shown that solutions which ALWAYS work tend to be way too expensive in situations that are far more simpler solution will do. There is therefore a cost/generality curve with a highly non-linear behavior, which results in solutions being defined across this curve. STUN happens to be extremely cheap to do in the cases where it works. THe most general solution, which are media-relay types of solutions, are very expensive because of the need to route media through intermediaries. > > The major focus of STUN seems to be the rapidly growing "NAT in a box" class > of router devices that have proliferated around broadband and wireless. > Given the current lack of support for RTSP, why would we assume that vendors > will be any more willing to support STUN? You have again misunderstood how stun works. STUN requires no support in NATs. A provider that wants to provide streaming media services using rtsp would deploy the stun server, NOT the ISP or IP access provider of the end user. > If the vendors won't support it, > then adding more Transport attributes creates more implementation headaches > for ourselves with little or no benefit. I think the best solution is to > find out how to persuade the vendors to properly support RTSP. It is really > not much more difficult to support than, say, FTP. I sinceerely doubt that. What incentive has Linksys, Netgear, and the REAMS of other home nat boxes to support ALGs for RTSP? Are those companies the experts on RTSP? Surely not! The need to separate out applications from NATs and firewalls is central to the midcom working group and much of the other work going on in IETF. ANYWAY, all of that said (just responding to this assault on STUN), I do not think STUN by itself is the right solution to RTSP nat traversal. THere are two options that are better. OPTION 1: Symmtric RTP. See http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.txt. Effectively, the IP address/ports provided by the RTSP client are ignored by the server. The client sends RTP/RTCP packets to the server, and the server sends media back to the client at the source ip/port that the RTP/RTCP came from. Requires no changes to the RTSP protocol, except to recommend this method. No STUN support needed. Works through all NAT types. It will require the client to send keepalive packets if there is a pause in media. NB: This ONLY works if the RTSP server is on the public Internet!!!! OPTION 2: Coming Soon I am working on a draft (out before the -00 deadline end of this month) that finally unifies all of the mess of nat traversal together - STUN, TURN, symmetric RTP. It has the property that it always results in the optimal media path, lowest latency, lowest cost, and highest probability of working (i.e., you hear media), compared to any other technique. In the case of the RTSP server running on the public Internet, it would end up working a lot like OPTION 1 above. But, it would also work in cases where that was not true, for example, a client connecting to a media server in another enterprise that is behind a nat. More to come soon. In fact, one might say that the best approach for nat traversal is not to document it in the RTSP revision itself, as there are multiple solutions in any case. We have done that for sip, documenting solutions in a separate document: http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt Then there are other thigns coming like nsis. So, keeping this separate from RTSP itself is probably a good thing. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 17:37:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24121 for ; Mon, 3 Feb 2003 17:37:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Mgi132274 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 17:42:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MgiJ32271 for ; Mon, 3 Feb 2003 17:42:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24108 for ; Mon, 3 Feb 2003 17:37:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MgTJ32252; Mon, 3 Feb 2003 17:42:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MfnJ32216 for ; Mon, 3 Feb 2003 17:41:49 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24088 for ; Mon, 3 Feb 2003 17:36:06 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18fpFb-0007Qc-00; Mon, 03 Feb 2003 14:39:39 -0800 Date: Mon, 3 Feb 2003 14:39:39 -0800 From: Tom Marshall To: Jonathan Rosenberg Cc: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs Message-ID: <20030203223939.GB26777@real.com> References: <3E3E982E.2010706@era.ericsson.se> <20030203181518.GA26315@real.com> <3E3ECD0D.8010601@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <3E3ECD0D.8010601@dynamicsoft.com> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 03, 2003 at 03:11:57PM -0500, Jonathan Rosenberg wrote: > inline. >=20 > Tom Marshall wrote: > >On Mon, Feb 03, 2003 at 05:26:22PM +0100, Magnus Westerlund wrote: > > > >>Hi, > >> > >>Here is a proposal to the RTSP spec for how to handle NATs using STUN.= =20 > >>Please read and comment. It is planned to discuss NAT's on wednessday's= =20 > >>RTSP telecon. > > > > > >I believe that a viable NAT traversal protocol should not require change= s=20 > >to > >the protocols that it supports. If it is desired that RTSP and STUN work > >well together, I think the proper course of action is to modify the STUN > >draft to allow requests for consecutive blocks of mapped UDP ports requi= red > >by RTSP and RTP. >=20 > No, that is impossible. You have misunderstood how STUN works. Yes, you are correct. On initial reading of the STUN draft, I assumed "server" meant the NAT device. My understanding now is that the STUN server resides on a publicly accessible address outside and independent from any NAT. > STUN does not allocate the addresses. It merely tells the client what a= =20 > regular, off the shelf NAT has allocated to a user. Since regular,=20 > off-the-shelf NATs do not know anything about RTP port pairings, two=20 > separate STUN requests will result in a nat allocating two bindings=20 > which are most likely not consecutive (or follow the odd/even rule).=20 > THis is dealt with through an SDP extension that allows a client to=20 > provide a specific address and port for SDP=20 > (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt). This draft again assumes that RTP is the only transport choice: rtcp-attribute =3D "a=3Drtcp:" port What if there were some other UDP based transport that required two UDP ports (perhaps even "RTPng")? You would need yet another draft to address it. Why not make the solution generic instead? > >Regardless of STUN, it may be useful to have a mechanism for non-contigu= ous > >UDP port mappings. I would argue in favor of a list based approach that= =20 > >has > >general applicability instead of an approach that is specific to RTP. F= or > >example, the client_port attribute could use '/' to separate non-contigu= ous > >ports: > > > >Transport: rtp/avp/udp;unicast;client_port=3D7834/23478 >=20 > Well, I will take this opportunity to once more complain, as I have done= =20 > at IETF meetings in the past, of the continued cost of repeating=20 > protocol development related to session initiation twice - once for SIP,= =20 > and once for RTSP. We already have a way to do this representation in=20 > SDP for SIP. Seems like we need to repeat such design now for RTSP. I am not familiar with SIP (although I will read up on it before the next meeting). My only concern is that any modification to RTSP does not limit itself needlessly. If SIP has done so (and it appears that at least one SDP draft is doing so), then perhaps those decisions should be reconsidered. > >If someone were to propose a simple and complete solution for all > >NATs that everyone could get behind, that would be worth supporting. ST= UN > >is, by its own admission, not a complete solution[2]. >=20 > Heh. How about world peace while you are at it. And a complete IPv6 transition too, eh (reducing or eliminating NAT)? ;-) > The problem is this. Experience has shown that solutions which ALWAYS=20 > work tend to be way too expensive in situations that are far more=20 > simpler solution will do. There is therefore a cost/generality curve=20 > with a highly non-linear behavior, which results in solutions being=20 > defined across this curve. STUN happens to be extremely cheap to do in=20 > the cases where it works. THe most general solution, which are=20 > media-relay types of solutions, are very expensive because of the need=20 > to route media through intermediaries. I have just started looking at STUN but I have some questions: 1. Given a NAT that supports RTSP (eg. Linux 2.2 masquerading with an RTSP module loaded), will the client "detect" that it is behind a NAT? If so, how does this affect the Transport: header as it passes through? It seems to me that the RTSP enabled NAT will break the STUN-enabled Transport: header. If this is the case, I think that STUN should be reconsidered (at least for RTSP) as would break an otherwise functional NAT setup. 2. Given a successful STUN setup, does the STUN client direct all UDP traffic to the STUN server as a relay point, or does the client assume that all UDP packets sent between the STUN mapped port and any outside address will have the same NAT mapping? I will have to do some checking, but IIRC the Linux 'ipchains' NAT code does mappings with a '5-tuple': client ip, client port, nat port, server ip, server port. If the latter case is assumed (no relay), I don't think that the STUN mappings would behave as described in the draft. Packets sent to and from the appserver will have a different 5-tuple, and thus a different nat port, rendering STUN ineffective. Has this case been considered? > >If the vendors won't support it, then adding more Transport attributes > >creates more implementation headaches for ourselves with little or no > >benefit. I think the best solution is to find out how to persuade the > >vendors to properly support RTSP. It is really not much more difficult > >to support than, say, FTP. >=20 > I sinceerely doubt that. Which do you doubt? The implementation headaches or that RTSP support is not difficult in NAT? > ANYWAY, all of that said (just responding to this assault on STUN), I do= =20 > not think STUN by itself is the right solution to RTSP nat traversal.=20 > THere are two options that are better. >=20 > OPTION 1: Symmtric RTP. See=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.txt.= =20 > Effectively, the IP address/ports provided by the RTSP client are=20 > ignored by the server. The client sends RTP/RTCP packets to the server,= =20 > and the server sends media back to the client at the source ip/port that= =20 > the RTP/RTCP came from. Requires no changes to the RTSP protocol, except= =20 > to recommend this method. No STUN support needed. Works through all NAT= =20 > types. It will require the client to send keepalive packets if there is= =20 > a pause in media. >=20 > NB: This ONLY works if the RTSP server is on the public Internet!!!! This is similar to a technique that we (RealNetworks) use for our internal transport. It is quite effective (but not 100% of course). The biggest problem I see is that client->server RTP traffic is not expected. There is some chance that an intermediate device or proxy may behave badly. But so far, it seems to be the best choice. > OPTION 2: Coming Soon > I am working on a draft (out before the -00 deadline end of this month)= =20 > that finally unifies all of the mess of nat traversal together - STUN,=20 > TURN, symmetric RTP. It has the property that it always results in the=20 > optimal media path, lowest latency, lowest cost, and highest probability= =20 > of working (i.e., you hear media), compared to any other technique. In=20 > the case of the RTSP server running on the public Internet, it would end= =20 > up working a lot like OPTION 1 above. But, it would also work in cases=20 > where that was not true, for example, a client connecting to a media=20 > server in another enterprise that is behind a nat. >=20 > More to come soon. I will keep an eye out, thanks. --=20 You can complain because roses have thorns, or you can rejoice because thorns have roses. -- Abraham Lincoln --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Pu+rqznSmcYu2m8RAtNHAKCFyYxSlsd27eD3nM67HWZHX1e+yQCfVkRd 29BY2wBAiURVY83bRlid7NM= =CIyw -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 18:02:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24657 for ; Mon, 3 Feb 2003 18:02:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13N7pr01384 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 18:07:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13N7pJ01381 for ; Mon, 3 Feb 2003 18:07:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24622 for ; Mon, 3 Feb 2003 18:02:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13N79J00919; Mon, 3 Feb 2003 18:07:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13N6JJ00649 for ; Mon, 3 Feb 2003 18:06:19 -0500 Received: from chiron.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24599 for ; Mon, 3 Feb 2003 18:00:36 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id h13N42D18715; Mon, 3 Feb 2003 18:04:02 -0500 Message-Id: <200302032304.h13N42D18715@chiron.nge.isi.edu> To: Jonathan Rosenberg cc: Tom Marshall , Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs In-Reply-To: Your message of "Mon, 03 Feb 2003 15:11:57 EST." <3E3ECD0D.8010601@dynamicsoft.com> Date: Mon, 03 Feb 2003 18:04:02 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> Jonathan Rosenberg writes: ... >In fact, one might say that the best approach for nat traversal is not >to document it in the RTSP revision itself, as there are multiple >solutions in any case. We have done that for sip, documenting solutions >in a separate document: > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt > >Then there are other thigns coming like nsis. So, keeping this separate >from RTSP itself is probably a good thing. Perhaps, although the RTSP spec should probably address any issues related to NAT/firewall traversal. Especially since RTSP supports interleaving a media stream on the control channel, which has quite different properties than separate media. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 18:44:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25500 for ; Mon, 3 Feb 2003 18:44:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13No6K03403 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 18:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13No6J03400 for ; Mon, 3 Feb 2003 18:50:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25485 for ; Mon, 3 Feb 2003 18:44:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NnQJ03367; Mon, 3 Feb 2003 18:49:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Nm3J03317 for ; Mon, 3 Feb 2003 18:48:03 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25463 for ; Mon, 3 Feb 2003 18:42:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h13NjwYH014901; Mon, 3 Feb 2003 18:45:58 -0500 (EST) Message-ID: <3E3EFF32.2090103@dynamicsoft.com> Date: Mon, 03 Feb 2003 18:45:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: <3E3E982E.2010706@era.ericsson.se> <20030203181518.GA26315@real.com> <3E3ECD0D.8010601@dynamicsoft.com> <20030203223939.GB26777@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Marshall wrote: >>STUN does not allocate the addresses. It merely tells the client what a >>regular, off the shelf NAT has allocated to a user. Since regular, >>off-the-shelf NATs do not know anything about RTP port pairings, two >>separate STUN requests will result in a nat allocating two bindings >>which are most likely not consecutive (or follow the odd/even rule). >>THis is dealt with through an SDP extension that allows a client to >>provide a specific address and port for SDP >>(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt). > > > This draft again assumes that RTP is the only transport choice: > > rtcp-attribute = "a=rtcp:" port > > What if there were some other UDP based transport that required two UDP > ports (perhaps even "RTPng")? You would need yet another draft to address > it. Why not make the solution generic instead? Well, if thats so, I would have rather had such a debate in the context of the above draft. Anyway, I know of no other media stream that uses UDP that uses multiple ports AND that has an algorithmic relationship between those ports (i.e., has no way to express in the SDP which ports are needed). Seems like a non-problem. > > >>>Regardless of STUN, it may be useful to have a mechanism for non-contiguous >>>UDP port mappings. I would argue in favor of a list based approach that >>>has >>>general applicability instead of an approach that is specific to RTP. For >>>example, the client_port attribute could use '/' to separate non-contiguous >>>ports: >>> >>>Transport: rtp/avp/udp;unicast;client_port=7834/23478 >> >>Well, I will take this opportunity to once more complain, as I have done >>at IETF meetings in the past, of the continued cost of repeating >>protocol development related to session initiation twice - once for SIP, >>and once for RTSP. We already have a way to do this representation in >>SDP for SIP. Seems like we need to repeat such design now for RTSP. > > > I am not familiar with SIP (although I will read up on it before the next > meeting). My only concern is that any modification to RTSP does not limit > itself needlessly. If SIP has done so (and it appears that at least one SDP > draft is doing so), then perhaps those decisions should be reconsidered. Ultimately, I'd like to see SIP used to set up sessions both point-to-point and to media servers, and if control is needed, RTSP be introduced in order to achieve that end. There are many benefits from using a single protocol to achieve setup. We've stumbled onto one of them (duplication of specification work). Another is a single call/communications routing infrastructure. I have been hoping to find the time to write that up in an I-D, but there are always higher priority ones than chasing a goal that no one else seems to care about... > > >>>If someone were to propose a simple and complete solution for all >>>NATs that everyone could get behind, that would be worth supporting. STUN >>>is, by its own admission, not a complete solution[2]. >> >>Heh. How about world peace while you are at it. > > > And a complete IPv6 transition too, eh (reducing or eliminating NAT)? ;-) Dont get me started... > > >>The problem is this. Experience has shown that solutions which ALWAYS >>work tend to be way too expensive in situations that are far more >>simpler solution will do. There is therefore a cost/generality curve >>with a highly non-linear behavior, which results in solutions being >>defined across this curve. STUN happens to be extremely cheap to do in >>the cases where it works. THe most general solution, which are >>media-relay types of solutions, are very expensive because of the need >>to route media through intermediaries. > > > I have just started looking at STUN but I have some questions: > > 1. Given a NAT that supports RTSP (eg. Linux 2.2 masquerading with an RTSP > module loaded), will the client "detect" that it is behind a NAT? Yes. > If so, > how does this affect the Transport: header as it passes through? It > seems to me that the RTSP enabled NAT will break the STUN-enabled > Transport: header. If this is the case, I think that STUN should be > reconsidered (at least for RTSP) as would break an otherwise functional > NAT setup. A smart ALG won't. It should know not to muck with IP addresses inside of the RTSP message if they are not private addresses (if stun is used, those addresses will have already been changed to public ones by the RTSP client). Indeed, one can imagine usign RTSP to setup a streaming media session to some third party device outside of the nat, in which case the ALG has to know not to change the IP. I wonder if the linux code you cite supports that. Which, of course, brings me to my beef with ALG - the wrong people write them in general. Only an RTSP expert would probably know to look for such nuances (even then...), and Linksys and Netgear to not hire such people - its not their business. > > 2. Given a successful STUN setup, does the STUN client direct all UDP > traffic to the STUN server as a relay point, No, the stun server is NOT a relay point. > or does the client assume > that all UDP packets sent between the STUN mapped port and any outside > address will have the same NAT mapping? STUn works a binding discovery mechanism ONLY if the client can assume that any client outside of the nat can send to that address. > I will have to do some checking, > but IIRC the Linux 'ipchains' NAT code does mappings with a '5-tuple': > client ip, client port, nat port, server ip, server port. If the latter > case is assumed (no relay), I don't think that the STUN mappings would > behave as described in the draft. Packets sent to and from the appserver > will have a different 5-tuple, and thus a different nat port, rendering > STUN ineffective. Has this case been considered? Certainly. This is called "symmetric NAT". Its common but to date the full-cone variety, which maps bindings by private IP/port alone, is quite prevalent amongst the home NATs. The presenec of a symmtric NAT is discoverable by STUN, in which case you need somethign else to receive media. Symmetric RTP, for example, is an application-specific method. Another would be TURN (http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-00.txt) which does use a relay. > > >>>If the vendors won't support it, then adding more Transport attributes >>>creates more implementation headaches for ourselves with little or no >>>benefit. I think the best solution is to find out how to persuade the >>>vendors to properly support RTSP. It is really not much more difficult >>>to support than, say, FTP. >> >>I sinceerely doubt that. > > > Which do you doubt? The implementation headaches or that RTSP support is > not difficult in NAT? That RTSP ALGs are likely to be supported widely in the vast array of $100 NAT boxes on the market. FTP *is* widely supported, but RTSP is a domain-specific protocol, and I suspect not on their radar screens. > > >>ANYWAY, all of that said (just responding to this assault on STUN), I do >>not think STUN by itself is the right solution to RTSP nat traversal. >>THere are two options that are better. >> >>OPTION 1: Symmtric RTP. See >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.txt. >>Effectively, the IP address/ports provided by the RTSP client are >>ignored by the server. The client sends RTP/RTCP packets to the server, >>and the server sends media back to the client at the source ip/port that >>the RTP/RTCP came from. Requires no changes to the RTSP protocol, except >>to recommend this method. No STUN support needed. Works through all NAT >>types. It will require the client to send keepalive packets if there is >>a pause in media. >> >>NB: This ONLY works if the RTSP server is on the public Internet!!!! > > > This is similar to a technique that we (RealNetworks) use for our internal > transport. It is quite effective (but not 100% of course). I am curious about what problems you have encountered. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 20:20:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26639 for ; Mon, 3 Feb 2003 20:20:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h141PxQ07624 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 20:25:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141PxJ07621 for ; Mon, 3 Feb 2003 20:25:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26609 for ; Mon, 3 Feb 2003 20:20:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141PLJ07600; Mon, 3 Feb 2003 20:25:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h141OSJ07558 for ; Mon, 3 Feb 2003 20:24:28 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26605 for ; Mon, 3 Feb 2003 20:18:43 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18frmy-0007kJ-00; Mon, 03 Feb 2003 17:22:16 -0800 Date: Mon, 3 Feb 2003 17:22:16 -0800 From: Tom Marshall To: Jonathan Rosenberg Cc: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs Message-ID: <20030204012216.GC26777@real.com> References: <3E3E982E.2010706@era.ericsson.se> <20030203181518.GA26315@real.com> <3E3ECD0D.8010601@dynamicsoft.com> <20030203223939.GB26777@real.com> <3E3EFF32.2090103@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline In-Reply-To: <3E3EFF32.2090103@dynamicsoft.com> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 03, 2003 at 06:45:54PM -0500, Jonathan Rosenberg wrote: >=20 >=20 > Tom Marshall wrote: >=20 > >>STUN does not allocate the addresses. It merely tells the client what a= =20 > >>regular, off the shelf NAT has allocated to a user. Since regular,=20 > >>off-the-shelf NATs do not know anything about RTP port pairings, two=20 > >>separate STUN requests will result in a nat allocating two bindings=20 > >>which are most likely not consecutive (or follow the odd/even rule).=20 > >>THis is dealt with through an SDP extension that allows a client to=20 > >>provide a specific address and port for SDP=20 > >>(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt). > > > > > >This draft again assumes that RTP is the only transport choice: > > > > rtcp-attribute =3D "a=3Drtcp:" port > > > >What if there were some other UDP based transport that required two UDP > >ports (perhaps even "RTPng")? You would need yet another draft to addre= ss > >it. Why not make the solution generic instead? >=20 > Well, if thats so, I would have rather had such a debate in the context= =20 > of the above draft. Anyway, I know of no other media stream that uses=20 > UDP that uses multiple ports AND that has an algorithmic relationship=20 > between those ports (i.e., has no way to express in the SDP which ports= =20 > are needed). Seems like a non-problem. Prior to IPv6 there was no known way to express a numeric IP address such that it would not fit into a 32-bit integer. Now there is, and it is one source of poring issues. Of course this is not a problem now. Can you say with certainty that it will never be a problem? There is no need to deliberately limit functionality in this way. Perhaps SDP is committed to its course, although it appears to still be in draft stage. We don't have to do the same with RTSP. > >I have just started looking at STUN but I have some questions: > > > >1. Given a NAT that supports RTSP (eg. Linux 2.2 masquerading with an RT= SP > > module loaded), will the client "detect" that it is behind a NAT?=20 >=20 > Yes. >=20 > > If so, > > how does this affect the Transport: header as it passes through? It > > seems to me that the RTSP enabled NAT will break the STUN-enabled > > Transport: header. If this is the case, I think that STUN should be > > reconsidered (at least for RTSP) as would break an otherwise function= al > > NAT setup. >=20 > A smart ALG won't. It should know not to muck with IP addresses inside=20 > of the RTSP message if they are not private addresses (if stun is used,= =20 > those addresses will have already been changed to public ones by the=20 > RTSP client). Indeed, one can imagine usign RTSP to setup a streaming=20 > media session to some third party device outside of the nat, in which=20 > case the ALG has to know not to change the IP. I wonder if the linux=20 > code you cite supports that. All of the four or so RTSP modules that I am familiar with simply look at client_port=3D and perform a mapping. In order to detect that a transport spec is using STUN, the module would also need to check for a destination=3D attribute. > Which, of course, brings me to my beef with ALG - the wrong people write= =20 > them in general. Only an RTSP expert would probably know to look for=20 > such nuances (even then...),=20 Indeed. I have written one of the modules referenced above and I did not consider it. On the other hand, the destination=3D parameter has always be= en a security risk at the server side and I am reluctant to advocate using it.= =20 Unfortunately, the overlap of people who would check for the destination=3D parameter and the people who know how to code ALGs is very very small.=20 Perhaps this argues for simpler protocol specs? > and Linksys and Netgear to not hire such people - its not their business. It certainly is their business if they make the equipment. It's enough of their business that they provide an ALG for FTP. But I think it should also be (or should have been) the business of the IETF to design a NAT traversal protocol which allows the client to directly request mapped ports from the NAT device. Such a protocol would reduce or eliminate the need for STUN and friends, and it would provide a single protocol for the vendors to implement instead of a running treadmill of RFCs. But the vendors have already been given a single protocol to implement: UPnP. It was created from the desire for NAT control at the client and appears to have a lot of support from NAT vendors already. And this makes me wonder why we are continuing to propose more NAT traversal solutions.=20 Why not either recommend UPnP or design an equivalent? > >I will have to do some checking, > > but IIRC the Linux 'ipchains' NAT code does mappings with a '5-tuple': > > client ip, client port, nat port, server ip, server port. If the lat= ter > > case is assumed (no relay), I don't think that the STUN mappings would > > behave as described in the draft. Packets sent to and from the=20 > > appserver > > will have a different 5-tuple, and thus a different nat port, renderi= ng > > STUN ineffective. Has this case been considered? >=20 > Certainly. This is called "symmetric NAT". Its common but to date the=20 > full-cone variety, which maps bindings by private IP/port alone, is=20 > quite prevalent amongst the home NATs. Interesting. Where can I find out more about how many home networks use which types of NAT? > >>>If the vendors won't support it, then adding more Transport attributes > >>>creates more implementation headaches for ourselves with little or no > >>>benefit. I think the best solution is to find out how to persuade the > >>>vendors to properly support RTSP. It is really not much more difficult > >>>to support than, say, FTP. > >> > >>I sinceerely doubt that. > > > > > >Which do you doubt? The implementation headaches or that RTSP support is > >not difficult in NAT? >=20 > That RTSP ALGs are likely to be supported widely in the vast array of=20 > $100 NAT boxes on the market. FTP *is* widely supported, but RTSP is a=20 > domain-specific protocol, and I suspect not on their radar screens. Unfortunately, I doubt any protocols requiring special handling besides FTP are on their radar screens. But UPnP compliance is, and together with the ALGs in Linux and FreeBSD and Symmetric RTP, I suspect that a vast majority of the home NATs are covered without STUN. > >>OPTION 1: Symmtric RTP. See=20 > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.tx= t.=20 > > > >This is similar to a technique that we (RealNetworks) use for our intern= al > >transport. It is quite effective (but not 100% of course).=20 >=20 > I am curious about what problems you have encountered. I was not personally involved in the testing but I can probably find someone who was. --=20 Happiness isn't something you experience; it's something you remember. -- Oscar Levant --OwLcNYc0lM97+oe1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+PxXIqznSmcYu2m8RAho/AKCBaaCAEeLjD03zBB7znuOZly+dPACfShcc ish6236pi38h3EJDSH37EOI= =QPHw -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 22:52:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29218 for ; Mon, 3 Feb 2003 22:52:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h143w9514637 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 22:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h143w9J14634 for ; Mon, 3 Feb 2003 22:58:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29208 for ; Mon, 3 Feb 2003 22:52:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h143vSJ14616; Mon, 3 Feb 2003 22:57:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h143uOJ14595 for ; Mon, 3 Feb 2003 22:56:24 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29166 for ; Mon, 3 Feb 2003 22:50:35 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h143sFYH015017; Mon, 3 Feb 2003 22:54:16 -0500 (EST) Message-ID: <3E3F3962.80100@dynamicsoft.com> Date: Mon, 03 Feb 2003 22:54:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: mmusic@ietf.org Subject: Re: [MMUSIC] comedia-fix and the whole source address/port boondoggle References: <5.1.1.6.0.20030107090246.03445d08@mail.rfdsoftware.com> <5.1.1.6.0.20030128115955.03105110@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. David Yon wrote: > At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote: > >> Responses inline. >> >> David Yon wrote: >> >>> comedia-fix again raises the argument against embedding the source >>> address/port information in the SDP. That is something that I still >>> feel strongly about, and work has progressed that makes use of it, >>> although not as a fail-safe session correlation mechanism. We've >>> found that it's useful as a DoS counter-measure, using the following >>> design: >>> - An intermediate proxy on our network acts as a STUN-like >>> inverse-NAT translator to at least recover the likely address >>> from where the media will originate, and rewrites the SDP >>> if necessary. >> >> >> It is quite a mystery to me how such a thing could possibly work in a >> causal fashion. The endpoint won't actually open any connections until >> after the offer/answer exchange has completed. The opening of the TCP >> connection is the thing which causes the NAT to assign a binding. So, >> the binding is assigned after the o/a exchange, but your proxy needs >> to know the binding before the exchange completes. So, I don't get it. > > > It works on ranking rather than absolute correlation. Ranking? > You're correct > about the NPAT port binding not being known ahead of time. However, > most NPAT scenarios involve a single IP Address, so a media connection > coming from that IP Address (regardless of source port) would be ranked > higher than one that comes an unknown address. None of this makes sense to me. The problem remains that the proxy cannot know anything about the allocated nat binding until media is sent. > > And let's not forget about connections that originate from dial-up > accounts (which accounts for the vast majority of home access), where > the IP Address and port are actually correct, in which case the ranking > is 100% accurate. Still makes no sense to me. Fact remains, that since you cannot know whether the source IP is accurate, it is simply unsafe to use. > > >>> - Our gateways, when under load, sort the incoming connection >>> pending queue based on source addresses that they expect >>> to arrive. >>> The idea is that when under DoS attack, connections sourced from >>> uninvited addresses are not dealt with until the queue of invited >>> addresses has been serviced. This is especially critical when the >>> media is carried over TLS, and in our case we do not commence with >>> the TLS handshake until either the connection has been correlated or >>> until servicing the connection does not overload the gateway. The >>> side-effect of a failed/incorrect inverse-NAT rewrite only occurs >>> under heavy load, and is not fatal. But without the source address >>> information, there is no way to implement such a scheme. >> >> >> Since, practically speaking, I would expect the majority of users to >> connect to things from behind a NAT, this mechanism serves little >> purpose to prevent DOS attacks. I don't understand why you would not >> use more tried-and-true mechanisms, such as return routability, which >> validate a source IP address by sending it a cookie, and getting this >> cookie back. Such a mechanism actually works through NAT, and you can >> provide much more than just service prioritiziation based on it. > > > Again, the scheme as described works in the presence of NAT (despite > assertions to the contrary), and allows the media to be 100% TLS without > any out-of-spec "enhancements". You simply dismiss my argument, but do not address it. My argument is, that when most users are behind NAT, the source IP of the TCP connection won't match that in the SDP, and the net result is that most if not all connections go in the low priority pool. This is equivalent to no priority. I have also asserted that there are more reliable, well-known techniques for DoS protection against these kinds of attacks, which work better. > >> I still maintain that, given we are painfully aware of the trials and >> tribulations of distributing source IP addresses in protocols, and >> given the vast potential for misuse, and the potentially small (if not >> ZERO) deployable benefits of this mechanism, I would like to see it >> removed. It is one thing to include a mechanism that is useful in many >> cases, but might not work in some (and then documenting such) as >> compared to a mechanism that will most likely be misused, and whose >> real benefit is small or zero. > > > It is OPTIONAL in the spec, and the limitations clearly outlined. At > least one implementation finds it useful. I don't know how to be more > clear than that, and why it causes such heartburn. Because its unsafe. You have put a piece of information there, for which there is NO WAY to ever know whether it is reliable. Its not that it might be wrong, you don't know when its wrong and when its not. If I am building a proxy that wishes to look at the source IP in the SDP, and configure a pinhole in a firewall, instead of a cone, what advice can you give me about when I can use this source IP field? Your only answer is, you can only use it when you know its right because you control every piece of equipment on the network (the clients and all intervening nats). How can I be sure that this is the case? Someone all of a sudden installs a linksys and everything stops working, because the pinholes are not opened properly. That would be a fun customer call to get at 2 in the morning. Anyway, this has remained a largely one-on-one discussion. I think all that can be said has been said, on my part anyway. I would like to hear from our esteemed chairs on whether this feature stays or goes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 23:05:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29436 for ; Mon, 3 Feb 2003 23:05:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h144AdK15658 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 23:10:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h144AdJ15655 for ; Mon, 3 Feb 2003 23:10:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29433 for ; Mon, 3 Feb 2003 23:04:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h144A3J15632; Mon, 3 Feb 2003 23:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1449SJ15600 for ; Mon, 3 Feb 2003 23:09:28 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29380 for ; Mon, 3 Feb 2003 23:03:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1447LYH015021; Mon, 3 Feb 2003 23:07:21 -0500 (EST) Message-ID: <3E3F3C73.6020804@dynamicsoft.com> Date: Mon, 03 Feb 2003 23:07:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: mmusic@ietf.org Subject: Re: [MMUSIC] comedia-fix-00 comments References: <5.1.1.6.0.20030103094038.00b37198@mail.rfdsoftware.com> <5.1.1.6.0.20030128121040.03130008@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Yon wrote: > At 09:58 PM 1/14/2003, Jonathan Rosenberg wrote: > >> David, >> >> Ben, Paul and I discussed your comments extensively over the last week >> or so. Our conclusion was that we will not use comedia for simple >> messaging sessions. At a high level, the conclusion was that we were >> looking at "message sessions over TCP" and that comedia was perhaps >> optimized for "streaming media sessions over TCP". As such, many of >> our requirements that were critical, or assumptions we could make >> (such as demux within a single TCP connection) don't necessarily apply >> to streaming media over TCP. >> >> Now, I still think that much of what we proposed is valid. However, it >> is no longer critical to get it changed. So, keep that in mind as you >> read my responses below. > > > The the meta-question is whether comedia-fix will continue to block > comedia's progress. On one hand you imply above that it won't, but then > again we have the rest of this email that argues that comedia is > severely flawed. So, where are we going from here? I still have a big beef with the source IP/port, per separate email. Beyond that, I believe that the limitations of comedia will restrict its utility; certainly, they limited the ability for me to use it. But since I am not using it, I am not going to complain further about things where nothing is broken per se, its just not what I think is the right thing. Thus, the one port vs. many port debate, and connection lifetime issues, I won't pursue further. However, the only other one is the security issue I have pointed out, where an eavesdropper can open connections allowing it to both send and receive media. You need to address it, both with protocol machinery and a note in security considerations. Your proposed solution of detecting a second connection on the same port, and then closing both and indicating an error or attack, is OK I believe, but it needs to be added. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 3 23:20:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29652 for ; Mon, 3 Feb 2003 23:20:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h144QHt16196 for mmusic-archive@odin.ietf.org; Mon, 3 Feb 2003 23:26:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h144QHJ16193 for ; Mon, 3 Feb 2003 23:26:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29640 for ; Mon, 3 Feb 2003 23:20:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h144Q6J16159; Mon, 3 Feb 2003 23:26:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h144P1J16091 for ; Mon, 3 Feb 2003 23:25:01 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29604 for ; Mon, 3 Feb 2003 23:19:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h144MpYH015030; Mon, 3 Feb 2003 23:22:51 -0500 (EST) Message-ID: <3E3F4015.2070800@dynamicsoft.com> Date: Mon, 03 Feb 2003 23:22:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: <3E3E982E.2010706@era.ericsson.se> <20030203181518.GA26315@real.com> <3E3ECD0D.8010601@dynamicsoft.com> <20030203223939.GB26777@real.com> <3E3EFF32.2090103@dynamicsoft.com> <20030204012216.GC26777@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Tom Marshall wrote: > On Mon, Feb 03, 2003 at 06:45:54PM -0500, Jonathan Rosenberg wrote: > >> >>Tom Marshall wrote: >> >> >>>>STUN does not allocate the addresses. It merely tells the client what a >>>>regular, off the shelf NAT has allocated to a user. Since regular, >>>>off-the-shelf NATs do not know anything about RTP port pairings, two >>>>separate STUN requests will result in a nat allocating two bindings >>>>which are most likely not consecutive (or follow the odd/even rule). >>>>THis is dealt with through an SDP extension that allows a client to >>>>provide a specific address and port for SDP >>>>(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt). >>> >>> >>>This draft again assumes that RTP is the only transport choice: >>> >>> rtcp-attribute = "a=rtcp:" port >>> >>>What if there were some other UDP based transport that required two UDP >>>ports (perhaps even "RTPng")? You would need yet another draft to address >>>it. Why not make the solution generic instead? >> >>Well, if thats so, I would have rather had such a debate in the context >>of the above draft. Anyway, I know of no other media stream that uses >>UDP that uses multiple ports AND that has an algorithmic relationship >>between those ports (i.e., has no way to express in the SDP which ports >>are needed). Seems like a non-problem. > > > Prior to IPv6 there was no known way to express a numeric IP address such > that it would not fit into a 32-bit integer. Now there is, and it is one > source of poring issues. Of course this is not a problem now. Can you say > with certainty that it will never be a problem? Seems like a bit of an over-exaggerated analogy. As I said, for any new protocol that needs multiple ports, it should simply make sure that its SDP parameter definitions include them. In such a case you will never have a problem. Anyway, the point is moot, since, based on my limited RTSP knowledge, SDP is not used in the client addresses anyway. Thus, you can't use the SDP draft above. >>A smart ALG won't. It should know not to muck with IP addresses inside >>of the RTSP message if they are not private addresses (if stun is used, >>those addresses will have already been changed to public ones by the >>RTSP client). Indeed, one can imagine usign RTSP to setup a streaming >>media session to some third party device outside of the nat, in which >>case the ALG has to know not to change the IP. I wonder if the linux >>code you cite supports that. > > > All of the four or so RTSP modules that I am familiar with simply look at > client_port= and perform a mapping. In order to detect that a transport > spec is using STUN, the module would also need to check for a destination= > attribute. Right. Although, I must admit confusion. If the client doesnt provide a destination attribute, to what IP address is the media sent? It seems to me that the destination parameter would normally be there. Or perhaps you are saying it is there, but its not looked at by the ALG? > > >>Which, of course, brings me to my beef with ALG - the wrong people write >>them in general. Only an RTSP expert would probably know to look for >>such nuances (even then...), > > > Indeed. I have written one of the modules referenced above and I did not > consider it. On the other hand, the destination= parameter has always been > a security risk at the server side and I am reluctant to advocate using it. I guess I don't understand how media is delivered to the client then. > It certainly is their business if they make the equipment. It's enough of > their business that they provide an ALG for FTP. But I think it should also > be (or should have been) the business of the IETF to design a NAT traversal > protocol which allows the client to directly request mapped ports from the > NAT device. Such a protocol would reduce or eliminate the need for STUN and > friends, and it would provide a single protocol for the vendors to implement > instead of a running treadmill of RFCs. Oh yes, no doubts there. midcom has been trying for years, and still no success. Even then, once its done, it doesn't work for many topoligies. The ultimate right answer is nsis, which would allow the client to directly ask for bindings through all nats that it will need to talk to. But, we are years and years away from such a thing seeing deployment. > > But the vendors have already been given a single protocol to implement: > UPnP. It was created from the desire for NAT control at the client and > appears to have a lot of support from NAT vendors already. And this makes > me wonder why we are continuing to propose more NAT traversal solutions. > Why not either recommend UPnP or design an equivalent? I indicated in another mail several problems with upnp. Another practical one is that its not that widely deployed yet. So, when an media company wants to deploy, do they wait and hope that people go off and buy upgrades to their nat, or hope all the nat vendors fall in line? No way. They want to be able to deploy the service now, without being dependent on features placed into home routers. Anyway, ietf is working on their version of upnp, which is the midcom protocol. >>Certainly. This is called "symmetric NAT". Its common but to date the >>full-cone variety, which maps bindings by private IP/port alone, is >>quite prevalent amongst the home NATs. > > > Interesting. Where can I find out more about how many home networks use > which types of NAT? I've heard reports of studies done on the subject, but have not seen concrete or quotable reports. I think such an analysis, especially tracking it over time, would be a great masters project for some student somewhere. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 4 02:24:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12780 for ; Tue, 4 Feb 2003 02:24:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h147U8003959 for mmusic-archive@odin.ietf.org; Tue, 4 Feb 2003 02:30:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147U7J03954 for ; Tue, 4 Feb 2003 02:30:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12773 for ; Tue, 4 Feb 2003 02:24:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147TaJ03909; Tue, 4 Feb 2003 02:29:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147SUJ03882 for ; Tue, 4 Feb 2003 02:28:30 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12767 for ; Tue, 4 Feb 2003 02:22:38 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18fxT9-000859-00; Mon, 03 Feb 2003 23:26:11 -0800 Date: Mon, 3 Feb 2003 23:26:11 -0800 From: Tom Marshall To: Jonathan Rosenberg Cc: Magnus Westerlund , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs Message-ID: <20030204072611.GA31035@real.com> References: <3E3E982E.2010706@era.ericsson.se> <20030203181518.GA26315@real.com> <3E3ECD0D.8010601@dynamicsoft.com> <20030203223939.GB26777@real.com> <3E3EFF32.2090103@dynamicsoft.com> <20030204012216.GC26777@real.com> <3E3F4015.2070800@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <3E3F4015.2070800@dynamicsoft.com> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >>>This draft again assumes that RTP is the only transport choice: > >>> > >>>rtcp-attribute =3D "a=3Drtcp:" port > >>> > >>>What if there were some other UDP based transport that required two UDP > >>>ports (perhaps even "RTPng")? You would need yet another draft to=20 > >>>address > >>>it. Why not make the solution generic instead? > >> > >>Well, if thats so, I would have rather had such a debate in the context= =20 > >>of the above draft. Anyway, I know of no other media stream that uses= =20 > >>UDP that uses multiple ports AND that has an algorithmic relationship= =20 > >>between those ports (i.e., has no way to express in the SDP which ports= =20 > >>are needed). Seems like a non-problem. > > > > > >Prior to IPv6 there was no known way to express a numeric IP address such > >that it would not fit into a 32-bit integer. Now there is, and it is one > >source of poring issues. Of course this is not a problem now. Can you = say > >with certainty that it will never be a problem? >=20 > Seems like a bit of an over-exaggerated analogy. As I said, for any new= =20 > protocol that needs multiple ports, it should simply make sure that its= =20 > SDP parameter definitions include them. In such a case you will never=20 > have a problem. How is it better to require more work down the road (someone has to write a draft, etc.) than build an extensible specification? It may not be likely that anyone will need the functionality, but it really does not require any more work to provide up front and you may reduce the work later on. What reason is there for not making an extensible solution (besides "it is unlilkely anyone would ever use it")? > Anyway, the point is moot, since, based on my limited RTSP knowledge,=20 > SDP is not used in the client addresses anyway. Thus, you can't use the= =20 > SDP draft above. You were the one who mentioned it. ;-) It is analogous to the proposed rtcp_client_port attribute in the RTSP Transport: header. > >>A smart ALG won't. It should know not to muck with IP addresses inside= =20 > >>of the RTSP message if they are not private addresses (if stun is used,= =20 > >>those addresses will have already been changed to public ones by the=20 > >>RTSP client). Indeed, one can imagine usign RTSP to setup a streaming= =20 > >>media session to some third party device outside of the nat, in which= =20 > >>case the ALG has to know not to change the IP. I wonder if the linux=20 > >>code you cite supports that. > > > > > >All of the four or so RTSP modules that I am familiar with simply look at > >client_port=3D and perform a mapping. In order to detect that a transpo= rt > >spec is using STUN, the module would also need to check for a destinatio= n=3D > >attribute. >=20 > Right. Although, I must admit confusion. If the client doesnt provide a= =20 > destination attribute, to what IP address is the media sent? It seems to= =20 > me that the destination parameter would normally be there. Or perhaps=20 > you are saying it is there, but its not looked at by the ALG? In the absence of a destination=3D attribute (which is far and away the most common case as you may have inferred), the server sends to the same address as the foreign end of the RTSP connection. Disallowing the destination=3D parameter pretty much eliminates the possibility for DoS abuse (hey server, go flood this IP address with UDP data). The possibility is more than idle speculation -- a very similar DoS issue for online gaming servers was recently discovered and published online (I forget which site but I can probably find the article again if desired). A few fat video stream makes online game servers' response packets look like child's play. --=20 There is nothing new under the sun, but there are lots of old things we don't know yet. -- Ambrose Bierce --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+P2sTqznSmcYu2m8RAlZBAJ9DJUu/LL9lIL4FmVK8meLtIdGsFACeKD4z ow/DuKBr2isJJuLiuR7YE+0= =u5Uz -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 4 06:46:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17512 for ; Tue, 4 Feb 2003 06:46:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Bq1l19795 for mmusic-archive@odin.ietf.org; Tue, 4 Feb 2003 06:52:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Bq1J19792 for ; Tue, 4 Feb 2003 06:52:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17439 for ; Tue, 4 Feb 2003 06:46:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BpsJ19772; Tue, 4 Feb 2003 06:51:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BojJ19644 for ; Tue, 4 Feb 2003 06:50:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17227; Tue, 4 Feb 2003 06:44:47 -0500 (EST) Message-Id: <200302041144.GAA17227@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Feb 2003 06:44:47 -0500 Subject: [MMUSIC] I-D ACTION:draft-camarillo-mmusic-alt-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Alternative Semantics for the Session Description Protocol Grouping Framework Author(s) : G. Camarillo, J. Rosenberg Filename : draft-camarillo-mmusic-alt-00.txt Pages : 8 Date : 2003-2-3 This document defines the alternative (ALT) semantics for the SDP grouping framework. The ALT semantics allow offering alternative media configurations to establish a particular media stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-alt-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-mmusic-alt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-mmusic-alt-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-mmusic-alt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-mmusic-alt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-3125500.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 4 07:07:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18816 for ; Tue, 4 Feb 2003 07:07:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14CDEP21940 for mmusic-archive@odin.ietf.org; Tue, 4 Feb 2003 07:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CDEJ21937 for ; Tue, 4 Feb 2003 07:13:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18768 for ; Tue, 4 Feb 2003 07:07:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CD5J21921; Tue, 4 Feb 2003 07:13:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CC9J21895 for ; Tue, 4 Feb 2003 07:12:09 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18664 for ; Tue, 4 Feb 2003 07:06:12 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14C9lAv026550 for ; Tue, 4 Feb 2003 13:09:47 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5JM7YX; Tue, 4 Feb 2003 13:09:47 +0100 Message-ID: <3E3FAD8B.6090500@era.ericsson.se> Date: Tue, 04 Feb 2003 13:09:47 +0100 X-Sybari-Trust: ed9ccdec 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: <3E3E982E.2010706@era.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I would like to try to summarize and give my comments to Tom's and Jonathan's discussion. These are issues to continue to discuss here on the list but which will also be brought up on tomorrow's RTSP teleconference. 1. We might break out the NAT traversal part into a separate specification. However we must look at how it relates to mechanisms that will be in the base spec. I think it is important that as soon as possible we outline these solutions. 2. The use of "client_rtcp_port" versus changing "client_port". Your are correct that it might not be necessary to call it RTCP port. What we will need for STUN support is to possibility to specify two explicit port numbers without relation to each other. The general case would then to allow to specify any set of port numbers in both directions. This will cover any future transport protocol. However I went on to a new parameter to avoid changing the already present parameters syntax. If people find this acceptable then we can basically do anything with "client_port". 3. Symmetric RTP. - STUN over cone nats work without changing the servers, where symmetric RTP requires server changes. - Symmetric has hi-jacking potentials that will impossible to protect against without RTP/RTCP based ID/authentication scheme. - Needs binding mechanism for RTP/RTCP packets to the correct RTSP Session. - Potential RTSP middle box (proxies, caches) problems. Should any way be fixed for future RECORD servers. - Otherwise of course a nice solution. 4. ALG's - ALG: Deployment issues, especially for extensions - ALG: Sub-standard implementations - Prevent end-to-end security. - Interactions between ALG's STUN is a potential problem. 5. UPnP or MIDCOM. - Time to deploy these solutions. - no real conflict, if UPnP/midcom is available use it. 6. Jonathan's other proposal Please provide it so that we can discuss it. 7. Use of "Destination" parameter for NAT/ALG's - Destination might be needed if NAT maps using several IP addresses to same client. - Needs client based authentication of that address/port in RTSP message to work in secure ways. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 4 07:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19174 for ; Tue, 4 Feb 2003 07:10:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14CG5S22172 for mmusic-archive@odin.ietf.org; Tue, 4 Feb 2003 07:16:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CG5J22169 for ; Tue, 4 Feb 2003 07:16:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19060 for ; Tue, 4 Feb 2003 07:10:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CG1J22153; Tue, 4 Feb 2003 07:16:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CFKJ22074 for ; Tue, 4 Feb 2003 07:15:20 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18975 for ; Tue, 4 Feb 2003 07:09:22 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h14CC2027921; Tue, 4 Feb 2003 07:12:02 -0500 Message-Id: <5.1.1.6.0.20030204064420.037d76f0@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Feb 2003 07:12:45 -0500 To: Jonathan Rosenberg From: David Yon Subject: Re: [MMUSIC] comedia-fix and the whole source address/port boondoggle Cc: mmusic@ietf.org In-Reply-To: <3E3F3962.80100@dynamicsoft.com> References: <5.1.1.6.0.20030107090246.03445d08@mail.rfdsoftware.com> <5.1.1.6.0.20030128115955.03105110@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 10:54 PM 2/3/2003, Jonathan Rosenberg wrote: >inline. > >David Yon wrote: >>At 09:02 PM 1/14/2003, Jonathan Rosenberg wrote: >>> >>> >>>Since, practically speaking, I would expect the majority of users to >>>connect to things from behind a NAT, this mechanism serves little >>>purpose to prevent DOS attacks. I don't understand why you would not use >>>more tried-and-true mechanisms, such as return routability, which >>>validate a source IP address by sending it a cookie, and getting this >>>cookie back. Such a mechanism actually works through NAT, and you can >>>provide much more than just service prioritiziation based on it. >> >>Again, the scheme as described works in the presence of NAT (despite >>assertions to the contrary), and allows the media to be 100% TLS without >>any out-of-spec "enhancements". > >You simply dismiss my argument, but do not address it. > >My argument is, that when most users are behind NAT, the source IP of the >TCP connection won't match that in the SDP, and the net result is that >most if not all connections go in the low priority pool. This is >equivalent to no priority. I have also asserted that there are more >reliable, well-known techniques for DoS protection against these kinds of >attacks, which work better. > Well, one more try and then I'll agree to leave the topic where it is. The piece of the puzzle you may be missing is that our system has the luxury of "owning" the front-line SIP proxies, and those proxies are outside of any client NAT boxes. They can determine whether NATting is going on, and what the translation is FOR THE IP ADDRESS. So if an INVITE is coming from an endpoint who's claiming a source address of 192.168.0.128, but the INVITE message is sourced from the address 216.153.163.173, it: (a) knows there's a NAT (b) knows with a high degree of certainty that the media will also appear to be sourced from 216.153.163.173. It therefore rewrites the source address from 192.168.0.128 to 216.153.163.173 for the downstream proxies (just like some poor tech at Netgear would have to do in their ALG :-)). The vast majority of NAT's use a single public address, so this translation works. Really. We've seen it. Existence proof hard at work. >>>I still maintain that, given we are painfully aware of the trials and >>>tribulations of distributing source IP addresses in protocols, and given >>>the vast potential for misuse, and the potentially small (if not ZERO) >>>deployable benefits of this mechanism, I would like to see it removed. >>>It is one thing to include a mechanism that is useful in many cases, but >>>might not work in some (and then documenting such) as compared to a >>>mechanism that will most likely be misused, and whose real benefit is >>>small or zero. >> >>It is OPTIONAL in the spec, and the limitations clearly outlined. At >>least one implementation finds it useful. I don't know how to be more >>clear than that, and why it causes such heartburn. > >Because its unsafe. You have put a piece of information there, for which >there is NO WAY to ever know whether it is reliable. Its not that it might >be wrong, you don't know when its wrong and when its not. If I am building >a proxy that wishes to look at the source IP in the SDP, and configure a >pinhole in a firewall, instead of a cone, what advice can you give me >about when I can use this source IP field? Your only answer is, you can >only use it when you know its right because you control every piece of >equipment on the network (the clients and all intervening nats). How can I >be sure that this is the case? Someone all of a sudden installs a linksys >and everything stops working, because the pinholes are not opened >properly. That would be a fun customer call to get at 2 in the morning. While there's room for argument here, I'll just leave this for now. >Anyway, this has remained a largely one-on-one discussion. I think all >that can be said has been said, on my part anyway. I would like to hear >from our esteemed chairs on whether this feature stays or goes. Yes, indeed, I would also like to hear from the chairs on this. >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 4 07:21:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19673 for ; Tue, 4 Feb 2003 07:21:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14CR9R22724 for mmusic-archive@odin.ietf.org; Tue, 4 Feb 2003 07:27:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CR9J22721 for ; Tue, 4 Feb 2003 07:27:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19669 for ; Tue, 4 Feb 2003 07:21:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CR2J22711; Tue, 4 Feb 2003 07:27:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CQQJ22687 for ; Tue, 4 Feb 2003 07:26:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19656 for ; Tue, 4 Feb 2003 07:20:28 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14CO4KV010878 for ; Tue, 4 Feb 2003 13:24:04 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW0C7BWW; Tue, 4 Feb 2003 13:24:04 +0100 Message-ID: <3E3FB0E1.5060402@era.ericsson.se> Date: Tue, 04 Feb 2003 13:24:01 +0100 X-Sybari-Trust: e7bb358d 9ffcebbb 22f6c2a2 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-00.txt References: <200301311251.HAA05102@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In this revision of the Transport independent SDP bandwidth modifiers the following changes has been performed: - Removed "avgprate" as it is not useful. - Removed the RTCP rules present in the last proposal and replaced them with simpler ones. If 5% RTCP bandwidht that shall be based on the local transport dependent rate. - Clarified the text. - Brought the text up to ID-nits level, ready for publication. As I think this document is ready and address the comments that I have received, I would like to ask for a WG last call on draft-ietf-mmusic-sdp-bwparam-00.txt. Best Regards Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 5 12:35:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02985 for ; Wed, 5 Feb 2003 12:35:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HfOm09799 for mmusic-archive@odin.ietf.org; Wed, 5 Feb 2003 12:41:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HfOJ09796 for ; Wed, 5 Feb 2003 12:41:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02963 for ; Wed, 5 Feb 2003 12:34:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HfGJ09785; Wed, 5 Feb 2003 12:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HeiJ09759 for ; Wed, 5 Feb 2003 12:40:44 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02929 for ; Wed, 5 Feb 2003 12:34:08 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 93371A39F2; Wed, 5 Feb 2003 18:37:44 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA01586; Wed, 5 Feb 2003 18:37:40 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA02209; Wed, 5 Feb 2003 18:37:37 +0100 (MET) Subject: Re: [MMUSIC] RTSP and NATs To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 5 Feb 2003 18:31:29 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 05/02/2003 18:38:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, I strongly support the recommendation to not use ALGs, therefore STUN should be used instead but then you wrote: > To be able to use STUN to traverse symmetric NATs the STUN server > needs to be co-located with the streaming server media distribution > ports. As this will create implementations difficulties and possi- > bly security problems this SHOULD NOT be done. I am surprised, I would have proposed _on the contrary_ a "SHOULD" here (since traversing symetric NATs is a key feature) ! also what do you mean by "implementation difficulties" ? (I really cannot see any ?) and could you explicit what type of _additional_ security issues this would cause (i.e. issues that are not inherent to running either a RTSP or a STUN server in the first place ?) regards Philippe Gentric Software Architect Philips MP4Net "philippe dot gentric at philips dot com" http://www.platform4.philips.com To: IETF MMUSIC WG cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Subject: [MMUSIC] RTSP and NATs Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 03/02/2003 17:26 Hi, Here is a proposal to the RTSP spec for how to handle NATs using STUN. Please read and comment. It is planned to discuss NAT's on wednessday's RTSP telecon. Cheers Magnus --------------------------------------- 15 RTSP through Firewalls & NATs 15.1 Introduction Today there is Network Address Translators (NAT) [32] everywhere and a protocol must make sure that it can work through them in some fashion. The problem with RTSP is that it carries information about network addresses and ports inside itself. It is primarily the media streams that are being blocked by NAT, as the given address to send to is a local one. Firewalls are also middle boxes that needs to be considered. They are deployed to prevent non-desired traffic/protocols to be used or reach the protected network. RTSP is designed to allow a firewall to let RTSP controlled streams through, if chosen to, with minimal implementation problems. 15.2 NAT Today there exist a number of different NAT types and usage areas. The different NAT types, cited from STUN [31]: Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. Port Restricted Cone: A port restricted cone NAT is like a res- tricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. NAT's are used on both small and large scale. The normal small scale user is home user that has a NAT to allow multiple computers share the single IP address given by their Internet Service Pro- vider (ISP). The large scale users are the ISP's themselves that gives there users private addresses. This is done both for control and lack of addresses. 15.2.1 STUN The STUN [31] protocol allows a client to discover the type of NAT(s) he is behind and also discover a mappings public address and port number. The protocol also allows discovery of the mappings timeout period and can be used as keep alive mechanism. How useful this protocol is depends on the type of NAT(s) the client is behind. If the user is behind a full cone NAT, STUN allows the RTSP client to traverse the NAT with some simple client side adaptations. For restricted cone NATs STUN is still useful but require some more adaptations. For symmetric NATs STUN requires such severe server adaptations that it is not practical to use. A RTSP client using RTP transport can use STUN to traverse a full cone NAT in the following way: 1. Use STUN to discover the type of NAT, if any, and the timeout period for any UDP mapping on the NAT. This is RECOMMENDED to be performed in the background as soon as IP connectivity is established. If this is performed prior to the attempt to establish a streaming session the possible delays in the ses- sion establishment will be reduced. If no NAT is present, use the normal SETUP behavior. 2. The RTSP client determines the number of UDP ports needed by the RTP sessions part of the multi-media presentation. This information is available in the media description protocol used, e.g. SDP. In general each RTP session will require two UDP ports, one for RTP, and one for RTCP. Ensure that the same public IP address is used for each RTP/RTCP port pair esta- blished. 3. For each UDP port required, establish a mapping and discover the public IP address and port number with use of STUN. if successful this results in that the client now knows for each port know the mapping: clients local address/port Leftrightar- row public address/port. 4. Perform the RTSP SETUP for each media. In the transport header the following parameters SHOULD be included with the given values: "destination" with the public IP address, "client_port" with the public port of the mapping determined to be used for RTP, "client_rtcp_port" with the port number of the mapping to be used for RTCP. The parameter "client_rtcp_port" needs to be used unless the client has managed to establish a mapping with two consecutive numbers starting with an even one. To allow this to work servers MUST allow a client to setup the RTP stream on any port, not only even ports. The server SHALL respond with a transport header containing the source IP address of the media streams. 5. To keep the mappings alive the client SHOULD periodically send UDP traffic over all mappings needed for the session. STUN can be used to determine the timeout period of the NAT(s) UDP map- pings. For the mapping carrying RTCP traffic the periodic RTCP traffic may be sent frequently enough. If not or for RTP car- rying mappings, empty IP/UDP messages SHOULD be sent to the streaming servers discard port (port number 9). If a UDP mapping is lost above process is required to be performed again and the media stream effected SETUP again. To allow the UDP packets to arrive from the server to a client behind a restricted NAT, any UDP messages must be sent to the server. Therefore SHOULD the client, before sending a RTSP PLAY request send an empty UDP message, on each mapping, to the IP address given as the servers source address and its discard port (port number 9). Otherwise no difference in procedure compared with a full cone NAT is needed. For a port restricted NAT the client must send messages to the exact ports used by the server to send messages. This makes it pos- sible to use the above described process with the following addi- tions: For each port mapping, a UDP message needs to be sent to the servers source address/port. To minimize potential effects on the server from these messages the following type of messages MUST be sent. RTP: An empty UDP message with out any payload. RTCP: A correctly formed RTCP message. Unless enough bandwidth is assigned to RTCP it might not be possible to keep the UDP mapping open. These messages SHOULD be sent before sending a PLAY request and then periodically according to the determined timeout time of the NAT. To be able to use STUN to traverse symmetric NATs the STUN server needs to be co-located with the streaming server media distribution ports. As this will create implementations difficulties and possi- bly security problems this SHOULD NOT be done. 15.2.2 Application Level Gateways An Application Level Gateway (ALG) reads the application level mes- sages and perform necessary changes to allow the protocol to work through the middle box. However this behavior has some problems in regards to RTSP: 1. Does not work when protocol is used with end-to-end security. As the ALG can't inspect and change the application level mes- sages the protocol will fail over the middle box. 2. Needs to be updated if extensions to the protocol are added. Due to deployment issues with changing ALG's this may also break the end-to-end functionality of RTSP. Due to the above reasons it is RECOMMENDED to not use ALGs in NATs. This is especially important for NAT's targeted to home users and not ISPs. In that case it is recommended that NATs are full cone and that the RTSP client instead used STUN or the planned MIDCOM protocols. An ALG for the this specification would need to perform the follow- ing tasks and changes to RTSP: 1. Detect a SETUP request. Create UDP mappings (client given IP/port Leftrightarrow public IP/port) where needed for all possible transport specification in the transport header of the request found in (1). Enter the public address and port(s) of these mappings in transport header. Mappings SHALL be created with consecutive public port number starting on a even number for RTP each stream. Mappings SHOULD also be given a long timeout period, at least 5 minutes. 2. When the response is received from the server the ALG MAY remove the unused UDP mappings, i.e. the ones not present in the transport header. The session ID SHOULD also be bound to the UDP mappings part of that session. 3. The ALG SHOULD keep alive the UDP mappings belonging to the an RTSP session as long as: RTSP messages with the session's ID has been sent in the last RTSP session timeout interval, or UDP messages are sent on any of the UDP mappings during the last RTSP timeout interval. 4. The ALG MAY remove a mapping as soon a TEARDOWN response has been received for that media stream. 15.2.3 TCP Tunneling TCP tunneling is the final fallback to get any RTSP controlled streaming to work through a NAT. As it is the client that establish the TCP connection to the server it will automatically create a binding through the NAT. This connection can then be used by the server to send media packets in. Using TCP tunneling has the drawback on real-time properties that TCP has with "head of line" blocking. It may also have large varia- tions in through put due to the congestion control algorithm. TCP tunneling must also be supported by both server and client. See section 10.11 for how to perform TCP tunneling. 15.3 Firewalls Firewalls exist for a purpose to protect a network from traffic not desired by the firewall owner. Therefore it is a policy decision if a firewall will let RTSP and its media streams through or not. RTSP is designed to be as easy as possible to process for a firewall with a policy to let the traffic pass through. The firewall will need to allow the media streams associated with a RTSP session pass through it. Therefore the firewall will need an ALG that reads RTSP SETUP and TEARDOWN messages. By reading the SETUP message the firewall can determine what type of transport and from where the media streams will use. Very common will be the need to open UDP ports for RTP/RTCP. By looking at the source and desti- nation addresses and ports the opening in the firewall can be minimized to the least necessary. The opening in the firewall can be closed after a teardown message for that session or the session itself timesout. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 5 13:43:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06140 for ; Wed, 5 Feb 2003 13:43:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15InPT13825 for mmusic-archive@odin.ietf.org; Wed, 5 Feb 2003 13:49:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15InPJ13822 for ; Wed, 5 Feb 2003 13:49:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06129 for ; Wed, 5 Feb 2003 13:42:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15InIJ13814; Wed, 5 Feb 2003 13:49:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15ImfJ13781 for ; Wed, 5 Feb 2003 13:48:41 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06115 for ; Wed, 5 Feb 2003 13:42:04 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h15IjgKV005196; Wed, 5 Feb 2003 19:45:42 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5TQJN0; Wed, 5 Feb 2003 19:45:42 +0100 Message-ID: <3E415BD6.90607@era.ericsson.se> Date: Wed, 05 Feb 2003 19:45:42 +0100 X-Sybari-Trust: 026a0f6f 9ffcebbb 22f6c2a2 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, philippe.gentric@philips.com wrote: >Magnus, > >I strongly support the recommendation to not use ALGs, >therefore STUN should be used instead but then you wrote: > > > > To be able to use STUN to traverse symmetric NATs the STUN server > > needs to be co-located with the streaming server media distribution > > ports. As this will create implementations difficulties and possi- > > bly security problems this SHOULD NOT be done. > >I am surprised, I would have proposed _on the contrary_ a "SHOULD" here >(since traversing symetric NATs is a key feature) ! > > >also what do you mean by "implementation difficulties" ? (I really cannot see any ?) >and could you explicit what type of _additional_ security issues this would cause >(i.e. issues that are not inherent to running either a RTSP or a STUN server in the first place ?) > > The problem of running STUN for a symmetric NAT is that the STUN server must be located at the servers sending port. So using the same RTSP mechanism that are used for traversing a cone-nat the client would: 1. first contact a well known port with the server for each his media stream to get the mapping of the stream. The client can't use any other then the well known port because it doesn't know what port to send to. 2. In the SETUP ask the server to send from its STUN servers well known port. It also needs to receive RTCP on that port. 3. For keep alive on the RTP port the client needs to send periodically STUN messages to the STUN server. This is a mess for a implementor. It need to have a STUN server receiving the STUN messages while the RTP/RTCP stack should receive all other messages. Also all the clients need to reside on the same port number which creates a multiplexing nightmare. If you change the setup phase so that the streams are first SETUP to dummy ports then reconfigured with a later message, the STUN could be located at each media streams source address. However in this setup it is actually better to use symmetric RTP in all regards except perhaps hi-jacking of media streams. However with certain restrictions you can actually end up with at least the same level of security that RTSP provides today. How are you using STUN to traverse a symmetric NAT? Best Regards Magnus -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 7 04:56:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03406 for ; Fri, 7 Feb 2003 04:56:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17A3Sb21886 for mmusic-archive@odin.ietf.org; Fri, 7 Feb 2003 05:03:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17A3Sp21881 for ; Fri, 7 Feb 2003 05:03:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03390 for ; Fri, 7 Feb 2003 04:56:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17A3Mp21872; Fri, 7 Feb 2003 05:03:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17A2Gp21834 for ; Fri, 7 Feb 2003 05:02:16 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03377 for ; Fri, 7 Feb 2003 04:54:51 -0500 (EST) From: ssundaragopalan@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h179SVa17452; Fri, 7 Feb 2003 14:58:32 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CC6.00364643 ; Fri, 7 Feb 2003 15:22:49 +0530 X-Lotus-FromDomain: HSSBLR To: Gonzalo Camarillo , Henning Schulzrinne cc: stoshniwal@hss.hns.com, mmusic Message-ID: <65256CC6.00364597.00@sampark.hss.hns.com> Date: Fri, 7 Feb 2003 15:22:33 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [MMUSIC] Deleted Streams in Grouping Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, Suppose there exists a group which groups two media streams m1 and m2. If a stream gets deleted in the middle of the session(say m1), then do we have to remove the "Media Stream Identification tag"(mid) from the grouping??. The RFC says we will have to remove the mid's for rejected streams. There is no mention about deleted streams. If we dont do this then there might be a problem when we try to add a new stream(say m3). Assume that we have deleted m1 from the session and the *mid* is not removed from grouping. When we try to add a third stream m3 to the session, the slot of the deleted stream gets reused. Also the Media Stream Identification tag(mid) remains the same . This will cause this stream to be part of the grouping, which is not TRUE. Please clarify. Thanks and regds, srikanth sundaragopalan Hughes Software Systems. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 7 05:29:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04150 for ; Fri, 7 Feb 2003 05:29:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17AaBK23751 for mmusic-archive@odin.ietf.org; Fri, 7 Feb 2003 05:36:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AaAp23748 for ; Fri, 7 Feb 2003 05:36:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04145 for ; Fri, 7 Feb 2003 05:28:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Aa6p23733; Fri, 7 Feb 2003 05:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AZvp23712 for ; Fri, 7 Feb 2003 05:35:57 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04142 for ; Fri, 7 Feb 2003 05:28:33 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17AW4Av006045; Fri, 7 Feb 2003 11:32:04 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW0DVLAW; Fri, 7 Feb 2003 11:32:04 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h17AW4H7007104; Fri, 7 Feb 2003 12:32:04 +0200 (EET) Message-ID: <3E438B22.EF551BAF@lmf.ericsson.se> Date: Fri, 07 Feb 2003 12:32:02 +0200 X-Sybari-Trust: 9ea5270d 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ssundaragopalan@hss.hns.com CC: Henning Schulzrinne , stoshniwal@hss.hns.com, mmusic References: <65256CC6.00364597.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Deleted Streams in Grouping Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, in the offer/answer model there is not such a thing as a "deleted" stream. You never delete m lines. You set the port number to zero, which is reffered to as "rejecting" a media stream. Therefore, if you have a session that lasts very long, and you have been adding and "rejecting" streams, your SDPs will carry a lot of garbage... ungly, but that's the way it is. Regards, Gonzalo ssundaragopalan@hss.hns.com wrote: > > Hi, > Suppose there exists a group which groups two media streams m1 and > m2. > If a stream gets deleted in the middle of the session(say m1), then do we > have to remove > the "Media Stream Identification tag"(mid) from the grouping??. The RFC > says we will > have to remove the mid's for rejected streams. There is no mention about > deleted streams. > > If we dont do this then there might be a problem when we try to add a new > stream(say m3). > > Assume that we have deleted m1 from the session and the *mid* is not > removed from > grouping. When we try to add a third stream m3 to the session, the slot of > the deleted stream > gets reused. Also the Media Stream Identification tag(mid) remains the same > . > This will cause this stream to be part of the grouping, which is not TRUE. > > Please clarify. > > Thanks and regds, > srikanth sundaragopalan > Hughes Software Systems. -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 7 08:09:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08997 for ; Fri, 7 Feb 2003 08:09:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17DGQ202056 for mmusic-archive@odin.ietf.org; Fri, 7 Feb 2003 08:16:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DGQp02053 for ; Fri, 7 Feb 2003 08:16:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08971 for ; Fri, 7 Feb 2003 08:08:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DGDp02021; Fri, 7 Feb 2003 08:16:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DFFp01994 for ; Fri, 7 Feb 2003 08:15:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08838; Fri, 7 Feb 2003 08:07:48 -0500 (EST) Message-Id: <200302071307.IAA08838@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Feb 2003 08:07:48 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-06.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for SDP and RTSP Author(s) : J. Arkko et al. Filename : draft-ietf-mmusic-kmgmt-ext-06.txt Pages : 12 Date : 2003-2-6 This document defines general extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, its use is meaningful only when it is completed by the key management protocol in use. General guidelines are also given on how the framework should be used together with SIP and RTSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-6152553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-6152553.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 7 10:44:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13817 for ; Fri, 7 Feb 2003 10:44:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17FpML11543 for mmusic-archive@odin.ietf.org; Fri, 7 Feb 2003 10:51:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FpMp11540 for ; Fri, 7 Feb 2003 10:51:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13808 for ; Fri, 7 Feb 2003 10:43:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17FpFp11525; Fri, 7 Feb 2003 10:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Fojp11503 for ; Fri, 7 Feb 2003 10:50:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13789 for ; Fri, 7 Feb 2003 10:43:14 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17FkqKV007562 for ; Fri, 7 Feb 2003 16:46:52 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWHD0K; Fri, 7 Feb 2003 16:46:52 +0100 Message-ID: <3E43D4EC.4090600@era.ericsson.se> Date: Fri, 07 Feb 2003 16:46:52 +0100 X-Sybari-Trust: 7a2cf5bf 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP transport header, port parameter changes Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, At the wednesdays telecon we discussed on how to update the transport header to support STUN and symmetric RTP for traversal of NATs. It was decided to allow the ports to be specified explicitly for RTP and RTCP. Therefore I have written up a proposal for new text for the transport header below: We where discussing making the port attributes totally flexible. However as I started looking at the section I discovered that port, client_port, server_port are RTP-specific. So my proposed changes does therefore only solves what is necessary for RTP. An alternative to this change would be to reclassify the port attributes to be general attributes and then they should have total flexibility. That would also require some text on how to related to the RTP media transport setup. I also included a client_ssrc parameter. This would be used for symmetric RTP to make the symmetric port opening more robust. I will try to write up a mail regarding using symmetric RTP for RTSP sessions. Please read and comment Magnus -------------------------------------------------------- changed parts of section 12.40 Transport header in relation to draft-ietf-mmusic-rfc2326bis-02.txt. RTP-specific: These parameters are only valid if the media transport protocol is RTP. The parameters containing port numbers are all subject to the following consideration: All port numbers where prior specified as a value or range, see "old-port-spec" in ABNF below. To support NAT traversal RTP has been updated to allow non-continuous port specif- ication not following the even/odd rule. As long as both the RTP and RTCP port is specified explicitly they are allow to take any valid port number. Therefore the RTP specific port parameters has been updated to support this. The updated format ("new-port-spec") SHOULD only be used when required to specify non-continuous port numbers. Before using the "new-port-spec" format the client MUST determine server support of the "play.basic" option tags. port: This parameter provides the RTP/RTCP port pair for a multi- cast session. This parameter SHOULD NOT use the "new-port- spec" format. It is should be specified as a range, e.g., port=3456-3457 client_port: This parameter provides the unicast RTP/RTCP port pair on the client where media data and control information is to be sent. It is specified either as a range, e.g., port=3456- 3457 or as two explicit numbers port=3457/4976 server_port: This parameter provides the unicast RTP/RTCP port pair on the server where media data and control information is to be sent. It is specified either as a range, e.g., port=3456- 3457 or as two explicit numbers port=3457/4976 ssrc: The ssrc parameter indicates the RTP SSRC [23] value that should be (request) or will be (response) used by the media server. This parameter is only valid for unicast transmission. It identifies the synchronization source to be associated with the media stream, and is expressed as an eight digit hexide- cimal value. In cases that a sender will use multiple SSRCs it SHOULD NOT use this parameter. client_ssrc: The client_ssrc parameter indicates the RTP SSRC [23] value that will be used by the client. This parameter is only valid for unicast transmission. It identifies the synchroniza- tion source to be associated with the media stream, and is expressed as an eight digit hexidecimal value. In cases that a client will use multiple SSRCs it SHOULD NOT use this parame- ter. Transport = "Transport" ":" 1#transport-spec transport-spec = transport-id *parameter transport-id = transport-protocol "/" profile ["/" lower-transport] ; no LWS is allowed inside transport-id transport-protocol = "RTP" / token profile = "AVP" / token lower-transport = "TCP" / "UDP" / token parameter = ";" ( "unicast" / "multicast" ) / ";" "source" "=" address / ";" "destination" [ "=" address ] / ";" "interleaved" "=" channel [ "-" channel ] / ";" "append" / ";" "ttl" "=" ttl / ";" "layers" "=" 1*DIGIT / ";" "port" "=" port-spec / ";" "client_port" "=" port-spec / ";" "server_port" "=" port-spec / ";" "ssrc" "=" ssrc / ";" "client_ssrc" "=" ssrc / ";" "mode" "=" mode-spec / ";" trn-parameter-extension port-spec = old-port-spec / new-port-spec old-port-spec = port [ "-" port ] new-port-spec = port "/" port ; RTP/RTCP port trn-parameter-extension = par-name "=" trn-par-value par-name = token trn-par-value = *unreserved ttl = 1*3(DIGIT) port = 1*5(DIGIT) ssrc = 8*8(HEX) channel = 1*3(DIGIT) address = host ;As defined in RFC 2732 [30] mode-spec = <"> 1#mode <"> / mode -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 7 11:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14937 for ; Fri, 7 Feb 2003 11:37:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17GiGB14770 for mmusic-archive@odin.ietf.org; Fri, 7 Feb 2003 11:44:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17GiFp14767 for ; Fri, 7 Feb 2003 11:44:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14900 for ; Fri, 7 Feb 2003 11:36:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17GiCp14759; Fri, 7 Feb 2003 11:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Ghlp14700 for ; Fri, 7 Feb 2003 11:43:47 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14882 for ; Fri, 7 Feb 2003 11:36:15 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18hBXc-0003he-00; Fri, 07 Feb 2003 08:39:52 -0800 Date: Fri, 7 Feb 2003 08:39:52 -0800 From: Tom Marshall To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP transport header, port parameter changes Message-ID: <20030207163952.GA14187@real.com> References: <3E43D4EC.4090600@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <3E43D4EC.4090600@era.ericsson.se> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > We where discussing making the port attributes totally flexible. However= =20 > as I started looking at the section I discovered that port, client_port,= =20 > server_port are RTP-specific. Yes, 2326 does say that client_port and server_port are for RTP. I would like to propose that the wording be changed, as client_port is not specific to RTP. The RealNetworks client and server have been using the client_port attribute with non-RTP transports since 2326 was written. --=20 I used to think I was a child; now I think I am an adult -- not because I no longer do childish things, but because those I call adults are no more mature than I am. --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Q+FYqznSmcYu2m8RAl//AJ4ves84fMTS6bnLLe25qZyJBfVOaQCfQMQG LVEBigChJ3gWwX7LTwQjyLU= =kf5Q -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 7 14:02:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18356 for ; Fri, 7 Feb 2003 14:02:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17J9LW23562 for mmusic-archive@odin.ietf.org; Fri, 7 Feb 2003 14:09:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17J9Lp23559 for ; Fri, 7 Feb 2003 14:09:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18344 for ; Fri, 7 Feb 2003 14:01:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17J9Fp23549; Fri, 7 Feb 2003 14:09:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17J8Vp23505 for ; Fri, 7 Feb 2003 14:08:31 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18296 for ; Fri, 7 Feb 2003 14:00:56 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h17J4ZB97421 for ; Fri, 7 Feb 2003 11:04:35 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 11:04:35 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A77D0@MISTY> From: Thomas Zeng To: "'mmusic@ietf.org'" Date: Fri, 7 Feb 2003 11:04:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Subject: [MMUSIC] Range Header In Play Responses Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi: During the Jan 22, 2003 RTSP telecon, we discussed Range header in PLAY reponses in the context of option tag play.basic. In current draft (draft-ietf-mmusic-rfc2326bis-02.txt), PLAY Range response is required for on demand media (see section 10.5). It was decided to make this an requirement for live streaming as well. Here is the proposed changes to section 10.5 and section 14 (examples) in draft-ietf-mmusic-rfc2326bis-02.txt. Each change is separated by "-----"'s, and instructions on how to make the changes are put in square brackets. Your comments are always welcome. Thanks thomas --------------------------------- [insert the following to Section 10.5, before the paragraph started with "For a on-demand stream, the server MUST reply with the actual range...] [new paragraph] Server MUST include a "Range" header in its Play response. When playing live media, the Play response MUST use one, and only one, of the two Range headers below: Range: now- - or - Range: 0- Here in live mode "now" happens to mean "0" in NPT time space for this session. ---------------------------------------------------------------------------- -------------------------------------- [change section 14.2, add the following right before the begining of actual RTSP DESCRIBE request] In this example we assume the length of the presentation is 600 seconds. [Also in section 14.2, Add a range header to PLAY response] Range: 0-600 ------------------------------------------------------- [change section 14.3, add the following right before the begining of actual RTSP DESCRIBE request] In this example we assume the length of the presentation is 600 seconds. [change the example RTSP conversation in section 14.3 to add the following "Range" header to PLAY reponse] Range: 0-600 ------------------------------ ------------------------------ [change section 14.4 Live Media example, add the following "Range" header to PLAY reponse] Range: now- ------------------------------ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Feb 9 17:48:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08424 for ; Sun, 9 Feb 2003 17:48:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h19Mv3526526 for mmusic-archive@odin.ietf.org; Sun, 9 Feb 2003 17:57:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h19Mv3p26523 for ; Sun, 9 Feb 2003 17:57:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08419 for ; Sun, 9 Feb 2003 17:48:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h19Muvp26513; Sun, 9 Feb 2003 17:56:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h19Mu1p26494 for ; Sun, 9 Feb 2003 17:56:01 -0500 Received: from purple.nge.isi.edu (dial161.east.isi.edu [65.114.169.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08395 for ; Sun, 9 Feb 2003 17:47:22 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h19MllY5003606; Sun, 9 Feb 2003 17:47:47 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200302092247.h19MllY5003606@purple.nge.isi.edu> To: Magnus Westerlund cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-00.txt In-Reply-To: Your message of "Tue, 04 Feb 2003 13:24:01 +0100." <3E3FB0E1.5060402@era.ericsson.se> Date: Sun, 09 Feb 2003 17:47:47 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, --> Magnus Westerlund writes: >In this revision of the Transport independent SDP bandwidth modifiers >the following changes has been performed: > >- Removed "avgprate" as it is not useful. >- Removed the RTCP rules present in the last proposal and replaced them > with simpler ones. If 5% RTCP bandwidht that shall be based on the local > transport dependent rate. >- Clarified the text. >- Brought the text up to ID-nits level, ready for publication. > >As I think this document is ready and address the comments that I have >received, I would like to ask for a WG last call on >draft-ietf-mmusic-sdp-bwparam-00.txt. Does the TIAS bandwidth include the RTP payload header and/or any RTP header extensions? What about profile specific additions, such as the SRTP trailer? As an editorial note, also, could you move the "Changes" section to be a final appendix, so that the RFC editor does not have to renumber the draft? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 03:40:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00366 for ; Mon, 10 Feb 2003 03:40:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A8mX332099 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 03:48:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8mXp32096 for ; Mon, 10 Feb 2003 03:48:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00350 for ; Mon, 10 Feb 2003 03:39:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8mLp32085; Mon, 10 Feb 2003 03:48:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8lJp32055 for ; Mon, 10 Feb 2003 03:47:19 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00330 for ; Mon, 10 Feb 2003 03:38:29 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1A8gAAv018789; Mon, 10 Feb 2003 09:42:10 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWQSN7; Mon, 10 Feb 2003 09:42:10 +0100 Message-ID: <3E4765E2.1090003@era.ericsson.se> Date: Mon, 10 Feb 2003 09:42:10 +0100 X-Sybari-Trust: 9e688f68 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP transport header, port parameter changes References: <20030207163952.GA14187@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom, I am willing to make the client_port parameters to general parameters. It will make their BNF slightly more complicated as they should allow for any number of ports, both as ranges and lists. This change will also require us to write some text on usage of RTP with general parameter. Best Regards Magnus Tom Marshall wrote: >>We where discussing making the port attributes totally flexible. >> >> >However > > >>as I started looking at the section I discovered that port, >> >> >client_port, > > >>server_port are RTP-specific. >> >> > >Yes, 2326 does say that client_port and server_port are for RTP. I >would >like to propose that the wording be changed, as client_port is not >specific >to RTP. The RealNetworks client and server have been using the >client_port >attribute with non-RTP transports since 2326 was written. > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 05:18:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03199 for ; Mon, 10 Feb 2003 05:18:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AAQL905009 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 05:26:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AAQLp05006 for ; Mon, 10 Feb 2003 05:26:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03184 for ; Mon, 10 Feb 2003 05:17:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AAQFp04996; Mon, 10 Feb 2003 05:26:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AAPdp04971 for ; Mon, 10 Feb 2003 05:25:39 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03176 for ; Mon, 10 Feb 2003 05:16:47 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1AAKSAv019606; Mon, 10 Feb 2003 11:20:28 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW01C5H7; Mon, 10 Feb 2003 11:20:28 +0100 Message-ID: <3E477CEC.60508@era.ericsson.se> Date: Mon, 10 Feb 2003 11:20:28 +0100 X-Sybari-Trust: da54f765 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] Range Header In Play Responses References: <72263E8E8622D611975C0002B32C19D84A77D0@MISTY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thomas, Some comments below. Thomas Zeng wrote: >Hi: > >During the Jan 22, 2003 RTSP telecon, we discussed Range header in PLAY >reponses in the context of option tag play.basic. >In current draft (draft-ietf-mmusic-rfc2326bis-02.txt), PLAY Range response >is required for on demand media (see section 10.5). >It was decided to make this an requirement for live streaming as well. > >Here is the proposed changes to section 10.5 and section 14 (examples) in >draft-ietf-mmusic-rfc2326bis-02.txt. Each change is separated by "-----"'s, >and instructions on how to make the changes are put in square brackets. > >Your comments are always welcome. > >Thanks >thomas > >--------------------------------- >[insert the following to Section 10.5, before the paragraph started with >"For a on-demand stream, the server MUST reply with the actual range...] > >[new paragraph] Server MUST include a "Range" header in its Play response. >When playing live media, the Play response MUST use one, and only one, of >the two >Range headers below: > >Range: now- > >- or - > >Range: 0- > >Here in live mode "now" happens to mean "0" in NPT time space for this >session. > > Actually I think at least one more range type attribute is allowed. That is the use of clock. It is perfectly all right for a client to ask a server to play a live session using the following range header: Range:clock=20030213T143205Z- Which means that the server should play out media starting at 13 Feb. 2003 at 14:32:05. If this stream is live stream the play out can't start before that time. There are also a requirement that range responses uses the same sort of units as in the request. Therefore also clock responses must be allowed. And for being future proof I think the above proposal in text needs to be reformulated so it will be possible to use those formats. Also what values should be given in SMTP request streams. --- My proposal for text would be: Server MUST include a "Range" header in any PLAY response. The response MUST use the same format as the request's range header contained. If no Range header was in the request, the NPT time format SHOULD be used unless the client showed support for other formats. For a session with live media streams the Range header MUST also be given, containing a valid time indication. It is RECOMMENDED that either "npt=now-" or a UTC clock time for the corresponding time is given, i.e. "clock=20030213T143205Z-". The UTC clock format SHOULD only be used if client has shown support for it. ------ End of proposal ------ The examples must all be updated when we have a stable specification. Especially the ones in chapter 14 are out of date. Best Regards Magnus >---------------------------------------------------------------------------- >-------------------------------------- >[change section 14.2, add the following right before the begining of actual >RTSP DESCRIBE request] > >In this example we assume the length of the presentation is 600 seconds. > >[Also in section 14.2, Add a range header to PLAY response] > >Range: 0-600 > > >------------------------------------------------------- >[change section 14.3, add the following right before the begining of actual >RTSP DESCRIBE request] > >In this example we assume the length of the presentation is 600 seconds. > >[change the example RTSP conversation in section 14.3 to add the following >"Range" header to PLAY reponse] > >Range: 0-600 > >------------------------------ > >------------------------------ >[change section 14.4 Live Media example, add the following "Range" header to >PLAY reponse] > >Range: now- > >------------------------------ > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 06:47:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05190 for ; Mon, 10 Feb 2003 06:47:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ABuFr09792 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 06:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABuEp09789 for ; Mon, 10 Feb 2003 06:56:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05176 for ; Mon, 10 Feb 2003 06:47:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABuAp09777; Mon, 10 Feb 2003 06:56:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABtWp09733 for ; Mon, 10 Feb 2003 06:55:32 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05124 for ; Mon, 10 Feb 2003 06:46:37 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ABoJAv015306; Mon, 10 Feb 2003 12:50:19 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWSGHA; Mon, 10 Feb 2003 12:50:18 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1ABoHmT001901; Mon, 10 Feb 2003 13:50:17 +0200 (EET) Message-ID: <3E4791F7.D9E73608@lmf.ericsson.se> Date: Mon, 10 Feb 2003 13:50:15 +0200 X-Sybari-Trust: 7f3fe825 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic CC: Jonathan Rosemberg Subject: [Fwd: [MMUSIC] I-D ACTION:draft-camarillo-mmusic-alt-00.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we have submitted the draft below. It defines a new "semantics" attribute for the SDP grouping framework. These semantics are intended to be useful for NAT traversal. There will be another draft that describes the NAT traversal problem and that references, among others, this draft. Regards, Gonzalo -------- Original Message -------- Subject: [MMUSIC] I-D ACTION:draft-camarillo-mmusic-alt-00.txt Date: Tue, 04 Feb 2003 06:44:47 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Alternative Semantics for the Session Description Protocol Grouping Framework Author(s) : G. Camarillo, J. Rosenberg Filename : draft-camarillo-mmusic-alt-00.txt Pages : 8 Date : 2003-2-3 This document defines the alternative (ALT) semantics for the SDP grouping framework. The ALT semantics allow offering alternative media configurations to establish a particular media stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-alt-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-mmusic-alt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-mmusic-alt-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-mmusic-alt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-mmusic-alt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 07:47:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07264 for ; Mon, 10 Feb 2003 07:47:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ACuIF13049 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 07:56:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACuHp13046 for ; Mon, 10 Feb 2003 07:56:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07241 for ; Mon, 10 Feb 2003 07:47:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACuBp13038; Mon, 10 Feb 2003 07:56:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACtKp12999 for ; Mon, 10 Feb 2003 07:55:20 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07211 for ; Mon, 10 Feb 2003 07:46:25 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ACo6Av004677 for ; Mon, 10 Feb 2003 13:50:06 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWSXF9; Mon, 10 Feb 2003 13:50:06 +0100 Message-ID: <3E479FFE.4030908@era.ericsson.se> Date: Mon, 10 Feb 2003 13:50:06 +0100 X-Sybari-Trust: d136df24 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP & NAT: Symmetric RTP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, During the last RTSP telecon we discussed symmetric RTP as a traversal mechanism for NATs, especially symmetric ones. Basic idea behind symmetric RTSP: A for each media stream the server ports are defined as both send and receive ports. The client sends RTP and RTCP on respective port. The server upon reception of the IP/UDP/RTP packet takes that packets sender port and address as clients ports. Thereby ignoring what has been said in the signaling. RTSP updates needed: Server support is needed and they must be able to indicate this. Therefore a client request symmetric RTP behavior through the use of a new transport header parameter. There are also need for a feature tag to be able to detect this feature prior to setup. Security risks: Hi-jacking of media streams. The basic problem is that any RTP/RTCP traffic arriving to the sender port prior to the clients message will result in redirection of the media stream to the sent packets address and port. This allows an attacker to spoof the sender IP/port number to that of a target of an Distributed DOS attack. This can basically be done without being on the path between client and server by simple guessing port numbers. Good Solution: Create a RTP payload format that carries session identifier and a sufficient large random tag that prevents guessing. However due to NATs and the setup this can never be ensured against attackers located on the path between client and server. Maybe adequate solution: Only allow RTP messages from same IP as control session arrives from. The SSRC must also be correct as signaled through an new client_SSRC parameter in Transport header. This would force an attacker to: 1) be behind the same NAT and receive the same IP from the NAT as the legitimate client. 2) Require the attacker to be able to read the RTSP control traffic. Guessing will be at one per 2^31 probability unless bad random values are used. The maybe adequate solution does have the restriction that a NAT must ensure to use the same IP address for both the RTSP control binding and the media flows bindings. Problems: The client does normally not send RTP traffic to server. May create problems with RTSP aware proxies. They should however be corrected to not interfere as this will also be a problem for RECORD streams. More important is that there is lack of mechanism to negotiate what RTP payloads that will be used in direction client->server. This will be a problem independent if we use a authentication payload or any other payload. To allow the adequate security to work we need at least a RTP header in the upstream traffic on the RTP channel carrying a SSRC. A default behavior of reusing a downstream RTP payload type with an empty payload could be used. The RTCP streams has no problems of this kind. Conclusion: Symmetric RTP can be used with a minimal change to allow servers to create bindings based on incoming RTP/RTCP packets. The stream will always be possible to hijack by a man in the middle on the path between server and client. basic security: Use SSRC as secret identifier of client. Gives 1/2^31 probability of guessing. Requires extra transport header parameter "client_ssrc". basic+ security: Requires media flow bindings IP address to have same address as RTSP connection. Both requires at least default rule on how to send RTP packets to server. best possible: Create special payload for identification and binding of symmetric RTP ports. Can use any size of random tag. Creates problem with what RTP payload type to use. Or could be sent on plain UDP. This presents my view on how symmetric RTP could be used with RTSP sessions. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 08:09:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07852 for ; Mon, 10 Feb 2003 08:09:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ADIH214386 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 08:18:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADIGp14383 for ; Mon, 10 Feb 2003 08:18:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07842 for ; Mon, 10 Feb 2003 08:09:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADI8p14375; Mon, 10 Feb 2003 08:18:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADH9p14338 for ; Mon, 10 Feb 2003 08:17:09 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07826 for ; Mon, 10 Feb 2003 08:08:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1ADBvYH021406; Mon, 10 Feb 2003 08:11:58 -0500 (EST) Message-ID: <3E47A519.4050908@dynamicsoft.com> Date: Mon, 10 Feb 2003 08:11:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: <3E479FFE.4030908@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that symmetric RTP is clearly the best solution for RTSP as it is used today. I do not believe that relying on source IP being the same between the RTSP and RTP sessions is a good idea. This won't work in enterprises which may be natting into a multiplicity of IP addresses. I would also strongly advise not to mandate that as the one and only one solution for nat traversal. A client should be allowed to do other things, and you want to leave the door open for better solutions down the road. As for the random identifiers, I will note that I recently proposed such a mechanism in support of connection oriented media. This draft also discusses the attack you are talking about: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt -Jonathan R. Magnus Westerlund wrote: > Hi, > > During the last RTSP telecon we discussed symmetric RTP as a traversal > mechanism for NATs, especially symmetric ones. > > Basic idea behind symmetric RTSP: A for each media stream the server > ports are defined as both send and receive ports. The client sends RTP > and RTCP on respective port. The server upon reception of the IP/UDP/RTP > packet takes that packets sender port and address as clients ports. > Thereby ignoring what has been said in the signaling. > > RTSP updates needed: Server support is needed and they must be able to > indicate this. Therefore a client request symmetric RTP behavior through > the use of a new transport header parameter. There are also need for a > feature tag to be able to detect this feature prior to setup. > > Security risks: Hi-jacking of media streams. The basic problem is that > any RTP/RTCP traffic arriving to the sender port prior to the clients > message will result in redirection of the media stream to the sent > packets address and port. This allows an attacker to spoof the sender > IP/port number to that of a target of an Distributed DOS attack. This > can basically be done without being on the path between client and > server by simple guessing port numbers. > > Good Solution: Create a RTP payload format that carries session > identifier and a sufficient large random tag that prevents guessing. > However due to NATs and the setup this can never be ensured against > attackers located on the path between client and server. > > Maybe adequate solution: Only allow RTP messages from same IP as control > session arrives from. The SSRC must also be correct as signaled through > an new client_SSRC parameter in Transport header. This would force an > attacker to: 1) be behind the same NAT and receive the same IP from the > NAT as the legitimate client. 2) Require the attacker to be able to read > the RTSP control traffic. Guessing will be at one per 2^31 probability > unless bad random values are used. > > The maybe adequate solution does have the restriction that a NAT must > ensure to use the same IP address for both the RTSP control binding and > the media flows bindings. > > Problems: The client does normally not send RTP traffic to server. May > create problems with RTSP aware proxies. They should however be > corrected to not interfere as this will also be a problem for RECORD > streams. More important is that there is lack of mechanism to negotiate > what RTP payloads that will be used in direction client->server. This > will be a problem independent if we use a authentication payload or any > other payload. To allow the adequate security to work we need at least a > RTP header in the upstream traffic on the RTP channel carrying a SSRC. A > default behavior of reusing a downstream RTP payload type with an empty > payload could be used. The RTCP streams has no problems of this kind. > > Conclusion: > Symmetric RTP can be used with a minimal change to allow servers to > create bindings based on incoming RTP/RTCP packets. The stream will > always be possible to hijack by a man in the middle on the path between > server and client. > > basic security: Use SSRC as secret identifier of client. Gives 1/2^31 > probability of guessing. Requires extra transport header parameter > "client_ssrc". > > basic+ security: Requires media flow bindings IP address to have same > address as RTSP connection. Both requires at least default rule on how > to send RTP packets to server. > > best possible: Create special payload for identification and binding of > symmetric RTP ports. Can use any size of random tag. Creates problem > with what RTP payload type to use. Or could be sent on plain UDP. > > This presents my view on how symmetric RTP could be used with RTSP > sessions. > > Best Regards > > Magnus Westerlund > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 08:14:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07975 for ; Mon, 10 Feb 2003 08:14:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ADNAY14559 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 08:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADNAp14556 for ; Mon, 10 Feb 2003 08:23:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07970 for ; Mon, 10 Feb 2003 08:14:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADN1p14546; Mon, 10 Feb 2003 08:23:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADM9p14520 for ; Mon, 10 Feb 2003 08:22:09 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07939 for ; Mon, 10 Feb 2003 08:13:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1ADGvYH021409; Mon, 10 Feb 2003 08:16:57 -0500 (EST) Message-ID: <3E47A644.6010800@dynamicsoft.com> Date: Mon, 10 Feb 2003 08:16:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP transport header, port parameter changes References: <3E43D4EC.4090600@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Can a separate IP address be specified for RTCP, as the port can? draft-ietf-mmusic-sdp4nat has this capability, and its needed for cases where the network is natting into more than one IP address. -Jonathan R. Magnus Westerlund wrote: > Hi, > > At the wednesdays telecon we discussed on how to update the transport > header to support STUN and symmetric RTP > for traversal of NATs. It was decided to allow the ports to be specified > explicitly for RTP and RTCP. Therefore I have written up a proposal for > new text for the transport header below: > > We where discussing making the port attributes totally flexible. However > as I started looking at the section I discovered that port, client_port, > server_port are RTP-specific. So my proposed changes does therefore only > solves what is necessary for RTP. An alternative to this change would be > to reclassify the port attributes to be general attributes and then they > should have total flexibility. That would also require some text on how > to related to the RTP media transport setup. > > I also included a client_ssrc parameter. This would be used for > symmetric RTP to make the symmetric port opening more robust. I will try > to write up a mail regarding using symmetric RTP for RTSP sessions. > > Please read and comment > > Magnus > > -------------------------------------------------------- > changed parts of section 12.40 Transport header in relation to > draft-ietf-mmusic-rfc2326bis-02.txt. > > RTP-specific: > > These parameters are only valid if the media transport protocol is > RTP. The parameters containing port numbers are all subject to the > following consideration: All port numbers where prior specified as > a value or range, see "old-port-spec" in ABNF below. To support NAT > traversal RTP has been updated to allow non-continuous port specif- > ication not following the even/odd rule. As long as both the RTP > and RTCP port is specified explicitly they are allow to take any > valid port number. Therefore the RTP specific port parameters has > been updated to support this. The updated format ("new-port-spec") > SHOULD only be used when required to specify non-continuous port > numbers. Before using the "new-port-spec" format the client MUST > determine server support of the "play.basic" option tags. > > port: This parameter provides the RTP/RTCP port pair for a multi- > cast session. This parameter SHOULD NOT use the "new-port- > spec" format. It is should be specified as a range, e.g., > port=3456-3457 > > client_port: This parameter provides the unicast RTP/RTCP port pair > on the client where media data and control information is to > be sent. It is specified either as a range, e.g., port=3456- > 3457 or as two explicit numbers port=3457/4976 > > server_port: This parameter provides the unicast RTP/RTCP port pair > on the server where media data and control information is to > be sent. It is specified either as a range, e.g., port=3456- > 3457 or as two explicit numbers port=3457/4976 > > ssrc: The ssrc parameter indicates the RTP SSRC [23] value that > should be (request) or will be (response) used by the media > server. This parameter is only valid for unicast transmission. > It identifies the synchronization source to be associated with > the media stream, and is expressed as an eight digit hexide- > cimal value. In cases that a sender will use multiple SSRCs it > SHOULD NOT use this parameter. > > client_ssrc: The client_ssrc parameter indicates the RTP SSRC [23] > value that will be used by the client. This parameter is only > valid for unicast transmission. It identifies the synchroniza- > tion source to be associated with the media stream, and is > expressed as an eight digit hexidecimal value. In cases that a > client will use multiple SSRCs it SHOULD NOT use this parame- > ter. > > > Transport = "Transport" ":" 1#transport-spec > transport-spec = transport-id *parameter > transport-id = transport-protocol "/" profile ["/" > lower-transport] > ; no LWS is allowed inside transport-id > transport-protocol = "RTP" / token > profile = "AVP" / token > lower-transport = "TCP" / "UDP" / token > parameter = ";" ( "unicast" / "multicast" ) > / ";" "source" "=" address > / ";" "destination" [ "=" address ] > / ";" "interleaved" "=" channel [ "-" channel ] > / ";" "append" > / ";" "ttl" "=" ttl > / ";" "layers" "=" 1*DIGIT > / ";" "port" "=" port-spec > / ";" "client_port" "=" port-spec > / ";" "server_port" "=" port-spec > / ";" "ssrc" "=" ssrc > / ";" "client_ssrc" "=" ssrc > / ";" "mode" "=" mode-spec > / ";" trn-parameter-extension > port-spec = old-port-spec / new-port-spec > old-port-spec = port [ "-" port ] > new-port-spec = port "/" port ; RTP/RTCP port > trn-parameter-extension = par-name "=" trn-par-value > par-name = token > trn-par-value = *unreserved > ttl = 1*3(DIGIT) > port = 1*5(DIGIT) > ssrc = 8*8(HEX) > channel = 1*3(DIGIT) > > address = host ;As defined in RFC 2732 [30] > mode-spec = <"> 1#mode <"> / mode > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 08:33:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08346 for ; Mon, 10 Feb 2003 08:33:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ADgAK15824 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 08:42:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADgAp15821 for ; Mon, 10 Feb 2003 08:42:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08338 for ; Mon, 10 Feb 2003 08:33:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADg5p15813; Mon, 10 Feb 2003 08:42:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ADfAp15786 for ; Mon, 10 Feb 2003 08:41:10 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08316 for ; Mon, 10 Feb 2003 08:32:14 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ADZtAv016851; Mon, 10 Feb 2003 14:35:55 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWTCX8; Mon, 10 Feb 2003 14:35:55 +0100 Message-ID: <3E47AABB.4090907@era.ericsson.se> Date: Mon, 10 Feb 2003 14:35:55 +0100 X-Sybari-Trust: 1c66f42b 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP transport header, port parameter changes References: <3E43D4EC.4090600@era.ericsson.se> <3E47A644.6010800@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, No, currently it is not possible to specify a separate IP address for the RTCP port in respect to the RTP port. I understand that this will create problems if a NAT would assign the RTP and RTCP udp flow mappings to different public addresses. Have you any knowledge how usual this behavior is for NATs? It is of course possible to solve, even rather easy at least for RTP. However the general case of specifying n address/port for server respective client would require some more work. To allow for this behavior in a general case would be best solved with totally new parameters. Best Regards Magnus Jonathan Rosenberg wrote: > Can a separate IP address be specified for RTCP, as the port can? > draft-ietf-mmusic-sdp4nat has this capability, and its needed for > cases where the network is natting into more than one IP address. > > -Jonathan R. > > Magnus Westerlund wrote: > >> Hi, >> >> At the wednesdays telecon we discussed on how to update the transport >> header to support STUN and symmetric RTP >> for traversal of NATs. It was decided to allow the ports to be >> specified explicitly for RTP and RTCP. Therefore I have written up a >> proposal for new text for the transport header below: >> >> We where discussing making the port attributes totally flexible. >> However as I started looking at the section I discovered that port, >> client_port, server_port are RTP-specific. So my proposed changes >> does therefore only solves what is necessary for RTP. An alternative >> to this change would be to reclassify the port attributes to be >> general attributes and then they should have total flexibility. That >> would also require some text on how to related to the RTP media >> transport setup. >> >> I also included a client_ssrc parameter. This would be used for >> symmetric RTP to make the symmetric port opening more robust. I will >> try to write up a mail regarding using symmetric RTP for RTSP sessions. >> >> Please read and comment >> >> Magnus >> >> -------------------------------------------------------- >> changed parts of section 12.40 Transport header in relation to >> draft-ietf-mmusic-rfc2326bis-02.txt. >> >> RTP-specific: >> >> These parameters are only valid if the media transport protocol is >> RTP. The parameters containing port numbers are all subject to the >> following consideration: All port numbers where prior specified as >> a value or range, see "old-port-spec" in ABNF below. To support NAT >> traversal RTP has been updated to allow non-continuous port specif- >> ication not following the even/odd rule. As long as both the RTP >> and RTCP port is specified explicitly they are allow to take any >> valid port number. Therefore the RTP specific port parameters has >> been updated to support this. The updated format ("new-port-spec") >> SHOULD only be used when required to specify non-continuous port >> numbers. Before using the "new-port-spec" format the client MUST >> determine server support of the "play.basic" option tags. >> >> port: This parameter provides the RTP/RTCP port pair for a multi- >> cast session. This parameter SHOULD NOT use the "new-port- >> spec" format. It is should be specified as a range, e.g., >> port=3456-3457 >> >> client_port: This parameter provides the unicast RTP/RTCP port pair >> on the client where media data and control information is to >> be sent. It is specified either as a range, e.g., port=3456- >> 3457 or as two explicit numbers port=3457/4976 >> >> server_port: This parameter provides the unicast RTP/RTCP port pair >> on the server where media data and control information is to >> be sent. It is specified either as a range, e.g., port=3456- >> 3457 or as two explicit numbers port=3457/4976 >> >> ssrc: The ssrc parameter indicates the RTP SSRC [23] value that >> should be (request) or will be (response) used by the media >> server. This parameter is only valid for unicast transmission. >> It identifies the synchronization source to be associated with >> the media stream, and is expressed as an eight digit hexide- >> cimal value. In cases that a sender will use multiple SSRCs it >> SHOULD NOT use this parameter. >> >> client_ssrc: The client_ssrc parameter indicates the RTP SSRC [23] >> value that will be used by the client. This parameter is only >> valid for unicast transmission. It identifies the synchroniza- >> tion source to be associated with the media stream, and is >> expressed as an eight digit hexidecimal value. In cases that a >> client will use multiple SSRCs it SHOULD NOT use this parame- >> ter. >> >> >> Transport = "Transport" ":" 1#transport-spec >> transport-spec = transport-id *parameter >> transport-id = transport-protocol "/" profile ["/" >> lower-transport] >> ; no LWS is allowed inside transport-id >> transport-protocol = "RTP" / token >> profile = "AVP" / token >> lower-transport = "TCP" / "UDP" / token >> parameter = ";" ( "unicast" / "multicast" ) >> / ";" "source" "=" address >> / ";" "destination" [ "=" address ] >> / ";" "interleaved" "=" channel [ "-" >> channel ] >> / ";" "append" >> / ";" "ttl" "=" ttl >> / ";" "layers" "=" 1*DIGIT >> / ";" "port" "=" port-spec >> / ";" "client_port" "=" port-spec >> / ";" "server_port" "=" port-spec >> / ";" "ssrc" "=" ssrc >> / ";" "client_ssrc" "=" ssrc >> / ";" "mode" "=" mode-spec >> / ";" trn-parameter-extension >> port-spec = old-port-spec / new-port-spec >> old-port-spec = port [ "-" port ] >> new-port-spec = port "/" port ; RTP/RTCP port >> trn-parameter-extension = par-name "=" trn-par-value >> par-name = token >> trn-par-value = *unreserved >> ttl = 1*3(DIGIT) >> port = 1*5(DIGIT) >> ssrc = 8*8(HEX) >> channel = 1*3(DIGIT) >> >> address = host ;As defined in RFC 2732 [30] >> mode-spec = <"> 1#mode <"> / mode >> >> > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 09:44:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10774 for ; Mon, 10 Feb 2003 09:44:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AErKE19767 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 09:53:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AErKp19764 for ; Mon, 10 Feb 2003 09:53:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10754 for ; Mon, 10 Feb 2003 09:44:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AErGp19716; Mon, 10 Feb 2003 09:53:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEpep19623 for ; Mon, 10 Feb 2003 09:51:40 -0500 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10682 for ; Mon, 10 Feb 2003 09:42:42 -0500 (EST) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.6/8.12.6) with ESMTP id h1AEkMdw004171; Mon, 10 Feb 2003 09:46:22 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200302101446.h1AEkMdw004171@purple.nge.isi.edu> To: mmusic@ietf.org cc: jo@tzi.uni-bremen.de Date: Mon, 10 Feb 2003 09:46:22 -0500 From: Colin Perkins Subject: [MMUSIC] Meeting in San Francisco Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The MMUSIC working group is scheduled for one slot at the 56th IETF meeting in San Francisco. On the tentative agenda, this is from 9:00 to 11:30am on Monday 17th March. This is subject to change - do not plan travel based on this date. Those wanting agenda time at the meeting should contact the working group chairs by 3rd March. Submitting a draft does not automatically provide agenda time. You are reminded that the cut-off date for -00 Internet Draft submissions is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior approval from the chairs, -00 submissions should have filenames with the format draft-yourname-mmusic-...-00.txt. Be advised that updates to -00 drafts received after 24th February will not be accepted. All other Internet-Draft submissions must be made by Monday, 3rd March at 9:00am EST. Drafts which are submitted late and do not make the cutoff date will not be discussed at the meeting. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 10:01:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11344 for ; Mon, 10 Feb 2003 10:01:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AFA8621159 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 10:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFA8p21156 for ; Mon, 10 Feb 2003 10:10:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11337 for ; Mon, 10 Feb 2003 10:01:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFA4p21139; Mon, 10 Feb 2003 10:10:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AF9Xp21107 for ; Mon, 10 Feb 2003 10:09:33 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11315 for ; Mon, 10 Feb 2003 10:00:36 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1AF4HKV001600; Mon, 10 Feb 2003 16:04:17 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5K4X9S; Mon, 10 Feb 2003 16:04:17 +0100 Message-ID: <3E47BF71.30001@era.ericsson.se> Date: Mon, 10 Feb 2003 16:04:17 +0100 X-Sybari-Trust: d8a3c5d0 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: <3E479FFE.4030908@era.ericsson.se> <3E47A519.4050908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, Comments: Jonathan Rosenberg wrote: > I agree that symmetric RTP is clearly the best solution for RTSP as it > is used today. I do not believe that relying on source IP being the > same between the RTSP and RTP sessions is a good idea. This won't > work in enterprises which may be natting into a multiplicity of IP > addresses. I agree that requiring IP address to be same may be to restrictive and create a lot of problems. I think that a sufficiently strong solution of identifying the end-point anyway is enough. > > I would also strongly advise not to mandate that as the one and only > one solution for nat traversal. A client should be allowed to do other > things, and you want to leave the door open for better solutions down > the road. We are not planning to require any one solution. It is planned to make a draft about RTSP and NAT traversal. This will document and write up rules how to use the different mechanism and what to consider. Also what to think when writing firewall ALGs will be documented. The solution that the draft currently will discuss is: 1. STUN 2. Symmetric NAT 3. TCP tunneling 4. ALG (not recommended) > > As for the random identifiers, I will note that I recently proposed > such a mechanism in support of connection oriented media. This draft > also discusses the attack you are talking about: > > http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt > I will further discuss this in a reply to David Yon's reply. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 10:40:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10776 for ; Mon, 10 Feb 2003 09:44:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AErKE19783 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 09:53:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AErKp19780 for ; Mon, 10 Feb 2003 09:53:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10752 for ; Mon, 10 Feb 2003 09:44:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AErFp19700; Mon, 10 Feb 2003 09:53:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEmfp19522 for ; Mon, 10 Feb 2003 09:48:41 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10565 for ; Mon, 10 Feb 2003 09:39:44 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h1AEfn017253; Mon, 10 Feb 2003 09:41:49 -0500 Message-Id: <5.1.1.6.0.20030210091935.00b2cc40@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 10 Feb 2003 09:43:20 -0500 To: Magnus Westerlund , IETF MMUSIC WG From: David Yon Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP In-Reply-To: <3E479FFE.4030908@era.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , As Jonathan points out in his reply, a similar attack is being discussed in the context of comedia/comedia-fix. The proposed solution in comedia-fix is to window the protocol by always starting the stream with a unique ID prior to sending packets using the protocol that has been signalled in the SDP. My discontent with this mechanism is well documented in that email thread. If there is to be some sort of session correlation embedded in the media, I would greatly prefer the approach you are suggesting. I.e., make the endpoint ID be something derived from the protocol proper, rather than inserting the ID out-of-band in relation to the signalled protocol. As evidenced by this RTSP discussion, this need exists outside the scope of connection-based media, so perhaps comedia isn't the place to document a generic media/session correlation mechanism. If one accepts the notion that connectionless media has this need for session correlation, then it becomes clear that the comedia-fix proposal is not equipped to address the problem in this larger scope. What immediately comes to my mind is how to window the protocol when the media is carried over unreliable transport (i.e., UDP). Since there is no guarantee of ordering or delivery, the sender cannot simply just send the first packet with the endpoint ID. The packet may never arrive at the receiver, or it may arrive after other media packets. So the receiver has no reliable way of parcelling out the endpoint ID from the in-band media, unless of course the endpoint ID is encoded within the framework of the media itself. This is sounding more and more to me like endpoint ID is a standalone topic. Perhaps a short I-D that documents the need and the SDP syntax, plus globbing together a few of the more obvious protocol extensions (i.e., the RTP suggestion discussed below). At 07:50 AM 2/10/2003, Magnus Westerlund wrote: >Security risks: Hi-jacking of media streams. The basic problem is that any >RTP/RTCP traffic arriving to the sender port prior to the clients message >will result in redirection of the media stream to the sent packets address >and port. This allows an attacker to spoof the sender IP/port number to >that of a target of an Distributed DOS attack. This can basically be done >without being on the path between client and server by simple guessing >port numbers. > >Good Solution: Create a RTP payload format that carries session identifier >and a sufficient large random tag that prevents guessing. However due to >NATs and the setup this can never be ensured against attackers located on >the path between client and server. > >Magnus Westerlund >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 10:49:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13139 for ; Mon, 10 Feb 2003 10:49:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AFwI423764 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 10:58:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFwIp23761 for ; Mon, 10 Feb 2003 10:58:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13108 for ; Mon, 10 Feb 2003 10:49:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFwCp23749; Mon, 10 Feb 2003 10:58:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFvlp23731 for ; Mon, 10 Feb 2003 10:57:47 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13007 for ; Mon, 10 Feb 2003 10:48:48 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1AFqTAv024889; Mon, 10 Feb 2003 16:52:29 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5KVDZ2; Mon, 10 Feb 2003 16:52:28 +0100 Message-ID: <3E47CABC.3080901@era.ericsson.se> Date: Mon, 10 Feb 2003 16:52:28 +0100 X-Sybari-Trust: 384fc4bf 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: <5.1.1.6.0.20030210091935.00b2cc40@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi David, For RTSP and RTP usage it seems possible to make the whole process work using the RTP SSRC. In RTP flows that is present in the RTP header making it simple to handle. For RTCP it becomes even more important that it can be sent in the context of RTCP. RTCP traffic will flow through out the whole session. Therefore a special demultiplexing between RTCP and binding messages will be difficult. Using SSRC requires a simple parameter addition to the transport header. The client simple tells the server what to use. However the big question is if a 32 bit SSRC value is unique enough to function well. A RTSP server at least has the advantage that it can use multiple sending ports. If a client SSRC proposal already is in use on some port this can simple be sent to a different sender port. Using other methods of transporting this ID on top of UDP or other transport protocols create problems. Defining a general format that is simple used creates multiplexing problems for all use cases. For RTP it could be possible to define both a RTP payload format and a RTCP packet type that can be sent containing a general type of ID. Best Regards Magnus David Yon wrote: > As Jonathan points out in his reply, a similar attack is being > discussed in the context of comedia/comedia-fix. The proposed > solution in comedia-fix is to window the protocol by always starting > the stream with a unique ID prior to sending packets using the > protocol that has been signalled in the SDP. My discontent with this > mechanism is well documented in that email thread. > > If there is to be some sort of session correlation embedded in the > media, I would greatly prefer the approach you are suggesting. I.e., > make the endpoint ID be something derived from the protocol proper, > rather than inserting the ID out-of-band in relation to the signalled > protocol. > > As evidenced by this RTSP discussion, this need exists outside the > scope of connection-based media, so perhaps comedia isn't the place to > document a generic media/session correlation mechanism. > > If one accepts the notion that connectionless media has this need for > session correlation, then it becomes clear that the comedia-fix > proposal is not equipped to address the problem in this larger scope. > What immediately comes to my mind is how to window the protocol when > the media is carried over unreliable transport (i.e., UDP). Since > there is no guarantee of ordering or delivery, the sender cannot > simply just send the first packet with the endpoint ID. The packet > may never arrive at the receiver, or it may arrive after other media > packets. So the receiver has no reliable way of parcelling out the > endpoint ID from the in-band media, unless of course the endpoint ID > is encoded within the framework of the media itself. > > This is sounding more and more to me like endpoint ID is a standalone > topic. Perhaps a short I-D that documents the need and the SDP > syntax, plus globbing together a few of the more obvious protocol > extensions (i.e., the RTP suggestion discussed below). > > At 07:50 AM 2/10/2003, Magnus Westerlund wrote: > >> Security risks: Hi-jacking of media streams. The basic problem is >> that any RTP/RTCP traffic arriving to the sender port prior to the >> clients message will result in redirection of the media stream to the >> sent packets address and port. This allows an attacker to spoof the >> sender IP/port number to that of a target of an Distributed DOS >> attack. This can basically be done without being on the path between >> client and server by simple guessing port numbers. >> >> Good Solution: Create a RTP payload format that carries session >> identifier and a sufficient large random tag that prevents guessing. >> However due to NATs and the setup this can never be ensured against >> attackers located on the path between client and server. >> >> Magnus Westerlund >> Multimedia Technologies, Ericsson Research ERA/TVA/A >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 11:17:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14085 for ; Mon, 10 Feb 2003 11:17:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AGQNO25482 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 11:26:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGQNp25479 for ; Mon, 10 Feb 2003 11:26:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14070 for ; Mon, 10 Feb 2003 11:17:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGQ8p25469; Mon, 10 Feb 2003 11:26:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGPRp25427 for ; Mon, 10 Feb 2003 11:25:27 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14050 for ; Mon, 10 Feb 2003 11:16:27 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id 595EDA3D02; Mon, 10 Feb 2003 17:20:07 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA27362; Mon, 10 Feb 2003 17:20:05 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA27109; Mon, 10 Feb 2003 17:20:01 +0100 (MET) Subject: Re: [MMUSIC] RTSP and NATs To: Magnus Westerlund , jdrosen@dynamicsoft.com Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 10 Feb 2003 17:13:39 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 10/02/2003 17:21:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Jonathan you wrote: >I agree that symmetric RTP is clearly the best solution for RTSP as it >is used today. I do not believe that relying on source IP being the same > between the RTSP and RTP sessions is a good idea. This won't work in >enterprises which may be natting into a multiplicity of IP addresses. YES! I fully agree, (see item 3 below) Magnus, (Sorry for the delay in responding to previous RTSP&NAT) Having a RTSP server and a STUN server co-located at the same port is no concern for us neither in terms of security nor in terms of implementation, or to be more specific it is largely worth the trouble ! i.e. the trade of is rather simple: either you do that or NATs will prevent you from using RTSP.... And yes, magnus, you are right, the first key issue is to inform the client about the ports the server will be listening for incomming STUN packets, which need to be the RTP and RTCP ports.... ******************************************* let me summarize the 4 open issues I see for RTSP/STUN/NAT: (1) server signals its RTP and RTCP ports: it can be done either: (a) in the SDP (since its per-media ?) as in draft-ietf-mmusic-sdp4nat-03.txt or (b) in the headers of the response to DESCRIBE or SETUP Note that if SETUP is used it is a failed-in-advance attempt ("hey, try again, because this wont work") causing 1 round trip, so I dont like this solution much, and also there are cases when you dont use DESCRIBE ... so I would prefer solution (a)SDP. 2) there is the possiblity that inside DESCRIBE and/or SETUP the client gives its IP address, then the server could compare this transported client IP with the apparent IP address of the client, Then the server could make a specific reply: -we would need to define a new status- for example: "463: See you from behind a NAT, use STUN on designated ports" But this solution would only be a safe-guard, I mean it is smart to assume that: "When the server indicates explicit RTP and RTCP ports, the client SHOULD send STUN queries toward the server at these port numbers and wait for STUN responses indicating the possible presence of NAT." so that if you prefer to wait for a possible 463... you loose... a round trip !-) too bad! 3) One key missing item (as noted by Jonathan) is also the capability at SETUP to indicate not only a specific port number but also a specific IP address since through some NATs RTP and RTCP packets will come out not only with an (apparently) random port number but also from a different apparent IP address ! So we _must_ add this capability....(but it is no big deal right?) 4) you also need to send packets periodically to keep the NAT mappings "open". But the issue here is simply to document that, right ? regards, Philippe Gentric Software Architect Philips MP4Net "philippe dot gentric at philips dot com" http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs Magnus Westerlund Classification: 05/02/2003 19:45 Hi Philippe, philippe.gentric@philips.com wrote: >Magnus, > >I strongly support the recommendation to not use ALGs, >therefore STUN should be used instead but then you wrote: > > > > To be able to use STUN to traverse symmetric NATs the STUN server > > needs to be co-located with the streaming server media distribution > > ports. As this will create implementations difficulties and possi- > > bly security problems this SHOULD NOT be done. > >I am surprised, I would have proposed _on the contrary_ a "SHOULD" here >(since traversing symetric NATs is a key feature) ! > > >also what do you mean by "implementation difficulties" ? (I really cannot see any ?) >and could you explicit what type of _additional_ security issues this would cause >(i.e. issues that are not inherent to running either a RTSP or a STUN server in the first place ?) > > The problem of running STUN for a symmetric NAT is that the STUN server must be located at the servers sending port. So using the same RTSP mechanism that are used for traversing a cone-nat the client would: 1. first contact a well known port with the server for each his media stream to get the mapping of the stream. The client can't use any other then the well known port because it doesn't know what port to send to. 2. In the SETUP ask the server to send from its STUN servers well known port. It also needs to receive RTCP on that port. 3. For keep alive on the RTP port the client needs to send periodically STUN messages to the STUN server. This is a mess for a implementor. It need to have a STUN server receiving the STUN messages while the RTP/RTCP stack should receive all other messages. Also all the clients need to reside on the same port number which creates a multiplexing nightmare. If you change the setup phase so that the streams are first SETUP to dummy ports then reconfigured with a later message, the STUN could be located at each media streams source address. However in this setup it is actually better to use symmetric RTP in all regards except perhaps hi-jacking of media streams. However with certain restrictions you can actually end up with at least the same level of security that RTSP provides today. How are you using STUN to traverse a symmetric NAT? Best Regards Magnus -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 12:19:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16433 for ; Mon, 10 Feb 2003 12:19:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AHRW729637 for mmusic-archive@odin.ietf.org; Mon, 10 Feb 2003 12:27:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHRWp29634 for ; Mon, 10 Feb 2003 12:27:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16408 for ; Mon, 10 Feb 2003 12:18:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHRQp29609; Mon, 10 Feb 2003 12:27:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHNJp29394 for ; Mon, 10 Feb 2003 12:23:19 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16213 for ; Mon, 10 Feb 2003 12:14:16 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h1AHGM023481; Mon, 10 Feb 2003 12:16:22 -0500 Message-Id: <5.1.1.6.0.20030210115651.00b2cc40@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 10 Feb 2003 12:15:17 -0500 To: Magnus Westerlund From: David Yon Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP Cc: IETF MMUSIC WG In-Reply-To: <3E47CABC.3080901@era.ericsson.se> References: <5.1.1.6.0.20030210091935.00b2cc40@mail.rfdsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Using SSRC was mentioned a long time ago, although at the time dismissed as too protocol-specific. But the context of the discussion has changed, and if that works then I have no problem with it in principle. That said, there was at least one other concern voiced about whether 32 bits is sufficient. It also begs the question of what format to use for an endpoint-ID, and whether this format is to be fixed or variable. One approach would be to make the endpoint-ID format specific on a per-protocol basis, with a limited number of choices (it seems like string and integer would cover most needs). I'm not sure I followed you exactly, but I read your first paragraph to mean that using a windowed protocol approach for endpoint ID is even more of a problem in the context of RTCP. Is that a fair interpretation? At 10:52 AM 2/10/2003, Magnus Westerlund wrote: >Hi David, > >For RTSP and RTP usage it seems possible to make the whole process work >using the RTP SSRC. In RTP flows that is present in the RTP header making >it simple to handle. For RTCP it becomes even more important that it can >be sent in the context of RTCP. RTCP traffic will flow through out the >whole session. Therefore a special demultiplexing between RTCP and binding >messages will be difficult. > >Using SSRC requires a simple parameter addition to the transport header. >The client simple tells the server what to use. However the big question >is if a 32 bit SSRC value is unique enough to function well. A RTSP server >at least has the advantage that it can use multiple sending ports. If a >client SSRC proposal already is in use on some port this can simple be >sent to a different sender port. > >Using other methods of transporting this ID on top of UDP or other >transport protocols create problems. Defining a general format that is >simple used creates multiplexing problems for all use cases. For RTP it >could be possible to define both a RTP payload format and a RTCP packet >type that can be sent containing a general type of ID. > >Best Regards > >Magnus > >David Yon wrote: > >>As Jonathan points out in his reply, a similar attack is being discussed >>in the context of comedia/comedia-fix. The proposed solution in >>comedia-fix is to window the protocol by always starting the stream with >>a unique ID prior to sending packets using the protocol that has been >>signalled in the SDP. My discontent with this mechanism is well >>documented in that email thread. >> >>If there is to be some sort of session correlation embedded in the media, >>I would greatly prefer the approach you are suggesting. I.e., make the >>endpoint ID be something derived from the protocol proper, rather than >>inserting the ID out-of-band in relation to the signalled protocol. >> >>As evidenced by this RTSP discussion, this need exists outside the scope >>of connection-based media, so perhaps comedia isn't the place to document >>a generic media/session correlation mechanism. >> >>If one accepts the notion that connectionless media has this need for >>session correlation, then it becomes clear that the comedia-fix proposal >>is not equipped to address the problem in this larger scope. >>What immediately comes to my mind is how to window the protocol when the >>media is carried over unreliable transport (i.e., UDP). Since there is >>no guarantee of ordering or delivery, the sender cannot simply just send >>the first packet with the endpoint ID. The packet may never arrive at >>the receiver, or it may arrive after other media packets. So the >>receiver has no reliable way of parcelling out the endpoint ID from the >>in-band media, unless of course the endpoint ID is encoded within the >>framework of the media itself. >> >>This is sounding more and more to me like endpoint ID is a standalone >>topic. Perhaps a short I-D that documents the need and the SDP syntax, >>plus globbing together a few of the more obvious protocol extensions >>(i.e., the RTP suggestion discussed below). >> >>At 07:50 AM 2/10/2003, Magnus Westerlund wrote: >> >>>Security risks: Hi-jacking of media streams. The basic problem is that >>>any RTP/RTCP traffic arriving to the sender port prior to the clients >>>message will result in redirection of the media stream to the sent >>>packets address and port. This allows an attacker to spoof the sender >>>IP/port number to that of a target of an Distributed DOS attack. This >>>can basically be done without being on the path between client and >>>server by simple guessing port numbers. >>> >>>Good Solution: Create a RTP payload format that carries session >>>identifier and a sufficient large random tag that prevents guessing. >>>However due to NATs and the setup this can never be ensured against >>>attackers located on the path between client and server. >>> >>>Magnus Westerlund >>>Multimedia Technologies, Ericsson Research ERA/TVA/A >>>---------------------------------------------------------------------- >>>Ericsson AB | Phone +46 8 4048287 >>>Torshamsgatan 23 | Fax +46 8 7575550 >>>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic > >-- > >Magnus Westerlund >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 10 23:54:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08593 for ; Mon, 10 Feb 2003 23:54:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B53em06839 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 00:03:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B53ep06836 for ; Tue, 11 Feb 2003 00:03:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08587 for ; Mon, 10 Feb 2003 23:54:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B53Xp06822; Tue, 11 Feb 2003 00:03:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B52Pp06784 for ; Tue, 11 Feb 2003 00:02:25 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08568 for ; Mon, 10 Feb 2003 23:53:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1B4usYH022313; Mon, 10 Feb 2003 23:56:55 -0500 (EST) Message-ID: <3E488292.9040201@dynamicsoft.com> Date: Mon, 10 Feb 2003 23:56:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: <3E479FFE.4030908@era.ericsson.se> <3E47A519.4050908@dynamicsoft.com> <3E47BF71.30001@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Magnus Westerlund wrote: > Hi Jonathan, > > Comments: > > Jonathan Rosenberg wrote: > >> I agree that symmetric RTP is clearly the best solution for RTSP as it >> is used today. I do not believe that relying on source IP being the >> same between the RTSP and RTP sessions is a good idea. This won't >> work in enterprises which may be natting into a multiplicity of IP >> addresses. > > > I agree that requiring IP address to be same may be to restrictive and > create a lot of problems. I think that a sufficiently strong solution of > identifying the end-point anyway is enough. I would like to see the ability to specify the client IP/port for rtp and rtcp so as to allow RTSP to work with stun, turn and other related protocols, even if there is a separate endpoint id mechanism. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 01:43:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11286 for ; Tue, 11 Feb 2003 01:43:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B6qIr12750 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 01:52:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6qIp12747 for ; Tue, 11 Feb 2003 01:52:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11267 for ; Tue, 11 Feb 2003 01:43:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6qCp12733; Tue, 11 Feb 2003 01:52:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6pbp12691 for ; Tue, 11 Feb 2003 01:51:37 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11256 for ; Tue, 11 Feb 2003 01:42:19 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18iUB6-0008LX-00; Mon, 10 Feb 2003 22:46:00 -0800 Date: Mon, 10 Feb 2003 22:46:00 -0800 From: Tom Marshall To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP Message-ID: <20030211064600.GA32008@real.com> References: <3E479FFE.4030908@era.ericsson.se> <3E47A519.4050908@dynamicsoft.com> <3E47BF71.30001@era.ericsson.se> <3E488292.9040201@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <3E488292.9040201@dynamicsoft.com> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2003 at 11:56:50PM -0500, Jonathan Rosenberg wrote: > inline. >=20 > Magnus Westerlund wrote: > >Hi Jonathan, > > > >Comments: > > > >Jonathan Rosenberg wrote: > > > >>I agree that symmetric RTP is clearly the best solution for RTSP as it= =20 > >>is used today. I do not believe that relying on source IP being the=20 > >>same between the RTSP and RTP sessions is a good idea. This won't=20 > >>work in enterprises which may be natting into a multiplicity of IP=20 > >>addresses. > > > > > >I agree that requiring IP address to be same may be to restrictive and= =20 > >create a lot of problems. I think that a sufficiently strong solution of= =20 > >identifying the end-point anyway is enough. >=20 > I would like to see the ability to specify the client IP/port for rtp=20 > and rtcp so as to allow RTSP to work with stun, turn and other related=20 > protocols, even if there is a separate endpoint id mechanism. It would seem to me that a new parameter is appropriate. client_port implies that only a port number is given. Perhaps something like this could serve as an endpoint specifier with addresses? "client_addr" "=3D" addr_list addr_list -> addr_list "/" addr || addr =20 addr -> ip4addr || ip6addr =20 ip4addr -> ip4host || ip4host ":" port =20 ip6addr -> ip6host || ip6host ":" port =20 ip4host -> hostname || ip4literal =20 ip6host -> hostname || ip6literal =20 port -> =20 hostname -> =20 ip4literal-> =20 ip6literal-> "[" "]" =20 =2E. and perhaps a note saying that client_addr is mutually exclusive with client_port, source, and destination parameters. Comments? --=20 Happiness isn't something you experience; it's something you remember. -- Oscar Levant --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+SJwoqznSmcYu2m8RArzJAKCO5iemDN4QOpODpF3VIwIwmZU8xwCdGSxW AqRpXkD32LzT/mINKOGNE5E= =vzrO -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 06:00:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27001 for ; Tue, 11 Feb 2003 06:00:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BB9aK05574 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 06:09:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BB9ap05571 for ; Tue, 11 Feb 2003 06:09:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26979 for ; Tue, 11 Feb 2003 06:00:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BB9Qp05561; Tue, 11 Feb 2003 06:09:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BB86p05500 for ; Tue, 11 Feb 2003 06:08:06 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26920 for ; Tue, 11 Feb 2003 05:58:43 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1BB2PAv010393 for ; Tue, 11 Feb 2003 12:02:25 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW01LPH7; Tue, 11 Feb 2003 12:02:25 +0100 Message-ID: <3E48D841.7010006@era.ericsson.se> Date: Tue, 11 Feb 2003 12:02:25 +0100 X-Sybari-Trust: 49629b27 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, Thanks for replying and giving your input. Comments inline. philippe.gentric@philips.com wrote: >Magnus, > >(Sorry for the delay in responding to previous RTSP&NAT) > > >Having a RTSP server and a STUN server co-located at the same port >is no concern for us neither in terms of security nor in terms of implementation, >or to be more specific it is largely worth the trouble ! >i.e. the trade of is rather simple: either you do that or >NATs will prevent you from using RTSP.... > > Yes, but co-locating STUN and RTP/RTCP sender ports does create demultiplexing problems. There is no real multiplexing point between these two protocols. Both will be run over IP/UDP. No indication in UDP points out if the UDP payload is a STUN message or a RTP/RTCP message. Matching based on message structure is not a sure thing. Therefore I would much rather use another approach. From this point of view symmetric RTP may be a much better solution from the multiplexing perspective. Of course this has the security problems. The advantage of symmetric RTP using SSRC as identifier is that is has no demultiplexing problem and at least gives basic security. For all others than the man in the middle guessing correctly a 32 bit number is rather hard. And the man in the middle is still impossible to protect against. >And yes, magnus, you are right, the first key issue is to inform the client about the ports >the server will be listening for incomming STUN packets, >which need to be the RTP and RTCP ports.... > >******************************************* > >let me summarize the 4 open issues I see for RTSP/STUN/NAT: > >(1) server signals its RTP and RTCP ports: > >it can be done either: >(a) in the SDP (since its per-media ?) as in draft-ietf-mmusic-sdp4nat-03.txt >or >(b) in the headers of the response to DESCRIBE or SETUP > >Note that if SETUP is used it is a failed-in-advance attempt >("hey, try again, because this wont work") causing 1 round trip, >so I dont like this solution much, and also there are cases when >you dont use DESCRIBE ... >so I would prefer solution (a)SDP. > One solution would be to use the well known port of STUN. That allows a client to first initiate a STUN request to the server. Upon detecting the clients public IP/port it sends a RTSP SETUP with this information and actually tells the server by using Server_port of the STUN port that it would the server to send media from these ports. This of course has the problem that the server will need to demultiplex all incoming RTP/RTCP traffic based on source IP/port to know which session it belongs to. Also any type of load balancing between ports will be impossible. To achieve load balancing between ports it will be a requirement to have signaling indicating which port the client shall connect the different flows to when doing STUN. It will still be required for the client to tell the server which port it must use. > > >2) there is the possiblity that inside DESCRIBE and/or SETUP the client >gives its IP address, then the server could compare this transported client IP >with the apparent IP address of the client, >Then the server could make a specific reply: >-we would need to define a new status- >for example: > > "463: See you from behind a NAT, use STUN on designated ports" > >But this solution would only be a safe-guard, >I mean it is smart to assume that: > >"When the server indicates explicit RTP and RTCP ports, >the client SHOULD send STUN queries toward the server >at these port numbers and wait for STUN responses >indicating the possible presence of NAT." > >so that if you prefer to wait for a possible 463... >you loose... a round trip !-) too bad! > > Might be a good addition. A question, are you assuming that any request containing destination IP that mismatch the source of the control flow will behind a NAT? This will then not work for non-transparent proxies. Actually I think we have a large problem in RTSP with proxies and where to send the media data. If a proxies is part of the TCP path to a server that connection will not have source IP equal to destination address of traffic. Then a server shall not send traffic to that source. > >3) One key missing item (as noted by Jonathan) >is also the capability at SETUP to indicate not only a specific >port number but also a specific IP address since through >some NATs RTP and RTCP packets will come out not only with >an (apparently) random port number but also >from a different apparent IP address ! > > I think a solution like what Tom has suggested will be required to fix this in a general way. However this solution has one very big problem with it. It opens up the DOS attack possibilities of RTSP. If your allowed to freely specify any IP/port this mechanism will be the certain choice of any DOS attacker. So we can't allow this to be used because this have worse security properties than symmetric RTP. So either we accept that NATs that gives out different IP address to the same client does not work or it will be required to create a security scheme that allows us to authorize the destination of the media traffic. >So we _must_ add this capability....(but it is no big deal right?) > > It is solveable but it will only work with servers that has been updated. But this is of course true with any server side changes. > >4) you also need to send packets periodically to keep >the NAT mappings "open". But the issue here is simply >to document that, right ? > > Yes, that is true independent which NAT traversal technique you use, STUN, or symmetric RTP. Some conclusions: Actually using STUN might not be possible at all from a security perspective if the TCP connection comes from a different IP addresses then the media streams. This will only work for single IP address NATs. Other solutions needs an authorization mechanism for the destination. Symmetric RTP seems to have better security despite all. Also it works for symmetric NATs without creating multiplexing problems, at least if we rely on RTP/RTCP's SSRC. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 06:06:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27128 for ; Tue, 11 Feb 2003 06:06:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BBF9f05747 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 06:15:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBF9p05744 for ; Tue, 11 Feb 2003 06:15:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27115 for ; Tue, 11 Feb 2003 06:05:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBF2p05736; Tue, 11 Feb 2003 06:15:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBEcp05716 for ; Tue, 11 Feb 2003 06:14:38 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27110 for ; Tue, 11 Feb 2003 06:05:15 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1BB8vKV000630; Tue, 11 Feb 2003 12:08:57 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MW5HVY; Tue, 11 Feb 2003 12:08:57 +0100 Message-ID: <3E48D9C9.6050003@era.ericsson.se> Date: Tue, 11 Feb 2003 12:08:57 +0100 X-Sybari-Trust: 0d83a884 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: <5.1.1.6.0.20030210091935.00b2cc40@mail.rfdsoftware.com> <5.1.1.6.0.20030210115651.00b2cc40@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi David, David Yon wrote: > Using SSRC was mentioned a long time ago, although at the time > dismissed as too protocol-specific. But the context of the discussion > has changed, and if that works then I have no problem with it in > principle. That said, there was at least one other concern voiced > about whether 32 bits is sufficient. It also begs the question of > what format to use for an endpoint-ID, and whether this format is to > be fixed or variable. One approach would be to make the endpoint-ID > format specific on a per-protocol basis, with a limited number of > choices (it seems like string and integer would cover most needs). My feeling is that 32 bits are enough for this. Because a brute force attack is not possible without the receiving end-point notice it. If good random numbers are used then it seem difficult enough to guess within a few message the correct one out of the 4.2 billion ones possible. > > I'm not sure I followed you exactly, but I read your first paragraph > to mean that using a windowed protocol approach for endpoint ID is > even more of a problem in the context of RTCP. Is that a fair > interpretation? Yes, the problem as I see it to safely demultiplex between ordinary traffic and the endpoint ID message. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 06:19:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27590 for ; Tue, 11 Feb 2003 06:19:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BBSDj06235 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 06:28:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBSDp06232 for ; Tue, 11 Feb 2003 06:28:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27585 for ; Tue, 11 Feb 2003 06:18:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBS4p06218; Tue, 11 Feb 2003 06:28:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBRJp06172 for ; Tue, 11 Feb 2003 06:27:19 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27544 for ; Tue, 11 Feb 2003 06:17:56 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1BBLcKV004172; Tue, 11 Feb 2003 12:21:38 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW01LVHC; Tue, 11 Feb 2003 12:21:38 +0100 Message-ID: <3E48DCC2.1010103@era.ericsson.se> Date: Tue, 11 Feb 2003 12:21:38 +0100 X-Sybari-Trust: 50aff029 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: <20030211064600.GA32008@real.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom, I think this is a good idea, however we will still have the DOS attack problems when specifying addresses other then the ones the RTSP connection uses. I don't have a good way of solving this. As you used a description format that is not the ABNF of RFC 2234 I converted it below. >It would seem to me that a new parameter is appropriate. client_port >implies that only a port number is given. Perhaps something like this >could >serve as an endpoint specifier with addresses? > > client_addr = "client_addr" "=" addr_list addr_list = addr *("/" addr) addr = ip4addr / ip6addr ip4addr = ip4host [":" port] ip6addr = ip6host [":" port] ip4host = hostname / ip4literal ip6host = hostname / ip6literal port = 1*DIGIT ip4literal = ip6literal = "[" "]" Some small detail questions: - Should the port range be limited to 16 bit values? - What are the rules when it would be optional to specify port numbers? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 11:19:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09878 for ; Tue, 11 Feb 2003 11:19:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BGSCd25621 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 11:28:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGSCp25618 for ; Tue, 11 Feb 2003 11:28:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09841 for ; Tue, 11 Feb 2003 11:18:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGS6p25599; Tue, 11 Feb 2003 11:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGQ9p25483 for ; Tue, 11 Feb 2003 11:26:09 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09782 for ; Tue, 11 Feb 2003 11:16:41 -0500 (EST) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1BGKMNh005850 for ; Tue, 11 Feb 2003 11:20:23 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAZ51613; Tue, 11 Feb 2003 11:25:26 -0500 (EST) Message-ID: <3E4922C5.1070407@cisco.com> Date: Tue, 11 Feb 2003 11:20:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: mmusic@ietf.org References: <200302041144.GAA17227@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: draft-camarillo-mmusic-alt-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo, I appreciate the value of this kind of mechanism. But I have a few questions about the details. My main concern is whether it is possible to be certain of ordering of media content as usage shifts from one alternative stream to another. There are several issues in this regard: - multiple streams may be established in parallel, but only one should be used. In some cases, e.g. UDP, the only way to attempt establishment is to send media over the stream. So by definition more than one is being used. And if this is done in parallel there is no way to know the order in which the media will arrive. - "During the session, a sender MAY choose to use any of the grouped m lines at a particular point in time to send data. This makes it possible to use the ALT semantics as a fail-over mechanism for ongoing sessions." This is described as being useful for failover, but not restricted to that. If a sender simply stops using one stream and begins using another, there is no guarantee of the order in which the resultant media will arrive at the recipient. This may again result in ambiguity about the order of media content. This gets worse if it is permissible to subsequently resume using a stream that had previously been used and then abandoned. As you bounce between streams it will rapidly become impossible to know the ordering of media content. I think there need to be more constraints over how an alternative is selected and how transitions between them are subsequently selected. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 11:48:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10992 for ; Tue, 11 Feb 2003 11:48:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BGvT227780 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 11:57:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGvTp27777 for ; Tue, 11 Feb 2003 11:57:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10980 for ; Tue, 11 Feb 2003 11:47:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGvBp27756; Tue, 11 Feb 2003 11:57:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGuip27726 for ; Tue, 11 Feb 2003 11:56:44 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10951 for ; Tue, 11 Feb 2003 11:47:14 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18idcV-0000Iw-00; Tue, 11 Feb 2003 08:50:55 -0800 Date: Tue, 11 Feb 2003 08:50:55 -0800 From: Tom Marshall To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP Message-ID: <20030211165055.GA1107@real.com> References: <20030211064600.GA32008@real.com> <3E48DCC2.1010103@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <3E48DCC2.1010103@era.ericsson.se> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 11, 2003 at 12:21:38PM +0100, Magnus Westerlund wrote: > Hi Tom, >=20 > I think this is a good idea, however we will still have the DOS attack=20 > problems when specifying addresses other then the ones the RTSP=20 > connection uses. I don't have a good way of solving this. Unfortunately, I don't either. Is it mandatory to solve it in the spec? It seems to me that the best solution is to have a challenge/response mechanism for each transport. But that is beyond the scope of RTSP. Perhaps it would be sufficient to say that the possibility for abuse exists and some form of cryptographically secure challenge/response mechanism should be used if the server allows sending to a different address than the client RTSP endpoint. The most troublesome scenario is a NAT that maps the RTSP and transport flows to different IP addresses. How common is this? > As you used a description format that is not the ABNF of RFC 2234 I=20 > converted it below. [...] Thank you. > Some small detail questions: > - Should the port range be limited to 16 bit values? For UDP with IPv4 and IPv6, yes. For others (non-UDP or IPv7+), who knows? > - What are the rules when it would be optional to specify port numbers? Perhaps a transport can have an implied or well-known port number, or a port number is not applicable to it, etc. --=20 A lot of people are afraid of heights. Not me. I'm afraid of widths. -- Steven Wright --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+SSnvqznSmcYu2m8RAnEUAJoDRz/VTVs0CWXpiI30/P2ii1rR1ACfdGj4 +bi0RgeJ7tlfMQaiDN0gVVc= =DmKk -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 11 14:41:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16569 for ; Tue, 11 Feb 2003 14:41:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BJoWP07144 for mmusic-archive@odin.ietf.org; Tue, 11 Feb 2003 14:50:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJoWp07141 for ; Tue, 11 Feb 2003 14:50:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16538 for ; Tue, 11 Feb 2003 14:40:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJoHp07114; Tue, 11 Feb 2003 14:50:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJnGp07057 for ; Tue, 11 Feb 2003 14:49:16 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16491 for ; Tue, 11 Feb 2003 14:39:41 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h1BJhPB94093 for ; Tue, 11 Feb 2003 11:43:25 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 11:43:25 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A77DB@MISTY> From: Thomas Zeng To: "'mmusic@ietf.org'" Date: Tue, 11 Feb 2003 11:43:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Subject: [MMUSIC] Minutes from Feb 5 RTSP telecon Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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 - 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? 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 mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 12 09:55:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05080 for ; Wed, 12 Feb 2003 09:55:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CF4dP21731 for mmusic-archive@odin.ietf.org; Wed, 12 Feb 2003 10:04:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CF4dp21728 for ; Wed, 12 Feb 2003 10:04:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05069 for ; Wed, 12 Feb 2003 09:54:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CF4Wp21719; Wed, 12 Feb 2003 10:04:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CF3Ip21669 for ; Wed, 12 Feb 2003 10:03:18 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05051 for ; Wed, 12 Feb 2003 09:53:21 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id BD8A0A5ADB; Wed, 12 Feb 2003 15:57:04 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA16620; Wed, 12 Feb 2003 15:57:03 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA01078; Wed, 12 Feb 2003 15:57:02 +0100 (MET) Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 12 Feb 2003 15:50:46 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 12/02/2003 15:58:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, I count 2 issues left : 1) STUN and RTP/RTCP co-located: I dont understand your concern here? the STUN draft says: "A STUN server can even be embedded within an end system." I assume it means exactly that, no? in practice it is easy for the server to discreminate between incomming STUN and incomming RTP or RTCP, since STUN and RTCP have completely different header structures; alos the STUN header contain a 128 bits nonce and the RTP/RTCP headers contain at least one 32 bits nonce .... So first the risk of collision is extremely small... secondly a good implementation will always include structural/coherence checks, right ? so what harm can it do that mis-formed RTCP packets would not cause in the first place anyway ? 2) Sending RTP at a different IP address than the RTSP client is un-secure. True. Unfortunately this is a property of RTSP today ;-) A) for NATs we simply want to extend it so that the RTP and RTCP can have both different IP addresses instead of "only" different port numbers > the additional danger is small compared to the benefit and: B) there is a need to fix that security hole _anyway_ One possible fix would be to define a RTCP extension whereby before sending RTP data the server sends a "confirmation request" with a Nonce and waits (with as short a time out as possible) for a RTCP "confirmation responce" containing the same nonce and originating from the correct target IP. defeating that is pretty difficult (afaik it requires a man in the middle in control of a router to trap the request and spoof the reply, with a guy in that position your concerns are probably elsewhere !-) regards, Philippe Gentric Software Architect Philips MP4Net "philippe dot gentric at philips dot com" http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 12 10:15:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05681 for ; Wed, 12 Feb 2003 10:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CFPM623281 for mmusic-archive@odin.ietf.org; Wed, 12 Feb 2003 10:25:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFPLp23278 for ; Wed, 12 Feb 2003 10:25:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05644 for ; Wed, 12 Feb 2003 10:15:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFP7p23269; Wed, 12 Feb 2003 10:25:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFOGp23233 for ; Wed, 12 Feb 2003 10:24:16 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05566 for ; Wed, 12 Feb 2003 10:14:20 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 10646A5599; Wed, 12 Feb 2003 16:18:02 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA00195; Wed, 12 Feb 2003 16:18:01 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA21879; Wed, 12 Feb 2003 16:18:00 +0100 (MET) Subject: Re: [MMUSIC] RTSP and NATs To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 12 Feb 2003 16:11:43 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 12/02/2003 16:19:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , magnus you wrote: >Also all the clients need to reside on the same port number > which creates a multiplexing nightmare. why? if the server _chooses_ its ports and puts them in the SDP ? (anyway demultiplexing using SSRC was already discussed: it is maybe not always a very good idea but it is doable...) regards, Philippe Gentric Software Architect Philips MP4Net "philippe dot gentric at philips dot com" http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 12 10:19:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05879 for ; Wed, 12 Feb 2003 10:19:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CFSb023555 for mmusic-archive@odin.ietf.org; Wed, 12 Feb 2003 10:28:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFSap23552 for ; Wed, 12 Feb 2003 10:28:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05823 for ; Wed, 12 Feb 2003 10:18:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFS2p23456; Wed, 12 Feb 2003 10:28:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFRGp23423 for ; Wed, 12 Feb 2003 10:27:16 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05742 for ; Wed, 12 Feb 2003 10:17:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CFL0KV027099; Wed, 12 Feb 2003 16:21:00 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 1XT3YQP4; Wed, 12 Feb 2003 16:20:59 +0100 Message-ID: <3E4A665B.3020209@era.ericsson.se> Date: Wed, 12 Feb 2003 16:20:59 +0100 X-Sybari-Trust: e2791046 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP & NAT: Symmetric RTP References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, Comments below: philippe.gentric@philips.com wrote: >Magnus, > >I count 2 issues left : > >1) STUN and RTP/RTCP co-located: > >I dont understand your concern here? > > >the STUN draft says: "A STUN server can even be embedded within an end system." >I assume it means exactly that, no? > > My concern is that it is not a clean, well engineered solution. However I can agree that it is possible to make it work. The second question is to Jonathan. >in practice it is easy for the server to discreminate between incomming STUN and incomming RTP or RTCP, >since STUN and RTCP have completely different header structures; >alos the STUN header contain a 128 bits nonce and the RTP/RTCP headers contain >at least one 32 bits nonce .... >So first the risk of collision is extremely small... >secondly a good implementation will always include structural/coherence checks, right ? > >so what harm can it do that mis-formed RTCP packets would not cause >in the first place anyway ? > I just took to heart the security consideration chapter of STUN that recommends that STUN server should avoid having other services that can open security holes. So its just a question that the server needs to be well built in regards to security and handling of bad messages. > > >2) Sending RTP at a different IP address than the RTSP client is un-secure. > >True. > >Unfortunately this is a property of RTSP today ;-) > Actually, if you look at RFC 2326 you can read the following in regards to destination parameter in the transport header: "To avoid becoming the unwitting perpetrator of a remote- controlled denial-of-service attack, a server SHOULD authenticate the client and SHOULD log such attempts before allowing the client to direct a media stream to an address not chosen by the server. This is particularly important if RTSP commands are issued via UDP, but implementations cannot rely on TCP as reliable means of client identification by itself. A server SHOULD not allow a client to direct media streams to an address that differs from the address commands are coming from." So if this should is followed, i.e. do not allow use of destination. Then RTSP is not that unsafe. > >A) for NATs we simply want to extend it so that the RTP and RTCP >can have both different IP addresses instead of "only" different port numbers > > >>the additional danger is small compared to the benefit >> This additional danger is way, way to big. You can't allow usage of client specified destination on any scale as it is such a potent DOS tool. a few messages can generate a multi Mbps attack on a target. So I don't see anyway of allowing such a security breach to be used. >> >> >and: > >B) there is a need to fix that security hole _anyway_ > > >One possible fix would be to define a RTCP extension whereby >before sending RTP data the server sends a "confirmation request" >with a Nonce and waits (with as short a time out as possible) >for a RTCP "confirmation responce" containing the same nonce and >originating from the correct target IP. > >defeating that is pretty difficult (afaik it requires a man in the middle >in control of a router to trap the request and spoof the reply, >with a guy in that position your concerns are probably elsewhere !-) > > I think we should look at ways to fix the whole. Because there are also other usage's then NAT traversal to such a mechanism. So from a security perspective I see the useful traversal methods are: - STUN for single IP NATs, preferable cone NATs. - Symmetric RTP for symmetric and multi-IP NATs. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 12 11:07:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07454 for ; Wed, 12 Feb 2003 11:07:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CGGn527118 for mmusic-archive@odin.ietf.org; Wed, 12 Feb 2003 11:16:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGGnp27115 for ; Wed, 12 Feb 2003 11:16:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07441 for ; Wed, 12 Feb 2003 11:06:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGGZp27104; Wed, 12 Feb 2003 11:16:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGEip27006 for ; Wed, 12 Feb 2003 11:14:44 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07409 for ; Wed, 12 Feb 2003 11:04:47 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1CG8TAv028216; Wed, 12 Feb 2003 17:08:29 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 1XT3Y9W2; Wed, 12 Feb 2003 17:08:29 +0100 Message-ID: <3E4A717D.6020603@era.ericsson.se> Date: Wed, 12 Feb 2003 17:08:29 +0100 X-Sybari-Trust: 6d075ab3 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, Comments inline. philippe.gentric@philips.com wrote: >magnus you wrote: > > > > >>Also all the clients need to reside on the same port number >>which creates a multiplexing nightmare. >> >> > >why? if the server _chooses_ its ports and puts them in the SDP ? > > Sorry, was not making clear that I assumed a known port which does not require signaling or spending extra RTTs. If you would send out the ports within the SDP then it gets simpler. However as discussed in another mail, co-locating is not a clean well engineered solution. > >(anyway demultiplexing using SSRC was already discussed: >it is maybe not always a very good idea but it is doable...) > > We have discussed for symmetric RTP to use SSRC as an random identifier ensuring that it not another user that tries to hijack the session. With symmetric RTP it is after all the server that gives the client what ports to connect to. That allow the server to place a single user on each port pair. This way we can avoid doing SSRC multiplexing of different RTP sessions. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 12 11:39:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08104 for ; Wed, 12 Feb 2003 11:39:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CGmUt04203 for mmusic-archive@odin.ietf.org; Wed, 12 Feb 2003 11:48:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGmUp04200 for ; Wed, 12 Feb 2003 11:48:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08097 for ; Wed, 12 Feb 2003 11:38:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGmQp04174; Wed, 12 Feb 2003 11:48:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGiPp03991 for ; Wed, 12 Feb 2003 11:44:25 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08017 for ; Wed, 12 Feb 2003 11:34:27 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl3.philips.com (Postfix) with ESMTP id E6C6C91EA3; Wed, 12 Feb 2003 17:29:29 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA00631; Wed, 12 Feb 2003 17:29:29 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA26560; Wed, 12 Feb 2003 17:29:28 +0100 (MET) Subject: Re: [MMUSIC] RTSP and NATs To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 12 Feb 2003 17:23:13 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 12/02/2003 17:30:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, symetric RTP and my other mail about "confirmation" are the same spirit then no? it is the principle that "the server sends only if it has received something", and the something must be a nonce to make hacking harder: and the SSRC can serve that purpose is that what you mean ? regards, Philippe Gentric Software Architect Philips MP4Net "philippe dot gentric at philips dot com" http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 12/02/2003 17:08 Hi Philippe, Comments inline. philippe.gentric@philips.com wrote: >magnus you wrote: > > > > >>Also all the clients need to reside on the same port number >>which creates a multiplexing nightmare. >> >> > >why? if the server _chooses_ its ports and puts them in the SDP ? > > Sorry, was not making clear that I assumed a known port which does not require signaling or spending extra RTTs. If you would send out the ports within the SDP then it gets simpler. However as discussed in another mail, co-locating is not a clean well engineered solution. > >(anyway demultiplexing using SSRC was already discussed: >it is maybe not always a very good idea but it is doable...) > > We have discussed for symmetric RTP to use SSRC as an random identifier ensuring that it not another user that tries to hijack the session. With symmetric RTP it is after all the server that gives the client what ports to connect to. That allow the server to place a single user on each port pair. This way we can avoid doing SSRC multiplexing of different RTP sessions. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 13 12:06:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18595 for ; Thu, 13 Feb 2003 12:06:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DHGYh03638 for mmusic-archive@odin.ietf.org; Thu, 13 Feb 2003 12:16:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DHGYp03635 for ; Thu, 13 Feb 2003 12:16:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18589 for ; Thu, 13 Feb 2003 12:06:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DHGSp03626; Thu, 13 Feb 2003 12:16:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DHFQp03586 for ; Thu, 13 Feb 2003 12:15:26 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18575 for ; Thu, 13 Feb 2003 12:04:58 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1DH8eAv024794; Thu, 13 Feb 2003 18:08:41 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 1X361613; Thu, 13 Feb 2003 18:08:40 +0100 Message-ID: <3E4BD118.7010404@era.ericsson.se> Date: Thu, 13 Feb 2003 18:08:40 +0100 X-Sybari-Trust: d9b5457b 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philippe, I get a bit confused by the below but I will try to answer stating my understanding of your questions. philippe.gentric@philips.com wrote: >Magnus, > >symetric RTP and my other mail about "confirmation" >are the same spirit then no? > >it is the principle that "the server sends only if it has received something", >and the something must be a nonce to make hacking harder: >and the SSRC can serve that purpose > > is that what you mean ? > > Symmetric RTP and security challenge for the UDP flows are two slightly different things. Symmetric RTP is based on that the client sends packet to the server that needs to have some protection against hijacking. That protection can be provided with SSRC of the client. This SSRC needs to be communicated between the client and server through other means (RTSP). This is not safe to a man in the middle attack. Security challenge is different in some ways. This is my understanding of how it could work. In this case the client asks the server to send media to any single IP/port number. Before sending a lot of traffic to these ports, the server needs to ensure that these ports are prepared to receive this traffic. To ensure this we make a security challenge either from server to client or the other way around. For STUN and "destination" usage the client initiates the challenge. In case of symmetric RTP the client could send a response without the challenge to id it clearly. The goal is to ensure that the client agrees to receive the traffic. By having the receiver sign the message going from client to server with keys that are transported through other ways we can ensure that no other than the intended receiver can verify that it agrees. This makes it possible to protect also against man in the middle attacks. It will of course requires secure RTSP signaling. The security challenge could as describe be taken into use also with symmetric RTP to identify that it is the correct receiver that sends these packets to use for binding. However this is still possible to attack and create an redirect by a man in the middle changing the packets source IP/port. By having a signed ACK we can at least ensure that the man in the middle can not do more than being a relay. Conclusion is that the security challenge initiated from server towards client can be made safe assuming this mechanism. However symmetric RTP can never be safe against man in the middle attacks. I hope that clarified the difference between the security challenge as a general mechanism and symmetric RTP as a special usage. Best Regards Magnus -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 14 07:51:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21174 for ; Fri, 14 Feb 2003 07:51:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ECtZB23961 for mmusic-archive@odin.ietf.org; Fri, 14 Feb 2003 07:55:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECtYp23958 for ; Fri, 14 Feb 2003 07:55:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21156 for ; Fri, 14 Feb 2003 07:51:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECtQp23950; Fri, 14 Feb 2003 07:55:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECsQp23921 for ; Fri, 14 Feb 2003 07:54:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21133 for ; Fri, 14 Feb 2003 07:50:16 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ECs0KV029669 for ; Fri, 14 Feb 2003 13:54:00 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 18KR51VQ; Fri, 14 Feb 2003 13:54:00 +0100 Message-ID: <3E4CE6E8.7060305@era.ericsson.se> Date: Fri, 14 Feb 2003 13:54:00 +0100 X-Sybari-Trust: 2f875a69 9ffcebbb a5ee123c 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP teleconference 19 february - Agenda Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here is the agenda for next weeks RTSP teleconference at wednesday the 19th of february at 18.00 CET. 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: * RTSP and NATs revisited: - 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. - Security problems. RTSP as Denial of Service tool. Hijacking and interception attacks. - Destination secure challenge mechanism? * Use of transport connection interleaved data http://rtsp.org/bug507408 http://rtsp.org/bug556589 http://rtsp.org/bug662436 http://rtsp.org/bug672160 * Unclarities when doing resetup http://rtsp.org/bug513737 * Conference header underspecified http://rtsp.org/bug539040 * "Clarify Range Where t0 <= t1" & "How to use Range when Scale is negative" http://rtsp.org/bug533691 http://rtsp.org/bug513880 Please be prepared if your participating. If your not a member of rtsp-logistics and would like to participate please send me a mail. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 14 08:26:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22160 for ; Fri, 14 Feb 2003 08:26:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EDUE526137 for mmusic-archive@odin.ietf.org; Fri, 14 Feb 2003 08:30:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EDUEp26134 for ; Fri, 14 Feb 2003 08:30:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22150 for ; Fri, 14 Feb 2003 08:26:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EDU8p26126; Fri, 14 Feb 2003 08:30:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EDTUp26092 for ; Fri, 14 Feb 2003 08:29:30 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22136 for ; Fri, 14 Feb 2003 08:25:20 -0500 (EST) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id h1EDSlZ22091; Fri, 14 Feb 2003 14:28:48 +0100 (MET) Message-ID: <3E4CEED9.9060506@tzi.uni-bremen.de> Date: Fri, 14 Feb 2003 14:27:53 +0100 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: yon.ietf@rfdsoftware.com, jdrosen@dynamicsoft.com CC: mmusic@ietf.org, csp@isi.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Proposed Resolution on comedia and comedia-fix Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Jonathan, We have reviewed the entire discussion again and have come to few concrete proposals how we would like to proceed on this issue. First of all, there is merit in the current comedia proposal to proceed (quickly), but there is also value in Jonathan's comments and observations. What we would like to do is: 1. Proceed using David's comedia-04 draft as a basis. 2. Remove the entire discussion of, and attributes for, source IP addresses. As there is no general way to determine when an IP addresss can be trusted, we believe its use is worthless, if not risky. 3. Include discussion of the security consideration Jonathan raised into the revision to comedia-04. 4. Include something like the eid: attribute as an optional indicator. We need to consider if a unique random indentifier is appropriate, or if an application specific identifier (e.g. RTP SSRC) might be better. 5. Do not follow the comedia-fix idea of sending the eid: as the first couple of bytes over any TCP connection. We believe this is going to cause problems with existing protocols and protocol implementations which do not natively send this information. Where necessary, for example when multiplexing several application layer connections into a single transport layer connection, the higher layer protocol must obviously already provide some framing structure. It is expected that such a structure can be used to tag the individual application layer connections and correlate them via the eid:. In such a case, or if the application layer protocol supports flow identifiers, this can also be used for single-hop TCP connections. If the transport protocol supports additional identifiers they might also be used. Obviously, this requires writing up further details. Specific use of, or formats for, the eid: per application layer protocol might need to be defined. It is hoped that this will solve the connection re-use issue for certain applications while allowing other applications to continue unmodified. 6. Port re-use on servers should preferably be dealt with on a per application basis. The eid: will be useful for this purpose if an application protocol supports referencing it in some fashion. There is no need to generally break backwards compatibility with arbitrary protocols. 7. The revised comedia document needs to specify that if eid: is included, it MUST be used by the application protocol. If the eid: is not present, then identifying incoming connections can only work on a receiver port basis (with all the negative implications identified by comedia-fix -- which should be included in a note). New application protocol to be used with comedia should incorporate the necessary behavior. Comments? Cheers, Colin and Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 14 09:47:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23746 for ; Fri, 14 Feb 2003 09:47:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EEolU31197 for mmusic-archive@odin.ietf.org; Fri, 14 Feb 2003 09:50:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EEolp31194 for ; Fri, 14 Feb 2003 09:50:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23740 for ; Fri, 14 Feb 2003 09:46:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EEoWp31184; Fri, 14 Feb 2003 09:50:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EEmjp31123 for ; Fri, 14 Feb 2003 09:48:45 -0500 Received: from www.frogsoup.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23708 for ; Fri, 14 Feb 2003 09:44:33 -0500 (EST) Received: from yon-lattitude.rfdsoftware.com (nh-londonderry2a-130.mrrmnh.adelphia.net [68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h1EEjj004918; Fri, 14 Feb 2003 09:45:45 -0500 Message-Id: <5.1.1.6.0.20030214094018.00b32758@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 14 Feb 2003 09:47:46 -0500 To: Joerg Ott , jdrosen@dynamicsoft.com From: David Yon Subject: Re: [MMUSIC] Proposed Resolution on comedia and comedia-fix Cc: mmusic@ietf.org, csp@isi.edu In-Reply-To: <3E4CEED9.9060506@tzi.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , I disagree with #2, but so be it. At this rate, all future IETF protocols are going to have use divining rods to determine where to send packets, since IP addresses are being banned because of NATs (insert half-smiley). I agree with your proposal for eid:, but per the recent RTSP discussion I propose that eid be made its own draft, as it is arguably not intrinsic to connection-oriented media and therefore does not belong in comedia. I have no problem with comedia referencing an externally-documented eid mechanism and applying the appropriate MUSTs listed below. At 08:27 AM 2/14/2003, Joerg Ott wrote: >David, Jonathan, > >We have reviewed the entire discussion again and have come to few concrete >proposals how we would like to proceed on this issue. First of all, there >is merit in the current comedia proposal to proceed (quickly), but there is >also value in Jonathan's comments and observations. > >What we would like to do is: > >1. Proceed using David's comedia-04 draft as a basis. > >2. Remove the entire discussion of, and attributes for, source IP > addresses. As there is no general way to determine when an IP > addresss can be trusted, we believe its use is worthless, if not > risky. > >3. Include discussion of the security consideration Jonathan raised > into the revision to comedia-04. > >4. Include something like the eid: attribute as an optional indicator. > We need to consider if a unique random indentifier is appropriate, or > if an application specific identifier (e.g. RTP SSRC) might be better. > >5. Do not follow the comedia-fix idea of sending the eid: as the > first couple of bytes over any TCP connection. We believe this > is going to cause problems with existing protocols and protocol > implementations which do not natively send this information. > > Where necessary, for example when multiplexing several application > layer connections into a single transport layer connection, the higher > layer protocol must obviously already provide some framing structure. > It is expected that such a structure can be used to tag the individual > application layer connections and correlate them via the eid:. In such > a case, or if the application layer protocol supports flow identifiers, > this can also be used for single-hop TCP connections. If the transport > protocol supports additional identifiers they might also be used. > > Obviously, this requires writing up further details. Specific use of, > or formats for, the eid: per application layer protocol might need to > be defined. > > It is hoped that this will solve the connection re-use issue for > certain applications while allowing other applications to continue > unmodified. > >6. Port re-use on servers should preferably be dealt with on a per > application basis. The eid: will be useful for this purpose if > an application protocol supports referencing it in some fashion. > There is no need to generally break backwards compatibility with > arbitrary protocols. > >7. The revised comedia document needs to specify that if eid: is included, > it MUST be used by the application protocol. If the eid: is not > present, then identifying incoming connections can only work on a > receiver port basis (with all the negative implications identified by > comedia-fix -- which should be included in a note). New application > protocol to be used with comedia should incorporate the necessary > behavior. > >Comments? > >Cheers, >Colin and Joerg > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 14 10:07:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24261 for ; Fri, 14 Feb 2003 10:07:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EFBHO32672 for mmusic-archive@odin.ietf.org; Fri, 14 Feb 2003 10:11:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EFBHp32669 for ; Fri, 14 Feb 2003 10:11:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24256 for ; Fri, 14 Feb 2003 10:07:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EFB9p32641; Fri, 14 Feb 2003 10:11:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EFA1p32588 for ; Fri, 14 Feb 2003 10:10:01 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24216 for ; Fri, 14 Feb 2003 10:05:49 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id 5EB009C06B; Fri, 14 Feb 2003 15:54:27 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA02187; Fri, 14 Feb 2003 15:54:26 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA13301; Fri, 14 Feb 2003 15:54:24 +0100 (MET) Subject: Re: [MMUSIC] RTSP and NATs To: Magnus Westerlund Cc: IETF MMUSIC WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 14 Feb 2003 15:48:06 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 14/02/2003 15:55:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus you write: >By having the receiver sign the message going from client >to server with keys that are transported through other ways we can >ensure that no other than the intended receiver can verify that it >agrees. This makes it possible to protect also against man in the middle >attacks. It will of course requires secure RTSP signaling. I dont see how a "secure RTSP session" solves the case I was thinking about is: your server thinks that the client is behind a NAT, because the IP addresses for RTSP and RTP are different, but in fact that client is a Bad Guy who wants to induce your server to flood someone else. if Mr Bad Guy is also a man-in-the-middle you are in real trouble because: 1) your attacker is initiating that RTSP session so A) your server cannot trust "a different IP address" indicated in that session, even if the session is TLS-ized ! B) you cannot use that session to convey crypto stuff for a separate UDP challenge either because: 2) this guys is also a man-in-the-middle who can trap/spoof UDP traffic i.e. a challenge/response at that "different IP address". I dont know how to solve that one (help security experts?) regards, Philippe Gentric Software Architect Philips MP4Net "philippe dot gentric at philips dot com" http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 14 11:12:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25841 for ; Fri, 14 Feb 2003 11:12:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EGFNZ04205 for mmusic-archive@odin.ietf.org; Fri, 14 Feb 2003 11:15:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EGFNp04202 for ; Fri, 14 Feb 2003 11:15:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25804 for ; Fri, 14 Feb 2003 11:11:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EGFHp04194; Fri, 14 Feb 2003 11:15:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EGCap04116 for ; Fri, 14 Feb 2003 11:12:36 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25749 for ; Fri, 14 Feb 2003 11:08:21 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1EGC6Av026796; Fri, 14 Feb 2003 17:12:06 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 18WY13P6; Fri, 14 Feb 2003 17:12:06 +0100 Message-ID: <3E4D1556.2080400@era.ericsson.se> Date: Fri, 14 Feb 2003 17:12:06 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP and NATs References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Philippe, The attack you describe is possible unless we have a way of positively identify a entity from two ways. First we must be able to establish the identity of the host that are located at the given media destination IP address/port. Secondly that host must be able to prove that it is that entity. In slightly more detail: When a client asks the server to send media to a given destination, the server must be able to get an global unique identifier of the destination from a trusted party. Then the server uses this global identifier in the security challenge to the destination. The destination answers the challenge and proves that it is really the given entity. The first step of getting a global host entity based on IP will never work with an NATed address. It seem to be possible to make it work when you use an public IP address. In basic any NAT traversal mechanism will allow for an attack by a man in the middle, see: http://www.ietf.org/internet-drafts/draft-dupont-transient-pseudonat-01.txt In fact today's RTSP is definitely not safe against man in the middle attacks. The man in the middle must only be able to receive the servers response to SETUP request to get the session ID: Then it can control the server from any place by simply spoof the sender address to that of the target. If you use TCP the attacker must be able to receive the TCP flows response. That it is all it takes to use RTSP as a DOS tool. Best Regards Magnus Westerlund philippe.gentric@philips.com wrote: >Magnus you write: > > > >>By having the receiver sign the message going from client >>to server with keys that are transported through other ways we can >>ensure that no other than the intended receiver can verify that it >>agrees. This makes it possible to protect also against man in the middle >>attacks. It will of course requires secure RTSP signaling. >> >> > >I dont see how a "secure RTSP session" solves the case I was thinking about is: > >your server thinks that the client is behind a NAT, >because the IP addresses for RTSP and RTP are different, >but in fact that client is a Bad Guy who wants to induce >your server to flood someone else. > >if Mr Bad Guy is also a man-in-the-middle you are in real trouble because: > >1) your attacker is initiating that RTSP session so > >A) your server cannot trust "a different IP address" indicated in that session, even if the session is TLS-ized ! > >B) you cannot use that session to convey crypto stuff for a separate UDP challenge either because: > >2) this guys is also a man-in-the-middle who can trap/spoof UDP traffic >i.e. a challenge/response at that "different IP address". > >I dont know how to solve that one (help security experts?) > >regards, > >Philippe Gentric >Software Architect >Philips MP4Net >"philippe dot gentric at philips dot com" >http://www.platform4.philips.com > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Feb 16 23:23:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04336 for ; Sun, 16 Feb 2003 23:23:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H4S1k16961 for mmusic-archive@odin.ietf.org; Sun, 16 Feb 2003 23:28:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4S1p16958 for ; Sun, 16 Feb 2003 23:28:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04331 for ; Sun, 16 Feb 2003 23:22:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4Rpp16948; Sun, 16 Feb 2003 23:27:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H4QCp16910 for ; Sun, 16 Feb 2003 23:26:12 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04309 for ; Sun, 16 Feb 2003 23:20:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1H4OZYH026477; Sun, 16 Feb 2003 23:24:35 -0500 (EST) Message-ID: <3E5063FF.8000609@dynamicsoft.com> Date: Sun, 16 Feb 2003 23:24:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yon CC: Joerg Ott , mmusic@ietf.org, csp@isi.edu Subject: Re: [MMUSIC] Proposed Resolution on comedia and comedia-fix References: <5.1.1.6.0.20030214094018.00b32758@mail.rfdsoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with the proposal. Some followup on eid below. David Yon wrote: > I disagree with #2, but so be it. At this rate, all future IETF > protocols are going to have use divining rods to determine where to send > packets, since IP addresses are being banned because of NATs (insert > half-smiley). Just source addresses. > > I agree with your proposal for eid:, but per the recent RTSP discussion > I propose that eid be made its own draft, as it is arguably not > intrinsic to connection-oriented media and therefore does not belong in > comedia. I have no problem with comedia referencing an > externally-documented eid mechanism and applying the appropriate MUSTs > listed below. At this point, I would actually agree with David here. If the way that eid is done is application specific anyway (I concede that sending it as the first bytes is not optimal and is better done application specific), then its encoding in SDP may as well be application specific too. The use of a separate draft would be primarily to outline the concept, I suppose. However, I don't see a need for comedia to have a dependency on it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 17 05:28:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19209 for ; Mon, 17 Feb 2003 05:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HAXgm15771 for mmusic-archive@odin.ietf.org; Mon, 17 Feb 2003 05:33:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HAXgp15766 for ; Mon, 17 Feb 2003 05:33:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19200 for ; Mon, 17 Feb 2003 05:28:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HAXWp15756; Mon, 17 Feb 2003 05:33:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HAUJp15623 for ; Mon, 17 Feb 2003 05:30:19 -0500 Received: from ns.live.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19171 for ; Mon, 17 Feb 2003 05:24:45 -0500 (EST) Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.6/8.12.5) with ESMTP id h1HASWQB067542 for ; Mon, 17 Feb 2003 02:28:32 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.6/8.12.3/Submit) id h1HASW9F067541; Mon, 17 Feb 2003 02:28:32 -0800 (PST) Message-Id: <4.3.1.1.20030217022718.00b32c50@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 17 Feb 2003 02:28:26 -0800 To: mmusic@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Updated "SDP source filter" Internet draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , FYI, I have submitted an updated version of the "SDP source filter" Internet draft. Until it appears on the IETF web site, you an get a copy at The major change in this version is that (as a result of feedback from Magnus Westerlund), there is now just one attribute defined: "a=source-filter:", rather than two: "a=incl:" and "a=excl:". I.e., the syntax is now: a=source-filter: where is either "incl" or "excl". Also, I've removed the "Multiple Source and Destination Example", because it was inconsistent with the rest of the spec. Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 18 05:31:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24392 for ; Tue, 18 Feb 2003 05:31:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IAals15556 for mmusic-archive@odin.ietf.org; Tue, 18 Feb 2003 05:36:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IAalp15553 for ; Tue, 18 Feb 2003 05:36:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24367 for ; Tue, 18 Feb 2003 05:30:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IAafp15545; Tue, 18 Feb 2003 05:36:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IAWVp15366 for ; Tue, 18 Feb 2003 05:32:31 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24222; Tue, 18 Feb 2003 05:26:28 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA29243; Tue, 18 Feb 2003 11:30:08 +0100 (MET) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA02817; Tue, 18 Feb 2003 11:30:08 +0100 (MET) Received: by MCHH248E with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Feb 2003 11:29:17 +0100 Message-ID: From: Kreuter Ruediger To: "'avt@ietf.org'" , "'mmusic@ietf.org'" , "'pwe3@ietf.org'" Cc: "'kschong@att.com'" , "'taylor@nortelnetworks.com'" Date: Tue, 18 Feb 2003 11:29:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] updated "Clearmode" (64kbit/s unrestricted) Internet-draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , FYI, I have submitted an update of the CLEARMODE Internet draft. You find it at http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clearmode-01.txt The major update, due to comments according the support of Nx64kbit/s and similar standardization activities in ITU's SG 11, is the introduction of Nx64kbit/s support. Two remarks to this issue: 1) 1x64kbit/s is used in current VoIP products and supported by most DSP Providers. Therefore I would like to keep Nx64kbit/s with N>1 as an option. 2) We currently do not have a VoIP product supporting Nx64kbit/s, therefore I introduced this merely as a discussion input. So if anybody has a working Nx64kbit/s solution I would like to get some comments on the packatization method in that case. If nobody has a solution I will delete this feature from the next version of this draft. Besides, the first draft initiated a controverse discussion, if this should be "audio/CLEARMODE" or e.g. "application/CLEARMODE". IMHO none of the existing IANA content types really fits for CLEARMODE. Since 1x64kbit/s is also used for 7kHz voice (despite G.722) I kept "audio" in this draft. Regards Ruediger _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 18 18:23:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11307 for ; Tue, 18 Feb 2003 18:23:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1INTf703056 for mmusic-archive@odin.ietf.org; Tue, 18 Feb 2003 18:29:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INTfp03053 for ; Tue, 18 Feb 2003 18:29:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11286 for ; Tue, 18 Feb 2003 18:23:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INTVp03042; Tue, 18 Feb 2003 18:29:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INSKp02993 for ; Tue, 18 Feb 2003 18:28:20 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11250; Tue, 18 Feb 2003 18:22:01 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1INO2JX008621; Tue, 18 Feb 2003 18:24:02 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Feb 2003 17:25:48 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3C80833@dyn-tx-exch-001.dynamicsoft.com> From: Kelvin Porter To: mmusic@ietf.org, "'sip@ietf.org'" Date: Tue, 18 Feb 2003 17:25:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] Java SDP API - JSR 141: Public Review 2 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, There is a new version of the Java SDP API available for review. Thank you for your consideration. Regards, Kelvin R. Porter -----Original Message----- From: Harold Ogle [mailto:harold.ogle@SUN.COM] Sent: Thursday, February 13, 2003 12:35 PM To: JCP-INTEREST@JAVA.SUN.COM Subject: JSR 141: Public Review 2 The Expert Group for JSR-000141 SDP API has released a second public review draft, which is now available from http://jcp.org/aboutJava/communityprocess/review/jsr141/index2.html This public review closes on 15 March 2003. =========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff JCP-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help". _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 19 10:09:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27418 for ; Wed, 19 Feb 2003 10:09:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFFdg17841 for mmusic-archive@odin.ietf.org; Wed, 19 Feb 2003 10:15:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFFdp17838 for ; Wed, 19 Feb 2003 10:15:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27387 for ; Wed, 19 Feb 2003 10:09:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFFSp17825; Wed, 19 Feb 2003 10:15:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFCap17679 for ; Wed, 19 Feb 2003 10:12:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27273; Wed, 19 Feb 2003 10:05:57 -0500 (EST) Message-Id: <200302191505.KAA27273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Feb 2003 10:05:57 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-srcfilter-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol (SDP) Source Filters Author(s) : B. Quinn, R. Finlayson Filename : draft-ietf-mmusic-sdp-srcfilter-03.txt Pages : 10 Date : 2003-2-18 This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination 'connection' addresses. It defines the syntax and semantics for an SDP 'source-filter' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. Receiver applications are expected use the SDP source-filter information to identify traffic from legitimate senders and discard traffic from illegitimate senders. Applications and hosts may also share the source-filter information with network elements (e.g., with routers using IGMPv3) so they can potentially perform the traffic filtering operation further 'upstream,' closer to the source(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-srcfilter-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-srcfilter-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-srcfilter-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-18160518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-srcfilter-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-srcfilter-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-18160518.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 19 11:52:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01291 for ; Wed, 19 Feb 2003 11:52:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JGwap25614 for mmusic-archive@odin.ietf.org; Wed, 19 Feb 2003 11:58:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGwap25611 for ; Wed, 19 Feb 2003 11:58:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01280 for ; Wed, 19 Feb 2003 11:51:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGwPp25599; Wed, 19 Feb 2003 11:58:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGvnp25569 for ; Wed, 19 Feb 2003 11:57:49 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01216 for ; Wed, 19 Feb 2003 11:51:07 -0500 (EST) Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09278 for ; Wed, 19 Feb 2003 09:54:57 -0700 (MST) Received: from sun.com (vpn-129-150-17-232.SFBay.Sun.COM [129.150.17.232]) by phys-ha2mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA21631 for ; Wed, 19 Feb 2003 08:54:56 -0800 (PST) Message-ID: <3E53B6B5.3050909@sun.com> Date: Wed, 19 Feb 2003 11:54:13 -0500 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Destination field in Transport Header - suggested text Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hey Folks, Here is my attempt to clarify the text for the destination field of the transport header. The action item was from the Feb 05, 03' conference call where the idea of having authorization form the recipient of the stream was proposed. The current text in draft-02 is: > destination: The address to which a stream will be sent. The | > client may specify the destination address with the destina- | > tion parameter. To avoid becoming the unwitting perpetrator of | > a remote-controlled denial-of-service attack, a server SHOULD | > authenticate the client and SHOULD log such attempts before | > allowing the client to direct a media stream to an address not | > chosen by the server. This is particularly important if RTSP | > commands are issued via UDP, but implementations cannot rely | > on TCP as reliable means of client identification by itself. | > IPv6 addresses is RECOMMENDED to be given as fully qualified | > domain to make it backwards compatible with RFC 2326 implemen- | > tations. | > The new suggested text to be placed in Section 12.40, p 75: destination: The address of the stream recipient to which a stream | will be sent. The client originating the RTSP request may | specify the destination address of the stream recipient with | the destination parameter. When the destination field is | specified, the recipient may be a different party than the | originator of the request. To avoid becoming the unwitting | perpetrator of a remote-controlled denial-of-service attack, a | server SHOULD authenticate the client originating the request | and SHOULD log such attempts before allowing the client to | direct a media stream to a recipient address not chosen by the | server. While, this is particularly important if RTSP commands | are issued via UDP, implementations cannot rely on TCP as | reliable means of client identification by itself either. | | The server SHOULD NOT allow the destination field to be set | unless a mechanism exists in the system to authorize the | request originator to direct streams to the recipient. It is | preferred that this authorization be performed by the | recipient itself and the credentials passed along to the | server. However, in certain cases, such as when recipient | address is a multicast group, or when the recipient is unable | to communicate with the server in an out-of-band manner, this | may not be possible. In these cases server may chose another | method such as a server-resident authorization list to ensure | that the request originator has the proper credentials to | request stream delivery to the recipient. | | IPv6 addresses are RECOMMENDED to be given as fully qualified | domain to make it backwards compatible with RFC 2326 implemen- | tations. | _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 19 12:27:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02241 for ; Wed, 19 Feb 2003 12:27:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JHXhQ28277 for mmusic-archive@odin.ietf.org; Wed, 19 Feb 2003 12:33:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHXhp28274 for ; Wed, 19 Feb 2003 12:33:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02228 for ; Wed, 19 Feb 2003 12:27:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JHXJp28254; Wed, 19 Feb 2003 12:33:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JH8jp26991 for ; Wed, 19 Feb 2003 12:08:45 -0500 Received: from antivir2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01541; Wed, 19 Feb 2003 12:02:01 -0500 (EST) Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 18:53:57 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 18:50:31 +0200 Message-ID: From: Sasha Vainshtein To: "'Kreuter Ruediger'" , "'avt@ietf.org'" , "'mmusic@ietf.org'" , "'pwe3@ietf.org'" Cc: "'kschong@att.com'" , "'taylor@nortelnetworks.com'" , Alik Shimelmits , Akiva Sadovski , Israel Sasson Date: Wed, 19 Feb 2003 18:50:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [PWE3] updated "Clearmode" (64kbit/s unrestricted) Internet-d raft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Ruediger and all, Please take a look at http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-05.txt , Section 6.6.2. It seems that the approach and the resulting format are pretty similar. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Kreuter Ruediger [mailto:ruediger.kreuter@siemens.com] > Sent: Tuesday, February 18, 2003 12:29 PM > To: 'avt@ietf.org'; 'mmusic@ietf.org'; 'pwe3@ietf.org' > Cc: 'kschong@att.com'; 'taylor@nortelnetworks.com' > Subject: [PWE3] updated "Clearmode" (64kbit/s unrestricted) > Internet-draft > > > FYI, > I have submitted an update of the CLEARMODE Internet draft. > You find it at > http://www.ietf.org/internet-drafts/draft-kreuter-avt-rtp-clea > rmode-01.txt > > The major update, due to comments according the support of Nx64kbit/s > and similar standardization activities in ITU's SG 11, is the > introduction of > Nx64kbit/s support. Two remarks to this issue: > 1) 1x64kbit/s is used in current VoIP products and supported > by most DSP > Providers. Therefore I would like to keep Nx64kbit/s with > N>1 as an option. > 2) We currently do not have a VoIP product supporting > Nx64kbit/s, therefore > I introduced this merely as a discussion input. > So if anybody has a working Nx64kbit/s solution I would > like to get some > comments on the packatization method in that case. If nobody has a > solution I will delete this feature from the next version > of this draft. > > Besides, the first draft initiated a controverse discussion, > if this should be > "audio/CLEARMODE" or e.g. "application/CLEARMODE". > IMHO none of the existing IANA content types really fits for > CLEARMODE. > Since 1x64kbit/s is also used for 7kHz voice (despite G.722) > I kept "audio" > in this draft. > > Regards > Ruediger > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 19 20:04:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14570 for ; Wed, 19 Feb 2003 20:04:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K1AbO24100 for mmusic-archive@odin.ietf.org; Wed, 19 Feb 2003 20:10:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K1Abp24097 for ; Wed, 19 Feb 2003 20:10:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14564 for ; Wed, 19 Feb 2003 20:03:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K1AOp24089; Wed, 19 Feb 2003 20:10:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K19Hp24033 for ; Wed, 19 Feb 2003 20:09:17 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14529 for ; Wed, 19 Feb 2003 20:02:25 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18lfAF-0000Zi-00 for ; Wed, 19 Feb 2003 17:06:15 -0800 Date: Wed, 19 Feb 2003 17:06:15 -0800 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030220010614.GC1393@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [MMUSIC] REDIRECT diff, v2 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --ZmUaFz6apKcXQszQ Content-Type: multipart/mixed; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's the new diff that incorporates the action items requested. Wording for actions required by the proxy was added and the Location header was made optional for all 3rr responses (although a 3rr response to a REDIRECT is probably not such a good idea in the first place...) --=20 Pardo's First Postulate: Anything good in life is either illegal, immoral, or fattening. Arnold's Addendum: Everything else causes cancer in rats. --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-02-v2.diff" Content-Transfer-Encoding: quoted-printable --- draft-rfc2326bis-02.txt 2002-11-06 14:34:00.000000000 -0800 +++ draft-rfc2326bis-02-mod.txt 2003-02-19 16:58:20.000000000 -0800 @@ -1202,7 +1202,7 @@ + 2xx: Success - The action was successfully received, understood, and accepted =20 - + 3xx: Redirection - Further action must be taken in order to com- + + 3rr: Redirection - Further action must be taken in order to com- plete the request =20 + 4xx: Client Error - The request contains bad syntax or cannot be @@ -2417,13 +2417,27 @@ =20 10.10 REDIRECT =20 - A redirect request informs the client that it MUST connect to another | - server location. REDIRECT SHALL only be sent to the client who cur- | - rently has a session at the server. The REDIRECT request MAY contain | - the header Location, which indicates that the client should issue | - requests for that URL. If the Location URL only contains a host | - address the client shall connect to the given host, while using the | - path from the URL on the current server. | + A redirect request informs the client that it MUST connect to another + server location. The REDIRECT request MAY contain the header Location, + which indicates that the client should issue requests for that URL. If + the Location URL only contains a host address the client shall connect = to + the given host, while using the path from the URL on the current server. + + If a REDIRECT request contains a Session header, it is end-to-end and + applies only to the given session. If there are proxies in the request + chain, they SHOULD NOT disconnect the control channel unless there are + no remaining sessions. + + If a REDIRECT request does not contain a Session header, it is next-hop + and applies to the control connection. The Location header SHOULD only + contain a host address. If there are proxies in the request chain, they + SHOULD do all of the following: (1) respond to the REDIRECT request, (2) + disconnect the control channel from the requestor, (3) reconnect to the + given host address, and (4) pass the request to each applicable client + (typically those clients with an active session or unanswered request + from the requestor). Note that the proxy is responsible for accepting + the REDIRECT response from its clients and these responses MUST NOT be + passed on to either the requesting or the destination server. =20 The redirect request MAY contain the header Range, which indicates | when the redirection takes effect. If the Range contains a time=3D = | @@ -2436,11 +2450,6 @@ time. The range value MUST be a single value in the open ended form, | e.g. npt=3D59-. = | =20 - If a Session header is included in the REDIRECT request the client | - MUST redirect the indicated session. If no Session header is included | - the client MUST redirect all sessions that it have on the server | - sending the request. | - If the client wants to continue to send or receive media for this | resource, the client MUST issue a TEARDOWN request for the current | session. A new session must be established with the designated host. | @@ -2647,7 +2656,11 @@ processes on the server may be consuming storage space simultane- ously, a client should take this only as an estimate. =20 -11.3 Redirection 3xx +11.3 Redirection 3rr + + The notation "3rr" indicates response codes from 300 to 399 inclusive + which are meant for redirection. The response code 304 is excluded + from this set, as it is not used for redirection. =20 See [H10.3] for definition of status code 300 to 305. However com- | ments are given for some to how they apply to RTSP. Further a couple | @@ -2679,6 +2692,24 @@ =20 11.3.5 304 Not Modified | =20 + If the client has performed a conditional DESCRIBE or SETUP (see 12.23) + and the requested resource has not been modified, the server SHOULD send + a 304 response. This response MUST NOT contain a message-body. + + The response MUST include the following header fields: + + - Date + - ETag and/or Content-Location, if the header would have been sent in + a 200 response to the same request. + - Expires, Cache-Control, and/or Vary, if the field-value might + differ from that sent in any previous response for the same variant. + + This response is independent for the DESCRIBE and SETUP requests. That + is, a 304 response to DESCRIBE does NOT imply that the resource content + is unchanged and a 304 response to SETUP does NOT imply that the resour= ce + description is unchanged. The ETag and If-Match headers may be used to + link the DESCRIBE and SETUP in this manner. + 11.3.6 305 Use Proxy | =20 See [H10.3.6]. | @@ -2948,7 +2979,7 @@ =20 The From, Location, and RTP-Info header fields contain a URI. If the URI contains a comma, or semicolon, the URI MUST be enclosed in dou- - ble quotas ("). Any URI parameters are contained within these quotas. + ble quotes ("). Any URI parameters are contained within these quotas. If the URI is not enclosed in double quotas, any semicolon- delimited parameters are header-parameters, not URI parameters. =20 @@ -3011,7 +3042,7 @@ If-Match R r - - o - - - If-Modified-Since R r o - o - - - Last-Modified r r o - - - - - - Location 3xx o - o - - - + Location 3rr o o o o o o Proxy-Authenticate 407 amr m m m m m m Proxy-Require R ar o o o o o o Public r admr - m* - - - - @@ -3028,7 +3059,7 @@ Internet Draft RTSP November 01, 2002 =20 =20 - Retry-After 3xx,503 o o o - - - + Retry-After 3rr,503 o o o - - - RTP-Info r - - o m - - Scale - - - o - - Session R - o o m m m @@ -3118,6 +3149,7 @@ Host o o o o o o Last-Modified R r - - o - - - Last-Modified r r o - - - - - + Location 3rr o o o o o o Location R - - - - m - Proxy-Authenticate 407 amr m m m m m m Proxy-Require R ar o o o o o o @@ -3125,7 +3157,7 @@ Range R - - - - o - Referer R o o o o o - Require R o o o o o o - Retry-After 3xx,503 o o - - - - + Retry-After 3rr,503 o o - - - - Scale - - - o - - Session R o o m m o m Session r c c m m o m @@ -5830,8 +5862,9 @@ =20 type of error occur the appropriate response code MUST be sent. If | the response code is a 4xx the session state is unchanged. A response | - code of 3xx will result in that the session is ended and its state is | - changed to Init. However there exist restrictions to when a 3xx | + code of 3rr will result in that the session is ended and its state is | + changed to Init. A response code of 304 results in no state change. + However there exist restrictions to when a 3xx | response may be used. A 5xx response SHALL not result in any change | of the session state, except if the error is not possible to recover | from. A unrecoverable error SHALL result the ending of the session. | @@ -5855,7 +5888,7 @@ =20 Event Prerequisite Response ----------------------------------------------------------------- - DESCRIBE Needs REDIRECT 3xx Redirect + DESCRIBE Needs REDIRECT 3rr Redirect DESCRIBE 200, Session description OPTIONS Session ID 200, Reset session timeout timer OPTIONS 200 @@ -5888,20 +5921,20 @@ Action Requisite New State Response ------------------------------------------------- SETUP Ready NRM=3D1, RP=3D0.0 - SETUP Needs Redirect Init 3xx Redirect + SETUP Needs Redirect Init 3rr Redirect =20 =20 Table 7: State: Init =20 state variables are also set by a correct request. This table also | shows that a correct SETUP can in some cases be redirected to another | - URL and/or server by a 3xx response. | + URL and/or server by a 3rr response. | =20 =20 Action Requisite New State Response ---------------------------------------------------------- SETUP Ready NRM=3D1,RP=3D0.0 - SETUP Needs Redirect Init 3xx + SETUP Needs Redirect Init 3rr TEARDOWN URL=3D* Init No session hdr. Timeout Init S->C:REDIRECT Range hdr Ready-nm Set RedP @@ -7187,7 +7220,7 @@ 11.1.1 100 Continue . . . . . . . . . . . . . . . . . . . . . . 47 11.2 Success 2xx . . . . . . . . . . . . . . . . . . . . . . . 48 11.2.1 250 Low on Storage Space . . . . . . . . . . . . . . . . 48 -11.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 48 +11.3 Redirection 3rr . . . . . . . . . . . . . . . . . . . . . 48 11.3.1 TBW . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . 48 11.3.3 302 Found . . . . . . . . . . . . . . . . . . . . . . . . 48 --hHWLQfXTYDoKhP50-- --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+VCoGqznSmcYu2m8RAnZnAJ9NNWJJF2H1IqmT2Wj+zLAcJh+Z0wCfcBDa WKjniye1RUFThgSRmKzc2PU= =iVYL -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 19 20:53:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15411 for ; Wed, 19 Feb 2003 20:53:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K20C626422 for mmusic-archive@odin.ietf.org; Wed, 19 Feb 2003 21:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K20Cp26419 for ; Wed, 19 Feb 2003 21:00:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15381 for ; Wed, 19 Feb 2003 20:53:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K203p26408; Wed, 19 Feb 2003 21:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K1xdp26332 for ; Wed, 19 Feb 2003 20:59:39 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15365 for ; Wed, 19 Feb 2003 20:52:47 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h1K1thB12888; Wed, 19 Feb 2003 17:56:35 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 17:55:43 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A780C@MISTY> From: Thomas Zeng To: "'Tom Marshall'" , mmusic@ietf.org Subject: RE: [MMUSIC] REDIRECT diff, v2 Date: Wed, 19 Feb 2003 17:55:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Tom: What about the resolution from a couple of RTSP telecon ago to replace END_OF_STREAM with REDIRECT to the same server? I don't see it in this diff file. Also it would be nice to see the new section 10.10 in its final form. thanks, thomas -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Wednesday, February 19, 2003 5:06 PM To: mmusic@ietf.org Subject: [MMUSIC] REDIRECT diff, v2 Here's the new diff that incorporates the action items requested. Wording for actions required by the proxy was added and the Location header was made optional for all 3rr responses (although a 3rr response to a REDIRECT is probably not such a good idea in the first place...) -- Pardo's First Postulate: Anything good in life is either illegal, immoral, or fattening. Arnold's Addendum: Everything else causes cancer in rats. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 19 22:04:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16814 for ; Wed, 19 Feb 2003 22:04:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K3BCC30349 for mmusic-archive@odin.ietf.org; Wed, 19 Feb 2003 22:11:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3BCp30346 for ; Wed, 19 Feb 2003 22:11:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16803 for ; Wed, 19 Feb 2003 22:04:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3B1p30337; Wed, 19 Feb 2003 22:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K39jp30290 for ; Wed, 19 Feb 2003 22:09:45 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16795 for ; Wed, 19 Feb 2003 22:02:52 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18lh2n-0000eC-00; Wed, 19 Feb 2003 19:06:41 -0800 Date: Wed, 19 Feb 2003 19:06:41 -0800 From: Tom Marshall To: Thomas Zeng Cc: mmusic@ietf.org Subject: Re: [MMUSIC] REDIRECT diff, v2 Message-ID: <20030220030641.GA2454@real.com> References: <72263E8E8622D611975C0002B32C19D84A780C@MISTY> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <72263E8E8622D611975C0002B32C19D84A780C@MISTY> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 19, 2003 at 05:55:43PM -0800, Thomas Zeng wrote: > Tom: >=20 > What about the resolution from a couple of RTSP telecon ago to replace > END_OF_STREAM with REDIRECT to the same server? That discussion started from a proposal by Magnus, so I figured he would write that part. I can do it if desired. > I don't see it in this diff file. Also it would be nice to see the new > section 10.10 in its final form. The patch utility will produce the final form. --=20 Psychiatry is the care of the id by the odd. -- Anonymous --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+VEZBqznSmcYu2m8RAiu2AJ4ocX3tmf3IGEjt4H1gZ7aGxS9OkwCeIxs1 KF7So3z020PvPPVAK0U4FR4= =i4c7 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 20 03:01:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03520 for ; Thu, 20 Feb 2003 03:01:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K88Dg25381 for mmusic-archive@odin.ietf.org; Thu, 20 Feb 2003 03:08:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K88Dp25378 for ; Thu, 20 Feb 2003 03:08:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03508 for ; Thu, 20 Feb 2003 03:01:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K887p25366; Thu, 20 Feb 2003 03:08:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K85Yp24551 for ; Thu, 20 Feb 2003 03:05:34 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03377 for ; Thu, 20 Feb 2003 02:58:35 -0500 (EST) From: toni.paila@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1K81C225080 for ; Thu, 20 Feb 2003 10:01:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Feb 2003 10:02:23 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 10:02:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2D8B6.65F94A12" Date: Thu, 20 Feb 2003 10:02:22 +0200 Message-ID: <26574F0076BFF449ADAE582D9E67780C0109F30D@esebe006.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt Thread-Index: AcLYKYaRDSOBN7rPSk6NNYh4uswwggAi6RSQ To: X-OriginalArrivalTime: 20 Feb 2003 08:02:23.0191 (UTC) FILETIME=[664F3670:01C2D8B6] Subject: [MMUSIC] FW: I-D ACTION:draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D8B6.65F94A12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, Note the draft below. It is related to Internet Media Guides. Regards, Toni=20 > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 19 February, 2003 17:05 > Subject: I-D ACTION:draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : DVB thoughts on Service Discovery and Selection > Author(s) : P. Stallard, T. Paila > Filename : draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt > Pages : 10 > Date : 2003-2-18 > =09 > This memo presents some thoughts on the requirements of Internet=20 > Media Guides. It is based on some similar work undertaken by the > Digital Video Broadcasting (DVB) group. >=20 > A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-stallard-mmusic-dvb-thoughts-on= -sds-00.txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail =20 > address. After logging in, type "cd internet-drafts" and then "get = draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-stallard-mmusic-dvb-thoughts-on-sds-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01C2D8B6.65F94A12 Content-Type: application/octet-stream; name="ATT323985.TXT" Content-Description: ATT323985.TXT Content-Disposition: attachment; filename="ATT323985.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAzLTItMTgxNjAzMzMuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3RhbGxhcmQtbW11c2lj LWR2Yi10aG91Z2h0cy1vbi1zZHMtMDAudHh0DQo= ------_=_NextPart_001_01C2D8B6.65F94A12 Content-Type: application/octet-stream; name="draft-stallard-mmusic-dvb-thoughts-on-sds-00.URL" Content-Description: draft-stallard-mmusic-dvb-thoughts-on-sds-00.URL Content-Disposition: attachment; filename="draft-stallard-mmusic-dvb-thoughts-on-sds-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zdGFsbGFyZC1tbXVzaWMtZHZiLXRob3VnaHRzLW9uLXNkcy0wMC50eHQNCg== ------_=_NextPart_001_01C2D8B6.65F94A12-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 20 03:22:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04081 for ; Thu, 20 Feb 2003 03:22:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K8SxP26084 for mmusic-archive@odin.ietf.org; Thu, 20 Feb 2003 03:28:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K8Swp26080 for ; Thu, 20 Feb 2003 03:28:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04048 for ; Thu, 20 Feb 2003 03:21:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K8Sop26066; Thu, 20 Feb 2003 03:28:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K8Q9p25982 for ; Thu, 20 Feb 2003 03:26:09 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03940 for ; Thu, 20 Feb 2003 03:19:09 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1K8MxKV013928; Thu, 20 Feb 2003 09:22:59 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4GAMQH; Thu, 20 Feb 2003 09:22:59 +0100 Message-ID: <3E549063.8090208@era.ericsson.se> Date: Thu, 20 Feb 2003 09:22:59 +0100 X-Sybari-Trust: 33434b87 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng , IETF MMUSIC WG Subject: Re: [MMUSIC] REDIRECT diff, v2 References: <72263E8E8622D611975C0002B32C19D84A780C@MISTY> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thomas, Thomas Zeng wrote: >Tom: > >What about the resolution from a couple of RTSP telecon ago to replace >END_OF_STREAM with REDIRECT to the same server? > > Just to avoid confusion with naming. I assume you mean the problem of doing server initiated teardowns. From the 22 January notes: Resolution: use redirect to tell the clients to teardown and reconnect to the same server. Then tell the clients that service is not available via perhaps a info page. That way we have good backwards compatibility and no need for TEARDOWN S->C nor END_OF_STREAM. And please Tom I would be thankful if you would include this in your text write up. We have another problem that also has been refered to as END_OF_STREAM. This is the problem that a client does not know when the last media packets part of the current playout range has been received. Therefore one proposal has been to send a END_OF_PLAYOUT request from the server to client to tell it that is near and what rtp packets will be the last ones. -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 20 07:40:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09773 for ; Thu, 20 Feb 2003 07:40:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KClTm09127 for mmusic-archive@odin.ietf.org; Thu, 20 Feb 2003 07:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KClTp09124 for ; Thu, 20 Feb 2003 07:47:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09741 for ; Thu, 20 Feb 2003 07:40:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KClKp09099; Thu, 20 Feb 2003 07:47:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KCiYp08892 for ; Thu, 20 Feb 2003 07:44:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09330; Thu, 20 Feb 2003 07:37:31 -0500 (EST) Message-Id: <200302201237.HAA09330@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 20 Feb 2003 07:37:31 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdpng-trans-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDPng Transition Author(s) : J. Ott, C. Perkins Filename : draft-ietf-mmusic-sdpng-trans-03.txt Pages : 15 Date : 2003-2-19 The Session Description Protocol (SDP) is today widely used in the Internet to announce as well as negotiate multimedia sessions and exchange capabilities. Having originally been designed for session announcements only, as opposed to announcements and capabilities negotiation announcements, native SDP lacks numerous features to be applicable in many session scenarios. Numerous extensions have been developed to circumvent SDP's shortcomings -- but they have also repeatedly shown its inherent limitations. A successor protocol -- termed 'SDPng' for the time being -- is developed to address the aforementioned needs of Internet applications in a more structured manner. With the huge installed base of SDP-based applications, a migration path needs to be developed to move from SDP to SDPng over time. This document outlines how this migration can be achieved: in general as well as for the various IETF control protocols that potentially make use of SDP and SDPng. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-trans-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdpng-trans-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdpng-trans-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19142205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdpng-trans-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdpng-trans-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 20 12:52:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22951 for ; Thu, 20 Feb 2003 12:52:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KHwo801037 for mmusic-archive@odin.ietf.org; Thu, 20 Feb 2003 12:58:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHwop01034 for ; Thu, 20 Feb 2003 12:58:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22928 for ; Thu, 20 Feb 2003 12:51:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHwdp01022; Thu, 20 Feb 2003 12:58:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHvbp00926 for ; Thu, 20 Feb 2003 12:57:37 -0500 Received: from wullbinkle.real.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22896 for ; Thu, 20 Feb 2003 12:50:24 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id h1KHs7TT006448 for ; Thu, 20 Feb 2003 09:54:07 -0800 Received: from raven.dev.prognet.com ([172.22.22.16]) by real.com (8.12.2/8.12.2) with ESMTP id h1KHs6Q2029732 for ; Thu, 20 Feb 2003 09:54:07 -0800 Date: Thu, 20 Feb 2003 09:54:27 -0800 (PST) From: Aaron Colwell To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] Relative URLs in RTP-Info field Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi, In some inter-op testing that I've done, I've discovered an ambiguous situation related to SDP initiated playback and relative URLs in the PLAY response. Say I have the following SDP v=0 a=control:rtsp://foo.com/blah.3gp m=audio 0 RTP/AVP 96 a=control:rtsp://foo.com/blah.3gp/trackID=1 a=rtpmap:96 MP4A-LATM/44100 a=range:npt=0-37 m=video 0 RTP/AVP 97 a=control:rtsp://foo.com/blah.3gp/trackID=2 a=rtpmap:97 MP4V-ES/90000 The RTSP chat sequence looks something like OPTIONS rtsp://foo.com SETUP rtsp://foo.com/blah.3gp/trackID=1 SETUP response SETUP rtsp://foo.com/blah.3gp/trackID=2 SETUP response PLAY rtsp://foo.com/blah.3gp PLAY response RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=2;seq=2234;rtptime=93875 Notice that the URLs in the RTP-Info field are relative. In this case, I don't have a base URL to apply the relative URLs to. This is because I did not issue a DESCRIBE and therefore did not get a Content-Base or Content-Location field from a DESCRIBE response. What is the proper thing to do in this case? Since I don't have a base URL to apply the relative URLs to, I can't figure out which SETUP URL the RTP-Info is referring to. In this particular example I would be able to figure it out by applying the relative URLs to each SETUP URL and then see if the resulting URL matches the original URL. That solution won't work for all cases though. Here is an example of where that won't work. You have an SDP that looks like.. v=0 a=control:rtsp://foo.com/movie m=audio 0 RTP/AVP 96 a=control:rtsp://foo.com/audio.3gp/trackID=1 a=rtpmap:96 MP4A-LATM/44100 a=range:npt=0-37 m=video 0 RTP/AVP 97 a=control:rtsp://foo.com/video.3gp/trackID=1 a=rtpmap:97 MP4V-ES/90000 The RTSP chat for this situation would look like OPTIONS rtsp://foo.com SETUP rtsp://foo.com/audio.3gp/trackID=1 SETUP response SETUP rtsp://foo.com/video.3gp/trackID=1 SETUP response PLAY rtsp://foo.com/movie PLAY response RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=1;seq=234;rtptime=23487 In this case I have no way to figure out what info is associated with which stream. I think part of the problem here is that the server is assuming that the client knows what the base URL is. In the case of an SDP initiated playback, I don't have one. To my knowledge there is no way that the server can detect whether I have a base URL or not. I suppose it could check to see if I issued a DESCRIBE or not, but that seems a little messy to me. I propose that the RTP-Info field should contain the SETUP URLs exactly the way that they were given to the server in the SETUP. This allows the client an easy way to figure out what URLs are associated with which streams. Relative URLs should not be allowed since it is ambiguous as to what they are relative to. I'm open to any questions or comments. Aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 21 05:25:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25213 for ; Fri, 21 Feb 2003 05:25:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LAWWv10651 for mmusic-archive@odin.ietf.org; Fri, 21 Feb 2003 05:32:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LAWWp10648 for ; Fri, 21 Feb 2003 05:32:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25210 for ; Fri, 21 Feb 2003 05:25:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LAWGp10632; Fri, 21 Feb 2003 05:32:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LAVCp10612 for ; Fri, 21 Feb 2003 05:31:12 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25188 for ; Fri, 21 Feb 2003 05:23:40 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1LARUAv010148; Fri, 21 Feb 2003 11:27:30 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVHQKY3; Fri, 21 Feb 2003 11:27:28 +0100 Message-ID: <3E55FF10.1000100@era.ericsson.se> Date: Fri, 21 Feb 2003 11:27:28 +0100 X-Sybari-Trust: 9ced1d5e 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell CC: mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aaron, I will try to provide answers to your questions. Aaron Colwell wrote: >Hi, > >In some inter-op testing that I've done, I've discovered an ambiguous >situation related to SDP initiated playback and relative URLs in the PLAY >response. > >Say I have the following SDP >v=0 >a=control:rtsp://foo.com/blah.3gp >m=audio 0 RTP/AVP 96 >a=control:rtsp://foo.com/blah.3gp/trackID=1 >a=rtpmap:96 MP4A-LATM/44100 >a=range:npt=0-37 >m=video 0 RTP/AVP 97 >a=control:rtsp://foo.com/blah.3gp/trackID=2 >a=rtpmap:97 MP4V-ES/90000 > >The RTSP chat sequence looks something like >OPTIONS rtsp://foo.com >SETUP rtsp://foo.com/blah.3gp/trackID=1 >SETUP response >SETUP rtsp://foo.com/blah.3gp/trackID=2 >SETUP response >PLAY rtsp://foo.com/blah.3gp >PLAY response > RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=2;seq=2234;rtptime=93875 > >Notice that the URLs in the RTP-Info field are relative. In this case, I >don't have a base URL to apply the relative URLs to. This is because I did >not issue a DESCRIBE and therefore did not get a Content-Base or >Content-Location field from a DESCRIBE response. > The relative URLs are having the base URL of the Request URL. It might not be very clear about how to derive the base URL for the RTP-info header. It is something we need to clarify in the updated RTSP spec. However the base URL rules that are defined for SDP base URL says that the request URL should be used if not Content-Base or Content-Location is defined in the response. So in the above case they are actually erroneous. The RTP info header should have the following look: RTP-Info: url=blah.3gp/trackID=1;seq=0;rtptime=0,url=blah.3gp/trackID=2;seq=2234;rtptime=93875 > >What is the proper thing to do in this case? Since I don't have a base URL >to apply the relative URLs to, I can't figure out which SETUP URL the >RTP-Info is referring to. In this particular example I would be able to >figure it out by applying the relative URLs to each SETUP URL and then see >if the resulting URL matches the original URL. That solution won't work >for all cases though. Here is an example of where that won't work. > > As said before the relative URLs uses the Request URL as base, i.e. the PLAY request for the RTP-Info header. Please also note that normal URL handling rules apply, e.g. the last path segment at the end of the URL is removed. >You have an SDP that looks like.. >v=0 >a=control:rtsp://foo.com/movie >m=audio 0 RTP/AVP 96 >a=control:rtsp://foo.com/audio.3gp/trackID=1 >a=rtpmap:96 MP4A-LATM/44100 >a=range:npt=0-37 >m=video 0 RTP/AVP 97 >a=control:rtsp://foo.com/video.3gp/trackID=1 >a=rtpmap:97 MP4V-ES/90000 > >The RTSP chat for this situation would look like >OPTIONS rtsp://foo.com >SETUP rtsp://foo.com/audio.3gp/trackID=1 >SETUP response >SETUP rtsp://foo.com/video.3gp/trackID=1 >SETUP response >PLAY rtsp://foo.com/movie >PLAY response > RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=1;seq=234;rtptime=23487 > >In this case I have no way to figure out what info is associated with >which stream. > Yes, you have. By using the PLAY request's URL as base the RTP-Info URLs would be: RTP-Info: url=audio.3gp/trackID=1;seq=0;rtptime=0, url=video.3gp/trackID=1;seq=234;rtptime=23487 > >I think part of the problem here is that the server is assuming that the >client knows what the base URL is. In the case of an SDP initiated >playback, I don't have one. To my knowledge there is no way that the >server can detect whether I have a base URL or not. I suppose it could >check to see if I issued a DESCRIBE or not, but that seems a little messy >to me. > There must always be clear what is the base-URL. For RTSP request you can't use base-urls that are remembered each request - response pair must be self contained in this regard. > >I propose that the RTP-Info field should contain the SETUP URLs exactly >the way that they were given to the server in the SETUP. This allows the >client an easy way to figure out what URLs are associated with which >streams. Relative URLs should not be allowed since it is ambiguous as to >what they are relative to. > For RTP-Info you either use relative URLs to the request URL or use absolute ones. Unless anyone argues against it I will add the following sentence to the RTP-Info URL description to clarify this: "Any relative URL SHALL use the request URL as base URL." Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 21 12:04:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07059 for ; Fri, 21 Feb 2003 12:04:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LHBJ105796 for mmusic-archive@odin.ietf.org; Fri, 21 Feb 2003 12:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHBJp05793 for ; Fri, 21 Feb 2003 12:11:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07048 for ; Fri, 21 Feb 2003 12:03:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHBFp05783; Fri, 21 Feb 2003 12:11:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHAvp05749 for ; Fri, 21 Feb 2003 12:10:57 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07038 for ; Fri, 21 Feb 2003 12:03:16 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18mGde-0003Xr-00; Fri, 21 Feb 2003 09:07:06 -0800 Date: Fri, 21 Feb 2003 09:07:06 -0800 From: Tom Marshall To: Magnus Westerlund Cc: Aaron Colwell , mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field Message-ID: <20030221170706.GA13605@real.com> References: <3E55FF10.1000100@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <3E55FF10.1000100@era.ericsson.se> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >You have an SDP that looks like.. > >v=3D0 > >a=3Dcontrol:rtsp://foo.com/movie > >m=3Daudio 0 RTP/AVP 96 > >a=3Dcontrol:rtsp://foo.com/audio.3gp/trackID=3D1 > >a=3Drtpmap:96 MP4A-LATM/44100 > >a=3Drange:npt=3D0-37 > >m=3Dvideo 0 RTP/AVP 97 > >a=3Dcontrol:rtsp://foo.com/video.3gp/trackID=3D1 > >a=3Drtpmap:97 MP4V-ES/90000 > > > >The RTSP chat for this situation would look like > >OPTIONS rtsp://foo.com > >SETUP rtsp://foo.com/audio.3gp/trackID=3D1 > >SETUP response > >SETUP rtsp://foo.com/video.3gp/trackID=3D1 > >SETUP response > >PLAY rtsp://foo.com/movie > >PLAY response > >RTP-Info: url=3DtrackID=3D1;seq=3D0;rtptime=3D0,url=3DtrackID=3D1;seq=3D= 234;rtptime=3D23487 > > > >In this case I have no way to figure out what info is associated with > >which stream. > > >=20 > Yes, you have. By using the PLAY request's URL as base the RTP-Info URLs= =20 > would be: >=20 > RTP-Info: url=3Daudio.3gp/trackID=3D1;seq=3D0;rtptime=3D0,=20 > url=3Dvideo.3gp/trackID=3D1;seq=3D234;rtptime=3D23487 You are making an assumption about the ordering here -- that the first url= =3D corresponds to the first SETUP. Is that required? --=20 Most people are too busy to have time for anything important. --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+Vly6qznSmcYu2m8RAhtgAKCTW6PKrXLAONHk2ZrDpl/Jc4n62gCdEZLT xffaOR6sy1aWzGBn+bmseyk= =wlNS -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 21 12:39:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08278 for ; Fri, 21 Feb 2003 12:39:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LHl9u08019 for mmusic-archive@odin.ietf.org; Fri, 21 Feb 2003 12:47:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHl9p08016 for ; Fri, 21 Feb 2003 12:47:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08245 for ; Fri, 21 Feb 2003 12:39:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHl4p08008; Fri, 21 Feb 2003 12:47:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHkip07984 for ; Fri, 21 Feb 2003 12:46:44 -0500 Received: from wullbinkle.real.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08242 for ; Fri, 21 Feb 2003 12:39:03 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id h1LHgjTT017680; Fri, 21 Feb 2003 09:42:45 -0800 Received: from raven.dev.prognet.com ([172.22.22.16]) by real.com (8.12.2/8.12.2) with ESMTP id h1LHgjQ2013960; Fri, 21 Feb 2003 09:42:45 -0800 Date: Fri, 21 Feb 2003 09:43:13 -0800 (PST) From: Aaron Colwell To: Magnus Westerlund cc: mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field In-Reply-To: <3E55FF10.1000100@era.ericsson.se> Message-ID: References: <3E55FF10.1000100@era.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Thank you for the clarification. I was somewhat expecting that answer, but I just wanted to make sure. One other thing that I'd like to have clarified is that if absolute URLs are returned that they match what was sent in the SETUP request for that stream. I've run into a case where a server will return me an IP address in the hostname part of the URL instead of the hostname that I specified. It is things like this that make matching SETUP URLs with RTP-Info information not very easy. I'd like to not have to use heuristic methods for dealing with these types of situations. Perhaps the clarification for RTP-Info URLs should be something like "Any relative URL SHALL use the request URL as base URL. The resulting URL must match the URL used to SETUP that stream. If an absolute URL is specified, it MUST match the URL used to SETUP that stream." I'm sure this could be worded a little better and put into proper RFC-speak. Thanks, Aaron On Fri, 21 Feb 2003, Magnus Westerlund wrote: > Hi Aaron, > > I will try to provide answers to your questions. > > Aaron Colwell wrote: > > >Hi, > > > >In some inter-op testing that I've done, I've discovered an ambiguous > >situation related to SDP initiated playback and relative URLs in the PLAY > >response. > > > >Say I have the following SDP > >v=0 > >a=control:rtsp://foo.com/blah.3gp > >m=audio 0 RTP/AVP 96 > >a=control:rtsp://foo.com/blah.3gp/trackID=1 > >a=rtpmap:96 MP4A-LATM/44100 > >a=range:npt=0-37 > >m=video 0 RTP/AVP 97 > >a=control:rtsp://foo.com/blah.3gp/trackID=2 > >a=rtpmap:97 MP4V-ES/90000 > > > >The RTSP chat sequence looks something like > >OPTIONS rtsp://foo.com > >SETUP rtsp://foo.com/blah.3gp/trackID=1 > >SETUP response > >SETUP rtsp://foo.com/blah.3gp/trackID=2 > >SETUP response > >PLAY rtsp://foo.com/blah.3gp > >PLAY response > > RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=2;seq=2234;rtptime=93875 > > > >Notice that the URLs in the RTP-Info field are relative. In this case, I > >don't have a base URL to apply the relative URLs to. This is because I did > >not issue a DESCRIBE and therefore did not get a Content-Base or > >Content-Location field from a DESCRIBE response. > > > > The relative URLs are having the base URL of the Request URL. It might > not be very clear about how to derive the base URL for the RTP-info > header. It is something we need to clarify in the updated RTSP spec. > However the base URL rules that are defined for SDP base URL says that > the request URL should be used if not Content-Base or Content-Location > is defined in the response. So in the above case they are actually > erroneous. The RTP info header should have the following look: > > RTP-Info: url=blah.3gp/trackID=1;seq=0;rtptime=0,url=blah.3gp/trackID=2;seq=2234;rtptime=93875 > > > > > >What is the proper thing to do in this case? Since I don't have a base URL > >to apply the relative URLs to, I can't figure out which SETUP URL the > >RTP-Info is referring to. In this particular example I would be able to > >figure it out by applying the relative URLs to each SETUP URL and then see > >if the resulting URL matches the original URL. That solution won't work > >for all cases though. Here is an example of where that won't work. > > > > > > As said before the relative URLs uses the Request URL as base, i.e. the > PLAY request for the RTP-Info header. Please also note that normal URL > handling rules apply, e.g. the last path segment at the end of the URL > is removed. > > >You have an SDP that looks like.. > >v=0 > >a=control:rtsp://foo.com/movie > >m=audio 0 RTP/AVP 96 > >a=control:rtsp://foo.com/audio.3gp/trackID=1 > >a=rtpmap:96 MP4A-LATM/44100 > >a=range:npt=0-37 > >m=video 0 RTP/AVP 97 > >a=control:rtsp://foo.com/video.3gp/trackID=1 > >a=rtpmap:97 MP4V-ES/90000 > > > >The RTSP chat for this situation would look like > >OPTIONS rtsp://foo.com > >SETUP rtsp://foo.com/audio.3gp/trackID=1 > >SETUP response > >SETUP rtsp://foo.com/video.3gp/trackID=1 > >SETUP response > >PLAY rtsp://foo.com/movie > >PLAY response > > RTP-Info: url=trackID=1;seq=0;rtptime=0,url=trackID=1;seq=234;rtptime=23487 > > > >In this case I have no way to figure out what info is associated with > >which stream. > > > > Yes, you have. By using the PLAY request's URL as base the RTP-Info URLs > would be: > > RTP-Info: url=audio.3gp/trackID=1;seq=0;rtptime=0, url=video.3gp/trackID=1;seq=234;rtptime=23487 > > > > > >I think part of the problem here is that the server is assuming that the > >client knows what the base URL is. In the case of an SDP initiated > >playback, I don't have one. To my knowledge there is no way that the > >server can detect whether I have a base URL or not. I suppose it could > >check to see if I issued a DESCRIBE or not, but that seems a little messy > >to me. > > > > There must always be clear what is the base-URL. For RTSP request you > can't use base-urls that are remembered each request - response pair > must be self contained in this regard. > > > > >I propose that the RTP-Info field should contain the SETUP URLs exactly > >the way that they were given to the server in the SETUP. This allows the > >client an easy way to figure out what URLs are associated with which > >streams. Relative URLs should not be allowed since it is ambiguous as to > >what they are relative to. > > > > For RTP-Info you either use relative URLs to the request URL or use > absolute ones. Unless anyone argues against it I will add the following > sentence to the RTP-Info URL description to clarify this: "Any relative > URL SHALL use the request URL as base URL." > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 21 13:20:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09812 for ; Fri, 21 Feb 2003 13:20:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LIRKJ10490 for mmusic-archive@odin.ietf.org; Fri, 21 Feb 2003 13:27:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIRKp10486 for ; Fri, 21 Feb 2003 13:27:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09805 for ; Fri, 21 Feb 2003 13:19:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIRGp10471; Fri, 21 Feb 2003 13:27:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIQ4p10446 for ; Fri, 21 Feb 2003 13:26:04 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09775 for ; Fri, 21 Feb 2003 13:18:22 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1LIMDAv021466; Fri, 21 Feb 2003 19:22:13 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4G3CQY; Fri, 21 Feb 2003 19:22:13 +0100 Message-ID: <3E566E55.3080708@era.ericsson.se> Date: Fri, 21 Feb 2003 19:22:13 +0100 X-Sybari-Trust: 631be167 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell CC: mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field References: <3E55FF10.1000100@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aaron, Aaron Colwell wrote: >Thank you for the clarification. I was somewhat expecting that answer, but >I just wanted to make sure. > >One other thing that I'd like to have clarified is that if absolute URLs >are returned that they match what was sent in the SETUP request for that >stream. I've run into a case where a server will return me an IP address >in the hostname part of the URL instead of the hostname that I specified. >It is things like this that make matching SETUP URLs with RTP-Info >information not very easy. I'd like to not have to use heuristic methods >for dealing with these types of situations. Perhaps the clarification for >RTP-Info URLs should be something like > >"Any relative URL SHALL use the request URL as base URL. The resulting > URL must match the URL used to SETUP that stream. If an absolute URL is > specified, it MUST match the URL used to SETUP that stream." > >I'm sure this could be worded a little better and put into proper >RFC-speak. > > Yes, this sounds reasonable. The sever should really reference the media resource that it has setup, not something else. However I have not have time to look up what RFC 2396 says about matching a URI. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 21 14:59:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12835 for ; Fri, 21 Feb 2003 14:59:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LK6Ua16672 for mmusic-archive@odin.ietf.org; Fri, 21 Feb 2003 15:06:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LK6Up16669 for ; Fri, 21 Feb 2003 15:06:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12813 for ; Fri, 21 Feb 2003 14:58:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LK6Ap16624; Fri, 21 Feb 2003 15:06:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LK5Kp16557 for ; Fri, 21 Feb 2003 15:05:20 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12757 for ; Fri, 21 Feb 2003 14:57:38 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18mJMH-0003yS-00; Fri, 21 Feb 2003 12:01:21 -0800 Date: Fri, 21 Feb 2003 12:01:21 -0800 From: Tom Marshall To: Magnus Westerlund Cc: Aaron Colwell , mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field Message-ID: <20030221200121.GB14792@real.com> References: <3E55FF10.1000100@era.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <3E55FF10.1000100@era.ericsson.se> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >You have an SDP that looks like.. > >v=3D0 > >a=3Dcontrol:rtsp://foo.com/movie > >m=3Daudio 0 RTP/AVP 96 > >a=3Dcontrol:rtsp://foo.com/audio.3gp/trackID=3D1 > >a=3Drtpmap:96 MP4A-LATM/44100 > >a=3Drange:npt=3D0-37 > >m=3Dvideo 0 RTP/AVP 97 > >a=3Dcontrol:rtsp://foo.com/video.3gp/trackID=3D1 > >a=3Drtpmap:97 MP4V-ES/90000 > > > >The RTSP chat for this situation would look like > >OPTIONS rtsp://foo.com > >SETUP rtsp://foo.com/audio.3gp/trackID=3D1 > >SETUP response > >SETUP rtsp://foo.com/video.3gp/trackID=3D1 > >SETUP response > >PLAY rtsp://foo.com/movie > >PLAY response > >RTP-Info: url=3DtrackID=3D1;seq=3D0;rtptime=3D0,url=3DtrackID=3D1;seq=3D= 234;rtptime=3D23487 > > > >In this case I have no way to figure out what info is associated with > >which stream. > > >=20 > Yes, you have. By using the PLAY request's URL as base the RTP-Info URLs= =20 > would be: >=20 > RTP-Info: url=3Daudio.3gp/trackID=3D1;seq=3D0;rtptime=3D0,=20 > url=3Dvideo.3gp/trackID=3D1;seq=3D234;rtptime=3D23487 Based on the RTSP spec and a few private emails, I think the correct answer here is that the server is in error (is this what you meant to say, Magnus?) When the client combines the relative urls in RTP-Info with the absolute url in the request using the rules in RFC1808, the result is this for both streams: rtsp://foo.com/movie + trackID=3D1 -> rtsp://foo.com/trackID=3D1 If the server wished to use relative urls in the RTP-Info header, the proper response would be one of the following: A completely relative response would be this: RTP-Info: url=3Daudio.3gp/trackID=3D1;seq=3D0;rtptime=3D0, url=3Dvideo.3gp/trackID=3D1;seq=3D234;rtptime=3D23487 Note that if the stream urls were in a different path from the aggregate url, the response would contain one or more ../ sequences. An absolute path without any host would also work: RTP-Info: url=3D/audio.3gp/trackID=3D1;seq=3D0;rtptime=3D0, url=3D/video.3gp/trackID=3D1;seq=3D234;rtptime=3D23487 --=20 Innovate, v.: To annoy people. --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+VoWRqznSmcYu2m8RAsvRAKCNpNgLcRjA7ThXNtkCUZ0wSmTPlwCfdkhb lWGjhQ1p/Tw3ZIa05Mrhk7k= =Ulbo -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 21 15:05:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13013 for ; Fri, 21 Feb 2003 15:05:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LKCJM17662 for mmusic-archive@odin.ietf.org; Fri, 21 Feb 2003 15:12:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKCJp17659 for ; Fri, 21 Feb 2003 15:12:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12995 for ; Fri, 21 Feb 2003 15:04:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKC4p17645; Fri, 21 Feb 2003 15:12:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKBvp17615 for ; Fri, 21 Feb 2003 15:11:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12989 for ; Fri, 21 Feb 2003 15:04:15 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1LK84KV018102; Fri, 21 Feb 2003 21:08:04 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4G3PLQ; Fri, 21 Feb 2003 21:08:04 +0100 Message-ID: <3E568724.7090509@era.ericsson.se> Date: Fri, 21 Feb 2003 21:08:04 +0100 X-Sybari-Trust: e720a624 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Aaron Colwell , mmusic@ietf.org Subject: Re: [MMUSIC] Relative URLs in RTP-Info field References: <20030221200121.GB14792@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Marshall wrote: >Based on the RTSP spec and a few private emails, I think the correct >answer >here is that the server is in error (is this what you meant to say, >Magnus?) > Yes, you are correct. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 24 10:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16936 for ; Mon, 24 Feb 2003 10:36:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OFicB01105 for mmusic-archive@odin.ietf.org; Mon, 24 Feb 2003 10:44:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFicp01100 for ; Mon, 24 Feb 2003 10:44:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16931 for ; Mon, 24 Feb 2003 10:35:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFiSp01090; Mon, 24 Feb 2003 10:44:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFfcp00981 for ; Mon, 24 Feb 2003 10:41:38 -0500 Received: from petasus.ch.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16859 for ; Mon, 24 Feb 2003 10:32:31 -0500 (EST) Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h1OFaia03370 for ; Mon, 24 Feb 2003 15:36:44 GMT Received: from azsmsx023.ch.intel.com ([10.2.248.28]) by azsmsxvs040.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2003022408362320418 ; Mon, 24 Feb 2003 08:36:23 -0700 Received: by azsmsx023.ch.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 08:32:04 -0700 Message-ID: <3D90571297ABD511957400508BF29C43043EA59F@pysmsx101.py.intel.com> From: "Miao, Kai" To: "'Alan Johnston'" Cc: mmusic@ietf.org Date: Mon, 24 Feb 2003 08:36:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [MMUSIC] draft-johnston-mmusic-offer-answer-examples-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The following in this draft look unclear to me. Could someone clarify? Exampe 2.5. The "m=" line in the Answer does not match that in the Offer. Example 2.8. In the Answer, "c=" line and the second "m=" line appear to be out of order? Example 4.1. Same as above. Example 4.2. Why there is the port change in Bob's Counter-Answer? Example 4.3. The "m=" line in the Answer does not match that in the Offer. In addition, is it possible to add the following to this draft? 1) RFC2833 and audio under the same "m=" line and RFC2833 has a different packet interval (for example, 50ms)from audio. 2) Show how to negotiate Adaptive Encoding ("on the fly", RFC2198 redundancy, etc.)and asymmetric codecs 3) Answerer's rejection of Offer, etc. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Feb 24 13:37:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21942 for ; Mon, 24 Feb 2003 13:37:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OIkOV13927 for mmusic-archive@odin.ietf.org; Mon, 24 Feb 2003 13:46:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIkOp13924 for ; Mon, 24 Feb 2003 13:46:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21935 for ; Mon, 24 Feb 2003 13:37:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIkHp13915; Mon, 24 Feb 2003 13:46:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIjJp13884 for ; Mon, 24 Feb 2003 13:45:19 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21922 for ; Mon, 24 Feb 2003 13:36:09 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h1OIe2B28461 for ; Mon, 24 Feb 2003 10:40:02 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 10:40:02 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7826@MISTY> From: Thomas Zeng To: mmusic@ietf.org Date: Mon, 24 Feb 2003 10:40:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Subject: [MMUSIC] Minutes RTSP Teleconf Feb 19, 2003 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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 mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Feb 25 06:49:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25232 for ; Tue, 25 Feb 2003 06:49:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBwoO21480 for mmusic-archive@odin.ietf.org; Tue, 25 Feb 2003 06:58:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBwop21477 for ; Tue, 25 Feb 2003 06:58:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25220 for ; Tue, 25 Feb 2003 06:49:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBwgp21463; Tue, 25 Feb 2003 06:58:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBtlp21272 for ; Tue, 25 Feb 2003 06:55:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25001; Tue, 25 Feb 2003 06:46:18 -0500 (EST) Message-Id: <200302251146.GAA25001@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Feb 2003 06:46:18 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : How to make Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls Author(s) : M. Westerlund Filename : draft-ietf-mmusic-rtsp-nat-00.txt Pages : 18 Date : 2003-2-24 This document describes four different types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations that exist is given. Further a description on how RTSP relates to firewalls are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rtsp-nat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-24142535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24142535.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 05:43:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00463 for ; Wed, 26 Feb 2003 05:43:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QArJ529885 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 05:53:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QArJp29882 for ; Wed, 26 Feb 2003 05:53:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00448 for ; Wed, 26 Feb 2003 05:43:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QArCp29870; Wed, 26 Feb 2003 05:53:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAqmp29829 for ; Wed, 26 Feb 2003 05:52:48 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00430 for ; Wed, 26 Feb 2003 05:42:48 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl4.philips.com (Postfix) with ESMTP id 64030A450B; Wed, 26 Feb 2003 11:46:42 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA03745; Wed, 26 Feb 2003 11:46:41 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA28184; Wed, 26 Feb 2003 11:46:40 +0100 (MET) To: magnus.westerlund@era.ericsson.se, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Feb 2003 11:40:04 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 26/02/2003 11:47:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, First bravo for this draft, it is a very useful document. I have a few comments, mostly about STUN (you know I am a STUN fan!) I note that in the STUN section you write: " To be able to use STUN to traverse symmetric NATs the STUN server needs to be co-located with the streaming server media distribution ports." This is true and it is a very interresting feature indeed, but then when you had the reader say "ahah!" and start to get really interrested you cold shower it with: "This creates an unclear demultiplexing point within the server. As this will create implementations difficulties and possibly security problems this SHOULD NOT be done." I think that a "should not" is really too strong here if it is an implementation issue, co-locating is not in itself a big issue for exemple a lot of RTSP servers are also HTTP servers right? (the "possible security problems" would have to be compared with the alternative solutions!...) ************** BTW in the Symetric RTP section you write: "It has the advantage of working for all types of NATs. However it requires server modifications." Therefore I conclude that there is no difference in terms of implementation between STUN and symetric RTP since in both case you need to change the RTSP server, and in a similar fashion! Also you write in the same section: " 1. The client knows or has determined by the use of STUN that it is located behind a NAT. It may also determined the type of NAT it is behind." So If one wants to use Symetric RTP one will have to implement STUN _anyway_ ! For implementers the advantages of symetric RTP are therefore difficult to see ? and then the reason why, by comparison, would co-located-STUN get a "SHOULD NOT" gets really difficult to understand! **************** Anyway I would propose to reword the section 3.1.3. as: "There are 2 ways to use STUN dependign if the STUN server is co-located with the streaming server media distribution ports or not. 3.1.3.1. STUN server outside Advantages: - Does not require RTSP server modifications, totally client implemented tool. Disadvantages: - Requires a STUN server deployed in the public address space. - Does only work well behind Cone NATs. Does not work with Symmetric NATs. 3.1.3.2. STUN server inside (co-located at the server media distribution ports) Advantages: - Works with all NATs including Symmetric NATs (however see the security section about sending RTP data at a different public IP address than the one of the RTSP client). Disadvantages: - Requires a modified RTSP server with co-located STUN server. ************************************** Last open issue about STUN: you describe a number of RTSP modifications for symetric RTP and none for STUN while there could be one very useful thing: In the response to DESCRIBE the server should indicate the UDP ports it is planning to use so that the client can immediately STUN toward these ports, and then the STUN server reply can be used for SETUP (saves a lot of round trips). The question is how can a server indicate its RTP _AND_ RTCP port numbers ? For example you can do that with a header in the RTSP response: C->S: DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 S->C: RTSP/1.0 200 OK CSeq: 1 Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057 Content-Type: application/sdp Content-Length: xxx v=0 o=- 2890844256 2890842807 IN IP4 172.16.2.93 s=RTSP Session etc... Also you can include this informationin SDP, which may be better since the client may get the SDP by some other means, right? Regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 09:02:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05448 for ; Wed, 26 Feb 2003 09:02:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QECKc11119 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 09:12:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QECKp11116 for ; Wed, 26 Feb 2003 09:12:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05415 for ; Wed, 26 Feb 2003 09:02:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QECEp11074; Wed, 26 Feb 2003 09:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QE9Up10741 for ; Wed, 26 Feb 2003 09:09:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04704; Wed, 26 Feb 2003 08:59:28 -0500 (EST) Message-Id: <200302261359.IAA04704@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 26 Feb 2003 08:59:28 -0500 Subject: [MMUSIC] I-D ACTION:draft-luoma-mmusic-img-metadata-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Media Guide Metadata Format Author(s) : J. Luoma Filename : draft-luoma-mmusic-img-metadata-00.txt Pages : 27 Date : 2003-2-25 This document defines the base metadata format for Internet Media Guides (IMGs), applicable to a wide variety of Internet hosts and communication links. IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. An IMG metadata model, semantics of the IMG media metadata entities, and an XML-based framing structure for IMG media metadata are defined. The aim is to reuse existing metadata standards for the IMG metadata format where possible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-luoma-mmusic-img-metadata-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-luoma-mmusic-img-metadata-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-luoma-mmusic-img-metadata-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-25155942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-luoma-mmusic-img-metadata-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-luoma-mmusic-img-metadata-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25155942.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 11:14:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14177 for ; Wed, 26 Feb 2003 11:14:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QGOGD22356 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 11:24:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGOGp22353 for ; Wed, 26 Feb 2003 11:24:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14171 for ; Wed, 26 Feb 2003 11:14:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGOAp22344; Wed, 26 Feb 2003 11:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGN2p22277 for ; Wed, 26 Feb 2003 11:23:02 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14136 for ; Wed, 26 Feb 2003 11:12:57 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1QGGkYH003781; Wed, 26 Feb 2003 11:16:48 -0500 (EST) Message-ID: <3E5CE86C.1020806@dynamicsoft.com> Date: Wed, 26 Feb 2003 11:16:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: magnus.westerlund@era.ericsson.se, mmusic@ietf.org Subject: Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have yet to read through the doc, but I wanted to let folks know that I have released an I-D which is very relevant to this problem: http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-00.txt it should appear in the archives shortly. Although its a sipping draft, its applicable to anything that follows an offer/answer style of negotiation. One of the things in there is the usage of STUN over media ports (called STUN derived transport addresses). It talks about this demux issue, and describes how it can be done for RTP and more generally for any UDP protocol. As your note below indicates, sending STUN to the media port will obviate the need for symmetric RTP, and it works for non-RTP transports too. It is my preference to do that in order to have a single solution. The benefit of ICE is that it always ends up selecting the "best" connectivity between entities. In the case of the typical RTSP deployment, it would end up using connectivity learned by STUNning to the media ports on the server. However, ICE would allow for other connectivity models, such as cases where a user is in an enterprise that wishes to have a media relay on-path for all media (a turn server, for example). Thanks, Jonathan R. philippe.gentric@philips.com wrote: > Magnus, > > First bravo for this draft, it is a very useful document. > > I have a few comments, mostly about STUN > (you know I am a STUN fan!) > > I note that in the STUN section you write: > > " To be able to use STUN to traverse symmetric NATs the STUN server > needs to be co-located with the streaming server media distribution > ports." > > This is true and it is a very interresting feature indeed, > but then when you had the reader say "ahah!" and > start to get really interrested you cold shower it with: > > "This creates an unclear demultiplexing point within the > server. As this will create implementations difficulties and possibly > security problems this SHOULD NOT be done." > > I think that a "should not" is really too strong here if it is > an implementation issue, co-locating is not in itself > a big issue for exemple a lot of RTSP servers > are also HTTP servers right? > (the "possible security problems" would have to be compared > with the alternative solutions!...) > > ************** > > BTW in the Symetric RTP section you write: > > "It has the advantage of working for all types of NATs. However it requires server modifications." > > Therefore I conclude that there is no difference > in terms of implementation between STUN and symetric RTP > since in both case you need to change the RTSP server, > and in a similar fashion! > > Also you write in the same section: > > " 1. The client knows or has determined by the use of STUN that it is > located behind a NAT. It may also determined the type of NAT it > is behind." > > So If one wants to use Symetric RTP one will have to implement STUN _anyway_ ! > > For implementers the advantages of symetric RTP are therefore difficult to see ? > > and then the reason why, by comparison, would co-located-STUN get a "SHOULD NOT" gets > really difficult to understand! > > **************** > > Anyway I would propose to reword the section 3.1.3. as: > > > "There are 2 ways to use STUN dependign if the STUN server > is co-located with the streaming server media distribution ports or not. > > 3.1.3.1. STUN server outside > > Advantages: > > - Does not require RTSP server modifications, totally client > implemented tool. > > Disadvantages: > > - Requires a STUN server deployed in the public address space. > - Does only work well behind Cone NATs. Does not work with > Symmetric NATs. > > 3.1.3.2. STUN server inside (co-located at the server media distribution > ports) > > Advantages: > > - Works with all NATs including Symmetric NATs (however see the security section about sending RTP > data at a different public IP address than the one of the RTSP client). > > Disadvantages: > > - Requires a modified RTSP server with co-located STUN server. > > ************************************** > > Last open issue about STUN: > > you describe a number of RTSP modifications for symetric RTP > and none for STUN while there could be one very useful thing: > > In the response to DESCRIBE the server should indicate > the UDP ports it is planning to use so that the client can immediately > STUN toward these ports, and then the STUN server reply can > be used for SETUP (saves a lot of round trips). > > The question is how can a server indicate its > RTP _AND_ RTCP port numbers ? > > For example you can do that with a header in the RTSP response: > > > C->S: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057 > Content-Type: application/sdp > Content-Length: xxx > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > etc... > > Also you can include this informationin SDP, > which may be better since the client may get the SDP > by some other means, right? > > > Regards, > > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 12:14:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16518 for ; Wed, 26 Feb 2003 12:14:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QHOHM27544 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 12:24:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHOHp27541 for ; Wed, 26 Feb 2003 12:24:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16495 for ; Wed, 26 Feb 2003 12:14:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHOAp27533; Wed, 26 Feb 2003 12:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHN5p27481 for ; Wed, 26 Feb 2003 12:23:05 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16427 for ; Wed, 26 Feb 2003 12:12:58 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAX008BCEO1RM@firewall.wcom.com> for mmusic@ietf.org; Wed, 26 Feb 2003 17:16:49 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAX00D01ENZUH@pmismtp01.wcomnet.com>; Wed, 26 Feb 2003 17:16:49 +0000 (GMT) Received: from ajohnston.wcom.com ([166.50.100.189]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAX00D5VENYLW@pmismtp01.wcomnet.com>; Wed, 26 Feb 2003 17:16:48 +0000 (GMT) Date: Wed, 26 Feb 2003 11:16:08 -0600 From: Alan Johnston Subject: Re: [MMUSIC] draft-johnston-mmusic-offer-answer-examples-00.txt In-reply-to: <3D90571297ABD511957400508BF29C43043EA59F@pysmsx101.py.inte l.com> X-Sender: Alan.Johnston@pop.mcit.com To: "Miao, Kai" Cc: mmusic@ietf.org, Robert Sparks Message-id: <5.1.1.6.0.20030226105255.01c5d660@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Kai, Thanks for your detailed reading and comments on the draft. See mine below. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 08:36 AM 2/24/2003 -0700, Miao, Kai wrote: >The following in this draft look unclear to me. Could someone clarify? > > >Exampe 2.5. The "m=" line in the Answer does not match that in the Offer. I don't see a problem with the m= line, but there are two a= lines that are: "a=rtpmap:0 PCMU/8000" that should be "a=rtpmap:97 iLBC" >Example 2.8. In the Answer, "c=" line and the second "m=" line appear to be >out of order? Yes - in this example, the second m= line should be swapped with the c= line. >Example 4.1. Same as above. Right as well. >Example 4.2. Why there is the port change in Bob's Counter-Answer? A port change can happen at any time. However, in this example, we mixed the port numbers of the offer and the answer and will fix this. >Example 4.3. The "m=" line in the Answer does not match that in the Offer. This has the same problem as example 2.5. >In addition, is it possible to add the following to this draft? > >1) RFC2833 and audio under the same "m=" line and RFC2833 has a different >packet interval (for example, 50ms)from audio. > >2) Show how to negotiate Adaptive Encoding ("on the fly", RFC2198 >redundancy, etc.)and asymmetric codecs If you send us a example of each we'll take a look and consider. >3) Answerer's rejection of Offer, etc. >_ There are some examples of declines media streams such as example 2.6 Is there something particular you are after? >______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 12:54:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17920 for ; Wed, 26 Feb 2003 12:54:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QI4E529869 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 13:04:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI4Ep29866 for ; Wed, 26 Feb 2003 13:04:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17871 for ; Wed, 26 Feb 2003 12:54:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI45p29839; Wed, 26 Feb 2003 13:04:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHwxp29660 for ; Wed, 26 Feb 2003 12:58:59 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17694 for ; Wed, 26 Feb 2003 12:48:50 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18o5jR-0001cu-00; Wed, 26 Feb 2003 09:52:37 -0800 Date: Wed, 26 Feb 2003 09:52:37 -0800 From: Tom Marshall To: philippe.gentric@philips.com Cc: magnus.westerlund@era.ericsson.se, mmusic@ietf.org Subject: Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt Message-ID: <20030226175237.GA6178@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 26, 2003 at 11:40:04AM +0100, philippe.gentric@philips.com wrot= e: >=20 > Magnus, >=20 > First bravo for this draft, it is a very useful document. >=20 > I have a few comments, mostly about STUN > (you know I am a STUN fan!) >=20 > I note that in the STUN section you write: >=20 > " To be able to use STUN to traverse symmetric NATs the STUN server > needs to be co-located with the streaming server media distribution > ports." >=20 > This is true and it is a very interresting feature indeed, > but then when you had the reader say "ahah!" and > start to get really interrested you cold shower it with: >=20 > "This creates an unclear demultiplexing point within the > server. As this will create implementations difficulties and possibly > security problems this SHOULD NOT be done." >=20 > I think that a "should not" is really too strong here if it is > an implementation issue, co-locating is not in itself > a big issue for exemple a lot of RTSP servers > are also HTTP servers right? > (the "possible security problems" would have to be compared > with the alternative solutions!...) It seems to me that an RTSP server which also does STUN is functionally equivalent to Symmetric RTP. So why bother to implement STUN in this case? > BTW in the Symetric RTP section you write: >=20 > "It has the advantage of working for all types of NATs. However it requir= es server modifications." >=20 > Therefore I conclude that there is no difference > in terms of implementation between STUN and symetric RTP > since in both case you need to change the RTSP server, > and in a similar fashion! I see two big differences: 1. Timing. In STUN, the client presumedly contacts the STUN server and receives the answer for its client_port mapping before sending the SETUP request (most likely introducing an extra round-trip latency). 2. Protocol. In STUN, a separate non-RTP protocol is used. The server must "demultiplex" the packets by using heuristics to determine if the incoming packet is STUN or RTP. While this may be possible due to the specific differences between STUN and RTP, it is not a good idea in general. > Also you write in the same section: >=20 > " 1. The client knows or has determined by the use of STUN that it is > located behind a NAT. It may also determined the type of NAT it > is behind." >=20 > So If one wants to use Symetric RTP one will have to implement STUN _anyw= ay_ ! I think the wording is incorrect here. The client does not need to know that it is behind a nat to use Symmetric RTP. It simply uses it and the server determines whether it needs to adjust its destination. > you describe a number of RTSP modifications for symetric RTP > and none for STUN while there could be one very useful thing: >=20 > In the response to DESCRIBE the server should indicate > the UDP ports it is planning to use so that the client can immediately > STUN toward these ports, and then the STUN server reply can > be used for SETUP (saves a lot of round trips). >=20 > The question is how can a server indicate its > RTP _AND_ RTCP port numbers ? >=20 > For example you can do that with a header in the RTSP response: >=20 >=20 > C->S: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 1 > Transport: RTP/AVP;server-rtp-port=3D4056;server-rtcp-port=3D4= 057 > Content-Type: application/sdp > Content-Length: xxx >=20 > v=3D0 > o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 > s=3DRTSP Session > etc... Firstly, I assume that the case where a server is behind a NAT is rare.=20 NATs are primarily for clients. If someone sets up an RTSP server behind a NAT and forwards port 554 to it, they should also forward UDP traffic to it= .=20 [My personal opinion: if an administrator is too afraid to handle those nasty unclean UDP packets, they shouldn't be running a server. Relying on the connection oriented nature of TCP for security is surely folly. But passing the buck by requiring someone else "take the security hit" is simply not acceptable and we should not be supporting this scenario at all.] Secondly, you are correct that there is no way to specify non-contiguous transport ports in 2326. The current agreement for 2326bis is to use the existing transport tokens with the syntax m/n to indicate an arbitrary list of ports. --=20 Coding is easy; All you do is sit staring at a terminal until the drops of blood form on your forehead. -- Anonymous --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XP7lqznSmcYu2m8RAur3AJ9wUAxfBrXt/fEW4CQP1v77lO21qwCfTPFJ N/MiL0tbC75WkwhPI7CsVRY= =q8nt -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 13:30:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19212 for ; Wed, 26 Feb 2003 13:30:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QIeTd00758 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 13:40:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QIeTp00755 for ; Wed, 26 Feb 2003 13:40:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19191 for ; Wed, 26 Feb 2003 13:30:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QIeKp00739; Wed, 26 Feb 2003 13:40:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QId2p00673 for ; Wed, 26 Feb 2003 13:39:03 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19115 for ; Wed, 26 Feb 2003 13:28:53 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl6.philips.com (Postfix) with ESMTP id C9CD1A5006; Wed, 26 Feb 2003 19:32:48 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA06847; Wed, 26 Feb 2003 19:32:48 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA06520; Wed, 26 Feb 2003 19:32:47 +0100 (MET) To: Tom Marshall Cc: magnus.westerlund@era.ericsson.se, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 26 Feb 2003 19:26:15 +0100 Subject: Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 26/02/2003 19:33:49 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=CEBBE64ADFF01FD28f9e8a93df938690918cCEBBE64ADFF01FD2" Content-Disposition: inline Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --0__=CEBBE64ADFF01FD28f9e8a93df938690918cCEBBE64ADFF01FD2 Content-type: text/plain; charset=us-ascii Tom you wrote: >Firstly, I assume that the case where a server is behind a NAT is rare. >NATs are primarily for clients. I dont see how the "localization" of the NAT makes any difference from the end-to-end point of view of having RTSP clients and servers ? [BTWwhat I am seeing (now and not improoving in any future) is a lot of NATs everywhere ! i.e. several NATs between a server and a client ! actually it was told that IPV6 deployement, which should solve the addressing issue(!?) can only happen progressively and that IPV6/IPV4 realms will be effectively linked using ...NATs ! arg! getting pessimistic ?-] > [My personal opinion: if an administrator is too afraid > to handle those nasty unclean UDP packets, > they shouldn't be running a server. yes ... I used to think that too... but I discovered that often the guy who wants to deploy the RTSP service only vaguely knows how to possibly get in contact with the guys running the (first) NAT :-! these are different jobs, typically different corporations and unfortunately they usually have so different priorities/agendas that they have trouble speaking together... regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: magnus.westerlund@era.ericsson.se mmusic@ietf.org Subject: Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt Tom Marshall Classification: 26/02/2003 18:52 On Wed, Feb 26, 2003 at 11:40:04AM +0100, philippe.gentric@philips.com wrote: > > Magnus, > > First bravo for this draft, it is a very useful document. > > I have a few comments, mostly about STUN > (you know I am a STUN fan!) > > I note that in the STUN section you write: > > " To be able to use STUN to traverse symmetric NATs the STUN server > needs to be co-located with the streaming server media distribution > ports." > > This is true and it is a very interresting feature indeed, > but then when you had the reader say "ahah!" and > start to get really interrested you cold shower it with: > > "This creates an unclear demultiplexing point within the > server. As this will create implementations difficulties and possibly > security problems this SHOULD NOT be done." > > I think that a "should not" is really too strong here if it is > an implementation issue, co-locating is not in itself > a big issue for exemple a lot of RTSP servers > are also HTTP servers right? > (the "possible security problems" would have to be compared > with the alternative solutions!...) It seems to me that an RTSP server which also does STUN is functionally equivalent to Symmetric RTP. So why bother to implement STUN in this case? > BTW in the Symetric RTP section you write: > > "It has the advantage of working for all types of NATs. However it requires server modifications." > > Therefore I conclude that there is no difference > in terms of implementation between STUN and symetric RTP > since in both case you need to change the RTSP server, > and in a similar fashion! I see two big differences: 1. Timing. In STUN, the client presumedly contacts the STUN server and receives the answer for its client_port mapping before sending the SETUP request (most likely introducing an extra round-trip latency). 2. Protocol. In STUN, a separate non-RTP protocol is used. The server must "demultiplex" the packets by using heuristics to determine if the incoming packet is STUN or RTP. While this may be possible due to the specific differences between STUN and RTP, it is not a good idea in general. > Also you write in the same section: > > " 1. The client knows or has determined by the use of STUN that it is > located behind a NAT. It may also determined the type of NAT it > is behind." > > So If one wants to use Symetric RTP one will have to implement STUN _anyway_ ! I think the wording is incorrect here. The client does not need to know that it is behind a nat to use Symmetric RTP. It simply uses it and the server determines whether it needs to adjust its destination. > you describe a number of RTSP modifications for symetric RTP > and none for STUN while there could be one very useful thing: > > In the response to DESCRIBE the server should indicate > the UDP ports it is planning to use so that the client can immediately > STUN toward these ports, and then the STUN server reply can > be used for SETUP (saves a lot of round trips). > > The question is how can a server indicate its > RTP _AND_ RTCP port numbers ? > > For example you can do that with a header in the RTSP response: > > > C->S: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057 > Content-Type: application/sdp > Content-Length: xxx > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > etc... Firstly, I assume that the case where a server is behind a NAT is rare. NATs are primarily for clients. If someone sets up an RTSP server behind a NAT and forwards port 554 to it, they should also forward UDP traffic to it. [My personal opinion: if an administrator is too afraid to handle those nasty unclean UDP packets, they shouldn't be running a server. Relying on the connection oriented nature of TCP for security is surely folly. But passing the buck by requiring someone else "take the security hit" is simply not acceptable and we should not be supporting this scenario at all.] Secondly, you are correct that there is no way to specify non-contiguous transport ports in 2326. The current agreement for 2326bis is to use the existing transport tokens with the syntax m/n to indicate an arbitrary list of ports. -- Coding is easy; All you do is sit staring at a terminal until the drops of blood form on your forehead. -- Anonymous (See attached file: att5k12c.dat) --0__=CEBBE64ADFF01FD28f9e8a93df938690918cCEBBE64ADFF01FD2 Content-type: application/octet-stream; name="att5k12c.dat" Content-Disposition: attachment; filename="att5k12c.dat" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMCAoR05V L0xpbnV4KQ0KDQppRDhEQlFFK1hQN2xxem5TbWNZdTJtOFJBdXIzQUo5d1VBeGZCclh0L2ZFVzRD UVAxdjc3bE8yMXF3Q2ZUUEZKDQpOL01pTDB0YkM3NVdrd2hQSTdDc1ZSWT0NCj1xOG50DQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --0__=CEBBE64ADFF01FD28f9e8a93df938690918cCEBBE64ADFF01FD2-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Feb 26 15:05:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22132 for ; Wed, 26 Feb 2003 15:05:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QKEdd06868 for mmusic-archive@odin.ietf.org; Wed, 26 Feb 2003 15:14:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKEdp06865 for ; Wed, 26 Feb 2003 15:14:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22113 for ; Wed, 26 Feb 2003 15:04:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKENp06857; Wed, 26 Feb 2003 15:14:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKDup06839 for ; Wed, 26 Feb 2003 15:13:56 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22109 for ; Wed, 26 Feb 2003 15:03:46 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18o7q5-0001p9-00; Wed, 26 Feb 2003 12:07:37 -0800 Date: Wed, 26 Feb 2003 12:07:37 -0800 From: Tom Marshall To: philippe.gentric@philips.com Cc: magnus.westerlund@era.ericsson.se, mmusic@ietf.org Subject: Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt Message-ID: <20030226200737.GB6385@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 26, 2003 at 07:26:15PM +0100, philippe.gentric@philips.com wrot= e: > Tom you wrote: >=20 > >Firstly, I assume that the case where a server is behind a NAT is rare. > >NATs are primarily for clients. >=20 >=20 > I dont see how the "localization" of the NAT > makes any difference from the end-to-end point of view > of having RTSP clients and servers ? It makes little difference in the specification, but it a huge difference in the implementation. If it's possible for the server to be behind a NAT that doesn't forward UDP packets, it would need to use NAT traversal to inform the client of its RTP ports. We know that STUN does not work for symmetric NATs. We know that NATs as implemented in most common Unix routers are symmetric. Therefore, I am guessing that most NATted servers will be behind symmetric NATs and server-to-client STUN will not work anyway. This is not to say that we should discourage its use, of course. I am only saying that NAT should be viewed primarily as a client-side phenomenon.=20 Implementors are free to implement STUN and/or Symmetric RTP on both client and server and have a product that works when both are behind NAT. With careful implementation, a product could even work when both ends are behind symmetric NATs. See http://www.peercast.org/ for one possible application of server side NAT traversal. > [BTWwhat I am seeing (now and not improoving in any future) > is a lot of NATs everywhere ! > i.e. several NATs between a server and a client ! Absolutely. There are two between my home machines and the net. > actually it was told that IPV6 deployement, > which should solve the addressing issue(!?) > can only happen progressively and that > IPV6/IPV4 realms will be effectively linked using ...NATs ! > arg! getting pessimistic ?-] IPv6 is amazingly adept at traversing IPv4 NAT. I am running an IPv6 tunnel to my home machines. You can contact them via IPv6 anywhere in the world even though they are behind two levels of IPv4 NAT. > > [My personal opinion: if an administrator is too afraid > > to handle those nasty unclean UDP packets, > > they shouldn't be running a server. >=20 >=20 > yes ... I used to think that too... > but I discovered that often the guy who wants to deploy the RTSP service > only vaguely knows how to possibly get in contact with the guys running t= he (first) NAT :-! > these are different jobs, typically different corporations and > unfortunately they usually have so different priorities/agendas > that they have trouble speaking together... The sysadmin vs. netadmin argument holds no water. We should NOT be providing a means to deliberately break administrative control. (It's redundant anyway, see RFC 3093). NAT traversal is intended to work around the limitations in common NAT implementations. If it happens to work for the server-to-client direction, well, that's a coincidence. It might even be seen as a consequence of good design. But it is not our intent to deliberately undermine administrative control. --=20 A revised schedule is to business what a new season is to an athlete or a new canvas to an artist. -- Norman Augustine --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XR6JqznSmcYu2m8RAiEOAJ9uYgeScSANaFKS35fTGAY8uGmhzQCfYEaF lYxYQgm8K8sRYnhojK/9cuw= =byjH -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 27 07:04:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26197 for ; Thu, 27 Feb 2003 07:04:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCEOF12014 for mmusic-archive@odin.ietf.org; Thu, 27 Feb 2003 07:14:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCENp12011 for ; Thu, 27 Feb 2003 07:14:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26184 for ; Thu, 27 Feb 2003 07:03:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCEFp11998; Thu, 27 Feb 2003 07:14:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCDop11952 for ; Thu, 27 Feb 2003 07:13:50 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26171 for ; Thu, 27 Feb 2003 07:03:19 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id 7980D91C68; Thu, 27 Feb 2003 13:07:13 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA00978; Thu, 27 Feb 2003 13:07:12 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA22005; Thu, 27 Feb 2003 13:07:11 +0100 (MET) To: Tom Marshall Cc: magnus.westerlund@era.ericsson.se, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 27 Feb 2003 13:00:30 +0100 Subject: Re: [MMUSIC] RE: Symmetric NAT traversal is a key feature. (was: draft-ietf-mmusic-rtsp-nat-00.txt) X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 27/02/2003 13:08:13 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBE649DFA1FA4B8f9e8a93df938690918c4EBBE649DFA1FA4B" Content-Disposition: inline Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --0__=4EBBE649DFA1FA4B8f9e8a93df938690918c4EBBE649DFA1FA4B Content-type: text/plain; charset=us-ascii Tom you write: > We know that STUN does not work for symmetric NATs. STUN works for symetric NAT if you run the STUN server co-located with the RTSP server, and that is the key thing: a solution that works for *all* NATs. As Jonathan coined it very nicely in draft-rosenberg-sipping-ice-00.txt: "The need to run STUN on the same transport address as the media stream represents the "ugliest" piece of ICE. However, it is an essential part of the story. By sending STUN requests to the very same place media is sent, any bindings learned through STUN will be useful even when communicating through symmetric NATs. This results in a substantial increase in the scope of applicability of STUN, in terms of cases where it can provide connectivity. In that sense, the usage of STUN here is radically different than the usage models outlined in [13], where STUN is generally useless for dealing with symmetric NAT." >The sysadmin vs. netadmin argument holds no water. We should NOT be >providing a means to deliberately break administrative control. (It's >redundant anyway, see RFC 3093). > .... >But it is not our intent to deliberately undermine administrative >control. ha no! not that! you cannot 3093'ze me on this because 3093 does not apply a single bit here. (I feel in the position to debate about 3093 since the London meeting!-) the plan is not to undermine "administrative control", because and *that* is the point: you *cannot* "undermine" it! when the adminitrator wants to block RTP traffic he will, because he can and it is *very* easy!!!!!! my original point was that: (A)in order of priority for operators "NAT comes first" and then "someone wants to fix the RTP problem" specifically we are told: "ok, there is this NAT, and we want to deploy VOD using RTSP, what do you propose ? " (B)Telling them to start a procedure (internal or external or both!) that would lead to transforming that NAT is not a good idea, *especially* since you cannot guarantee it will work in all cases! But we will have to influence "them" in at least one respect, it must be documented somewhere that: "Symmetric NATs SHOULD be configured so that a given RTP client is attributed the same public IP address as the corresponding RTSP client" (if there are NAT implementors online can they please comment on that? it does not look like a very difficult thing to implement ?) Because otherwise whenever the symmetric NAT will allocate different IP addresses the RTSP server will *have to* deny the service for DDOS prevention. >NAT traversal is intended to work around the limitations in common NAT >implementations. not enough for me, I want a solution for all NATs, forever. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: magnus.westerlund@era.ericsson.se mmusic@ietf.org Subject: Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt Tom Marshall Classification: 26/02/2003 21:07 On Wed, Feb 26, 2003 at 07:26:15PM +0100, philippe.gentric@philips.com wrote: > Tom you wrote: > > >Firstly, I assume that the case where a server is behind a NAT is rare. > >NATs are primarily for clients. > > > I dont see how the "localization" of the NAT > makes any difference from the end-to-end point of view > of having RTSP clients and servers ? It makes little difference in the specification, but it a huge difference in the implementation. If it's possible for the server to be behind a NAT that doesn't forward UDP packets, it would need to use NAT traversal to inform the client of its RTP ports. We know that STUN does not work for symmetric NATs. We know that NATs as implemented in most common Unix routers are symmetric. Therefore, I am guessing that most NATted servers will be behind symmetric NATs and server-to-client STUN will not work anyway. This is not to say that we should discourage its use, of course. I am only saying that NAT should be viewed primarily as a client-side phenomenon. Implementors are free to implement STUN and/or Symmetric RTP on both client and server and have a product that works when both are behind NAT. With careful implementation, a product could even work when both ends are behind symmetric NATs. See http://www.peercast.org/ for one possible application of server side NAT traversal. > [BTWwhat I am seeing (now and not improoving in any future) > is a lot of NATs everywhere ! > i.e. several NATs between a server and a client ! Absolutely. There are two between my home machines and the net. > actually it was told that IPV6 deployement, > which should solve the addressing issue(!?) > can only happen progressively and that > IPV6/IPV4 realms will be effectively linked using ...NATs ! > arg! getting pessimistic ?-] IPv6 is amazingly adept at traversing IPv4 NAT. I am running an IPv6 tunnel to my home machines. You can contact them via IPv6 anywhere in the world even though they are behind two levels of IPv4 NAT. > > [My personal opinion: if an administrator is too afraid > > to handle those nasty unclean UDP packets, > > they shouldn't be running a server. > > > yes ... I used to think that too... > but I discovered that often the guy who wants to deploy the RTSP service > only vaguely knows how to possibly get in contact with the guys running the (first) NAT :-! > these are different jobs, typically different corporations and > unfortunately they usually have so different priorities/agendas > that they have trouble speaking together... The sysadmin vs. netadmin argument holds no water. We should NOT be providing a means to deliberately break administrative control. (It's redundant anyway, see RFC 3093). NAT traversal is intended to work around the limitations in common NAT implementations. If it happens to work for the server-to-client direction, well, that's a coincidence. It might even be seen as a consequence of good design. But it is not our intent to deliberately undermine administrative control. -- A revised schedule is to business what a new season is to an athlete or a new canvas to an artist. -- Norman Augustine (See attached file: att29tr3.dat) --0__=4EBBE649DFA1FA4B8f9e8a93df938690918c4EBBE649DFA1FA4B Content-type: application/octet-stream; name="att29tr3.dat" Content-Disposition: attachment; filename="att29tr3.dat" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMCAoR05V L0xpbnV4KQ0KDQppRDhEQlFFK1hSNkpxem5TbWNZdTJtOFJBaUVPQUo5dVlnZVNjU0FOYUZLUzM1 ZlRHQVk4dUdtaHpRQ2ZZRWFGDQpsWXhZUWdtOEs4c1JZbmhvaksvOWN1dz0NCj1ieWpIDQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --0__=4EBBE649DFA1FA4B8f9e8a93df938690918c4EBBE649DFA1FA4B-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 27 07:47:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28072 for ; Thu, 27 Feb 2003 07:47:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCv8h14832 for mmusic-archive@odin.ietf.org; Thu, 27 Feb 2003 07:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCv8p14829 for ; Thu, 27 Feb 2003 07:57:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28045 for ; Thu, 27 Feb 2003 07:46:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCv4p14818; Thu, 27 Feb 2003 07:57:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCswp14598 for ; Thu, 27 Feb 2003 07:54:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27591; Thu, 27 Feb 2003 07:44:27 -0500 (EST) Message-Id: <200302271244.HAA27591@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:44:27 -0500 Subject: [MMUSIC] I-D ACTION:draft-nomura-mmusic-img-requirements-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol Requirements for Internet Media Guides Author(s) : Y. Nomura, H. Schulzrinne Filename : draft-nomura-mmusic-img-requirements-00.txt Pages : 7 Date : 2003-2-26 This memo specifies requirements for a protocol for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. The requirements details general protocol operations and description formats transmitted by an uni- or bi- directional transport based on the IMG framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nomura-mmusic-img-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nomura-mmusic-img-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nomura-mmusic-img-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nomura-mmusic-img-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nomura-mmusic-img-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160745.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Feb 27 12:24:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12655 for ; Thu, 27 Feb 2003 12:24:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RHYRr05632 for mmusic-archive@odin.ietf.org; Thu, 27 Feb 2003 12:34:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHYRp05629 for ; Thu, 27 Feb 2003 12:34:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12624 for ; Thu, 27 Feb 2003 12:23:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHY8p05612; Thu, 27 Feb 2003 12:34:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHXXp05575 for ; Thu, 27 Feb 2003 12:33:33 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12598 for ; Thu, 27 Feb 2003 12:22:57 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 18oRo2-0002ga-00; Thu, 27 Feb 2003 09:26:50 -0800 Date: Thu, 27 Feb 2003 09:26:50 -0800 From: Tom Marshall To: philippe.gentric@philips.com Cc: magnus.westerlund@era.ericsson.se, mmusic@ietf.org Subject: Re: [MMUSIC] RE: Symmetric NAT traversal is a key feature. (was: draft-ietf-mmusic-rtsp-nat-00.txt) Message-ID: <20030227172650.GA10182@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >The sysadmin vs. netadmin argument holds no water. We should NOT be > >providing a means to deliberately break administrative control. (It's > >redundant anyway, see RFC 3093). > > > .... > >But it is not our intent to deliberately undermine administrative > >control. >=20 > ha no! not that! > you cannot 3093'ze me on this because > 3093 does not apply a single bit here. > (I feel in the position to debate about 3093 since the London meeting!-) >=20 > the plan is not to undermine "administrative control", > because and *that* is the point: you *cannot* "undermine" it! > when the adminitrator wants to block RTP traffic he will, > because he can and it is *very* easy!!!!!! Am I the only one here that reads the same argument for 3093? the plan is not to undermine "administrative control", because and *that* is the point: you *cannot* "undermine" it! when the adminitrator wants to block 3093 traffic he will, =20 because he can and it is *very* easy!!!!!! it's a simple matter of blocking the "TCP_*", "IP_*", "IP4_*", and "IP6_*" headers!!! > (A)in order of priority for operators "NAT comes first" and then > "someone wants to fix the RTP problem" specifically we are told: > "ok, there is this NAT, and we want to deploy > VOD using RTSP, what do you propose ? " > But we will have to influence "them" in at least one respect, > it must be documented somewhere that: >=20 > "Symmetric NATs SHOULD be configured so that a given RTP > client is attributed the same public IP address as the corresponding > RTSP client" I have yet to see an example where a client was assigned different public IP addresses for RTSP and RTP connections to the same server. Rumors keep flying that they exist so I'll assume they do. I like this recommendation -- it should always be the case anyway. If it's not, the NAT is being unreasonable. > (if there are NAT implementors online can they please comment on that? > it does not look like a very difficult thing to implement ?) Yes, please. Does someone run a NAT where a given (client_ip, server_ip) can be mapped to more than one nat_ip? > Because otherwise whenever the symmetric NAT will allocate different IP a= ddresses > the RTSP server will *have to* deny the service for DDOS prevention. I am wondering if you are equating "symmetric NAT" with a NAT that maps clients to multiple public addresses. My understanding is that symmetric NAT is a more strict case of general NAT= .=20 The difference is that a general NAT maps a given NAT port based on the pair (client_ip,client_port) and a symmetric NAT maps a given NAT port based on the 4-tuple (client_ip,client_port,server_ip,server_port). Am I mistaken? > >NAT traversal is intended to work around the limitations in common NAT > >implementations. >=20 > not enough for me, > I want a solution for all NATs, forever. I want world peace, too. And no more spam. And ... Seriously, there is no all-encompassing solution. Why not? Because NAT is the general name for a family of hacks with no formal specification or interoperability requirements. As soon as you design a solution that you think covers all NATs, someone will build a different NAT that breaks your solution. Symmetric RTP and multiplexed STUN/RTP are functionally equivalent for NAT traversal and they are the best solution you will find in the forseeable future. --=20 Any sufficiently advanced technology is indistinguishable from a rigged demo. -- Andy Finkel --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+XkpaqznSmcYu2m8RApFHAJ9pLRkMTIPlRDQJd3/g/nvEScvOmQCbBJI5 AOOcUP8NkduG0tEPs7jrudo= =F6as -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 05:25:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19557 for ; Fri, 28 Feb 2003 05:25:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAaCa14878 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 05:36:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAaBp14875 for ; Fri, 28 Feb 2003 05:36:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19539 for ; Fri, 28 Feb 2003 05:25:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAa6p14847; Fri, 28 Feb 2003 05:36:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAZRp14815 for ; Fri, 28 Feb 2003 05:35:27 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19511 for ; Fri, 28 Feb 2003 05:24:30 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SASPnS015235; Fri, 28 Feb 2003 11:28:25 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4H7KB4; Fri, 28 Feb 2003 11:28:25 +0100 Message-ID: <3E5F39C9.2050004@era.ericsson.se> Date: Fri, 28 Feb 2003 11:28:25 +0100 X-Sybari-Trust: 19f229c0 9ffcebbb 7a95d2f4 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: draft-ietf-mmusic-rtsp-nat-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Philippe, My comments below: philippe.gentric@philips.com wrote: >Magnus, > >First bravo for this draft, it is a very useful document. > >I have a few comments, mostly about STUN >(you know I am a STUN fan!) > >I note that in the STUN section you write: > >" To be able to use STUN to traverse symmetric NATs the STUN server > needs to be co-located with the streaming server media distribution > ports." > >This is true and it is a very interresting feature indeed, >but then when you had the reader say "ahah!" and >start to get really interrested you cold shower it with: > >"This creates an unclear demultiplexing point within the > server. As this will create implementations difficulties and possibly > security problems this SHOULD NOT be done." > >I think that a "should not" is really too strong here if it is >an implementation issue, co-locating is not in itself >a big issue for exemple a lot of RTSP servers >are also HTTP servers right? >(the "possible security problems" would have to be compared >with the alternative solutions!...) > > I think this is something we need to discuss further. My current view is that due to the lack of a well defined demultiplexing structure between media protocol and STUN on the servers ports makes STUN solutions for symmetric NATs a bad choice. As pointed out you need to compare the media protocols bit structure with STUN request. This is not safe operation. I do agree that RTP and RTCP seems to be reasonable safe to demultiplex, however it is impossible to know that all protocols media protocols will work. I also find your example with HTTP and RTSP a bad example. HTTP and RTSP are distinguished using the nice demultiplexing mechanism of ports. Normally HTTP request goes to port 80 while RTSP goes to port number 540. This is a well defined demultiplexing. >************** > >BTW in the Symetric RTP section you write: > >"It has the advantage of working for all types of NATs. However it requires server modifications." > >Therefore I conclude that there is no difference >in terms of implementation between STUN and symetric RTP >since in both case you need to change the RTSP server, >and in a similar fashion! > Yes, unless you can use STUN to find two port numbers that match the RTP rule of consecutive even and odd ports. Both solutions requires updates. However STUNs are less from a RTSP protocol perspective. > >Also you write in the same section: > >" 1. The client knows or has determined by the use of STUN that it is > located behind a NAT. It may also determined the type of NAT it > is behind." > >So If one wants to use Symetric RTP one will have to implement STUN _anyway_ ! > I need to clarify that this is OPTIONAL behavior that MAY improve the performance of the solution. >For implementers the advantages of symetric RTP are therefore difficult to see ? >and then the reason why, by comparison, would co-located-STUN get a "SHOULD NOT" gets >really difficult to understand! > > As explained before this is not a clean solution. >**************** > >Anyway I would propose to reword the section 3.1.3. as: > > >"There are 2 ways to use STUN dependign if the STUN server >is co-located with the streaming server media distribution ports or not. > >3.1.3.1. STUN server outside > > Advantages: > > - Does not require RTSP server modifications, totally client > implemented tool. > > Disadvantages: > > - Requires a STUN server deployed in the public address space. > - Does only work well behind Cone NATs. Does not work with > Symmetric NATs. > >3.1.3.2. STUN server inside (co-located at the server media distribution > ports) > > Advantages: > > - Works with all NATs including Symmetric NATs (however see the security section about sending RTP >data at a different public IP address than the one of the RTSP client). > > Disadvantages: > > - Requires a modified RTSP server with co-located STUN server. > > In the second case you forgot the disadvantage of not being guaranteed to be able to correctly distinguish media packets and STUN request. Another thing that it seems that I forgot being a disadvantage of STUN is that it does not work if the media mappings would get different IP addresses, either between each UDP stream or with the TCP connection. The reason is the restriction that RTSP must use to prevent DOS attacks. >************************************** > >Last open issue about STUN: > >you describe a number of RTSP modifications for symetric RTP >and none for STUN while there could be one very useful thing: > >In the response to DESCRIBE the server should indicate >the UDP ports it is planning to use so that the client can immediately >STUN toward these ports, and then the STUN server reply can >be used for SETUP (saves a lot of round trips). > >The question is how can a server indicate its >RTP _AND_ RTCP port numbers ? > >For example you can do that with a header in the RTSP response: > > > C->S: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057 > Content-Type: application/sdp > Content-Length: xxx > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > etc... > >Also you can include this informationin SDP, >which may be better since the client may get the SDP >by some other means, right? > > > Actually you can include this information in the SDP without any extra extensions is just the matter of defining the usage. The RTP port number can be located in its normal place on the m= line. The RTCP port can be set by the attribute defined by draft-ietf-mmusic-sdp4nat-03.txt. To make this in a good fashion the server should define a RTSP feature tag that indicates this functionality and that the server should provide the information when sending the DESCRIBE response. I think we need to further discuss the RTSP NAT traversal solutions and possible optimization. My draft was intended to be a common ground to discuss around. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 06:57:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21519 for ; Fri, 28 Feb 2003 06:57:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SC7VI20970 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 07:07:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SC7Up20967 for ; Fri, 28 Feb 2003 07:07:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21506 for ; Fri, 28 Feb 2003 06:56:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SC7Np20858; Fri, 28 Feb 2003 07:07:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SC6Op20168 for ; Fri, 28 Feb 2003 07:06:24 -0500 Received: from gw-nl4.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21491 for ; Fri, 28 Feb 2003 06:55:24 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl4.philips.com (Postfix) with ESMTP id A3A5FA488F; Fri, 28 Feb 2003 12:59:14 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA14501; Fri, 28 Feb 2003 12:59:13 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA10994; Fri, 28 Feb 2003 12:59:12 +0100 (MET) To: Tom Marshall Cc: magnus.westerlund@era.ericsson.se, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 28 Feb 2003 12:52:38 +0100 Subject: Re: [MMUSIC] RE: Symmetric NAT traversal is a key feature. (was: draft-ietf-mmusic-rtsp-nat-00.txt) X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 28/02/2003 13:00:14 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4EBBE648DFA480FB8f9e8a93df938690918c4EBBE648DFA480FB" Content-Disposition: inline Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --0__=4EBBE648DFA480FB8f9e8a93df938690918c4EBBE648DFA480FB Content-type: text/plain; charset=us-ascii Tom, no more 3093'zation please! my wife is getting worried she said I am speaking to myself at night and I keep on saying "non! non! pas la trente quatrevingt treize! pas la trente quatrevingt treize!" ;-) >> "Symmetric NATs SHOULD be configured so that a given RTP >> client is attributed the same public IP address as the corresponding >> RTSP client" > >I have yet to see an example where a client was assigned different public IP >addresses for RTSP and RTP connections to the same server. Rumors keep >flying that they exist so I'll assume they do. > >I like this recommendation -- it should always be the case anyway. If it's >not, the NAT is being unreasonable. > > (if there are NAT implementors online can they please comment on that? > it does not look like a very difficult thing to implement ?) > >Yes, please. Does someone run a NAT where a given (client_ip, server_ip) >can be mapped to more than one nat_ip? I think a lot of NATs are running on a single public IP address: it gives 60000+ ports to multiplex clients through which is already quite a bit...so we dont see it happen now. My concern is to get in trouble for larger deployements where the operator has many more public IP addresses because I suspect the "most simple" way to implement such NAT is to pick up the first free pair (public IP address, port number) and since de-allocation and allocation are stochastical then there is a fair chance that RTSP and RTP can be mapped on different public IP addresses.. >I am wondering if you are equating "symmetric NAT" with a NAT that maps >clients to multiple public addresses. I am equating "symmetric NAT" with a NAT that *may* maps clients to multiple public addresses. > >My understanding is that symmetric NAT is a more strict case of general NAT. >The difference is that a general NAT maps a given NAT port based on the pair >(client_ip,client_port) and a symmetric NAT maps a given NAT port based on >the 4-tuple (client_ip,client_port,server_ip,server_port). Am I mistaken? I dont know what you mean by "general NAT"? my reference for NAT typologie is the STUN draft? I think your 4-tuple is accurate for "symetric NAT" unless it is a 5-tuple including the protocol i.e. TCP vs UDP? regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: magnus.westerlund@era.ericsson.se mmusic@ietf.org Subject: Re: [MMUSIC] RE: Symmetric NAT traversal is a key feature. (was: Tom Marshall draft-ietf-mmusic-rtsp-nat-00.txt) Classification: 27/02/2003 18:26 > >The sysadmin vs. netadmin argument holds no water. We should NOT be > >providing a means to deliberately break administrative control. (It's > >redundant anyway, see RFC 3093). > > > .... > >But it is not our intent to deliberately undermine administrative > >control. > > ha no! not that! > you cannot 3093'ze me on this because > 3093 does not apply a single bit here. > (I feel in the position to debate about 3093 since the London meeting!-) > > the plan is not to undermine "administrative control", > because and *that* is the point: you *cannot* "undermine" it! > when the adminitrator wants to block RTP traffic he will, > because he can and it is *very* easy!!!!!! Am I the only one here that reads the same argument for 3093? the plan is not to undermine "administrative control", because and *that* is the point: you *cannot* "undermine" it! when the adminitrator wants to block 3093 traffic he will, because he can and it is *very* easy!!!!!! it's a simple matter of blocking the "TCP_*", "IP_*", "IP4_*", and "IP6_*" headers!!! > (A)in order of priority for operators "NAT comes first" and then > "someone wants to fix the RTP problem" specifically we are told: > "ok, there is this NAT, and we want to deploy > VOD using RTSP, what do you propose ? " > But we will have to influence "them" in at least one respect, > it must be documented somewhere that: > > "Symmetric NATs SHOULD be configured so that a given RTP > client is attributed the same public IP address as the corresponding > RTSP client" I have yet to see an example where a client was assigned different public IP addresses for RTSP and RTP connections to the same server. Rumors keep flying that they exist so I'll assume they do. I like this recommendation -- it should always be the case anyway. If it's not, the NAT is being unreasonable. > (if there are NAT implementors online can they please comment on that? > it does not look like a very difficult thing to implement ?) Yes, please. Does someone run a NAT where a given (client_ip, server_ip) can be mapped to more than one nat_ip? > Because otherwise whenever the symmetric NAT will allocate different IP addresses > the RTSP server will *have to* deny the service for DDOS prevention. I am wondering if you are equating "symmetric NAT" with a NAT that maps clients to multiple public addresses. My understanding is that symmetric NAT is a more strict case of general NAT. The difference is that a general NAT maps a given NAT port based on the pair (client_ip,client_port) and a symmetric NAT maps a given NAT port based on the 4-tuple (client_ip,client_port,server_ip,server_port). Am I mistaken? > >NAT traversal is intended to work around the limitations in common NAT > >implementations. > > not enough for me, > I want a solution for all NATs, forever. I want world peace, too. And no more spam. And ... Seriously, there is no all-encompassing solution. Why not? Because NAT is the general name for a family of hacks with no formal specification or interoperability requirements. As soon as you design a solution that you think covers all NATs, someone will build a different NAT that breaks your solution. Symmetric RTP and multiplexed STUN/RTP are functionally equivalent for NAT traversal and they are the best solution you will find in the forseeable future. -- Any sufficiently advanced technology is indistinguishable from a rigged demo. -- Andy Finkel (See attached file: attde3bo.dat) --0__=4EBBE648DFA480FB8f9e8a93df938690918c4EBBE648DFA480FB Content-type: application/octet-stream; name="attde3bo.dat" Content-Disposition: attachment; filename="attde3bo.dat" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMCAoR05V L0xpbnV4KQ0KDQppRDhEQlFFK1hrcGFxem5TbWNZdTJtOFJBcEZIQUo5cExSa01USVBsUkRRSmQz L2cvbnZFU2N2T21RQ2JCSkk1DQpBT09jVVA4TmtkdUcwdEVQczdqcnVkbz0NCj1GNmFzDQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --0__=4EBBE648DFA480FB8f9e8a93df938690918c4EBBE648DFA480FB-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 07:29:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23083 for ; Fri, 28 Feb 2003 07:29:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCeDt23364 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 07:40:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCeCp23358 for ; Fri, 28 Feb 2003 07:40:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23060 for ; Fri, 28 Feb 2003 07:29:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCe9p23338; Fri, 28 Feb 2003 07:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCZcp22235 for ; Fri, 28 Feb 2003 07:35:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22490; Fri, 28 Feb 2003 07:24:39 -0500 (EST) Message-Id: <200302281224.HAA22490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org, mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:24:39 -0500 Subject: [MMUSIC] I-D ACTION:draft-mahy-sipping-media-policy-control-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Media Policy Manipulation in the Conference Policy Control Protocol Author(s) : R. Mahy, N. Ismail Filename : draft-mahy-sipping-media-policy-control-00.txt Pages : 19 Date : 2003-2-27 The SIP conferencing framework defines a model for tightly-coupled conferencing in the Session Initiation Protocol (SIP), in which a Conference Policy Control Protocol is used to manipulate policies relevant to a specific conference, such as conference membership policy, authorization policy, and media policy. This document describes a logical model to describe media processing in a SIP conference. It also defines specific protocol semantics and a specific syntax to manipulate that model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sipping-media-policy-control-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mahy-sipping-media-policy-control-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mahy-sipping-media-policy-control-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sipping-media-policy-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sipping-media-policy-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132718.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 07:35:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23623 for ; Fri, 28 Feb 2003 07:35:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCjux23732 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 07:45:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCjup23729 for ; Fri, 28 Feb 2003 07:45:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23532 for ; Fri, 28 Feb 2003 07:34:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCjqp23719; Fri, 28 Feb 2003 07:45:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCbUp23062 for ; Fri, 28 Feb 2003 07:37:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22948; Fri, 28 Feb 2003 07:26:31 -0500 (EST) Message-Id: <200302281226.HAA22948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:26:31 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-01.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) Author(s) : M. Westerlund Filename : draft-ietf-mmusic-sdp-bwparam-01.txt Pages : 16 Date : 2003-2-27 The existing Session Description Protocol (SDP) bandwidth modifiers and their values include the bandwidth needed also for the transport and IP layers. When using SDP in protocols like Session Announcement Protocol (SAP), Session Initiation Protocol (SIP) and Real-Time Streaming Protocol (RTSP) and the involved hosts reside in networks running different IP versions, the interpretation of what type of lower layers that is included is not clear. This documents defines a bandwidth modifier that does not include transport overhead, instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the packet rate can then be used to calculate the real bit-rate over the actually used transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-bwparam-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27133034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-bwparam-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27133034.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 10:42:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01994 for ; Fri, 28 Feb 2003 10:42:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SFqeA05537 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 10:52:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFqep05534 for ; Fri, 28 Feb 2003 10:52:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01985 for ; Fri, 28 Feb 2003 10:41:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFqXp05524; Fri, 28 Feb 2003 10:52:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFpkp05479 for ; Fri, 28 Feb 2003 10:51:46 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01972; Fri, 28 Feb 2003 10:40:43 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl3.philips.com (Postfix) with ESMTP id E582F9202A; Fri, 28 Feb 2003 16:43:12 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA10262; Fri, 28 Feb 2003 16:42:59 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA11608; Fri, 28 Feb 2003 16:42:53 +0100 (MET) Subject: Re: [MMUSIC] Re: draft-ietf-mmusic-rtsp-nat-00.txt To: Magnus Westerlund Cc: mmusic@ietf.org, mmusic-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 28 Feb 2003 16:36:20 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 28/02/2003 16:43:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, I expect indeed that we will discuss this more especially during the SFO meeting and I agree your draft is an excellent basis! you write: >My current view is >that due to the lack of a well defined demultiplexing structure between >media protocol and STUN on the servers ports makes STUN solutions for >symmetric NATs a bad choice. As pointed out you need to compare the >media protocols bit structure with STUN request. This is not safe >operation. I do agree that RTP and RTCP seems to be reasonable safe to >demultiplex, however it is impossible to know that all protocols media >protocols will work. Well I dont know about other protocols but the use of STUN in the RTSP scenario is *extremely* safe: 1) your client sends and receives STUN on the UDP ports it has choosen for RTP and RTCP _but_ since this is *before* the SETUP there is *only* a STUN client behind these UDP ports, (the RTP/RTCP stack does not have to be initialized yet). And vice versa i.e. as soon as STUN completed you can stop the STUN client to start the RTP/RTCP session ! => so on the client side it is totally safe. 2) the server does NOT listen for incomming data on the RTP ports: there will be the STUN server listening behind these ports, nothing else => no possible collision of STUN with RTP on the server side 3) then the server needs to distinguish between RTCP RR and STUN on the RTCP port but the headers are _really_ different. for starters the first bit is different (1 for RTCP, 0 for STUN)! but let us imagine that a STUN packet (of an hypothetical future extended version!) will by chance match the first 32 bits of a paussible RTCP RR packet, then what is the probability of having the 32 bits SSRC (random, fixed per transaction) match the first 32 bits of the 128 STUn tID (random, changing every message) ? 2 to the power 64 ? etc ... I dont see how even the worse implementation can collide ? > As explained before this is not a clean solution. "Striving to better, oft we mar what's well." (William Shakespeare) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: mmusic@ietf.org Subject: [MMUSIC] Re: draft-ietf-mmusic-rtsp-nat-00.txt Magnus Westerlund Classification: Sent by: mmusic-admin@ietf.org 28/02/2003 11:28 Hi, Philippe, My comments below: philippe.gentric@philips.com wrote: >Magnus, > >First bravo for this draft, it is a very useful document. > >I have a few comments, mostly about STUN >(you know I am a STUN fan!) > >I note that in the STUN section you write: > >" To be able to use STUN to traverse symmetric NATs the STUN server > needs to be co-located with the streaming server media distribution > ports." > >This is true and it is a very interresting feature indeed, >but then when you had the reader say "ahah!" and >start to get really interrested you cold shower it with: > >"This creates an unclear demultiplexing point within the > server. As this will create implementations difficulties and possibly > security problems this SHOULD NOT be done." > >I think that a "should not" is really too strong here if it is >an implementation issue, co-locating is not in itself >a big issue for exemple a lot of RTSP servers >are also HTTP servers right? >(the "possible security problems" would have to be compared >with the alternative solutions!...) > > I think this is something we need to discuss further. My current view is that due to the lack of a well defined demultiplexing structure between media protocol and STUN on the servers ports makes STUN solutions for symmetric NATs a bad choice. As pointed out you need to compare the media protocols bit structure with STUN request. This is not safe operation. I do agree that RTP and RTCP seems to be reasonable safe to demultiplex, however it is impossible to know that all protocols media protocols will work. I also find your example with HTTP and RTSP a bad example. HTTP and RTSP are distinguished using the nice demultiplexing mechanism of ports. Normally HTTP request goes to port 80 while RTSP goes to port number 540. This is a well defined demultiplexing. >************** > >BTW in the Symetric RTP section you write: > >"It has the advantage of working for all types of NATs. However it requires server modifications." > >Therefore I conclude that there is no difference >in terms of implementation between STUN and symetric RTP >since in both case you need to change the RTSP server, >and in a similar fashion! > Yes, unless you can use STUN to find two port numbers that match the RTP rule of consecutive even and odd ports. Both solutions requires updates. However STUNs are less from a RTSP protocol perspective. > >Also you write in the same section: > >" 1. The client knows or has determined by the use of STUN that it is > located behind a NAT. It may also determined the type of NAT it > is behind." > >So If one wants to use Symetric RTP one will have to implement STUN _anyway_ ! > I need to clarify that this is OPTIONAL behavior that MAY improve the performance of the solution. >For implementers the advantages of symetric RTP are therefore difficult to see ? >and then the reason why, by comparison, would co-located-STUN get a "SHOULD NOT" gets >really difficult to understand! > > As explained before this is not a clean solution. >**************** > >Anyway I would propose to reword the section 3.1.3. as: > > >"There are 2 ways to use STUN dependign if the STUN server >is co-located with the streaming server media distribution ports or not. > >3.1.3.1. STUN server outside > > Advantages: > > - Does not require RTSP server modifications, totally client > implemented tool. > > Disadvantages: > > - Requires a STUN server deployed in the public address space. > - Does only work well behind Cone NATs. Does not work with > Symmetric NATs. > >3.1.3.2. STUN server inside (co-located at the server media distribution > ports) > > Advantages: > > - Works with all NATs including Symmetric NATs (however see the security section about sending RTP >data at a different public IP address than the one of the RTSP client). > > Disadvantages: > > - Requires a modified RTSP server with co-located STUN server. > > In the second case you forgot the disadvantage of not being guaranteed to be able to correctly distinguish media packets and STUN request. Another thing that it seems that I forgot being a disadvantage of STUN is that it does not work if the media mappings would get different IP addresses, either between each UDP stream or with the TCP connection. The reason is the restriction that RTSP must use to prevent DOS attacks. >************************************** > >Last open issue about STUN: > >you describe a number of RTSP modifications for symetric RTP >and none for STUN while there could be one very useful thing: > >In the response to DESCRIBE the server should indicate >the UDP ports it is planning to use so that the client can immediately >STUN toward these ports, and then the STUN server reply can >be used for SETUP (saves a lot of round trips). > >The question is how can a server indicate its >RTP _AND_ RTCP port numbers ? > >For example you can do that with a header in the RTSP response: > > > C->S: DESCRIBE rtsp://foo/twister RTSP/1.0 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057 > Content-Type: application/sdp > Content-Length: xxx > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > etc... > >Also you can include this informationin SDP, >which may be better since the client may get the SDP >by some other means, right? > > > Actually you can include this information in the SDP without any extra extensions is just the matter of defining the usage. The RTP port number can be located in its normal place on the m= line. The RTCP port can be set by the attribute defined by draft-ietf-mmusic-sdp4nat-03.txt. To make this in a good fashion the server should define a RTSP feature tag that indicates this functionality and that the server should provide the information when sending the DESCRIBE response. I think we need to further discuss the RTSP NAT traversal solutions and possible optimization. My draft was intended to be a common ground to discuss around. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 11:15:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03471 for ; Fri, 28 Feb 2003 11:15:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGPx108139 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 11:25:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGPxp08136 for ; Fri, 28 Feb 2003 11:25:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03375 for ; Fri, 28 Feb 2003 11:14:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGPsp08102; Fri, 28 Feb 2003 11:25:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGOxp07920 for ; Fri, 28 Feb 2003 11:24:59 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03318 for ; Fri, 28 Feb 2003 11:13:54 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SGHknS004308; Fri, 28 Feb 2003 17:17:46 +0100 (MET) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.46]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5XGS3AB; Fri, 28 Feb 2003 17:17:46 +0100 Message-ID: <3E5F8BAA.1030304@era.ericsson.se> Date: Fri, 28 Feb 2003 17:17:46 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philippe.gentric@philips.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Re: draft-ietf-mmusic-rtsp-nat-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Phillipe, Comments below: philippe.gentric@philips.com wrote: >you write: > > > >>My current view is >>that due to the lack of a well defined demultiplexing structure between >>media protocol and STUN on the servers ports makes STUN solutions for >>symmetric NATs a bad choice. As pointed out you need to compare the >>media protocols bit structure with STUN request. This is not safe >>operation. I do agree that RTP and RTCP seems to be reasonable safe to >>demultiplex, however it is impossible to know that all protocols media >>protocols will work. >> >> > >Well I dont know about other protocols but the use of STUN in the RTSP scenario is *extremely* safe: > >1) your client sends and receives STUN on the UDP ports it has choosen for RTP and RTCP >_but_ since this is *before* the SETUP there is *only* a STUN client behind these UDP ports, >(the RTP/RTCP stack does not have to be initialized yet). And vice versa >i.e. as soon as STUN completed you can stop the STUN client to >start the RTP/RTCP session ! > >=> so on the client side it is totally safe. > > I don't think that client implementation has been my major concern when it comes to STUN. >2) the server does NOT listen for incomming data on the RTP ports: >there will be the STUN server listening behind these ports, nothing else > >=> no possible collision of STUN with RTP on the server side > > I don't agree with you here. What I believe will happen is that a server will use a single port pair for sending all the sessions it needs to be STUNed. This will result in that these port will receive traffic from other clients that already has established their sessions. Therefore there will be a flow of both RTP or RTCP and STUN packets. One must also consider any mapping keep alive, especially on the RTP port. This can be either RTP or STUN packets. In the draft I recommend the usage of empty RTP packets. >3) then the server needs to distinguish between RTCP RR >and STUN on the RTCP port but the headers are _really_ different. > >for starters the first bit is different (1 for RTCP, 0 for STUN)! > I agree that there is a pretty good difference here, but RTP and RTCP first byte was never designed to be a demultiplexing tool. What happens if a server or client would send RAT packets that actually has a version number of 0. Then you don't have this nice difference anymore. >but let us imagine that a STUN packet (of an hypothetical future extended version!) >will by chance match the first 32 bits of a paussible RTCP RR packet, >then what is the probability of having the 32 bits SSRC (random, fixed per transaction) >match the first 32 bits of the 128 STUn tID (random, changing every message) ? >2 to the power 64 ? > > Actually having one fixed and the other being random only increases the chance of collisions. Of course it will only happened with one STUN message not the next. However the whole idea requires both STUN and RTP/RTCP to handle packets that are routed wrong. Of course any good implementation will anyway have these properties. > > >>As explained before this is not a clean solution. >> >> > >"Striving to better, oft we mar what's well." (William Shakespeare) > > Yes, the perfect are in many case the enemy of the good. However I don't really see how this proverb apply here. First of all, any NAT solution is basically a deal with the devil. Secondly I am not trying to better anything. Only use what is there and does work, i.e. multiplexing points that are designed to be it. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Feb 28 19:13:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17785 for ; Fri, 28 Feb 2003 19:13:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h210MUh06738 for mmusic-archive@odin.ietf.org; Fri, 28 Feb 2003 19:22:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h210MUp06735 for ; Fri, 28 Feb 2003 19:22:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17769 for ; Fri, 28 Feb 2003 19:13:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h210MNp06727; Fri, 28 Feb 2003 19:22:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h210LRp06695 for ; Fri, 28 Feb 2003 19:21:27 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17765 for ; Fri, 28 Feb 2003 19:12:07 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id h210E6B50914 for ; Fri, 28 Feb 2003 16:14:06 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 16:14:06 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7858@MISTY> From: Thomas Zeng To: mmusic@ietf.org Date: Fri, 28 Feb 2003 16:14:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.com) Subject: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus: I have a comment on 3.2 Symetric RTP. As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server normally uses a single RTP port (let's call it X) to send RTP packets to many (potentially hundreds) of clients. Now Symetric RTP asks these clients to send an RTP packet with their individual client SSRC in the payload to this port X on the server host. Since each client randomly generates client SSRC, there is some chance (as high as 10^-4 according to RFC1889, section 8.1) that two clients may end up with same SSRC, in which case the server may send RTP packets to wrong clients. I did study the SSRC collision detection scheme in RFC1889 and found it irrelevant because it only applies to multicast RTP sessions. I don't think destination IP can help here since prior to the establishment of binding our server doesn't know clients public IPs. Besides, the two collided clients may well be behind the same NAT and hence probably share public IP. I hereby suggest that the binding RTPs to add, in a fashion defined below, client's RTSP sessionID in addition to client's SSRC in those binding RTP packets. Notice RTSP sessionIDs are generated by the server and hence can be made unique amongst all clients of that server. The session ID happens to provide other niceties: 1. One client only has to make sure that its client SSRCs are unique amongst the RTP tracks it has in the session (if it happens to have more than one track) 2. Since RTSP session ID can be 64 bytes or longer, it offers added protection against stream hijacking or brute force attacks (since now the hijacker/attacker must guess not only SSRC, but also SessionID). Careful thinking revealed to me that the fundamental problem here is that prior to the establishment of port mapping, there is no way for the server to determine RTP session using the traditional source and destination (IP, port-pair) as defined in RFC1889 section 3. Unfortunately, it means that what I said about RTP port mapping is also true to RTCP port mapping. Assuming you readers are with me so far, I then propose that the binding RTP packets include SessionID in the following fashion: 1. Do NOT use PT=0, instead, use a dedicated PT for binding purposes (we probably need to reserve one). 2. The only payload in this RTP is the session ID. 3. This payload type shall be used for the binding packets the client send to sender's RTCP send port as well (in lieu of the normal RTCP packets in Magnus draft, section 3.2.3, page 8). Interestingly, there is another way to deal with client SSRC collision: rejecting the SETUP request containing a client SSRC already registered. But that breaks backwards compatibility in that current clients don't know to change SSRC and resend SETUP request. Besides, the nice security feature of sessionID is gone. Hence I prefer the inclusion of SessionID. - thomas -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, February 25, 2003 3:46 AM Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : How to make Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls Author(s) : M. Westerlund Filename : draft-ietf-mmusic-rtsp-nat-00.txt Pages : 18 Date : 2003-2-24 This document describes four different types of NAT traversal techniques that can be used by RTSP. For each technique a description on how it shall be used, what security implications it has and other deployment considerations that exist is given. Further a description on how RTSP relates to firewalls are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rtsp-nat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic