Subject: (NAT) NAT operational issue

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Mar 1999 14:57:40 +0000

Here's an indication that one of the inherent dangers of 
NATs (leakage) is a real operational problem. Any ideas
how to stop this happening?

   Brian

-----Original Message-----
From:   [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] <mailto:[mailto:[email-masked]]> 
Sent:   Friday, February 26, 1999 11:41 AM
To:     [email-masked] <mailto:[email-masked]> 
Subject:        buggy server re-directors?  buggy NATs?  Too much RFC 1918
traffic on the net!

I've been seeing a growing amount of traffic of various sorts from
various public internet sites that has a source address in an RFC 1918
private net.

In some cases because I have servers running multi-homed on
administrative LANs which use these private networks, and because I've
installed filters to ensure traffic isn't coming from the wrong nets on
the wrong interfaces, this is even causing some services and requests to
fail.  (Eg. source quenches coming from private nets where even if the
filters didn't exist the desired effect is not achieved.)

I'm also seeing a growing number of requests on a couple of my
transparent web cache machines that seem to be directed at hosts in RFC
1918 private networks -- i.e. it would appear as though the URLs refer
either directly to private networks, or perhaps some domain names used
in publicly accessible URLs resolve to point at private nets.

I'm almost tempted to try and implement a DNS proxy that'll refuse to
allow any responses from foreign nameservers to contain RFC 1918
addresses (and of course ensure that my internal DNS is authoritative
for all the necessary in-addr.arpa zones).

I suspect what's happening is that people are putting load-balanced
servers behind service re-directors and are running these servers on RFC
1918 private networks in hopes that the re-director will do the
appropriate NAT.  Unfortunately most of these re-directors are not yet
sophisticated enough to work as full proxies, and they often fail to
properly translate associated packets, such as related ICMP traffic.
(As has been amply evidenced by the extremely common failure of Path-MTU
discovery from several such load-balancing devices.)

In cases where I can identify the owners of the errant servers from my
filter logs and/or from simple tcpdump traces I do attempt to contact
them.  However I'd rather try a more preventative approach, perhaps by
making this issue more widely known, and perhaps by educating vendors
and implementors of devices that might be causing these problems of what
mistakes they might be making.

I'm interested in exchanging information about these issues with other
operators and in trying to track down and identify devices that might be
letting some such private traffic slip through, and of course in helping
to find and implement fixes to these problems.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <[email-masked] <mailto:[email-masked]> >
<robohack!woods>
Planix, Inc. <[email-masked] <mailto:[email-masked]> >; Secrets of the
Weird <[email-masked] <mailto:[email-masked]> >
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 02 Mar 1999 10:42:45 -0500

> how to stop this happening?

Brian,

This isn't necessarily a NAT issue at all. Some providers are using
RFC1918 space for their routers and such, which results in traceroutes
spraying back from RFC1918 space. I find this poor practice, but given
the push to conserve address space, some folks are going WAY too far...
My upstream is @Home network, and they are heavy users of RFC1918 space.
I've complained about this on several occasions. If I'd known they built
their network this way, I would not have signed a contract with them.

So, while it's certainly possible the leaks are coming from poorly
implemented NAT deployments, there are a LOT of folks using RFC1918 in
other places and doing a bad job of it.

I would dearly like to see all ISPs doing ingress filtering. I'm quite
willing to write a proposed BCP that states that providers MUST NOT leak
private address space addresses out of their network (source or
destination address).

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 02 Mar 1999 13:38:20 -0500

> private address space addresses out of their network (source or

It's worth noting that if routers in the path have RFC1918 addresses,
filtering based on source addresses will break Path MTU discovery
(since it relies on getting error messages from intermediate routers).

There are enough PMTUD black holes out there.. let's not add any more.

					- Bill
-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Mar 1999 11:02:54 +0000

Huh?

If there are routers in the ISP path with 1918 addresses, it seems
to me that much more than MTU discovery will end up broken.

    Brian

-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Mar 1999 11:48:09 +0000

Daniel,

RFC 1918 is a BCP and it says:

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links. Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks. If such a router receives
   such information the rejection shall not be treated as a routing
   protocol error.

   Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses. In particular, Internet service providers should take
   measures to prevent such leakage.   

It seems to me that that already says most of what needs to be said.
The problem is, from what you say, that some operators are blowing it.

     Brian

-

---

From: Daniel Senie <[email-masked]>
Date: Wed, 03 Mar 1999 09:41:37 -0500

> The problem is, from what you say, that some operators are blowing it.

Guess it's been a while since I read the full text. Yes, it says exactly
what's needed. Now the question is, "why is at least one major ISP
ignoring it?" The ISP I'm aware of that's doing this is @Home network.
They set their MTUs everywhere to 1500, presumably in the belief that
this would take care of the PMTUD problems, but that doesn't work in all
cases.

It's my guess that @Home is far from the only ISP/NSP network which is
doing this. With the emphasis on conserving globally routable address
space, folks are going off the deep end trying to conserve. What got me
most annoyed initially with @Home's use of RFC1918 addresses is that it
makes it difficult for enterprises to do proper filtering per the RFC.
If I'm using 10.x.x.x inside a corporate network attached to @Home, I
cannot filter out all 10.x.x.x addresses (source or dest) to/from
outside my network or else I'll have trouble with communications to some
@Home equipment.

I'd like to hear of other providers who are violating this BCP. Of
course there's not a lot we can do about the violations other than
public ostracism...
-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 03 Mar 1999 12:00:17 -0500

> to me that much more than MTU discovery will end up broken.

Without naming names, at least two cable modem providers are using
RFC1918 addresses for interior routers.

At least one other (and probably the two implied above as well) are
using RFC1918 space for the cable modems themselves (which, in that
network at least, are bridges, not routers, and have ip addresses only
for management purposes, which seems OK, I guess..).

					- Bill
-