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

matthew.ford@bt.com Sun, 14 July 2002 03:30 UTC

Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13252 for <ngtrans-archive@odin.ietf.org>; Sat, 13 Jul 2002 23:30:08 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01231; Sat, 13 Jul 2002 21:30:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22449; Sat, 13 Jul 2002 20:29:50 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6E3TEoN015807 for <ngtrans-dist@sunroof.eng.sun.com>; Sat, 13 Jul 2002 20:29:14 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6E3TE6i015806 for ngtrans-dist; Sat, 13 Jul 2002 20:29:14 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6E3TCoN015799 for <ngtrans@sunroof.eng.sun.com>; Sat, 13 Jul 2002 20:29:12 -0700 (PDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v2.1p1) with ESMTP id UAA22393 for <ngtrans@sunroof.eng.sun.com>; Sat, 13 Jul 2002 20:29:15 -0700 (PDT)
From: matthew.ford@bt.com
Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26218 for <ngtrans@sunroof.eng.sun.com>; Sat, 13 Jul 2002 20:29:14 -0700 (PDT)
Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Sun, 14 Jul 2002 04:28:45 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2654.89) id <NZ8ZT3GV>; Sun, 14 Jul 2002 04:25:31 +0100
Message-ID: <F66469FCE9C5D311B8FF0000F8FE9E070A924F66@mbtlipnt03.btlabs.bt.co.uk>
To: alain.durand@sun.com
Cc: ngtrans@sunroof.eng.sun.com
Subject: (ngtrans) Comments on draft-durand-natpt-dns-alg-issues-00.txt
Date: Sun, 14 Jul 2002 04:27:09 +0100
X-Mailer: Internet Mail Service (5.5.2654.89)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: matthew.ford@bt.com

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.