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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/