Subject: RE: Removing features

From: "Michel Py" <[email-masked]>
Date: Wed, 15 Oct 2003 08:00:46 -0700

> Keith Moore wrote:
> great.  now we'll have NAT boxes intercepting
> outgoing DNS traffic also.

That was not my point. My point was to have a DNS server in the inside
configured for reverse lookup of private IPs. What you mention would
help though.

Michel.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 15 Oct 2003 17:42:54 +0200

-----BEGIN PGP SIGNED MESSAGE-----

> configured for reverse lookup of private IPs. What you mention would

Which most people already have when configuring their local network
as they setup a local DNS server. Usually NAT boxes also include
a DNS server btw. Even my Alcatel Speedtouch *adsl modem* has one.
But I gladly use a much easier to configure bind ofcourse ;)

People not configuring these DNS servers usually use their ISP's
DNS servers and these should comply to AS112 standards, aka
serve empty versions of the rfc1918 zones and make themselves authoritive.
Afaik the latest bind distributions include at least setup examples
for rfc1918 addresses.

Shouldn't there be a BCP for such cases? Aka that ISP's should
have rfc1918/localhost/169.254.x.x zones in the DNS servers that
face their customers?

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Oct 2003 11:58:24 -0400

> configured for reverse lookup of private IPs. 

one of the most-frequently cited justifications for NAT is plug-and-play.
expecting people to set up their own DNS servers sort of nullifies that.

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Oct 2003 13:21:07 -0400

--On Wednesday, 15 October, 2003 11:58 -0400 Keith Moore 
<[email-masked]> wrote:

>> That was not my point. My point was to have a DNS server in
>> the inside configured for reverse lookup of private IPs.
>
> one of the most-frequently cited justifications for NAT is
> plug-and-play. expecting people to set up their own DNS
> servers sort of nullifies that.

Keith, two observations...

(1) Yes, I think, and think we are in agreement, that this sort 
of thing digs the NAT hole even deeper.

(2) But the typical plug-and-play NAT, at least the ones I have 
run across, is preconfigured with the addresses to be used on 
the "inside" and contains (or is intimately paired with) a DHCP 
server that gives out those addresses.  Installing a DNS filter 
in the thing that would intercept PTR queries for that address 
range, or any 1918 address range, and respond to them in some 
"canned" way while passing other DNS queries out to the network 
as intended is not rocket science and certainly doesn't violate 
any plug-and-play arguments.

Now, whether that interception and diversion of DNS queries is a 
moral activity is a different question.    But, if you believe 
strongly enough that having a NAT in the first place puts one 
into a serious state of sin, then the marginal sin of 
intercepting DNS queries for private addresses, to prevent the 
sort of problems those queries cause, seems to me to be fairly 
small.

"where are we going and what are we doing in this handbasket?"

   john

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Oct 2003 13:45:23 -0400

> sort of problems those queries cause, seems to me to be fairly 

I probably agree.  But I guess my question is "where does it end?"

That is, how many things do we change elsewhere in the network in order
to minimize the operational problems that crop up with NATs?  What is
the cost of those changes, and how much do they impair the ability of
the network to support applications?

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Oct 2003 14:10:04 -0400

--On Wednesday, 15 October, 2003 13:45 -0400 Keith Moore 
<[email-masked]> wrote:

>> Now, whether that interception and diversion of DNS queries
>> is a  moral activity is a different question.    But, if you
>> believe  strongly enough that having a NAT in the first place
>> puts one  into a serious state of sin, then the marginal sin
>> of  intercepting DNS queries for private addresses, to
>> prevent the  sort of problems those queries cause, seems to
>> me to be fairly  small.
>
> That is, how many things do we change elsewhere in the network
> in order to minimize the operational problems that crop up
> with NATs?  What is the cost of those changes, and how much do
> they impair the ability of the network to support applications?

That, it seems to me, is a pragmatic way to state the key 
architectural question.  A different version of it, borrowed 
from a different debate, is how much a particular new capability 
is permitted to force deployed systems or applications code to 
change the way they are doing things in the interest of the 
innovation contained in that new capability.

     john

