This is an heads-up from the Mediacom Network Operations Center about an
issue we are seeing. We
were recently given an IP scope from ARIN (American Registry for Internet
Numbers) that still
exists on older Bogon lists many web providers are currently using.
A Bogon prefix is a route that should never appear in the Internet routing
table. A packet routed
over the public Internet (not including over VPN or other tunnels) should
never have a source
address in a Bogon range. These are commonly found as the source addresses
of DDoS attacks.
The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list
and was blocked by all
websites using a Bogon prefix up until February of 2008, when it was
released by IANA (Internet
Assigned Numbers Authority) for public use and an updated Bogon prefix was
provided. Mediacom
customers that are within this IP range are not able to reach a website
hosted by many organizations.
Mediacom is individually requesting that these providers update their Bogon
prefix to the most current version
to resolve this issue immediately. We are requesting assistance from this
community to make this issue known
and to advise administrators to update to the most current Bogon list.
This is an heads-up from the Mediacom Network Operations Center about an
issue we are seeing. We
were recently given an IP scope from ARIN (American Registry for Internet
Numbers) that still
[..]
Please fix your mailer as it seems to be broken with respect to line-breaks and that makes reading very annoying.
The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list
and was blocked by all
If you really want the block you have to be debogonized it would be handy if you:
- provide the full prefix, including prefix length, and not just x.x.x
- reference to the whois entry
- the ASN you are announcing this from
- an IP address in that prefix that replies to at least ICMP echo
requests with an ICMP echo response so that people can check for
you if they can reach it.
The people who care about these things would love to help you, but without proper information (173.0.0.0/8 is pretty big you know), that is very impossible, and why would they spend time on resolving your problem if you don't take the nice steps to provide proper information?
Out of curiosity - what percentage of connectivity providers are both clued
enough to be represented on NANOG and yet unclued enough to not understand
the need to keep bogon filters up to date (even if you just get a BGP feed
from Team Cymru)?
(By the way, Nick - if what you sent NANOG was a form letter template, I'd
lose a lot of the RFC references and point at Team Cymru's stuff instead)...
I'd be shocked it there were no people who read NANOG and misunderstood or blatantly ignored some of it.
Unfortunately, that means they would ignore / misunderstand the OP's request. But there is probably a small percentage clueless enough to have stale bogon filters, but just clueful enough to realize what the OP said might apply to them. A very small percentage....
Switching topics only slightly: Nick, do you have any data on what parts of the 'Net you can and cannot reach? Perhaps take a dump of route-views and ping some IPs in each ASN? Shouldn't be hard to script, and might yield useful data - both to you and the rest of us.
Switching topics only slightly: Nick, do you have any data on what parts
of the 'Net you can and cannot reach? Perhaps take a dump of
route-views and ping some IPs in each ASN? Shouldn't be hard to script,
and might yield useful data - both to you and the rest of us.
we are running it approximately monthly from servers on three continents
to see how things change over time and how locations differ.
oh, and we do comparative traceroutes do diagnose *where* the filter is.
just pinging out there, as patrick suggested, does not tell you where
the blockage actually is.
sad to say, folk do not seem to remove filters. but when we wrote to
them, they did.
credit to olaf maennel, now of t-labs, tu berlin, etc., for most of the
hard work on this.
"Bogon" filters made a lot of sense when most of the Internet was
bogons. Back when 5% of the IP space was allocated blocking the
other 95% was an extremely useful endevour. However, by the same
logic as we get to 80-90% used, blocking the 20-10% unused is
reaching diminishing returns; and at the same time the rate in which
new blocks are allocated continues to increase causing more and
more frequent updates.
Have bogon filters outlived their use? Is it time to recommend people
go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that
doesn't need to be updated as frequently?
Was looking over 1918 again, and for the record I have only run into one
network that follows:
"If two (or more) organizations follow the address allocation
specified in this document and then later wish to establish IP
connectivity with each other, then there is a risk that address
uniqueness would be violated. To minimize the risk it is strongly
recommended that an organization using private IP addresses choose
*randomly* from the reserved pool of private addresses, when
allocating
sub-blocks for its internal allocation."
I added the asterisks.
Most private networks start at the bottom and work up: 192.168.0.X++,
10.0.0.X++, etc. This makes
any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen
a lot of hack jobs
using NAT to get around this. Ugly.
Where I work we are more aimed towards the SMB market, and we do run into that issue a lot. Of course a lot of the problem we run into is that the "engineers" who set up these SMB clients, even getting into some of the larger businesses just use what they always do. I can think of one specific engineer who everything he does is 192.168.1.0/24 .254 gateway .1 server which has cause issues. We have one particular client who has nearly 40 VPN's between partners and they have actually had to do a lot of natting at the vpn endpoint as they have 3 clients they connect to that are 10.0.1.0/24 and several that are 192.168.0.0/24 however a lot of the newer VPN firewalls that we work with actually do a pretty slick job. SonicWall NSA series devices have a "NAT VPN range" checkbox when you build the VPN and you just give it the range to use, as do the Fortinet devices.
Most private networks start at the bottom and work up: 192.168.0.X++,
10.0.0.X++, etc. This makes
any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen
a lot of hack jobs
using NAT to get around this. Ugly.
Well, you can always do what one of the companies I work with does: allocate from 42.0.0.0/8 for networks that might need to interoperate with 1918 space and hope that it is "forever" before we run so low on IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status.
do what one of the companies I work with does: allocate from
42.0.0.0/8
some italian isps use blocked american military /8s. i find that highly
amusing, especially when i think of the long-term implication for the
folk who blocked access to that they wanted to 'own'.
Honestly, I don't believe the 80/20 rules applies here.
Until all transit networks are willing to strictly filter their downstreams (and themselves!), if there is any unused space (note I said "unused", not "unallocated"), the miscreants will use it. They are not going around saying "oh, damn, there are only a few /8s left, we better stop!".
Filter your bogons. But do it in an automated fashion, from a trusted source.
Of course, I recommend Team Cymru, which has a most sterling record. Nearly perfect (other than the fact they still recommend MD5 on BGP sessions :).
Until all transit networks are willing to strictly filter their
downstreams (and themselves!), if there is any unused space (note I said
"unused", not "unallocated"), the miscreants will use it.
serious curiosity:
what is the proportion of bad stuff coming from unallocated space vs
allocated space? real measurements, please. and are there longitudinal
data on this?
