--- 1/draft-ietf-mmusic-rtsp-nat-evaluation-07.txt 2013-05-27 11:14:23.877242432 +0100 +++ 2/draft-ietf-mmusic-rtsp-nat-evaluation-08.txt 2013-05-27 11:14:23.953244319 +0100 @@ -1,19 +1,19 @@ Network Working Group M. Westerlund Internet-Draft Ericsson Intended status: Informational T. Zeng -Expires: November 24, 2013 May 23, 2013 +Expires: November 28, 2013 May 27, 2013 The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) - draft-ietf-mmusic-rtsp-nat-evaluation-07 + draft-ietf-mmusic-rtsp-nat-evaluation-08 Abstract This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relates to firewalls and how each technique can @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 24, 2013. + This Internet-Draft will expire on November 28, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -121,21 +121,21 @@ 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 31 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 31 4.9.3. Deployment Considerations . . . . . . . . . . . . . . 32 4.9.4. Security Considerations . . . . . . . . . . . . . . . 33 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. Comparison of NAT traversal techniques . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 10. Informative References . . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Today there is a proliferate deployment of different flavors of Network Address Translator (NAT) boxes that in many cases only loosely follow standards [RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause discontinuity in address realms [RFC3424], therefore an application protocol, such as Real-time Streaming Protocol (RTSP) [RFC2326][I-D.ietf-mmusic-rfc2326bis], needs to deal with such @@ -1483,54 +1483,50 @@ and media traffic from different addresses also the TCP connection must be done through the same TURN server as the one in the next step. This will require the usage of TURN for TCP [RFC6062]. 2. The client establishes the necessary bindings on the TURN server. It must choose the local RTP and RTCP ports that it desires to receive media packets. TURN supports requesting bindings of even port numbers and continuous ranges. - 3. The RTSP client uses the acquired address and port mappings in - the RTSP SETUP request using the destination header. Note that - the server is required to have a mechanism to verify that it is - allowed to send media traffic to the given address. The server - should include its RTP SSRC in the SETUP response. + 3. The RTSP client uses the acquired address and port allocations in + the RTSP SETUP request using the destination header. - 4. The client requests that the server starts playing. The server - starts sending media packets to the given destination address and - ports. + 4. The RTSP Server sends the SETUP reply, which must include the + transport headers src_addr parameter (source and port in RTSP + 1.0). Note that the server is required to have a mechanism to + verify that it is allowed to send media traffic to the given + address. - 5. The first media packet to arrive at the TURN server on the - external port causes "lock down"; then TURN server forwards the - media packets to the RTSP client. + 5. The RTSP Client uses the RTSP Servers response to create TURN + permissions for the server's media traffic. - 6. When media arrives at the client, the client should try to verify - that the media packets are from the correct RTSP server, by - matching the RTP SSRC of the packet. The source IP address of - this packet will be that of the TURN server and can therefore not - be used to verify that the correct source has caused lock down. + 6. The client requests that the server starts playing. The server + starts sending media packets to the given destination address and + ports. - 7. If the client notices that some other source has caused lock down - on the TURN server, the client should create new bindings and - change the session transport parameters to reflect the new - bindings. + 7. The first media packet to arrive at the TURN server on the + external port; If matching established permissions the TURN + server forwards the media packets to the RTSP client. 8. If the client pauses and media is not sent for about 75% of the mapping timeout the client should use TURN to refresh the bindings. 4.9.3. Deployment Considerations Advantages: - o Does not require any server modifications. + o Does not require any server modifications given that the server + includes the src_addr header in the SETUP response. o Works for any type of NAT as long as the RTSP server has public reachable IP address. Disadvantage: o Requires another network element, namely the TURN server. o A TURN server for RTSP may not scale since the number of sessions it must forward is proportional to the number of client media @@ -1545,58 +1541,40 @@ will cause the media traffic to be sent to the wrong address. Transition: TURN is not intended to be phased-out completely, see Section 19 of [RFC5766]. However the usage of TURN could be reduced when the demand for having NAT traversal is reduced. 4.9.4. Security Considerations - An eavesdropper of RTSP messages between the RTSP client and RTSP - server will be able to do a simple denial of service attack on the - media streams by sending messages to the destination address and port - present in the RTSP SETUP messages. If the attacker's message can - reach the TURN server before the RTSP server's message, the lock down - can be accomplished towards some other address. This will result in - the TURN server dropping all the media server's packets when they - arrive. This can be accomplished with little risk for the attacker - of being caught, as it can be performed with a spoofed source IP. - The client may detect this attack when it receives the lock down - packet sent by the attacker as being mal-formed and not corresponding - to the expected context. It will also notice the lack of further - incoming packets. See bullet 7 in Section 4.9.2. - - The TURN server can also become part of a denial of service attack - towards any victim. To perform this attack the attacker must be able - to eavesdrop on the packets from the TURN server towards a target for + The TURN server can become part of a denial of service attack towards + any victim. To perform this attack the attacker must be able to + eavesdrop on the packets from the TURN server towards a target for the DoS attack. The attacker uses the TURN server to setup a RTSP session with media flows going through the TURN server. The attacker is in fact creating TURN mappings towards a target by spoofing the source address of TURN requests. As the attacker will need the address of these mappings he must be able to eavesdrop or intercept the TURN responses going from the TURN server to the target. Having these addresses, he can set up a RTSP session and start delivery of the media. The attacker must be able to create these mappings. The attacker in this case may be traced by the TURN username in the mapping requests. - The first attack can be made very hard by applying transport security - for the RTSP messages, which will hide the TURN servers address and - port numbers from any eavesdropper. - - The second attack requires that the attacker has access to a user - account on the TURN server to be able set up the TURN mappings. To - prevent this attack the RTSP server needs to verify that the ultimate - target destination accept this media stream. Which would require - something like ICE's connectivity checks being run between the RTSP - server and the RTSP client. + This attack requires that the attacker has access to a user account + on the TURN server to be able set up the TURN mappings. To prevent + this attack the RTSP server needs to verify that the ultimate target + destination accept this media stream. Which would require something + like ICE's connectivity checks being run between the RTSP server and + the RTSP client. 5. Firewalls Firewalls exist for the purpose of protecting 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 firewall friendly in that it should be easy to design firewall policies to permit passage of RTSP traffic and its media streams.