draft-ietf-mmusic-rtsp-nat-evaluation-12.txt   draft-ietf-mmusic-rtsp-nat-evaluation-13.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: July 27, 2014 Expires: August 14, 2014
January 23, 2014 February 10, 2014
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-12 draft-ietf-mmusic-rtsp-nat-evaluation-13
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 41 skipping to change at page 1, line 41
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 July 27, 2014. This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 13, line 14 skipping to change at page 13, line 14
As it may be difficult to determine why the failure occurs, the usage As it may be difficult to determine why the failure occurs, the usage
of TLS protected RTSP message exchange at all times would avoid this of TLS protected RTSP message exchange at all times would avoid this
issue. issue.
4.1.4. Deployment Considerations 4.1.4. Deployment Considerations
For the Stand-Alone usage of STUN the following applies: For the Stand-Alone usage of STUN the following applies:
Advantages: Advantages:
o STUN is a solution first used by SIP based applications (See o STUN is a solution first used by SIP [RFC3261] based applications
section 1 and 2 of [RFC5389]). As shown above, with little or no (See section 1 and 2 of [RFC5389]). As shown above, with little
changes, the RTSP application can re-use STUN as a NAT traversal or no changes, the RTSP application can re-use STUN as a NAT
solution, avoiding the pit-fall of solving a problem twice. traversal solution, avoiding the pit-fall of solving a problem
twice.
o Using STUN does not require RTSP server modifications; it only o Using STUN does not require RTSP server modifications; it only
affects the client implementation. affects the client implementation.
Disadvantages: Disadvantages:
o Requires a STUN server deployed in the public address space. o Requires a STUN server deployed in the public address space.
o Only works with NATs that perform endpoint independent and address o Only works with NATs that perform endpoint independent and address
dependent mappings. Address and Port-Dependent filtering NATs dependent mappings. Address and Port-Dependent filtering NATs
skipping to change at page 19, line 31 skipping to change at page 19, line 31
performance rather than always successful is recommended, as it performance rather than always successful is recommended, as it
is most likely to be a server in the public. is most likely to be a server in the public.
4. The server responds to the SETUP (200 OK) for each media stream 4. The server responds to the SETUP (200 OK) for each media stream
with its candidates. A server with a public address usually only with its candidates. A server with a public address usually only
provides a single ICE candidate. Also here one candidate is the provides a single ICE candidate. Also here one candidate is the
server primary address. server primary address.
5. The connectivity checks are performed. For the server the 5. The connectivity checks are performed. For the server the
connectivity checks from the server to the clients have an connectivity checks from the server to the clients have an
additional usage. They verify that there is someone willingly to additional usage. They verify that there is someone willing to
receive the media, thus preventing the server from unknowingly receive the media, thus preventing the server from unknowingly
performing a DoS attack. performing a DoS attack.
6. Connectivity checks from the client promoting a candidate pair 6. Connectivity checks from the client promoting a candidate pair
were successful. Thus no further SETUP requests are necessary were successful. Thus no further SETUP requests are necessary
and processing can proceed with step 7. If another address than and processing can proceed with step 7. If another address than
the primary has been verified by the client to work, that address the primary has been verified by the client to work, that address
may then be promoted for usage in a SETUP request (Go to 7). If may then be promoted for usage in a SETUP request (Go to 7). If
the checks for the available candidates failed and if further the checks for the available candidates failed and if further
candidates have been derived during the connectivity checks, then candidates have been derived during the connectivity checks, then
skipping to change at page 22, line 4 skipping to change at page 22, line 4
Specifically, when the RTSP server receives the latching packet Specifically, when the RTSP server receives the latching packet
(a.k.a. hole-punching packet, since it is used to punch a hole in the (a.k.a. hole-punching packet, since it is used to punch a hole in the
Firewall/NAT and to aid the server for port binding and address Firewall/NAT and to aid the server for port binding and address
mapping) from its client, it copies the source IP and Port number and mapping) from its client, it copies the source IP and Port number and
uses them as delivery address for media packets. By having the uses them as delivery address for media packets. By having the
server send media traffic back the same way as the client's packet server send media traffic back the same way as the client's packet
are sent to the server, address mappings will be honored. Therefore are sent to the server, address mappings will be honored. Therefore
this technique works for all types of NATs, given that the server is this technique works for all types of NATs, given that the server is
not behind a NAT. However, it does require server modifications. not behind a NAT. However, it does require server modifications.
Unless there is built-in protection mechanism, latching is very Unless there is built-in protection mechanism, latching is very
vulnerable to DDoS attacks (See Security Considerations of vulnerable to both hijacking and becoming a tool in Distributed
Denail of Service (DDoS) attacks (See Security Considerations of
[I-D.ietf-mmusic-latching]), because attackers can simply forge the [I-D.ietf-mmusic-latching]), because attackers can simply forge the
source IP & Port of the latching packet. Using the rule for source IP & Port of the latching packet. Using the rule for
restricting IP address to the one of the signaling connection will restricting IP address to the one of the signaling connection will
need to be applied here also. However, that does not protect against need to be applied here also. However, that does not protect against
hijacking from another client behind the same NAT. This can become a hijacking from another client behind the same NAT. This can become a
serious issue in deployments with CGNs. serious issue in deployments with CGNs.
4.4.2. Necessary RTSP extensions 4.4.2. Necessary RTSP extensions
To support Latching, the RTSP signaling must be extended to allow the To support Latching, the RTSP signaling must be extended to allow the
skipping to change at page 23, line 9 skipping to change at page 23, line 9
o Limited to work with servers that have an public IP address. o Limited to work with servers that have an public IP address.
o The format of the RTP packet for "connection setup" (a.k.a o The format of the RTP packet for "connection setup" (a.k.a
Latching packet) is yet to be defined. One possibility is to use Latching packet) is yet to be defined. One possibility is to use
RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op]. RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].
o SSRC management if RTP is used for latching due to risk for mis- o SSRC management if RTP is used for latching due to risk for mis-
association of clients to RTSP sessions at the server if SSRC association of clients to RTSP sessions at the server if SSRC
collision occurs. collision occurs.
o Has significant security considerations (Section 4.4.4) due to o Has significant security considerations (See Section 4.4.4), due
lack of strong authentication mechanism, compare with STUN message to lack of a strong authentication mechanism and will need to use
authentication, and will need to use address restrictions. address restrictions.
4.4.4. Security Consideration 4.4.4. Security Consideration
Latching's major security issue is that RTP streams can be hijacked Latching's major security issue is that RTP streams can be hijacked
and directed towards any target that the attacker desires unless and directed towards any target that the attacker desires unless
address restrictions are used. In the case of NATs with multiple address restrictions are used. In the case of NATs with multiple
clients on the inside of them, hijacking can still occur. This clients on the inside of them, hijacking can still occur. This
becomes a significant threat in the context of carrier grade NATs becomes a significant threat in the context of carrier grade NATs
(CGN). (CGN).
skipping to change at page 23, line 49 skipping to change at page 23, line 49
attacker can send its own Latching packets containing the correct RTP attacker can send its own Latching packets containing the correct RTP
SSRC to the correct address and port on the server. The RTSP server SSRC to the correct address and port on the server. The RTSP server
will then use the source IP and port from the Latching packet as the will then use the source IP and port from the Latching packet as the
destination for the media packets it sends. destination for the media packets it sends.
Another variation of this attack is for a man in the middle to modify Another variation of this attack is for a man in the middle to modify
the RTP latching packet being sent by a client to the server by the RTP latching packet being sent by a client to the server by
simply changing the source IP to the target one desires to attack. simply changing the source IP to the target one desires to attack.
One can fend off the snooping based attack by applying encryption to One can fend off the snooping based attack by applying encryption to
the RTSP signaling transport. However, if the attacker is an man in the RTSP signaling transport. However, if the attacker is a man in
the middle modifying latching packets, the attack is impossible to the middle modifying latching packets, the attack is impossible to
defend against other than through address restrictions. As a NAT re- defend against other than through address restrictions. As a NAT re-
writes the source IP and (possibly) port this cannot be writes the source IP and (possibly) port this cannot be
authenticated, but authentication is required in order to protect authenticated, but authentication is required in order to protect
against this type of DoS attack. against this type of DoS attack.
Yet another issues is that these attacks also can be used to deny the Yet another issue is that these attacks also can be used to deny the
client the service it desires from the RTSP server completely. The client the service it desires from the RTSP server completely. The
attacker modifies or originates its own latching packets with another attacker modifies or originates its own latching packets with another
port than what the legit latching packets uses, which results in that port than what the legit latching packets uses, which results in that
the media server sends the RTP/RTCP traffic to ports the client isn't the media server sends the RTP/RTCP traffic to ports the client isn't
listening for RTP/RTCP on. listening for RTP/RTCP on.
The amount of random non-guessable material in the latching packet The amount of random non-guessable material in the latching packet
determines how well Latching can fend off stream-hijacking performed determines how well Latching can fend off stream-hijacking performed
by parties that are off the client to server network path, i.e. lacks by parties that are off the client to server network path, i.e. lacks
the capability to see the client's latching packets. This proposal the capability to see the client's latching packets. This proposal
skipping to change at page 37, line 41 skipping to change at page 37, line 41
2013. 2013.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in
progress), January 2014. progress), January 2014.
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal Mechanism for Media
controlled by Real-Time Streaming Protocol (RTSP)", draft- Controlled by Real-Time Streaming Protocol (RTSP)", draft-
ietf-mmusic-rtsp-nat-18 (work in progress), January 2014. ietf-mmusic-rtsp-nat-20 (work in progress), February 2014.
[NICE] "Libnice - The GLib ICE implementation, [NICE] "Libnice - The GLib ICE implementation,
http://nice.freedesktop.org/wiki/", May 2013. http://nice.freedesktop.org/wiki/", May 2013.
[PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library, [PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library,
http://www.pjsip.org/pjnath/docs/html/", May 2013. http://www.pjsip.org/pjnath/docs/html/", May 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
skipping to change at page 38, line 25 skipping to change at page 38, line 25
1999. 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022, January
2001. 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
 End of changes. 11 change blocks. 
18 lines changed or deleted 25 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/