Date: Tue, 23 May 2006 09:36:30 -0400 To: nanog@nanog.org From: Daniel Senie <dts@senie.com> Subject: Re: private ip addresses from ISP
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?
"Can be" is not sufficient (in and of itself, that is) reason to block. _Anything_ "can be" used as part of a DOS attack. TTL-E messages _do_ have legitimate function in network management. TTL-E messages _can_ originate from RFC1918 space, addressed to 'public internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'? Ever use it where packets went across a network using RFC1918 internally? Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses network? If you don't like that example, substitute "host/network unreachable", or 'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet. If you don't get those messages back, you can't communicate.
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.
You need to learn to read. I said "malicious content", not 'used in a malicious fashion'. Packets that could have legitimate meaning should be passed on. Packets that _cannot_ have legitimate meaning should not be.
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 at all. You're either ignorant of network architecture, or trying to pick fights. I was talking about a situation where a customer machine of a network that uses RFC1918 addresses internally starts sending malicious packets with a RFC1918 source address that _matches_ that of one of the *in*use* addresses on the service-provider network. AND the service-provider does not do ingress (from the customer) or egress (to the customer) filtering of RFC1918 address-space. Customer A's machine starts attacking Customer B, C, D, E, F ...; those ill-informed customers don't null-route outbound RFC1918 addresses; you get an 'inadvertent' smurf attack on the NSP resource. It's comical, because the ISP's 'bad practice' facilitated the attack on the ISP. "Traceroute", by the way, *is* one of those 'legitimate' cases for which RFC1918 source-address packets should be allowed across network boundaries. Proper "good net neighbor" egress filtering of RFC1918 source addresses takes a number of separate rules. Several 'allows', followed by a default 'deny'.
Not sure to what degree it's the NSP's fault vs. the router vendors', but yes.
Can't imagine why you think it might be the fault of the router vendor. Can't imagine why think it is somebody's "fault".
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).
If everybody did _egress_ filtering of 'cannot possibly be legitimate' traffic, ingress filtering of that traffic would not be necessary. Unfortunately, not everybody does, so ingress filtering _is_ necessary. 'ingress' filtering is self-defense. 'egress' filtering is about 'being a good net neighbor'.
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.
Robert Bonomi wrote:
TTL-E messages _do_ have legitimate function in network management. TTL-E messages _can_ originate from RFC1918 space, addressed to 'public internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'? Ever use it where packets went across a network using RFC1918 internally? Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses network?
I guess this means that providers who utilize rfc1918 along their hops should make an effort to ensure these addresses are not used for icmp messages or translate these addresses when they source icmp. Understandably, translation on providers networks is not always feasible. A feature on routers that sourced icmp packets to be told specificaly which address of the router to source it from would also help.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Joe Maimon Sent: Tuesday, May 23, 2006 10:15 AM To: Robert Bonomi Cc: nanog@nanog.org Subject: Re: private ip addresses from ISP
Robert Bonomi wrote:
TTL-E messages _do_ have legitimate function in network management. TTL-E messages _can_ originate from RFC1918 space,
addressed to 'public
internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'? Ever use it where packets went across a network using RFC1918 internally? Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses network?
I guess this means that providers who utilize rfc1918 along their hops should make an effort to ensure these addresses are not used for icmp messages or translate these addresses when they source icmp.
Understandably, translation on providers networks is not always feasible.
A feature on routers that sourced icmp packets to be told specificaly which address of the router to source it from would also help.
In the Cisco world, I thought that the source would always be the interface that replies to the ICMP packet. That seems to be good form to me. Where am I going wrong?
Brian Johnson wrote:
In the Cisco world, I thought that the source would always be the interface that replies to the ICMP packet. That seems to be good form to me.
Where am I going wrong?
You are correct, however it could be usefull in regards to the topic at hand if this was configurable.
Folks are sounding as if they'd never 'traceroute'd THROUGH a set of unroutable IP addresses. I have seen cases where my 'traceroute' looked like this [when I've had the patience to not hit Interrupt at the first sign of stars]: 1 1 ms 1 ms 1 ms router.here 2 10 ms 10 ms 10 ms router.there 3 * * * 4 * * * 5 * * * 6 * * * 7 80 ms 80 ms 80 ms router.over.yonder 8 90 ms 90 ms 90 ms host.over.yonder It works! -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Joseph S D Yao wrote:
Folks are sounding as if they'd never 'traceroute'd THROUGH a set of unroutable IP addresses. I have seen cases where my 'traceroute' looked like this [when I've had the patience to not hit Interrupt at the first sign of stars]:
1 1 ms 1 ms 1 ms router.here 2 10 ms 10 ms 10 ms router.there 3 * * * 4 * * * 5 * * * 6 * * * 7 80 ms 80 ms 80 ms router.over.yonder 8 90 ms 90 ms 90 ms host.over.yonder
It works!
Its also quite annoying to wait for each hop to timeout.
On Tue, May 23, 2006 at 11:55:56AM -0400, Joe Maimon wrote: ...
Its also quite annoying to wait for each hop to timeout.
Well, yes. ;-} But as someone hinted, that's purely a problem with my own psyche, which I do [to some degree] control. OBTW, the 'ad hominem' attacks starting up in this thread should really be deprecated [speaking of which]. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Proper "good net neighbor" egress filtering of RFC1918 source addresses takes a number of separate rules. Several 'allows', followed by a default 'deny'.
Really? Do you have those rules on your network? Any reason why you didn't post the operational details on this operational list? Have you ever read your peering agreements or service contracts to see if filtering of RFC 1918 sourced traffic is specifically covered by them? If it is not covered by the contract, then why should your peers/upstreams filter it? Another good question is whether or not every service contract and peering agreement should contain unique text or whether there should be some community-developed best practices statement that could be plugged in by reference. For instance, software publishers can publish their software under the terms of the GPL without including the full text of the GPL verbatim in their software license. Does NANOG have a role in developing some best practices text that could be easily imcorporated into peering agreements and service contracts? --Michael Dillon
On Tue, May 23, 2006 at 04:22:26PM +0100, Michael.Dillon@btradianz.com wrote: ...
Does NANOG have a role in developing some best practices text that could be easily imcorporated into peering agreements and service contracts? ...
RFC 2267 -> RFC 2827 == Best Current Practice (BCP) 38 RFC 3013 == BCP 46 RFC 3704 == BCP 84 Are these followed? -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Does NANOG have a role in developing some best practices text that could be easily imcorporated into peering agreements and service contracts? ...
RFC 2267 -> RFC 2827 == Best Current Practice (BCP) 38 RFC 3013 == BCP 46 RFC 3704 == BCP 84 Are these followed?
No, the IETF BCP's are not followed and part of the reason is that they are not written by network operators but often by vendors and academics. The fact is that the collective of network operations people (in North America at least) does not have any agreed set of BEST OPERATIONAL PRACTICES. There are various camps that promote various sets of rules which are often overly simplistic and cannot be 100% adhered to in practice. What we really need is a forum to discuss best operational practices and resolve all these various differences in opinion systematically. The end result should be a set of best practices that people really can follow with no exceptions. Of course this means that the best practices must incorporate various exceptions to the simple rules and explain when those exceptions are and are not appropriate. So again, I ask the question: Is NANOG an appropriate forum to develop some best practices text that could be incorporated into service agreements and peering agreements by reference in the same way that a software licence incorporates the GPL by referring to it? --Michael Dillon
On May 24, 2006, at 2:05 AM, Michael.Dillon@btradianz.com wrote: <snip>
So again, I ask the question: Is NANOG an appropriate forum to develop some best practices text that could be incorporated into service agreements and peering agreements by reference in the same way that a software licence incorporates the GPL by referring to it?
Ah, I think we all assumed you were kidding when you asked that! While I think NANOG *should* be the appropriate forum, I don't really think it will be -- there are too many personal agendas -- getting the community to agree on *anything* these days appears to be a losing proposition.... I suspect that a post suggesting we replace IP with a piece of wet spaghetti would: a: Get n replies agreeing b: Get n replies disagreeing c: Possibly generate a post that is trying to be useful. d: A fish (not a fish anything, just a random posting not related to anything on topic) e: Spawn a thread screaming "Troll" f: Get 2n replies asking if that will run on vendor X g: Get 2n replies suggesting that an alternate root / better SPAM detection / would fix all our woes h: Generate n^2 ad hominem attack threads. i: Be sidetracked into a request for a contact for company Y j: Get misinterpreted [supporting | blasting] someone's pet theory / idea / etc Even the fairly simple question of whether a network should emit packets with RFC1918 sourced packets (a topic I am declining to comment on) exhibited many of the above. While I think having "some best practices text that could be incorporated into service agreements and peering agreements" would be great I suspect this isn't the forum to generate such a thing -- unless it looks like: Best Common Practices (please circle appropriate field): 1: Interconnecting networks (agree to always) / (agree to never) / (agree to sometimes) emit packets with RFC1918 addresses 2: Interconnecting networks ( shall) / (shall not ) run some form of RPF 3: Interconnecting networks (will) / (won't) / (might) randomly depeer ... etc. Having "some best practices text that could be incorporated into service agreements and peering agreements" would be great -- lets how about setting up a forum for this? Warren (who is feeling very grumpy and cynical this morning -- and might take all the above back once the coffee sinks in)
--Michael Dillon
-- "Real children don't go hoppity-skip unless they are on drugs." -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)
Date: Wed, 24 May 2006 15:26:15 -0400 From: Valdis.Kletnieks
d: A fish (not a fish anything, just a random posting not related to anything on topic)
And this one will invariably start a "trout"/"salmon"/"swordfish"/"octopus" debate.....
...at which point someone interjects that an octopus is a mollusk... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On May 23, 2006, at 10:47 AM, 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?
"Can be" is not sufficient (in and of itself, that is) reason to block. _Anything_ "can be" used as part of a DOS attack.
TTL-E messages _do_ have legitimate function in network management. TTL-E messages _can_ originate from RFC1918 space, addressed to 'public internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'? Ever use it where packets went across a network using RFC1918 internally? Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses network?
If you don't like that example, substitute "host/network unreachable", or 'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet. If you don't get those messages back, you can't communicate.
Robert, to quote your own words: "You're either ignorant of network architecture, or trying to pick fights." TTL-E messages "can" originate from any IP address. They should not. And allowing packets with RFC1918 source addresses to leave your administrative domain is bad network administration (not to mention going against the RFC). There are no loopholes here, you are being a bad 'Netizen if you pass packets with bogon source addresses to your peers. Period. If you have issues where you need to send DNF or other messages to peers, it is incumbent upon _you_ to ensure those messages originate with valid source addresses. It is perfectly acceptable - even good network hygiene - for other networks to drop any packets with bad source addresses at their boarder. You cannot expect them to accept your packets just because you don't know how to architect a network properly. If that breaks traceroute or PMTU-D or anything else, that is your fault, not theirs. Please read RFC1918 again, as well as BCP38. And perhaps a book on networking. -- TTFN, patrick
participants (9)
-
Brian Johnson -
Edward B. DREGER -
Joe Maimon -
Joseph S D Yao -
Michael.Dillon＠btradianz.com -
Patrick W. Gilmore -
Robert Bonomi -
Valdis.Kletnieks＠vt.edu -
Warren Kumari