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
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
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
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.
When the router needs to send an ICMP packet back to the source it becomes an originator.
--lyndon
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.
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
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
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
> 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