Internet DRAFT - draft-durand-natpt-dns-alg-issues
draft-durand-natpt-dns-alg-issues
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
