At 09:22 AM 5/23/2006, Robert Bonomi wrote:
Date: Tue, 23 May 2006 03:33:34 -0400 From: Richard A Steenbergen <ras@e-gerbil.net> To: nanog@nanog.org Subject: Re: private ip addresses from ISP
On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP?
...
From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise
Sorry to dig this up from last week but I have to strongly disagree with point #3. 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.
The ISP shouldn't be "leaving" anything to the end-user, these packets should be dropped as a matter of course, along with any routing advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space into my network piss me off, and get irate phone calls for their trouble.
The section you quoted from RFC1918 specifically addresses routes, not packets.
I quote, from the material cited above: " ..., and packets with private source or destination addresses should not be forwarded across such links. ... "
There are some types of packets that can legitimately have RFC1918 source addresses -- 'TTL exceeded' for example -- that one should legitimately allow across network boundaries.
Really? You really want TTL-E messages with RFC1918 source addr? Even if they're used as part of a denial of service attack? Even though you can't tell where they actually came from?
If you're receiving RFC1918 *routes* from anyone, you need to thwack them over the head with a cluebat a couple of times until the cluey filling oozes out. If you're receiving RFC1918 sourced packets, for the most part you really shouldn't care.
*I* care.
When those packets contain 'malicious' content, for example.
When the provider =cannot= tell me which of _their_own_customers_ originated that attack, for example. (This provider has inbound source-filtering on their Internet 'gateway' routers, but *not* on their customer-facing equipment (either inbound or outbound.)
So you really don't want ANY packets with RFC 1918 source addresses then, not even ICMP TTL-E messages, since they could be used in a malicious fashion, and you would not be able to determine the true origin.
It's even more comical when the NSP uses RFC1918 space internally, and does *not* filter those source addresses from their customers.
You mean like Comcast using Cisco routers in their head-ends and having the 10/8 address show up in traceroutes and so forth? Not sure to what degree it's the NSP's fault vs. the router vendors', but yes.
There are semi-legitimate reasons for packets with those sources addresses to float around the Internet, and they don't hurt anything.
I guess you don't mind paying for transit of packets that _cannot_possibly_ have any legitimate purpose on your network.
Along with this goes the usual flamewar over RFC 2827, ingress filtering (of which URPF is a subset implementation).
Some of us, on the other hand, _do_ object.
And some of us pay for bandwidth, care about getting congestion problems from useless traffic, etc. Perhaps it makes the case a lot clearer for selling "better than equal" service to the highest bidder if your network is overrun with undesired traffic.