---

From: Leif Johansson <[email-masked]>
Date: Wed, 15 Oct 2003 22:10:33 +0200

<snip>

|
| (2) But the typical plug-and-play NAT, at least the ones I have run
| across, is preconfigured with the addresses to be used on the "inside"
| and contains (or is intimately paired with) a DHCP server that gives out
| those addresses.  Installing a DNS filter in the thing that would
| intercept PTR queries for that address range, or any 1918 address range,
| and respond to them in some "canned" way while passing other DNS queries
| out to the network as intended is not rocket science and certainly
| doesn't violate any plug-and-play arguments.

So where is the the leak coming from? If what people claim is true and
if not all, but most NAT-boxes are configured with inside DNS, filtering
and extra cheese, where, I ask you do all of those root-zone requests
and other rfc1918 leaks come from?

	Cheers Leif

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Oct 2003 14:19:16 -0400

--On Wednesday, 15 October, 2003 22:10 +0200 Leif Johansson 
<[email-masked]> wrote:

>| (2) But the typical plug-and-play NAT, at least the ones I
>| have run across, is preconfigured with the addresses to be
>| used on the "inside" and contains (or is intimately paired
>| with) a DHCP server that gives out those addresses.
>| Installing a DNS filter in the thing that would intercept PTR
>| queries for that address range, or any 1918 address range,
>| and respond to them in some "canned" way while passing other
>| DNS queries out to the network as intended is not rocket
>| science and certainly doesn't violate any plug-and-play
>| arguments.
>

Leif,

I was speaking to the architectural issue, not the deployment 
one.  None of the three plug and play boxes I have here with NAT 
capability has any inside DNS capability (either enabled by 
default or available to be turned on).

It does sound like a recommendation to the effect of "if you are 
going to use NAT, or construct a NAT box, then an 'inside DNS' 
mechanism" would be a reasonable idea.  And I would assume it 
would be an even better one if it made clear what the preferred 
way was to do an "inside DNS" -- I think there might be a couple 
of different ways to do it, and some might be less reprehensible 
than the others.

    john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2003 21:08:24 +0200

On 15 okt 2003, at 19:45, Keith Moore wrote:

>> the marginal sin of

> I probably agree.  But I guess my question is "where does it end?"

It ends when IPv4 ends. That is, if we can keep NAT out of IPv6.

> the network to support applications?

There is no answer for these questions. Everyone can unilaterally 
decide to run stuff like NATs. That's actually a strength of our 
archictecture. Also, anyone can unilaterally decide to send traffic. 
That's a big issue with our architecture. Fixing the latter (so, 
amongst other things, root nameservers aren't forced to receive traffic 
from RFC 1918 sources) without getting in the way of the former isn't 
going to be easy.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 15 Oct 2003 23:09:56 +0200

<snip>

|
| Leif,
|
| I was speaking to the architectural issue, not the deployment one.  None
| of the three plug and play boxes I have here with NAT capability has any
| inside DNS capability (either enabled by default or available to be
| turned on).

Exactly! Now why is that?

| It does sound like a recommendation to the effect of "if you are going
| to use NAT, or construct a NAT box, then an 'inside DNS' mechanism"
| would be a reasonable idea.  And I would assume it would be an even
| better one if it made clear what the preferred way was to do an "inside
| DNS" -- I think there might be a couple of different ways to do it, and
| some might be less reprehensible than the others.
|

Of course (I am beeing intentionally obtuse) but isn't it quite unlikely
that any recommendation the we make at this point will have any impact
on how v4 NAT is deployed - we are after all talking about kazillions of
adsl modems, SOHO-routers etc etc? Do you believe that things will be
different with v6 NAT, I.e what are the interoperability problems a NAT
vendor will have unless they implement NAT 'correctly'?

	Cheers Leif

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2003 22:41:38 +0200

> that any recommendation the we make at this point will have any impact

RFC 2827 provides exactly these recommendations. Unfortunately many 
operators still can't be bothered or use prehistoric equipment that 
can't handle the filtering.