Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Yes - the space in question was allocated last January - it looks like not everyone has updated their bogon access lists to remove this space from the bogon list. On Wed, 19 Jan 2005 13:51:11 -0500 Kurt Kruegel <kurt@amnh.org> wrote:
from http://www.cymru.com/Documents/bogon-list.html
Changes in version 2.5 (02 AUG 2004) 71/8 and 72/8 allocated to ARIN (AUG 2004). Removed from the bogon lists. Changes in version 2.4 (28 APR 2004) 58/8 and 59/8 allocated to the APNIC (APR 2004). Removed from the bogon lists. Changes in version 2.3 (01 APR 2004) 85/8, 86/8, 87/8, and 88/8 allocated to the RIPE NCC (APR 2004). Removed from the bogon lists. Changes in version 2.2 (15 JAN 2004) 70/8 allocated to ARIN (JAN 2004). Removed from the bogon lists.
At 10:20 AM 1/19/2005 -0800, Richard J. Sears wrote:
_______________________________ From: jamesl@pcipros.com Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog@merit.edu' Subject: BOGON Filtering IP Space? Our NOC is opening a lot of tickets for customers that live on our 72.14.128.0/19 network going towards local and federal government sites in particular. I'm curious if providers / vendors / managed service providers are BOGON filtering this network range as it's relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove - it's real space. :-) I'd appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. james@pcipros.com 760-807-5129 24x7 NOC contact 951-541-9688 office Return-Path: X-Original-To: rsearsadn@pop3-02.adnc.com Delivered-To: rsearsadn@pop3-02.adnc.com Received: from smtp01.adnc.com (smtp01.adnc.com [206.251.248.151]) by pop3-02.adnc.com (Postfix) with ESMTP id D869735C056 for ; Wed, 19 Jan 2005 10:18:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp01.adnc.com (Postfix) with ESMTP id BA3601BCC6D for ; Wed, 19 Jan 2005 10:17:17 -0800 (PST) Received: from smtp01.adnc.com ([127.0.0.1]) by localhost (smtp01.adnc.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 20263-01-59 for ; Wed, 19 Jan 2005 10:17:15 -0800 (PST) Received: from sandcaexch01.pcipros.net (unknown [207.158.33.163]) by smtp01.adnc.com (Postfix) with ESMTP id 2B9E01BC7DA for ; Wed, 19 Jan 2005 10:17:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 MIME-Version: 1.0 Subject: FW: BOGON Filtering IP Space? Date: Wed, 19 Jan 2005 10:24:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BOGON Filtering IP Space? Thread-Index: AcT+TgcBXRcsgfNZT8u0oENeEuZ2VQAAjpjgAADzviA= From: "James Laszko" To: "Richard J. Sears" X-Virus-Scanned: by amavisd-new at smtp01.adnc.com X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on pop3-02.adnc.com X-Spam-Status: No, hits=-4.6 required=3.0 tests=BAYES_00,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.61 X-Spam-Level: X-UIDL: It doesn’t appear to be showing up at all when I send it in………. From: jamesl@pcipros.com Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog@merit.edu' Subject: BOGON Filtering IP Space? I’m curious if providers / vendors / managed service providers are BOGON filtering this network range as it’s relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove – it’s real space. J I’d appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. james@pcipros.com 760-807-5129 24x7 NOC contact 951-541-9688 office
Kurt A Kruegel, CCNP, DP, SP, CISSP#30711 Senior Network Administrator Network Systems American Museum of Natural History Central Park West at 79th Street New York, New York 10024 (P) 212-496-3601 (F) 212-496-3555 (E) kurt@amnh.org (W) http://www.amnh.org
****************************************** Richard J. Sears Vice President American Internet Services ---------------------------------------------------- rsears@adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."
--- "Richard J. Sears" <rsears@americanIS.net> wrote:
Yes - the space in question was allocated last January - it looks like not everyone has updated their bogon access lists to remove this space from the bogon list.
I think that Cisco's Autosecure feature is part of the problem here: http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_feature_guid... While it says that bogon filters change, and provides a URL to check it, what percentage of folks who would use a feature like "autosecure" would ever update their filters? sigh. ===== David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
David Barak <thegameiam@yahoo.com> wrote:
While it says that bogon filters change, and provides a URL to check it, what percentage of folks who would use a feature like "autosecure" would ever update their filters?
What do they do to update that bogon list anyway - push a new IOS image? srs
On Thu, Jan 20, 2005 at 06:26:15PM +0530, Suresh Ramasubramanian wrote:
David Barak <thegameiam@yahoo.com> wrote:
While it says that bogon filters change, and provides a URL to check it, what percentage of folks who would use a feature like "autosecure" would ever update their filters?
What do they do to update that bogon list anyway - push a new IOS image?
Actually, my assumption is anyone with autosecure gets free software upgrades for life, as this is a flexible list that will change over time. Each time a change is made they need to release new software, and notify their installed customer base. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Thu, 20 Jan 2005 09:29:34 -0500, Jared Mauch <jared@puck.nether.net> wrote:
Actually, my assumption is anyone with autosecure gets free software upgrades for life, as this is a flexible list that
... or as long as your support contract with cisco lasts, whichever comes earlier. -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Thu, Jan 20, 2005 at 08:03:42PM +0530, Suresh Ramasubramanian wrote:
On Thu, 20 Jan 2005 09:29:34 -0500, Jared Mauch <jared@puck.nether.net> wrote:
Actually, my assumption is anyone with autosecure gets free software upgrades for life, as this is a flexible list that
... or as long as your support contract with cisco lasts, whichever comes earlier.
No, cisco providing a time sensitive feature like this implies free upgrades to repair this critical defect. Just like they give out free software to people without contracts when they have a major security vulnerability. Seems like this falls in the same category to me. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Thu, 20 Jan 2005 09:42:54 -0500, Jared Mauch <jared@puck.nether.net> wrote:
No, cisco providing a time sensitive feature like this implies free upgrades to repair this critical defect. Just like they give out free software to people without contracts when they have a major security vulnerability.
Seems like this falls in the same category to me.
Analogies suck, but look at (for example) Norton AntiVirus. You pay for a year of virus definition updates. Then when the year runs out, Symantec is not going to give you a single new virus definition even if there's a new worm around that dwarfs Sobig, Klez and all the other viruses put together ... I can see brand C following a similar strategy with their bogon updates. [and that's not a new thing I guess - every single virus that comes down the pike is written up in the press as the worst and most virulent virus yet] -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Thu, Jan 20, 2005 at 08:16:14PM +0530, Suresh Ramasubramanian wrote:
On Thu, 20 Jan 2005 09:42:54 -0500, Jared Mauch <jared@puck.nether.net> wrote:
No, cisco providing a time sensitive feature like this implies free upgrades to repair this critical defect. Just like they give out free software to people without contracts when they have a major security vulnerability.
Seems like this falls in the same category to me.
Analogies suck, but look at (for example) Norton AntiVirus. You pay for a year of virus definition updates. Then when the year runs out,
Yes, but this is protection of an end-host/end-node, not a portion of the global internet infrastructure. Bad features like this and bad behaviour are serious issues when they cause these ripple effects. It's flat-out defective software to me. This hurts Ciscos reputation that they are causing pockets of the internet to not work. Next subnets to get allocated will increase the size of those pockets and so on. Then the internet will become less reliable as an end-to-end transport medium, hurting *everyone*. At minimum, cisco should be offering free software updates to people who have the older releases through something simple like a updated maint release of software (same ver they have running but with *CORRECT* filters), but doing the minimum isn't always the best thing as most of us know. Providing a reliable mechanisim for this to happen is important, and possibly something that Cisco could productize and sell a for-fee monthly subscription for (a bgp feed or somesuch like what Team CYMRU provides is an example) but there are those (Hi Rob & Co.) doing it for free already, so the key is getting the blackholes minimized that exist today. If there is software that I can download from CCO that hasn't been deferred that has these old filters in it, Cisco is being a poor net.citizen IMHO. I'm not saying this to trash cisco, many people there know that, but the important thing is insuring that the global internet isn't further harmed, and as more allocations are done the harm becomes greater and it hurts every single person in this industry, providers and vendors alike. - 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 Jared Mauch wrote: | I'm not saying this to trash cisco, many people there know that, | but the important thing is insuring that the global internet isn't | further harmed, and as more allocations are done the harm becomes | greater and it hurts every single person in this industry, providers | and vendors alike. k, bit my tongue as much as I could... But I gotta vent ;-P So, Cisco provides this 'AutoSecure' function and everyone jumps all over the static bogon list. Why? Hello? The basic idea here is that it gets you decent out of the box setup defaults which you tailor after running it, right? (NOTE: I haven't actually hit the AUTOSECURE button yet, just read a little about it) Whats so bad about decent secure defaults? I just see it as a shortcut to getting a router online, not a solution to security. If you're implementing a new router and setting up Bogon filters you should already know that they'll need to be updated regularly and should replace the access list with a refreshed one using the autosecure configuration as a TEMPLATE that you work off of. If you don't know this, then you shouldn't be in charge of said router. Am I missing something here??? - -- ~ /"\ ~ \ / ASCII RIBBON CAMPAIGN ~ X AGAINST HTML MAIL ~ / \ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB7/Z925hr1at2zS8RAsyyAJ9DBfqDfgsdmCpCJP0oxhJ57pkLSgCfQsTb ujQRVk4dJa82CZfnq7AhgWc= =4VkL -----END PGP SIGNATURE-----
--- "Chris A. Epler" <cepler@HostMySite.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jared Mauch wrote:
| I'm not saying this to trash cisco, many people there know that, | but the important thing is insuring that the global internet isn't | further harmed, and as more allocations are done the harm becomes | greater and it hurts every single person in this industry, providers | and vendors alike.
k, bit my tongue as much as I could... But I gotta vent ;-P
So, Cisco provides this 'AutoSecure' function and everyone jumps all over the static bogon list. Why? Hello? The basic idea here is that it gets you decent out of the box setup defaults which you tailor after running it, right? (NOTE: I haven't actually hit the AUTOSECURE button yet, just read a little about it)
Well, the problem is that the autosecure feature introduces a static element (address filtering) into a dynamic world (routing), in a way which is generally considered "set and forget." The target audience for autosecure is people who don't have their own security people on staff, thus ensuring that the filters will get out of date, and cause mysterious reachability issues (mysterious, that is, because no one will think of looking for the problem in the router...)
Whats so bad about decent secure defaults? I just see it as a shortcut to getting a router online, not a solution to security.
Getting a router online is giving it an IP address. Translate from geek to English: when someone who is not-so-technical hears "autosecure" the end result is something like "automatic transmission" - i.e. something which doesn't need to be played with except once every few years.
If you're implementing a new router and setting up Bogon filters
The argument is that autosecure SHOULDN'T set up bogon filters.
you should already know that they'll need to be updated regularly and should replace the access list with a refreshed one using the autosecure configuration as a TEMPLATE that you work off of. If you don't know this, then you shouldn't be in charge of said router. Am I missing something here???
The primary audience for the autosecure feature is people who really don't quite get routers. No, they don't have any business with enable, but do they have it? yes. ===== David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
On (20/01/05 13:20), Chris A. Epler wrote:
Whats so bad about decent secure defaults?
secure defaults are good...but there are other aspects of cisco ios which would be better suited to be disabled out of the box: redirects, proxy arp, tcp/udp small-servers, the lack of decent ssh (this is getting better), lack of receive acls on all but the big boxen, etc...these are a few things which would be better to have out of the box.
If you're implementing a new router and setting up Bogon filters you should already know that they'll need to be updated regularly
read the beginning of this thread - people implement bogon filters without keeping them up to date already. this is just another mechanism to do the same thing (but on a larger scale).
If you don't know this, then you shouldn't be in charge of said router. Am I missing something here???
in an ideal world, yes, this would be true; however we all know the reality of this. there are already secure config templates available which people follow without actually knowing the implications of. one more 'feature' in ios will go unnoticed by most, and thus will be left out of date...that was, i believe, jared's point. /joshua -- **** THIS .sig CENSORSED ****
On Thu, 20 Jan 2005 13:20:45 EST, "Chris A. Epler" said:
Whats so bad about decent secure defaults? I just see it as a shortcut to getting a router online, not a solution to security. If you're implementing a new router and setting up Bogon filters you should already know that they'll need to be updated regularly and should replace the access list with a refreshed one using the autosecure configuration as a TEMPLATE that you work off of. If you don't know this, then you shouldn't be in charge of said router. Am I missing something here???
Only thing you're missing is that "shouldn't be in charge of said router" describes a nice-to-dream-about but nonexistent state of affairs. I'll go out on a limb and say that 3/4 of the Cisco routers in production use are managed by unqualified network monkeys employed by the leaf sites. The fact that they get one interface connected to their local LAN, and the other interface connected to the fractional T-1 back to the ISP, and that packets make it from the LAN to www.google.com and back is amazing enough. Expecting them to do things like proper inbound bogon filtering and outbound 1918 egress filtering is pushing it... In other words, the only people who are likely to *use* the autosecure feature are people who (a) will Get It Wrong (either at initial config, or failure to update it regularly), (b) aren't reading this list anyhow (or any other place where they're likely to see the "Update your bogons" mantra), and (c) indeed shouldn't have "enable".
On Thu, Jan 20, 2005 at 01:44:04PM -0500, Valdis.Kletnieks@vt.edu wrote:
I'll go out on a limb and say that 3/4 of the Cisco routers in production use are managed by unqualified network monkeys employed by the leaf sites. The fact [...]
I beg to differ - 3/4 of the Cisco routers in (enterprise) production are *unmaintained*. These will have a variety of vulnerable, buggy or just plain crap IOS versions and no-one would've even considered upgrading for years. If filters depend on IOS upgrades then those filters are there to stay. ISPs will of course feed their routers more often, but to be honest anyone else looks at their network kit only when there's something far wrong with it. -- Will
Hi, NANOGers. Will makes an excellent point here: ] I beg to differ - 3/4 of the Cisco routers in (enterprise) production are ] *unmaintained*. These will have a variety of vulnerable, buggy or just plain ] crap IOS versions and no-one would've even considered upgrading for years. While I don't have any numbers, I can say that we see a LOT of routers overtly compromised and modified as a result. The modifications are generally scripted, and include changing the passwords (to anything but "cisco"), disabling logging, and adding filters. You'd think such things would be rather obvious, and they are, yet no one notices. Most of these compromised routers are at the end of FR or frac-T connections. I suspect a great many of them were configured once, then left to rot with the same code and configuration for years and years. Thanks, Rob. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.
On Fri, 21 Jan 2005 00:55:45 GMT, Will Hargrave said:
I beg to differ - 3/4 of the Cisco routers in (enterprise) production are *unmaintained*. These will have a variety of vulnerable, buggy or just plain crap IOS versions and no-one would've even considered upgrading for years.
Oh.. I was including all the sites where a secretary saw somebody power cycle the box and it fixed the problem, so that's what they do when they have a problem. It's the rare site that can't even scare up somebody who "knows" how to power cycle the box while dancing widdershins 3 times around the box while waving a dead chicken....
"Chris A. Epler" <cepler@HostMySite.com> wrote:
Whats so bad about decent secure defaults? I just see it as a shortcut
Nothing at all as long as they remain decent. New /8s getting allocated every few months make it positively indecent. srs
On Thu, 20 Jan 2005 20:16:14 +0530, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Analogies suck, but look at (for example) Norton AntiVirus. You pay for a year of virus definition updates. Then when the year runs out, Symantec is not going to give you a single new virus definition even if there's a new worm around that dwarfs Sobig, Klez and all the other viruses put together ... I can see brand C following a similar strategy with their bogon updates.
The problem with this analogy is that the failure modes are opposite. Once something is a virus, it stays a virus, so keeping it in your virus file forever is fine; all you miss are the new viruses. But once something is a bogon, it doesn't stay a bogon; it eventually will get used, unless the Great IPv6 Revolution catches up with us first. A slightly more conservative approaches is to not list the next couple of address blocks as bogons, but that just means that problems will occur six months later when everybody's forgotten to update them. ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 in-line: Jared Mauch wrote: | On Thu, Jan 20, 2005 at 06:26:15PM +0530, Suresh Ramasubramanian wrote: | |>David Barak <thegameiam@yahoo.com> wrote: |> |>>While it says that bogon filters change, and provides |>>a URL to check it, what percentage of folks who would |>>use a feature like "autosecure" would ever update |>>their filters? |>> |> |>What do they do to update that bogon list anyway - push a new IOS image? | | | Actually, my assumption is anyone with autosecure gets | free software upgrades for life, as this is a flexible list that | will change over time. Each time a change is made they | need to release new software, and notify their installed | customer base. - ------------------- i understand bogon filters and reasoning behind it and i'm all for it. but why does one think (maybe i missing something) this approach (autosecure) is scalable and acceptable to update your ios or even constantly updating your acls every time one has to update their bogon filters? yet another think to look out for? i like to see the network availability for aol, google, nasdaq, every time they update their bogons. why can't this somehow be dynamically updated and /or linked to a master file as opposed to upgrading the ios? like to hear more thoughts on it. regards, /vicky | | - jared | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7+ugpbZvCIJx1bcRApL0AJ0T2xb1ZHkxDSg0Ne3UwXqQ8z7xogCaA4rc /An79+f9qmCKqfqkDsMH1wU= =Sv6E -----END PGP SIGNATURE-----
--- Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
David Barak <thegameiam@yahoo.com> wrote:
While it says that bogon filters change, and
provides
a URL to check it, what percentage of folks who would use a feature like "autosecure" would ever update their filters?
What do they do to update that bogon list anyway - push a new IOS image?
That's a mighty fine question: the link I referenced is the most recent I was able to find, and its list of bogons is thoroughly out-of-date. In the interest of long-term reachability, I would call on Cisco to remove the IANA-UNASSIGNED blocks from the autosecure filters. This will only get worse: consider how bad the GWF problem is now with the antivirus-response-spam... ===== David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
David Barak wrote:
--- Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
David Barak <thegameiam@yahoo.com> wrote:
While it says that bogon filters change, and
provides
a URL to check it, what percentage of folks who
would
use a feature like "autosecure" would ever update their filters?
What do they do to update that bogon list anyway - push a new IOS image?
That's a mighty fine question: the link I referenced is the most recent I was able to find, and its list of bogons is thoroughly out-of-date. In the interest of long-term reachability, I would call on Cisco to remove the IANA-UNASSIGNED blocks from the autosecure filters.
I think the last time this was hashed out here, there was a consensus that Cisco should not be promoting a feature that uses a static list for blackholing. The problem is with now-good-bogons bad enough as it is, even with a presumably competent admin responsible for the setup. Perhaps Cisco could couple this with a scheduled scp to a server of choice, preferably Cisco's, for an update checking feature. At that point I would think perhaps it has a bit more + than - to it. At any rate it should NOT be tied to IOS images, the vast majority of those never get upgraded. Make ACLS be able to parse their rules from a file stored wherever. Just like that new DHCP static bindings from text file feature. Joe
I will check on this and get back with you. Rodney On Thu, Jan 20, 2005 at 11:18:10AM -0500, Joe Maimon wrote:
David Barak wrote:
--- Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
David Barak <thegameiam@yahoo.com> wrote:
While it says that bogon filters change, and
provides
a URL to check it, what percentage of folks who
would
use a feature like "autosecure" would ever update their filters?
What do they do to update that bogon list anyway - push a new IOS image?
That's a mighty fine question: the link I referenced is the most recent I was able to find, and its list of bogons is thoroughly out-of-date. In the interest of long-term reachability, I would call on Cisco to remove the IANA-UNASSIGNED blocks from the autosecure filters.
I think the last time this was hashed out here, there was a consensus that Cisco should not be promoting a feature that uses a static list for blackholing. The problem is with now-good-bogons bad enough as it is, even with a presumably competent admin responsible for the setup.
Perhaps Cisco could couple this with a scheduled scp to a server of choice, preferably Cisco's, for an update checking feature. At that point I would think perhaps it has a bit more + than - to it.
At any rate it should NOT be tied to IOS images, the vast majority of those never get upgraded. Make ACLS be able to parse their rules from a file stored wherever. Just like that new DHCP static bindings from text file feature.
Joe
Hi Folks - Due to the feedback we've received on the Autosecure bogon list issue, we've decided to do the following: 1) Provide a fix that removes bogon ACL creation and deployment from the Autosecure feature. This change will be available in mainline and maintenance software releases. For the software release details, please refer to 2. 2) A Cisco Field Notice will be published to inform customers of the change and will contain instructions on how to remove the bogon ACLs created by executing the autosecure command. We'll update the list with the Field Notice URL as soon as it's available. Tentative date for FN posting is 18th February 2005. Regards. /kunjal
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Barak Sent: Wednesday, January 19, 2005 11:11 AM To: rsears@adnc.com; Kurt Kruegel Cc: nanog@merit.edu Subject: Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
--- "Richard J. Sears" <rsears@americanIS.net> wrote:
Yes - the space in question was allocated last January - it
not everyone has updated their bogon access lists to remove
looks like this space
from the bogon list.
I think that Cisco's Autosecure feature is part of the problem here:
http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/product s_feature_guide09186a008017d101.html
While it says that bogon filters change, and provides a URL to check it, what percentage of folks who would use a feature like "autosecure" would ever update their filters?
sigh.
===== David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
On Wed, 16 Feb 2005, Kunjal Trivedi wrote:
Due to the feedback we've received on the Autosecure bogon list issue, we've decided to do the following:
1) Provide a fix that removes bogon ACL creation and deployment from the Autosecure feature. This change will be available in mainline and maintenance software releases. For the software release details, please refer to 2.
2) A Cisco Field Notice will be published to inform customers of the change and will contain instructions on how to remove the bogon ACLs created by executing the autosecure command.
We'll update the list with the Field Notice URL as soon as it's available. Tentative date for FN posting is 18th February 2005.
The pendulum swings too far in the other direction. Martian addresses are relatively static, and might be good candidates for one-click security. If you see a 127.0.0.0/8 packet floating around, its probably up to no good. The objection is naive people assuming all the addresses on the list are the same, in particular what Team Cymru calls "Bogons." Bogon filters should only be configured by people who understand what they are doing. Bogon lists, as opposed to Martian lists, are probably not a good thing for cookbook security or one-click auto-configure.
At 05:27 PM 16-02-05 -0500, Sean Donelan wrote:
On Wed, 16 Feb 2005, Kunjal Trivedi wrote:
Due to the feedback we've received on the Autosecure bogon list issue, we've decided to do the following:
1) Provide a fix that removes bogon ACL creation and deployment from the Autosecure feature. This change will be available in mainline and maintenance software releases. For the software release details, please refer to 2.
2) A Cisco Field Notice will be published to inform customers of the change and will contain instructions on how to remove the bogon ACLs created by executing the autosecure command.
We'll update the list with the Field Notice URL as soon as it's available. Tentative date for FN posting is 18th February 2005.
The pendulum swings too far in the other direction.
Sure would have been nice if Cisco had asked/polled a number of key customers to get an idea of what we wanted, rather than to know what they thought we wanted.
Martian addresses are relatively static, and might be good candidates for one-click security. If you see a 127.0.0.0/8 packet floating around, its probably up to no good.
As are RFC1918 addresses. Oh well. -Hank
On Thu, 17 Feb 2005, Hank Nussbacher wrote:
Martian addresses are relatively static, and might be good candidates for one-click security. If you see a 127.0.0.0/8 packet floating around, its probably up to no good.
As are RFC1918 addresses.
Cisco routers are frequently used in enterprise networks, which may use RFC1918 internally. Again, not a good thing to auto-magically do for naive network managers. RFC1918 addresses may or may not be legitimate depending on your network, just like "no ip classless" and the NSA security guide. I would not classify RFC1918 as "Martian" addresses. Of course, if all network equipment did source address validation by default, you wouldn't need bogon filters.
participants (19)
-
Bill Stewart -
Charles R. Anderson -
Chris A. Epler -
David Barak -
Hank Nussbacher -
Jared Mauch -
Joe Maimon -
joshua sahala -
Kunjal Trivedi -
ops.lists＠gmail.com -
Richard J. Sears -
Rob Evans -
Rob Thomas -
Rodney Dunn -
Sean Donelan -
Suresh Ramasubramanian
-
Valdis.Kletnieks＠vt.edu -
Vicky Rode -
Will Hargrave