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

[Alain Durand <[e-mail]>]

On Saturday, July 13, 2002, at 08:27 PM, [e-mail] wrote:

First of all, thanks for your comments.

> 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.

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.


>  ...
>
>    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?

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


>
> 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.

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


>
> 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.

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.


> 1.4. DNS-sec
>
>  ...
>
>    DNS-sec is not deployable within a NAT-PT doamin with DNS-ALG
>
> => 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.


> 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.
>

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.