draft-ietf-mmusic-rtsp-nat-evaluation-15.txt   draft-ietf-mmusic-rtsp-nat-evaluation-16.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: October 22, 2015 April 20, 2015 Expires: November 20, 2015 May 19, 2015
The Comparison of Different Network Address Translator (NAT) Traversal The Comparison 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-15 draft-ietf-mmusic-rtsp-nat-evaluation-16
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 of how it would be (RTSP). Each technique includes a description of 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 relate to firewalls and how each technique can traversal techniques relate to firewalls and how each technique can
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 October 22, 2015. This Internet-Draft will expire on November 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 41 skipping to change at page 2, line 41
4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 17 4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 17
4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17 4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17
4.2.6. Security Considerations . . . . . . . . . . . . . . . 18 4.2.6. Security Considerations . . . . . . . . . . . . . . . 18
4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18
4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19 4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19
4.3.3. Implementation burden of ICE . . . . . . . . . . . . 21 4.3.3. Implementation burden of ICE . . . . . . . . . . . . 21
4.3.4. ALG Considerations . . . . . . . . . . . . . . . . . 21 4.3.4. ALG Considerations . . . . . . . . . . . . . . . . . 21
4.3.5. Deployment Considerations . . . . . . . . . . . . . . 22 4.3.5. Deployment Considerations . . . . . . . . . . . . . . 22
4.3.6. Security Consideration . . . . . . . . . . . . . . . 22 4.3.6. Security Consideration . . . . . . . . . . . . . . . 22
4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 22 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 23
4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23 4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23
4.4.3. ALG Considerations . . . . . . . . . . . . . . . . . 24 4.4.3. ALG Considerations . . . . . . . . . . . . . . . . . 24
4.4.4. Deployment Considerations . . . . . . . . . . . . . . 24 4.4.4. Deployment Considerations . . . . . . . . . . . . . . 24
4.4.5. Security Consideration . . . . . . . . . . . . . . . 25 4.4.5. Security Consideration . . . . . . . . . . . . . . . 25
4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 26 4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 26
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 26 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 27
4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27 4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27
4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 27 4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 28
4.5.4. Deployment Considerations . . . . . . . . . . . . . . 27 4.5.4. Deployment Considerations . . . . . . . . . . . . . . 28
4.5.5. Security Considerations . . . . . . . . . . . . . . . 28 4.5.5. Security Considerations . . . . . . . . . . . . . . . 28
4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 28 4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 28
4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 28 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 28
4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 28 4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 29
4.6.3. ALG Considerations . . . . . . . . . . . . . . . . . 29 4.6.3. ALG Considerations . . . . . . . . . . . . . . . . . 29
4.6.4. Deployment Considerations . . . . . . . . . . . . . . 29 4.6.4. Deployment Considerations . . . . . . . . . . . . . . 29
4.6.5. Security Considerations . . . . . . . . . . . . . . . 29 4.6.5. Security Considerations . . . . . . . . . . . . . . . 29
4.7. Application Level Gateways . . . . . . . . . . . . . . . 30 4.7. Application Level Gateways . . . . . . . . . . . . . . . 30
4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 30 4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 30
4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 30 4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 31
4.7.3. Deployment Considerations . . . . . . . . . . . . . . 31 4.7.3. Deployment Considerations . . . . . . . . . . . . . . 32
4.7.4. Security Considerations . . . . . . . . . . . . . . . 32 4.7.4. Security Considerations . . . . . . . . . . . . . . . 32
4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 32 4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 33
4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 33 4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 33
4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 33 4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 33
4.8.3. ALG Considerations . . . . . . . . . . . . . . . . . 33 4.8.3. ALG Considerations . . . . . . . . . . . . . . . . . 33
4.8.4. Deployment Considerations . . . . . . . . . . . . . . 33 4.8.4. Deployment Considerations . . . . . . . . . . . . . . 34
4.8.5. Security Considerations . . . . . . . . . . . . . . . 34 4.8.5. Security Considerations . . . . . . . . . . . . . . . 34
4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 34 4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 34
4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 34 4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 34
4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 35 4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 35
4.9.3. ALG Considerations . . . . . . . . . . . . . . . . . 36 4.9.3. ALG Considerations . . . . . . . . . . . . . . . . . 36
4.9.4. Deployment Considerations . . . . . . . . . . . . . . 36 4.9.4. Deployment Considerations . . . . . . . . . . . . . . 36
4.9.5. Security Considerations . . . . . . . . . . . . . . . 37 4.9.5. Security Considerations . . . . . . . . . . . . . . . 37
5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6. Comparison of NAT traversal techniques . . . . . . . . . . . 38 6. Comparison of NAT traversal techniques . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
10. Informative References . . . . . . . . . . . . . . . . . . . 41 10. Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
Today there is a proliferating deployment of different types of Today there is a proliferating deployment of different types 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)
skipping to change at page 22, line 43 skipping to change at page 22, line 43
4.3.6. Security Consideration 4.3.6. Security Consideration
One should review the security consideration section of ICE and STUN One should review the security consideration section of ICE and STUN
to understand that ICE contains some potential issues. However these to understand that ICE contains some potential issues. However these
can be avoided by correctly using ICE in RTSP. An important factor can be avoided by correctly using ICE in RTSP. An important factor
is to secure the signalling, i.e. use TLS between RTSP client and is to secure the signalling, i.e. use TLS between RTSP client and
server. In fact ICE does help avoid the DDoS attack issue with RTSP server. In fact ICE does help avoid the DDoS attack issue with RTSP
substantially as it reduces the possibility for a DDoS using RTSP substantially as it reduces the possibility for a DDoS using RTSP
servers to attackers that are on-path between the RTSP server and the servers to attackers that are on-path between the RTSP server and the
target and capable of intercepting the STUN connectivity check target and capable of intercepting the STUN connectivity check
packets and correctly send a response to the server. packets and correctly send a response to the server. The ICE
connectivity checks with their random transaction IDs from the server
to the client serves as return-routability check and prevents off-
path attacker to succeed with address spoofing. Similar to Mobile
IPV6's return routability procedure (Section 5.2.5 of [RFC6275]).
4.4. Latching 4.4. Latching
4.4.1. Introduction 4.4.1. Introduction
Latching is a NAT traversal solution that is based on requiring RTSP Latching is a NAT traversal solution that is based on requiring RTSP
clients to send UDP packets to the server's media output ports. clients to send UDP packets to the server's media output ports.
Conventionally, RTSP servers send RTP packets in one direction: from Conventionally, RTSP servers send RTP packets in one direction: from
server to client. Latching is similar to connection-oriented server to client. Latching is similar to connection-oriented
traffic, where one side (e.g., the RTSP client) first "connects" by traffic, where one side (e.g., the RTSP client) first "connects" by
skipping to change at page 29, line 36 skipping to change at page 29, line 48
o May be simpler to implement due to the avoidance of the ICE o May be simpler to implement due to the avoidance of the ICE
prioritization and check-board mechanisms. prioritization and check-board mechanisms.
However, a 3-way Latching protocol is very similar to using STUN in However, a 3-way Latching protocol is very similar to using STUN in
both directions as Latching and verification protocol. Using STUN both directions as Latching and verification protocol. Using STUN
would remove the need for implementing a new protocol. would remove the need for implementing a new protocol.
4.6.5. Security Considerations 4.6.5. Security Considerations
The three way latching is significantly securer than its simpler Three way latching is significantly more secure than its simpler
versions discussed above. The client to server nonce which is versions discussed above. The client to server nonce which is
included in signalling and also can be bigger than the 32-bits of included in signalling and also can be bigger than the 32-bits of
random data that the SSRC field supports makes it very difficult for random data that the SSRC field supports makes it very difficult for
an off-path attacker to perform an denial of service attack by an off-path attacker to perform an denial of service attack by
diverting the media. diverting the media.
The client to server nonce and its echoing back does not protect The client to server nonce and its echoing back does not protect
against on-patch attacker, including malicious clients. However, the against on-patch attacker, including malicious clients. However, the
server to client nonce and its echoing back prevents malicious server to client nonce and its echoing back prevents malicious
clients to divert the media stream by spoofing the source address and clients to divert the media stream by spoofing the source address and
port, as it can't echo back the nonce in these cases. port, as it can't echo back the nonce in these cases. Similar to the
Mobile IPv6 return routability procedure (Section 5.2.5 of [RFC6275])
Three way latching is really only vulnerable to an on-path attacker Three way latching is really only vulnerable to an on-path attacker
that is quite capable. First the attacker can either learn the that is quite capable. First the attacker can either learn the
client to server nonce, by intercepting the signalling, or modifying client to server nonce, by intercepting the signalling, or modifying
the source information (target destination) of a client's latching the source information (target destination) of a client's latching
packet. Secondly, it is also on-path between the server and target packet. Secondly, it is also on-path between the server and target
destination and can generate a response using the server's nonce. An destination and can generate a response using the server's nonce. An
adversary that has these capabilities are commonly capable of causing adversary that has these capabilities are commonly capable of causing
significantly worse damage than this using other methods. significantly worse damage than this using other methods.
skipping to change at page 41, line 23 skipping to change at page 41, line 29
signaling connection. signaling connection.
The usage of TURN has severe risk of denial of service attacks The usage of TURN has severe risk of denial of service attacks
against a client. The TURN server can also be used as a redirect against a client. The TURN server can also be used as a redirect
point in a DDoS attack unless the server has strict enough rules for point in a DDoS attack unless the server has strict enough rules for
who may create bindings. who may create bindings.
The latching and variant of latching have so big security issues that The latching and variant of latching have so big security issues that
they should not be used at all. The three way latching as well as they should not be used at all. The three way latching as well as
ICE mitigates these security issues and performs the important ICE mitigates these security issues and performs the important
return-routability check that prevents spoofed source addresses, and return-routability checks that prevents spoofed source addresses, and
should be recommended for that reason. RTP ALG's is a security risk should be recommended for that reason. RTP ALG's is a security risk
as they can create an incitement against using secure RTSP as they can create an incitement against using secure RTSP
signalling. That can be avoided as ALGs requires trust in the signalling. That can be avoided as ALGs requires trust in the
middlebox, and that trust becomes explicit if one uses the hop-by-hop middlebox, and that trust becomes explicit if one uses the hop-by-hop
security solution as specified in Section 19.3 of RTSP 2.0. security solution as specified in Section 19.3 of RTSP 2.0.
[I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be [I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be
considered safe enough, assuming that the appropriate security considered safe enough, assuming that the appropriate security
mechanisms are used and not ignored. mechanisms are used and not ignored.
9. Acknowledgements 9. Acknowledgements
The author would also like to thank all persons on the MMUSIC working The author would also like to thank all persons on the MMUSIC working
group's mailing list that has commented on this document. Persons group's mailing list that has commented on this document. Persons
having contributed in such way in no special order to this protocol having contributed in such way in no special order to this protocol
are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon, are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,
Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill
Atwood, Alissa Cooper, Colin Perkins, Sarah Banks and David Black. Atwood, Alissa Cooper, Colin Perkins, Sarah Banks, David Black and
Thomas Zeng would also like to give special thanks to Greg Sherwood Alvaro Retana. Thomas Zeng would also like to give special thanks to
of PacketVideo for his input into this memo. Greg Sherwood of PacketVideo for his input into this memo.
Section 1.1 contains text originally written for RFC 4787 by Francois Section 1.1 contains text originally written for RFC 4787 by Francois
Audet and Cullen Jennings. Audet and Cullen Jennings.
10. Informative References 10. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", draft- Andreasen, F., "A No-Op Payload Format for RTP", draft-
ietf-avt-rtp-no-op-04 (work in progress), May 2007. ietf-avt-rtp-no-op-04 (work in progress), May 2007.
skipping to change at page 44, line 9 skipping to change at page 44, line 13
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", RFC around NAT (TURN) Extensions for TCP Allocations", RFC
6062, November 2010. 6062, November 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263, June 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", RFC Traversal (HNT) for Media in Real-Time Communication", RFC
7362, September 2014. 7362, September 2014.
[STUN-IMPL] [STUN-IMPL]
"Open Source STUN Server and Client, "Open Source STUN Server and Client,
http://sourceforge.net/projects/stun/", May 2013. http://sourceforge.net/projects/stun/", May 2013.
Authors' Addresses Authors' Addresses
 End of changes. 17 change blocks. 
21 lines changed or deleted 29 lines changed or added

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