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,ö
<draft-durand-v6ops-natpt-dns-alg-issues-00.txt>, 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,ö <draft-huitema-ngtrans-
unmaneval-01.txt>, 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,ö <draft-
park-scalable-multi-natpt-0.txt>, Internet-Draft, May 2003.
[SecCon] Savola, P. ôSecurity Considerations for 6to4,ö <draft-
savola-v6ops-6to4-security-02.txt>, 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,ö <draft-vanderpol-v6ops-translation-issues-
00.txt>, 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]