The Cidr Report
This report has been generated at Fri Feb 13 21:13:35 2009 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
06-02-09285832 177824
07-02-09285798 177687
08-02-09285807 177487
09-02-09285105 177994
10-02-09285977 177992
11-02-09286165 177022
12-02-09286477 177950
13-02-09286337 178268
AS Summary
30645 Number of ASes in routing system
13024 Number of ASes announcing only one prefix
4368 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
89824768 Largest address span announced by an AS (/32s)
AS27064: DDN-ASNBLK1 - 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').
--- 13Feb09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 286636 178252 10838437.8% All ASes
AS6389 4368 356 401291.8% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4223 1770 245358.1% TWTC - tw telecom holdings,
inc.
AS209 2830 1260 157055.5% ASN-QWEST - Qwest
Communications Corporation
AS4766 1772 508 126471.3% KIXS-AS-KR Korea Telecom
AS17488 1523 368 115575.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4755 1210 233 97780.7% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS22773 1007 61 94693.9% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS1785 1785 903 88249.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS8151 1479 603 87659.2% Uninet S.A. de C.V.
AS8452 1084 255 82976.5% TEDATA TEDATA
AS11492 1212 472 74061.1% CABLEONE - CABLE ONE, INC.
AS19262 953 244 70974.4% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS18566 1061 466 59556.1% COVAD - Covad Communications
Co.
AS18101 753 168 58577.7% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS3356 1142 559 58351.1% LEVEL3 Level 3 Communications
AS6478 1235 675 56045.3% ATT-INTERNET3 - ATT WorldNet
Services
AS7545 736 187 54974.6% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS2706 550 43 50792.2% HKSUPER-HK-AP Pacific Internet
(Hong Kong) Limited
AS22047 619 116 50381.3% VTR BANDA ANCHA S.A.
AS17908 604 111 49381.6% TCISL Tata Communications
AS4808 616 156 46074.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS855605 146 45975.9% CANET-ASN-4 - Bell Aliant
AS7018 1439 995 44430.9% ATT-INTERNET4 - ATT WorldNet
Services
AS24560 671 242 42963.9% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS4134 904 477 42747.2% CHINANET-BACKBONE
No.31,Jin-rong Street
AS10620 747 322 42556.9% TV Cable S.A.
AS4668 701 284 41759.5% LGNET-AS-KR LG CNS
AS7011 966 554 41242.7% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS9443 504 92 41281.7% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS17676 527 116 41178.0% GIGAINFRA BB TECHNOLOGY
BGP Update Report
BGP Update Report Interval: 12-Jan-09 -to- 12-Feb-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9583 187305 4.3% 125.8 -- SIFY-AS-IN Sify Limited 2 - AS7643 167261 3.8% 285.9 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - AS662949189 1.1% 756.8 -- NOAA-AS - NOAA 4 - AS30890 48137 1.1% 109.2 -- EVOLVA Evolva Telecom 5 - AS35805 41565 0.9% 110.0 -- UTG-AS United Telecom AS 6 - AS14420 31055 0.7% 123.2 -- ANDINATEL S.A. 7 - AS645828143 0.6% 58.3 -- Telgua 8 - AS30306 25107 0.6%6276.8 -- AfOL-Sz-AS 9 - AS505024109 0.6% 408.6 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - AS845222589 0.5% 14.9 -- TEDATA TEDATA 11 - AS12500 21936 0.5%5484.0 -- RCS-AS RCS Autonomus System 12 - AS27757 21928 0.5% 160.1 -- ANDINATEL S.A. 13 - AS20115 21136 0.5% 10.2 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS30969 20102 0.5%2512.8 -- TAN-NET TransAfrica Networks 15 - AS638919952 0.5% 4.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 16 - AS23966 19602 0.5% 53.7 -- LDN-AS-AP LINKdotNET Telecom Limited 17 - AS33783 19399 0.4% 122.8 -- EEPAD 18 - AS815119180 0.4% 12.8 -- Uninet S.A. de C.V. 19 - AS21433 18998 0.4% 146.1 -- ACCENTUREFSSC Accenture London Delivery Centre 20 - AS209 18203 0.4% 6.3 -- ASN-QWEST - Qwest Communications Corporation TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS302877838 0.2%7838.0 -- ALON-USA - ALON USA, LP 2 - AS30306 25107 0.6%6276.8 -- AfOL-Sz-AS 3 - AS12500 21936 0.5%5484.0 -- RCS-AS RCS Autonomus System 4 - AS413823264 0.1%3264.0 -- TELEPORT-AS Teleport LLC Network AS 5 - AS30969 20102 0.5%2512.8 -- TAN-NET TransAfrica Networks 6 - AS281947118 0.2%2372.7 -- 7 - AS239172237 0.1%2237.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 8 - AS190172085 0.1%2085.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 9 - AS503316305 0.4%1811.7 -- ISW - Internet Specialties West Inc. 10 - AS108066266 0.1%1566.5 -- AFP-NET - AGENCE FRANCE PRESSE 11 - AS16559 15253 0.3%1525.3 -- REALCONNECT-01 - RealConnect, Inc 12 - AS294272706 0.1%1353.0 -- AZM-AS Mercury Telecom 13 - AS451221318 0.0%1318.0 -- JASPACE-AS-ID-AP PT. JASPACE NET 14 - AS32398 11831 0.3%1314.6 -- REALNET-ASN-1 15 - AS300952584 0.1%1292.0 -- AS-30095 - Group M Worldwide, Inc. 16 - AS481291268 0.0%1268.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 17 - AS259707548 0.2%1258.0 -- IAC - IAC Services LLC 18 - AS44265 13244 0.3%1204.0 -- SMOLTELECOM-NET Smoltelecom Ltd AS peering 19 - AS292242402 0.1%1201.0 -- HELLMANN Hellmann Worldwide Logistics GmbH Co KG 20 - AS353351123 0.0%1123.0 -- ESSTU-AS East-Siberian State Technological University AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/2423883 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 144.36.245.0/24 16897 0.3% AS21433 -- ACCENTUREFSSC Accenture London Delivery Centre 3 - 192.35.129.0/24 16468 0.3% AS6629 -- NOAA-AS - NOAA 4 - 192.102.88.0/24 16325 0.3% AS6629 -- NOAA-AS - NOAA 5 - 64.162.116.0/24 16281 0.3% AS5033 -- ISW - Internet Specialties West Inc. 6 - 198.77.177.0/24 16198 0.3% AS6629 -- NOAA-AS - NOAA 7 - 221.134.32.0/24 13957 0.3% AS9583 -- SIFY-AS-IN Sify Limited 8 - 221.135.80.0/24 12943 0.3% AS9583 -- SIFY-AS-IN Sify Limited 9 - 190.152.103.0/24 12748 0.3% AS27757 -- ANDINATEL S.A. 10 - 210.214.151.0/24 12729 0.3% AS9583 -- SIFY-AS-IN Sify Limited 11 - 212.85.223.0/24 12392 0.3% AS30306 -- AfOL-Sz-AS 12 - 212.85.220.0/24 12363 0.3% AS30306 -- AfOL-Sz-AS 13 - 41.204.2.0/24 11684 0.2% AS32398 -- REALNET-ASN-1 14 - 124.7.201.0/2411454 0.2% AS9583 -- SIFY-AS-IN Sify Limited 15 - 222.255.51.64/26 10848 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - 192.12.120.0/24 10058 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 17 - 196.27.104.0/219856 0.2% AS30969 -- TAN-NET TransAfrica Networks 18 - 196.27.108.0/229795 0.2% AS30969 -- TAN-NET TransAfrica Networks 19 - 221.135.107.0/24 8910 0.2% AS9583 -- SIFY-AS-IN Sify Limited 20 - 210.214.222.0/24 8839 0.2% AS9583 -- SIFY-AS-IN Sify
Re: Global Blackhole Service
On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG j@plusserver.de wrote: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Ah. rbl.maps.vix.com from about a decade back when it was available as a bgp feed. But only for ddos sources. srs
Re: Global Blackhole Service
would this itself not be a dos path? randy
Re: Global Blackhole Service
In that way, Spamcop and other folks are DOS'ing for years aswell. And in fact, by denying things around, they are just scrubing and filtering, to make our day happier, avoiding huge masses of spam and useless crap. I don't see it the way you do. A project like this, like also spamcop, are great paths to take out the scum and undesired things from the net. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Randy Bush ra...@psg.com wrote: would this itself not be a dos path? randy
Re: Global Blackhole Service
Hi Suresh, But in the meanwhile, a decade later, it does not longer exist. At least, i can't reach that host, and i was unable to find working documentation on google of how about this project works, today. In fact, the first link that google gave out, says that this project is dead at least 2 years ago. http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html I think that we all have a real opportunity here for make something that can be useful to all. And, we are not talk of spam here, but, to mitigate time, money and patience consuming DDoS attacks, which often are easier to mitigate only at the Source and at the Destination, while at Destinatation, sink is the only viable solution that is out there today. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Suresh Ramasubramanian ops.li...@gmail.com wrote: On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG j@plusserver.de wrote: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Ah. rbl.maps.vix.com from about a decade back when it was available as a bgp feed. But only for ddos sources. srs
Re: Global Blackhole Service
On Fri, 13 Feb 2009 15:57:32 +0100, Jens Ott - PlusServer AG said: Therefore I had the following idea: Why not taking one of my old routers and set it up as blackhole-service. Then everyone who is interested could set up a session to there and 1.) announce /32 (/128) routes out of his prefixes to blackhole them 2.) receive all the /32 (/128) announcements from the other peers with the IPs they want to have blackholed and rollout the blackhole to their network. How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. You usually don't *have* a similar luxury if you're trying to deal with a DDoS, because those are essentially a real-time issue. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away... pgpbpAddW2Wfu.pgp Description: PGP signature
Re: Global Blackhole Service
DDoS drones - especially with botnets - can produce a really large zone To start with google spamhaus drop list. Then look at the cbl and see if you think its worth using as a bgp feed On Fri, Feb 13, 2009 at 9:20 PM, Nuno Vieira - nfsi telecom nuno.vie...@nfsi.pt wrote: Hi Suresh, But in the meanwhile, a decade later, it does not longer exist. At least, i can't reach that host, and i was unable to find working documentation on google of how about this project works, today. In fact, the first link that google gave out, says that this project is dead at least 2 years ago. http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html I think that we all have a real opportunity here for make something that can be useful to all. And, we are not talk of spam here, but, to mitigate time, money and patience consuming DDoS attacks, which often are easier to mitigate only at the Source and at the Destination, while at Destinatation, sink is the only viable solution that is out there today. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Suresh Ramasubramanian ops.li...@gmail.com wrote: On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG j@plusserver.de wrote: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Ah. rbl.maps.vix.com from about a decade back when it was available as a bgp feed. But only for ddos sources. srs -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Global Blackhole Service
valdis.kletni...@vt.edu wrote: How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. Presumably, the route server would have to have the same guidelines as issued by service providers. ie, /32 networks injected should come from authenticated feeds and fall within the netblock range owned by the injector. So one extra set of ACL's for each injector to upkeep. I believe what is being suggested is just one step beyond what many providers give to BGP customers to extend blackholes out. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away... This also would be decided by the injecting provider. More of a Hey, one of my IPs is being DDOS'd, please drop traffic to it to protect the rest of my network. The downside to widespread use, is that it makes tracking the problem on the other side of the blocks near impossible. In all cases, once a blackhole is initiated anywhere, the DDOS has been successful. We use automatic community changes to accept /32 blackholes from customers, verify them, then send them on to peers that also support /32 blackholes with appropriate communities. Jack Jack
Re: Global Blackhole Service
Ok, however, what i am talking about is a competelly diferent thing, and i think that my thoughts are alligned with Jens. We want to have a Sink-BGP-BL, based on Destination. Imagine, i as an ISP, host a particular server that is getting nn Gbps of DDoS attack. I null route it, and start advertising a /32 to my upstream providers with a community attached, for them to null route it at their network. However, the attacks continue going, on and on, often flooding internet exchange connections and so. A solution like this, widelly used, would prevent packets to leave their home network, mitigating with effective any kind of DDoS (or packet flooding). Obviously, we need a few people to build this (A Website, an organization), where when a new ISP connects is added to the system, a prefix list should be implemented, preventing that ISP to announce IP addresses that DON'T belong to him. The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, and those member ISP's, should apply route-maps or whatever they want, but, in the end they want to discard the traffic to those prefixes (ex: Null0 or /dev/null). This is a matter or getting enough people to kick this off, to build a website, to establish one or two route-servers and to give use to. Once again, i am interested on this, if others are aswell, let know. This should be a community-driven project. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Valdis Kletnieks valdis.kletni...@vt.edu wrote: How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. You usually don't *have* a similar luxury if you're trying to deal with a DDoS, because those are essentially a real-time issue. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away...
Re: Global Blackhole Service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Skywing schrieb: Of course, whomever hosts such a service becomes an attractive DoS target themselves if it were ever to gain real traction in the field. There is also the reverse-DoS issue of an innocent party getting into the feed if anyone can peer with it. You are right, and that's also what I am currently thinking about. Well, one solution might be, that all participants blackhole-routers IPs are also announced with some special community and all participants drop all traffic but bgp traffic from IPs listed with that community to the blackhole RR destination(s) everywhere in there network. BR Jens - S -Original Message- From: Nuno Vieira - nfsi telecom nuno.vie...@nfsi.pt Sent: Friday, February 13, 2009 07:13 To: Jens Ott - PlusServer AG j@plusserver.de Cc: nanog nanog@nanog.org Subject: Re: Global Blackhole Service Hi Jens, I think we are in the same boat. We suffered the same problem often, on a lower magnitude, but if a project like this exists those DDoS could even be almost near zero. This is somewhat similar to what Spamcop, and other folks do with SPAM today, but applied on a diferent scope, say, BGP Blackhole. This service can span wide after just peers, opening the opportunity to edge-to-edge DDoS mitigation. Say, a network in .pt or .de is beign attacked at large, and dst operators inject the dst attacked source on the blackhole bgp feed... say that 100+ other ops around the world use a cenário like this... this might be very useful. concers: the autohority or the responsible for maintaining this project, must assure that OP A or OP B can *only* annouce chunks that below to him, avoiding any case of hijack. We would be interested in participating in something like this. So, My questions to all of you: - - What do you think about such service? It will be great. We are available to help. - - Would you/your ASN participate in such a service? Yes. - - Do you see some kind of usefull feature in such a service? Yes, a few thoughts above, some more might come up. - - Do you have any comments? For starters, a few above. Regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Jens Ott - PlusServer AG j@plusserver.de wrote: Hi, in the last 24 hours we received two denial of service attacks with something like 6-8GBit volume. It did not harm us too much, but e.g. one of our upstreams got his Amsix-Port exploded. With our upstreams we have remote-blackhole sessions running where we announce /32 prefixes to blackhole at their edge, but this does not work with our peers. Also our Decix-Port received something like 2Gbit extra-traffic during this DoS. I can imagine, that for some peers, especially for the once having only a thin fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with a DoS and that they might be interested in dropping such traffic at their edge. Well I could discuss with my peers (at least the once who might get in trouble with such issue) to do some individual config for some blackhole-announcement, but most probably I'm not the only one receiving DoS and who would be interested in such setup. Therefore I had the following idea: Why not taking one of my old routers and set it up as blackhole-service. Then everyone who is interested could set up a session to there and 1.) announce /32 (/128) routes out of his prefixes to blackhole them 2.) receive all the /32 (/128) announcements from the other peers with the IPs they want to have blackholed and rollout the blackhole to their network. My questions to all of you: - What do you think about such service? - Would you/your ASN participate in such a service? - Do you see some kind of usefull feature in such a service? - Do you have any comments? Thank you for telling me your opinions and best regards - -- === Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j@plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVqvwACgkQMf0yjMLKfXp1OgCfcvTgueonvW4z0dOash9KWUb0 pjMAniZprPAM14H477EHy4I0Ccd9nqy4 =EH0/ -END PGP SIGNATURE-
Re: Global Blackhole Service
On Fri, 13 Feb 2009 16:41:41 + (WET) Nuno Vieira - nfsi telecom nuno.vie...@nfsi.pt wrote: Ok, however, what i am talking about is a competelly diferent thing, and i think that my thoughts are alligned with Jens. We want to have a Sink-BGP-BL, based on Destination. Imagine, i as an ISP, host a particular server that is getting nn Gbps of DDoS attack. I null route it, and start advertising a /32 to my upstream providers with a community attached, for them to null route it at their network. However, the attacks continue going, on and on, often flooding internet exchange connections and so. A solution like this, widelly used, would prevent packets to leave their home network, mitigating with effective any kind of DDoS (or packet flooding). Obviously, we need a few people to build this (A Website, an organization), where when a new ISP connects is added to the system, a prefix list should be implemented, preventing that ISP to announce IP addresses that DON'T belong to him. The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, and those member ISP's, should apply route-maps or whatever they want, but, in the end they want to discard the traffic to those prefixes (ex: Null0 or /dev/null). This is a matter or getting enough people to kick this off, to build a website, to establish one or two route-servers and to give use to. Once again, i am interested on this, if others are aswell, let know. This should be a community-driven project. In other words, a legitimate prefix hijacking service... As Randy and Valdis have pointed out, if this isn't done very carefully it's an open invitation to a new, very effective DoS technique. You can't do this without authoritative knowledge of exactly who owns any prefix; you also have to be able to authenticate the request to blackhole it. Those two points are *hard*. I also note that the scheme as described here is incompatible with more or less any possible secured BGP, since by definition it involves an AS that doesn't own a prefix advertising a route to it. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Global Blackhole Service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 @jack: sorry for duplicate ... pressed reply instead of reply-all ;) Jack Bates schrieb: valdis.kletni...@vt.edu wrote: Presumably, the route server would have to have the same guidelines as issued by service providers. ie, /32 networks injected should come from authenticated feeds and fall within the netblock range owned by the injector. So one extra set of ACL's for each injector to upkeep. I believe what is being suggested is just one step beyond what many providers give to BGP customers to extend blackholes out. Exactly that's the way I intended. I know that it's a not to small thing to maintain such a system, we are running it successfully for years with both, downstream-bgp-customers and upstreams. Even with quiet a small number of downstreams there are several changes each month (new IP-Space, drop-off of PI moved away from the customer ...), but I think it would be a manageable thing to keep it up2date when preparing some automatism. E.g. a automated prefix-list-generator requesting the authorization (e.g. automated mail with link including authorization-hash) for blackholing at the AS-Owner before accepting prefixes ... Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away... This also would be decided by the injecting provider. More of a Hey, one of my IPs is being DDOS'd, please drop traffic to it to protect the rest of my network. The downside to widespread use, is that it makes tracking the problem on the other side of the blocks near impossible. In all cases, once a blackhole is initiated anywhere, the DDOS has been successful. Well, for that single IP the DDoS was sucessfull, but looking at the issue I had yesterday, it's to protect other customers also getting into trouble due to this DoS. The complete rack had 1GBit-Uplink, which is normally absolutely sufficient for 20 servers. Well one single server was under attack, but 19 other innocent customers were not reachable. And, the even bigger problem was, the AMSIX-Port of one of my upstreams was filled to death due to this DoS and therefore several thousand customers had enormous packetloss due to one single destination-ip. Therefore it's to decide what to prefer, one single customer dead or thousands of angry customers. And I know that I prefer to protect my own backbone under these circumstances. We use automatic community changes to accept /32 blackholes from customers, verify them, then send them on to peers that also support /32 blackholes with appropriate communities. That's what we currently also do and until now we never had any problem with this. BR Jens Jack Jack - -- === Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j@plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVq0gACgkQMf0yjMLKfXqq+QCfW7FzEeXE8MsN3DJQcn8B/ezE EIwAoJttNgusWNFu+ebOswIBw0g6734w =5x5v -END PGP SIGNATURE-
Re: Global Blackhole Service
Paul Vixie wrote: i think Spamhaus and Cymru are way ahead of you in implementing such a thing, and it's likely that there are even commercial alternatives to Trend Micro although i have not kept up on those details. I think there's a misunderstanding from what I've read about what is being blackholed. We are not talking about blackholing the senders, but a massive scale method of blackholing the victims at the victim's request to protect infrastructure. Currently this type of service usually doesn't extend beyond one or two ASs and depending on traffic flows can still cause damage, especially through exchange points. With enough support and use, this would allow a larger portion of bad traffic to be null routed closer to the sender origination points. Since the null routing BGP servers would expect a larger routing table from these /32 networks, they would be placed at key points capable of handling the larger tables; compared to just allowing the /32's out into the wild and possibly exceeding route/memory constraints. It can also be used as authoritative information that an IP is undergoing a DOS attack, and large volumes of connections to that IP should be considered suspect. I consider this a much more useful method of detecting DOS traffic leaving your infected users than the emails which are usually sent out by those being hit by DOS. Jack
Re: Global Blackhole Service
Jens, I would be interested in participating with a destination blackhole service, so long as peers were authenticated and only authorized to advertise /32s out of space that they are assigned -- hopefully the same OrgID is used for the ASN as the IP allocations. However, a blackhole service based on sources would be out of the question altogether in my book, unless paired with a number of third parties that could vet the badness of those source IPs, as is done with spam zombies. Even then I'd be very nervous about it from a causes more [potential] problems than it fixes standpoint, no matter how cool it would be to defang a DDoS. As for the memory requirements / oh no! too many routes! issue, that would be a non-issue for me. Feel free to contact me off-list if you're serious about starting this project. I think that it would be worth it to talk to the Team Cymru guys to see if they'd be interested in this. -Tico Jens Ott - PlusServer AG wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in the last 24 hours we received two denial of service attacks with something like 6-8GBit volume. It did not harm us too much, but e.g. one of our upstreams got his Amsix-Port exploded. With our upstreams we have remote-blackhole sessions running where we announce /32 prefixes to blackhole at their edge, but this does not work with our peers. Also our Decix-Port received something like 2Gbit extra-traffic during this DoS. I can imagine, that for some peers, especially for the once having only a thin fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with a DoS and that they might be interested in dropping such traffic at their edge. Well I could discuss with my peers (at least the once who might get in trouble with such issue) to do some individual config for some blackhole-announcement, but most probably I'm not the only one receiving DoS and who would be interested in such setup. Therefore I had the following idea: Why not taking one of my old routers and set it up as blackhole-service. Then everyone who is interested could set up a session to there and 1.) announce /32 (/128) routes out of his prefixes to blackhole them 2.) receive all the /32 (/128) announcements from the other peers with the IPs they want to have blackholed and rollout the blackhole to their network. My questions to all of you: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Thank you for telling me your opinions and best regards - -- === Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j@plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVilwACgkQMf0yjMLKfXpNuQCeKcicthIadISe7I+Xs5ZNHS+1 0qUAnRDkOY9/6kokq3Hf68BRQFfkP3xy =jKUA -END PGP SIGNATURE-
Re: Global Blackhole Service
blackholing victims is an interesting economics proposition. you're saying the attacker must always win but that they must not be allowed to affect the infrastructure. and you're saying victims will request this, since they know they can't withstand the attack and don't want to be held responsible for damage to the infrastructure. where you lose me is where the attacker must always win.
Re: Global Blackhole Service
Listen online to my favorite hip hop radio station http://www.Jellyradio.com On Feb 13, 2009, at 9:35 AM, Paul Vixie vi...@isc.org wrote: blackholing victims is an interesting economics proposition. you're saying the attacker must always win but that they must not be allowed to affect the infrastructure. and you're saying victims will request this, since they know they can't withstand the attack and don't want to be held responsible for damage to the infrastructure. where you lose me is where the attacker must always win. Perhaps removing the challenge from the attacker will bore them and they lose interest? However if an attackers goal is to put someone out of business, they will keep it up until the deed is done. Identifying the attacker is important. They must be the one who is in trouble, not the victim. We have seen attackers extorting customers for money with things like 100k wired to Nevis bank account or attack continues. In any case I do not believe a victim should be responsible for infrastructure damage caused by some random criminal attacking them. While I understand that it's that customer receiving the attack; the providers must work with the customer to trace it back to the source. A hacker who thinks the customer is on a security weak provider will return seeking your other customers. However if the hacker feels you are security savvy then he may choose another target. Everyone wins. Also, rather than penalize the victim for damage, you could always unplug them to interdict the damage. By going after the hacker, you could prosecute and perhaps gain some nice press/media about the strength of your orginization as a side dish to the satisfying meal of eating your enemy?
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 bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 14 Feb, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 279513 Prefixes after maximum aggregation: 133074 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 136951 Total ASes present in the Internet Routing Table: 30575 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26606 Origin ASes announcing only one prefix: 12952 Transit ASes present in the Internet Routing Table:3969 Transit-only ASes present in the Internet Routing Table: 93 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 530 Unregistered ASNs in the Routing Table: 181 Number of 32-bit ASNs allocated by the RIRs:100 Prefixes from 32-bit ASNs in the Routing Table: 15 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:229 Number of addresses announced to Internet: 2001869152 Equivalent to 119 /8s, 82 /16s and 25 /24s Percentage of available address space announced: 54.0 Percentage of allocated address space announced: 63.2 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 75.7 Total number of prefixes smaller than registry allocations: 137208 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:64538 Total APNIC prefixes after maximum aggregation: 23028 APNIC Deaggregation factor:2.80 Prefixes being announced from the APNIC address blocks: 61376 Unique aggregates announced from the APNIC address blocks:27784 APNIC Region origin ASes present in the Internet Routing Table:3532 APNIC Prefixes per ASN: 17.38 APNIC Region origin ASes announcing only one prefix:955 APNIC Region transit ASes present in the Internet Routing Table:550 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 401272544 Equivalent to 23 /8s, 234 /16s and 238 /24s Percentage of available APNIC address space announced: 79.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:123310 Total ARIN prefixes after maximum aggregation:65208 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks:92830 Unique aggregates announced from the ARIN address blocks: 35508 ARIN Region origin ASes present in the Internet Routing Table:12768 ARIN Prefixes per ASN: 7.27 ARIN Region origin ASes announcing only one prefix:4910 ARIN Region transit ASes present in the Internet Routing Table:1219 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 414191136 Equivalent to 24 /8s, 176 /16s and 14 /24s Percentage of available ARIN address space announced: 79.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772,
Re: Global Blackhole Service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jack Bates schrieb: Paul Vixie wrote: Do you have a miraculous way to stop DDOS? Is there now a way to quickly and efficiently track down forged packets? Is there a remedy to shutting down the *known* botnets, not to mention the unknown ones? This is another issue, and _all_ of us are in charge to keep their net clean from outgoing DoS. Most outgoing DoS inside our network are mitigated - ok most of the time the dos'ing server is being disconnected - in less than 10 minutes, as we do not only check what's coming in, but also check what our customers are sending out. And as soon as someone forges IPs, he's disconnected unless we know what was happening (mostly hacked servers) and the issue was fixed. As it is the nature of DoS that there are lots of packets send, they can easily be identified in (s|c|net)flows ... unfortunately there are _lots_ of ISP not having automated mechanism for misuse-detection and mitigation, or if they have some, they don't care about alarms. Therefore I agree, the only practicable way to protect the majority of customers is to blackhole the IP under attack. Even if the DoS is not DDoS, but coming from one single source... 99,9% of any emails to any NOC worldwide is not being answered in less than one hour (especially in out-shift-hours) and from the 0.1% left I bet 99,9% of the DoS are also not stopped during this hour. And one hour of DoS may make some small ISP loose more money then they earn per month! While all this is worked out, we have one solution we know works. If we null route the victim IP, the traffic stops at the null route. Since most attackers don't care to DOS the ISP, but just to take care of that end point, they usually don't start shifting targets to try and keep the ISP itself out. ACK! Jack - -- === Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j@plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVv5EACgkQMf0yjMLKfXptpQCeNNgDOxXWoTBHA5W5yCwifcG2 IasAnAh06DE3qry/puXzBs05pBfIMSS/ =boMf -END PGP SIGNATURE-
TeliaSonera AS1299
Hello, If anyone from TeliaSonera is around please contact me off-list Thanks German pgptdISWjhXk2.pgp Description: PGP signature
Dark Fiber in Parker Arizona
I am in need of dark fiber in the Parker, Arizona area. If anyone can help please contact me off list. Thanks, David
Re: Global Blackhole Service
On Fri, Feb 13, 2009 at 1:04 PM, Jack Bates jba...@brightok.net wrote: Paul Vixie wrote: blackholing victims is an interesting economics proposition. you're saying the attacker must always win but that they must not be allowed to affect the infrastructure. and you're saying victims will request this, since they know they can't withstand the attack and don't want to be held responsible for damage to the infrastructure. Blackholing victims is what is current practice. For each stage of affected it is A current practice.. so is filtering, so is scrubbing... there is no one answer for this. infrastructure, the business/provider will make requests to their peers to blackhole the victim IP to protect the bandwidth caps or router throughput caps. or cause no one really cares about: your.mama.wears.combat.boots.tobed.com ... or other silly 95%-of attacked, things. where you lose me is where the attacker must always win. Do you have a miraculous way to stop DDOS? Is there now a way to quickly and There are purchasable answers to this problem... 3 (at least) providers in the US (and at least one now offers it globally) offer traffic scrubbing services. I know that one offers it at a very reasonable price even... efficiently track down forged packets? Is there a remedy to shutting down you can track streams of forged packets, but that's not super important here. Forged packets actually make this part of the problem (stopping the dos) easier, not harder. the *known* botnets, not to mention the unknown ones? there are lots of folks tracking and shutting down botnets, it's not horribly effective in stopping this sort of thing. I can vividly recall tracking down 4 nights in a row the same 'botnet' (same controller person, different CC and mostly different bots) as they were being used to attack a customer of mine at the time. This with the cooperation of 2 other very large ISP's in the US and one vendor security team even. In the end though a simple scrubbing solution was deemed the simplest answer for all involved. The attacker will always win if he has a large enough attack For extreme cases this is true, but there are quite a lot of things on the spectrum which don't require super human efforts, and don't even require intervention from the ISP if proper precautions are taken at the outset. -chris
RE: Global Blackhole Service
I think this solution addresses a number of issues that the current blackhole process lacks. Generally when a blackhole is sent to your provider, they in turn pass that on to the rest of their routers, dropping the traffic as soon as it hits their network. The traffic is still taking up just as much capacity up to that point. Were a system implemented as discussed, providers are able to prevent traffic that is known to be malicious from even exiting their network, which in the end works out better for everyone. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Friday, February 13, 2009 1:59 PM To: NANOG list Subject: Re: Global Blackhole Service On Fri, Feb 13, 2009 at 1:04 PM, Jack Bates jba...@brightok.net wrote: Paul Vixie wrote: blackholing victims is an interesting economics proposition. you're saying the attacker must always win but that they must not be allowed to affect the infrastructure. and you're saying victims will request this, since they know they can't withstand the attack and don't want to be held responsible for damage to the infrastructure. Blackholing victims is what is current practice. For each stage of affected it is A current practice.. so is filtering, so is scrubbing... there is no one answer for this. infrastructure, the business/provider will make requests to their peers to blackhole the victim IP to protect the bandwidth caps or router throughput caps. or cause no one really cares about: your.mama.wears.combat.boots.tobed.com ... or other silly 95%-of attacked, things. where you lose me is where the attacker must always win. Do you have a miraculous way to stop DDOS? Is there now a way to quickly and There are purchasable answers to this problem... 3 (at least) providers in the US (and at least one now offers it globally) offer traffic scrubbing services. I know that one offers it at a very reasonable price even... efficiently track down forged packets? Is there a remedy to shutting down you can track streams of forged packets, but that's not super important here. Forged packets actually make this part of the problem (stopping the dos) easier, not harder. the *known* botnets, not to mention the unknown ones? there are lots of folks tracking and shutting down botnets, it's not horribly effective in stopping this sort of thing. I can vividly recall tracking down 4 nights in a row the same 'botnet' (same controller person, different CC and mostly different bots) as they were being used to attack a customer of mine at the time. This with the cooperation of 2 other very large ISP's in the US and one vendor security team even. In the end though a simple scrubbing solution was deemed the simplest answer for all involved. The attacker will always win if he has a large enough attack For extreme cases this is true, but there are quite a lot of things on the spectrum which don't require super human efforts, and don't even require intervention from the ISP if proper precautions are taken at the outset. -chris
Re: One /22 Two ISP no BGP
Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=142.217.0.0submit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=204.144.60.0submit=Go What can we do now ? Any suggestions ? Charles
anyone knows about extreme switch
Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/
RE: One /22 Two ISP no BGP
I see multiple paths to that block all converge at bell.ca. I don't see a route with 35911 (telebec) in the AS_PATH, unless it is start-of-string and followed by _577_ (bell.ca). They seem to be consistent... -Original Message- From: Charles Regan [mailto:charles.re...@gmail.com] Sent: Friday, February 13, 2009 3:23 PM To: nanog@nanog.org Subject: Re: One /22 Two ISP no BGP Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=142.217.0.0; s ubmit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=204.144.60.0 submit=Go What can we do now ? Any suggestions ? Charles
RE: One /22 Two ISP no BGP
Telebec's only upstream is Bell Canada (AS577) hence why you see that...;) Paul -Original Message- From: Michael Smith [mailto:msm...@internap.com] Sent: Friday, February 13, 2009 3:34 PM To: Charles Regan; nanog@nanog.org Subject: RE: One /22 Two ISP no BGP I see multiple paths to that block all converge at bell.ca. I don't see a route with 35911 (telebec) in the AS_PATH, unless it is start-of-string and followed by _577_ (bell.ca). They seem to be consistent... -Original Message- From: Charles Regan [mailto:charles.re...@gmail.com] Sent: Friday, February 13, 2009 3:23 PM To: nanog@nanog.org Subject: Re: One /22 Two ISP no BGP Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=142.217.0.0; s ubmit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=204.144.60.0 submit=Go What can we do now ? Any suggestions ? Charles The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Global Blackhole Service
* Valdis Kletnieks: On Fri, 13 Feb 2009 15:57:32 +0100, Jens Ott - PlusServer AG said: Therefore I had the following idea: Why not taking one of my old routers and set it up as blackhole-service. Then everyone who is interested could set up a session to there and 1.) announce /32 (/128) routes out of his prefixes to blackhole them 2.) receive all the /32 (/128) announcements from the other peers with the IPs they want to have blackholed and rollout the blackhole to their network. How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? The same way you prevent rogue announcements. 8-/ I guess an IX would be able to perform some validation of blacklisting requests, or at least provide a contractual framework. I don't think a global solution exists (beyond the use my route server approach, which is quite global--until there are two of them).
Re: One /22 Two ISP no BGP
Charles Regan wrote: Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=142.217.0.0submit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=204.144.60.0submit=Go What can we do now ? Any suggestions ? Do you know who is upstream of ISP2? We've established that Telebec is only connected to Bell Canada. If ISP2 also has a connection to Bell then you don't gain anything with Telebec except this huge mess and horrible hacks to work around their lack of BGP. ~Seth
RE: anyone knows about extreme switch
We use Extreme products, but use telnet or SSH behind firewall. Can you use telnet? It provide more flexibility, but SSH is more secure Regardless of the connection the CLI configuration is the same. HyperTerminal setting? Baud rate-9600 Data bits-8 Stop bit-1 Parity-None Flow control-XON/XOFF Cable: Null-Modem RS-232 (9 pin to 25 pin) Good luck! --Louis -Original Message- From: ann kok [mailto:oiyan...@yahoo.ca] Sent: Friday, February 13, 2009 3:31 PM To: nanog@nanog.org Subject: anyone knows about extreme switch Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/
RE: One /22 Two ISP no BGP
That was my implication... -Original Message- From: Paul Stewart [mailto:pstew...@nexicomgroup.net] Sent: Friday, February 13, 2009 3:50 PM To: Michael Smith; Charles Regan; nanog@nanog.org Subject: RE: One /22 Two ISP no BGP Telebec's only upstream is Bell Canada (AS577) hence why you see that...;) Paul -Original Message- From: Michael Smith [mailto:msm...@internap.com] Sent: Friday, February 13, 2009 3:34 PM To: Charles Regan; nanog@nanog.org Subject: RE: One /22 Two ISP no BGP I see multiple paths to that block all converge at bell.ca. I don't see a route with 35911 (telebec) in the AS_PATH, unless it is start-of-string and followed by _577_ (bell.ca). They seem to be consistent... -Original Message- From: Charles Regan [mailto:charles.re...@gmail.com] Sent: Friday, February 13, 2009 3:23 PM To: nanog@nanog.org Subject: Re: One /22 Two ISP no BGP Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=142.217.0.0 s ubmit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=204.144.60. 0 submit=Go What can we do now ? Any suggestions ? Charles --- - The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Global Blackhole Service
eventually, the rpki will give you the first half, authentication of the owner of the ip space. this leaves, as smb hinted, securing the request path from the black-hole requestor to the service and of the service to the users. smb: You can't do this without authoritative knowledge of exactly who owns any prefix; you also have to be able to authenticate the request to blackhole it. Those two points are *hard*. randy
RE: anyone knows about extreme switch
Thank you it works properly Do you know the default pw? Thank you again --- On Fri, 2/13/09, LEdouard Louis ledou...@edrnet.com wrote: From: LEdouard Louis ledou...@edrnet.com Subject: RE: anyone knows about extreme switch To: oiyan...@yahoo.ca, nanog@nanog.org Received: Friday, February 13, 2009, 4:11 PM We use Extreme products, but use telnet or SSH behind firewall. Can you use telnet? It provide more flexibility, but SSH is more secure Regardless of the connection the CLI configuration is the same. HyperTerminal setting? Baud rate-9600 Data bits-8 Stop bit-1 Parity-None Flow control-XON/XOFF Cable: Null-Modem RS-232 (9 pin to 25 pin) Good luck! --Louis -Original Message- From: ann kok [mailto:oiyan...@yahoo.ca] Sent: Friday, February 13, 2009 3:31 PM To: nanog@nanog.org Subject: anyone knows about extreme switch Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ __ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/
RE: anyone knows about extreme switch
The default user name is admin and there is no password. --Louis -Original Message- From: ann kok [mailto:oiyan...@yahoo.ca] Sent: Friday, February 13, 2009 5:31 PM To: nanog@nanog.org; LEdouard Louis Subject: RE: anyone knows about extreme switch Thank you it works properly Do you know the default pw? Thank you again --- On Fri, 2/13/09, LEdouard Louis ledou...@edrnet.com wrote: From: LEdouard Louis ledou...@edrnet.com Subject: RE: anyone knows about extreme switch To: oiyan...@yahoo.ca, nanog@nanog.org Received: Friday, February 13, 2009, 4:11 PM We use Extreme products, but use telnet or SSH behind firewall. Can you use telnet? It provide more flexibility, but SSH is more secure Regardless of the connection the CLI configuration is the same. HyperTerminal setting? Baud rate-9600 Data bits-8 Stop bit-1 Parity-None Flow control-XON/XOFF Cable: Null-Modem RS-232 (9 pin to 25 pin) Good luck! --Louis -Original Message- From: ann kok [mailto:oiyan...@yahoo.ca] Sent: Friday, February 13, 2009 3:31 PM To: nanog@nanog.org Subject: anyone knows about extreme switch Hi I have old model extreme switch Anyone knows about hyperterminal setting. ls null modem cable same as HP serial cables? I try both cables in this switch and can see the boot information but keyboard is not responsing ! Thank you __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ __ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/
Re: Security Assessment of the Transmission Control Protocol (TCP)
Barry Shein wrote: And it was observed that routing around damage could at least in theory have utility in a situation where circuit facilities were being damaged in warfare so long as some route between two points remained. So these two goals are not mutually exclusive by any means. The point of the text was to point out that operating in warfare environments was not the top level goal. The recent John Day¿s Patterns in Network Architecture provides more insights in this aspec. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. This is a non-sequitar and not a result at all. Neither goal implied security, only integrity. This was not an oversight, security was, and to a great extent still is, thought to be a higher-level function than packetizing and packet routing, with a few exceptions where a potential security flaw truly lies in the protocol (e.g., poor choice of packet sequence numbers.) I don't really understand what you mean. Attacks such as syn-floods and others are clearly issues that lie in the protocol design. And while it is understood that security was not a goal two or three decades ago, one would expect that it should be a goal nowadays, and that the specs should have been updated accordingly. For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). (for some reason?) To the best of my knowledge the reason is quite simple: That is not what RFCs are used for tho occasionally some summary of the state of the art appears in an RFC. Not sure what you mean. Only *few* years ago there was some work published within the IETF about well-known issues such as, e.g., syn-floods. Think about any TCP/IP-based security issue, and most likely you will not be able to find any information about it within the RFC series. Talk with anybody that works day-to-day implementing the TCP/IP protocols, and most likely the comment you'll get about the current situation is a PITA. A few years ago I published an I-D on ICMP attacks against TCP (draft-ietf-tcpm-icmp-attacks, which is close to be published as an RFC, I believe). Known issues... but the counter-measures were not clear. The reult? Vulnerability advisories from many vendors, including Cisco, Microsoft, and the security-concious OpenBSD. I don't think it should be that hard to implement the protocols in a security-conscious way from the IETF specs. And that is the area in which this CPNI document (and the preivous Security Assessment of the Internet Protocol) tries to help. Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Chicago Sprint convulsions?
Is anyone else seeing convulsions via Sprint Chicago? Lightly loaded OC3 and we've got stuff all over the net seeing crazy latency. -- mailto:n...@layer3arts.com // GoogleTalk: nrauhau...@gmail.com IM: nealrauhauser
Re: One /22 Two ISP no BGP
The problem we have now is that we got our /22 from arin to do multihoming. If we dump tlb, no more multihoming? No /22. Is that correct? We also have a contract with tlb. $$$ 1.5yrs left... 2009/2/13, Seth Mattinen se...@rollernet.us: Charles Regan wrote: Isp2 is vtl not bell 2009/2/13, Seth Mattinen se...@rollernet.us: Charles Regan wrote: Just got final confirmation from ISP1 that they will not do BGP with us. ISP1 is Telebec. http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=142.217.0.0submit=Go My subnet http://www.iptools.com/dnstools.php?tool=ipwhoisuser_data=204.144.60.0submit=Go What can we do now ? Any suggestions ? Do you know who is upstream of ISP2? We've established that Telebec is only connected to Bell Canada. If ISP2 also has a connection to Bell then you don't gain anything with Telebec except this huge mess and horrible hacks to work around their lack of BGP. ~Seth Also, VTL peers with Sprint and SAVVIS. Based on this information I'd just drop Telebec completely. They only have one upstream. You won't get any redundancy with them since they're just giving you a connection to Bell, which VTL already gives you. Here's the view from my SAVVIS router with Sprint as the preferred path: routy-border0show ip bgp 216.113.0.0/17 BGP routing table entry for 216.113.0.0/17, version 78286019 Paths: (3 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 1239 5769, (received used) 208.79.242.129 (metric 3) from 208.79.242.129 (208.79.242.129) Origin IGP, metric 439, localpref 100, valid, internal, best Community: 11170:1239 3561 5769 216.88.158.93 from 216.88.158.93 (206.24.210.102) Origin IGP, localpref 90, valid, external Community: 3561:11840 11170:3561 3561 5769, (received-only) 216.88.158.93 from 216.88.158.93 (206.24.210.102) Origin IGP, localpref 90, valid, external Community: 3561:11840 -- Seth Mattinen se...@rollernet.us Roller Network LLC -- Envoyé avec mon mobile
Happy 1234567890 everyone!
Just in case you missed it. date -d Fri Feb 13 23:31:30 UTC 2009 +%s It's like a really geeky y2k without the potential cataclysm. :) Steve
Re: One /22 Two ISP no BGP
Charles Regan wrote: The problem we have now is that we got our /22 from arin to do multihoming. If we dump tlb, no more multihoming? No /22. Is that correct? We also have a contract with tlb. $$$ 1.5yrs left... There's something in there about non-multihomed sites, but I'm not familiar with it. Telebec doesn't appear to be multihomed, though. The only other thing I can think of to avoid horrible hackery is to convince them to colo a router for you to do eBGP to. Honestly, I wouldn't recommend multihoming *without* BGP. One day you'll end up with some really ugly failure mode. ~Seth
Re: Happy 1234567890 everyone!
You haven't lived until you've lived through an epoch. On Fri, Feb 13, 2009 at 06:54:54PM -0500, Ravi Pina wrote: On Fri, Feb 13, 2009 at 06:49:49PM -0500, Steve Church wrote: Just in case you missed it. date -d Fri Feb 13 23:31:30 UTC 2009 +%s It's like a really geeky y2k without the potential cataclysm. :) Steve Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19... ...by then I can only hope I am out of this profession. :) -r --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: One /22 Two ISP no BGP
And/or see if bell canada can sell you something diverse. - Original Message - From: Seth Mattinen se...@rollernet.us To: Charles Regan charles.re...@gmail.com Cc: nanog@nanog.org nanog@nanog.org Sent: Fri Feb 13 18:58:54 2009 Subject: Re: One /22 Two ISP no BGP Charles Regan wrote: The problem we have now is that we got our /22 from arin to do multihoming. If we dump tlb, no more multihoming? No /22. Is that correct? We also have a contract with tlb. $$$ 1.5yrs left... There's something in there about non-multihomed sites, but I'm not familiar with it. Telebec doesn't appear to be multihomed, though. The only other thing I can think of to avoid horrible hackery is to convince them to colo a router for you to do eBGP to. Honestly, I wouldn't recommend multihoming *without* BGP. One day you'll end up with some really ugly failure mode. ~Seth
Re: Happy 1234567890 everyone!
Once upon a time, Ravi Pina r...@cow.org said: Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19... Oddly enough, the end of the current Unix epoch is a prime. Not only that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest known Mersenne prime where its Mersenne number (31) is also a Mersenne prime (2^5 - 1). You can always count on numerology. This means something! -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Happy 1234567890 everyone!
Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? On Fri, Feb 13, 2009 at 8:03 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Ravi Pina r...@cow.org said: Yes... that is more like the y2k38 problem on 03:14:07 UTC 2038-01-19... Oddly enough, the end of the current Unix epoch is a prime. Not only that, it is a Mersenne prime, 2^31 - 1. Even more, it is the largest known Mersenne prime where its Mersenne number (31) is also a Mersenne prime (2^5 - 1). You can always count on numerology. This means something! -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Happy 1234567890 everyone!
Once upon a time, Nathan Malynn ne...@nerdramblingz.com said: Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? Unix/POSIX systems use time_t to store the base time counter, which is seconds since the epoch (1970-01-01 00:00:00 UTC). Most platforms still use a 32 bit time_t for compatibility. However, it does appear that at some point, 64 bit Linux systems switched to a 64 bit time_t, so I can only assume others are switching as well. Hopefully, the 32 bit systems (at least that have to count seconds) will be mostly gone in another 29 years. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Happy 1234567890 everyone!
On Fri, Feb 13, 2009 at 6:06 PM, Nathan Malynn ne...@nerdramblingz.com wrote: Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? Exactly! What are we going to do when we're at the end of the 2^64 epoch?? (after the sun burns out and.. oh wait) -- Eric http://nixwizard.net
Re: Global Blackhole Service
Nuno et all, Count me in for this.. Cheers, --Ricardo http://www.cs.ucla.edu/~rveloso On Feb 13, 2009, at 8:41 AM, Nuno Vieira - nfsi telecom wrote: Ok, however, what i am talking about is a competelly diferent thing, and i think that my thoughts are alligned with Jens. We want to have a Sink-BGP-BL, based on Destination. Imagine, i as an ISP, host a particular server that is getting nn Gbps of DDoS attack. I null route it, and start advertising a /32 to my upstream providers with a community attached, for them to null route it at their network. However, the attacks continue going, on and on, often flooding internet exchange connections and so. A solution like this, widelly used, would prevent packets to leave their home network, mitigating with effective any kind of DDoS (or packet flooding). Obviously, we need a few people to build this (A Website, an organization), where when a new ISP connects is added to the system, a prefix list should be implemented, preventing that ISP to announce IP addresses that DON'T belong to him. The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, and those member ISP's, should apply route-maps or whatever they want, but, in the end they want to discard the traffic to those prefixes (ex: Null0 or /dev/null). This is a matter or getting enough people to kick this off, to build a website, to establish one or two route-servers and to give use to. Once again, i am interested on this, if others are aswell, let know. This should be a community-driven project. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Valdis Kletnieks valdis.kletni...@vt.edu wrote: How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. You usually don't *have* a similar luxury if you're trying to deal with a DDoS, because those are essentially a real-time issue. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away...
Re: Happy 1234567890 everyone!
Once upon a time, Nathan Malynn ne...@nerdramblingz.com said: Question about 2k38: Aren't most Unixoid systems using 64-bit clocks now? Unix/POSIX systems use time_t to store the base time counter, which is seconds since the epoch (1970-01-01 00:00:00 UTC). Most platforms still use a 32 bit time_t for compatibility. However, it does appear that at some point, 64 bit Linux systems switched to a 64 bit time_t, so I can only assume others are switching as well. Hopefully, the 32 bit systems (at least that have to count seconds) will be mostly gone in another 29 years. FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted it wouldn't be a problem. Nowhere near as annoying a problem as the variability of the size of size_t. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Happy 1234567890 everyone!
Once upon a time, Joe Greco jgr...@ns.sol.net said: FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted it wouldn't be a problem. Tru64 on Alpha uses a 32 bit time_t (they have their own time64_t and time64() call), so I expect *BSD and Linux on Alpha stayed with 32 bit time_t for compatibility (Linux at least could run many Tru64 binaries). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Happy 1234567890 everyone!
On Fri, 13 Feb 2009 21:08:12 -0600 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Joe Greco jgr...@ns.sol.net said: FreeBSD used a 64-bit time_t for the AMD64 port pretty much right away. On the flip side, it used a 32-bit time_t for the Alpha port. I guess someone predicted it wouldn't be a problem. Tru64 on Alpha uses a 32 bit time_t (they have their own time64_t and time64() call), so I expect *BSD and Linux on Alpha stayed with 32 bit time_t for compatibility (Linux at least could run many Tru64 binaries). NetBSD has just converted its -current branch to 64-bit time_t; I'm pretty sure that that includes the Alpha port. --Steve Bellovin, http://www.cs.columbia.edu/~smb
