Subject: (ngtrans) NAT-PT DNS ALG issues

From: Alain Durand <[email-masked]>
Date: Thu, 21 Feb 2002 15:42:45 -0800

I've just published a draft outlining some issues related to the DNS ALG
part of NAT-PT.

	- Alain.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Issues with NAT-PT DNS ALG in RFC2766
	Author(s)	: A. Durand
	Filename	: draft-durand-natpt-dns-alg-issues-00.txt
	Pages		:
	Date		: 20-Feb-02

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-durand-natpt-dns-alg-issues-00.txt
--

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 22 Feb 2002 10:57:47 -0500

Hi Alain,

First of all a disclaimer. I am not surprised that several problems have
surfaced with DNS-ALGs; what I am surprised about is the fact that it was
ever allowed to be part of a standards track RFC :-0 Even at the time I was
arguing that this (and anything NAT related) should be at best
Informational. I am not a huge fun of NAT-PT, I have never promoted it as a
serious solution to anything, certainly not as solution for large
deployments (e.g.: 3G) and I am actually surprised it ever became so
popular....eehhm, please do not ask me why I wrote the draft :-)

Anyway, do you have a suggestion about how to proceed? your draft only
points to "issues"...no suggestions. As a co-author I have no problems if
the WG wants to review and change the spec. My only problem is time...of
which I have very little to spend on this. I can contribute maybe but I will
need help if any changes are required.

Regards
George 

Here are some comments on <draft-durand-natpt-dns-alg-issues-00.txt>:

...

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

GT> Well, that was the idea....i.e.: a stub network with IPv6 ONLY devices
to be able to talk to IPv4 devices external to this stub network.

...

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

GT> Indeed this is true. At the time we did suggest that such translated
addresses to be identifiable and thus be assigned with low priority in terms
of address selection but I think this was rejected; people did not want to
define yet another type of address.

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

GT> Yes indeed...I am actually amazed that 3G is talking about using
NAT-PT...good luck to them.

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

GT> Yes, as stated in the RFC...

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

GT> Yes, we state this in the spec very clearly I think.

-----Original Message-----
From: Alain Durand [mailto:[email-masked]]
Sent: Thursday, February 21, 2002 11:43 PM
To: [email-masked]
Subject: (ngtrans) NAT-PT DNS ALG issues

	- Alain.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

---

From: Alain Durand <[email-masked]>
Date: Fri, 22 Feb 2002 11:25:23 -0800

At 8:38 AM -0800 2/22/02, Christian Huitema wrote:
>
>NAT-PT is clearly a "third phase" product, something that is needed by
>those networks who wish to simply remove internal support for IPv4.
>(DSTM occupies the same niche.) This means that such products are less
>urgent than phase 1 products such as 6to4, Shipworm/Teredo, or the
>management of configured tunnels. It also means that we have some time
>to "do it right."

Well, IMHO, there are 2 ways to deploy IPv6.
One is in existing environment where you want to gradually infuse IPv6
and then you're right.
The other one is for (very) large scale networks which are starting 
from scratch.
There is a temptation to do IPv6 only in the beginning, mainly 
because there are so
large, that their 'perceived value' according to Meltcafe law (the 
square of the
number of users) is very important. Those network are directly in "phase 3"
and need a way to talk to the rest of the Internet. This seems to me the
reason why some 3G folks have been looking at solution like NAT-PT.

Now, what my analysis points out, is that NAT-PT, in its current form, is not
suitable for such networks. There are ways to fix the issues, I did not
discuss them in the draft, and I think they are worth pursuing if:
a) people agrees that the issues I raised need to be fixed
b) there is enough interest in the wg to do so.

As explained in the new charter, we would like this wg to focus first
on transitioning the infrastructure, and 3G is one of the components we
have to look at. If it appears during this analysis that a solution is needed
in that space, we'll have to fix NAT-PT, and we'll have hopefully a set
of requirements on what a  translation mechanism for 3G should be.

note also that there are other areas that require a  translation
mechanism to operate in IPv4 only, dual stack and IPv6 only mode.
DNS is a case (see draft-ietf-ngtransdns-ops-req-03),  SMTP is another...
As one day itojun pointed out, it would be nice if we could rely on a generic
translation mechanism for all those applications.

	 - Alain.

--