RE: optics pricing (Re: Weird GigE Media Converter Behavior)
On Fri, 27 Aug 2004, Michel Py wrote: > so darn pricey it's because it's so darn good. Like Rolls-Royce cars, > the ones that buy them are typically not the ones that drive them, so > technical arguments tend to become irrelevant. If the VSR card was $899k, the SR card was $999k and the LR card was $1099 you wouldn't hear any complaints from me. It's the fact that Cisco is reselling optics (which is not their core business as far as I see it) at a huge markup that is bothering me. But then again, if other people want to pay a huge premium that's their problem, I'm not buying it. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: BGP Homing Question
> Patrick W Gilmore wrote: > There is zero "bad citizenry" in this, and don't > let anyone tell you differently. I agree, but not for the reason below: > It is your netblock, you get to use it as needed. This is not a good reason; it might be a good excuse, but not a good reason. > This is much better than getting another /20 for > an EU site that only needs a /24. However, what's above _is_ a good reason. In terms of the size of the routing table, it does not really matter which two prefixes you announce, as the simpl(istic) way to see it is that they take two prefixes anyway. In terms of conservation of the address space it does matter, as announcing a subnet of your ARIN block in Europe is actually being a good netizen because it does not waste an ARIN netblock. > Also, filtering will not be an issue, if you are careful. > Anyone who does not hear the /24 will hear the /20. Rick, you do need to tunnel the EU block from your US location back to your EU location, for people that are behind a filter that masks your /24. It does not happen often but it does happen. This leads to suboptimal asymmetric traffic, double whammy in terms of bandwidth (EU-bound traffic received by the US site from people that see the /20 and not the /24 that has to be re-sent back to EU over the tunnel) and interesting issues with stateful firewalls though. Bottom line is: what Rick is suggesting is actually The Right Thing (tm) to do; the bad netizen would embellish the truth and request a /20 from RIPE instead, as Patrick mentioned. Technically speaking, it is sad to say that the bad thing is more bullet-proof than the right thing though :-( no filtering issues. It's not nearly as bad as it was a few years ago though, as people have finally given up on trying to get a full BGP feed on a 3640 with 128 Megs of RAM. Michel.
RE: optics pricing (Re: Weird GigE Media Converter Behavior)
> Mikael Abrahamsson wrote: > 4 port OC192 IR $1030k > Is there anyone who can justify this pricing > with anything else than "because we can?" That's a heck of a good reason! Any for-profit business tries hard to position themselves where they could name their price. This pricing is consistent with the guesses/predictions that were floating at the time of the product announcement; there was some political will to have a million bucks line card (otherwise they would have priced it at $999,950 ;-). This is Rolls-Royce marketing: if it's so darn pricey it's because it's so darn good. Like Rolls-Royce cars, the ones that buy them are typically not the ones that drive them, so technical arguments tend to become irrelevant. Michel.
Re: BGP Homing Question
No it was because we (Sprint, where I worked at that time) still felt that it was valuable. The change happened a couple of months after I left. From what I was told when the change happened, it was decided that it was no longer more important to do, then the pain it caused, because of massive increases in router memory, and the ability to do prefix-filters to clamp down on large eruptions. jon > > Out of the ether, [EMAIL PROTECTED] spewed forth the following bitstream: > > > Actually Sprint continued filtering for 2 years after Sean left. > > But was that because they could not figure out how to turn it off? > > AlanC > -- > A plot, if there is to be one, must be a secret. A secret that, if | > we only knew it, would dispel our frustration, lead us to salvation; | TSILB > or else the knowing of it in itself would be salvation. | >
10 GE WAN PHY status?
Hi, I'm currently looking into how to best integrate 10G lambda lines into a network. The two obvious ways are via "native" SDH/SONET or via 10 GE WAN PHY, but the latter isn't available on any router platform so far. What I like with 10GE is that its possible to run a ring segment via L2-switches on each end and connect to them via multiple L3-devices. So you can basically run a 10G line with a redundant pair of routers on each line concurrently and without any static bandwith partitioning. Am I missing something? Sine none of the long distance providers I talked with so far can provide 10 GE LAN PHY as client side interface, I'm currently looking for L2-switches that can perform this conversion between LAN and WAN PHY, but I only found the Nortel Passport and the Force10 E-Series, both AFAIK quite pricy product lines. Last informations I got about WAN PHY XENPAKs was that most switch manufacturers can only provide them sometime in Q1/2005 (but I read the same in an article on this list about Q1/2004 :] ). Are there other products I missed? Are there XENPAKs already available which work with main stream switch manufacturers although they don't sell them themselves so far? Grateful for any pointers or experiences... tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA pgpuS0tSjjTak.pgp Description: PGP signature
Re: time to bury nethead versus bellhead polemics
> "netheaded" was seen as the 'nirvana' to which the Internet would > guide telecommunications. And I've been netheaded since '95. ;) -- Joe Hamelin <[EMAIL PROTECTED]/.org/.us/.org.uk> Edmonds, WA, US
Re: On the back of other security posts (well some over a year ago now)....
- Original Message - From: "joe mcguckin" <[EMAIL PROTECTED]> To: "NANOG" <[EMAIL PROTECTED]> Sent: Friday, August 27, 2004 1:36 PM Subject: Re: On the back of other security posts (well some over a year ago now) > > > What strikes me as interesting is the fact that someone did hundreds of > thousands of dollars worth of damage in exchange for -- a shell account?? you want to attract idiots - use a shell account as bait. just like flies and feces. paul
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 28 Aug, 2004 Analysis Summary BGP routing table entries examined: 144261 Prefixes after maximum aggregation: 85919 Unique aggregates announced to Internet: 69594 Total ASes present in the Internet Routing Table: 17870 Origin-only ASes present in the Internet Routing Table: 15497 Origin ASes announcing only one prefix:7274 Transit ASes present in the Internet Routing Table:2373 Transit-only ASes present in the Internet Routing Table: 75 Average AS path length visible in the Internet Routing Table: 4.8 Max AS path length visible: 22 Prefixes from unregistered ASNs in the Routing Table:30 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 16 Number of addresses announced to Internet: 1331425836 Equivalent to 79 /8s, 91 /16s and 242 /24s Percentage of available address space announced: 35.9 Percentage of allocated address space announced: 58.1 Percentage of available address space allocated: 61.9 Total number of prefixes smaller than registry allocations: 65356 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:27805 Total APNIC prefixes after maximum aggregation: 13969 Prefixes being announced from the APNIC address blocks: 26034 Unique aggregates announced from the APNIC address blocks:14136 APNIC Region origin ASes present in the Internet Routing Table:2114 APNIC Region origin ASes announcing only one prefix:627 APNIC Region transit ASes present in the Internet Routing Table:329 Average APNIC Region AS path length visible:4.8 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 158085760 Equivalent to 9 /8s, 108 /16s and 50 /24s Percentage of available APNIC address space announced: 72.1 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 23552-24575 APNIC Address Blocks 58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 82155 Total ARIN prefixes after maximum aggregation:50156 Prefixes being announced from the ARIN address blocks:63556 Unique aggregates announced from the ARIN address blocks: 22488 ARIN Region origin ASes present in the Internet Routing Table: 9438 ARIN Region origin ASes announcing only one prefix:3399 ARIN Region transit ASes present in the Internet Routing Table: 924 Average ARIN Region AS path length visible: 4.5 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 230906400 Equivalent to 13 /8s, 195 /16s and 90 /24s Percentage of available ARIN address space announced: 68.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647,29695-30719, 31744-33791 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/7, 72/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 26719 Total RIPE prefixes after maximum aggregation:18867 Prefixes being announced from the RIPE address blocks:23513 Unique aggregates announced from the RIPE address blocks: 15669 RIPE Region origin ASes present in the Internet Routing Table: 5771 RIPE Region origin ASes announcing only one prefix:3110 RIPE Region transit ASes present in the Internet Routing Table: 995 Average RIPE Region AS path length visible: 5.4 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 169823552 Equivalent to 10 /8s, 31 /16s and 77 /24s Percentage o
Re: On the back of other security posts (well some over a year ag o now)....
What strikes me as interesting is the fact that someone did hundreds of thousands of dollars worth of damage in exchange for -- a shell account?? This is beyond idiotic. Joe On 8/27/04 7:56 AM, "Hosman, Ross" <[EMAIL PROTECTED]> wrote: > > Wow... > > Glad to see we know the real reason foonet got raided. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Matthew Sullivan > Sent: Friday, August 27, 2004 4:41 AM > To: nanog > Subject: On the back of other security posts (well some over a year ago > now) > > > > Need I say more...? > > http://www.securityfocus.com/news/9411 > > My thanks to those who listened and helped me. My thanks to those who > helped Spamhaus, and my thanks to anyone else who got involved with the > whole deal. > > / Mat > -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-213-1302 Cell: 650-207-0372 Fax: 650-969-2124
Re: BGP Homing Question
On Fri, Aug 27, 2004 at 11:16:40AM -0400, Patrick W Gilmore wrote: > Anyone knows who filters these days? Sprint stopped when Sean left. > Verio stopped when Randy left. I don't know anyone beating that drum > any more. (Kinda nice, actually.) I've heard some Asian ISPs do, but > don't remember who. Verio filtering had nothing to do with Randy leaving. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: BGP Homing Question
Actually Sprint continued filtering for 2 years after Sean left. jon > > > Anyone knows who filters these days? Sprint stopped when Sean left. > > -- > TTFN, > patrick > >
Re: VeriSign's antitrust suit against ICANN dismissed
Not exactly, as apparently they can take it back to the state courts. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace On Aug 27, 2004, at 10:51 AM, Hosman, Ross wrote: One stupid lawsuit from Verisign down...one more stupid lawsuit from SCO to go -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Henry Linneweh Sent: Friday, August 27, 2004 9:29 AM To: [EMAIL PROTECTED] Subject: VeriSign's antitrust suit against ICANN dismissed http://news.com.com/ VeriSign%27s+antitrust+suit+against+ICANN+dismissed/2100 -1030_3-5326136.html?tag=nefd.top
RE: time to bury nethead versus bellhead polemics
seems like a moment to announce a conference dedicated to burying the polemics: Nethead/Bellhead: The FCC Takes On the Internet www.cardozobellhead.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Cook Sent: Friday, August 27, 2004 11:40 AM To: [EMAIL PROTECTED] Subject: time to bury nethead versus bellhead polemics Hope that more than a few here will be interested in some of my recent conclusions - from the November issue that I just published. Why a Layered Model is the Only Reasonable Way to Evaluate Telecom Lines of Business Have Blurred - Making the Regulatory Concept of Vertical Silos Archaic Time Has Come to Bury All "Bellhead versus Nethead" Polemics Introduction Since the bubble burst in late 2000 sending the Internet and the rest of telecom into a tailspin, it has been rather obvious that former stability and predictability of the economics of telecommunications has been shattered. The last several issues of The COOK Report have explored the fallout of those shattered economics in great detail. In this introduction The COOK Report notes that telecom economics is likely to stay broken, first, due to oversupply, and second due to lack of differentiation on anything other than price across too many competitors in services and service providers. Third: because of very loosely bonded brand loyalty. A final and very serious additional problem is regulatory instability as the FCC struggles with historical precedent in its interpretation of legislation. It finds itself whip-sawed between its "vertical silo" model derived from the technology it regulates, and the increasingly advocated "horizontal network layer view" of the IP enabled services, including but not limited to VoIP, Video over IP, and so on. As long-term, and, perhaps, not so long term, readers of The COOK Report are aware, this publication has not only long trumpeted the "bellhead vs. nethead" divide, but taken a partisan position where anything seen to be "bell-headed" was regarded as bad while "netheaded" was seen as the 'nirvana' to which the Internet would guide telecommunications. = = == For the remainder of my Bury "Bellhead versus Nethead" Polemics article please see http://cookreport.com/13.08.shtml -- = The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 415 651-4147 (Lingo) Subscription info & prices at http://cookreport.com/subscriptions.shtml Why Bellhead vs Nethead polemics don't help at: http://cookreport.com/13.08.shtml E-mail [EMAIL PROTECTED] =
time to bury nethead versus bellhead polemics
Hope that more than a few here will be interested in some of my recent conclusions - from the November issue that I just published. Why a Layered Model is the Only Reasonable Way to Evaluate Telecom Lines of Business Have Blurred - Making the Regulatory Concept of Vertical Silos Archaic Time Has Come to Bury All "Bellhead versus Nethead" Polemics Introduction Since the bubble burst in late 2000 sending the Internet and the rest of telecom into a tailspin, it has been rather obvious that former stability and predictability of the economics of telecommunications has been shattered. The last several issues of The COOK Report have explored the fallout of those shattered economics in great detail. In this introduction The COOK Report notes that telecom economics is likely to stay broken, first, due to oversupply, and second due to lack of differentiation on anything other than price across too many competitors in services and service providers. Third: because of very loosely bonded brand loyalty. A final and very serious additional problem is regulatory instability as the FCC struggles with historical precedent in its interpretation of legislation. It finds itself whip-sawed between its "vertical silo" model derived from the technology it regulates, and the increasingly advocated "horizontal network layer view" of the IP enabled services, including but not limited to VoIP, Video over IP, and so on. As long-term, and, perhaps, not so long term, readers of The COOK Report are aware, this publication has not only long trumpeted the "bellhead vs. nethead" divide, but taken a partisan position where anything seen to be "bell-headed" was regarded as bad while "netheaded" was seen as the 'nirvana' to which the Internet would guide telecommunications. = = == For the remainder of my Bury "Bellhead versus Nethead" Polemics article please see http://cookreport.com/13.08.shtml -- = The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 415 651-4147 (Lingo) Subscription info & prices at http://cookreport.com/subscriptions.shtml Why Bellhead vs Nethead polemics don't help at: http://cookreport.com/13.08.shtml E-mail [EMAIL PROTECTED] =
Re: BGP Homing Question
On Aug 27, 2004, at 8:58 AM, Joe Abley wrote: On 27 Aug 2004, at 08:13, Rick Lowery wrote: I know they would not be good Internet citizen, but if they needed to do this for a temp basis does anyone see an issue? There's not much bad citizenry in what you are suggesting: the assigning-RIR problem is a non-problem, and your two sites are still only going to originate one prefix each (which they would presumably do even if you had a separate LIR assignment for the European node). There is zero "bad citizenry" in this, and don't let anyone tell you differently. It is your netblock, you get to use it as needed. This is much better than getting another /20 for an EU site that only needs a /24. Also, filtering will not be an issue, if you are careful. Anyone who does not hear the /24 will hear the /20. Packets for the /24 will go to your US upstream. As long as your US upstream peers with your EU upstream, and does not filter the /24 being announced over that peering link, they will send the bits where they belong. Since this is much more common than the alternative, you will likely have full connectivity. Anyone knows who filters these days? Sprint stopped when Sean left. Verio stopped when Randy left. I don't know anyone beating that drum any more. (Kinda nice, actually.) I've heard some Asian ISPs do, but don't remember who. -- TTFN, patrick
RE: On the back of other security posts (well some over a year ag o now)....
Wow... Glad to see we know the real reason foonet got raided. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matthew Sullivan Sent: Friday, August 27, 2004 4:41 AM To: nanog Subject: On the back of other security posts (well some over a year ago now) Need I say more...? http://www.securityfocus.com/news/9411 My thanks to those who listened and helped me. My thanks to those who helped Spamhaus, and my thanks to anyone else who got involved with the whole deal. / Mat
RE: VeriSign's antitrust suit against ICANN dismissed
One stupid lawsuit from Verisign down...one more stupid lawsuit from SCO to go -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Henry Linneweh Sent: Friday, August 27, 2004 9:29 AM To: [EMAIL PROTECTED] Subject: VeriSign's antitrust suit against ICANN dismissed http://news.com.com/VeriSign%27s+antitrust+suit+against+ICANN+dismissed/2100 -1030_3-5326136.html?tag=nefd.top
Fastmail.fm contact
Hi All, I'm looking for an admin bod @fastmail.fm - anybody have a contact to lend me off-list? Many thanks, George -- George Barnett Reality Engineer & Explorer e: [EMAIL PROTECTED] m: +44 778 884 7205 Things must be as they may - William Shakespear, Henry V
VeriSign's antitrust suit against ICANN dismissed
http://news.com.com/VeriSign%27s+antitrust+suit+against+ICANN+dismissed/2100-1030_3-5326136.html?tag=nefd.top
Re: BGP Homing Question
On Fri, Aug 27, 2004 at 08:13:41AM -0400, Rick Lowery wrote: > If someone owns their own /20 which they received from Arin back > in the day and they want to subnet and use part of it (/24) in Europe. > Would their be any problems if the wanted to advertise the North > American issued space from a European AS? I know they would not be > good Internet citizen, but if they needed to do this for a temp basis > does anyone see an issue? You'd be creating "Total number of prefixes smaller than registry allocations++" and some people might filter the route. Apart from that, no. Nils
Re: DNS
(Can you turn off HTML when posting to lists? TIA) * [EMAIL PROTECTED] (Paul Gilbert) [Fri 27 Aug 2004, 14:49 CEST]: > I have a friend whom has a problem with we believe DNS. In this case the > ISP is NTL. He has a stateful firewall and is running NAT you can see from > the tcp dump below that he sends the query to one DNS server but another > responds thus breaking the firewall state and therefore it never resolves. Breaking the DNS protocol, too - cf. BIND's old "Response from unexpected source" syslog messages. http://archives.neohapsis.com/archives/incidents/2000-02/0032.html http://archives.neohapsis.com/archives/incidents/2000-02/0044.html Haven't seen one of those in a while, actually - has BIND gotten better at binding sockets to specific interface addresses (it has) or has it stopped reporting such instances? > Should the provider have the forwarding option on there servers or does he > need to punch another hole in his firewall. Punching holes is not likely to work as it's NAT that breaks... -- Niels.
Re: BGP Homing Question
On 27 Aug 2004, at 08:13, Rick Lowery wrote: If someone owns their own /20 which they received from Arin back in the day and they want to subnet and use part of it (/24) in Europe. Would their be any problems if the wanted to advertise the North American issued space from a European AS? There should be no technical problem due to the origins of the numbers. There might be a problem with some operators filtering out the /24 if it's allocated from a block with consistent /20 allocation boundaries. However, if it's an old allocation this is not necessarily going to be the case (and many people are not that enthusiastic about allocation boundary filtering anyway). If you poke around on www.arin.net you should find summaries by /8 for the longest allocation within each block. The paragraph above is only a concern if your specific /20 lives in a /8 where the longest allocation made by ARIN has a mask length less than 24 bits. I know they would not be good Internet citizen, but if they needed to do this for a temp basis does anyone see an issue? There's not much bad citizenry in what you are suggesting: the assigning-RIR problem is a non-problem, and your two sites are still only going to originate one prefix each (which they would presumably do even if you had a separate LIR assignment for the European node). Joe
DNS
I have a friend whom has a problem with we believe DNS. In this case the ISP is NTL. He has a stateful firewall and is running NAT you can see from the tcp dump below that he sends the query to one DNS server but another responds thus breaking the firewall state and therefore it never resolves. Should the provider have the forwarding option on there servers or does he need to punch another hole in his firewall. cheers 09:23:01.216136 80.2.189.69.53 > 194.168.8.100.53: 54051+ [1au][|domain] (DF) 09:23:01.534353 194.168.4.100.53 > 80.2.189.69.53: 54051[|domain] (DF) 09:23:01.534618 80.2.189.69 > 194.168.4.100: icmp: 80.2.189.69 udp port 53 unreachable [tos 0xc0] 09:23:11.238123 80.2.189.69.53 > 194.168.8.100.53: 12113+ [1au][|domain] (DF) 09:23:11.414372 194.168.4.100.53 > 80.2.189.69.53: 12113[|domain] (DF) 09:23:11.414606 80.2.189.69 > 194.168.4.100: icmp: 80.2.189.69 udp port 53 unreachable [tos 0xc0] 09:23:19.634810 80.2.189.69.53 > 194.168.8.100.53: 9737+ [1au][|domain] (DF) 09:23:19.643883 194.168.4.100.53 > 80.2.189.69.53: 9737[|domain] (DF) 09:23:19.644127 80.2.189.69 > 194.168.4.100: icmp: 80.2.189.69 udp port 53 unreachable [tos 0xc0] Paul Gilbert Router Management Solutions, Inc. www.routermanagement.com work: 5167666068 mobile: 5164564983
BGP Homing Question
If someone owns their own /20 which they received from Arin back in the day and they want to subnet and use part of it (/24) in Europe. Would their be any problems if the wanted to advertise the North American issued space from a European AS? I know they would not be good Internet citizen, but if they needed to do this for a temp basis does anyone see an issue? Thanks, Rick
The Cidr Report
This report has been generated at Fri Aug 27 21:42:49 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
20-08-04140707 96788
21-08-04140804 96668
22-08-04140728 96674
23-08-04140727 96681
24-08-04140829 96703
25-08-04140971 96790
26-08-04140909 96844
27-08-04141076 96827
AS Summary
17798 Number of ASes in routing system
7272 Number of ASes announcing only one prefix
1373 Largest number of prefixes announced by an AS
AS7018 : ATTW AT&T WorldNet Services
85962240 Largest address span announced by an AS (/32s)
AS721 : DNIC DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 27Aug04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 141093968314426231.4% All ASes
AS18566 7417 73499.1% CVAD Covad Communications
AS4134 782 172 61078.0% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4323 775 219 55671.7% TWTC Time Warner Telecom
AS6347 659 122 53781.5% SAVV SAVVIS Communications
Corporation
AS7018 1373 944 42931.2% ATTW AT&T WorldNet Services
AS7843 488 103 38578.9% ADELPH-13 Adelphia Corp.
AS22773 379 20 35994.7% CXAB Cox Communications Inc.
Atlanta
AS6467 387 31 35692.0% ACSI e.spire Communications,
Inc.
AS9583 528 178 35066.3% SATYAMNET-AS Satyam Infoway
Ltd.,
AS701 1252 904 34827.8% UU UUNET Technologies, Inc.
AS6197 717 395 32244.9% BNS-14 BellSouth Network
Solutions, Inc
AS9929 353 34 31990.4% CNCNET-CN China Netcom Corp.
AS22909 361 44 31787.8% CMCS Comcast Cable
Communications, Inc.
AS27364 351 37 31489.5% ARMC Armstrong Cable Services
AS1239 940 630 31033.0% SPRN Sprint
AS11172 354 52 30285.3% Alestra
AS17676 345 43 30287.5% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS4355 380 99 28173.9% ERSD EARTHLINK, INC
AS6478 345 64 28181.4% ATTW AT&T WorldNet Services
AS4766 543 266 27751.0% KIXS-AS-KR Korea Telecom
AS9443 359 109 25069.6% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS6140 369 123 24666.7% IMPSA ImpSat
AS14654 254 10 24496.1% WAYPOR-3 Wayport
AS6198 456 220 23651.8% BNS-14 BellSouth Network
Solutions, Inc
AS25844 244 15 22993.9% SASMFL-2 Skadden, Arps, Slate,
Meagher & Flom LLP
AS3561 466 253 21345.7% CWU Cable & Wireless USA
AS6327 226 29 19787.2% SHAWC-2 Shaw Communications
Inc.
AS5668 388 196 19249.5% CIH-12 CenturyTel Internet
Holdings, Inc.
AS22291 260 68 19273.8% CC04 Charter Communications
AS721605 427 17829.4% DNIC DoD Network Information
Center
Total 15680 5814 986662.9% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax
Cable Ltd.
24.246.0.0/17AS7018 ATTW AT&T WorldNet Services
24.246.38.0/24 AS25994 NPGCAB NPG Cable, INC
24.246.128.0/18 AS7018 ATTW AT&T WorldNet Services
64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS
64.46.12.0/24AS7850 IHIGHW iHighway.net, Inc.
64.46.27.0/24AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB
64.46.34.0/24AS3408
6
Cisco Security Advisory: Cisco Telnet Denial of Service Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco Telnet Denial of Service Vulnerability Revision 1.0 For Public Release 2004 August 27 1000 UTC - - Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures - - Summary === A specifically crafted Transmission Control Protocol (TCP) connection to a telnet or reverse telnet port of a Cisco device running Internetwork Operating System (IOS) may block further telnet, reverse telnet, Remote Shell (RSH), Secure Shell (SSH), and in some cases Hypertext Transport Protocol (HTTP) access to the Cisco device. Telnet, reverse telnet, RSH and SSH sessions established prior to exploitation are not affected. All other device services will operate normally. Services such as packet forwarding, routing protocols and all other communication to and through the device are not affected. Cisco will make free software available to address this vulnerability. Workarounds, identified below, are available that protect against this vulnerability. This vulnerability is documented in Cisco bug ID CSCef46191 ( registered customers only) . This Advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20040827-telnet.shtml. Affected Products = Vulnerable Products - --- This vulnerability affects all Cisco devices that permit access via telnet or reverse telnet and are running an unfixed version of IOS. Products Confirmed Not Vulnerable - - Cisco products that do not run IOS are not affected. Details === Telnet, RSH and SSH are used for remote management of Cisco IOS devices. The SSH protocol is also used for Secure Copy (SCP), which allows an encryption-protected transfer of files to and from Cisco devices. HTTP is also used for management of certain Cisco devices. IOS versions prior to12.2(15)T include HTTP server version 1.0, which, if configured, will be unresponsive on a device that is under exploitation. IOS versions after and including 12.2(15)T include HTTP server version 1.1, which is unaffected. Reverse telnet is a feature that allows you to telnet to a Cisco device and then connect to a third device through an asynchronous serial connection. For more information on reverse telnet, consult the following documents: http://cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a00800871ec.html http://cisco.com/en/US/products/sw/iosswrel/ps1826/products_configuration_guide_chapter09186a00800d9bd8.html Cisco devices that are operating as a reverse telnet server may have ports open in the ranges of: * 2001 to 2999 * 3001 to 3099 * 6001 to 6999 * 7001 to 7099 After a specially crafted TCP connection to an IOS device on TCP port 23 or the reverse telnet ports listed above, all subsequent telnet, reverse telnet, RSH (TCP port 514), SSH, SCP (SSH and SCP use TCP port 22), and in some cases HTTP (TCP port 80) connections to the device experiencing exploitation will be unsuccessful. Any telnet, reverse telnet, RSH, SSH, SCP and HTTP sessions that are already established with the device will continue to function properly. In Cisco IOS, telnet, reverse telnet, RSH, SSH, SCP and some HTTP sessions are handled by a virtual terminal (VTY). Each telnet, reverse telnet, RSH, SSH and SCP session consumes a VTY. After successful exploitation, the Cisco device can no longer accept any subsequent VTY connections. Though it is not possible to establish new telnet, reverse telnet, RSH, SSH, SCP or HTTP connections to the device after a successful exploitation, the device is only vulnerable on TCP port 23 and the reverse telnet ports listed above. A successful exploitation of this vulnerability requires a complete 3-way TCP handshake, which makes it very difficult to spoof the source IP address. Only remote access services that use VTYs are affected. This includes telnet, reverse telnet, RSH, SSH, SCP and version 1.0 of the HTTP server. Other device services including, but not limited to, routing protocols, TACACS/RADIUS, Voice over IP (VoIP) and packet forwarding are not affected. This vulnerability is addressed by Cisco bug ID: * CSCef46191 ( registered customers only) To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS ®". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the
On the back of other security posts (well some over a year ago now)....
Need I say more...? http://www.securityfocus.com/news/9411 My thanks to those who listened and helped me. My thanks to those who helped Spamhaus, and my thanks to anyone else who got involved with the whole deal. / Mat
