I am a network engineer for Midcontinent Communications We are an ISP in the American Midwest. Recently, we were allocated a new network assignment: 96.2.0.0/16. We’ve been having major issues with sites still blocking this network. I normally wouldn’t blanket post to the group, but I’m looking to hit as many direct network engineers/operators as possible. Would it be possible to have people do a quick check on their inbound filters?
Thanks!
Eric Ortega
Midcontinent Communications
Network Engineer
605.357.5720 eric.ortega@midco.net
I am a network engineer for Midcontinent Communications We are an ISP in
the American Midwest. Recently, we were allocated a new network
assignment: 96.2.0.0/16. We've been having major issues with sites still
blocking this network. I normally wouldn't blanket post to the group,
but I'm looking to hit as many direct network engineers/operators as
possible. Would it be possible to have people do a quick check on their
inbound filters?
We found out last Thursday we were blocking that range (our customer base is
across the state line from this Midcon). Our upstream internet provider,
who manages the BGP side of things, had had their automated Bogon update
process stalled since last fall. =)
I am a network engineer for Midcontinent Communications We are an ISP in
the American Midwest. Recently, we were allocated a new network
assignment: 96.2.0.0/16. We've been having major issues with sites still
blocking this network. I normally wouldn't blanket post to the group, but
I'm looking to hit as many direct network engineers/operators as possible.
Would it be possible to have people do a quick check on their inbound
filters?
you may find the presentation i will be giving on thursday (bali time)
at apricot/apnic relevant, even though it is not being given in the
USA.
We found out last Thursday we were blocking that range (our customer base is
across the state line from this Midcon). Our upstream internet provider,
who manages the BGP side of things, had had their automated Bogon update
process stalled since last fall. =)
would love to know if anyone knows that indeed they were caught in
that list. fyi, the ASns listed are. would very much appreciate
o if you see your asn listed
o go to http://psg.com/filter-candidates.txt
o get the links associated with your as
o and tell us if indeed that link was filtering 96/8 97/8 or 98/8
about 22/23 jan 2007
i know its all the rage to post/shame the offending parties (those whois filtering
policies don't reflect our own) - BUT - how hard would it be for you perl jocks
to publish the ASNs of the "good guys"
none taken... although "name/shame" as a technique for
validating experimetnal results is a tried & ture method,
an equally valid technique is to look in the other direction
and praise/name those whose practices match your expected
results. ... i'd prefer to see the full curve, not just the
sigma-six folks on the left side.
well, at least i am actually doing research instead of doing nothing but
blindly whining abour anything by others that moves.
e.g. you may want to contemplate the silliness of your suggestion that
we list all the asns' links that were not troubled. the list of
suspected troubled links is a few kb. the list of good links would be
gigabytes and no one would look at it.
many thanks to those isps who have helped us with the validation so far.
the results have been quite cheering.
fwiw, the preso we gave a few hours ago on this research project is at
The amazing/sad thing is that people have been facing and fixing the same problem for more than 4 years. How many times does a network have to fix their static bogon filters before coming to the realization that those filters are a bad idea?
So, where are static bogon filters appropriate? (loaded question perhaps)
I ask because just about every 'security expert' and 'security whitepaper'
or 'security suggestions' has some portion that speaks to "why it's a
grand idea to have acl-lines/firewall-policy tp block 'bogon' ip space"
(for some definition of 'bogon' of course).
Obviously, one's bogon filters (both for iACLs and for prefix-lists or whatever other mechanism one uses to filter the route announcements one accepts) must be dynamic enough in nature to accommodate updates when new blocks are cracked open. 'Static' shouldn't be read as 'eternal', although that's often what ends up happening.
So, where are static bogon filters appropriate? (loaded question perhaps)
I ask because just about every 'security expert' and 'security whitepaper'
or 'security suggestions' has some portion that speaks to "why it's a
grand idea to have acl-lines/firewall-policy tp block 'bogon' ip space"
(for some definition of 'bogon' of course).
I suppose they're appropriate when done by network security consultants, as it guarantees future / repeat business.
I'll second this opinion, As most of DDoS attacks are from zombies, which are in registered networks.
Especially I did never see any traffic from so called bogons. Perhaps, bogon acls are helpful when they are configured on backbone, but not everywhere.
Perhaps,
bogon acls are helpful when they are configured on backbone, but not
everywhere.
And if ever major backbones (read tier 2/3) would do so all us little
guys wouldn't have to (yet for some reason I keep getting the odd hit
in my acl logs from bogon space daily).
Yes I know they will defend this with "we sell unfiltered service"
(which of course isn't true); I am just not convinced filtering bogon's
would invalidate this any more than their MPLS QoS clouds do.
