Subject: (ngtrans) Comments on draft-durand-natpt-dns-alg-issues-00.txt

From: [email-masked]
Date: Sun, 14 Jul 2002 04:27:09 +0100

Alain,

Some comments on your draft:

1.1 AAAA answers for A queries

 ...

   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.

=> Agreed that RFC2766 probably needs to be more explicit about this.
However, DNS-ALGs exist that are very careful about when to relay, and when
to translate. They work well in practice.

 ...

   Applications behind a NAT-PT DNS ALG may think they use IPv6 when
   they are actually using IPv6 + NAT-PT + IPv4.

=> Application transparency is a bad thing? Do you think there is a need for
signalling to indicate that translation is occurring?

1.2. Source Address Selection/Destination address ordering

 ...

   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.

=> This is only true of the sort of 'sloppy' implementations referred to
above. If implementors are careful about when they relay and when they
translate, this problem does not arise.

1.3. NAT-PT & IPv6 default router

 ...

   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.

=> We've been running IPv6 networks where our NAT-PT box is not the default
IPv6 router for several years. The only requirement here is that the local
IPv6 DNS forwards to an IPv4 located DNS via NAT-PT.

1.4. DNS-sec

 ...

   DNS-sec is not deployable within a NAT-PT doamin with DNS-ALG

=> Yes, NAT breaks end-to-end security.

2.1. Incoming address pool exhaustion.

 ...

   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

=> Outgoing connections from the NAT-PT domain can easily be protected in
the presence of such attacks by reserving at least one pool address for
NAPT-PT. Important services hosted within the NAT-PT domain can also be
protected by allocating static IPv4 address mappings. Finally, in order for
an attacker to exhaust the available pool of IPv4 addresses, the attacker
would have to know or discover a number of domain names for distinct
internal addresses equal to the size of the incoming address pool.

 -- Mat.

---

From: Alain Durand <[email-masked]>
Date: Sun, 14 Jul 2002 01:20:44 -0700

On Saturday, July 13, 2002, at 08:27 PM, [email-masked] wrote:

First of all, thanks for your comments.

> to translate. They work well in practice.

The fact that some implementations appear to work fine does not
change the fact that the RFC is not clear and need to be fixed.

> signalling to indicate that translation is occurring?

An application that knows it does not work fine over a NAT box may
want to know.

> translate, this problem does not arise.

This relay vs translate behavior is not documented in the RFC.

> IPv6 DNS forwards to an IPv4 located DNS via NAT-PT.

What you are suggesting is to forbid recursive resolvers within
the NAT-PT domain. a) you'll have to find an open DNS relay
and b) this will not scale very well.

> => Yes, NAT breaks end-to-end security.

You are confusing IPsec and DNSsec.
Yes, NAT breaks IPsec, but does not break DNSsec.
In that regard, NAT-PT is worse than NAT.

> internal addresses equal to the size of the incoming address pool.

Sure you can always limit incoming NAT-PT to a few selected hosts
and have a static mapping. But this does not change the fact that
if you want incoming NAT-PT to work for any hosts, it will be open
to DOS.

	- Alain.