Rép. : 85.68.0.0/19 Please Check Filters - BOGON Filtering IP Space
oh my bad: 85.68/15 sorry for the mistake. RAMAHEFASON David FTC [EMAIL PROTECTED] 01/20 10:44 Hi, we're AS34033 and have been assigned the 85.68/19 address space from the RIPE on October 2004. But we still have some network reachability issues, due often to the use old BOGON filters, can you check that this supernet is not part of your bogon filters anymore. Thanks a lot David Ramahefason
Re: Graphing Peering
On Jan 19, 1:41pm, andrew matthews [EMAIL PROTECTED] wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. If you don't mind a reasonably inexpensive commercial solution, BENTO does exactly what you need. It was in fact initially developed to address the very problem you face, with multiple peers on a plain, shared interface, but has other applications too. Please see http://www.networksignature.com Any questions, better send them directly to me. but please check the FAQ first.-) Best, -- Per
Re: Confirmation of receipt of the transfer request at Verisign for panix.com
On Wed, 19 Jan 2005, Richard Parker wrote: on 1/19/05 9:56 PM, Bruce Tonkin at [EMAIL PROTECTED] wrote: Here is the copy of the email Melbourne IT received. Thanks for providing a copy of the e-mail Bruce. You've been extraordinarily forthcoming on NANOG. I wish that Dotster, as the losing registrar, was as willing to discuss the hijack of panix.com as you as a representative of the gaining registrar, Melbourne IT, have been. According to http://www.eweek.com/article2/0,1759,1751981,00.asp there were actually several other domains hijacked over the weekend (aem.com, f3.com) in addition to panix.com. While those other domains were transfered to different registrar (not MIT), apparently all of them were previously with Dotster. Hmm... -- William Leibzon Elan Networks [EMAIL PROTECTED]
broke Inktomi floods?
Inktomi (now Yahoo!) sends it's spiders all over the Internet. Lately some of our systems are reporting that they open many HTTP connections to our web sites, without ever sending any data and immediately disconnecting. This is getting to a level where it disturbs us. Is something broke over there? I can't seem to be able to reach them and this is becoming a real annoyance. Anyone else observing this? -- Gadi Evron, Information Security Manager, Project Tehila - Israeli Government Internet Security. Ministry of Finance, Israel. [EMAIL PROTECTED] [EMAIL PROTECTED] Office: +972-2-5317890 Fax: +972-2-5317801 http://www.tehila.gov.il
Re: broke Inktomi floods?
On Thu, 20 Jan 2005 14:30:04 +0200, Gadi Evron [EMAIL PROTECTED] wrote:
Inktomi (now Yahoo!) sends it's spiders all over the Internet. Lately
some of our systems are reporting that they open many HTTP connections
to our web sites, without ever sending any data and immediately
disconnecting. This is getting to a level where it disturbs us.
I have heard previous stories of inktomi ignoring robots.txt (not seen
this for myself though). And there are threads like this -
Quoting from http://www.webmasterworld.com/forum11/1968-1-15.htm
I've got Scooter allowed in, but I've also got it lumped int with a
number of agents that are not allowed to get non-HTML files. This is
especially important at my site as it includes a number of very large
binary datasets in numerous locations and the robots have proven too
stupid to understand that downloading them is a waste of bandwidth.
RewriteCond %{HTTP_USER_AGENT} .*Ask.Jeeves.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*FAST.WebCrawl.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*ia_archiver.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*InfoSeek.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*inktomi.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*Scooter.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*Slurp.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*Teoma.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*VoilaBot.* [OR]
RewriteCond %{HTTP_USER_AGENT} .*Google.*
RewriteRule!.*(html¦htm¦txt¦/)$ /www/msgs/badagent.html [F]
Re: Regarding registrar LOCK for panix.com
At 12:22 AM 20-01-05 +, Eric Brunner-Williams in Portland Maine wrote: I picked 1990 because Panix is 15 year old. And not to forget that Panix was the 1st victim ever of a SYN attack in Sept 1996: http://www.panix.com/press/synattack.html http://www.panix.com/press/synattack2.html Seems like someone out there just luvs Panix! :-) -Hank
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
David Barak [EMAIL PROTECTED] 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
Re: Regarding registrar LOCK for panix.com
And not to forget that Panix was the 1st victim ever of a SYN attack in Sept 1996: http://www.panix.com/press/synattack.html http://www.panix.com/press/synattack2.html And due to coordinated action between members of the NANOG mailing list and the FIREWALLS mailing list, within 24 hours, there were patches made available for Linux and various BSD kernels that mitigated these attacks. This type of an event shows the real power of the NANOG mailing list to communicate in a crisis. If only we could extend this communication to other media (INOC-DBA) and to include representatives of more network operators. I hope that the NANOG reform discussion spends a good bit of its time on articulating a vision for the future of a membership-based NANOG organization, and not worry so much about past problems. --Michael Dillon
Re: Confirmation of receipt of the transfer request at Verisign
Speaking on Deep Background, the Press Secretary whispered: on 1/19/05 9:56 PM, Bruce Tonkin at [EMAIL PROTECTED] wrote: Here is the copy of the email Melbourne IT received. Thanks for providing a copy of the e-mail Bruce. You've been extraordinarily forthcoming on NANOG. I wish that Dotster, as the losing registrar, was as willing to discuss the hijack of panix.com as you as a representative of the gaining registrar, Melbourne IT, have been. I wonder if they have anything to share? From what I recall, they state they didn't receive any notification... -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: panix hijack press
Speaking on Deep Background, the Press Secretary whispered:
(1) Stop blaming the victim!
To me, as big an issue as the original FUBAR is the
alleged/reported failure of both MelIT and VGRS to respond and
attempt to lessen the damage they had helped cause.
I'm no lawyer, but believe under US laws such failure to mitigate
is a factor in civil judgements -- if you choose to {say} just
stand there and look stoopid rather than call 911 after you knock
over the propane torch and start the house on fire
Add to the mix the detail that Verisign is paying a LARGE
settlement out on a past infamous theftand you'd think they'd
Buy Some Clue...
--
A host is a host from coast to [EMAIL PROTECTED]
no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, Jan 20, 2005 at 06:26:15PM +0530, Suresh Ramasubramanian wrote: David Barak [EMAIL PROTECTED] 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 [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005 09:29:34 -0500, Jared Mauch [EMAIL PROTECTED] 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 ([EMAIL PROTECTED])
Re: Regarding registrar LOCK for panix.com
On Thu, 20 Jan 2005 13:18:03 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I hope that the NANOG reform discussion spends a good bit of its time on articulating a vision for the future of a membership-based NANOG organization, and not worry so much about past problems. That is something I am working on, as it strikes me as a really good way to bring more asian operators into the mainstream. A clueful contact at an ISP prevents people dropping in blackhole routes and access.db entries for huge netblocks when they see the first sign of abuse from out of there ... which would be a very good thing. INOC-DBA does get talked about on several other operator lists like apricot and sanog .. but there's not nearly enough adoption yet. I'm still hopeful about seeing it grow in popularity and get some critical mass. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, Jan 20, 2005 at 08:03:42PM +0530, Suresh Ramasubramanian wrote: On Thu, 20 Jan 2005 09:29:34 -0500, Jared Mauch [EMAIL PROTECTED] 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 [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005 09:42:54 -0500, Jared Mauch [EMAIL PROTECTED] 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 ([EMAIL PROTECTED])
Re: Graphing Peering
On Wed, 2005-01-19 at 22:41, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. off in what sense? We use mac-accounting, snmp nad mrtg to graph per peer utilization. The following script is helpful http://www.thiscow.com/dl/bgp-peers-1.5.pl I reworked it to spit out the AS number instead of the ip address. The issue you then have is that multiple sessions with one As number all show as the same target. Which MRTG does not like. You can fix that as well of course in the script. And it does not autoscan, which means that if people change their mac-address, you lose the data, until you rerun the script. Another problem you might run into is counter wrapping. When polling every 5 minutes, some counters may wrap. (there is no 64 bit counter for the mac-address accounting). So you have to run it in short timeframes, causing more cpu utilization. But all in all, mac-accounting and Netflow source-as give you a very good overview of your network flows. Frank
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, Jan 20, 2005 at 08:16:14PM +0530, Suresh Ramasubramanian wrote: On Thu, 20 Jan 2005 09:42:54 -0500, Jared Mauch [EMAIL PROTECTED] 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 [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
...and it's not like ARIN, etc., does not announce to the Internet community when it allocates from address space which may have previously been listed in various operational places as bogon or unalloacted -- they do. I recall seeing similar announcements on the list from time to time, suggesting due diligence on ARIN's behalf to notifying people to modify their filtering. *plonk* Scanning the archives, an example: http://www.merit.edu/mail.archives/nanog/2004-01/msg00374.html - ferg -- Jared Mauch [EMAIL PROTECTED] wrote: 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*. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
--- Suresh Ramasubramanian [EMAIL PROTECTED] wrote: David Barak [EMAIL PROTECTED] 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
Re: Graphing Peering - Solution
Take a look at http://jffnms.sourceforge.net According to the Author whom I know very well it will do exactly what you need it to do: ---SNIP--- Yes, JFFNMS has a specific system to do this. Using MAC Accounting, we track each MAC address, using ARP its IP, and using BGP Table its ASN (by the IP). So you will get MAC Accounting graphs labeled with the ASN you are peering. SNIP- On Wed, 19 Jan 2005 23:01:11 -0600 Kevin [EMAIL PROTECTED] wrote: On Wed, 19 Jan 2005 14:37:54 -0800, andrew matthews [EMAIL PROTECTED] wrote: no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. If you are looking to graph statistics about the BGP peering sessions, (rather than graphing transit router bytes in/out as suggested elsewhere), you might take a look at the sample-config for the Cricket graphing tool, specifically ~cricket/cricket-1.0.4/sample-config/routing Unfortunately this graphs counts of BGP peering messages, not bytes. Cricket can track BGP route announcements, including graphing counts (rates) of peer updates in/out along along with total BGP messages, for each peering session. You could use Cricket itself to view the data, extract the collected data from 'rrdtool', or just look at the sources to get an idea of the requisite Cisco OIDs to use in another tool entirely. More information on Cricket is available from http://cricket.sourceforge.net/ Kevin ** Richard J. Sears Vice President American Internet Services [EMAIL PROTECTED] 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.
Router-switch-router peering module
I'm hunting for some presentations or papers on what I've seen called a peering module, using a router, a L2 switch, and a router in series, rather than a single router. Unfortunately, I can't remember where I saw the detailed description, and I haven't been able to find it in the NANOG archives. IIRC, the rationale was to spread filtering and rate limiting over a set of processors, also to keep the configuations more manageable. Does anyone have any pointers to detail? I've seen the topology, but not a detailed discussion, in a couple of Cisco presentations.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Is there an RFC or other standards document that clearly states that static bogon filter lists are a bad idea? While this seems like common sense, there was just an RFC published on why IP addresses for specific purposes (like NTP) shouldn't be encoded into hardware. Using a dynamic feed needs to be codified so that it finds its way into training classes, documentation, etc. Otherwise, this problem will recur indefinitely. - Dan On 1/20/05 10:18 AM, Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote: ...and it's not like ARIN, etc., does not announce to the Internet community when it allocates from address space which may have previously been listed in various operational places as bogon or unalloacted -- they do. I recall seeing similar announcements on the list from time to time, suggesting due diligence on ARIN's behalf to notifying people to modify their filtering. *plonk* Scanning the archives, an example: http://www.merit.edu/mail.archives/nanog/2004-01/msg00374.html - ferg -- Jared Mauch [EMAIL PROTECTED] wrote: 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*. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
David Barak wrote: --- Suresh Ramasubramanian [EMAIL PROTECTED] wrote: David Barak [EMAIL PROTECTED] 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
Re: Graphing Peering
Andrew, The 32 bit counters are a significant problem when using gigabit ethernet public peering interfaces. Needless to say, MAC accounting was not designed for gigabit speeds. Frequent polling is, sadly the only solution. If you write your own scripts, make sure to account for counter wrapping. - Dan on 1/20/05 9:45 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 2005-01-19 at 22:41, andrew matthews wrote: Anyone have any suggestions on graphing peering on a cisco router? I'm using mrtg and i did mac address accounting but the numbers are off. off in what sense? We use mac-accounting, snmp nad mrtg to graph per peer utilization. The following script is helpful http://www.thiscow.com/dl/bgp-peers-1.5.pl I reworked it to spit out the AS number instead of the ip address. The issue you then have is that multiple sessions with one As number all show as the same target. Which MRTG does not like. You can fix that as well of course in the script. And it does not autoscan, which means that if people change their mac-address, you lose the data, until you rerun the script. Another problem you might run into is counter wrapping. When polling every 5 minutes, some counters may wrap. (there is no 64 bit counter for the mac-address accounting). So you have to run it in short timeframes, causing more cpu utilization. But all in all, mac-accounting and Netflow source-as give you a very good overview of your network flows. Frank
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
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 [EMAIL PROTECTED] wrote: David Barak [EMAIL PROTECTED] 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
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
11:02am Daniel Golding said:
Is there an RFC or other standards document that clearly states that static
bogon filter lists are a bad idea? While this seems like common sense, there
Since this keeps coming up. I'll toss my quick and dirty reminder cronjob
into the discussion. I cannot imagine any other way of managing the static
bogons published on the Team Cymru web site. (For those of us who don't
need to run their many other dynamic options.) Copying a static config
wholesale is a classic case of myopic thinking.
$ cat /etc/cron.monthly/ckbogons.sh
#!/bin/bash
bnagg=http://www.cymru.com/Documents/bogon-bn-agg.txt
# make a new bogon list from the web
newbog=`mktemp` || exit 1
wget -qO- $bnagg |awk '{print any net $1 \treject}' $newbog
# get current list from our static-route config
oldbog=`sed -ne '/^any.*reject$/,/^$/p' /etc/sysconfig/static-routes`
# commpare
#echo $oldbog |cdiff - $newbog
echo $oldbog |diff -uw - $newbog
rm -f $newbog
Obviously it's for a linux edge using Red Hat style initscripts. But the
basic gist is sound; alert the admin whenever we are out of sync. And an
expect script could easily be whipped up for monitoring IOS/whatever other
static bogons one has installed.
Admins who choose the *static* bogon list should use this technique of
self-control.
../C
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
-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 [EMAIL PROTECTED] 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-
Re: panix hijack press
Apparently, some folks just don't get it Richard Parker wrote: ... However, all domain holders can directly monitor the status of their domain using the .com registry's whois server - including whether or not their domain has a status of registrar-lock. They do not have to rely on their registrar to tell them if their domain is locked or not. Now let's get this straight. You think that ISPs in general need to assign staff to monitor the lock status of the hundreds or thousands of registered domains of our subscribers. Or that the subscribers, who typically aren't even on the whois contacts list, should be monitoring the lock status, of which they probably don't know (nor care) exists? What are you smoking? The whole locking mechanism was a poor design from the beginning. It's opt-out. And we all are so fond of opt-out schemes, eh? I don't think registrar-lock is a red-herring. In the wake of the panix.com hijack holders of domain names are naturally going to want to know what they can do to prevent something similar happening to them. The ability to request registrar-lock is one the few defenses domain holders have. Huh? What you are saying is maybe panix.com isn't at fault because they had requested (or expected) registrar-lock, but they are at fault because their registrar didn't properly lock it? Or at fault because they didn't monitor the lock? Stop blaming the victim! The registrar-lock isn't a defense for the domain holder. Not one iota. It was designed as a defense for the registrar. And the registrar in this case is a victim as much as the domain holder. Stop blaming the victim! I haven't seen anyone on NANOG claim that Panix is not a victim. Clearly a serious error occurred in the process Melbourne IT uses to authenticate transfers. However, your analogies seem unnecessarily inflammatory. Sometimes folks such as yourself need to be educated in clear, unambigous terms that relate to life. And yet the lesson still hasn't taken hold: Another analogy might be to describe Panix as a bank. An analogy that is pretty far off, since the bank in this case would be the REGISTRAR, not Panix. And the registrar in this case is a victim as much as the domain holder. Stop blaming the victim! A personal responder wrote: On Wed, Jan 19, 2005 at 09:35:21PM -0500, William Allen Simpson wrote: (6) Stop blaming the victim! Well, in this case, it appears that the victim is saying that it had taken precautions... and I concur with whomever it was who said that if the lock date on all their other domains is post-incident, that's pretty strong circumstantial evidence that they hadn't requested a lock (which is what we *mean* when we say customer locked that domain, so kindly leggo that red herring). You concur, without checking, and have no idea whomever it was that speculated, nor how many domains are administered by panix or dotster? You mean the REGISTRAR didn't lock the domain. But the registrar in this case is a victim as much as the domain holder. Stop blaming the victim! So all we're *really* annoyed about here is that Bruce stepped up to the plate, but Alexis (*reportedly*) won't. IMHO. Huh? I've seen no such reports. On what do you base your speculation? The only report that I've seen clearly says (Thu, 20 Jan 2005 16:56:41 +1100 quoting Sat, 8 Jan 2005 20:40:34 -0500): (1) you have obtained the requisite authorization from the domain name registrant listed in the database of the Current Registrar, NO. Obviously not. and (2) you have retained a copy of reliable evidence of the authorization. NO. Nothing described here. Indeed, as for Mel-IT stepping up to the plate, we've seen only contrary evidence here. Sure Bruce seems to be a nice guy. So what? His staff wasn't responding to phone calls. His boss wasn't responding, either. His lawyer was actively hostile. Looks to me like Alexis is the one that got screwed. Certainly spent a lot of time at the plate, many many hours! So, let's go back to basics: - If you leave your house unlocked, the thief still goes to jail. - If you leave your car unlocked and the engine running, the thief still goes to jail. - If your bank leaves its doors unlocked and the safe open and all the employees go to lunch, the thief still goes to jail. Stop blaming the victim! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
--- Chris A. Epler [EMAIL PROTECTED] 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
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Whats so bad about decent secure defaults? I don't consider a configuration that disenfranchises part of the internet as decent [...] defaults. :) Cheers, Rob
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
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
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
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. pgpPCbuENUotj.pgp Description: PGP signature
Enough. (was Re: panix hijack press)
Ok. I think at this point we all know there are problems with the domain transfer process. I suspect we can further agree that, as with many serious problems, there were probably multiple contributing factors here. I'd like to suggest that getting into a public screaming match or trying to establish fault probably won't do anything useful, or at the very least would be more productive if done in a court rather than on the NANOG list. What might be more useful would be for those of you with a lot of time to spend on this issue to come up with proposals for fixing or better documentng the system, so that it will be more obvious how to avoid problems like this in the future. -Steve On Thu, 20 Jan 2005, William Allen Simpson wrote: Apparently, some folks just don't get it Richard Parker wrote: ... However, all domain holders can directly monitor the status of their domain using the .com registry's whois server - including whether or not their domain has a status of registrar-lock. They do not have to rely on their registrar to tell them if their domain is locked or not. Now let's get this straight. You think that ISPs in general need to assign staff to monitor the lock status of the hundreds or thousands of registered domains of our subscribers. Or that the subscribers, who typically aren't even on the whois contacts list, should be monitoring the lock status, of which they probably don't know (nor care) exists? What are you smoking? The whole locking mechanism was a poor design from the beginning. It's opt-out. And we all are so fond of opt-out schemes, eh? I don't think registrar-lock is a red-herring. In the wake of the panix.com hijack holders of domain names are naturally going to want to know what they can do to prevent something similar happening to them. The ability to request registrar-lock is one the few defenses domain holders have. Huh? What you are saying is maybe panix.com isn't at fault because they had requested (or expected) registrar-lock, but they are at fault because their registrar didn't properly lock it? Or at fault because they didn't monitor the lock? Stop blaming the victim! The registrar-lock isn't a defense for the domain holder. Not one iota. It was designed as a defense for the registrar. And the registrar in this case is a victim as much as the domain holder. Stop blaming the victim! I haven't seen anyone on NANOG claim that Panix is not a victim. Clearly a serious error occurred in the process Melbourne IT uses to authenticate transfers. However, your analogies seem unnecessarily inflammatory. Sometimes folks such as yourself need to be educated in clear, unambigous terms that relate to life. And yet the lesson still hasn't taken hold: Another analogy might be to describe Panix as a bank. An analogy that is pretty far off, since the bank in this case would be the REGISTRAR, not Panix. And the registrar in this case is a victim as much as the domain holder. Stop blaming the victim! A personal responder wrote: On Wed, Jan 19, 2005 at 09:35:21PM -0500, William Allen Simpson wrote: (6) Stop blaming the victim! Well, in this case, it appears that the victim is saying that it had taken precautions... and I concur with whomever it was who said that if the lock date on all their other domains is post-incident, that's pretty strong circumstantial evidence that they hadn't requested a lock (which is what we *mean* when we say customer locked that domain, so kindly leggo that red herring). You concur, without checking, and have no idea whomever it was that speculated, nor how many domains are administered by panix or dotster? You mean the REGISTRAR didn't lock the domain. But the registrar in this case is a victim as much as the domain holder. Stop blaming the victim! So all we're *really* annoyed about here is that Bruce stepped up to the plate, but Alexis (*reportedly*) won't. IMHO. Huh? I've seen no such reports. On what do you base your speculation? The only report that I've seen clearly says (Thu, 20 Jan 2005 16:56:41 +1100 quoting Sat, 8 Jan 2005 20:40:34 -0500): (1) you have obtained the requisite authorization from the domain name registrant listed in the database of the Current Registrar, NO. Obviously not. and (2) you have retained a copy of reliable evidence of the authorization. NO. Nothing described here. Indeed, as for Mel-IT stepping up to the plate, we've seen only contrary evidence here. Sure Bruce seems to be a nice guy. So what? His staff wasn't responding to phone calls. His boss wasn't responding, either. His lawyer was actively hostile. Looks to me like Alexis is the one that got screwed. Certainly spent a lot of time at the plate, many many hours! So, let's go back to basics: - If you leave your house unlocked, the thief still goes to jail. - If you leave your car unlocked
Re: broke Inktomi floods?
On Thu, 20 Jan 2005, Suresh Ramasubramanian wrote: On Thu, 20 Jan 2005 14:30:04 +0200, Gadi Evron [EMAIL PROTECTED] wrote: Inktomi (now Yahoo!) sends it's spiders all over the Internet. Lately some of our systems are reporting that they open many HTTP connections to our web sites, without ever sending any data and immediately disconnecting. This is getting to a level where it disturbs us. I have heard previous stories of inktomi ignoring robots.txt (not seen this for myself though). And there are threads like this - Quoting from http://www.webmasterworld.com/forum11/1968-1-15.htm back in 1999 inktomi hammered our nameserver (which never has, and never will run http. ever.) After _weeks_ of complaining to them and to their upstream exodus (hah!) I finally got them to stop. Only to have them start up again a month later. not suprising to see them up to their old antics again. time to nullroute i guess? -Dan
Re: broke Inktomi floods?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 not sure if spiders falls under spam or ddos bracket when they repeatedly start hammering one's network. you could possible report to spamcop (*grin*) to get a quicker response. spamcom hasn't been accurate in some instances :-) do you remember this incident, http://www.cs.wisc.edu/~plonka/netgear-sntp/ regards, /vicky Dan Hollis wrote: | On Thu, 20 Jan 2005, Suresh Ramasubramanian wrote: | |On Thu, 20 Jan 2005 14:30:04 +0200, Gadi Evron [EMAIL PROTECTED] wrote: | |Inktomi (now Yahoo!) sends it's spiders all over the Internet. Lately |some of our systems are reporting that they open many HTTP connections |to our web sites, without ever sending any data and immediately |disconnecting. This is getting to a level where it disturbs us. | |I have heard previous stories of inktomi ignoring robots.txt (not seen |this for myself though). And there are threads like this - |Quoting from http://www.webmasterworld.com/forum11/1968-1-15.htm | | | back in 1999 inktomi hammered our nameserver (which never has, and never | will run http. ever.) After _weeks_ of complaining to them and to their | upstream exodus (hah!) I finally got them to stop. Only to have them | start up again a month later. | | not suprising to see them up to their old antics again. | | time to nullroute i guess? | | -Dan | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8DFOpbZvCIJx1bcRAu2FAJ4+a2SHF7XxWgaHKFZzi7hf46tJFwCfcU12 fbIMwtwkPhI33onPawlBKYE= =P+y0 -END PGP SIGNATURE-
Ability to use and monitor LOCK status
However, that still looks to me like Users can only ask that domains be locked. Unless you are claiming that users can send the lock request directly to the registry, and monitor its status. Only a registrar can send commands directly the registry. Different registrars offer different services. Most are now offering the ability for customer to put a name on Lock, and remove a name from lock using the normal online maintenance tools. The status of LOCK is published in the Registry WHOIS service, although this display is not in real-time (ie believe it is updated once a day). Registrars have real-time access to the lock status of a name under their management. Regards, Bruce
RE: improving the registrar transfer process
Hello William, We know how to do 3-way handshakes. Rather a fundamental of the Internet. So quickly folks forget We knew in advance that the VRSN/NetSol/whatever protocol was terrible, and that the ICANN policy change was not going to be helpful. The ICANN policy change had no impact on this particular incident. As the incident has been documented so far, the transfer would have occurred under both the old and the new policy. With respect to the protocol. An IETF process was used to develop the EPP protocol as a replacement for RRP. With respect to notifications of transfers, the new protocol handles this by a message queue at the registry. (ie email is no longer the mechanism). It might be useful to consider reviewing the protocol to ensure that a transfer cannot proceed unless the losing registrar system confirms receipt of the transfer request. Regards, Bruce
RE: improving the registrar transfer process
Accountability. Responsibility. I agree with you on this 100%. ICANN needs to enforce there current policies. I agree too. Look at totalnic/pacnames. They have been refusing transfer requests years now until very very recent. What has ICANN done about all those complaints and violations that has been well documented? nothing! ICANN needs to stop just accepting money and start enforcing policies... Interestingly, the ICANN equivalent in Australia (auDA), does pro-actively enforce policies, and even took Capital Networks to court on the basis that they could be de-accredited as a registrar for .au, if they continued not to allow transfers for .com. See: http://www.austlii.edu.au/au/cases/cth/FCAFC/2004/324.html The original judgment is at: http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/808.html
RE: improving the registrar transfer process
On Fri, 2005-01-21 at 10:28 +1100, Bruce Tonkin wrote: Interestingly, the ICANN equivalent in Australia (auDA), does pro-actively enforce policies, and even took Capital Networks to court on the basis that they could be de-accredited as a registrar for .au, if they continued not to allow transfers for .com. See: http://www.austlii.edu.au/au/cases/cth/FCAFC/2004/324.html The original judgment is at: http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/808.html yes they did. now pacnames in another country supposedly bought capital... at least they are allowing you to transfer away this time though auDA being proactive is good...now its time icann is...
Re: Gtld transfer process
On Wed, 19 Jan 2005, Bruce Tonkin wrote: (5) The registry will send a message to the losing registrar confirming that a transfer has been initiated. Can you confirm or deny whether this actually happened in the case of the panix.com transfer? I don't have any direct visibility over this. I have asked Verisign and Dotster if they can confirm. My personal view is that I think it unlikely that this part of the system failed. Note however that Verisign would send the message via email to Dotster. Verisign could prove that they sent the email, but it is possible that it was not delivered. I'd like to make a few comments about the panix.com transfer issue. First, I can confirm that the panix.com domain was not in registrar lock status at the time of the transfer. Second, VeriSign did indeed send a transfer email to Dotster. The logs below show the message to Melbourne IT that Bruce already posted as well as the corresponding message to Dotster: To Melbourne IT: Jan 8 20:40:34 imx2 sendmail[19959]: j091eXp7019959: from=[EMAIL PROTECTED], size=1432, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=SMTP, daemon=MTA, relay=dump.pvt.dr.verisign-grs.net [172.26.148.34] Jan 8 20:40:35 imx2 sendmail[19977]: j091eXp7019959: to=[EMAIL PROTECTED], delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30130, relay=prod.internetnamesww.com. [203.27.227.115], dsn=2.0.0, stat=Sent (2.0.0 j091eYgt003545 Message accepted for delivery) To Dotster: Jan 8 20:40:34 imx2 sendmail[19959]: j091eXp9019959: from=[EMAIL PROTECTED], size=1113, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=SMTP, daemon=MTA, relay=dump.pvt.dr.verisign-grs.net [172.26.148.34] Jan 8 20:40:35 imx2 sendmail[19979]: j091eXp9019959: to=[EMAIL PROTECTED], delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30122, relay=mailgwca01.rightnowtech.com. [216.136.229.28], dsn=2.0.0, stat=Sent (2.6.0 Ok, id=31930-07, from MTA: 250 Ok: queued as BF1E258415) Third, every day VeriSign publishes a report for each registrar that shows, among other things, a list of pending outbound transfers. We have confirmed that panix.com appeared on Dotster's daily report as a pending outbound transfer for five days. (We cannot publish Dotster's reports without Dotster's permission.) Finally, there were many people here at VeriSign working behind the scenes over the weekend on this issue. Our ability to act unilaterally is constrained as we follow the process within the consensus policy for transfers--I hope everyone can understand and appreciate this. But we can focus our efforts on opening communications and working toward a resolution among the all parties. That's what happened last weekend: Martin Hannigan and I got the ball rolling on Sunday morning about 1000 EST. Our 24x7 customer service department contacted Dotster and Melbourne IT. Melbourne IT changed the panix.com name servers back to their original settings and transferred the domain back to Dotster. Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Naming and Directory Services
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
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.
RE: Gtld transfer process
Hello Mark, That's what happened last weekend: Martin Hannigan and I got the ball rolling on Sunday morning about 1000 EST. Our 24x7 customer service department contacted Dotster and Melbourne IT. Melbourne IT changed the panix.com name servers back to their original settings and transferred the domain back to Dotster. I can confirm that Verisign did get in touch with our Production Manager (Peter Berry) around 1pm Sunday (New York time), and our Reseller Program Manager (Steve Karabatsos) around 4:30pm Sunday (New York time). We were contacted previously by Panix around 5pm Saturday (New York time). I believe that Verisign complied with all their obligations with respect to the ICANN transfer policy, and Verisign was very cooperative in assisting us with the issue. Regards, Bruce
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Fri, Jan 21, 2005 at 12:55:45AM +, Will Hargrave wrote: If filters depend on IOS upgrades then those filters are there to stay. Perhaps the feature/filters ought to have an expiration date/TTL.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Chris A. Epler [EMAIL PROTECTED] 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
Re: broke Inktomi floods?
Vicky Rode [EMAIL PROTECTED] wrote: not sure if spiders falls under spam or ddos bracket when they repeatedly start hammering one's network. you could possible report to spamcop (*grin*) to get a quicker response. spamcom hasn't been accurate in some instances :-) Er.. just what would you report to spamcop, and what would spamcop do with your reports? do you remember this incident, http://www.cs.wisc.edu/~plonka/netgear-sntp/ Not very new .. broken apps which keep hammering on a resource for some reason are a fairly regular feature of the internet. srs
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Whats so bad about decent secure defaults? I don't consider a configuration that disenfranchises part of the internet as decent [...] defaults. :) The big problem that we're experiencing here is that the big telco ISP's, network providers and managed service providers that should have something better than a 'network monkey' running their routers are having BOGON filtering problems. We diagnosed a problem getting to east cost government sites and in working with SAVVIS, we corrected problems in a matter of hours. This has been the only positive progress we've made in unblackholing out network segment. We're going on day number 4 trying to get SBC to fix 'managed' local government routers. To tell you the truth, the little leaf nodes that have a corporation without world-accessible resources behind their router are unconsequential to us -- let them filter on old BOGON lists -- our customers need to be able to get to the resources that are behind the huge networks that are maintained by companies much larger than ours that are running out of date filters. Why more people don't use resources like what Cymru offer is beyond me... James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED]
RE: Gtld transfer process
I can confirm that * did get in touch with our Production Manager (*) around 1pm Sunday What I want to know, as a customer of a domain registrar and a holder of many domains, is why wasn't the person/company paying for the domain contacted through out this process? It seems to me that the majority of the communicationswas between people who contributed nothing to the domain and had nothing to loose by corruption of the domain. Clearly, in my mind, the process seems broken. Abounding apologies do nothing to assure my concerns that this problem will re-occur. I sincerely doubt that the outcome would be as quick and complete if the domain in question wasn't as substantial as panix.com. -Jim P.
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005 21:14:12 -0800, James Laszko [EMAIL PROTECTED] wrote: ... Why more people don't use resources like what Cymru offer is beyond me... Not-Invented-Here syndrome? -- GDB has a 'break' feature; why doesn't it have 'fix' too?
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005, James Laszko wrote: Whats so bad about decent secure defaults? I don't consider a configuration that disenfranchises part of the internet as decent [...] defaults. :) The big problem that we're experiencing here is that the big telco ISP's, network providers and managed service providers that should have something better than a 'network monkey' running their routers are having BOGON filtering problems. We diagnosed a problem getting to east cost government sites and in working with SAVVIS, we corrected problems in a matter of hours. This has been the only positive progress we've made in unblackholing out network segment. We're going on day number 4 trying to get SBC to fix 'managed' local government routers. you do understand that for SBC (or anyone who manages customer devices) to make a change: 1) the customer has to be notified of the change and given a reason for the change 2) the customer has to agree to the change (presumably they also have to actually be contacted a task of it's own at times) 3) the change has to be scheduled into a maint window 4) the procedures and maintenance changes probably have to be checked over with the 'network monkey' (as you put it) and customer 5) change happens, for 1 customer... Wash, rinse, repeat for the other 70,000 routers you manage for customers... This is definitely NOT a half-rack in a colo fix. Just contacting the customers is a feat. -Chris
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Wash, rinse, repeat for the other 70,000 routers you manage for customers... This is definitely NOT a half-rack in a colo fix. Just contacting the customers is a feat. In the same hand, do you know how hard it was to get in touch with someone at SBC/SBC-IS/PBI/PacBell that knew what the heck I was talking about -- much less someone that might be able to do something about it? Every group wanted to point their finger at some other group in the company... James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED]
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Wash, rinse, repeat for the other 70,000 routers you manage for customers... This is definitely NOT a half-rack in a colo fix. Just contacting the customers is a feat. And I completely agree that it's a big pain to coordinate this. In the same hand, SBC and all other 'big' providers use BGP to dynamically update their routing tables. Their BOGON filtering should use the same sort of mechanism. If they're not going to use something like the Cymru BOGON BGP feed they should build their own and should have configured their managed routers to query that from the beginning. As more old-BOGON IP's come into play, more and more of the Internet is going to 'fall off' to these legacy route access list restricted routers. As much as I would have liked to coin the term 'network monkey', I read it in this thread by someone much more creative than I. :-) James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED]
Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
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 pgpxUfvMrZCcZ.pgp Description: PGP signature
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005, James Laszko wrote: Wash, rinse, repeat for the other 70,000 routers you manage for customers... This is definitely NOT a half-rack in a colo fix. Just contacting the customers is a feat. And I completely agree that it's a big pain to coordinate this. In the same hand, SBC and all other 'big' providers use BGP to dynamically update their routing tables. Their BOGON filtering should use the same BGP holds destination info, the problem filters you speak of are MOST PROBABLY not BGP related at all, they are likely interface filters of the form: access-list 100 deny ip 0.0.0.0 0.255.255.255 any (assuming a cisco box of course, and this is a single line, hopefully they permit the customer network to get something as a last line in the acl) sort of mechanism. If they're not going to use something like the Cymru BOGON BGP feed they should build their own and should have configured their managed routers to query that from the beginning. As more This is impractical as the afore-mentioned 70,000 routers are likely not bgp capable (not all atleast, why buy that feature when all it'll ever do is static and conencted routes?). old-BOGON IP's come into play, more and more of the Internet is going to 'fall off' to these legacy route access list restricted routers. Perhaps they will see the problems and move to a better solution, perhaps their customers will ask for filter adjustments as these new pesky /8's you speak of are 'released' for people to use... what's an ip address again? :( As much as I would have liked to coin the term 'network monkey', I read it in this thread by someone much more creative than I. :-) Either way, it's not the monkeys in this case most likely. I'd bet at the least there is the issue of getting in touch with the customer, and initiatinng change at his/her/their request... why 'fix' something that isn't broken? there are hundreds of thousands of 2511's out there with 2MB of flash and 11.2 code still running on them. These will NEVER be upgraded to anything 'new' because cost to upgrade includes upgrading the hardware at 3k minimum per box... not to mention outages for customers who 'dont see a problem today' and don't like outages. -Chris
RE: improving the registrar transfer process
On Fri, 21 Jan 2005, Bruce Tonkin wrote: We know how to do 3-way handshakes. Rather a fundamental of the Internet. So quickly folks forget The ICANN policy change had no impact on this particular incident. As the incident has been documented so far, the transfer would have occurred under both the old and the new policy. I think it would be helpfull if you explain what steps are involved in domain transfer process (to your registrar) and its authorization, i.e. something like 1. MIT receives transfer request from reseller 2. MIT sends email confirmation to whois contact (which contact - tech, admin?) 3. MIT sends email (or is it request through Verisign RRP?) to Verisign 4. MIT waits for such and such action... etc. I also would like to confirm who is responsible for denying transfer request if LOCK is present. Is Registry supposed to do it automaticly or is it responsibility of losing registrar to actively deny the request if they have put lock on domain? -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005, James Laszko wrote: Wash, rinse, repeat for the other 70,000 routers you manage for customers... This is definitely NOT a half-rack in a colo fix. Just contacting the customers is a feat. In the same hand, do you know how hard it was to get in touch with someone at SBC/SBC-IS/PBI/PacBell that knew what the heck I was talking about -- much less someone that might be able to do something about it? Every group wanted to point their finger at some other group in the company... Sure, start with the customer and convince them that there is a problem. SBC has, like sprint/att/mci/qwest/abovenet/blah-provider-of-managed-services 12 groups that do 'similar' things for 'managed customers'. Fighting their phone tree as a non-customer is a fruitless effort. Fighting the phone-tree for gov't agency #13 to let them know that some of their 'customers' aren't able to reach them might prove simpler. -Chris
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005, James Laszko wrote: sort of mechanism. If they're not going to use something like the Cymru BOGON BGP feed they should build their own and should have configured their managed routers to query that from the beginning. As more How would this scale for say 200K routers? 2M? -Hank
FW: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
We've had complaints from people at the other side of Broadwing connections -- anyone here from Broadwing? Looks like you may even be stripping 72.0.0.0/8 from BGP announcements. James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: Christopher L. Morrow [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 9:55 PM To: James Laszko Cc: Rob Evans; Chris A. Epler; nanog@merit.edu Subject: RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19 On Thu, 20 Jan 2005, James Laszko wrote: Wash, rinse, repeat for the other 70,000 routers you manage for customers... This is definitely NOT a half-rack in a colo fix. Just contacting the customers is a feat. In the same hand, do you know how hard it was to get in touch with someone at SBC/SBC-IS/PBI/PacBell that knew what the heck I was talking about -- much less someone that might be able to do something about it? Every group wanted to point their finger at some other group in the company... Sure, start with the customer and convince them that there is a problem. SBC has, like sprint/att/mci/qwest/abovenet/blah-provider-of-managed-services 12 groups that do 'similar' things for 'managed customers'. Fighting their phone tree as a non-customer is a fruitless effort. Fighting the phone-tree for gov't agency #13 to let them know that some of their 'customers' aren't able to reach them might prove simpler. -Chris
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
Well, if the router CAN run BGP, the feed from Cymru is only about 84 prefixes - not a lot of memory tied up there, is there? If the router isn't capable of BGP, someone earlier today was kind enough to post a script that they use to find changes to one of the BOGON lists and suggested an Expect script to automatically update their router. Probably a little advanced for most leaf sites, but for someone who's responsible for a larger network -- doesn't seem that bad. James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: Hank Nussbacher [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 10:51 PM To: James Laszko Cc: nanog@merit.edu Subject: RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19 On Thu, 20 Jan 2005, James Laszko wrote: sort of mechanism. If they're not going to use something like the Cymru BOGON BGP feed they should build their own and should have configured their managed routers to query that from the beginning. As more How would this scale for say 200K routers? 2M? -Hank
RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
On Thu, 20 Jan 2005, James Laszko wrote: Well, if the router CAN run BGP, the feed from Cymru is only about 84 prefixes - not a lot of memory tied up there, is there? I am *not* talking about the leaf - rather the core. I am curious what resources are needed to manage 200K BGP peers other than 200K IP addresses. Is there an IOS limit on the number of BGP peers? Memory? -Hank If the router isn't capable of BGP, someone earlier today was kind enough to post a script that they use to find changes to one of the BOGON lists and suggested an Expect script to automatically update their router. Probably a little advanced for most leaf sites, but for someone who's responsible for a larger network -- doesn't seem that bad. James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: Hank Nussbacher [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 10:51 PM To: James Laszko Cc: nanog@merit.edu Subject: RE: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19 On Thu, 20 Jan 2005, James Laszko wrote: sort of mechanism. If they're not going to use something like the Cymru BOGON BGP feed they should build their own and should have configured their managed routers to query that from the beginning. As more How would this scale for say 200K routers? 2M? -Hank +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
