Subject: RE: rfc1918 impact

From: "Michel Py" <[email-masked]>
Date: Wed, 15 Oct 2003 18:44:53 -0700

Daniel / Iljitsch,

> Daniel Senie wrote:
> [NAT box acting as a DNS server]
> It also may be ill-advised, unless a switch is present for disabling
it.

Of course.

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

Indeed. However, one should consider the trade-off between having
blanket reverse resolution for RFC1918 hops vs. flooding the roots with
bogus requests. Besides, for what I have seen these ISPs that use
RFC1918 space for links do not provide reverse lookup for them anyway
:-(

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

> Daniel Senie wrote:
> 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.

Both accept and intercept are needed.

For accept, what we are looking at is as follows: The NAT box is also
the DHCP server and gives its own address for the DNS server. Then MS
hosts register with it, making it possible not only to return something
for an RFC1918 reverse lookup and not flood the roots, but also to
return the actual host name instead of a blanket name. If using DHCP,
the MS host on the inside could try to register with a DNS server
outside: it does not know its address and registration to a broadcast
address would not be forwarded.

Intercept would be nice in the following situations:
- When Joe Blow has configured a static IP and static DNS servers that
point to the ISP's DNS servers instead of the NAT box.
- When the NAT box is not the DNS server and there is no other DNS
server.
I both cases, intercept would discard the packets of clients trying to
register with the ISP's DNS servers. This would require a comprehensive
implementation: the box should intercept dynamic DNS registration
packets and reverse lookups with an RFC1918 target, but allow other
requests.

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

>> Michel Py wrote:
>> 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.

> Daniel Senie wrote:
> 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.

Rare indeed, because if the source address is private it is unlikely
that the reply would ever get back to the requester, and NAT
implementations that break DNS do not make it to the market.

Michel.

---

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

> point to the ISP's DNS servers instead of the NAT box.

so the next time Joe Blow is trying to figure out why a particular DNS server
isn't responding correctly by explicitly sending it queries, the NAT box
will intercept the queries, forge replies, and mask the problem.

Keith