Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystems January 9, 2002 Expires July 10, 2002 Issues with NAT-PT DNS ALG in RFC2766 draft-durand-natpt-dns-alg-issues-00.txt Status of this memo This memo provides information to the Internet community. It does not specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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 Recent discussions on DNS over IPv6 transport have brought a better understanding on the impact of tools like NAT-PT (RFC2766). Several problems have been identified around the DNS ALG functionality. 1. Issues related to NAT-PT DNS ALG for outgoing connections 1.1 AAAA answers for A queries Within an IPv6 NAT-PT domain, an application asking for an A record could be returned a translated AAAA record. RFC2766 section 4.2: "...the DNS-ALG on the NAT-PT device forwards the original AAAA/A6 query to the external DNS system unchanged, as well as an A query for the same node. If an AAAA/A6 record exists for the destination, this will be returned to NAT-PT which will forward it, also unchanged, to the originating host. If there is an A record for Node-C the reply also returns to the NAT-PT. The DNS-ALG then, translates the reply adding the appropriate PREFIX and forwards it to the originating device with any IPv6 addresses that might have learned." RFC2766 is not clear on how a DNS-ALG should treat answers to A queries made by internal nodes. As a matter of fact, one could fear that a careless a DNS-ALG would also intercept them and translate them into a AAAA form. In other words, nodes asking for a A record could be returned a AAAA record. Although this may not be a problem for simple IPv6 only applications, it may be a concern for applications that 'walk through' the DNS structure and may pas information to peers. This is in contradiction to the spirit of RFC2826 [RFC2826], "IAB Technical Comment on the Unique DNS Root" that says: "The property of uniqueness allows a symbol to be used unambiguously in any context, allowing the symbol to be passed on, referred to, and reused, while still preserving the meaning of the original use." -------------------------------------------------------------------- => NAT-PT DNS ALG could break any application that passes records returned by the DNS to peers. In particular, this can add complexity to the operation of the DNS itself: zone transfer, operation in a mixed v4/v6 transport,... -------------------------------------------------------------------- Second, the application has no way of knowing that the returned AAAA address is actually not a real IPv6 one, but a IPv4 translated one. It may be led to believe that it's a real one and think "It's IPv6, so it has End to End IP connectivity, thus there will be no NAT in the middle and I can use any IPv6 specific options" -------------------------------------------------------------------- => Applications behind a NAT-PT DNS ALG may think they use IPv6 when they are actually using IPv6 + NAT-PT + IPv4. -------------------------------------------------------------------- 1.2. Source Address Selection/Destination address ordering The translated AAAA record points to an IPv6 address that belongs to the site IPv6 prefix. Let's assume that an IPv6 node X within a NAT-PT domain wants to communicate with a dual-stack host Y on the public Internet. That host Y has published both IPv4 (A) and IPv6 (AAAA) addresses in the DNS. When X will query A and AAAA for Y, it will be returned 2 AAAA. One will be the actual IPv6 address of Y and the other one the "translated" IPv4 address. As the prefix associated to the translated address belongs to same site as X''s IPv6 address, when X will use source address selection/destination address ordering it will result to longest prefix match and will choose the "translated" address over the native one. -------------------------------------------------------------------- => The communication between a node within the NAT-PT domain and a external dual stack host will select the translated path over the native IPv6 path. -------------------------------------------------------------------- 1.3. NAT-PT & IPv6 default router NAT-PT ALG makes the assumption that the DNS traffic goes through the NAT-PT box. This is OK is DNS resolution is done over IPv4. However, if it is done over IPv6, there is no reason why the DNS traffic will still go through the NAT-PT box unless the NAT-PT box is also the default IPv6 router of the site. -------------------------------------------------------------------- => For NAT-PT to work correctly with DNS-ALG, it requires that the NAT-PT box be the only default IPv6 router of the NAT-PT domain. This works fine for small networks but raises some scalibity issues when applied to large networks or for networks with multiple exit routes. -------------------------------------------------------------------- 1.4. DNS-sec Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS- sec. It would work if all the DNS resolution were done over IPv6, but in a mixed environment as described in draf-ietf-ngtrans-dns- ops-req-03.txt, this will be a problem. -------------------------------------------------------------------- => DNS-sec is not deployable within a NAT-PT doamin with DNS-ALG. If NAT-PT is widely deployed, it would become be a serious obstacle to the large scale deployment of DNS-SEC. -------------------------------------------------------------------- 2. Issue is related to NAT-PT DNS ALG for incoming connections. 2.1. Incoming address pool exhaustion. Section 4.1 proposes to allocate an IPv4 address from the external pool each time a DNS lookup is perform from the outside for a internal name. RFC2766 recognize this is a potential problem and says: "address mappings for incoming sessions should time out to minimise the effect of denial of service attacks." -------------------------------------------------------------------- => Even with short time out, it is very easy for an attacker to create a DoS attack just by repetitively querying the DNS for all known internal domain names. As the minimum DNS timeouts are usually in seconds, such DOS would be much more devastating as simple flooding as it only requires very limited bandwith to be effective. -------------------------------------------------------------------- 3. Security considerations Section 1.4 and 2.1 discuss the potential security impact of RFC2766. 4 Authors addresses Alain Durand SUN Microsystems, Inc 901 San Antonio Road UMPK17-202 Palo Alto, CA 94303-4900 USA Mail: Alain.Durand@sun.com 5. References [RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000 [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000