Re: Best way to get of Bogon list?
Exactly what I have been doing for last week 2 weeks now. Thanks, Majid -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Suresh Ramasubramanian <suresh@outblaze.com> To: Majid Farid <MajidFarid@TelecomOttawa.com>; nanog@merit.edu <nanog@merit.edu> Sent: Thu Nov 25 21:56:04 2004 Subject: Re: Best way to get of Bogon list? Majid Farid <MajidFarid@TelecomOttawa.com> wrote:
I have question for the list what would be best/fastest way to get off bogon list. Arin allocated us a /19 2 months ago (72.1.192.0/19) We find that a lot of providers aren't accepting the BGP advertisements for that block because the block 72.0.0.0/8 was on bogon list.
There's only one widely used "list" of bogons that I know of - bogons.cymru.com, and that is quite well updated. What you are seeing is a whole bunch of providers who have hardcoded bogon lists into their router ACLs, manually. The fastest way for you to get off these providers' ACLs is going to be "call each provider's NOC and tell them to update their filters". srs
On 2004-11-26, Majid Farid <MajidFarid@TelecomOttawa.com> wrote:
This is a multi-part message in MIME format.
Have fun :) I hate to say it, but that is the only way. You aren't dealing with a single bogon blocking list, you're dealing with a whole lot of providers who are way behind the times and you just have to go on contacting them one at a time. srs
From: Suresh Ramasubramanian <suresh@outblaze.com> Majid Farid <MajidFarid@TelecomOttawa.com> wrote:
I have question for the list what would be best/fastest way to get off bogon list. Arin allocated us a /19 2 months ago (72.1.192.0/19) We
The fastest way for you to get off these providers' ACLs is going to be=20 "call each provider's NOC and tell them to update their filters".
On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote:
I hate to say it, but that is the only way.
You aren't dealing with a single bogon blocking list, you're dealing with a whole lot of providers who are way behind the times and you just have to go on contacting them one at a time.
Its not even just providers. If it were, it'd be relatively easy to just find and call each NOC. You're likely to have bogon issues with few large providers. It's mostly smaller providers and end user networks...some of which are quite large or high profile. Do what I did and give people a way to test connectivity from both affected and unaffected space and setup a 'hall of shame' page listing the IPs/networks that are behind broken filters. If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, 25 Nov 2004, Jon Lewis wrote:
Its not even just providers. If it were, it'd be relatively easy to just find and call each NOC. You're likely to have bogon issues with few large providers. It's mostly smaller providers and end user networks...some of which are quite large or high profile.
Do what I did and give people a way to test connectivity from both affected and unaffected space and setup a 'hall of shame' page listing the IPs/networks that are behind broken filters. Can someone identify the *benefits* of using bogon lists for unallocated space? It appears that it only hurts connectivity, but does not help in any significant way to enhance security.
Possibly, whoever are the vendors of software that recommends this practice (and authors of security handbooks) should be show the error of their ways? -alex
alex@pilosoft.com wrote:
Can someone identify the *benefits* of using bogon lists for unallocated space? It appears that it only hurts connectivity, but does not help in any significant way to enhance security.
Possibly, whoever are the vendors of software that recommends this practice (and authors of security handbooks) should be show the error of their ways?
Is this where we restart the BCP38 thread and then argue that if everybody implemented BCP38, people wouldn't need to use this? srs
On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote:
Possibly, whoever are the vendors of software that recommends this practice (and authors of security handbooks) should be show the error of their ways?
Is this where we restart the BCP38 thread and then argue that if everybody implemented BCP38, people wouldn't need to use this? I dare to say that even without wholesale BCP38 implementation, benefit of bogon-filtering unallocated space is tiny compared to cost of lost connectivity due to the filters that aren't updated.
-alex
On Fri, Nov 26, 2004 at 01:02:27AM -0500, alex@pilosoft.com wrote:
On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote:
Possibly, whoever are the vendors of software that recommends this practice (and authors of security handbooks) should be show the error of their ways?
Never heard of a particular software vendor nor security author disctating it, but then perhaps that's because some of us set things up based on real experience and don't always see those who come after.
I dare to say that even without wholesale BCP38 implementation, benefit of bogon-filtering unallocated space is tiny compared to cost of lost connectivity due to the filters that aren't updated.
That's a change mgmt complaint, not a bogon filter complaint. There are many many many of us who experience concrete benefits and zero problems WRT bogon filters. I suspect those stating there's no benefit never actually used them. Vote with your wallet, etc etc. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Fri, 26 Nov 2004 alex@pilosoft.com wrote:
Can someone identify the *benefits* of using bogon lists for unallocated space? It appears that it only hurts connectivity, but does not help in any significant way to enhance security.
It makes people feel like they're more secure. It may cut down slightly on junk traffic entering their networks, but I suspect thats an insignifigantly small amount / benefit.
Possibly, whoever are the vendors of software that recommends this practice (and authors of security handbooks) should be show the error of their ways?
Unfortunately, there are many sources that advocate/demonstrate how to do these filters, some of which still have their examples out of date wrt current IANA assignments. The problem isn't so much the idea, but the implementation. Static unmaintained filters pretty much guaranteed to become a problem at some point. And yeah, if nobody could spoof, and everyone filtered customer BGP announcements, there'd be no need at all (not that there really is one now) for these filters. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon Lewis <jlewis@lewis.org> wrote:
It makes people feel like they're more secure.
aka "airport security". Inconvenience the users, and achieve nothing useful.
It may cut down slightly on junk traffic entering their networks, but I suspect thats an insignifigantly small amount / benefit.
s/junk// Why not just block 0/0 and be done with it? -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key
On Fri, 26 Nov 2004 alex@pilosoft.com wrote:
On Thu, 25 Nov 2004, Jon Lewis wrote:
Its not even just providers. If it were, it'd be relatively easy to just find and call each NOC. You're likely to have bogon issues with few large providers. It's mostly smaller providers and end user networks...some of which are quite large or high profile.
Do what I did and give people a way to test connectivity from both affected and unaffected space and setup a 'hall of shame' page listing the IPs/networks that are behind broken filters. Can someone identify the *benefits* of using bogon lists for unallocated space? It appears that it only hurts connectivity, but does not help in any significant way to enhance security.
It might be a way to proactively keep your part of the network 'cleaner' than the other parts... 'managed' properly and 'updated' regularly (when changes dictate an update is required) it might even be seemless to your userbase. The devil here is, as always, in the details. Once you move beyond some number of devices or acls or 'parts', making changes on a wide scale and keeping things up to date becomes more difficult. Change management and the number of hands in the pot seem to make these things much more challenging.
Possibly, whoever are the vendors of software that recommends this practice (and authors of security handbooks) should be show the error of their ways?
if they did they'd lose part of their punch :( And lose some of their readerbase... and who'd call you to complain? :)
On 26-nov-04, at 8:29, Christopher L. Morrow wrote:
Can someone identify the *benefits* of using bogon lists for unallocated space? It appears that it only hurts connectivity, but does not help in any significant way to enhance security.
It might be a way to proactively keep your part of the network 'cleaner' than the other parts... 'managed' properly and 'updated' regularly (when changes dictate an update is required) it might even be seemless to your userbase.
The devil here is, as always, in the details. Once you move beyond some number of devices or acls or 'parts', making changes on a wide scale and keeping things up to date becomes more difficult.
I've never been a fan of bogon packet filtering (bogon route filtering is more useful), but it occurs to me that it's probably better for us network opertors to do this rather than have each and every firewall admin do it for themselves. I.e., in networks that do proper BCP38 filtering towards their customers and bogon filtering on the edges to other networks, customers will never see packets from bogon sources, making it unnecessary for them to filter those themselves and thereby improving the plight of those who get address space that was recently allocated to a RIR by the IANA.
On Fri, 26 Nov 2004, Iljitsch van Beijnum wrote:
On 26-nov-04, at 8:29, Christopher L. Morrow wrote:
Can someone identify the *benefits* of using bogon lists for unallocated space? It appears that it only hurts connectivity, but does not help in any significant way to enhance security.
It might be a way to proactively keep your part of the network 'cleaner' than the other parts... 'managed' properly and 'updated' regularly (when changes dictate an update is required) it might even be seemless to your userbase.
The devil here is, as always, in the details. Once you move beyond some number of devices or acls or 'parts', making changes on a wide scale and keeping things up to date becomes more difficult.
I've never been a fan of bogon packet filtering (bogon route filtering is more useful), but it occurs to me that it's probably better for us network opertors to do this rather than have each and every firewall admin do it for themselves.
be it 'route' filtering or packet filtering' the end result is the same in this case, eh? (no route back means packet drop). Being the internet's firewall is a dangerous proposition, ask those that dropped ICMP on large backbones during welchia... :( Anyway, the problem from the requestor is only going to be remedied by him contacting all the 'bad' people, or their users contacting their providers to get to his interesting content :( Another poster pointed out that static filters are just a bad plan, that reminds me I need to automate updates to the filters on some other things :( I'll bet I'm blocking the original poster's access to some places too :(
I.e., in networks that do proper BCP38 filtering towards their customers and bogon filtering on the edges to other networks, customers will never see packets from bogon sources, making it unnecessary for them to filter those themselves and thereby improving the plight of those who get address space that was recently allocated to a RIR by the IANA.
To some extent this is correct, but these users really need to learn to effectively protect themselves. In the long term atleast.
On 27-nov-04, at 9:02, Christopher L. Morrow wrote:
I've never been a fan of bogon packet filtering (bogon route filtering is more useful), but it occurs to me that it's probably better for us network opertors to do this rather than have each and every firewall admin do it for themselves.
be it 'route' filtering or packet filtering' the end result is the same in this case, eh?
Well, with uRPF you can turn route filtering into packet filtering, but otherwise they're different. There is nothing bad that a packet with a bogon source can do that a packet with a non-bogon source can't do too. But spammers and the like can hijack unused address space to do untracable nastiness if these routes aren't filtered.
Being the internet's firewall is a dangerous proposition, ask those that dropped ICMP on large backbones during welchia... :(
There are two big difference between filtering packets with bogon sources and firewalling in general: the bogon stuff can be done just by looking at the source address, and these packets never serve any useful purpose, so they can be filtered anywhere, anytime without problems. (While with ICMP some crazy people actually like to get the port unreachables rather than having to wait for a timeout, or for PMTUD to work.)
To some extent this is correct, but these users really need to learn to effectively protect themselves. In the long term atleast.
Never teach a pig to sing: it wastes your time and annoys the pig.
On Sat, 27 Nov 2004 18:03:28 +0100, Iljitsch van Beijnum said:
To some extent this is correct, but these users really need to learn to effectively protect themselves. In the long term atleast.
Never teach a pig to sing: it wastes your time and annoys the pig.
I've always wondered whether said pig needs pilot training when it gets the RFC1925 rocket packs attached..... The lack of adequate pilot and flight safety training for the victims(*) is a deployment issue for any reasonable firewall/security scheme - either it really *does* have to be "victim is along for the ride", or we're going to be sitting in the control tower talking them through the landing.... (*) victims - sometimes the users, sometimes the ISP....
On Thu, Nov 25, 2004 at 10:29:51PM -0500, Jon Lewis wrote:
On Fri, 26 Nov 2004, Suresh Ramasubramanian wrote:
I hate to say it, but that is the only way.
You aren't dealing with a single bogon blocking list, you're dealing with a whole lot of providers who are way behind the times and you just have to go on contacting them one at a time. If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters.
http://puck.nether.net/~jared/papers/69-paper.html I can rewrite this slightly and post it on slashdot and other places again.. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters.
http://puck.nether.net/~jared/papers/69-paper.html
I can rewrite this slightly and post it on slashdot and other places again..
I think it would be useful. The "Bogon Team" implemented several changes after 69/8 to make "change management" easier. This included maintain objects at Merit RADB, RIPE NCC RADB, and a way to track via DNS (see the details on http://www.cymru.com/Bogons/index.html). Of course the biggest service CYRMU added to help people with "change management" was the Bogon Route Server (http://www.cymru.com/BGP/bogon-rs.html). So with all these "change management" tools done for the operations community, it looks like we still need some "policing" service. Note from mine and Hank's "CIDR Police" Experiment, we know that have a "list of shame" is not effective. The only way it works is if you have people who act as 'police,' use the list of shame, and knock on people's door. 90% of the time, people eventually respond and make the changes. But the impact only remains as long as you have people to go knocking on the doors. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQas4TL/UEA/xivvmEQIf9gCcCGMjrDGhKvOGMAtXoOhYy/J/CcgAniBM zT0m/7YQhl7z+qjlbqaTNXWs =dA2u -----END PGP SIGNATURE-----
On Mon, Nov 29, 2004 at 07:04:28AM -0800, Barry Raveendran Greene wrote:
Jared Mauch:
jlewis: If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters.
http://puck.nether.net/~jared/papers/69-paper.html
I can rewrite this slightly and post it on slashdot and other places again..
I think it would be useful. The "Bogon Team" implemented several changes after 69/8 to make "change management" easier. This included maintain objects at Merit RADB, RIPE NCC RADB, and a way to track via DNS (see the details on http://www.cymru.com/Bogons/index.html).
I'll write up a new version of this. Can those of you that are having problems in the 70/8 and 71/8 space write me a snippet in private email saying how this is impacting them? One paragraph please, also include your full name and employer or whom you represent. this way i can include the impact seen in it so people *may* wake up and realize the impact of lack of maintence of these filters. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (12)
-
abuse＠cabal.org.uk -
alex＠pilosoft.com -
Barry Raveendran Greene -
Christopher L. Morrow -
Iljitsch van Beijnum -
Jared Mauch -
Joe Provo -
Jon Lewis -
Majid Farid -
Suresh Ramasubramanian -
suresh＠outblaze.com
-
Valdis.Kletnieks＠vt.edu