Re: private ip addresses from ISP
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
Re: private ip addresses from ISP
On May 24, 2006, at 2:05 AM, [EMAIL PROTECTED] 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)
Re: private ip addresses from ISP
On Wed, 24 May 2006 11:50:34 PDT, Warren Kumari said: 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. pgpey06HNxilK.pgp Description: PGP signature
Re: private ip addresses from ISP
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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: private ip addresses from ISP
In reality, from what I see, most large ISP doesn't care about RFC1918. I've been dealing with this issue for a while. Not all of them, because I didn't deal with all of them. But some of them has strange policy for ACL, because it has large impact on router platform CPU utilization. Strictly some ISP doesn't allow to put ACL for more than 24 hours including RFC1918 ip address space originated traffic. So I'm doing it from our core router to block those traffic, and fun to watch the counters increasing so rapidly. ^.^ For an example, [EMAIL PROTECTED] show firewall filter XXX-in Filter: XXX-in Counters: NameBytes Packets XXX-in-default 430738360735883 743436641099 XXX-in-rfc1918-10 12742937908 41900221 XXX-in-loopback 785367140 2678266 XXX-in-dhcp-default36982506 413978 XXX-in-rfc1918-172-161240646548 13026411 XXX-in-test-net 44318 621 XXX-in-rfc1918-192-168 1806857741 17309861 XXX-in-reserved-e-class 00 ospf-deny 14135 35 h323 8785570 186042 XXX-in-microsoft 305199975828 5751955784 ms-exclude 424428929 696688 on-fire 173190029170 5970455314 I'm wondering whether this is really about router platform issue, and they want their customer including smaller ISPs to bill more because of these junk traffic. Hyun Andrew Kirch wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Wednesday, May 17, 2006 1:37 PM To: [EMAIL PROTECTED] Subject: RE: private ip addresses from ISP Our router is running BGP and connecting to our upstream provider with /30 network. Our log reveals that there are private IP addresses reaching our router's interface that is facing our upstream ISP. How could this be possible? Should upstream ISP be blocking private IP address according to standard configuration? Could the packet be stripped and IP be converted somehow during the transition? It happens in many Tier-1 ISP though ! Thank you for your information Do you mean: 1) You are seeing BGP routes for addresses inside private space? 2) You are seeing packets with destination IPs inside private space arriving at your interface from your ISP? 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? If 1, feel free to filter them. You ISP probably uses them internally and is leaking them to you. Feel free to complain if you want. If 2, make sure you aren't advertising routes into RFC1918 space to your ISP. If not, you should definitely ask them what's up. If 3, that's normal. These are packets your ISP received that are addressed to you and the ISP is leaving to you the decision of whether to accept them or not. Feel free to filter them out if you wish. (It won't break anything that's not already broken.) 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. Andrew
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 packets. 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. There are semi-legitimate reasons for packets with those sources addresses to float around the Internet, and they don't hurt anything. If you really can't stand seeing an RFC1918 sourced packet over the Internet it is more of a personality problem than a networking problem, so a good shrink is probably going to be more useful than a good firewall. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: private ip addresses from ISP
RAS Date: Tue, 23 May 2006 03:33:34 -0400 RAS From: Richard A Steenbergen RAS If you're receiving RFC1918 sourced packets #include flamewars/urpf.h #include flamewars/pmtud.h 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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: private ip addresses from ISP
Date: Tue, 23 May 2006 03:33:34 -0400 From: Richard A Steenbergen [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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. 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.) It's even more comical when the NSP uses RFC1918 space internally, and does *not* filter those source addresses from their customers. 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. Some of us, on the other hand, _do_ object. YMMV
RE: private ip addresses from ISP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Bonomi Sent: Tuesday, May 23, 2006 9:22 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: private ip addresses from ISP Date: Tue, 23 May 2006 03:33:34 -0400 From: Richard A Steenbergen [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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. 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.) It's even more comical when the NSP uses RFC1918 space internally, and does *not* filter those source addresses from their customers. 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. Some of us, on the other hand, _do_ object. YMMV Well said, I think that Robert has done a phenomenal job of summing up my point. I don't want this trash on my network. The pertinent RFC says it shouldn't be entering my network from *your* network (for varying values of your). I don't buy the argue that the end user should decide what traffic they do and don't want when the RFC states unequivocally that the traffic shouldn't be there. Even reasonably large networks are often run by people with no appreciable networking experience, MCSE, MCP MCP+I etc. This is a simple fact of life. Andrew
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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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.
RE: private ip addresses from ISP
While we're on the topic, perhaps I should ask for some best practices (where 'best' equals one for every listserv member) on the use of RFC 1918 addresses within a network provider's infrastructure. We use private addresses for some stub routes, as well as our cable modems. Should we aggressively move away from private stub networks? And for the second, should we specifically limit access to those cable modem IPs to just our management network ? Right now any of customers could do an SNMP sweep and identify them all, but I don't really care that much about that, or should I? And yes, I do have RFC 1918 filters on our outbound traffic. =) Frank
Re: private ip addresses from ISP
Date: Tue, 23 May 2006 09:36:30 -0400 To: [EMAIL PROTECTED] From: Daniel Senie [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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
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.
Re: private ip addresses from ISP
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
RE: private ip addresses from ISP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Maimon Sent: Tuesday, May 23, 2006 10:15 AM To: Robert Bonomi Cc: [EMAIL PROTECTED] 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?
Re: private ip addresses from ISP
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.
Re: private ip addresses from ISP
Robert Bonomi wrote: Date: Tue, 23 May 2006 11:14:53 -0400 Translating those addresses is a *BAD*IDEA*(TM). That obscures who the reporting machine was _if_ you have to actually communicate with that network operator. These are the options: Construct the network so that icmp is never sourced from rfc1918 OR Do either of below: Filter icmp sourced from rfc1918 on egress Dont filter icmp sourced from rfc1918 on egress Translate icmp sourced from rfc1918 on egress Use some feature that translates/replaces rfc1918 sourced icmp with nonrfc1918 identifiable internally. This is exactly why RFC1918 says that private-addrss source packets _should_ _not_ be passed across enterprise boundaries. It does _not_ say 'must not', because there *are* situations where it is necessary. This _is_ one of them. :) You are in favor of: Dont filter icmp sourced from rfc1918 on egress However that leads to a significant hole in anti spoofing defense sheild of the net. So it becomes difficult to be in favor of this and also claim that liberal application of anti-spoofing/urpf will solve most of the abuses which depend on spoofing to be effective. 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. When the router has only RFC1918 addresses (totally internal to the network), it doesn't matter/help. In this instance they would assign a single or more address nonrfc1918 to leverage this feature. Also, the address to use as the source _is_ well-defined. it is the interface the packet came in on that triggered the ICMP message. The proposed feature would make it configurable, perhaps on a per interface basis. The provider would keep an internal database. It need not even be routed. It would be nice if this was completely an icmp packet field value and not dependant on the ip header to identify the icmp generator.
Re: private ip addresses from ISP
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.
Re: private ip addresses from ISP
On Tue, May 23, 2006 at 04:22:26PM +0100, [EMAIL PROTECTED] 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.
Re: private ip addresses from ISP
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.
Re: private ip addresses from ISP
On May 23, 2006, at 3:33 AM, Richard A Steenbergen wrote: 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 packets. I know it was late when you wrote that, RAS, but from the _very_first_sentence_: and packets with private source or destination addresses should not be forwarded across such links 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. There are semi-legitimate reasons for packets with those sources addresses to float around the Internet, and they don't hurt anything. If you really can't stand seeing an RFC1918 sourced packet over the Internet it is more of a personality problem than a networking problem, so a good shrink is probably going to be more useful than a good firewall. Incorrect. Not to mention Just Plain Wrong. Please read BCP38 again. (For the first time? :) -- TTFN, patrick
Re: private ip addresses from ISP
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
Re: private ip addresses from ISP
On Tue, May 23, 2006 at 12:23:54PM -0400, Patrick W. Gilmore wrote: I know it was late when you wrote that, RAS, but from the _very_first_sentence_: Er yeah I meant to say it says nothing about filtering 1918 packets. Please read BCP38 again. (For the first time? :) Clearly allowing anyone to inject large quantities of spoofed packets into the Internet is Bad (tm), no one is arguing that. First of all note that I was talking about how you deal with packets you receive, not packets you send. Hate to bust out the old be conservative in what you send and liberal in what you receive line, but in this case it is true. There are legitimate uses for RFC1918 sourced packets (as has been pointed out many times, for example, ICMP responses from people who want/need their routers to not source packets from publicly routed space). Filtering every last 1918 sourced packet you receive because it might have a DoS is like filtering all ICMP because people can ping flood. If you want to rate limit it, that is reasonable. If you want to restrict it to ICMP responses only, that is also reasonable. If on the other hand you are determined to filter every 1918 sourced packets between AS boundries (including ttl exceed, mtu exceed, and dest unreachable) because an RFC told you you should, you are actually doing your customers a disservice. If you are an end-user network or don't transit other people's packets and you want to do yourself a disservice then by all means filter 1918 sourced packets until you are blue in the face. If on the other hand you do handle other people's packets, I would encourage you to fully consider the ramifications before you go out and apply those filters. This is why k00ks who can only cite RFC's instead of think for themselves and large networks tend to be a bad mix. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: private ip addresses from ISP
Filtering every last 1918 sourced packet you receive because it might have a DoS is like filtering all ICMP because people can ping flood. If you want to rate limit it, that is reasonable. If you want to restrict it to ICMP responses only, that is also reasonable. If on the other hand you are determined to filter every 1918 sourced packets between AS boundries (including ttl exceed, mtu exceed, and dest unreachable) because an RFC told you you should, you are actually doing your customers a disservice. Well, some of us happen to disagree. I have been very happy to see that both at my previous and at my present employer (large SPs by Norwegian standards), all 1918 traffic is filtered at the borders. We have never had any trouble from customers because of this, and we certainly intend to keep the filters. And yes, we have had these filters in place for several years... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: private ip addresses from ISP
On May 23, 2006, at 1:14 PM, Richard A Steenbergen wrote: [...] Filtering every last 1918 sourced packet you receive because it might have a DoS is like filtering all ICMP because people can ping flood. If you want to rate limit it, that is reasonable. If you want to restrict it to ICMP responses only, that is also reasonable. If on the other hand you are determined to filter every 1918 sourced packets between AS boundries (including ttl exceed, mtu exceed, and dest unreachable) because an RFC told you you should, you are actually doing your customers a disservice. If you are an end-user network or don't transit other people's packets and you want to do yourself a disservice then by all means filter 1918 sourced packets until you are blue in the face. If on the other hand you do handle other people's packets, I would encourage you to fully consider the ramifications before you go out and apply those filters. This is why k00ks who can only cite RFC's instead of think for themselves and large networks tend to be a bad mix. :) No one is arguing that you should ruin your business because an RFC told you to. (At least no one reasonable.) However, in your first post you said: If you're receiving RFC1918 sourced packets, for the most part you really shouldn't care. There are semi-legitimate reasons for packets with those sources addresses to float around the Internet, and they don't hurt anything. I disagree. As do many people. You -should- care when people do bad things. And passing bogon-source packets between ASes is a Bad Thing. You suggest thwacking people over the head with a cluebat when they send you 1918 prefixes. Is that really a problem? It's easy to filter (as everyone should be doing already), and doesn't really 'break' anything. So why the vehemence? Because it is a Bad Thing. And the Internet doesn't work if everyone does Bad Things. As a result, you get upset when people do Bad Things. But, as you point out, sometimes customers are stupid. So sometimes you have to do things that upset you. You get paid for connectivity, and customers don't understand why certain actions hurt the Internet. For instance, I get pissed when someone sends 256 /24s instead of one /16. But that doesn't mean I suggest filtering all 256 /24s. Customers would get pissed if they can't reach their fav pr0n server in that /16. Similarly, if someone sends you 1918-sourced packets, you may have to accept them to keep your customers happy. But you should care. And you should be upset. Telling people they need to see a shrink for trying to keep the 'Net clean is not the correct response. -- TTFN, patrick
Re: private ip addresses from ISP
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.
RE: private ip addresses from ISP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Wednesday, May 17, 2006 1:37 PM To: [EMAIL PROTECTED] Subject: RE: private ip addresses from ISP Our router is running BGP and connecting to our upstream provider with /30 network. Our log reveals that there are private IP addresses reaching our router's interface that is facing our upstream ISP. How could this be possible? Should upstream ISP be blocking private IP address according to standard configuration? Could the packet be stripped and IP be converted somehow during the transition? It happens in many Tier-1 ISP though ! Thank you for your information Do you mean: 1) You are seeing BGP routes for addresses inside private space? 2) You are seeing packets with destination IPs inside private space arriving at your interface from your ISP? 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? If 1, feel free to filter them. You ISP probably uses them internally and is leaking them to you. Feel free to complain if you want. If 2, make sure you aren't advertising routes into RFC1918 space to your ISP. If not, you should definitely ask them what's up. If 3, that's normal. These are packets your ISP received that are addressed to you and the ISP is leaving to you the decision of whether to accept them or not. Feel free to filter them out if you wish. (It won't break anything that's not already broken.) 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. Andrew
private ip addresses from ISP
Hi all Have you had this experience? Our router is running BGP and connecting to our upstream provider with /30 network. Our log reveals that there are private IP addresses reaching our router's interface that is facing our upstream ISP. How could this be possible? Should upstream ISP be blocking private IP address according to standard configuration? Could the packet be stripped and IP be converted somehow during the transition? It happens in many Tier-1 ISP though ! Thank you for your information
RE: private ip addresses from ISP
What do you mean by reaching? Two quick observations from a mis-configuration point of view: If you mean you are seeing BGP routes for those networks: Sometimes ISPs null route private addresses with static routes in their networks and they accidentally leak (redistribute) to customers/peers. There are obviously other reasons too, but you can filter stuff like that yourself. Just don't accept routes for private IP space from you upstream. If you mean you are getting traffic destined for RFC1918 space, then make sure you aren't announcing those networks to your upstreams by accident. Poor upstream configs/filters could allow stuff like that to escape to peers of the upstream. (stranger things have happened) It's not normal or necessary to see those routes or traffic. Just contact your upstream and point it out they should fix it. Ivan Groenewald [EMAIL PROTECTED] CTO Tel: 0845 345 0919 Xtraordinary Hosting, 6 The Clocktower, South Gyle, Edinburgh, EH12 9LB http://www.xtrahost.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of adrian kok Sent: Wednesday, May 17, 2006 2:48 PM To: [EMAIL PROTECTED] Subject: private ip addresses from ISP Hi all Have you had this experience? Our router is running BGP and connecting to our upstream provider with /30 network. Our log reveals that there are private IP addresses reaching our router's interface that is facing our upstream ISP. How could this be possible? Should upstream ISP be blocking private IP address according to standard configuration? Could the packet be stripped and IP be converted somehow during the transition? It happens in many Tier-1 ISP though ! Thank you for your information
RIPE IP Anti-Spoofing Task Force (Was: private ip addresses from ISP)
On Wed, 2006-05-17 at 15:14 +0100, Ivan Groenewald wrote: [..] If you mean you are getting traffic destined for RFC1918 space, then make sure you aren't announcing those networks to your upstreams by accident. Poor upstream configs/filters could allow stuff like that to escape to peers of the upstream. (stranger things have happened) [..] On a related note, RIPE has started an IP Anti-Spoofing Task Force, see http://www.ripe.net/ripe/tf/anti-spoofing/ for more information. Greets, Jeroen -- RIPE IP Anti-Spoofing Task Force == IP source address spoofing is the practice of originating IP datagrams with source addresses other than those assigned to the host of origin. In simple words the host pretends to be some other host. This can be exploited in various ways, most notably to execute DoS amplification attacks which cause an amplifier host to send traffic to the spoofed address. There are many recommendations to prevent IP spoofing by ingress filtering, e.g. checking source addresses of IP datagrams close to the network edge. At RIPE-52 in Istanbul RIPE has established a task force that promotes deployment of ingress filtering at the network edge by raising awareness and provide indirect incentives for deployment. Document ripe-379 provides the task force charter and the initial time-line. The mailing list archive is at http://www.ripe.net/ripe/maillists/archives/spoofing-tf/2006/index.html The task force web page is at http://www.ripe.net/ripe/tf/anti-spoofing/ The task force is co-chaired by Nina Hjorth Bargisen (NINA1-RIPE) and Daniel Karrenberg (DK58). signature.asc Description: This is a digitally signed message part
RE: private ip addresses from ISP
Our router is running BGP and connecting to our upstream provider with /30 network. Our log reveals that there are private IP addresses reaching our router's interface that is facing our upstream ISP. How could this be possible? Should upstream ISP be blocking private IP address according to standard configuration? Could the packet be stripped and IP be converted somehow during the transition? It happens in many Tier-1 ISP though ! Thank you for your information Do you mean: 1) You are seeing BGP routes for addresses inside private space? 2) You are seeing packets with destination IPs inside private space arriving at your interface from your ISP? 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? If 1, feel free to filter them. You ISP probably uses them internally and is leaking them to you. Feel free to complain if you want. If 2, make sure you aren't advertising routes into RFC1918 space to your ISP. If not, you should definitely ask them what's up. If 3, that's normal. These are packets your ISP received that are addressed to you and the ISP is leaving to you the decision of whether to accept them or not. Feel free to filter them out if you wish. (It won't break anything that's not already broken.) DS
