Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done? RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space. <---------------------------> Is there a site to "report" networks/isps that still leak rfc1918 space? By leaking I not only mean "don't filter", but actually _use_ in their network? If someone is keeping a list, feel free to add ServerBeach.com. All traceroutes to servers housed there, pass by 10.10.10.3. traceroute to www.serverbeach.com ... 20. 64-132-228-70.gen.twtelecom.net 21. 10.10.10.3 22. 66.139.72.12 Kind Regards, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium -- David Temkin
On Wed, 23 Jul 2003, Dave Temkin wrote:
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done?
If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38: http://www.faqs.org/rfcs/bcp/bcp38.html Rich
On Wed, Jul 23, 2003 at 02:10:17PM +0100, variable@ednet.co.uk wrote:
On Wed, 23 Jul 2003, Dave Temkin wrote:
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done?
If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38:
I think you'll see more and more networks slowly over time move closer to bcp38. I believe that AT&T is the only "tier-1" provider that is in full compliance with this. I'm sure some of the smaller providers are as well. I've been looking at the "unicast-rpf loose" drops at our edges of our network the past month off and on and am still surprised at the bitrate of packets that can not be returned to their sources. I think it's a simple thing to do that will insure that you are not carrying all this extra junk traffic on your network. Another perspective here: A number of people refuse to answer calls that show up on their phones as "out of area" or "private". Why would you answer or trust IP packets from hosts that are not in the routing table. While there is no PKI or similar to check if the packets are authenticated/signed for most of the network traffic, this does seem like a simple thing to do. Don't trust packets if you can't possibly figure out where they are coming from. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Wed, 23 Jul 2003, Jared Mauch wrote:
I think you'll see more and more networks slowly over time move closer to bcp38.
Is there anywhere that this is recorded? It would be interesting to see what the actual state of play on implementation of BCP38 was.
I believe that AT&T is the only "tier-1" provider that is in full compliance with this.
We've asked other tier-1's about BCP38 and were completely underwhelmed by the response. If you believe in the BCPs then I guess you just have to vote with your feet and try to use transit providers which comply with them. We've been trying to get transit from AT&T in London for a while now, but they're obviously spending all their efforts on blocking RFC1918 traffic rather than talking to prospective customers. :-S Rich
On Thu, Jul 24, 2003 at 01:44:33PM +0100, variable@ednet.co.uk wrote:
On Wed, 23 Jul 2003, Jared Mauch wrote:
I think you'll see more and more networks slowly over time move closer to bcp38.
Is there anywhere that this is recorded? It would be interesting to see what the actual state of play on implementation of BCP38 was.
I can speak about the networks that I operate with regards to this: AS2914 performs source filtering on a significant number of our customers. This coverage is not 100%, and sometimes is only the 'loose' rpf check, but there are a significant number of customers that have the strict rpf check that was enabled some time ago without any problems (we watched counters for drops, and looked at the packets that were dropped to determine if there was some asymetrical routing going on). It was shocking how many t1 customers that had a /28 or similar routed to them were spoofing address space outside of the continent. I am personally trying to insure that our IPv6 infrastructure begins with filtering in place instead of adding it on later as an afterthought.
I believe that AT&T is the only "tier-1" provider that is in full compliance with this.
We've asked other tier-1's about BCP38 and were completely underwhelmed by the response. If you believe in the BCPs then I guess you just have to vote with your feet and try to use transit providers which comply with them.
Well, i'm sure that some providers face the challenges that some of the older router hardware can't do linerate filtering for unicast-rpf. It's sometimes dificult to get this stuff out of the network as managment wants to extend the lifetime of working hardware as long as possible to reduce capital expendetures. network security vs budgets.. /sigh. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of variable@ednet.co.uk Sent: Wednesday, July 23, 2003 6:10 AM To: Dave Temkin Cc: nanog@merit.edu Subject: re: rfc1918 ignorant
On Wed, 23 Jul 2003, Dave Temkin wrote:
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done?
If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38:
They're not complying with RFC1918 either: In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. and 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's pretty clear that devices with network layer connectivity outside the etnerprise are not private and thus can't be numbered inside private IP space. DS
Except you're making assumptions as to how that router is used. If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through. -- David Temkin On Wed, 23 Jul 2003, David Schwartz wrote:
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of variable@ednet.co.uk Sent: Wednesday, July 23, 2003 6:10 AM To: Dave Temkin Cc: nanog@merit.edu Subject: re: rfc1918 ignorant
On Wed, 23 Jul 2003, Dave Temkin wrote:
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done?
If Frank's seeing the IP in his traceroute then the network concerned isn't properly filtering traffic leaving their borders as per BCP38:
They're not complying with RFC1918 either:
In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways).
All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises.
and
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's pretty clear that devices with network layer connectivity outside the etnerprise are not private and thus can't be numbered inside private IP space.
DS
On Wednesday, July 23, 2003, at 11:40 AM, Dave Temkin wrote:
Except you're making assumptions as to how that router is used.
If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through.
When the router needs to send an ICMP packet back to the source it becomes an originator. --lyndon
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea. -- David Temkin On Wed, 23 Jul 2003, Lyndon Nerenberg wrote:
On Wednesday, July 23, 2003, at 11:40 AM, Dave Temkin wrote:
Except you're making assumptions as to how that router is used.
If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through.
When the router needs to send an ICMP packet back to the source it becomes an originator.
--lyndon
On Wednesday, July 23, 2003, at 11:50 AM, Dave Temkin wrote:
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea.
True enough, but my view of networks that blindly block all ICMP is about the same as those that misuse 1918 addresses. And if they're blocking ICMP specifically to hide their misuse of 1918, well ... There are direct costs associated with dealing with networks that are configured as described above. If you can't see inside to diagnose problems, you can't call horsepucky when their support people start feeding you a line. The cost of downtime and local support staff quickly adds up. I've cancelled contracts in the past for this very reason. --lyndon
Needs is a tough call. Plenty of networks block ICMP at the border and could very well be using 1918 addressing in between and you'd have no idea.
-- David Temkin
Wholesale blocking of ICMP is another sign of incompetence. Either way a network using RFC1918 inappropriately, filtering all icmp, or both is a clueless network.
On Wed, 23 Jul 2003 13:40:03 EDT, Dave Temkin said:
If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through.
If it shows up on a traceroute, it originated an ICMP packet. 10 * * * 11 * * * 12 * * * would be "proper" behavior if it was *purely* transit-only.
On Wed, Jul 23, 2003 at 01:49:37PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Wed, 23 Jul 2003 13:40:03 EDT, Dave Temkin said:
If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through.
If it shows up on a traceroute, it originated an ICMP packet.
10 * * * 11 * * * 12 * * *
would be "proper" behavior if it was *purely* transit-only.
Perhaps it should send back the icmp packet from a loopback interface that has a publically routed ip on it. that would allow p-mtu to work as well as you'd get the packet saying frag-needed and you can still get a general idea of what route the packets are taking (although not the specific interface). it would allow people involved to look at their lsp routes or forwarding tables to determine where the fault is without revelaing information they would rather not about their infrastructure. "ip icmp response-interface loopback0" junipers already do this if you traceroute directly to them (ie: they're the last hop in the traceroute) and send back the packet from their lo interface if you have 'default-address-selection' configured. (i think that's the keyword) - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Date: Wed, 23 Jul 2003 13:40:03 -0400 (EDT) From: Dave Temkin <dave@ordinaryworld.com> Sender: owner-nanog@merit.edu
Except you're making assumptions as to how that router is used.
If it's being used for purely transit then your third paragraph doesn't apply at all. The traffic is not originating or terminating there, it is merely passing through.
And what are the ICMP packets doing on the net? They seem to be originating from 1918 space. Nothing in the RFC says that ICMP does not count. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Is this really an issue? So long as they're not advertising the space I see no issue with routing traffic through a 10. network as transit. If you have no reason to reach their router directly (and after Cisco's last exploit, I'd think no one would want anyone to reach their router directly :-) ), what's the harm done?
RFC1918 merely states that it shouldn't be routed on the global internet, not that it can't be used for transit space.
RFC1918: 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. By virtue of using RFC1918 addresses on packet-passing interfaces (those which generate ICMP error messages) it is a violation of RFC1918. One could, in turn, disable those messages, or filter them, but as others point out, that breaks such things as PMTU-D. Also, those who think their RFC1918-numbered device is not directly reachable solely due to being RFC1918 numbered, are deluded.
participants (8)
-
bdragon＠gweep.net -
Dave Temkin -
David Schwartz -
Jared Mauch -
Kevin Oberman -
Lyndon Nerenberg -
Valdis.Kletnieks＠vt.edu -
variable＠ednet.co.uk