North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: private ip addresses from ISP
- From: Daniel Senie
- Date: Tue May 23 09:39:08 2006
At 09:22 AM 5/23/2006, Robert Bonomi wrote:
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?
> Date: Tue, 23 May 2006 03:33:34 -0400
> From: Richard A Steenbergen <firstname.lastname@example.org>
> To: email@example.com
> 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?
> > Sorry to dig this up from last week but I have to strongly disagree with
> > point #3.
> > >From RFC 1918
> > 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.
> > 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
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.
> If you're receiving RFC1918 *routes* from anyone, you need to
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.
> 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.
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
(either inbound or outbound.)
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.
It's even more comical when the NSP uses RFC1918 space internally, and does
*not* filter those source addresses from their customers.
Along with this goes the usual flamewar over RFC 2827, ingress
filtering (of which URPF is a subset implementation).
> 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.
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.
Some of us, on the other hand, _do_ object.