Internet Engineering Task Force Internet Draft Satomi Okazaki Anand Desai NTT MCL, Inc. Expires: January 2004 June 2003 NAT-PT Security Considerations draft-okazaki-v6ops-natpt-security-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract NAT-PT (RFC2766) is an address translation mechanism designed to facilitate communications between IPv6-only and IPv4-only nodes. This mechanism was designed to be used when tunneling transition mechanisms cannot be used. This document is intended to be a compilation of known security issues related to NAT-PT and includes a few new ones. These issues are discussed in some detail, and suggestions on how to deal with them are included in this document. Okazaki, S. [Expires January 2004] [Page 1] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 Table of Contents 1.0 Introduction....................................................2 2.0 Description of Scheme...........................................3 2.1 IPv6-node-initiated communications............................4 2.2 IPv4-node-initated communications.............................4 3.0 Security analysis...............................................5 3.1 End-to-end security...........................................5 3.2 Prefix assignment.............................................5 3.3 DNS-ALG.......................................................5 3.4 Source address spoofing attack................................6 3.4.1 Attacker in the NAT-PT stub domain.........................6 3.4.2 Attacker outside of NAT-PT stub domain.....................6 3.5 An external attacker node.....................................7 4.0 Possible solutions..............................................7 4.1 End-to-end security...........................................7 4.2 Prefix assignment.............................................7 4.3 DNS-ALG.......................................................8 4.4 Source address spoofing attack................................8 4.4.1 Attacker in the NAT-PT stub domain.........................8 4.4.2 Attacker outside of the NAT-PT stub domain.................9 4.5 An external attacker node.....................................9 5.0 Acknowledgements................................................9 6.0 Security Considerations.........................................9 7.0 References.....................................................10 8.0 AuthorsÆ Contact Information...................................11 9.0 Full Copyright Statement.......................................11 1.0 Introduction Given the current deployment of IPv4 and the infrastructure changes necessary to adopt IPv6, there is guaranteed to be a long period in which the two must coexist. Various mechanisms have been proposed to allow for a smooth transition from IPv4 to IPv6. These techniques may be divided into two general types: tunneling mechanisms and translation mechanisms. Translation mechanism documents such as NAT-PT (Network Address Translation û Protocol Translation) [RFC2766] and SIIT (Stateless IP/ICMP Translation Algorithm) [RFC2765] indicate that they are to be used when tunneling techniques are not applicable. Translation mechanisms are intended for use between IPv6-only nodes and IPv4-only nodes. Okazaki, S. [Expires January 2004] [Page 2] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 Security issues in tunneling have been examined ([TunSec][SecCon]) to some extent. We are not aware of any dedicated security analysis documents related to translation techniques. In this document, we examine the security of NAT-PT, one of the prominent translation mechanism proposals. We list a few new security issues in addition to those that have been noted in the original draft and some others that have been mentioned in other drafts [DNSALG] [TransUnman] [TransIss] or on the v6ops mailing list. We propose solutions for the security issues that we have found. 2.0 Description of Scheme NAT-PT defines a method for allocating a globally unique temporary IPv4 address to an IPv6-only node to allow transparent routing between an IPv6-only node and an IPv4-only node. It is designed to work with a scheme like SIIT, which is a specification for a box that translates IPv4 headers into IPv6 headers and vice versa. The NAT-PT specification defines the functionality of an address translation box that sits on a border router. The NAT-PT box has a pool of globally unique IPv4 addresses to assign to IPv6-only nodes that need to communicate with IPv4-only nodes. There are two types of sessions û those that are initiated by an IPv6 node and those that are initiated by an IPv4 node. Here, we focus on the basic NAT-PT address translation functionality. Suppose that an IPv6-only node X behind a NAT-PT box has the IPv6 address FEDC:BA98::7654:3210, and suppose that an IPv4-only node Y in an IPv4 network has the IPv4 address 136.40.1.1. Furthermore, let us say that the NAT-PT box has a pool of globally unique IPv4 addresses in the range 140.32.1.1 to 140.32.1.20. +============+ [IPv6 node X]-----[NAT-PT]---|IPv4 Network| û[IPv4 node Y] | +============+ {pool of IPv4 addresses} IPv6 address of X: FEDC:BA98::7654:3210 IPv4 address of Y: 136.40.1.1 NAT-PT pool of IPv4 addresses: 140.32.1.1 to 140.32.1.20 Okazaki, S. [Expires January 2004] [Page 3] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 2.1 IPv6-node-initiated communications Suppose IPv6-only node X wishes to initiate communications with IPv4-only node Y. The NAT-PT box in XÆs network is associated with some prefix, which we will denote by ôPREFIX.ö X prepends this prefix to YÆs IPv4 address to get an IPv6 address that looks like ôPREFIX::IPv4 address of Yö. The source address and destination address of the packets that X sends to Y look like the following: src: FEDC:BA98::7654:3210 dst: PREFIX::136.40.1.1 All packets with destination address beginning with PREFIX are routed to the NAT-PT box, as the prefix is chosen to be unique in the stub domain, and the NAT-PT box advertises the prefix for routing purposes. The NAT-PT box then replaces the source address in the packets with the temporary IPv4 address (say 140.32.1.1) it chooses from its pool for X, and the box then strips ôPREFIXö from the destination address so that the IPv4 address of Y remains: src: 140.32.1.1 dst: 136.40.1.1 2.2 IPv4-node-initated communications The case in which a session is initiated by an IPv4 node is a bit more complicated and involves Domain Name Servers (DNSs). The IPv4 node YÆs DNS resolver would send a name look-up request (type ôAö) for X. This request gets sent through XÆs NAT-PT box to the DNS server on XÆs network. The NAT-PT contains a DNS-ALG (Application Level Gateway) that translates an ôAö query to an ôAAAAö or ôA6ö query and sends it to the DNS server on XÆs network. When the IPv6 DNS server responds with an ôAAAAö or ôA6ö record, it is sent through the NAT-PT box, where DNS-ALG translates it into an ôAö record and replaces the IPv6 address of X with the corresponding temporary IPv4 address from the pool. Okazaki, S. [Expires January 2004] [Page 4] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 3.0 Security analysis In this section, we list all of the security threats that we know of - a number of security threats that have been outlined in the original draft itself, in external documents, and those that we have isolated. 3.1 End-to-end security As noted in [RFC2766], NAT-PT and end-to-end security do not work together. When IPv6-only node X initiates communications to IPv4- only node Y, the packet that X forms has an IPv6 source address (FEDC:BA98::7654:3210) and an IPv6 destination address (PREFIX::136.40.1.1), which are used in IPsec (ESP or AH) computations, including TCP/UDP/ICMP checksum computations. Since NAT-PT assigns X an IPv4 address (140.32.1.1) that has no relationship to XÆs IPv6 address, there is no way for recipient Y to determine XÆs IPv6 address, which is involved in verifying TCP/UDP/ICMP checksum computations. 3.2 Prefix assignment The draft [RFC2766] does not describe how the IPv6 nodes learn the prefix that is used to route packets to the NAT-PT box. If the prefix is pre-configured in IPv6 nodes, the IPv6 node would prepend the pre-configured prefix to the address of any IPv4-only node with which it want to initiate communications. However, with a fixed prefix, there might be a reachability problem if the NAT-PT box were to shut down. If an attacker were somehow able to give the IPv6 node a fake prefix, the attacker would be able to steal all of the nodeÆs outbound packets to IPv4 nodes. 3.3 DNS-ALG The DNS-ALG is required when allowing IPv4-only-node-initiated communications in the NAT-PT setting. Since DNS-ALG will translate ôAö record requests into ôAAAAö or ôA6ö request and conversely, ôAAAAö or ôA6ö records into ôAö records, DNS-SEC will not work with NAT-PT, as noted in [RFC2766]. This means that it is possible for an attacker to modify records from DNS-ALG to the IPv4 nodes. Okazaki, S. [Expires January 2004] [Page 5] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 3.4 Source address spoofing attack We consider attackers that will use NAT-PT resources. There are two cases: in the first, the attacker is in the same stub domain as the NAT-PT, and in the second, the attacker is outside of the NAT- PT stub domain. 3.4.1 Attacker in the NAT-PT stub domain Here, we suppose that an attacker in the same stub domain as NAT-PT sends a packet destined for an IPv4-only node Y on the other side of NAT-PT. We look at the more interesting case in which the attacker forges its source address to be an address that is topologically inside the stub domain. (This address could belong to another node, or it could be unassigned.) Address depletion attack - If the IPv6 attacker sends many such packets, each with a different source address, then the pool of IPv4 addresses may get used up, resulting in a Denial of Service attack. (This vulnerability is also noted in [RFC2766] and [TransIss].) The other attacks exist even without NAT-PT. These are reflection attacks, resource exhaustion attacks, and broadcast/multicast attacks. In a reflection attack, the IPv6 source address is set to that of an existing node. That node will be the recipient of a reflection attack, as the IPv4 node will send response packets to the victim node. In a resource exhaustion attack, the IPv6 source address is set to that of a non-existent node. The return packets will be dropped, but this may still result in a resource exhaustion DoS attack on Y. Finally, in a multicast attack, the IPv6 source address is a multicast address. The return packet from the IPv4 node will be sent to the multicast address, resulting in a multicast attack. 3.4.2 Attacker outside of NAT-PT stub domain Here, we suppose that an attacker on the other side of NAT-PT sends a packet destined for an IPv6-only node X behind NAT-PT. We look at the more interesting case in which the attacker forges its source address to be an address that is topologically outside the stub domain. (This address could belong to another node, or it could be unassigned.) The same attacks are possible here as in the case described in the previous section. Okazaki, S. [Expires January 2004] [Page 6] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 3.5 An external attacker node In this case, an attacker that knows the IP address of the NAT-PT box can send packets directly to the box. It can use NAT-PT resources, preventing legitimate IPv6-only nodes from accessing NAT-PT services. 4.0 Possible solutions 4.1 End-to-end security End-to-end security is not possible with NAT-PT. One reason is outlined in section 3.1. 4.2 Prefix assignment Though it is not specified in [RFC2766], DNS servers and DNS-ALG may be used in outgoing connections to return the prefix information to the IPv6 node. This is a way to avoid the problem of a statically pre-configured prefix. When an IPv6-only node wishes to initiate communications with an IPv4-only node, its resolver would send an ôAAAAö query. This query can be passed through the DNS-ALG, which would receive an ôAö record in response. In this case, the DNS-ALG can prepend the appropriate prefix for the NAT-PT and translate the ôAö record into an ôAAAAö or ôA6ö record and return it to the IPv6 node. The DNS-ALG can also monitor the state of a number of NAT-PT boxes (multiple boxes for scalability) and return the prefixes of those that are running. This idea was stated in [DNSALG] and [mNATPT], as well as in e-mail communication on the v6ops mailing list. As mentioned in [mNATPT], the method by which DNS-ALG determines the state and validity of a NAT-PT box must be secure. The DNS-ALG and each NAT-PT box should be configured with a pairwise unique shared key that will be used for integrity-protected communications. Note that messages from DNS-ALG are not integrity-protected and can therefore be modified. To prevent such a modification, DNS-ALG can sign its packets. DNS-ALGÆs public key can be made available like that of a DNS server (see [RFC2535]) or presented in a certificate that has a root CA that is well known to all nodes behind NAT-PT. A shared-key technique may not be as practical. Okazaki, S. [Expires January 2004] [Page 7] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 4.3 DNS-ALG The end host (IPv6 node or IPv4 node) will not be able to verify the signature on a DNS record because of the translation that the DNS-ALG performs. However, as is pointed out in [DNSALG], if the host sets the "AD is secure" bit in the DNS header, then it is possible for the local DNS server to verify the signatures. Another option is for DNS-ALG to verify the received records (like a DNS resolver), translate them, and sign the translated records (like a DNS server). DNS-ALGÆs public key can be made available like that of a DNS server (see [RFC2535]). A third option would be for a host to have an IPsec security association with the DNS-ALG to protect DNS records. 4.4 Source address spoofing attack 4.4.1 Attacker in the NAT-PT stub domain The NAT-PT (which sits on a border router) should perform ingress filtering. This would prevent an attacking node in its stub domain that forges its source address from performing a reflection attack on nodes in other stub domains. However, this does not prevent such an attacker from performing a reflection attack on other nodes in the same stub domain. These are not attacks introduced by NAT- PT. The NAT-PT should drop packets whose IPv6 source address is a multicast address. This would prevent the multicast attack. This is not an attack introduced by NAT-PT. One way to get around the address depletion attack is to employ NAPT-PT (Network Address Port Translation - Protocol Translation)[RFC2766], which translates TCP/UDP ports of IPv6 nodes into TCP/UDP ports of the translated IPv4 addresses. However, as the draft points out, IPv4-node-initiated NAPT-PT sessions are restricted to one server per service. Another method of dealing with address depletion is to have a list of nodes to which NAT-PT will offer its translation services. Or for more security, an IPsec security association could be required between the NAT-PT and nodes to which it will offer its services. Okazaki, S. [Expires January 2004] [Page 8] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 4.4.2 Attacker outside of the NAT-PT stub domain The NAT-PT should drop packets whose IPv4 source address is a broadcast/multicast address to prevent a broadcast/multicast attack. Furthermore, NAT-PT should filter out packets from outside that claim to have a source address behind NAT-PT. These are not attacks introduced by NAT-PT. The address depletion attack is discussed in the previous section. 4.5 An external attacker node NAT-PT should drop packets that are sent directly to its IP address rather than being routed to it via the prefix PREFIX. If NAT-PT maintains a list of nodes to which it will offer its services, this type of attack will be minimized as well. Or for more security, an IPsec security association could be required between the NAT-PT and nodes to which it will offer its services. 5.0 Acknowledgements The authors would like to acknowledge DoCoMo USA Labs for support of this work and in particular, James Kempf for helpful comments and insights. 6.0 Security Considerations This draft is itself a document about security considerations for NAT-PT. Okazaki, S. [Expires January 2004] [Page 9] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 7.0 References [TunSec] Di Battista et al. ôOperational procedures for secured management with transition mechanisms,ö 28 February 2003. [DNSALG] Durand, A. ôIssues with NAT-PT DNS ALG in RFC2766,ö , Internet- Draft, 29 January 2003. [RFC2535] Eastlake, D. ôDomain Name Security Extensions,ö RFC 2535, March 1999. [TransUnman] Huitema, C. et al. ôEvaluation of Transition Mechanisms for Unmanaged Networks,ö , Internet-Draft, 1 November 2002. [RFC2765] Nordmark, E. ôStateless IP/ICMP Translation Algorithm (SIIT),ö RFC 2765, February 2000. [mNATPT] Park, S.D. et al. ôScalable mNAT-PT Solution,ö , Internet-Draft, May 2003. [SecCon] Savola, P. ôSecurity Considerations for 6to4,ö , Internet-Draft, January 2003. [RFC2766] Tsirtsis, G. and Srisuresh, P. ôNetwork Address Translation û Protocol Translation (NAT-PT),ö RFC 2766, February 2000. [TransIss] Van der Pol, R. et al. ôIssues when translating between IPv4 and IPv6,ö , Internet-Draft, 27 January 2003. Okazaki, S. [Expires January 2004] [Page 10] Internet Draft draft-okazaki-v6ops-natpt-security-00.txt June 2003 8.0 AuthorsÆ Contact Information Satomi Okazaki Phone: +1 650 833 3631 NTT MCL, Inc. Fax: +1 650 326 1878 250 Cambridge Avenue, Suite 300 Email: satomi@nttmcl.com Palo Alto, California 94306 USA Anand Desai Phone: +1 650 833 3638 NTT MCL, Inc. Fax: +1 650 326 1878 250 Cambridge Avenue, Suite 300 Email: anand@nttmcl.com Palo Alto, California 94306 USA 9.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Okazaki, S. [Expires January 2004] [Page 11]