Subject: RE: rfc1918 impact

From: "Michel Py" <[email-masked]>
Date: Wed, 15 Oct 2003 14:24:37 -0700

Leif / Iljitsch,

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

>> Leif Johansson wrote:
>> 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

Keith will not like it, but NAT vendors will take suggestions that will
make NAT better. In this case, having in the NAT box a DNS proxy that
forwards reverse lookups for public addresses to the ISP's DNS servers
and replies a blanket reply for RFC1918 addresses does not look to much
work. That box could also accept dynamic address registration that is
default in the latest MS products. Even if _we_ have a DNS server at
home Joe-Six-Pack does not, therefore the place for that animal is in
the NAT box indeed. You want to convince NAT box vendors to implement
it? Tell them that if they do, Keith will stop beating the crap out of
them :-)

> Iljitsch van Beijnum wrote:
> RFC 2827 provides exactly these recommendations.

Does it? We are not talking about blocking RFC1918 traffic here; what we
are talking is blocking traffic where both SA(after NAT) and DA are
public that contains a DNS request for a PRT like 8191CFR.in-addr.arpa,
which requires to decapsulate the packet to inspect its content. It's
not that simple.

Michel.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2003 23:46:03 +0200

>> RFC 2827 provides exactly these recommendations.

[FYI: RFC 2827 is about ingress filtering to stop source address 
spoofing]

> Does it? We are not talking about blocking RFC1918 traffic here;

I was.

> what we

I don't feel that a lookup for <something>.10.in-addr.arpa is all that 
wrong. This can be handled in many very reasonable ways, and the usual 
caching applies. Requests with unroutable sources are wrong because 
they break the protocol.

Iljitsch

---

From: Daniel Senie <[email-masked]>
Date: Wed, 15 Oct 2003 17:45:41 -0400

At 05:24 PM 10/15/2003, Michel Py wrote:
>work.

It also may be ill-advised, unless a switch is present for disabling it.

While we can argue ISPs should not use RFC 1918 space, there are many using 
it, including some who use it because their equipment vendors force them to 
do so (Cisco in the CMTS routing space comes to mind. Do a traceroute out 
from behind a cable modem, and the head-end router responds with a 10/8 
address. Nice job folks).

>  That box could also accept dynamic address registration that is
>default in the latest MS products.

accept, or INTERCEPT? Intercepting the traffic would be nice. After all, 
NAT boxes usually (not always, so a disabling switch would be a good idea) 
are at an administrative border (i.e. gateway to home or office). Those DNS 
updates should not be travelling beyond administrative boundaries in most 
cases.

>  Even if _we_ have a DNS server at

Heh. Router vendors would likely be interested because it's a good thing to 
do. As for the part about Keith...

>which requires to decapsulate the packet to inspect its content. It's

Agree. RFC 2827 only discusses filtering packets whose source address is 
inappropriate for crossing a border. When NAT is used, it's rare (if the 
implementation is any good) to have a problem with bogus source addressed 
packets leaving the private network.

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Oct 2003 18:36:55 -0400

> Keith will not like it, but NAT vendors will take suggestions that
> will make NAT better.

I'd be happy for them to take suggestions from me, or IETF.  But there's
a big difference between saying "if you must do NAT, please do it this
way" and "NATs are good if they are implemented this way"