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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Ortega wrote:
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?
Pingable IP address in that network please :) - -- COO Entanet International T: 0870 770 9580 http://www.enta.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4xiRR+KszLBLUT8RAnR/AJ43MzH5PUaTflUsPU95MUp4iuZolQCfcJAZ Y6j4ipQBBseS/VhdvT8ry6c= =t+y8 -----END PGP SIGNATURE-----
After I sent that mail I realized that I didn't give enough information. 96.2.0.1 is pingable from the net. Thank you all for your quick response! -----Original Message----- From: James Blessing [mailto:james.blessing@entagroup.com] Sent: Monday, February 26, 2007 11:28 AM To: Eric Ortega Cc: nanog@merit.edu Subject: Re: 96.2.0.0/16 Bogons -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Ortega wrote:
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?
Pingable IP address in that network please :) - -- COO Entanet International T: 0870 770 9580 http://www.enta.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4xiRR+KszLBLUT8RAnR/AJ43MzH5PUaTflUsPU95MUp4iuZolQCfcJAZ Y6j4ipQBBseS/VhdvT8ry6c= =t+y8 -----END PGP SIGNATURE-----
I'd like to thank the group for the responses and help with this issue. I find it ironic that Randy's study actually uses 96 space. Thanks again! Eric -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Eric Ortega Sent: Monday, February 26, 2007 12:17 PM To: nanog@merit.edu Cc: 'James Blessing' Subject: RE: 96.2.0.0/16 Bogons After I sent that mail I realized that I didn't give enough information. 96.2.0.1 is pingable from the net. Thank you all for your quick response! -----Original Message----- From: James Blessing [mailto:james.blessing@entagroup.com] Sent: Monday, February 26, 2007 11:28 AM To: Eric Ortega Cc: nanog@merit.edu Subject: Re: 96.2.0.0/16 Bogons -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Ortega wrote:
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?
Pingable IP address in that network please :) - -- COO Entanet International T: 0870 770 9580 http://www.enta.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4xiRR+KszLBLUT8RAnR/AJ43MzH5PUaTflUsPU95MUp4iuZolQCfcJAZ Y6j4ipQBBseS/VhdvT8ry6c= =t+y8 -----END PGP SIGNATURE-----
On Wed, 28 Feb 2007, Eric Ortega wrote:
I'd like to thank the group for the responses and help with this issue. I find it ironic that Randy's study actually uses 96 space.
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? For my "solution" to the problem, see http://69box.atlantic.net/ It's also http://not69box.atlantic.net/ for the 69/8 challenged. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Wed, 28 Feb 2007, Eric Ortega wrote:
I'd like to thank the group for the responses and help with this issue. I find it ironic that Randy's study actually uses 96 space.
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). -Chris
On Mar 1, 2007, at 6:22 AM, Chris L. Morrow wrote:
So, where are static bogon filters appropriate?
#define static 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. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan
On Thu, 1 Mar 2007, Roland Dobbins wrote:
On Mar 1, 2007, at 6:22 AM, Chris L. Morrow wrote:
So, where are static bogon filters appropriate?
#define static
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.
I absolutely agree, but without some tool or process to follow... we get stuck acls/filters and no idea that there is a problem until it's far into the problem :(
On Mar 1, 2007, at 11:33 AM, Chris L. Morrow wrote:
I absolutely agree, but without some tool or process to follow... we get stuck acls/filters and no idea that there is a problem until it's far into the problem :(
There are canonical email lists on which these changes are announced, and Team Cymru maintain examples which are updated regularly. But, of course, you know this, so I suspect somehow you're trying to make a different kind of point. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
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. :) ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon Lewis wrote:
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
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. just my 1E-10 cents :-) -- With best regards, Gregory Edigarov
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.
On Thu, Mar 01, 2007 at 07:16:37AM -0800, Peter Thoenen wrote: [Thoenen seems to have clipped the attribution]
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.
There are smaller internets that are large enough that one person is not managing all of the routers, but small enough that policy can be "MANAGED" across all of them. Some of these required implementation of the bogon lists. As they are small, this rarely changes - so when a change to the bogon list comes, some resist this as if an article of their faith were being challenged. Even within the group managing the backbone. As I'm STILL fighting skirmishes on this front, I'm less happy about bogon lists than I once was. "Leaf" networks should perform egress filtering, everyone knows that now [;-} we wish]. Service provider networks should probably filter on connections to the "customer" networks to allow only that customer's IPs, but on connections to "transit" networks to only eliminate the truly "unroutable" IP addresses such as RFC 1918. However, since it is not possible to require this or anything else on the public Internet, except by making sure that all routers are run by clueful people who have entered into mutual agreement to do this [sorry, dreaming again], this is not likely to happen. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
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. :)
ah-ha! but seriously, is this something an NSP/ISP should be doing? or is this an enterprise function? or MSSP function? Are there standard tools available to notify folks when changes occur? (aside from: "go check iana.org website" or "golly traffic's not flowing anymore") -Chris
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
ah-ha! but seriously, is this something an NSP/ISP should be doing? or is this an enterprise function? or MSSP function? Are there standard tools available to notify folks when changes occur? (aside from: "go check iana.org website" or "golly traffic's not flowing anymore")
Such updates get posted to various places like nanog, cisco-nsp, probably other -nsp lists, and such...but for the large number of ASNs not represented at all on those lists, I don't know how they're supposed to "get notified" every time a bogon ceases to be. My own experience with this was that its very diffifcult to find your way to the clue at organizations with such filter issues...and even when you find such breakage, its hard to tell from the outside which end of a connection has the filter issue. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, 1 Mar 2007, Jon Lewis wrote:
Such updates get posted to various places like nanog, cisco-nsp, probably other -nsp lists, and such...but for the large number of ASNs not represented at all on those lists, I don't know how they're supposed to "get notified" every time a bogon ceases to be. My own experience with
right, so often the acls/filters/policies get setup at install time, the installer leaves/changes-jobs/blah and 2 years later the noc/net-admin at the smaller-isp or hosting company or enterprise ends up not knowing what this portion of the config might be doing, so it doesn't get touched... The challenge for folks on the far side of this problem (69box.atlantech.net for instance or midco) is finding a way to get this adjusted. So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours) The cisco auto-secure feature sure showed some fun effects for this too, eh?
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
The challenge for folks on the far side of this problem (69box.atlantech.net for instance or midco) is finding a way to get this adjusted.
69box.atlantic.net
So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours) The cisco auto-secure feature sure showed some fun effects for this too, eh?
If by core you mean the "tier 1's" where in theory there are people with enable keeping up with the community mailing lists, then sure, bogon filters there sure beat bogon filters at every enterprise where they 'set it and forget it.' ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours) The cisco auto-secure feature sure showed some fun effects for this too, eh?
We managed to fix that mis-application in later releases, but it has human dependency for that set of releases. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_field_notice... Like security "experts" the recommend blocking calls in the North American numbering plan to area code 809, or listing individual area codes in PBXs, its not a good idea unless you have full-time telephone LERG engineers. My rule of thumb is networks which use the "default" route probably should not implement bogon filters of reserved for future allocation addresses. Of course, they should still implement postive outbound traffic controls (i.e. BCP38++) on their own traffic. Even if the current engineers are careful, people change, but the new people may not know or forget about updating miscellanous routers especially in networks with "default" routing. Most RFC3330 Special Use Addresses which should not appear on the public Internet probably should be dropped crossing Internet provider boundaries unless specifically allowed, i.e. RFC1918, 127/8, 169.254/16, 224/4, 240/4, etc. That does not include other addresses mentioned in RFC3330 like 14/8, 24/8, 223.255.255.0/24 which are/will be routable on the public Internet. Most backbones already apply some filter like this to their BGP sessions and it can be optimized for hardware support even on very high traffic links. This is pretty low-risk, low-change traffic hygiene. So what about filtering reserved for future use "unallocated" IP addresses between "default-free" backbones? Is it enough of a real problem to overcome the other hurdle of making operational changes/errors in major backbone interconnects. Or is the current practice of whacking the traffic when it causes a problem, whether its from allocated or unallocated space sufficient? Personally, I think the current practice of whacking problem traffic from unallocated IP addresses seems sufficient. If people decide its enough of a problem that backbones must take the operational risk to change filters, then I think IANA must adopt a more predictable schedule. For example, IANA announces future allocations at each IETF meeting which will become allocated for use after the next IETF meeting to give backbones 3-4 months to schedule the change.
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours)
Antispoofing is 'static' and therefore brittle in nature, people change jobs, etc. - so, we shouldn't do antispoofing, either? Enterprises typically don't do this stuff. They should, and we work to educate them, but it's even more difficult in that space than in the SP space. A question I have is whether or not this class of problems is more of a 'need the vendors to come up with better/easier functionality' type of problem, a 'need the SPs to do a better job with this' kind of problem, or is it more in the realm of a 'TCP/IP in its current incarnation(s) lends itself these kinds of issues' type of problem? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan
On Thu, Mar 01, 2007, Roland Dobbins wrote:
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours)
Antispoofing is 'static' and therefore brittle in nature, people change jobs, etc. - so, we shouldn't do antispoofing, either?
Enterprises typically don't do this stuff. They should, and we work to educate them, but it's even more difficult in that space than in the SP space.
A question I have is whether or not this class of problems is more of a 'need the vendors to come up with better/easier functionality' type of problem, a 'need the SPs to do a better job with this' kind of problem, or is it more in the realm of a 'TCP/IP in its current incarnation(s) lends itself these kinds of issues' type of problem?
As stuff like Ironport shows - you'll probably have better market penetration by making a little knob labelled "filter unknown and unallocated IP prefixes (default on)" on a nice shiny firewall appliance/blade and charge the enterprise $150pm to keep this up to date. (Then another for "filter hosts actively involved in hacking attempts" for another $300 pm.) (And, finally, "check active IP(s) that I'm transiting against the various list(s) of botnet and CERT related activities, send SNMP trap when matches are found" for even more.) Adrian
Roland Dobbins <rdobbins@cisco.com> writes:
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours)
Antispoofing is 'static' and therefore brittle in nature, people change jobs, etc. - so, we shouldn't do antispoofing, either?
Unicast RPF is neither static nor brittle, and we should do it. I agree with smb though in somewhat less diplomatic terms - bogon filtering by end sites is the sort of thing that is recommended by "experts" for whom "security" is an end in and of itself, rather than a component of the arsenal you bring forth (backups, DR, spares, multihoming, etc) to improve uptime and business availability and decrease potential risk. For people who recommend cures that are as bad as the disease, we recommend one of these: http://despair.com/consulting.html ---Rob
On Mar 2, 2007, at 4:12 AM, Robert E. Seastrom wrote: uRPF isn't always adequate for all antispoofing cases, as you know. What about iACLs?
bogon filtering by end sites is the sort of thing that is recommended by "experts" for whom "security" is an end in and of itself, rather than a component of the arsenal you bring forth (backups, DR, spares, multihoming, etc) to improve uptime and business availability and decrease potential risk.
I don't claim to be an 'expert' at anything, but I most certainly - do- recommend bogon filtering, along with multihoming, infrastructure self-protection measures (iACLs, rACLs, CoPP, core-hiding, et. al.), various antispoofing techniques (all the way down to layer-2 where possible), instrumentation and telemetry, anomaly-detection, reaction tools, layer-7 things like backup and DR, layer-8 things like sparing, and so forth. And my goal isn't 'security', it's a resilient Internet infrastructure which keeps the packets flowing so that the users can access the applications which are the point of the whole exercise. I'm not the only one who thinks like that, either. So, painting us all with the same broad brush hardly seems fair, does it? Rejecting bogon filtering out of hand because it isn't effortless to maintain doesn't make much sense to me. After all, if one's being a good Internet neighbor, one's doing ingress filtering (routes and packets) from one's customers and egress filtering (routes and packets) to one's peers/transits/customers, anyways; one will see more churn there than in the bogon lists. It's also part of the very basic protections which ought to be provided to one's customers. No, the SP can't be the 'Internet firewall' for customers, and, no, the SP can't be expected to keep the customer magically protected from all the Bad Things which can happen to him (and for free, naturally), but protecting one's customers from being spammed/packeted from purported source addresses which are by definition nonsensical (as well as protecting everyone else's customers from same) doesn't seem much to ask. What's needed here are better/easier/less brittle mechanisms for same. Until such time as they're invented and deployed, let's not make the perfect the enemy of the merely good, yes? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan
Hey, Chris.
ah-ha! but seriously, is this something an NSP/ISP should be doing? or is this an enterprise function? or MSSP function? Are there standard tools available to notify folks when changes occur? (aside from: "go check iana.org website" or "golly traffic's not flowing anymore")
We have two ways to notify folks: 1. bogon-announce list, <http://puck.nether.net/mailman/listinfo/ bogon-announce> 2. Automated updates with the bogon route-servers, <http:// www.cymru.com/BGP/bogon-rs.html> Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ cmn_err(do_panic, "Out of coffee!");
On Thu, 01 Mar 2007 14:22:37 +0000 (GMT) "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> wrote:
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Wed, 28 Feb 2007, Eric Ortega wrote:
I'd like to thank the group for the responses and help with this issue. I find it ironic that Randy's study actually uses 96 space.
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).
Well, not all of us advocate that; see http://www.merit.edu/mail.archives/nanog/2006-01/msg00150.html --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Thu, 01 Mar 2007 21:08:59 EST, "Steven M. Bellovin" said:
On Thu, 01 Mar 2007 14:22:37 +0000 (GMT)> "Chris L. Morrow" <christopher.morrow@verizonbusiness.com> wrote:
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).
Well, not all of us advocate that; see http://www.merit.edu/mail.archives/nanog/2006-01/msg00150.html
Well Steve, it's like this: There are (a) security experts, (b) "security experts", and (c) guys that spend their day making things usable in spite of what the rest of the net throws in their AS's direction. You're an example of one, I'm an example of another, and the advocates of static bogon filters are an example of the third. Figuring out which is which is left as an exercise for the reader...
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Chris L. Morrow Sent: Thursday, March 01, 2007 6:23 AM To: Jon Lewis Cc: Eric Ortega; nanog@merit.edu Subject: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
On Thu, 1 Mar 2007, Jon Lewis wrote:
On Wed, 28 Feb 2007, Eric Ortega wrote:
I'd like to thank the group for the responses and help with this issue. I find it ironic that Randy's study actually uses 96 space.
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).
-Chris
Agreed. This "security experts copying each other - without knowing what they are really talking about" started to happen 4 years ago. Which is why some people working with SP all over moved evolving work of Bogon/DUSA prefix filtering to two places, CYMRU's sponsored "Bogon" project and RIPE (work like http://www.ripe.net/ripe/docs/ripe-351.html). Both places allow for policy practice suggestions to evolve. And they have evolved - working with operators who are working to institute policies and practices in their organization which is resistant to operational entropy. For example, http://www.cymru.com/Bogons/index.html describes the static policies for people to get started. Static is not the way to go. Operators who understand the impact of "operational entropy" (OPEX growth) want dynamic tools. Hence, they spend time find a tool which is a multipurpose dynamic prefix policy system (i.e. something that does their customer's prefixes, anti-spoofing, DUSA, Bogon, Black Hole, and Hijack). This is why the Bogon reference page has grown over the years adding tricks and tools to build prefix filters dynamically: -> The Bogon Route Server Project (http://www.cymru.com/BGP/bogon-rs.html) allows SPs to take a feed or build their own. -> RADb -> RIPE NCC -> DNS Bogon Tracking -> E-mail Bogon Tracking To 'globally' monitor, we have http://www.cymru.com/BGP/robbgp-bogon.html and http://www.cymru.com/BGP/asnbogusrep.html and http://www.cidr-report.org/ and http://www.routeviews.org/ and http://www.completewhois.com/bogons/active_bogons.htm. (Steve B, you were looking for data, here are your sources. I'm sure Geoff might be persuaded to do a historical graph on the 'Possible Bogons.') To organizationally monitor, J & C both have the ability to count the prefix drops. It was operators who taught me both of these tricks - which allow them to put in prefix filters which included bogons, then count the packets originating from those filters prefixes get dropped -- one pulling all that data via SNMP and plugged it into MRTG so they know the count of packets coming from their peers whose source is in the Bogon/DUSA list. Just remember the real reason we do this. 7007 demonstrated an operational risk to networks. That risk is a cascading risk (prefix advertisements moving from one network to another). Jump on a miscreant shopping mall, buy a bunch of BGP speaking "owned" routers, check out which ones do not have any upstream prefix filters, and have fun. The two reasons why this has not happened is 1) enough SPs do ingress prefix filters with their peers to disrupt this attack vector and 2) there is no way to 'extort' money from the Internet (Miscreant principle #3 - never to anything for free). Has this risk gone away? When it has been demonstrated to NOT be a risk, organizations will change their prefix filter policies. In the mean time, each organization on the Internet who have perceived operational risk mitigation benefits from ingress prefix filtering will keep on doing it.
On Sun, 4 Mar 2007 07:46:12 -0800 "Barry Greene (bgreene)" <bgreene@cisco.com> wrote:
To 'globally' monitor, we have http://www.cymru.com/BGP/robbgp-bogon.html and http://www.cymru.com/BGP/asnbogusrep.html and http://www.cidr-report.org/ and http://www.routeviews.org/ and http://www.completewhois.com/bogons/active_bogons.htm.
(Steve B, you were looking for data, here are your sources. I'm sure Geoff might be persuaded to do a historical graph on the 'Possible Bogons.')
I'd love to see a paper based such data. And I'll suggest that SRUTI -- http://www.usenix.org/events/sruti07/cfp and yes, I'm the program chair -- would be a perfect venue for the analysis. --Steve Bellovin, http://www.cs.columbia.edu/~smb
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. =) Frank ________________________________ From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Eric Ortega Sent: Monday, February 26, 2007 11:26 AM To: nanog@merit.edu Subject: 96.2.0.0/16 Bogons 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
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. =)
frank, could your links be in http://psg.com/filter-candidates.txt 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 thanks! randy 174 209 286 293 701 702 703 721 1239 1267 1273 1299 1668 2152 2497 2500 2828 2854 2914 3257 3292 3320 3343 3356 3491 3549 3561 4323 4637 4755 4761 4766 5400 5539 5568 6429 6453 6461 6467 6471 6517 6619 6730 7018 7473 7474 7575 8468 8928 9942 10026 11908 11955 12180 12695 12956 13237 15412 15830 17557 19029 19094 19151 19158 19752 21318 21413 21414 21922 22291 22773 23342 23504 25462 25973 29226 29278 29668 32869 -30-
Randy: Sorry, our upstream provider's ASN is not listed in that filter-candidates.txt document. Kind regards, Frank -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, February 26, 2007 4:34 PM To: Frank Bulk Cc: nanog@merit.edu Subject: RE: 96.2.0.0/16 Bogons
We found out last Thursday we were blocking that range (our customer base is across the state line from this Midcon).
frank, could your links be in http://psg.com/filter-candidates.txt 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 thanks! randy 174 209 286 293 701 702 703 721 1239 1267 1273 1299 1668 2152 2497 2500 2828 2854 2914 3257 3292 3320 3343 3356 3491 3549 3561 4323 4637 4755 4761 4766 5400 5539 5568 6429 6453 6461 6467 6471 6517 6619 6730 7018 7473 7474 7575 8468 8928 9942 10026 11908 11955 12180 12695 12956 13237 15412 15830 17557 19029 19094 19151 19158 19752 21318 21413 21414 21922 22291 22773 23342 23504 25462 25973 29226 29278 29668 32869 -30-
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" --bill
On Tue, Feb 27, 2007 at 08:25:13AM +0900, Randy Bush wrote:
i know its all the rage to post/shame the offending parties (those whois filtering policies don't reflect our own)
bull
we are trying to validate experimental results. sorry if that offends you or you do your research result validation differently.
randy
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. --bill
bmanning@karoshi.com wrote:
On Tue, Feb 27, 2007 at 08:25:13AM +0900, Randy Bush wrote:
i know its all the rage to post/shame the offending parties (those whois filtering policies don't reflect our own) bull
we are trying to validate experimental results. sorry if that offends you or you do your research result validation differently.
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.
your issues might be better based if you knew anything about what was happening instead of shooting off mouth in dark. as i already said, but somehow you missed. preso will be this afternoon (gmt+8). i will try to post a pointer here. randy randy
On Wed, Feb 28, 2007 at 07:49:40AM +0800, Randy Bush wrote:
bmanning@karoshi.com wrote:
On Tue, Feb 27, 2007 at 08:25:13AM +0900, Randy Bush wrote:
i know its all the rage to post/shame the offending parties (those whois filtering policies don't reflect our own) bull
we are trying to validate experimental results. sorry if that offends you or you do your research result validation differently.
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.
your issues might be better based if you knew anything about what was happening instead of shooting off mouth in dark.
as i already said, but somehow you missed. preso will be this afternoon (gmt+8). i will try to post a pointer here.
randy
your interpersonal skills are improving. will be interesting in the reported progress of your experiments. --bill (gmt+10)
your interpersonal skills are improving.
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 http://rip.psg.com/~randy/070228.apnic-bogons.pdf randy
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. randy
participants (18)
-
Adrian Chadd -
Barry Greene (bgreene) -
bmanning＠karoshi.com -
Chris L. Morrow -
Eric Ortega -
Frank Bulk -
Gregory Edigarov -
James Blessing -
Jon Lewis -
Joseph S D Yao -
Peter Thoenen -
Randy Bush -
Rob Thomas -
Robert E. Seastrom -
Roland Dobbins -
Sean Donelan -
Steven M. Bellovin -
Valdis.Kletnieks＠vt.edu