--- 1/draft-ietf-v6ops-natpt-to-exprmntl-00.txt 2006-02-05 02:08:15.000000000 +0100 +++ 2/draft-ietf-v6ops-natpt-to-exprmntl-01.txt 2006-02-05 02:08:15.000000000 +0100 @@ -1,103 +1,102 @@ v6ops Working Group C. Aoun -Internet-Draft Nortel Networks/ENST Paris +Internet-Draft ENST Updates: 2766 (if approved) E. Davies -Expires: July 5, 2005 Consultant - January 2005 +Expires: January 6, 2006 Consultant + July 5, 2005 Reasons to Move NAT-PT to Experimental - draft-ietf-v6ops-natpt-to-exprmntl-00 + draft-ietf-v6ops-natpt-to-exprmntl-01 Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. 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. + 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. - This Internet-Draft will expire on July 5, 2005. + This Internet-Draft will expire on January 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract - This document discusses issues with the specific form of IPv6-IPv4 + This document discusses general issues with all forms of IPv6-IPv4 + translation and specific issues related to the form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These - issues are sufficiently serious that recommending RFC 2766 as a - general purpose transition mechanism is no longer desirable, and this - document requests that the IETF reclassifies RFC 2766 from Standards - Track to Experimental status. + specific issues are sufficiently serious that recommending RFC 2766 + as a general purpose transition mechanism is no longer desirable, and + this document recommends that the IETF should reclassify RFC 2766 + from Standards Track to Experimental status. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . 6 2.1 Issues with Protocols Embedding IP Addresses . . . . . . . 6 2.2 NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 - 2.3 NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 7 + 2.3 NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8 2.4 Loss of Information through Incompatible Semantics . . . . 8 2.5 NA(P)T-PT and Fragmentation . . . . . . . . . . . . . . . 9 2.6 NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 - 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 10 + 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 11 2.8 NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 11 3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . 12 3.1 Network Topology Constraints Implied by NAT-PT . . . . . . 12 3.2 Scalability and Single Point of Failure Concerns . . . . . 13 - 3.3 Issues with Lack of Address Persistence . . . . . . . . . 13 + 3.3 Issues with Lack of Address Persistence . . . . . . . . . 14 3.4 DOS Attacks on Memory and Address/Port Pools . . . . . . . 14 4. Issues Directly Related to use of DNS-ALG . . . . . . . . . 15 4.1 Address Selection Issues when Communicating with Dual-Stack End-hosts . . . . . . . . . . . . . . . . . . . 15 4.2 Non-global Validity of Translated RR Records . . . . . . . 17 4.3 Inappropriate Translation of Responses to A Queries . . . 17 4.4 DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 17 4.5 Limitations on Deployment of DNS Security Capabilities . . 18 5. Impact on IPv6 Application Development . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 - 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10.1 Normative References . . . . . . . . . . . . . . . . . . 20 - 10.2 Informative References . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10.1 Normative References . . . . . . . . . . . . . . . . . . 21 + 10.2 Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . 25 1. Introduction The Network Address Translator - Protocol Translator NAT-PT) document - [RFC2766] defines a set of network layer translation mechanisms - designed to allow nodes which only support IPv4 to communicate with - nodes which only support IPv6 during the transition to the use of - IPv6 in the Internet. + [RFC2766] defines a set of network layer translation mechanisms. + These mechanisms are designed to allow nodes which only support IPv4 + to communicate with nodes which only support IPv6 during the + transition to the use of IPv6 in the Internet. [RFC2766] specifies the basic NAT-PT in which only addresses are translated and NAPT-PT (Network Address Port Translator - Protocol Translator)which also translates transport identifiers, allowing for greater economy of scarce IPv4 addresses. Protocol translation is performed using the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. A number of previous documents have raised issues with NAT-PT. This document will summarize these issues, note several other issues @@ -120,44 +119,44 @@ [RFC2766] as a general purpose transition mechanism for intercommunication between IPv6 networks and IPv4 networks. Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node which can only support IPv4 will need to communicate with a node which can only support IPv6: this is bound to need a translation mechanism of some kind. Although this may be better carried out by an application level proxy or transport layer translator, there may still be scenarios in which a (possibly restricted) version of NAT-PT can be a - suitable solution: accordingly this document requests the IETF to - reclassify RFC2766 from Standards Track to Experiemental status. + suitable solution: accordingly this document recommends that the IETF + should reclassify RFC2766 from Standards Track to Experimental + status. The following documents relating directly to NAT-PT have been reviewed while drafting this document: - o Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765] - o NAT-PT applicability statement - [I-D.satapati-v6ops-natpt-applicability] - o Issues with NAT-PT DNS ALG in RFC2766 - [I-D.durand-natpt-dns-alg-issues] + o NAT-PT applicability statement [I-D.satapati-v6ops-natpt- + applicability] + o Issues with NAT-PT DNS ALG in RFC2766 [I-D.durand-natpt-dns-alg- + issues] o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security] - o Issues when translating between IPv4 and IPv6 - [I-D.vanderpol-v6ops-translation-issues] + o Issues when translating between IPv4 and IPv6 [I-D.vanderpol- + v6ops-translation-issues] o IPv6-IPv4 Translation mechanism for SIP-based services in Third - Generation Partnership Project (3GPP) Networks - [I-D.elmalki-sipping-3gpp-translator] - o Analysis on IPv6 Transition in 3GPP Networks - [I-D.ietf-v6ops-3gpp-analysis] - o Considerations for Mobile IP Support in NAT-PT - [I-D.lee-v6ops-natpt-mobility] + Generation Partnership Project (3GPP) Networks [I-D.elmalki- + sipping-3gpp-translator] + o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp- + analysis] + o Considerations for Mobile IP Support in NAT-PT [I-D.lee-v6ops- + natpt-mobility] o An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp) [I-D.tsuchiya-mtp] o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw] o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] Because the majority of the documents containing discussions of the issues are Internet Drafts which are unlikely to become RFCs, the issues are summarized here to avoid the need for normative references. @@ -180,71 +179,79 @@ interactions between DNS and NAT-PT. However, detailed inspection of [RFC2766] shows that the 'simple' case has not been worked out and it is unclear how information about the address translation could be passed to the hosts in the absence of the DNS-ALG. This document therefore assumes that the DNS-ALG is an integral part of NAT-PT: accordingly issues with the DNS-ALG must be considered as issues for the whole specification. Note that the issues which are not specifically related to the use of the DNS-ALG will apply to any network layer translation scheme, - including any based on the SIIT algorithm [RFC2765]. + including any based on the SIIT algorithm [RFC2765]. In the event + that new forms of translator are developed as alternatives to NAT-PT, + the generic issues relevant to all IPv6-IPv4 translators should be + borne in mind. - Issues raised with NAT-PT can be categorized as follows: - o Issues which are independent of the use of a DNS-ALG: + Issues raised with IPv6-IPv4 translators in general and NAT-PT in + particular can be categorized as follows: + o Issues which are independent of the use of a DNS-ALG and are, + therefore, applicable to any form of IPv6-IPv4 translator: * Disruption of all protocols which embed IP addresses (and/or ports) in packet payloads or which apply integrity mechanisms using IP addresses (and ports). * Inability to re-direct traffic for protocols without any demultiplexing capabilities or not built on top of specific transport layer protocols in situations where one NAPT-PT is translating for multiple IPv6 hosts. * Requirement for applications to use keep alive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout. * Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols. * Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation. * Interaction with SCTP and multihoming. * Need for NAT-PT to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility. * NAT-PT not being able to handle multicast traffic. - o Issues which are exacerbated by the use of a DNS-ALG: + o Issues which are exacerbated by the use of a DNS-ALG and are, + therefore also applicable to any form of IPv6-IPv4 translator: * Constraints on network topology. * Scalability concerns together with introduction of single point of failure and security attack nexus. * Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be - disrupted if a different mapping is used. The use of the - DNS-ALG to create address mappings with limited lifetimes means + disrupted if a different mapping is used. The use of the DNS- + ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keeping it alive once they start using it. + * Creation of a DOS threat relating to exhaustion of memory and address/port pool resources on the translator. - o Issues which result from the use of a DNS-ALG: + o Issues which result from the use of a DNS-ALG and are, therefore, + specific to NAT-PT as defined in [RFC2766]: * Address selection issues when either the internal or external hosts implement both IPv4 and IPv6. * Restricted validity of translated DNS records: a translated record may be forwarded to an application which cannot use it. * Inappropriate translation of responses to A queries from IPv6 nodes. - * Address selection issues and resource consumption in DNS-ALG with multi-addressed nodes. * Limitations on DNS security capabilities when using DNS-ALG. Section 2, Section 3 and Section 4 discuss these groups of issues. Section 5 examines the consequences of deploying NAT-PT for - application developers and the long term effects of NAT-PT on the - further development of IPv6. + application developers and the long term effects of NAT-PT or any + form of generally deployed IPv6-IPv4 translator on the further + development of IPv6. The terminology used in this document is defined in [RFC2663], [RFC2766] and [RFC3314]. 2. Issues Unrelated to DNS-ALG 2.1 Issues with Protocols Embedding IP Addresses It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] and [RFC3027]) that the large class of protocols which embed numeric @@ -267,26 +274,26 @@ coordinated updates of the ALGs to keep them in step. Assuming that the NAT-PT contains a co-located ALG for one of the relevant protocols, the ALG could replace the embedded IP addresses and ports. However this replacement can only happen if no cryptographic integrity mechanism is used and the protocol messages are sent in clear (i.e. not encrypted). A possible workaround relies on the NAT-PT being party to the security association used to provide authentication and/or - encryption. The NAT-PT should then be aware of the cryptographic - algorithms and keys used to secure the traffic and could modify and - re-secure the packets: this would certainly complicate network + encryption. NAT-PT would then be aware of the cryptographic + algorithms and keys used to secure the traffic. It could then modify + and re-secure the packets: this would certainly complicate network operations and provides additional points of security vulnerability. - Unless UDP encapsulation is used for IPsec [RFC3948], traffic using + Unless UDP encapsulation is used for IPsec [RFC3498], traffic using IPsec AH (in transport and tunnel mode) and IPsec ESP (in transport mode) are unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection. A related issue with DNS security is discussed in Section 4.5. 2.2 NAPT-PT Redirection Issues Section 4.2 of [RFC3027] discusses problems specific to RSVP and @@ -297,21 +304,22 @@ (and any other port translator) because there is nothing for NAPT-PT to use to identify the correct binding. This type of issue affects IPsec encrypted packets where the transport port is not visible (although it might be possible to use the SPI as an alternative demultiplexer) and protocols, such as RSVP, which are carried directly in IP datagrams rather than using a standard transport layer protocol such as TCP or UDP. In the case of RSVP, packets going from the IPv4 domain to the IPv6 domain do not necessarily carry a suitable demultiplexing field, because the port - fields in the flow identifer and traffic specifications are optional. + fields in the flow identifier and traffic specifications are + optional. Several ad hoc workarounds could be used to solve the demultiplexing issues, however in most cases these solutions are not documented anywhere which could lead to non-deterministic, undesirable behavior (for example, such workarounds often assume particular network topologies etc in order to function correctly; if the assumptions are not met in a deployment the workaround may not work as expected). This issue is closely related to the fragmentation issue described in Section 2.5. @@ -349,33 +357,32 @@ can lead to loss of information when packets are translated. Three issues arising from this are: o There is no equivalent in IPv4 for the flow label field of the IPv6 header. Hence any special treatment of packets based on flow label patterns cannot be propagated into the IPv4 domain. o IPv6 extension headers provide flexibility for improvements in the IP protocol suite in future. New headers may be defined in future which do not have equivalents in IPv4. In practice, some existing extensions such as routing headers and mobility extensions are not translatable. - o As described in section 2.2 of - [I-D.satapati-v6ops-natpt-applicability] there are no equivalents - in IPv6 for some ICMP(v4) messages, while for others (notably the - 'Parameter Problem' messages) the semantics are not equivalent. - Translation of such messages may lead to loss of information. - However, this issue may not be very severe because the error - messages relate to packets that have been translated by NAT-PT - rather than arbitrary packets. If the NAT-PT is functioning - correctly, there is, for example, no reason why IPv6 packets with - unusual extension headers or options should be generated. This - case is cited in [I-D.satapati-v6ops-natpt-applicability] as an - example where the IPv6 error has no equivalent in IPv4 resulting - in lost information. + o As described in section 2.2 of [I-D.satapati-v6ops-natpt- + applicability] there are no equivalents in IPv6 for some ICMP(v4) + messages, while for others (notably the 'Parameter Problem' + messages) the semantics are not equivalent. Translation of such + messages may lead to loss of information. However, this issue may + not be very severe because the error messages relate to packets + that have been translated by NAT-PT rather than arbitrary packets. + If the NAT-PT is functioning correctly, there is, for example, no + reason why IPv6 packets with unusual extension headers or options + should be generated. This case is cited in [I-D.satapati-v6ops- + natpt-applicability] as an example where the IPv6 error has no + equivalent in IPv4 resulting in lost information. Loss of information in any of these cases could be a constraint to certain applications. A related matter concerns the propagation of the Differentiated Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP field when translating packets. Accordingly the IPv4 and IPv6 domains must have equivalent Per-Hop Behaviors for the same code point or alternative means must be in place to translate the DSCP between domains. @@ -394,43 +401,44 @@ lead to the first fragment appearing at the NAPT-PT after later fragments. The NAPT-PT would then not have the information needed to translate the fragments received before the first. Although it would not be expected in normal operation, NAPT-PT needs to be proofed against receiving short first fragments which don't contain the transport port numbers. Note that such packets are a problem for IPv6 stateful packet inspection. The current specifications of IPv6 do not mandate any minimum packet size beyond the need to carry the unfragmentable part (which doesn't include the - transport port numbers) or reassembly rules to minimise the effects + transport port numbers) or reassembly rules to minimize the effects of overlapping fragments, leaving IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128]. An additional concern arises when a fragmented IPv4 UDP packet, which does not have a transport layer checksum, traverses a NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct the whole packet so that it can calculate the checksum needed for the translated IPv6 packet. This can result in significant delay to the packet, especially if it has to be re-fragmented before transmission on the IPv6 side. If NA(P)T-PT boxes reassembled all incoming fragmented packets (both from the IPv4 and IPv6 directions) in the same way as they have to do for unchecksummed IPv4 UDP packets, this would be a solution to the - first problem. The cost would be considerable: apart from the - potential delay problem if the outgoing packet has to be fragmented, - the NA(P)T-PT would consume extra memory and CPU resources, making - the NAT-PT even less scaleable (see Section 3.2). + first problem. The resource cost would be considerable apart from + the potential delay problem if the outgoing packet has to be re- + fragmented. In any case fragmentation would mean that the NA(P)T-PT + would consume extra memory and CPU resources, making the NAT-PT even + less scaleable (see Section 3.2). Packet reassembly in NA(P)T-PT also opens up the possibility of various fragment-related security attacks. Some of these are - analagous to attacks identified for IPv4. Of particular concern is a + analogous to attacks identified for IPv4. Of particular concern is a DOS attack based on sending large numbers of small fragments without a terminating last fragment which would potentially overload the reconstruction buffers and consume large amounts of CPU resources. 2.6 NAT-PT Interaction with SCTP and Multihoming The Stream Control Transmission Protocol (SCTP) [RFC2960] is a transport protocol which has been standardized since SIIT was specified. SIIT does not explicitly cover translation of SCTP, but SCTP uses transport port numbers in the same way as UDP and TCP so @@ -438,29 +446,29 @@ However, SCTP also supports multihoming. During connection setup SCTP control packets carry embedded addresses which would have to be translated. This would also require that the types of the options fields in the SCTP control packets were changed with consequent changes to packet length: the transport checksum would also have to be recalculated. The ramifications of multihoming as it might interact with NAT-PT have not been fully explored. Because of the 'chunked' nature of data transfer it does not appear that state would have to be maintained to relate packets transmitted using the - different IP addresses associated with the connection. [Author's - Note: This needs to be considered by an SCTP expert]. + different IP addresses associated with the connection. Even if these technical issues can be overcome, using SCTP in a NAT-PT environment may effectively nullify the multihoming advantages of SCTP if all the connections run through the same NAT-PT. The consequences of running a multihomed network with separate NAT-PT boxes associated with each of the 'homes' have not been fully explored, but one issue that will arise is described in Section 4.4. + SCTP will need an associated 'ALG' - actually a Transport Layer Gateway - to handle the packet payload modifications. If it turns out that state is required, the state would have to distributed and synchronized across several NAT-PT boxes in a multihomed environment. SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1. 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 @@ -459,27 +467,26 @@ out that state is required, the state would have to distributed and synchronized across several NAT-PT boxes in a multihomed environment. SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1. 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to propagate Mobile IPv6 control messages into the IPv4 domain. - According to the IPv6 Node Requirements - [I-D.ietf-ipv6-node-requirements], IPv6 nodes should normally be - prepared to support the route optimization mechanisms needed in a - correspondent node. If communications from an IPv6 mobile node is - traversing a NAT-PT, the destination IPv4 node is not going to - support the correspondent node features needed for route - optimization. + According to the IPv6 Node Requirements [I-D.ietf-ipv6-node- + requirements], IPv6 nodes should normally be prepared to support the + route optimization mechanisms needed in a correspondent node. If + communications from an IPv6 mobile node are traversing a NAT-PT, the + destination IPv4 node will certainly not be able to support the + correspondent node features needed for route optimization. This can be resolved in two ways: o The NAT-PT can discard messages and headers relating to changes of care-of addresses including reverse routing checks. Communications with the mobile node will continue through the home agent without route optimization. This is clearly sub-optimal but communication should remain possible. o Additional functionality could be implemented in the NAT-PT to allow it to function as a proxy correspondent node for all IPv4 nodes for which it has bindings. This scheme adds considerably to @@ -510,24 +517,25 @@ comprehensive approach which includes proxying of the multicast routing protocols is described in 'An IPv4 - IPv6 multicast gateway' [I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the issues described in this section, notably issues with embedded addresses. [I-D.okazaki-v6ops-natpt-security] identifies the possibility of a multiplicative reflection attack if the NAT-PT can be spoofed into creating a binding for a multicast address. This attack would be very hard to mount because routers should not forward packets with - muticast addresses in the source address field. However, it points - up that a naively implemented DNS-ALG could create such bindings from - spoofed DNS responses since [RFC2766] does not mention the need for - checks on the types of addresses in these responses. + multicast addresses in the source address field. However, it + highlights the possibility that a naively implemented DNS-ALG could + create such bindings from spoofed DNS responses since [RFC2766] does + not mention the need for checks on the types of addresses in these + responses. The issues for NAT-PT and multicast reflect the fact that NAT-PT is at best a partial solution. Completing the translation solution to cater for multicast traffic is likely to carry a similar set of issues to the current unicast NAT-PT and may open up significant additional security risks. 3. Issues exacerbated by the Use of DNS-ALG 3.1 Network Topology Constraints Implied by NAT-PT @@ -536,26 +544,26 @@ DNS-ALG in the NAT-PT to provide the mapped address needed to communicate with the flow destination on the other side of the NAT-PT. Whether used for flows initiated in the IPv4 domain or the IPv6 domain, the NAT-PT has to be on the path taken by the DNS query sent by the flow initiator to the relevant DNS server; otherwise the DNS query will not be modified and the response type would not be appropriate. The implication is that the NAT-PT box also has to be the default IPv6 router for the site in order that the DNS-ALG is able to examine - all DNS requests made over IPv6. On sites with both IPv6 and - dual-stack nodes, this will result in all traffic flowing through the + all DNS requests made over IPv6. On sites with both IPv6 and dual- + stack nodes, this will result in all traffic flowing through the NAT-PT with consequent scalability concerns. - These constraints are described in more detail in - [I-D.durand-natpt-dns-alg-issues]. + These constraints are described in more detail in [I-D.durand-natpt- + dns-alg-issues]. [I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows initiated from the IPv6 domain but it appears that this solution still has issues. For IPv6-only clients the solution requires the use of a DNS server in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT PREFIX (see [RFC2766]). Queries to this server would necessarily pass through the NAT-PT. Dual-stack hosts would use a separate DNS server accessed through a normal IPv6 address. This removes the need @@ -613,21 +621,21 @@ and the legitimate modification of packets in the NAT-PT make NAT-PTs enticing targets for security attacks. 3.3 Issues with Lack of Address Persistence Using the DNS-ALG to create address bindings requires that the application uses the translated address returned by the DNS query before the NAT-PT binding state is timed out (see Section 2.3). Applications will not normally be aware of this constraint, which may be different from the existing lifetime of DNS query responses. This - could lead to difficult diagnosis problems with applications. + could lead to 'difficult to diagnose' problems with applications. Additionally, the DNS-ALG needs to determine the initial lifetime of bindings which it creates. As noted in Section 2.3, this may need to be determined heuristically. The DNS-ALG does not know which protocol the mapping is to be used for, and so needs another way to determine the initial lifetime. This could be tied to the DNS response lifetime but this might open up additional DOS attack possibilities if very long validities are allowed. Also the lifetime should be adjusted once the NAT-PT determines which protocol is being used with the binding. @@ -650,24 +658,24 @@ 3.4 DOS Attacks on Memory and Address/Port Pools As discussed in Section 2.3 a NAT-PT may create dynamic NAT bindings each of which consumes memory resources as well as an address (or port if NAPT-PT is used) from an address (or port) pool. A number of documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security] discuss possible denial of service (DOS) attacks on NA(P)T-PT which result in resource depletion associated with address and port pools. NAT-PT does not specify any authentication mechanisms so that an - attacker may be able to create spurious binds by spoofing addresses - in packets sent through NAT-PT. The attack is more damaging if the - attacker is able to spoof protocols with long binding timeouts - (typically used for TCP). + attacker may be able to create spurious bindings by spoofing + addresses in packets sent through NAT-PT. The attack is more + damaging if the attacker is able to spoof protocols with long binding + timeouts (typically used for TCP). The use of the DNS-ALG in NAT-PT introduces another vulnerability which can result in resource depletion. The attack identified in [I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries traversing NAT-PT to create dynamic bindings. Every time a DNS query is sent through the NAT-PT the NAT-PT may create a new NA(P)T-PT bind without any end-host authentication or authorization mechanisms. This behavior could lead to a serious DOS attack on both memory and address or port pools. Address spoofing is not required for this attack to be successful. @@ -678,27 +686,27 @@ The ideal mitigation solution would be to disallow dynamically created binds until authentication and authorization of the end-host needing the protocol translation has been carried out. This would require that the proper security infrastructure be in place to support the authentication and authorization, which increases the network operational complexity. 4. Issues Directly Related to use of DNS-ALG -4.1 Address Selection Issues when Communicating with Dual-Stack - End-hosts +4.1 Address Selection Issues when Communicating with Dual-Stack End- + hosts [I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues with regard to address selection. As specified in [RFC2766], the DNS-ALG returns AAAA RRs from two possible sources to the IPv6 host - which has made an AAAA DNS query AAAA. + which has made an AAAA DNS query. If the query relates to a dual-stack host, the query will return both the native IPv6 address(es) and the translated IPv4 address(es) in AAAA RRs. Without additional information, the IPv6 host address selection may pick a translated IPv4 address instead of selecting the more appropriate native IPv6 address. Under some circumstances, the address selection algorithms will always prefer the translated address over the native IPv6 address which is obviously undesirable. [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which @@ -704,29 +712,28 @@ [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which involves modification to the NAT-PT specification intended to return only the most appropriate address(es) to an IPv6 capable host: o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT will forward the query to the DNS server in the IPv4 domain unchanged but using IPv4 transport: * If the authoritative DNS server has one or more AAAA records, it returns them. The DNS-ALG then forwards this response to the IPv6 host and does not send an A query as the standard NAT-PT would do. - * Otherwise, if the DNS server does not understand the AAAA query or has no AAAA entry for the host, it will return an error. The NAT-PT DNS-ALG will intercept the error or empty return and send an A query for the same host. If this query returns an IPv4 address, the ALG creates a binding and synthesizes a corresponding AAAA record which it sends back to the IPv6 host. o The NAT-PT thus forwards the result of the first successful DNS - response back to the end-host or an error if neither succeeeds. + response back to the end-host or an error if neither succeeds. Consequently only AAAA RRs from one source will be provided instead of two as specified in [RFC2766] and it will contain the most appropriate address for a dual-stack or IPv6-only querier. There is, however, still an issue with the proposed solution: o The DNS client may timeout the query if it doesn't receive a response in time. This is more likely because the NAT-PT may have to make two separate queries sequentially which the client is not aware of. It may be possible to reduce the response time by sending the two queries in parallel and ignoring the result of the @@ -799,21 +806,21 @@ addresses. The same may be true for multihomed IPv4 nodes. Responses to DNS queries for these nodes will normally contain all these addresses. Since the DNS-ALG in the NAT-PT has no knowledge which of the addresses can or will be used by the application issuing the query, it is obliged to translate all of them. This could be a significant drain on resources in both NAT-PT and NAPT-PT, as bindings will have to be created for each address. When using SCTP in a multihomed network, the problem is exacerbated - if multiple NAT-PTs translate mutiple addresses: also it is not + if multiple NAT-PTs translate multiple addresses: also it is not clear that SCTP will actually look up all the destination IP addresses via DNS so that bindings may not be in place when packets arrive. 4.5 Limitations on Deployment of DNS Security Capabilities Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key cryptographic signing to authenticate DNS responses. The DNS-ALG modifies DNS query responses traversing the NAT-PT in both directions which would invalidate the signatures as (partially) described in @@ -868,21 +875,21 @@ behavior of the application in native IPv6 and NAT-PT environments would be likely to be significantly different. 6. Security Considerations This document summarizes security issues related to the NAT-PT [RFC2766] specification. Security issues are discussed in various sections: o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP - encapsulation is not used [RFC3948]); and authentication and + encapsulation is not used [RFC3498]); and authentication and encryption are generally incompatible with NAT-PT. o Section 2.5 discusses possible fragmentation related security attacks on NAT-PT. o Section 2.8 discusses security issues related to multicast addresses and NAT-PT. o Section 3.3 highlights that NAT-PT is an enticing nexus for security attacks. o Section 3.4 discusses possible NAT-PT DOS attacks on both memory and address/port pools. o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC @@ -890,25 +897,24 @@ DNSSEC. 7. IANA Considerations There are no IANA considerations defined in this document. 8. Conclusion This document has discussed a number of significant issues with NAT-PT as defined in [RFC2766]. From a deployment perspective 3GPP - networks are currently the only 'standardised' scenario where an IPv6 + networks are currently the only 'standardized' scenario where an IPv6 only host communicates with an IPv4 only host using NAT-PT as - described in the 3GPP IPv6 transition analysis - [I-D.ietf-v6ops-3gpp-analysis] but NAT-PT has seen some limited usage - for other purposes. + described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp- + analysis] but NAT-PT has seen some limited usage for other purposes. Although some of issues identified with NAT-PT appear to have solutions, many of the solutions required significant alterations to the existing specification and would be likely to increase operational complexity. Even if these solutions were applied, we have shown that NAT-PT still has significant irresolvable issues and appears to have limited applicability. The potential constraints on the development of IPv6 applications described in Section 5 are particularly un desirable. It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a @@ -916,26 +922,25 @@ scenarios. However it is clear that in some circumstances a IPv6/IPv4 protocol translation solution may be a useful transitional solution, particularly in more constrained situations where the translator is not required to deal with traffic for a wide variety of protocols which are not determined in advance. It is therefore possible that a more limited form of NAT-PT could be defined for use in specific situations. - Accordingly the IETF no longer recommends its usage as a general - purpose IPv4/IPv6 transition mechanisms but NAT-PT will be retained - as an experimental mechanisms while further experience is gained and - any future replacement is defined and deployed. Consequently, we - request that RFC2766 is reclassified from Standards Track to - Experimental status. + Accordingly we recommend that the IETF no longer suggest its usage as + a general IPv4/IPv6 transition mechanism in the Internet but retain + it as an experimental mechanism while further experience is gained + and any future replacement is defined and deployed. Consequently we + recommend moving RFC2766 to experimental status. 9. Acknowledgments This work builds on a large body of existing work examining the issues and applicability of NAT-PT: the work of the authors of the documents referred in Section 1 has been extremely useful in creating this document. Particular thanks are due to Pekka Savola for rapid and thorough review of the document. 10. References @@ -950,27 +955,27 @@ February 2000. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications - with the IP Network Address Translator", RFC 3027, January - 2001. + with the IP Network Address Translator", RFC 3027, + January 2001. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., - Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header + Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. @@ -984,42 +989,43 @@ Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. [I-D.ietf-v6ops-3gpp-analysis] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in progress), October 2004. [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Massey, D., Larson, M. and S. + Arends, R., Austein, R., Massey, D., Larson, M., and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-13 (work in progress), October 2004. 10.2 Informative References - [RFC1858] Ziemba, G., Reed, D. and P. Traina, "Security + [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., - Zhang, L. and V. Paxson, "Stream Control Transmission + Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. - [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. - Stenberg, "UDP Encapsulation of IPsec ESP Packets", - RFC 3948, January 2005. + [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of + Managed Objects for Synchronous Optical Network (SONET) + Linear Automatic Protection Switching (APS) + Architectures", RFC 3498, March 2003. [I-D.satapati-v6ops-natpt-applicability] Satapati, S., "NAT-PT Applicability", draft-satapati-v6ops-natpt-applicability-00 (work in progress), October 2003. [I-D.durand-natpt-dns-alg-issues] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", draft-durand-natpt-dns-alg-issues-00 (work in progress), February 2002. @@ -1038,55 +1044,55 @@ Shin, M. and J. Lee, "Considerations for Mobility Support in NAT-PT", draft-lee-v6ops-natpt-mobility-00 (work in progress), June 2003. [I-D.okazaki-v6ops-natpt-security] Okazaki, S. and A. Desai, "NAT-PT Security Considerations", draft-okazaki-v6ops-natpt-security-00 (work in progress), June 2003. [I-D.vanderpol-v6ops-translation-issues] - Pol, R., Satapati, S. and S. Sivakumar, "Issues when + Pol, R., Satapati, S., and S. Sivakumar, "Issues when translating between IPv4 and IPv6", draft-vanderpol-v6ops-translation-issues-00 (work in progress), January 2003. [I-D.elmalki-sipping-3gpp-translator] Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks", draft-elmalki-sipping-3gpp-translator-00 (work in progress), December 2003. [I-D.tsuchiya-mtp] - Tsuchiya, K., Higuchi, H., Sawada, S. and S. Nozaki, "An + Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying - (mtp)", draft-tsuchiya-mtp-01 (work in progress), February - 2003. + (mtp)", draft-tsuchiya-mtp-01 (work in progress), + February 2003. [I-D.venaas-mboned-v4v6mcastgw] Venaas, S., "An IPv4 - IPv6 multicast gateway", draft-venaas-mboned-v4v6mcastgw-00 (work in progress), February 2003. [I-D.park-scalable-multi-natpt] Park, S., "Scalable mNAT-PT Solution", - draft-park-scalable-multi-natpt-00 (work in progress), May - 2003. + draft-park-scalable-multi-natpt-00 (work in progress), + May 2003. Authors' Addresses Cedric Aoun - Nortel Networks/ENST Paris + ENST + Paris France - Email: cedric.aoun@nortel.com - + Email: cedric@caoun.net Elwyn B. Davies Consultant Soham, Cambs UK Phone: +44 7889 488 335 Email: elwynd@dial.pipex.com Intellectual Property Statement