From roll at Stupi.SE Thu Jan 1 01:01:23 2009 From: roll at Stupi.SE (Peter Lothberg) Date: Thu, 1 Jan 2009 1:01:23 CET Subject: Leap second tonight In-Reply-To: Your message of Wed, 31 Dec 2008 15:28:16 -0800 Message-ID: bash-2.05b# date Thu Jan 1 00:59:58 CET 2009 bash-2.05b# date Thu Jan 1 00:59:59 CET 2009 bash-2.05b# date Thu Jan 1 00:59:60 CET 2009 bash-2.05b# date Thu Jan 1 01:00:00 CET 2009 bash-2.05b# date Thu Jan 1 01:00:01 CET 2009 bash-2.05b# -P From simon at slimey.org Thu Jan 1 03:15:51 2009 From: simon at slimey.org (Simon Lockhart) Date: Thu, 1 Jan 2009 09:15:51 +0000 Subject: Leap second tonight In-Reply-To: References: Message-ID: <20090101091551.GS14718@virtual.bogons.net> On Wed Dec 31, 2008 at 04:53:57PM -0800, Wil Schultz wrote: > At which point my Solaris 10 v490's reboot in unison, lovely. > > Anyone else see anything interesting? I had a couple of Oracle servers (Solaris 10) reboot a couple of minutes just before the leap second. All my other Solaris 10 boxes appear to have stayed up fine. Simon From yahoo at jimpop.com Thu Jan 1 03:29:35 2009 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 1 Jan 2009 04:29:35 -0500 Subject: Leap second tonight In-Reply-To: <20090101091551.GS14718@virtual.bogons.net> References: <20090101091551.GS14718@virtual.bogons.net> Message-ID: <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> On Thu, Jan 1, 2009 at 04:15, Simon Lockhart wrote: > On Wed Dec 31, 2008 at 04:53:57PM -0800, Wil Schultz wrote: >> At which point my Solaris 10 v490's reboot in unison, lovely. >> >> Anyone else see anything interesting? > > I had a couple of Oracle servers (Solaris 10) reboot a couple of minutes > just before the leap second. All my other Solaris 10 boxes appear to have > stayed up fine. Have either of you determined if this was a OS reboot and not a bios reset? -Jim P. From simon at slimey.org Thu Jan 1 04:36:46 2009 From: simon at slimey.org (Simon Lockhart) Date: Thu, 1 Jan 2009 10:36:46 +0000 Subject: Leap second tonight In-Reply-To: <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> References: <20090101091551.GS14718@virtual.bogons.net> <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> Message-ID: <20090101103646.GT14718@virtual.bogons.net> On Thu Jan 01, 2009 at 04:29:35AM -0500, Jim Popovitch wrote: > Have either of you determined if this was a OS reboot and not a bios reset? I've been trawling through all the logfiles I can find on the box, and I see normal entries up until 23:59:xx, and then the next entry is stuff restarting. Could well be a BIOS/LOM reset, but it's odd that the only two boxes affected were my Oracle servers. Simon From wschultz at bsdboy.com Thu Jan 1 09:58:21 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 1 Jan 2009 07:58:21 -0800 Subject: Leap second tonight In-Reply-To: <20090101103646.GT14718@virtual.bogons.net> References: <20090101091551.GS14718@virtual.bogons.net> <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> <20090101103646.GT14718@virtual.bogons.net> Message-ID: <10CBFB91-7B4D-44BE-80EA-EC8949CE40E2@bsdboy.com> All of my Solaris 10 boxes stayed up with the exception of the Oracle 10g RAC boxes. db1:~ wschultz$ uname -a SunOS db1 5.10 Generic_137111-01 sun4u sparc SUNW,Sun-Fire-V490 A friend of mine had his RAC boxes reboot as well, similar configuration. I've poured through the logs and see normal activity until the reboot, nothing suspicious and no reason for the reboot. Seems to be specific to Solaris 10 running RAC on this end. -wil On Jan 1, 2009, at 2:36 AM, Simon Lockhart wrote: > On Thu Jan 01, 2009 at 04:29:35AM -0500, Jim Popovitch wrote: >> Have either of you determined if this was a OS reboot and not a >> bios reset? > > I've been trawling through all the logfiles I can find on the box, > and I see > normal entries up until 23:59:xx, and then the next entry is stuff > restarting. > Could well be a BIOS/LOM reset, but it's odd that the only two boxes > affected > were my Oracle servers. > > Simon > From simon at slimey.org Thu Jan 1 10:13:51 2009 From: simon at slimey.org (Simon Lockhart) Date: Thu, 1 Jan 2009 16:13:51 +0000 Subject: Leap second tonight In-Reply-To: <10CBFB91-7B4D-44BE-80EA-EC8949CE40E2@bsdboy.com> References: <20090101091551.GS14718@virtual.bogons.net> <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> <20090101103646.GT14718@virtual.bogons.net> <10CBFB91-7B4D-44BE-80EA-EC8949CE40E2@bsdboy.com> Message-ID: <20090101161351.GU14718@virtual.bogons.net> On Thu Jan 01, 2009 at 07:58:21AM -0800, Wil Schultz wrote: > All of my Solaris 10 boxes stayed up with the exception of the Oracle > 10g RAC boxes. My Oracle boxes that rebooted were running RAC (version 10G R2), too. Another Solaris 10 box running the same version of Oracle, but not RAC, did not reboot. Looks rather like an Oracle 10 RAC bug. Simon From joelja at bogus.com Thu Jan 1 11:57:46 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 01 Jan 2009 09:57:46 -0800 Subject: Hijacking and Tools BOF Nanog 45 - Call for participants Message-ID: <495D041A.8070009@bogus.com> Greetings and happy new year, As Nanog 45 is quickly approaching, I would encourage anyone who has been thinking about the problem of address hijacking and mitigation within the framework of our existing routing system to consider participating in the Hijack and Tools BOF at, in Santo Domingo. We have sufficient space in the agenda for the Sunday afternoon BOF to accommodate some additional participants. Discussions from both tools developers and operators with deployment experience with opsen-source or commercial tools are encouraged, as well as filtering policy, strategy for communicating with peer network operators to coordinate response and related topics within the sphere of ip hijacking response. Thanks and Looking forward to seeing you all in Santo Domingo. Joel From joelja at bogus.com Thu Jan 1 12:25:48 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 01 Jan 2009 10:25:48 -0800 Subject: NANOG 45 PGP signing party. Message-ID: <495D0AAC.5070704@bogus.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick note, The thrice annual NANOG pgp key signing party will be making an appearance at NANOG 45. The keysigning sessions are going to be during the morning breaks during the general session, and will be location TDB. Monday January 26th 11:00-11:30 Tuesday January 27th 11:00-11:30 If you plan to participate, please add your key to the keyring at: https://biglumber.com/x/web?keyring=9210 Then come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. While printouts will probably be available at the sessions, feel free to add your key to the keyring right up to the time of the last keysigning event. Thanks Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkldCqwACgkQ8AA1q7Z/VrKoQACfSgOEzqbSplmCyKPmhc6Y13fu M3AAn1ZcEXMCqLvu0c7TAyDpjSuWLoIZ =Ie47 -----END PGP SIGNATURE----- From jeffw at smoe.org Thu Jan 1 14:05:28 2009 From: jeffw at smoe.org (Jeff Wasilko) Date: Thu, 1 Jan 2009 15:05:28 -0500 Subject: Leap second tonight In-Reply-To: <20090101161351.GU14718@virtual.bogons.net> References: <20090101091551.GS14718@virtual.bogons.net> <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> <20090101103646.GT14718@virtual.bogons.net> <10CBFB91-7B4D-44BE-80EA-EC8949CE40E2@bsdboy.com> <20090101161351.GU14718@virtual.bogons.net> Message-ID: <20090101200528.GE6440@fs1.rfc1918.smoe.org> On Thu, Jan 01, 2009 at 04:13:51PM +0000, Simon Lockhart wrote: > On Thu Jan 01, 2009 at 07:58:21AM -0800, Wil Schultz wrote: > > All of my Solaris 10 boxes stayed up with the exception of the Oracle > > 10g RAC boxes. > > My Oracle boxes that rebooted were running RAC (version 10G R2), too. Another > Solaris 10 box running the same version of Oracle, but not RAC, did not reboot. I've got a 10g RAC cluster with T2000s and 2900s that didn't reboot. I can dig up specific release levels, but I think we're at 10.2.0.4 -j From stefan at csudsu.com Thu Jan 1 15:13:57 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Thu, 1 Jan 2009 21:13:57 +0000 Subject: Leap second tonight Message-ID: <359835439-1230844425-cardhu_decombobulator_blackberry.rim.net-1153097755-@bxe351.bisx.prod.on.blackberry> What FS do you have on your RAC? And do you have a log of console? We do not have 10g R2 on Solaris, but with the random issues we have seen. Oracle could have fenced each other off. We noticed that some errors do not show up anywhere than console, so we run conserver and dump all console out to log. ------Original Message------ From: Simon Lockhart Sender: To: Wil Schultz Cc: NANOG list Sent: Jan 1, 2009 8:13 AM Subject: Re: Leap second tonight On Thu Jan 01, 2009 at 07:58:21AM -0800, Wil Schultz wrote: > All of my Solaris 10 boxes stayed up with the exception of the Oracle > 10g RAC boxes. My Oracle boxes that rebooted were running RAC (version 10G R2), too. Another Solaris 10 box running the same version of Oracle, but not RAC, did not reboot. Looks rather like an Oracle 10 RAC bug. Simon From cmadams at hiwaay.net Thu Jan 1 20:12:32 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 1 Jan 2009 20:12:32 -0600 Subject: Leap second tonight In-Reply-To: <495C1A5C.6010600@hubris.net> References: <495C1A5C.6010600@hubris.net> Message-ID: <20090102021232.GE1544760@hiwaay.net> Once upon a time, Steven Saner said: > I run a bunch of Slackware Linux boxes of varying versions. As best as I > can tell, at or around 00:00 UTC all of my Slackware 12.0 boxes crashed > with a kernel panic. I don't think it is ntpd because it is the same > version as on 12.1 boxes (4.2.4p0) that did not crash. It may be the > kernel: 2.6.21.5 > > Anyone else experience similar or was this coincidental and I have other > issues... I had one (out of many, including about a half dozen identically configured) Red Hat Enterprise Linux 4 systems hang at the leap second. There have been some messages on the NTP list referencing posts on a Debian list about leap second crashes, and there's a post on /. about a similar problem with Fedora 8. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From eddies at softhome.net Thu Jan 1 20:46:52 2009 From: eddies at softhome.net (Eddie) Date: Thu, 01 Jan 2009 18:46:52 -0800 Subject: Leap second tonight In-Reply-To: <495C1A5C.6010600@hubris.net> References: <495C1A5C.6010600@hubris.net> Message-ID: <495D801C.8050306@softhome.net> Steven Saner wrote: > Jon Meek wrote: >> My Solaris 10 boxes are all happy (and did not reboot). I monitor NTP >> on a number >> of devices, including one router. The router was off by one second for >> a while, but >> is OK after an hour. Everything else was fine immediately. >> >> In 2005, our CDMA clock got the leap second between 15:08 and 15:38 >> EST creating >> some issues due to disagreement with the (too few) GPS clocks. >> >> Jon >> >> On Wed, Dec 31, 2008 at 7:53 PM, Wil Schultz wrote: >>> At which point my Solaris 10 v490's reboot in unison, lovely. >>> >>> Anyone else see anything interesting? >>> >>> -wil > > I run a bunch of Slackware Linux boxes of varying versions. As best as I > can tell, at or around 00:00 UTC all of my Slackware 12.0 boxes crashed > with a kernel panic. I don't think it is ntpd because it is the same > version as on 12.1 boxes (4.2.4p0) that did not crash. It may be the > kernel: 2.6.21.5 > > Anyone else experience similar or was this coincidental and I have other > issues... > > Steve > Yep. I have a few Slack 12 boxes lockup. Digging around, it looks to be a issue with pre 2.6.21.5 kernels. -Eddie -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From iljitsch at muada.com Fri Jan 2 04:16:43 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 2 Jan 2009 11:16:43 +0100 Subject: 2008 IPv4 Address Use Report Message-ID: [ (Non-cross)posted to IETF discussions, NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace2008.php ] 2008 IPv4 Address Use Report As of January first, 2009, the number of unused IPv4 addresses is 925.58 million. On January 1, 2008, it was 1122.85 million. So in 2008, 197.27 million addresses were used up. With 3706.65 million usable addresses, this means that 75.3% of the available IPv4 addresses are in some kind of use, up from 69.7% a year ago. So the depletion of the IPv4 address reserves is continuing in much the same way as in previous years: Date Addresses free Used up 2006-01-01 1468.61 M 2007-01-01 1300.65 M 167.96 M 2008-01-01 1122.85 M 177.80 M (with return of 16.78 M to IANA) 2009-01-01 925.58 M 197.27 M These figures are derived from from the Internet Assigned Numbers Authority's IPv4 Global Unicast Address Assignments page and the records published on the FTP servers of the five Regional Internet Registries (RIRs): AfriNIC, which gives out address space in Africa, APNIC (Asia-Pacific region), ARIN (North America), LACNIC (Latin American and the Caribbean) and the RIPE NCC (Europe, the former Soviet Union and the Middle East). The IANA list shows the status of all 256 blocks of 16777216 addresses identified by the first 8-bit number in the IPv4 address. (Note that the file is in a somewhat different format than in previous years.) The RIR data indicates how much address space the RIRs have delegated to internet service providers (and sometimes end-users). Delegated Blocks +/- 2008 Addresses Used Available to/status (in millions) AfriNIC 2 33.55 9.18 24.37 APNIC 30 +4 503.32 454.36 48.96 ARIN 31 +4 520.09 446.06 74.03 LACNIC 6 100.66 68.88 31.78 RIPE NCC 26 436.21 423.65 12.56 LEGACY 92 +1 1543.50 1363.29 180.21 UNALLOCATED 34 -9 570.43 570.43 Totals 221 3707.76 2765.42 942.34 The difference between the 942.34 million free addresses here and 925.58 million earlier is explained by the fact that the 43.0.0.0/8 legacy block shows up as delegated in the IANA list, but not in the APNIC delegation records. In previous years, 7.0.0.0/8 didn't show up in the IANA records but it did in the ARIN records. This has now been fixed, hence the increase in legacy delegations. No legacy blocks were returned to IANA in 2008. The total number of available addresses is slightly higher than the previously mentioned figure at 3707.76 million because the table above includes 172.16.0.0/12 and 192.168.0.0/16, which are set aside for private use. Networks 0.0.0.0/8 and 127.0.0.0/8 aren't usable because of special uses and 10.0.0.0/8 is also set aside for private use. 224 - 239 are multicast addresses, and 240 - 255 is class E, which is "reserved" for future use. If the class E space could be used, it would increase the available address space by 268 million addresses. The past two years, this has been a topic of hot debate in the IETF and elsewhere. The problem is that almost all operating systems need modification to be able to use class E addresses, and a good part of the installed base of devices connected to the internet must be considered unupgradable. The 2781.07 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2009-01-01 2008-01-01 increase Country 1 - US 1458.21 M 1408.15 M 4% United States 2 (3) CN 181.80 M 135.31 M 34% China 3 (2) JP 151.56 M 141.47 M 7% Japan 4 - EU 120.29 M 120.35 M 0% Multi-country in Europe 5 - GB 86.31 M 83.50 M 3% United Kingdom 6 (7) DE 81.75 M 72.46 M 13% Germany 7 (6) CA 74.49 M 73.20 M 2% Canada 8 - FR 68.04 M 67.79 M 0% France 9 - KR 66.82 M 58.86 M 14% Korea 10 - AU 36.26 M 33.43 M 8% Australia 11 (12) BR 29.75 M 23.46 M 27% Brazil 12 (11) IT 29.64 M 24.04 M 23% Italy 13 (16) TW 24.01 M 19.83 M 21% Taiwan 14 (18) RU 23.18 M 17.01 M 36% Russia 15 (14) ES 21.67 M 20.42 M 6% Spain In 2008, the United States was again the biggest user of new address space with no less than 50 million addresses added to the 1.4 billion they already had at the beginning of the year. China is a close second with 46.50 million new addresses. There is no clear trend in the growth percentages. A few countries like France and the UK show very modest growth, while other countries with a large installed base like Germany and Korea saw double digit growth percentages. And in addition to China, Brazil, Taiwan and Russia, but also Italy, are catching up. The US now holds 52.4% of the IPv4 address space in use. The total for the top 15 excluding the US is 35.8%. The rest of the world gets the remaining 327.23 million addresses, or 11.8%. The size of address blocks given out was increasing until 2005, but now shows a downturn. The table below shows the number of delegations for a certain range of block sizes (equal or higher than the first, lower than the second value). 2002 2003 2004 2005 2006 2007 2008 < 1000 547 745 1022 1309 1507 1830 1896 1000 - 8000 897 1009 1516 1891 2265 2839 3235 8000 - 64k 822 1014 1100 1039 1192 1015 1129 64k - 500k 163 215 404 309 419 395 410 500k - 2M 29 46 61 60 57 62 82 > 2M 5 6 7 18 17 24 18 In millions of addresses: 2002 2003 2004 2005 2006 2007 2008 < 1000 0.18 0.25 0.35 0.44 0.51 0.63 0.65 1000 - 8000 3.23 3.45 4.49 5.07 5.83 6.93 7.75 8000 - 64k 11.35 14.00 15.99 15.46 18.01 15.67 17.40 64k - 500k 20.28 25.51 42.01 34.23 50.86 50.83 52.58 500k - 2M 21.30 31.98 44.63 41.63 46.69 45.50 57.41 > 2M 12.58 12.58 20.97 68.62 52.43 67.37 54.00 The growth in the smallest and largest categories has been curtailed, but this growth now seems to happen in the second smallest and second largest categories, so the total effect isn't all that different, as indicated by the number of addresses given out per request/delegation: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 2006 5457 174.32 31945 2007 6165 186.92 30320 2008 6770 189.79 28035 (The numbers of addresses given out are lower here because ARIN often attributes the delegation of new addresses to a previous year, this view doesn't correct for that.) From cidr-report at potaroo.net Fri Jan 2 05:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Jan 2009 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200901021100.n02B05jJ027505@wattle.apnic.net> BGP Update Report Interval: 01-Dec-08 -to- 01-Jan-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35805 250272 3.2% 897.0 -- UTG-AS United Telecom AS 2 - AS4323 122592 1.6% 28.9 -- TWTC - tw telecom holdings, inc. 3 - AS9583 114770 1.5% 91.8 -- SIFY-AS-IN Sify Limited 4 - AS209 82772 1.1% 27.2 -- ASN-QWEST - Qwest Communications Corporation 5 - AS4538 81992 1.0% 16.1 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS6298 59306 0.8% 27.1 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 7 - AS8452 49246 0.6% 30.0 -- TEDATA TEDATA 8 - AS6389 46045 0.6% 10.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 9 - AS7643 44654 0.6% 34.7 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 10 - AS17974 42677 0.5% 72.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS24863 41693 0.5% 60.1 -- LINKdotNET-AS 12 - AS30306 40259 0.5% 8051.8 -- AfOL-Sz-AS 13 - AS6478 38479 0.5% 20.5 -- ATT-INTERNET3 - AT&T WorldNet Services 14 - AS6458 37586 0.5% 94.2 -- Telgua 15 - AS20115 36726 0.5% 16.3 -- CHARTER-NET-HKY-NC - Charter Communications 16 - AS17488 35422 0.5% 22.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS4755 34561 0.4% 28.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 18 - AS29372 31659 0.4% 285.2 -- SFR-NETWORK SFR 19 - AS8151 30440 0.4% 21.6 -- Uninet S.A. de C.V. 20 - AS2386 30336 0.4% 18.3 -- INS-AS - AT&T Data Communications Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 27352 0.3% 9117.3 -- EMENTOR-AS Enfo Oyj 2 - AS30306 40259 0.5% 8051.8 -- AfOL-Sz-AS 3 - AS30287 6619 0.1% 6619.0 -- ALON-USA - ALON USA, LP 4 - AS32398 23391 0.3% 2923.9 -- REALNET-ASN-1 5 - AS46115 28844 0.4% 2884.4 -- LUTHER - Luther College 6 - AS30969 21396 0.3% 2674.5 -- TAN-NET TransAfrica Networks 7 - AS41007 10802 0.1% 2160.4 -- CTCASTANA CTC ASTANA, KZ 8 - AS43925 4250 0.1% 2125.0 -- MOLDCELL_AS Moldcell SA Autonomous System 9 - AS23917 2066 0.0% 2066.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 10 - AS8599 1988 0.0% 1988.0 -- Ulyanovsk State University Network 11 - AS31901 1087 0.0% 1087.0 -- THECHIMES - The Chimes, Inc. 12 - AS5691 12188 0.1% 937.5 -- MITRE-AS-5 - The MITRE Corporation 13 - AS8668 6456 0.1% 922.3 -- TELONE-AS TelOne Zimbabwe P/L 14 - AS15561 920 0.0% 920.0 -- CDS-ITALY C.D.S. Informatica S.r.l. 15 - AS48129 909 0.0% 909.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 16 - AS35805 250272 3.2% 897.0 -- UTG-AS United Telecom AS 17 - AS19017 892 0.0% 892.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 18 - AS16214 4910 0.1% 818.3 -- CERIST 19 - AS28519 2418 0.0% 806.0 -- Universidad Autonoma de Guadalajara 20 - AS5033 7176 0.1% 797.3 -- ISW - Internet Specialties West Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 210.214.151.0/24 23239 0.3% AS9583 -- SIFY-AS-IN Sify Limited 2 - 41.204.2.0/24 22979 0.3% AS32398 -- REALNET-ASN-1 3 - 221.134.222.0/24 21839 0.3% AS9583 -- SIFY-AS-IN Sify Limited 4 - 77.95.144.0/22 18567 0.2% AS29282 -- EMENTOR-AS Enfo Oyj 5 - 212.85.220.0/24 18449 0.2% AS30306 -- AfOL-Sz-AS 6 - 212.85.223.0/24 18420 0.2% AS30306 -- AfOL-Sz-AS 7 - 221.135.80.0/24 13021 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 118.95.130.0/23 13019 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 124.7.201.0/24 12983 0.2% AS9583 -- SIFY-AS-IN Sify Limited 10 - 192.12.120.0/24 12062 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 11 - 196.27.104.0/21 10553 0.1% AS30969 -- TAN-NET TransAfrica Networks 12 - 196.27.108.0/22 10518 0.1% AS30969 -- TAN-NET TransAfrica Networks 13 - 199.2.119.0/24 9131 0.1% AS11816 -- SetarNet 14 - 217.69.48.0/20 8774 0.1% AS29282 -- EMENTOR-AS Enfo Oyj 15 - 195.189.68.0/24 7941 0.1% AS41007 -- CTCASTANA CTC ASTANA, KZ 16 - 89.4.131.0/24 7356 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - 64.162.116.0/24 7062 0.1% AS5033 -- ISW - Internet Specialties West Inc. 18 - 65.214.174.0/24 6619 0.1% AS30287 -- ALON-USA - ALON USA, LP 19 - 192.102.88.0/24 6529 0.1% AS6629 -- NOAA-AS - NOAA 20 - 192.35.129.0/24 6468 0.1% AS6629 -- NOAA-AS - NOAA Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 2 05:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Jan 2009 22:00:03 +1100 (EST) Subject: The Cidr Report Message-ID: <200901021100.n02B03Oj027496@wattle.apnic.net> This report has been generated at Fri Jan 2 21:19:11 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 Prefixes CIDR Agg 26-12-08 284016 175054 27-12-08 283830 175219 28-12-08 283977 175112 29-12-08 283978 175457 30-12-08 283996 175982 31-12-08 284233 175829 01-01-09 283834 175623 02-01-09 283623 175676 AS Summary 30285 Number of ASes in routing system 12884 Number of ASes announcing only one prefix 4382 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89820672 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'). --- 02Jan09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 283598 175619 107979 38.1% All ASes AS6389 4382 357 4025 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4198 1715 2483 59.1% TWTC - tw telecom holdings, inc. AS209 2845 1266 1579 55.5% ASN-QWEST - Qwest Communications Corporation AS4766 1754 492 1262 71.9% KIXS-AS-KR Korea Telecom AS17488 1477 337 1140 77.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1705 719 986 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1185 212 973 82.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 994 62 932 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1400 535 865 61.8% Uninet S.A. de C.V. AS11492 1231 462 769 62.5% CABLEONE - CABLE ONE, INC. AS19262 943 254 689 73.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1581 901 680 43.0% INS-AS - AT&T Data Communications Services AS18101 782 139 643 82.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1110 470 640 57.7% LEVEL3 Level 3 Communications AS18566 1060 516 544 51.3% COVAD - Covad Communications Co. AS9583 901 368 533 59.2% SIFY-AS-IN Sify Limited AS2706 545 23 522 95.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS7545 679 170 509 75.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 623 156 467 75.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 593 129 464 78.2% CANET-ASN-4 - Bell Aliant AS6478 1032 574 458 44.4% ATT-INTERNET3 - AT&T WorldNet Services AS17676 522 64 458 87.7% GIGAINFRA BB TECHNOLOGY Corp. AS9443 523 82 441 84.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1425 987 438 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS22047 565 127 438 77.5% VTR BANDA ANCHA S.A. AS4134 896 465 431 48.1% CHINANET-BACKBONE No.31,Jin-rong Street AS17908 590 159 431 73.1% TCISL Tata Communications AS20115 1850 1422 428 23.1% CHARTER-NET-HKY-NC - Charter Communications AS24560 661 233 428 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 693 278 415 59.9% LGNET-AS-KR LG CNS Total 38745 13674 25071 64.7% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.0.0.0/8 AS17550 SMC-AS-AP San Miguel Corporation 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.9.30.0/24 AS41457 A1-AS A1 Ltd. 193.9.31.0/24 AS41457 A1-AS A1 Ltd. 193.23.142.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 193.23.143.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From rodrick.brown at gmail.com Fri Jan 2 08:04:26 2009 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Fri, 2 Jan 2009 09:04:26 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Message-ID: A team of security researchers and academics has broken a core piece of Internet technology. They made their work public at the 25th Chaos Communication Congress in Berlin today. The team was able to create a rogue certificate authority and use it to issue valid SSL certificates for any site they want. The user would have no indication that their HTTPS connection was being monitored/modified. http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ http://phreedom.org/research/rogue-ca/ -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown From frnkblk at iname.com Fri Jan 2 08:36:30 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Fri, 2 Jan 2009 08:36:30 -0600 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly Message-ID: We were assigned a new block from ARIN two weeks ago and are getting several reports from end users that the Spanish and German versions of Google's search page are coming up. IP2Location and Maxmind are mostly correct, but there appears to be no way for me to verify that Google and Akamai have 96.31.0.0/20 listed correctly. Perhaps someone can point me in the right direction so I can make an authoritative check. Thanks, Frank From jgreco at ns.sol.net Fri Jan 2 09:58:05 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Jan 2009 09:58:05 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: from "Rodrick Brown" at Jan 02, 2009 09:04:26 AM Message-ID: <200901021558.n02Fw5bs040941@aurora.sol.net> > A team of security researchers and academics has broken a core piece > of Internet technology. They made their work public at the 25th Chaos > Communication Congress in Berlin today. The team was able to create a > rogue certificate authority and use it to issue valid SSL certificates > for any site they want. The user would have no indication that their > HTTPS connection was being monitored/modified. > > http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ > http://phreedom.org/research/rogue-ca/ That's a bit of a stretch. It doesn't seem that they've actually broken "a core piece of Internet technology." It's more like they've nibbled at a known potential problem enough to make it a real problem. According to the quoted article, "They collected 30K certs from Firefox trusted CAs. 9K of them were MD5 signed. 97% of those came from RapidSSL." I've seen other discussions of the topic that suggest that a variety of CA's (one such discussion talked about "VeriSign resellers", and I believe RapidSSL ~== VeriSign) are vulnerable. Anyways, I was under the impression that the whole purpose of the revocation capabilities of SSL was to deal with problems like this, and that a large part of the justification of the cost of an SSL certificate was the administrative burden associated with guaranteeing and maintaining the security of the chain. It seems like the major browser vendors and anyone else highly reliant on SSL should be putting VeriSign and any other affected CA's on notice that their continued existence as trusted CA's in software distributions is dependent on their rapidly forcing customers to update their certificates, an obligation that they should have expected to undertake every now and then, even though they'll obviously not *want* to have to do that. I'm aware that the VeriSign position is that their existing certificates are "not vulnerable" to "this attack," which I believe may be the case for some values of those terms. However, it is often the case that a limited- effectiveness example such as this is soon replaced by a more generally- effective exploit, and the second URL suggests to me that what VeriSign is saying may not be true anyways. ... 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. From jabley at hopcount.ca Fri Jan 2 10:00:34 2009 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 2 Jan 2009 11:00:34 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: Message-ID: On 2009-01-02, at 09:04, Rodrick Brown wrote: > A team of security researchers and academics has broken a core piece > of Internet technology. They made their work public at the 25th Chaos > Communication Congress in Berlin today. The team was able to create a > rogue certificate authority and use it to issue valid SSL certificates > for any site they want. The user would have no indication that their > HTTPS connection was being monitored/modified. I read a comment somewhere else that while this is interesting, and good work, and well done, in practice it's much easier to social- engineer a certificate with a stolen credit card from a real CA than it is to create a fake CA. (I'd give proper attribution if I could remember who it was, but it put things into perspective for me at the time so I thought I'd share.) Joe From martin at airwire.ie Fri Jan 2 10:06:31 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 02 Jan 2009 16:06:31 +0000 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: Message-ID: <495E3B87.9000007@airwire.ie> Joe Abley wrote: > > On 2009-01-02, at 09:04, Rodrick Brown wrote: > >> A team of security researchers and academics has broken a core piece >> of Internet technology. They made their work public at the 25th Chaos >> Communication Congress in Berlin today. The team was able to create a >> rogue certificate authority and use it to issue valid SSL certificates >> for any site they want. The user would have no indication that their >> HTTPS connection was being monitored/modified. > > I read a comment somewhere else that while this is interesting, and good > work, and well done, in practice it's much easier to social-engineer a > certificate with a stolen credit card from a real CA than it is to > create a fake CA. > > (I'd give proper attribution if I could remember who it was, but it put > things into perspective for me at the time so I thought I'd share.) > It is. But this issue might open for man-in-the-middle attacks, which is much harder for issued certificates. Issued certificates usually also incorporate a check, that you control a domain etc. With engineered certificates you can practically avoid that whole process. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From ge at linuxbox.org Fri Jan 2 10:08:42 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 2 Jan 2009 10:08:42 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: Message-ID: On Fri, 2 Jan 2009, Joe Abley wrote: > > On 2009-01-02, at 09:04, Rodrick Brown wrote: > >> A team of security researchers and academics has broken a core piece >> of Internet technology. They made their work public at the 25th Chaos >> Communication Congress in Berlin today. The team was able to create a >> rogue certificate authority and use it to issue valid SSL certificates >> for any site they want. The user would have no indication that their >> HTTPS connection was being monitored/modified. > > I read a comment somewhere else that while this is interesting, and good > work, and well done, in practice it's much easier to social-engineer a > certificate with a stolen credit card from a real CA than it is to create a > fake CA. > > (I'd give proper attribution if I could remember who it was, but it put > things into perspective for me at the time so I thought I'd share.) My facebook status? :P From swmike at swm.pp.se Fri Jan 2 10:38:14 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 2 Jan 2009 17:38:14 +0100 (CET) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <200901021558.n02Fw5bs040941@aurora.sol.net> References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: On Fri, 2 Jan 2009, Joe Greco wrote: > Anyways, I was under the impression that the whole purpose of the > revocation capabilities of SSL was to deal with problems like this, and How to revoke the CA is actually in the file. The fake CA they created didn't have any revokation. MD5 is broken, don't use it for anything important. The reason for their exercise is just as you said, they executed in practice what had been said to be possible since around 2004-2006. This is obviously needed for people to start paying attention. -- Mikael Abrahamsson email: swmike at swm.pp.se From Valdis.Kletnieks at vt.edu Fri Jan 2 10:44:33 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 02 Jan 2009 11:44:33 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: Your message of "Fri, 02 Jan 2009 09:58:05 CST." <200901021558.n02Fw5bs040941@aurora.sol.net> References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: <15115.1230914673@turing-police.cc.vt.edu> On Fri, 02 Jan 2009 09:58:05 CST, Joe Greco said: > Anyways, I was under the impression that the whole purpose of the > revocation capabilities of SSL was to deal with problems like this, and > that a large part of the justification of the cost of an SSL certificate > was the administrative burden associated with guaranteeing and maintaining > the security of the chain. What percentage of deployed browsers handle CRL's correctly? Consider this snippet from the phreedom.org page (section 6.1): "One interesting observation from our work is that the rogue certificate we have created is very hard to revoke using the revocation mechanism available in common browsers. There are two protocols for certificate revocation, CRL and OSCP. Until Firefox 3 and IE 7, certificate revocation was disabled by default. Even in the latest versions, the browsers rely on the certificate to include a URL pointing to a revocation server. Our rogue CA certificate had very limited space and it was impossible to include such a URL, which means that by default both Internet Explorer and Firefox are unable to find a revocation server to check our certificate against." Hmm... so basically all deployed FireFox and IE either don't even try to do a CRL, or they ask the dodgy certificate "Who can I ask if you're dodgy?" What's wrong with this picture? (Personally, I consider this a potentially bigger problem than the MD5 issue...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From link at pobox.com Fri Jan 2 10:53:55 2009 From: link at pobox.com (Terje Bless) Date: Fri, 2 Jan 2009 17:53:55 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <15115.1230914673@turing-police.cc.vt.edu> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> Message-ID: <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> On Fri, Jan 2, 2009 at 5:44 PM, wrote: > Hmm... so basically all deployed FireFox and IE either don't even try to do > a CRL, or they ask the dodgy certificate "Who can I ask if you're dodgy?" Hmm. Don't the shipped-with-the-browser trusted root certificates include a CRL URL? From smb at cs.columbia.edu Fri Jan 2 11:06:36 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 2 Jan 2009 12:06:36 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> Message-ID: <20090102120636.3b4a9444@cs.columbia.edu> On Fri, 2 Jan 2009 17:53:55 +0100 "Terje Bless" wrote: > On Fri, Jan 2, 2009 at 5:44 PM, wrote: > > Hmm... so basically all deployed FireFox and IE either don't even > > try to do a CRL, or they ask the dodgy certificate "Who can I ask > > if you're dodgy?" > > Hmm. Don't the shipped-with-the-browser trusted root certificates > include a CRL URL? > > Every CA runs its own CRL server -- it has to be that way. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jgreco at ns.sol.net Fri Jan 2 11:33:48 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Jan 2009 11:33:48 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <15115.1230914673@turing-police.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Jan 02, 2009 11:44:33 AM Message-ID: <200901021733.n02HXnAN047547@aurora.sol.net> > On Fri, 02 Jan 2009 09:58:05 CST, Joe Greco said: > > Anyways, I was under the impression that the whole purpose of the > > revocation capabilities of SSL was to deal with problems like this, and > > that a large part of the justification of the cost of an SSL certificate > > was the administrative burden associated with guaranteeing and maintaining > > the security of the chain. > > What percentage of deployed browsers handle CRL's correctly? > > Consider this snippet from the phreedom.org page (section 6.1): > > "One interesting observation from our work is that the rogue certificate we > have created is very hard to revoke using the revocation mechanism available in > common browsers. There are two protocols for certificate revocation, CRL and > OSCP. Until Firefox 3 and IE 7, certificate revocation was disabled by default. > Even in the latest versions, the browsers rely on the certificate to include a > URL pointing to a revocation server. Our rogue CA certificate had very limited > space and it was impossible to include such a URL, which means that by default > both Internet Explorer and Firefox are unable to find a revocation server to > check our certificate against." > > Hmm... so basically all deployed FireFox and IE either don't even try to do > a CRL, or they ask the dodgy certificate "Who can I ask if you're dodgy?" > > What's wrong with this picture? (Personally, I consider this a potentially > bigger problem than the MD5 issue...) I suppose I wasn't sufficiently clear. It seems that part of the proposed solution is to get people to move from MD5-signed to SHA1-signed. There will be a certain amount of resistance. What I was suggesting was the use of the revocation mechanism as part of the "stick" (think carrot-and-stick) in a campaign to replace MD5-based certs. If there is a credible threat to MD5-signed certs, then forcing their retirement would seem to be a reasonable reaction, but everyone here knows how successful "voluntary" conversion strategies typically are. Either we take the potential for transparent MitM attacks seriously, or we do not. I'm sure the NSA would prefer "not." :-) As for the points raised in your message, yes, there are additional problems with clients that have not taken this seriously. It is, however, one thing to have locks on your door that you do not lock, and another thing entirely not to have locks (and therefore completely lack the ability to lock). I hope that there is some serious thought going on in the browser groups about this sort of issue. We cannot continue to justify security failure on the basis that a significant percentage of the clients don't support it, or are broken in their support. That's an argument for fixing the clients. ... 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. From jabley at hopcount.ca Fri Jan 2 11:39:30 2009 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 2 Jan 2009 12:39:30 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901021733.n02HXnAN047547@aurora.sol.net> References: <200901021733.n02HXnAN047547@aurora.sol.net> Message-ID: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> On 2 Jan 2009, at 12:33, Joe Greco wrote: > We cannot continue to justify security failure on the basis that a > significant percentage of the clients don't support it, or are > broken in > their support. That's an argument for fixing the clients. At a more basic level, though, isn't failure guaranteed for these kind of clients (web browsers) so long as users are conditioned to click OK/ Continue for every SSL certificate failure that is reported to them? If I was attempting a large-scale man-in-the-middle attack, perhaps I'd be happier to do no work and intercept 5% of sessions (those who click OK on a certificate that is clearly bogus) than I would to do an enormous amount of work and intercept 100% (those who would see no warnings). And surely 5% is a massive under-estimate. Joe From mathews at hawaii.edu Fri Jan 2 11:56:19 2009 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Fri, 02 Jan 2009 12:56:19 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901021733.n02HXnAN047547@aurora.sol.net> References: <200901021733.n02HXnAN047547@aurora.sol.net> Message-ID: <495E5543.20504@hawaii.edu> Joe Greco wrote: > [ .... ] > > Either we take the potential for transparent MitM attacks seriously, or > we do not. I'm sure the NSA would prefer "not." :-) > > As for the points raised in your message, yes, there are additional > problems with clients that have not taken this seriously. It is, however, > one thing to have locks on your door that you do not lock, and another > thing entirely not to have locks (and therefore completely lack the > ability to lock). I hope that there is some serious thought going on in > the browser groups about this sort of issue. > > [ ... ] > > ... JG F Y I, see: SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' certificates @ http://www.codefromthe70s.org/sslblacklist.aspx Best. From cscora at apnic.net Fri Jan 2 12:13:36 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Jan 2009 04:13:36 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200901021813.n02IDakw018648@thyme.apnic.net> 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-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 Jan, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 275280 Prefixes after maximum aggregation: 131723 Deaggregation factor: 2.09 Unique aggregates announced to Internet: 133384 Total ASes present in the Internet Routing Table: 30197 Prefixes per ASN: 9.12 Origin-only ASes present in the Internet Routing Table: 26280 Origin ASes announcing only one prefix: 12806 Transit ASes present in the Internet Routing Table: 3917 Transit-only ASes present in the Internet Routing Table: 95 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 523 Unregistered ASNs in the Routing Table: 188 Number of 32-bit ASNs allocated by the RIRs: 70 Prefixes from 32-bit ASNs in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 231 Number of addresses announced to Internet: 1980712736 Equivalent to 118 /8s, 15 /16s and 71 /24s Percentage of available address space announced: 53.4 Percentage of allocated address space announced: 63.2 Percentage of available address space allocated: 84.6 Percentage of address space in use by end-sites: 75.1 Total number of prefixes smaller than registry allocations: 134788 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63617 Total APNIC prefixes after maximum aggregation: 22614 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 60489 Unique aggregates announced from the APNIC address blocks: 25957 APNIC Region origin ASes present in the Internet Routing Table: 3492 APNIC Prefixes per ASN: 17.32 APNIC Region origin ASes announcing only one prefix: 956 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 24 Number of APNIC addresses announced to Internet: 395968416 Equivalent to 23 /8s, 153 /16s and 255 /24s Percentage of available APNIC address space announced: 78.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/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: 122871 Total ARIN prefixes after maximum aggregation: 64857 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 92460 Unique aggregates announced from the ARIN address blocks: 35159 ARIN Region origin ASes present in the Internet Routing Table: 12687 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4890 ARIN Region transit ASes present in the Internet Routing Table: 1213 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 405423904 Equivalent to 24 /8s, 42 /16s and 71 /24s Percentage of available ARIN address space announced: 78.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 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, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 61292 Total RIPE prefixes after maximum aggregation: 36722 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56859 Unique aggregates announced from the RIPE address blocks: 37994 RIPE Region origin ASes present in the Internet Routing Table: 12432 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6539 RIPE Region transit ASes present in the Internet Routing Table: 1884 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 383811168 Equivalent to 22 /8s, 224 /16s and 126 /24s Percentage of available RIPE address space announced: 88.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22931 Total LACNIC prefixes after maximum aggregation: 5719 LACNIC Deaggregation factor: 4.01 Prefixes being announced from the LACNIC address blocks: 21036 Unique aggregates announced from the LACNIC address blocks: 11601 LACNIC Region origin ASes present in the Internet Routing Table: 1047 LACNIC Prefixes per ASN: 20.09 LACNIC Region origin ASes announcing only one prefix: 341 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 59299968 Equivalent to 3 /8s, 136 /16s and 216 /24s Percentage of available LACNIC address space announced: 58.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4068 Total AfriNIC prefixes after maximum aggregation: 1396 AfriNIC Deaggregation factor: 2.91 Prefixes being announced from the AfriNIC address blocks: 4338 Unique aggregates announced from the AfriNIC address blocks: 2165 AfriNIC Region origin ASes present in the Internet Routing Table: 268 AfriNIC Prefixes per ASN: 16.19 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 58 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12971264 Equivalent to 0 /8s, 197 /16s and 237 /24s Percentage of available AfriNIC address space announced: 25.8 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1647 6410 372 Korea Telecom (KIX) 17488 1477 104 101 Hathway IP Over Cable Interne 4755 1176 434 165 TATA Communications formerly 9583 902 131 67 Sify Limited 4134 896 15977 360 CHINANET-BACKBONE 18101 782 168 30 Reliance Infocom Ltd Internet 9498 759 292 47 BHARTI BT INTERNET LTD. 4780 721 360 66 Digital United Inc. 24560 662 227 169 Bharti Airtel Ltd. 7545 661 152 82 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4381 3435 345 bellsouth.net, inc. 209 2843 4032 621 Qwest 20115 1848 1455 741 Charter Communications 1785 1705 717 154 PaeTec Communications, Inc. 4323 1606 1059 378 Time Warner Telecom 2386 1580 706 894 AT&T Data Communications Serv 7018 1425 5872 985 AT&T WorldNet Services 11492 1231 192 12 Cable One 3356 1105 10994 432 Level 3 Communications, LLC 18566 1060 296 10 Covad Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 434 1764 383 TDC Tele Danmark 30890 391 80 203 SC Kappa Invexim SRL 12479 383 578 6 Uni2 Autonomous System 3301 336 1413 303 TeliaNet Sweden 3320 333 7065 282 Deutsche Telekom AG 8866 330 109 22 Bulgarian Telecommunication C 3215 327 2857 96 France Telecom Transpac 29049 323 26 3 AzerSat LLC. 8551 304 287 35 Bezeq International 8452 271 188 7 TEDATA Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2820 224 UniNet S.A. de C.V. 10620 688 149 57 TVCABLE BOGOTA 11830 671 299 9 Instituto Costarricense de El 22047 565 302 14 VTR PUNTO NET S.A. 7303 505 249 76 Telecom Argentina Stet-France 6471 429 86 40 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 411 118 72 Servicios Alestra S.A de C.V 28573 364 489 26 NET Servicos de Comunicao S.A 7738 360 730 27 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 518 71 83 LINKdotNET AS number 3741 270 857 227 The Internet Solution 20858 258 34 3 This AS will be used to conne 2018 239 215 140 Tertiary Education Network 33783 147 10 13 EEPAD TISP TELECOM & INTERNET 6713 145 139 12 Itissalat Al-MAGHRIB 29571 121 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 118 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4381 3435 345 bellsouth.net, inc. 209 2843 4032 621 Qwest 20115 1848 1455 741 Charter Communications 1785 1705 717 154 PaeTec Communications, Inc. 4766 1647 6410 372 Korea Telecom (KIX) 4323 1606 1059 378 Time Warner Telecom 2386 1580 706 894 AT&T Data Communications Serv 17488 1477 104 101 Hathway IP Over Cable Interne 7018 1425 5872 985 AT&T WorldNet Services 8151 1400 2820 224 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2843 2222 Qwest 1785 1705 1551 PaeTec Communications, Inc. 17488 1477 1376 Hathway IP Over Cable Interne 4766 1647 1275 Korea Telecom (KIX) 4323 1606 1228 Time Warner Telecom 11492 1231 1219 Cable One 8151 1400 1176 UniNet S.A. de C.V. 20115 1848 1107 Charter Communications 18566 1060 1050 Covad Communications 4755 1176 1011 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:9 /10:20 /11:54 /12:158 /13:310 /14:562 /15:1102 /16:10283 /17:4528 /18:7753 /19:16641 /20:19591 /21:19140 /22:24233 /23:24626 /24:144146 /25:655 /26:822 /27:513 /28:98 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2864 4381 bellsouth.net, inc. 209 1589 2843 Qwest 4766 1382 1647 Korea Telecom (KIX) 17488 1263 1477 Hathway IP Over Cable Interne 2386 1257 1580 AT&T Data Communications Serv 11492 1200 1231 Cable One 1785 1168 1705 PaeTec Communications, Inc. 18566 1041 1060 Covad Communications 20115 930 1848 Charter Communications 7011 837 936 Citizens Utilities Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:173 12:2177 13:2 15:21 16:3 17:5 20:35 24:1107 32:54 38:532 40:96 41:824 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:525 59:600 60:455 61:1097 62:1113 63:2002 64:3397 65:2448 66:3607 67:1440 68:655 69:2415 70:530 71:173 72:1591 73:7 74:1339 75:193 76:306 77:785 78:512 79:302 80:945 81:845 82:561 83:378 84:593 85:1061 86:394 87:638 88:354 89:1377 90:41 91:1811 92:307 93:1076 94:866 95:145 96:96 97:153 98:172 99:10 110:1 111:1 113:56 114:151 115:176 116:1112 117:434 118:244 119:590 120:130 121:701 122:892 123:480 124:772 125:1345 128:358 129:220 130:134 131:410 132:72 133:9 134:323 135:34 136:219 137:133 138:144 139:92 140:415 141:109 142:382 143:306 144:320 145:53 146:371 147:142 148:605 149:219 150:139 151:208 152:149 153:131 154:10 155:254 156:168 157:271 158:162 159:299 160:273 161:131 162:255 163:141 164:519 165:501 166:364 167:348 168:676 169:159 170:462 171:38 172:10 173:144 174:18 187:17 188:1 189:358 190:2484 192:5818 193:4176 194:3308 195:2655 196:1033 198:3694 199:3314 200:5544 201:1484 202:7782 203:8080 204:3924 205:2168 206:2324 207:2769 208:3794 209:3501 210:2688 211:1159 212:1557 213:1629 214:67 215:29 216:4538 217:1157 218:374 219:403 220:1236 221:399 222:294 End of report From jasper at unleash.co.nz Fri Jan 2 14:07:18 2009 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Sat, 3 Jan 2009 09:07:18 +1300 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <20090102120636.3b4a9444@cs.columbia.edu> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> Message-ID: <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> On 3/01/2009, at 6:06 AM, Steven M. Bellovin wrote: > On Fri, 2 Jan 2009 17:53:55 +0100 > "Terje Bless" wrote: > >> On Fri, Jan 2, 2009 at 5:44 PM, wrote: >>> Hmm... so basically all deployed FireFox and IE either don't even >>> try to do a CRL, or they ask the dodgy certificate "Who can I ask >>> if you're dodgy?" >> >> Hmm. Don't the shipped-with-the-browser trusted root certificates >> include a CRL URL? >> >> > Every CA runs its own CRL server -- it has to be that way. But the engineered certificate won't be considered trusted if its whole chain back to the root isn't trusted, and one or more of the certificates in that chain should have been shipped with the browser and hopefully includes a CRL URL. Although they won't want to, surely the roots should revoke their root certificates that issued MD5-signed certificates, and issue new root certificates for issuing SHA-1-signed certificates. Browsers would then stop trusting all the MD5-signed certificates due to them not having a trusted chain back to the root, assuming they bother to check all the certificates in the chain for revocation. Of course, this will just make the browsers pop up dialog boxes which everyone will click OK on... -- Jasper Bryant-Greene Network Engineer, Unleash ddi: +64 3 978 1222 mob: +64 21 129 9458 From jbates at brightok.net Fri Jan 2 14:23:14 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 02 Jan 2009 14:23:14 -0600 Subject: Happy New Year! Let the botnets loose! Message-ID: <495E77B2.3000007@brightok.net> From reports in the CBL database, it appears they have enjoyed some DOS traffic yesterday, and I'm currently enjoying a little 40k+ botnet attack (small botnet beats large one when you host the victim IP). Anyone have any good resources on the breakdowns of the current known botnets and their traffic patterns? This one appears to use random IP protocol numbers, and extremely small packets. IP 255 and ICMP type 70 seem popular on this one, but I see a lot of randomness. Feel free to reply offlist if you have some good resources. Jack Bates From martin at theicelandguy.com Fri Jan 2 14:47:18 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 2 Jan 2009 15:47:18 -0500 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: References: Message-ID: Maxmind www.maxmind.com is a fairly good indicator of what geo-locators are seeing, but I recall a recent thread here that there have been disagreements between the various geolocation services. I think that some of it depends on the reference sources i.e. how many and what the algorithms are and also the update frequency. Using plain old whois data, for example, is notoriously unreliable, but definitely "usable" as a reference. Might be nice if search engines and cdn's had a verification site for checking and suggesting corrections i.e. www.favoritesearchengine.com/ipverifiy Best, Martin On Fri, Jan 2, 2009 at 9:36 AM, Frank Bulk - iName.com wrote: > We were assigned a new block from ARIN two weeks ago and are getting > several > reports from end users that the Spanish and German versions of Google's > search page are coming up. > > IP2Location and Maxmind are mostly correct, but there appears to be no way > for me to verify that Google and Akamai have 96.31.0.0/20 listed > correctly. > > Perhaps someone can point me in the right direction so I can make an > authoritative check. > > Thanks, > > Frank > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From deepak at ai.net Fri Jan 2 14:49:24 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 2 Jan 2009 15:49:24 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> Message-ID: > Of course, this will just make the browsers pop up dialog boxes which > everyone will click OK on... > And brings us to an even more interesting question, since everything is trusting their in-browser root CAs and such. How trustable is the auto-update process? If one does provoke a mass-revocation of certificates and everyone needs to update their browsers... how do the auto-update daemons *know* that what they are getting is the real deal? [I haven't looked into this, just bringing it up. I'm almost certain its less secure than the joke that is SSL certification]. Happy New Year! Deepak From smb at cs.columbia.edu Fri Jan 2 14:58:12 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 2 Jan 2009 15:58:12 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> Message-ID: <20090102155812.1cc85ee6@cs.columbia.edu> On Fri, 2 Jan 2009 15:49:24 -0500 Deepak Jain wrote: > > Of course, this will just make the browsers pop up dialog boxes > > which everyone will click OK on... > > > > And brings us to an even more interesting question, since everything > is trusting their in-browser root CAs and such. How trustable is the > auto-update process? If one does provoke a mass-revocation of > certificates and everyone needs to update their browsers... how do > the auto-update daemons *know* that what they are getting is the real > deal? > > [I haven't looked into this, just bringing it up. I'm almost certain > its less secure than the joke that is SSL certification]. > If done properly, that's actually an easier task: you build the update key into the browser. When it pulls in an update, it verifies that it was signed with the proper key. --Steve Bellovin, http://www.cs.columbia.edu/~smb From hescominsoon at emmanuelcomputerconsulting.com Fri Jan 2 15:09:32 2009 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Fri, 02 Jan 2009 16:09:32 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: Message-ID: <495E828C.3030205@emmanuelcomputerconsulting.com> Rodrick Brown wrote: > A team of security researchers and academics has broken a core piece > of Internet technology. They made their work public at the 25th Chaos > Communication Congress in Berlin today. The team was able to create a > rogue certificate authority and use it to issue valid SSL certificates > for any site they want. The user would have no indication that their > HTTPS connection was being monitored/modified. > > http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ > http://phreedom.org/research/rogue-ca/ > > > -- > [ Rodrick R. Brown ] > http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown > > > ssl itself wasn't cracked they simply exploited the known vulnerable md5 hashing. Another hashing method needs to be used. From deepak at ai.net Fri Jan 2 15:13:45 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 2 Jan 2009 16:13:45 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <20090102155812.1cc85ee6@cs.columbia.edu> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> <20090102155812.1cc85ee6@cs.columbia.edu> Message-ID: > If done properly, that's actually an easier task: you build the update > key into the browser. When it pulls in an update, it verifies that it > was signed with the proper key. > If you build it into the browser, how do you revoke it when someone throws 2000 PS3s to crack it, or your hash, or your [pick algorithmic mistake here]. Deepak From deepak at ai.net Fri Jan 2 15:16:20 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 2 Jan 2009 16:16:20 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <495E828C.3030205@emmanuelcomputerconsulting.com> References: <495E828C.3030205@emmanuelcomputerconsulting.com> Message-ID: > ssl itself wasn't cracked they simply exploited the known vulnerable > md5 > hashing. Another hashing method needs to be used. The encryption algorithm wasn't hacked. Correct. Another hashing method may help. Yup. My problem is with the chain-of-trust and a lack of reasonable or reasonably reliable (pick) ways of revoking certificates. Deepak From Skywing at valhallalegends.com Fri Jan 2 15:19:19 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 2 Jan 2009 15:19:19 -0600 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> <20090102155812.1cc85ee6@cs.columbia.edu> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5FE@caralain.haven.nynaeve.net> For IE and other things using CryptoAPI on Windows, this should be handled through the automagic root certificate update through Windows Update (if one hasn't disabled it), AFAIK. The question is really whether that mechanism requires a cert rooted at a Microsoft authority or not. The danger being that someone could use an intermediate CA rooted at an md5-signing CA and present a seemingly valid cert through that with the right common name. Some other Microsoft things (i.e. KMCS) require certs rooted to a single specific root and not just *any* global root, so it's possible that the same is done for root certificate update blobs; however, I don't know for certain, and some research would need to be done. I don't think any of the MS issuing roots use md5, though. - S -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Friday, January 02, 2009 4:14 PM To: Steven M. Bellovin Cc: NANOG Subject: RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. > If done properly, that's actually an easier task: you build the update > key into the browser. When it pulls in an update, it verifies that it > was signed with the proper key. > If you build it into the browser, how do you revoke it when someone throws 2000 PS3s to crack it, or your hash, or your [pick algorithmic mistake here]. Deepak From blakjak at blakjak.net Fri Jan 2 15:30:47 2009 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 3 Jan 2009 10:30:47 +1300 (NZDT) Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: References: Message-ID: Funny this should come up... I've found that a local Mobile Broadband outfit here in NZ are using an IP range that Akamai's Geolocation service thinks is actually in New Jersey. Causes me some oddness as a result - this despite the fact that Maxmind has it correct. Whilst investigating this (just the day before yesterday) the following URL came to my attention - allows you to check the IP you're on against Akamai's Edgescape product: http://www.akamai.com/html/technology/products/personalization.html Their customer care team were responsive to an email I sent them (but were unwilling to make changes without the request coming through their customer... which in itself seems mad, their info is wrong - why don't they correct it?) Geolocation is clever, but seems to be very retrospective, and very much an imperfect science... there should be some obligation on people offering the service to work very hard to keep their data current, given the effect it can have on an end user. Mark. On Fri, 2 Jan 2009, Martin Hannigan wrote: > Maxmind www.maxmind.com is a fairly good indicator of what geo-locators are > seeing, but I recall a recent thread here that there have been disagreements > between the various geolocation services. > > I think that some of it depends on the reference sources i.e. how many and > what the algorithms are and also the update frequency. Using plain old whois > data, for example, is notoriously unreliable, but definitely "usable" as a > reference. > > Might be nice if search engines and cdn's had a verification site for > checking and suggesting corrections i.e. > www.favoritesearchengine.com/ipverifiy > > > Best, > > Martin > > > > > On Fri, Jan 2, 2009 at 9:36 AM, Frank Bulk - iName.com wrote: > >> We were assigned a new block from ARIN two weeks ago and are getting >> several >> reports from end users that the Spanish and German versions of Google's >> search page are coming up. >> >> IP2Location and Maxmind are mostly correct, but there appears to be no way >> for me to verify that Google and Akamai have 96.31.0.0/20 listed >> correctly. >> >> Perhaps someone can point me in the right direction so I can make an >> authoritative check. >> >> Thanks, >> >> Frank >> >> >> > > > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > From jgreco at ns.sol.net Fri Jan 2 15:33:05 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Jan 2009 15:33:05 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> from "Joe Abley" at Jan 02, 2009 12:39:30 PM Message-ID: <200901022133.n02LX5G5057940@aurora.sol.net> > On 2 Jan 2009, at 12:33, Joe Greco wrote: > > > We cannot continue to justify security failure on the basis that a > > significant percentage of the clients don't support it, or are > > broken in > > their support. That's an argument for fixing the clients. > > At a more basic level, though, isn't failure guaranteed for these kind > of clients (web browsers) so long as users are conditioned to click OK/ > Continue for every SSL certificate failure that is reported to them? Yes. This is a major problem. > If I was attempting a large-scale man-in-the-middle attack, perhaps > I'd be happier to do no work and intercept 5% of sessions (those who > click OK on a certificate that is clearly bogus) than I would to do an > enormous amount of work and intercept 100% (those who would see no > warnings). And surely 5% is a massive under-estimate. Yet I do not particularly wish to ignore the problem, just because we do not have a completely comprehensive solution to the problem that solves every case and prevents every mistake. The Firefox changes to really draw attention to certificate issues is, regardless of what people have said about "usability" and "practicality," an important step. However, there's something else being highlighted here. SSL certificates have a major failing in that it is really spectacularly annoying and difficult for some people to acquire them, and/or the value in paying more than a trivial sum (or any sum) is hard to justify, etc. For example, I have absolutely no desire to pay even a modest $15/year per device to get all my various networking devices to have legitimate SSL certificates; instead, we run our own local CA and import our root CA cert into browsers. It's cheaper, *more* secure, etc. Nobody but us will be logging into our devices, and our browsers have the local root CA added. Now, many sites just don't see the need, and self-signed certs are the result. This would seem to point out some critical shortcomings in the current SSL system; these shortcomings are not necessarily technological, but rather social/psychological. We need the ability for Tom, Dick, or Harry to be able to crank out a SSL cert with a minimum of fuss or cost; having to learn the complexities of SSL is itself a "fuss" which has significantly and negatively impacted Internet security. Somehow, we managed to figure out how to do this with PGP and keysigning, but it all fell apart (I can hear the "it doesn't scale" already) with SSL. ... 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. From tomb at byrneit.net Fri Jan 2 15:53:19 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 2 Jan 2009 13:53:19 -0800 Subject: Anyone else seeing loss in SAVVIS? Message-ID: <70D072392E56884193E3D2DE09C097A90B551C@pascal.zaphodb.org> 7 170 ms 163 ms 167 ms cr2-pos-0-3-0-2.sanfrancisco.savvis.net [204.70. 95.25] 8 * 208 ms * cr1-tengig-0-15-0-0.NewYork.savvis.net [204.70.1 6.117] 9 170 ms * * kar1-ge-0-0-0.newyork.savvis.net [204.70.193.1] 10 * * * Request timed out. From jtrooney at nexdlevel.com Fri Jan 2 16:00:06 2009 From: jtrooney at nexdlevel.com (Jeff Rooney) Date: Fri, 2 Jan 2009 16:00:06 -0600 Subject: Anyone else seeing loss in SAVVIS? In-Reply-To: <70D072392E56884193E3D2DE09C097A90B551C@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A90B551C@pascal.zaphodb.org> Message-ID: I'm seeing some loss thru washington: Host Loss% Snt Last Avg Best Wrst StDev 4. 10ge.xe-0-0-0.wdc-eqx-dis-1.peer1.net 0.0% 81 1.0 1.5 0.8 19.1 2.2 5. cpr2-pos-12-0.virginiaequinix.savvis.net 0.0% 81 35.0 12.7 1.1 177.2 33.8 6. er2-tengig2-1.virginiaequinix.savvis.net 0.0% 81 1.4 4.0 0.9 163.1 19.1 7. cr2-tengig0-7-3-0.washington.savvis.net 26.2% 81 2.3 2.3 1.8 4.9 0.4 8. cr2-pos-0-7-3-2.chicago.savvis.net 0.0% 81 19.2 19.4 18.5 29.1 1.1 9. hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net 0.0% 81 20.3 23.2 19.8 159.4 17.9 On Fri, Jan 2, 2009 at 3:53 PM, Tomas L. Byrnes wrote: > 7 170 ms 163 ms 167 ms cr2-pos-0-3-0-2.sanfrancisco.savvis.net[204.70. > 95.25] > 8 * 208 ms * cr1-tengig-0-15-0-0.NewYork.savvis.net[204.70.1 > 6.117] > 9 170 ms * * kar1-ge-0-0-0.newyork.savvis.net[204.70.193.1] > 10 * * * Request timed out. > > -- Jeff Rooney jtrooney at nexdlevel.com From hrlinneweh at sbcglobal.net Fri Jan 2 16:07:46 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Fri, 2 Jan 2009 14:07:46 -0800 (PST) Subject: Anyone else seeing loss in SAVVIS? Message-ID: <295039.99357.qm@web82902.mail.mud.yahoo.com> Target Name: N/A ???????? IP: 204.70.95.25 ? Date/Time: 1/2/2009 1:59:37 PM ?1??? 1 ms??? 0 ms? home [192.168.1.254] ?2?? 11 ms?? 11 ms? adsl-75-18-183-254.dsl.pltn13.sbcglobal.net [75.18.183.254] ?3?? 10 ms?? 10 ms? [64.164.107.130] ?4?? 11 ms??? 9 ms? bb1-g3-0.pltnca.sbcglobal.net [151.164.43.54] ?5?? 12 ms?? 12 ms? ex1-p10-0.eqsjca.sbcglobal.net [151.164.191.66] ?6?? 11 ms?? 12 ms? [151.164.251.146] ?7?? 11 ms?? 12 ms? pr2-ge-2-0-0.SanJoseEquinix.savvis.net [204.70.200.130] ?8?? *?????? *?????? [-] destination address unreachable ________________________________ From: Tomas L. Byrnes To: nanog at merit.edu Sent: Friday, January 2, 2009 1:53:19 PM Subject: Anyone else seeing loss in SAVVIS? 7? 170 ms? 163 ms? 167 ms? cr2-pos-0-3-0-2.sanfrancisco.savvis.net [204.70. 95.25] 8? ? *? ? ? 208 ms? ? *? ? cr1-tengig-0-15-0-0.NewYork.savvis.net [204.70.1 6.117] 9? 170 ms? ? *? ? ? ? *? ? kar1-ge-0-0-0.newyork.savvis.net [204.70.193.1] 10? ? *? ? ? ? *? ? ? ? *? ? Request timed out. From stasinia at msoe.edu Fri Jan 2 16:14:17 2009 From: stasinia at msoe.edu (Stasiniewicz, Adam) Date: Fri, 2 Jan 2009 16:14:17 -0600 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> References: <200901021733.n02HXnAN047547@aurora.sol.net> <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> Message-ID: <001d01c96d27$7448a5c0$5cd9f140$@edu> Something worth noting. I am not sure about Firefox, but with IE 7 (and IE 6 when CRL validation is enabled) when a the browser encounters a revoked certificate, it does not present the usual "yes/no" box. Instead, one gets a message basically saying "certificate is revoked, you can't continue, period". Now, if the user is smart enough they can go into the advanced settings and turn off CRL validation and get around the error. Though not bullet-proof, that is better than just a "yes/no" box. In a perfect world, all certificate checks should result in a non-bypass-able error message. But the wide spread nature of self-signed certs and the lack of knowledge of many tech staff would make this a very hard position for any web browser vendor to swallow. In the near term, it would be nice to see browsers start to implement mandatory CRL checking for all non-self signed/root-level certificates. Ensuring that a each tier of the PKI has a time/signature valid CRL published (note, many root certificates do not publish CRL paths for themselves, hence the exception for them and self-signed). Speaking of this attack specifically. Publishing a CRL that would revoke this certificate would be basically useless. Since the CRL path that is used to valid a certificate is contained in the certificate, not the issuing CA's certificate. And a potential attacker would have little reason to point to a CRL that would incriminate themselves. (Note, there are a *few* applications that actually do mandate strict CRL checking, and thereby require the certificate to point to a valid CRL signed by the issuing CA, though they are not very common). My $0.02, Adam Stasiniewicz -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Friday, January 02, 2009 11:40 AM To: Joe Greco Cc: nanog at nanog.org Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 On 2 Jan 2009, at 12:33, Joe Greco wrote: > We cannot continue to justify security failure on the basis that a > significant percentage of the clients don't support it, or are > broken in > their support. That's an argument for fixing the clients. At a more basic level, though, isn't failure guaranteed for these kind of clients (web browsers) so long as users are conditioned to click OK/ Continue for every SSL certificate failure that is reported to them? If I was attempting a large-scale man-in-the-middle attack, perhaps I'd be happier to do no work and intercept 5% of sessions (those who click OK on a certificate that is clearly bogus) than I would to do an enormous amount of work and intercept 100% (those who would see no warnings). And surely 5% is a massive under-estimate. Joe From fw at deneb.enyo.de Fri Jan 2 16:37:56 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 02 Jan 2009 23:37:56 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901021733.n02HXnAN047547@aurora.sol.net> (Joe Greco's message of "Fri, 2 Jan 2009 11:33:48 -0600 (CST)") References: <200901021733.n02HXnAN047547@aurora.sol.net> Message-ID: <87bpupibaz.fsf@mid.deneb.enyo.de> * Joe Greco: > It seems that part of the proposed solution is to get people to move from > MD5-signed to SHA1-signed. There will be a certain amount of resistance. > What I was suggesting was the use of the revocation mechanism as part of > the "stick" (think carrot-and-stick) in a campaign to replace MD5-based > certs. If there is a credible threat to MD5-signed certs, then forcing > their retirement would seem to be a reasonable reaction, but everyone here > knows how successful "voluntary" conversion strategies typically are. A CA statement that they won't issue MD5-signed certificates in the future should be sufficient. There's no need to reissue old certificates, unless the CA thinks other customers have attacked it. > Either we take the potential for transparent MitM attacks seriously, or > we do not. I'm sure the NSA would prefer "not." :-) I doubt the NSA is interested in MITM attacks which can be spotted by comparing key material. 8-) From smb at cs.columbia.edu Fri Jan 2 16:45:56 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 2 Jan 2009 17:45:56 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> <20090102155812.1cc85ee6@cs.columbia.edu> Message-ID: <20090102174556.15b088e9@cs.columbia.edu> On Fri, 2 Jan 2009 16:13:45 -0500 Deepak Jain wrote: > > If done properly, that's actually an easier task: you build the > > update key into the browser. When it pulls in an update, it > > verifies that it was signed with the proper key. > > > > If you build it into the browser, how do you revoke it when someone > throws 2000 PS3s to crack it, or your hash, or your [pick algorithmic > mistake here]. > If you use bad crypto, you lose no matter what. If you use good crypto, 2,000,000,000 PS3s won't do the job. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Skywing at valhallalegends.com Fri Jan 2 16:51:53 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 2 Jan 2009 16:51:53 -0600 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FEE@caralain.haven.nynaeve.net> Of course, md5 *used* to be good crypto. ? S -----Original Message----- From: Steven M. Bellovin Sent: Friday, January 02, 2009 14:46 To: Deepak Jain Cc: NANOG Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. On Fri, 2 Jan 2009 16:13:45 -0500 Deepak Jain wrote: > > If done properly, that's actually an easier task: you build the > > update key into the browser. When it pulls in an update, it > > verifies that it was signed with the proper key. > > > > If you build it into the browser, how do you revoke it when someone > throws 2000 PS3s to crack it, or your hash, or your [pick algorithmic > mistake here]. > If you use bad crypto, you lose no matter what. If you use good crypto, 2,000,000,000 PS3s won't do the job. --Steve Bellovin, http://www.cs.columbia.edu/~smb From smb at cs.columbia.edu Fri Jan 2 17:07:48 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 2 Jan 2009 18:07:48 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FEE@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FEE@caralain.haven.nynaeve.net> Message-ID: <20090102180748.0206401b@cs.columbia.edu> On Fri, 2 Jan 2009 16:51:53 -0600 Skywing wrote: > Of course, md5 *used* to be good crypto. > See http://www.cs.columbia.edu/~smb/blog/2008-12/2008-12-30.html for the links, but MD5 has been suspect for a very long time. Dobbertin found problems with it in 1996. The need for caution with it was not just knowable but known, and stated publicly. I'm sure others did so as well; I can only easily quote my own works. From the second edition of my Firewalls book, in 2003: Additionally, \i{SHA} has replaced \i{MD5}, as the latter appears to be weaker than previously believed. and Hints of weakness have shown up in MD5 and RIPEMD-160; cautious people will eschew them, though none of the attacks are of use against either function when used with HMAC\@. As of this writing, the \i{NIST} algorithm appears to be the best choice. For many purposes, the newer versions of SHA are better; these have block sizes ranging from 256 to 512 bits. Even if that were not enough, Wang et al presented the actual collisions in 2004. There have been many updates and patches to more or less everything since then... Yes -- if you pick something that's very weak, you can get caught by surprise. But modern algorithms don't fall all at once. I should add, of course, that if you use bad algorithms or bad protocols, it doesn't matter where you store the public key. When I said that the update problem was easier, what I was saying is that you're not relying on outside parties for verification of identity, etc., it's all your own data. --Steve Bellovin, http://www.cs.columbia.edu/~smb From mike.lyon at gmail.com Fri Jan 2 17:19:16 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 2 Jan 2009 15:19:16 -0800 Subject: London Demon Internet NOC/ENG contact? Message-ID: <1b5c1c150901021519p25137be5r9dca2afd4cbc63ff@mail.gmail.com> Could you please hit me up off list? E-mails to your helpdesk and NOC have gone unanswered. It's in regards to a routing loop: 16 227 ms 204 ms 204 ms park-ll-1-7200.access.demon.net[194.159.245.133] 17 225 ms 204 ms 204 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] 18 175 ms 204 ms 204 ms 194.159.245.129 19 175 ms 204 ms 204 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] 20 227 ms 204 ms 204 ms 194.159.245.129 21 227 ms 204 ms 204 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] 22 227 ms 204 ms 204 ms 194.159.245.129 23 227 ms 205 ms 203 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] Thanks in advance. Cheers, Mike From kngspook at gmail.com Fri Jan 2 17:21:06 2009 From: kngspook at gmail.com (Neil) Date: Fri, 2 Jan 2009 15:21:06 -0800 Subject: RR Routing Loop? Message-ID: <77e4079b0901021521j3a482dedk68d2167722edfc7c@mail.gmail.com> So my night was fun: I was in the middle of configuring a mail server over SSH when suddenly it goes unresponsive... It seems (to me, but I'm by no means an expert) to be a routing loop. This is off a residential line in Southern California, between about 2-4:30am PST. Does anyone know what was going on there? 1 cpe-75-82-48-1.socal.res.rr.com (75.82.48.1) 23.890 ms 11.594 ms 10.598 ms 2 gig11-35.vnnyca2-rtr2.socal.rr.com (76.167.5.141) 12.732 ms 11.605 ms 10.378 ms 3 * * * 4 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 28.318 ms 30.164 ms 25.177 ms 5 * * * 6 * * * 7 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 43.524 ms 43.117 ms 42.888 ms 8 * * * 9 * * * 10 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 60.265 ms 59.196 ms 59.076 ms 11 * * * 12 * * * [snip] 28 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 150.724 ms 154.224 ms * 29 prt23.vnnyca2-rtr1.socal.rr.com (76.167.2.11) 154.232 ms * * [snip] 56 * * * 57 * * * 58 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 173.394 ms 173.101 ms 168.737 ms 59 * * * 60 * * * 61 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 178.986 ms 178.072 ms * 62 * * * 63 * * * 64 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 189.424 ms 188.331 ms 196.333 ms From Skywing at valhallalegends.com Fri Jan 2 17:21:25 2009 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 2 Jan 2009 17:21:25 -0600 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> That md5 has now been deprecated for awhile is certainly also true; and people should have definitely moved on by now. Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. We still have a long way to go. :) ? S -----Original Message----- From: Steven M. Bellovin Sent: Friday, January 02, 2009 15:07 To: Skywing Cc: Deepak Jain ; NANOG Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. On Fri, 2 Jan 2009 16:51:53 -0600 Skywing wrote: > Of course, md5 *used* to be good crypto. > See http://www.cs.columbia.edu/~smb/blog/2008-12/2008-12-30.html for the links, but MD5 has been suspect for a very long time. Dobbertin found problems with it in 1996. The need for caution with it was not just knowable but known, and stated publicly. I'm sure others did so as well; I can only easily quote my own works. From the second edition of my Firewalls book, in 2003: Additionally, \i{SHA} has replaced \i{MD5}, as the latter appears to be weaker than previously believed. and Hints of weakness have shown up in MD5 and RIPEMD-160; cautious people will eschew them, though none of the attacks are of use against either function when used with HMAC\@. As of this writing, the \i{NIST} algorithm appears to be the best choice. For many purposes, the newer versions of SHA are better; these have block sizes ranging from 256 to 512 bits. Even if that were not enough, Wang et al presented the actual collisions in 2004. There have been many updates and patches to more or less everything since then... Yes -- if you pick something that's very weak, you can get caught by surprise. But modern algorithms don't fall all at once. I should add, of course, that if you use bad algorithms or bad protocols, it doesn't matter where you store the public key. When I said that the update problem was easier, what I was saying is that you're not relying on outside parties for verification of identity, etc., it's all your own data. --Steve Bellovin, http://www.cs.columbia.edu/~smb From deepak at ai.net Fri Jan 2 17:26:33 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 2 Jan 2009 18:26:33 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <20090102174556.15b088e9@cs.columbia.edu> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <15115.1230914673@turing-police.cc.vt.edu> <47ac005a0901020853v2e46b07cr8c09a92e746d505e@mail.gmail.com> <20090102120636.3b4a9444@cs.columbia.edu> <8B0CF863-02FA-4580-8E2E-3D7A8DFBB8BF@unleash.co.nz> <20090102155812.1cc85ee6@cs.columbia.edu> <20090102174556.15b088e9@cs.columbia.edu> Message-ID: > If you use bad crypto, you lose no matter what. If you use good > crypto, 2,000,000,000 PS3s won't do the job. > Even if you use good crypto, and someone steals your key (say, a previously in-access person) you need a way to reliably, completely, revoke it. This has been a problem with SSL since its [implementation] inception. Lots of math (crypto) is good on paper and fails at the implementation stage. Deepak From jgreco at ns.sol.net Fri Jan 2 17:29:56 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Jan 2009 17:29:56 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <87bpupibaz.fsf@mid.deneb.enyo.de> from "Florian Weimer" at Jan 02, 2009 11:37:56 PM Message-ID: <200901022329.n02NTuj6063258@aurora.sol.net> > * Joe Greco: > > It seems that part of the proposed solution is to get people to move from > > MD5-signed to SHA1-signed. There will be a certain amount of resistance. > > What I was suggesting was the use of the revocation mechanism as part of > > the "stick" (think carrot-and-stick) in a campaign to replace MD5-based > > certs. If there is a credible threat to MD5-signed certs, then forcing > > their retirement would seem to be a reasonable reaction, but everyone here > > knows how successful "voluntary" conversion strategies typically are. > > A CA statement that they won't issue MD5-signed certificates in the > future should be sufficient. There's no need to reissue old > certificates, unless the CA thinks other customers have attacked it. That would seem to be at odds with what the people who documented this problem believe. > > Either we take the potential for transparent MitM attacks seriously, or > > we do not. I'm sure the NSA would prefer "not." :-) > > I doubt the NSA is interested in MITM attacks which can be spotted by > comparing key material. 8-) Doubting that the NSA might be interested in any given technique is, of course, good for the NSA. Our national security people have been known to use imperfect interception technologies when it suits the task at hand. Do people here really so quickly forget things? There was a talk on Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the instigating causes of that talk was problems that Earthlink had experienced when the FBI had deployed Carnivore there. ... 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. From kngspook at gmail.com Fri Jan 2 17:30:47 2009 From: kngspook at gmail.com (Neil) Date: Fri, 2 Jan 2009 15:30:47 -0800 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: References: Message-ID: <77e4079b0901021530l4c22a28fv392d87cf9c21e644@mail.gmail.com> Or maybe they just shouldn't rely on it so much. It annoys me at the hoops I have to jump through to change the language on Google-owned properties when they think I'm coming from Czechoslovakia or Malaysia or some such... Some, like Blogger, still don't do it right... On Fri, Jan 2, 2009 at 1:30 PM, Mark Foster wrote: > Funny this should come up... > > I've found that a local Mobile Broadband outfit here in NZ are using an IP > range that Akamai's Geolocation service thinks is actually in New Jersey. > Causes me some oddness as a result - this despite the fact that Maxmind has > it correct. > Whilst investigating this (just the day before yesterday) the following URL > came to my attention - allows you to check the IP you're on against Akamai's > Edgescape product: > > http://www.akamai.com/html/technology/products/personalization.html > > Their customer care team were responsive to an email I sent them (but were > unwilling to make changes without the request coming through their > customer... which in itself seems mad, their info is wrong - why don't they > correct it?) > > Geolocation is clever, but seems to be very retrospective, and very much an > imperfect science... there should be some obligation on people offering the > service to work very hard to keep their data current, given the effect it > can have on an end user. > > Mark. > > On Fri, 2 Jan 2009, Martin Hannigan wrote: > >> Maxmind www.maxmind.com is a fairly good indicator of what geo-locators >> are >> seeing, but I recall a recent thread here that there have been >> disagreements >> between the various geolocation services. >> >> I think that some of it depends on the reference sources i.e. how many and >> what the algorithms are and also the update frequency. Using plain old >> whois >> data, for example, is notoriously unreliable, but definitely "usable" as a >> reference. >> >> Might be nice if search engines and cdn's had a verification site for >> checking and suggesting corrections i.e. >> www.favoritesearchengine.com/ipverifiy >> >> >> Best, >> >> Martin >> >> >> >> >> On Fri, Jan 2, 2009 at 9:36 AM, Frank Bulk - iName.com >> wrote: >> >>> We were assigned a new block from ARIN two weeks ago and are getting >>> several >>> reports from end users that the Spanish and German versions of Google's >>> search page are coming up. >>> >>> IP2Location and Maxmind are mostly correct, but there appears to be no >>> way >>> for me to verify that Google and Akamai have 96.31.0.0/20 listed >>> correctly. >>> >>> Perhaps someone can point me in the right direction so I can make an >>> authoritative check. >>> >>> Thanks, >>> >>> Frank >>> >>> >>> >> >> >> -- >> Martin Hannigan martin at theicelandguy.com >> p: +16178216079 >> > > From kngspook at gmail.com Fri Jan 2 17:37:51 2009 From: kngspook at gmail.com (Neil) Date: Fri, 2 Jan 2009 15:37:51 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901022329.n02NTuj6063258@aurora.sol.net> References: <87bpupibaz.fsf@mid.deneb.enyo.de> <200901022329.n02NTuj6063258@aurora.sol.net> Message-ID: <77e4079b0901021537w72b5eb2dx379b70b1b2b54211@mail.gmail.com> On Fri, Jan 2, 2009 at 3:29 PM, Joe Greco wrote: >> * Joe Greco: [snip >> > Either we take the potential for transparent MitM attacks seriously, or >> > we do not. I'm sure the NSA would prefer "not." :-) >> >> I doubt the NSA is interested in MITM attacks which can be spotted by >> comparing key material. 8-) > > Doubting that the NSA might be interested in any given technique is, of > course, good for the NSA. Our national security people have been known > to use imperfect interception technologies when it suits the task at hand. > Do people here really so quickly forget things? There was a talk on > Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the > instigating causes of that talk was problems that Earthlink had experienced > when the FBI had deployed Carnivore there. > Naturally. The NSA isn't filled with theorists who want to get the job done the "right" way. They have a mission to fulfill, and they'll use whatever tool works to get it done. From shrdlu at deaddrop.org Fri Jan 2 18:43:53 2009 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Fri, 02 Jan 2009 16:43:53 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <77e4079b0901021537w72b5eb2dx379b70b1b2b54211@mail.gmail.com> References: <87bpupibaz.fsf@mid.deneb.enyo.de> <200901022329.n02NTuj6063258@aurora.sol.net> <77e4079b0901021537w72b5eb2dx379b70b1b2b54211@mail.gmail.com> Message-ID: <495EB4C9.1010207@deaddrop.org> Neil wrote: >>Do people here really so quickly forget things? There was a talk on >>Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the >>instigating causes of that talk was problems that Earthlink had experienced >>when the FBI had deployed Carnivore there. > Naturally. The NSA isn't filled with theorists who want to get the > job done the "right" way. They have a mission to fulfill, and they'll > use whatever tool works to get it done. Just a slight point of order, here. Carnivore (and its successor, DCS1000) were used by, and developed by, the FBI. The NSA use other stuff. Let's get back to reality, anyway. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan From dr at kyx.net Fri Jan 2 20:32:01 2009 From: dr at kyx.net (Dragos Ruiu) Date: Fri, 2 Jan 2009 18:32:01 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <495E5543.20504@hawaii.edu> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> Message-ID: <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: > Joe Greco wrote: >> [ .... ] >> >> Either we take the potential for transparent MitM attacks >> seriously, or >> we do not. I'm sure the NSA would prefer "not." :-) >> >> As for the points raised in your message, yes, there are additional >> problems with clients that have not taken this seriously. It is, >> however, >> one thing to have locks on your door that you do not lock, and >> another >> thing entirely not to have locks (and therefore completely lack the >> ability to lock). I hope that there is some serious thought going >> on in >> the browser groups about this sort of issue. >> >> [ ... ] >> >> ... JG > > F Y I, see: > > SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' > certificates @ > http://www.codefromthe70s.org/sslblacklist.aspx > > Best. Snort rule to detect said... url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"POLICY Weak SSL OSCP response -- MD5 usage"; content:"content-type: application/ ocsp-response"; content:"2A 86 48 86 F7 0D 01 01 05"; metadata: policy security-ips drop, service http; reference: url, www.win.tue.nl/hashclash/rogue-ca/ ; classtype: policy-violation; sid:1000001;) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From ge at linuxbox.org Fri Jan 2 20:53:06 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 2 Jan 2009 20:53:06 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> Message-ID: On Fri, 2 Jan 2009, Dragos Ruiu wrote: > www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; > sid:1000001;) You can't really use any snort rule to detect SHA-1 certs created by a fake authority created using the MD5 issue. Yes, this is a serious matter, but it hardly has any operational impact to speak of for users and none for NSPs. Gadi. From jgreco at ns.sol.net Fri Jan 2 21:30:51 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 2 Jan 2009 21:30:51 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <495EB4C9.1010207@deaddrop.org> from "Etaoin Shrdlu" at Jan 02, 2009 04:43:53 PM Message-ID: <200901030330.n033UqKP074017@aurora.sol.net> > Neil wrote: > > >>Do people here really so quickly forget things? There was a talk on > >>Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the > >>instigating causes of that talk was problems that Earthlink had experienced > >>when the FBI had deployed Carnivore there. > > > Naturally. The NSA isn't filled with theorists who want to get the > > job done the "right" way. They have a mission to fulfill, and they'll > > use whatever tool works to get it done. > > Just a slight point of order, here. Carnivore (and its successor, > DCS1000) were used by, and developed by, the FBI. The NSA use other > stuff. Let's get back to reality, anyway. Both the FBI and NSA are our "national security people." Since there are not many visible examples of failures of NSA technology, and because such failures are more likely to be covered up, pointing out an obvious screwup that was more readily visible seems reasonable. As a further point of order, I expect that the NSA has access to any tools that the FBI has developed, if and when they ask for them, especially now, in our new and less compartmentalized homeland security infrastructure. Unless, of course, you're saying that you work for the NSA and you actually know this not to be the case, in which case, do tell. ... 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. From dr at kyx.net Fri Jan 2 21:44:05 2009 From: dr at kyx.net (Dragos Ruiu) Date: Fri, 2 Jan 2009 19:44:05 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> Message-ID: <519E6B84-3794-41AE-9D92-D052744D520C@kyx.net> On 2-Jan-09, at 6:53 PM, Gadi Evron wrote: > Yes, this is a serious matter, but it hardly has any operational > impact to speak of for users and none for NSPs. Dunno. Last I checked NSPs had web servers too. :-P cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From morrowc.lists at gmail.com Sat Jan 3 00:31:08 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 3 Jan 2009 01:31:08 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <519E6B84-3794-41AE-9D92-D052744D520C@kyx.net> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <519E6B84-3794-41AE-9D92-D052744D520C@kyx.net> Message-ID: <75cb24520901022231x41bdc1bcv85429e8bca8ac943@mail.gmail.com> On Fri, Jan 2, 2009 at 10:44 PM, Dragos Ruiu wrote: > > On 2-Jan-09, at 6:53 PM, Gadi Evron wrote: >> >> Yes, this is a serious matter, but it hardly has any operational impact to >> speak of for users and none for NSPs. > > Dunno. Last I checked NSPs had web servers too. :-P so, aside from 'get a re-issued cert signed SHA-1 from an approved CA that's SHA-1 signed as well' what's the recourse for an NSP? -chris From martin at theicelandguy.com Sat Jan 3 00:31:28 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 3 Jan 2009 01:31:28 -0500 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: <77e4079b0901021530l4c22a28fv392d87cf9c21e644@mail.gmail.com> References: <77e4079b0901021530l4c22a28fv392d87cf9c21e644@mail.gmail.com> Message-ID: On Fri, Jan 2, 2009 at 6:30 PM, Neil wrote: > Or maybe they just shouldn't rely on it so much. > > It annoys me at the hoops I have to jump through to change the > language on Google-owned properties when they think I'm coming from > Czechoslovakia or Malaysia or some such... Some, like Blogger, still > don't do it right... > > [ clip ] > > > > http://www.akamai.com/html/technology/products/personalization.html > > > Like what? I have found that interacting with your favorite search engine is generally easy and interactive as long as you know where to look. I think that's really the problem at hand, the interaction and where you actually do it. Overall, geo location has turned out to be a somewhat valuable tool in terms of language, fraud, and localization. I think that it's important to continue to urge improvements in this technology, not divestment. NoSoObOp: Renesys ought to be playing in this space. :-) Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From chort at smtps.net Sat Jan 3 01:20:52 2009 From: chort at smtps.net (Brian Keefer) Date: Fri, 2 Jan 2009 23:20:52 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901022329.n02NTuj6063258@aurora.sol.net> References: <200901022329.n02NTuj6063258@aurora.sol.net> Message-ID: On Jan 2, 2009, at 3:29 PM, Joe Greco wrote: >> * Joe Greco: >>> It seems that part of the proposed solution is to get people to >>> move from >>> MD5-signed to SHA1-signed. There will be a certain amount of >>> resistance. >>> What I was suggesting was the use of the revocation mechanism as >>> part of >>> the "stick" (think carrot-and-stick) in a campaign to replace MD5- >>> based >>> certs. If there is a credible threat to MD5-signed certs, then >>> forcing >>> their retirement would seem to be a reasonable reaction, but >>> everyone here >>> knows how successful "voluntary" conversion strategies typically >>> are. >> >> A CA statement that they won't issue MD5-signed certificates in the >> future should be sufficient. There's no need to reissue old >> certificates, unless the CA thinks other customers have attacked it. > > That would seem to be at odds with what the people who documented this > problem believe. I do not wish to be rude, so don't think that's my intent--however, clarification is required here I believe. From section 7 of http://www.win.tue.nl/hashclash/rogue-ca/ : "An interesting question is whether CAs should revoke existing certificates signed using MD5. One may argue that the present attack scenario has in principle been possible since May 2007, and that therefore all certificates (or all CA certificates) signed with MD5 that have been issued after this date may have been compromised. Whether they really have been compromised is not relevant. What is relevant is that the relying party who needs to trust the certificate does not have a proper way of checking whether the certificate is to be trusted or not. One may even argue that all older certificates based on MD5 should be revoked, as for an attacker constructing rogue certificates it is easy to backdate them to any date in the past he likes, so any MD5-based certificate may be a forgery. On the other hand, one may argue that the likelihood of these scenarios is quite small, and that the cost of replacing many MD5- based certificates may be substantial, so that therefore the risks of continued use of existing MD5-based certificates may be seen as acceptable. Regardless, MD5 should no longer be used for new certificates." Note that they aren't actually recommending that all certs with MD5 signatures be replaced. The authors present two sides of the argument. The only absolute statement is that MD5 should not be used to sign _new_ certificates. This is because the attack doesn't allow the impersonation of the vulnerable CA; the attack merely creates a new intermediate CA that maintains the "chain of trust", so that certificates issued by the rogue intermediate CA will be trusted by most browsers. The weakness isn't that the vulnerable CA root certificate is signed by MD5, the weakness is that it uses MD5 to sign CSRs. Since I'm probably not explaining this very well, a picture is worth a thousand words: http://www.win.tue.nl/hashclash/rogue-ca/images/certificate4.png Additionally, from second 8: "Question. Are all digital certificates/signatures broken? Answer. No. When digital certificates and signatures are based on secure cryptographic hash functions, our work yields no reason to doubt their security. Our result only applies when digital certificates are signed using the hash function MD5, which is known to be broken. With our method it is only possible to copy digital signatures based on MD5 between two specially constructed digital certificates. It is not possible to copy digital signatures based on MD5 from digital certificates unless the certificates are specially constructed. Even so, our result shows that MD5 is NOT suited for digital signatures. Certification Authorities should stop using the known broken MD5 and move to the widely available, more secure alternatives, such as SHA-2." and "Question. What should websites do that have digital certificates signed with MD5? Answer. Nothing at this point. Digital certificates legitimately obtained from all CAs can be believed to be secure and trusted, even if they were signed with MD5. Our method required the purchase of a specially crafted digital certificate from a CA and does not affect certificates issued to any other regular website." My apologies if you were commenting on some other aspect, or if my understand is in some way flawed. -- bk CA cert: http://www.smtps.net/pub/smtps-dot-net-ca-2.pem -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1613 bytes Desc: not available URL: From fw at deneb.enyo.de Sat Jan 3 07:57:59 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 03 Jan 2009 14:57:59 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901022329.n02NTuj6063258@aurora.sol.net> (Joe Greco's message of "Fri, 2 Jan 2009 17:29:56 -0600 (CST)") References: <200901022329.n02NTuj6063258@aurora.sol.net> Message-ID: <87y6xsa3vc.fsf@mid.deneb.enyo.de> * Joe Greco: >> A CA statement that they won't issue MD5-signed certificates in the >> future should be sufficient. There's no need to reissue old >> certificates, unless the CA thinks other customers have attacked it. > > That would seem to be at odds with what the people who documented this > problem believe. What do they believe? That the CA should reissue certificates even if the CA assumes that there haven't been other attacks? Or that the CA should not reissue, despite evidence of other attacks? From chaz at chaz6.com Sat Jan 3 05:44:49 2009 From: chaz at chaz6.com (Chris Hills) Date: Sat, 03 Jan 2009 12:44:49 +0100 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: References: <77e4079b0901021530l4c22a28fv392d87cf9c21e644@mail.gmail.com> Message-ID: On 03/01/09 07:31, Martin Hannigan wrote: > Overall, geo location has turned out to be a somewhat valuable tool in terms > of language, fraud, and localization. I think that it's important to > continue to urge improvements in this technology, not divestment. Is it really that difficult to check the Accept-Language header for determining the language to use? This is particularly useful in countries that either have no official language, countries that have more than one official language, and tourists. From hescominsoon at emmanuelcomputerconsulting.com Sat Jan 3 08:35:06 2009 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sat, 03 Jan 2009 09:35:06 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> Message-ID: <495F779A.9000905@emmanuelcomputerconsulting.com> Dragos Ruiu wrote: > > On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: > >> Joe Greco wrote: >>> [ .... ] >>> >>> Either we take the potential for transparent MitM attacks seriously, or >>> we do not. I'm sure the NSA would prefer "not." :-) >>> >>> As for the points raised in your message, yes, there are additional >>> problems with clients that have not taken this seriously. It is, >>> however, >>> one thing to have locks on your door that you do not lock, and another >>> thing entirely not to have locks (and therefore completely lack the >>> ability to lock). I hope that there is some serious thought going >>> on in >>> the browser groups about this sort of issue. >>> >>> [ ... ] >>> >>> ... JG >> >> F Y I, see: >> >> SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' >> certificates @ >> http://www.codefromthe70s.org/sslblacklist.aspx >> >> Best. > > Snort rule to detect said... > > url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html > > alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"POLICY Weak > SSL OSCP response -- MD5 usage"; content:"content-type: > application/ocsp-response"; content:"2A 86 48 86 F7 0D 01 01 05"; > metadata: policy security-ips drop, service http; reference: url, > www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; > sid:1000001;) > > cheers, > --dr > > -- > World Security Pros. Cutting Edge Training, Tools, and Techniques > Vancouver, Canada March 16-20 2009 http://cansecwest.com > London, U.K. May 27/28 2009 http://eusecwest.com > pgpkey http://dragos.com/ kyxpgp > > > Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So we trade MD5 for SHA-1? This makes no sense. From dhetzel at gmail.com Sat Jan 3 08:38:10 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Sat, 3 Jan 2009 09:38:10 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <495F779A.9000905@emmanuelcomputerconsulting.com> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> Message-ID: <7db2dcf90901030638m146eaanf3784fcda41a3ae7@mail.gmail.com> Would using the combination of both MD5 and SHA-1 raise the computational bar enough for now, or are there other good prospects for a harder to crack hash? On Sat, Jan 3, 2009 at 9:35 AM, William Warren < hescominsoon at emmanuelcomputerconsulting.com> wrote: > Dragos Ruiu wrote: > >> >> On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: >> >> Joe Greco wrote: >>> >>>> [ .... ] >>>> >>>> Either we take the potential for transparent MitM attacks seriously, or >>>> we do not. I'm sure the NSA would prefer "not." :-) >>>> >>>> As for the points raised in your message, yes, there are additional >>>> problems with clients that have not taken this seriously. It is, >>>> however, >>>> one thing to have locks on your door that you do not lock, and another >>>> thing entirely not to have locks (and therefore completely lack the >>>> ability to lock). I hope that there is some serious thought going on in >>>> the browser groups about this sort of issue. >>>> >>>> [ ... ] >>>> >>>> ... JG >>>> >>> >>> F Y I, see: >>> >>> SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' >>> certificates @ >>> http://www.codefromthe70s.org/sslblacklist.aspx >>> >>> Best. >>> >> >> Snort rule to detect said... >> >> url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html >> >> alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"POLICY Weak SSL >> OSCP response -- MD5 usage"; content:"content-type: >> application/ocsp-response"; content:"2A 86 48 86 F7 0D 01 01 05"; metadata: >> policy security-ips drop, service http; reference: url, >> www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; >> sid:1000001;) >> >> cheers, >> --dr >> >> -- >> World Security Pros. Cutting Edge Training, Tools, and Techniques >> Vancouver, Canada March 16-20 2009 http://cansecwest.com >> London, U.K. May 27/28 2009 http://eusecwest.com >> pgpkey http://dragos.com/ kyxpgp >> >> >> >> Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. So > we trade MD5 for SHA-1? This makes no sense. > > From tme at multicasttech.com Sat Jan 3 09:36:08 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 3 Jan 2009 10:36:08 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <7db2dcf90901030638m146eaanf3784fcda41a3ae7@mail.gmail.com> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> <7db2dcf90901030638m146eaanf3784fcda41a3ae7@mail.gmail.com> Message-ID: <1AA295BE-45E7-4E9A-808F-F05A1C6FBA34@multicasttech.com> On Jan 3, 2009, at 9:38 AM, Dorn Hetzel wrote: > Would using the combination of both MD5 and SHA-1 raise the > computational > bar enough for now, I have never seen this recommended (and I do try and follow this). > or are there other good prospects for a harder to crack > hash? The Federal Information Processing Standard 180-2, Secure Hash Standard, specifies algorithms for computing five cryptographic hash functions ? SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. SHA-256 is thought to be still safe, unlike SHA-1 http://eprint.iacr.org/2008/271 http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html and its use is recommended by RFC4509. http://tools.ietf.org/html/rfc4509 So, I would use SHA-256 if possible. (SHA-224 is a truncation of -256 - see rfc3874.) There is, BTW, a competition to find a replacement. http://csrc.nist.gov/groups/ST/hash/sha-3/index.html Regards Marshall > > > On Sat, Jan 3, 2009 at 9:35 AM, William Warren < > hescominsoon at emmanuelcomputerconsulting.com> wrote: > >> Dragos Ruiu wrote: >> >>> >>> On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote: >>> >>> Joe Greco wrote: >>>> >>>>> [ .... ] >>>>> >>>>> Either we take the potential for transparent MitM attacks >>>>> seriously, or >>>>> we do not. I'm sure the NSA would prefer "not." :-) >>>>> >>>>> As for the points raised in your message, yes, there are >>>>> additional >>>>> problems with clients that have not taken this seriously. It is, >>>>> however, >>>>> one thing to have locks on your door that you do not lock, and >>>>> another >>>>> thing entirely not to have locks (and therefore completely lack >>>>> the >>>>> ability to lock). I hope that there is some serious thought >>>>> going on in >>>>> the browser groups about this sort of issue. >>>>> >>>>> [ ... ] >>>>> >>>>> ... JG >>>>> >>>> >>>> F Y I, see: >>>> >>>> SSL Blacklist 4.0 - for a Firefox extension able to detect 'bad' >>>> certificates @ >>>> http://www.codefromthe70s.org/sslblacklist.aspx >>>> >>>> Best. >>>> >>> >>> Snort rule to detect said... >>> >>> url: http://vrt-sourcefire.blogspot.com/2009/01/md5-actually-harmful.html >>> >>> alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"POLICY >>> Weak SSL >>> OSCP response -- MD5 usage"; content:"content-type: >>> application/ocsp-response"; content:"2A 86 48 86 F7 0D 01 01 05"; >>> metadata: >>> policy security-ips drop, service http; reference: url, >>> www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation; >>> sid:1000001;) >>> >>> cheers, >>> --dr >>> >>> -- >>> World Security Pros. Cutting Edge Training, Tools, and Techniques >>> Vancouver, Canada March 16-20 2009 http://cansecwest.com >>> London, U.K. May 27/28 2009 http://eusecwest.com >>> pgpkey http://dragos.com/ kyxpgp >>> >>> >>> >>> Everyone seems to be stampeding to SHA-1..yet it was broken in >>> 2005. So >> we trade MD5 for SHA-1? This makes no sense. >> >> From fw at deneb.enyo.de Sat Jan 3 09:45:58 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 03 Jan 2009 16:45:58 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: (Brian Keefer's message of "Fri, 2 Jan 2009 23:20:52 -0800") References: <200901022329.n02NTuj6063258@aurora.sol.net> Message-ID: <87eizk8kax.fsf@mid.deneb.enyo.de> * Brian Keefer: > My apologies if you were commenting on some other aspect, or if my > understand is in some way flawed. I don't think so. There's a rule of thumb which is easy to remembe: Never revoke anything just because some weak algorithm is involved. The rationale is that that revocation is absolute and (usually) retroactive, but we generally want a more nuanced approach. If certain algorithms are too weak to be used, this is up to the relying party to decide whether it's fine in a particular case. On the other hand, replacing MD5-signed certificates in the browser PKI is costly, but the overhead is very finely dispersed (assuming that reissuing certificates has very little overhead at the CA). I think it's doable if the browser vendors could agree on a flag date after which MD5 signatures on certificates are no longer considered valid. (The implicit assumptions in that rule of thumb do not always apply. For instance, if weak RSA keys are discovered which occur with sufficiently high probability as the result of the standard key generating algorithms to pose a real problem, the public key may not reveal this property immediately, it may only be evident from the private key, or only after a rather expensive computation. In the latter case, we would be in very deep trouble.) From smb at cs.columbia.edu Sat Jan 3 09:49:04 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 3 Jan 2009 10:49:04 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <495F779A.9000905@emmanuelcomputerconsulting.com> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> Message-ID: <20090103104904.56562d56@cs.columbia.edu> On Sat, 03 Jan 2009 09:35:06 -0500 William Warren wrote: > Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. > So we trade MD5 for SHA-1? This makes no sense. > (a) SHA-1 was not broken as badly. The best attack is, as I recall, 2^63, which is computationally infeasible without special-purpose hardware. (b) Per a paper Eric Rescorla and I wrote, there's no usable alternative, since too many protocols (including TLS) don't negotiate hash functions before presenting certificates. In particular, this means that a web site can't use SHA-256 because (1) most clients won't support it; and (2) it can't tell which ones do. (Note that this argument applies just as much to combinations of hash functions -- anything that *the large majority of today's* browsers don't implement isn't usable.) These two points lead us to (c): security is a matter of economics, not algorithms. Switching now to something else loses more in connectivity or customers than you would lose from such an expensive attack. --Steve Bellovin, http://www.cs.columbia.edu/~smb From fw at deneb.enyo.de Sat Jan 3 10:23:06 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 03 Jan 2009 17:23:06 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> (Skywing@valhallalegends.com's message of "Fri, 2 Jan 2009 17:21:25 -0600") References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> Message-ID: <87ljts5pg5.fsf@mid.deneb.enyo.de> > Then again, I just got yet another Debian DSA mail which has > plaintext download links for new binaries. The integrity > verification mechanism for said binaries is, you guessed it: > PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files. From hank at efes.iucc.ac.il Sat Jan 3 10:53:25 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 3 Jan 2009 18:53:25 +0200 (IST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: On Fri, 2 Jan 2009, Mikael Abrahamsson wrote: > MD5 is broken, don't use it for anything important. You mean like for BGP neighbors? Wanna suggest an alternative? :-) -Hank From martin at airwire.ie Sat Jan 3 10:58:16 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 03 Jan 2009 16:58:16 +0000 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: <495F9928.8010201@airwire.ie> Hank Nussbacher wrote: > On Fri, 2 Jan 2009, Mikael Abrahamsson wrote: > >> MD5 is broken, don't use it for anything important. > > You mean like for BGP neighbors? Wanna suggest an alternative? :-) > MD5 on BGP sessions has already been proven to not being that effective anyhow, for the purpose that it was intended for. I don't think these findings will make any difference there. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From martin at theicelandguy.com Sat Jan 3 10:59:40 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 3 Jan 2009 11:59:40 -0500 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: References: <77e4079b0901021530l4c22a28fv392d87cf9c21e644@mail.gmail.com> Message-ID: On Sat, Jan 3, 2009 at 6:44 AM, Chris Hills wrote: > On 03/01/09 07:31, Martin Hannigan wrote: > >> Overall, geo location has turned out to be a somewhat valuable tool in >> terms >> of language, fraud, and localization. I think that it's important to >> continue to urge improvements in this technology, not divestment. >> > > Is it really that difficult to check the Accept-Language header for > determining the language to use? This is particularly useful in countries > that either have no official language, countries that have more than one > official language, and tourists. What's the accuracy rate? Combined, it is probably higher for that specific use case. I digress, ask your favorite search engine. Perhaps they'll explain. It is certainly interesting. [I think that] Over the last year we're seeing an uptick in geo-location problems addressed on NANOG because it's becoming profitable (whether through ads or fraud correlation through ip reputation) and it's probably not going away. Personally, I'd be happier with the publicly available checker. *shrug* YMMV and Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From morrowc.lists at gmail.com Sat Jan 3 11:31:53 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 3 Jan 2009 12:31:53 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <20090103104904.56562d56@cs.columbia.edu> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> <20090103104904.56562d56@cs.columbia.edu> Message-ID: <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> On Sat, Jan 3, 2009 at 10:49 AM, Steven M. Bellovin wrote: > On Sat, 03 Jan 2009 09:35:06 -0500 > William Warren wrote: > >> Everyone seems to be stampeding to SHA-1..yet it was broken in 2005. >> So we trade MD5 for SHA-1? This makes no sense. >> > (a) SHA-1 was not broken as badly. The best attack is, as I recall, > 2^63, which is computationally infeasible without special-purpose > hardware. > special purpose? or lots of commodity? like the Amazon-EC2 example used in the cert issue? (or PS3s or...) > (b) Per a paper Eric Rescorla and I wrote, there's no usable > alternative, since too many protocols (including TLS) don't negotiate > hash functions before presenting certificates. In particular, this > means that a web site can't use SHA-256 because (1) most clients won't > support it; and (2) it can't tell which ones do. (Note that this > argument applies just as much to combinations of hash functions -- > anything that *the large majority of today's* browsers don't implement > isn't usable.) This is a function of an upgrade (firefox3.5 coming 'soon!') for browsers, and for OS's as well, yes? So, given a future flag-day (18 months from today no more MD5, only SHA-232323 will be used!!) browsers for the majority of the market could be upgraded. Certainly there are non-browsers out there (eudora, openssl, wget, curl..bittorrent-clients, embedded things) which either will lag more or break all together. > > These two points lead us to (c): security is a matter of economics, not > algorithms. Switching now to something else loses more in connectivity > or customers than you would lose from such an expensive attack. > only if not staged out with enough time to roll updates in first, right? -Chris From swmike at swm.pp.se Sat Jan 3 11:44:29 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 3 Jan 2009 18:44:29 +0100 (CET) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: On Sat, 3 Jan 2009, Hank Nussbacher wrote: > You mean like for BGP neighbors? Wanna suggest an alternative? :-) Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all. But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term. -- Mikael Abrahamsson email: swmike at swm.pp.se From frnkblk at iname.com Sat Jan 3 11:46:43 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 3 Jan 2009 11:46:43 -0600 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <87ljts5pg5.fsf@mid.deneb.enyo.de> References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> <87ljts5pg5.fsf@mid.deneb.enyo.de> Message-ID: For me the MD5 hashes on file downloads are more valuable to ensure the package is accurate to a byte rather than to verify its authenticity or integrity. Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost complete confidence that the file is the original one? I don't think anyone has been able to create a duplicate file that generates the same SHA-1 *and* MD5 hashes as the original file. Frank -----Original Message----- From: Florian Weimer [mailto:fw at deneb.enyo.de] Sent: Saturday, January 03, 2009 10:23 AM To: Skywing Cc: NANOG Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. > Then again, I just got yet another Debian DSA mail which has > plaintext download links for new binaries. The integrity > verification mechanism for said binaries is, you guessed it: > PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files. From Skywing at valhallalegends.com Sat Jan 3 11:56:57 2009 From: Skywing at valhallalegends.com (Skywing) Date: Sat, 3 Jan 2009 11:56:57 -0600 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FFB@caralain.haven.nynaeve.net> What's the cost to switching to something other than MD5 here, though? I agree that users not checking download links is likely more probablistic. But as checking the sums is already entirely a manual process, what's the trouble with switching to sha256 now abd stating this in the DSA mails? No, there probably won't be another major md5 break in six months. Or maybe a year, or two, or... However, the both of us well know that the attacks here won't do anything but get better. Even if it's not a thing to sound a fire drill about, I have to admit that hearing that Debian's going to continue moving forward with md5 until an unspecified somewhen date in the future is a bit disappointing. Not (yet) the end of the world, but I would like to understand the reason (cost) for the pushback here. ? S -----Original Message----- From: Florian Weimer Sent: Saturday, January 03, 2009 08:23 To: Skywing Cc: Steven M. Bellovin ; NANOG Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. > Then again, I just got yet another Debian DSA mail which has > plaintext download links for new binaries. The integrity > verification mechanism for said binaries is, you guessed it: > PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files. From smb at cs.columbia.edu Sat Jan 3 12:03:48 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 3 Jan 2009 13:03:48 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> <20090103104904.56562d56@cs.columbia.edu> <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> Message-ID: <20090103130348.08572569@cs.columbia.edu> On Sat, 3 Jan 2009 12:31:53 -0500 "Christopher Morrow" wrote: > On Sat, Jan 3, 2009 at 10:49 AM, Steven M. Bellovin > wrote: > > On Sat, 03 Jan 2009 09:35:06 -0500 > > William Warren wrote: > > > >> Everyone seems to be stampeding to SHA-1..yet it was broken in > >> 2005. So we trade MD5 for SHA-1? This makes no sense. > >> > > (a) SHA-1 was not broken as badly. The best attack is, as I recall, > > 2^63, which is computationally infeasible without special-purpose > > hardware. > > > > special purpose? or lots of commodity? like the Amazon-EC2 example > used in the cert issue? (or PS3s or...) No -- special-purpose chips, along the lines of Deep Crack (http://en.wikipedia.org/wiki/EFF_DES_cracker). Let's do the arithmetic. 'openssl speed sha1' on my desktop -- a 3.4 Ghz Dell -- manages 1583237 16-byte blocks in 2.92 seconds, or ~542204/second. Let's assume that for an attack to be economical, the calculations have to be completed within 30 days. My machine could do 1405B hashes in that time frame. But I need 2^63 of them, which means I need 6.5 million machines cooperating. Not impossible for BOINC, but I don't think that EC2 could handle it. > > > (b) Per a paper Eric Rescorla and I wrote, there's no usable > > alternative, since too many protocols (including TLS) don't > > negotiate hash functions before presenting certificates. In > > particular, this means that a web site can't use SHA-256 because > > (1) most clients won't support it; and (2) it can't tell which ones > > do. (Note that this argument applies just as much to combinations > > of hash functions -- anything that *the large majority of today's* > > browsers don't implement isn't usable.) > > This is a function of an upgrade (firefox3.5 coming 'soon!') for > browsers, and for OS's as well, yes? So, given a future flag-day (18 > months from today no more MD5, only SHA-232323 will be used!!) > browsers for the majority of the market could be upgraded. Certainly > there are non-browsers out there (eudora, openssl, wget, > curl..bittorrent-clients, embedded things) which either will lag more > or break all together. > Have you looked at the statistics on upgrades lately? Not a pretty picture... See, among others, http://www.ews.uiuc.edu/bstats/latest.html http://www.upsdell.com/BrowserNews/stat_trends.htm http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2 http://www.techzoom.net/publications/insecurity-iceberg/index.en > > > > These two points lead us to (c): security is a matter of economics, > > not algorithms. Switching now to something else loses more in > > connectivity or customers than you would lose from such an > > expensive attack. > > > > only if not staged out with enough time to roll updates in first, > right? > From all the data I've seen, very many machines are *never* upgraded, so the proper metric for "enough time" is "computer lifetime". Firefox 3 does handle SHA-256/384/512; I don't think IE7 does. --Steve Bellovin, http://www.cs.columbia.edu/~smb From warren at kumari.net Sat Jan 3 12:25:35 2009 From: warren at kumari.net (Warren Kumari) Date: Sat, 3 Jan 2009 13:25:35 -0500 Subject: NANOG 45: ISP Security BOF - Call for participants Message-ID: <784BB5AC-E89E-4F4E-8E3E-D29DC10582F0@kumari.net> Hello and Happy New Years all, NANOG 45 is fast approaching and so here is the call for participants for the ISP Security BOF. This is *your* chance to talk about interesting security related topics and provide some feedback on what you would (and would not) like to hear about... Some security thing been buggin' you all year? Some topic that you feel strongly about and would like a change to inform others about? Step right up and give a talk... Slides are welcome, but not required... W From nick at foobar.org Sat Jan 3 12:41:52 2009 From: nick at foobar.org (Nick Hilliard) Date: Sat, 03 Jan 2009 18:41:52 +0000 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> <20090103104904.56562d56@cs.columbia.edu> <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> Message-ID: <495FB170.4050101@foobar.org> Christopher Morrow wrote: > This is a function of an upgrade (firefox3.5 coming 'soon!') for > browsers, and for OS's as well, yes? So, given a future flag-day (18 > months from today no more MD5, only SHA-232323 will be used!!) > browsers for the majority of the market could be upgraded. Certainly > there are non-browsers out there (eudora, openssl, wget, > curl..bittorrent-clients, embedded things) which either will lag more > or break all together. I think you might be downplaying the size of the problem here. X.509 and TLS/SSL isn't just used for browsers, but for a wide variety of places where there is a requirement for PKI based security. So when you talk about a flag day for dealing with SHA-X (where X != 1), have you considered the logistical problems of upgrading all those embedded devices around the world? The credit card terminals? The tiny CPE vpn units? The old machine in the corner which handles corporate sign-on, where the vendor has now gone bust and no-one has the source code. And the large web portal which had a whole bunch of local apache customisations based on apache 1.3.x and where the original developers left for greener pa$ture$, and no-one in-house really understands what they did any longer. Etc, etc. It's different if you have a protocol which allows parameter negotiation to deal with issues like this, but not so good when you don't. Nick From nick at foobar.org Sat Jan 3 12:41:04 2009 From: nick at foobar.org (Nick Hilliard) Date: Sat, 03 Jan 2009 18:41:04 +0000 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: <495FB140.8000405@foobar.org> Hank Nussbacher wrote: > You mean like for BGP neighbors? Wanna suggest an alternative? :-) tcp/md5 + gtsm (assuming directly connected peers) makes messing around with bgp sessions rather difficult. Filtering BGP packets at the edge and borders slightly more so. If you have CPU and sufficient quantities of administrivium to spare, you can use ipsec on your routers for these sessions. The real issue is how to make compromising bgp sessions sufficiently difficult to make it an unattractive target. Given that the cost of getting write access to the DFZ is not really very high either technically or financially, I'd propose that while gtsm / md5 / filtering aren't perfect, they raise the bar high enough to make it not really worth someone's while trying to break them; and IPsec more so. Nick From tme at multicasttech.com Sat Jan 3 14:01:16 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 3 Jan 2009 15:01:16 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> <87ljts5pg5.fsf@mid.deneb.enyo.de> Message-ID: <0A47CB44-8A39-4E5E-8858-F26A9886A9A5@multicasttech.com> On Jan 3, 2009, at 12:46 PM, Frank Bulk wrote: > For me the MD5 hashes on file downloads are more valuable to ensure > the > package is accurate to a byte rather than to verify its authenticity > or > integrity. > > Wouldn't listing both SHA-1 and MD5 hashes for a file download > assure almost > complete confidence that the file is the original one? I don't > think anyone > has been able to create a duplicate file that generates the same > SHA-1 *and* > MD5 hashes as the original file. I would not be too sure. MD5 only makes one pass over the data. Suppose that I find two messages, M1 and M2, that have the same MD5 hash - there are methods out there to do that. M1 is the good message, M2 is the bad message. Let "||" be the concatenation operator. So, for any string S M1||S and M2||S have the same MD5 hash. So, if I can find an S such that the SHA-1 hash for M1||S and M2||S are the same, the MD5 hashes for these messages will still be the same, and you have your feared condition. My understanding is that one type of collision search involves using an S and trying to find collisions of M1 and M2||S by varying S. Modifying this to a common S does not seem that different, and I would not want to bet a lot on it being fundamentally much more difficult. (It might be, it might not be, I have no idea, the question is, how much are you willing to bet on it ?) Regards Marshall Regards Marshall > > > Frank > > -----Original Message----- > From: Florian Weimer [mailto:fw at deneb.enyo.de] > Sent: Saturday, January 03, 2009 10:23 AM > To: Skywing > Cc: NANOG > Subject: Re: Security team successfully cracks SSL using 200 PS3's > and MD5 > flaw. > >> Then again, I just got yet another Debian DSA mail which has >> plaintext download links for new binaries. The integrity >> verification mechanism for said binaries is, you guessed it: >> PGP-signed md5sums. > > I can assure you that you will continue to receive these messages for > a while (unless you unsubscribe from the relevant mailing lists). > > Our rationale is that in order to carry out currently known attacks on > MD5, you need to create a twin of documents, one evil and one > harmless. In Debian's case, we prepare the data we sign on our > trusted infrastructure. If someone can sneak in an evil twin due to a > breach, more direct means of attack are available. > > In practice, the download links themselves are the larger problem > because users might use them without checking anything. Eventually, > they will go away, together with the MD5 hashes. Newer versions of > APT also use the SHA-256 checksums embedded in the Release and > Packages files. > > > From fw at deneb.enyo.de Sat Jan 3 14:01:37 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 03 Jan 2009 21:01:37 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: (Hank Nussbacher's message of "Sat, 3 Jan 2009 18:53:25 +0200 (IST)") References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: <87prj417mm.fsf@mid.deneb.enyo.de> * Hank Nussbacher: > On Fri, 2 Jan 2009, Mikael Abrahamsson wrote: > >> MD5 is broken, don't use it for anything important. > > You mean like for BGP neighbors? Good point. However, as a defense against potential blind injection attacks, even an unhashed password in a TCP option would do the trick (at least in the non-IXP case, IXPs may pose different challenges). > Wanna suggest an alternative? :-) Just switch on IPsec. 8-) From fw at deneb.enyo.de Sat Jan 3 15:33:53 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 03 Jan 2009 22:33:53 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <495FB170.4050101@foobar.org> (Nick Hilliard's message of "Sat, 03 Jan 2009 18:41:52 +0000") References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> <20090103104904.56562d56@cs.columbia.edu> <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> <495FB170.4050101@foobar.org> Message-ID: <874p0gyszi.fsf@mid.deneb.enyo.de> * Nick Hilliard: > I think you might be downplaying the size of the problem here. X.509 and > TLS/SSL isn't just used for browsers, but for a wide variety of places > where there is a requirement for PKI based security. So when you talk > about a flag day for dealing with SHA-X (where X != 1), have you considered > the logistical problems of upgrading all those embedded devices around the > world? They won't be affected by the flag day, because the flag day is set by the relying party (that is, the browser), not the CA. If you've got a real PKI deployment, by definition, you've got procedures to deal with sudden advances in published cryptanalysis (even if it involves posting guards at certain buildings, instead of relying on smartcards for access control). The problematic areas are those where cryptography is used to comply with some checklist (or for PR purposes), and not for its security properties. In those environments, algorithm changes can never justify the associated costs. From fw at deneb.enyo.de Sat Jan 3 16:04:00 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 03 Jan 2009 23:04:00 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: (Frank Bulk's message of "Sat, 3 Jan 2009 11:46:43 -0600") References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> <87ljts5pg5.fsf@mid.deneb.enyo.de> Message-ID: <87tz8gxd0v.fsf@mid.deneb.enyo.de> * Frank Bulk: > For me the MD5 hashes on file downloads are more valuable to ensure the > package is accurate to a byte rather than to verify its authenticity or > integrity. Indeed. I've experienced that first-hand: the hashes helped to isolate a case of faulty router memory at the ISP I used at home. (The TCP checksum is very weak and does not detect bit errors which occur at multiples of 16 bits. If the probability of such errors is so high that two of them occur in a single segment, they very likely cancel out, which was exactly what I observed in the issue mentioned above.) > Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost > complete confidence that the file is the original one? I don't think anyone > has been able to create a duplicate file that generates the same SHA-1 *and* > MD5 hashes as the original file. For most applications, it's better to include a totally random string at the beginning of the message, before signing it, and strip it upon signature verification (or encode it in a way so that it is simply ignored by the application). The convergent property of hash functions (if, by chance, two people come up independently with the same document, it hashes to the same value) is rarely needed. A random string near the beginning means that the attacker doesn't know the initial internal state of the hash function when the collision is constructed, which should make attacks involving evil twins much, much harder. I expect that at a not too distant point in the future (say, within the next ten years), strong hashes keyed in a such a way offer very significant performance gains over non-keyed, but still strong hashes, so that most protocols which do not rely on the convergence property will switch to them. Convergence might even turn out to be too costly, not just in terms of performance, but in security. (And I write this as a frequent Git user. 8-/) From fw at deneb.enyo.de Sat Jan 3 17:16:03 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 04 Jan 2009 00:16:03 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FFB@caralain.haven.nynaeve.net> (Skywing@valhallalegends.com's message of "Sat, 3 Jan 2009 11:56:57 -0600") References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FFB@caralain.haven.nynaeve.net> Message-ID: <87d4f4vv4c.fsf@mid.deneb.enyo.de> > What's the cost to switching to something other than MD5 here, > though? Just the general risk of change (sometimes referred to as "bricking"). The changes on the generating side have already been implemented. Maybe we should include a dummy package entry at the beginning of the package list, with unpredictable contents. This should be sufficient with the current level of cryptanalysis (like most folks, we are relatively unprotected against second preimage attacks because we still need to support MD5-only private repositories and OpenPGP V3 signing keys). It does not solve the problem that MD5 is an outcast these days, no matter how it is used. > I agree that users not checking download links is likely more > probablistic. But as checking the sums is already entirely a manual > process, what's the trouble with switching to sha256 now abd stating > this in the DSA mails? There are some folks who use scripts to parse the messages. But as I said, we are far more likely to drop .deb hashes altogether, probably as lenny is released. > I have to admit that hearing that Debian's going to continue moving > forward with md5 until an unspecified somewhen date in the future is > a bit disappointing. Yes, I'd like to zap a magic wand and make all those MD5-only APT installations go away, but it isn't that easy. From morrowc.lists at gmail.com Sat Jan 3 21:55:34 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 3 Jan 2009 22:55:34 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <495FB170.4050101@foobar.org> References: <200901021733.n02HXnAN047547@aurora.sol.net> <495E5543.20504@hawaii.edu> <85140EB3-6CED-43ED-8340-493338E7BCCE@kyx.net> <495F779A.9000905@emmanuelcomputerconsulting.com> <20090103104904.56562d56@cs.columbia.edu> <75cb24520901030931i39acb456l3202cbed539f8631@mail.gmail.com> <495FB170.4050101@foobar.org> Message-ID: <75cb24520901031955l9541b72u3a8fc1d48e7894bb@mail.gmail.com> On Sat, Jan 3, 2009 at 1:41 PM, Nick Hilliard wrote: > Christopher Morrow wrote: >> This is a function of an upgrade (firefox3.5 coming 'soon!') for >> browsers, and for OS's as well, yes? So, given a future flag-day (18 >> months from today no more MD5, only SHA-232323 will be used!!) >> browsers for the majority of the market could be upgraded. Certainly >> there are non-browsers out there (eudora, openssl, wget, >> curl..bittorrent-clients, embedded things) which either will lag more >> or break all together. > > I think you might be downplaying the size of the problem here. X.509 and I wasn't, not intentionally.. I was trying to address the problem which the researchers harped on, and which seems like the hot-button for many folks: "oh my, someone can intercept https silently!!" I understand there are LOTS of things out there using certs for all manner of not-http things. I also understand that by telling a browser class that they shouldn't accept anything but sha-X seems workable. I suppose having the CA's kick out ONLY SHA-X is a bad plan, but ... maybe letting cert requestors select the hash funciton (not md5) is better? (or a step in the right direction at least) > TLS/SSL isn't just used for browsers, but for a wide variety of places > where there is a requirement for PKI based security. So when you talk > about a flag day for dealing with SHA-X (where X != 1), have you considered > the logistical problems of upgrading all those embedded devices around the > world? The credit card terminals? The tiny CPE vpn units? The old I had... yup. > machine in the corner which handles corporate sign-on, where the vendor has > now gone bust and no-one has the source code. And the large web portal > which had a whole bunch of local apache customisations based on apache > 1.3.x and where the original developers left for greener pa$ture$, and > no-one in-house really understands what they did any longer. Etc, etc. > > It's different if you have a protocol which allows parameter negotiation to > deal with issues like this, but not so good when you don't. agreed, 100%. There are also lots of folks using certs internally for all manner of oddball reasons... signed on their own CA (perhaps chained to a 'real' CA, perhaps not). They'll have to be accomodated as well, of course. -chris From Valdis.Kletnieks at vt.edu Sat Jan 3 23:37:59 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 04 Jan 2009 00:37:59 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: Your message of "Sat, 03 Jan 2009 17:23:06 +0100." <87ljts5pg5.fsf@mid.deneb.enyo.de> References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25FF2@caralain.haven.nynaeve.net> <87ljts5pg5.fsf@mid.deneb.enyo.de> Message-ID: <26282.1231047479@turing-police.cc.vt.edu> On Sat, 03 Jan 2009 17:23:06 +0100, Florian Weimer said: > Our rationale is that in order to carry out currently known attacks on > MD5, you need to create a twin of documents, one evil and one > harmless. In Debian's case, we prepare the data we sign on our > trusted infrastructure. If someone can sneak in an evil twin due to a > breach, more direct means of attack are available. More to the point - there are known easy ways for an attacker to generate *two* documents that have the same MD5 hash (the basis of this attack). However, the attacker has no control over what the actual value of that MD5 hash is. What's *not* still feasible is for an attacker to take Debian's data and the already-generated MD5 hash, and create a second file that hashes to that same already-known hash. At that point, it's probably easier to just attack the trusted infrastructure in an attempt to recover the GnuPG private key, and then just sign your evil replacement package. There's 2 advantages to this attack: 1) It doesn't *matter* if they PGP-sign the file with the MD5 hashes or if the file has SHA1 or SHA512 - the signature will look fine. 2) It's been proven doable to at least one major distro in the past few months. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From hank at efes.iucc.ac.il Sun Jan 4 01:22:06 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 04 Jan 2009 09:22:06 +0200 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> Message-ID: <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: >On Sat, 3 Jan 2009, Hank Nussbacher wrote: > >>You mean like for BGP neighbors? Wanna suggest an alternative? :-) > >Well, most likely MD5 is better than the alterantive today which is to run >no authentication/encryption at all. > >But we should push whoever is developing these standards to go for SHA-1 >or equivalent instead of MD5 in the longer term. Who is working on this? I don't find anything here: http://www.ietf.org/html.charters/idr-charter.html All I can find is: http://www.ietf.org/rfc/rfc2385.txt http://www.ietf.org/rfc/rfc3562.txt http://www.ietf.org/rfc/rfc4278.txt Nothing on replacing MD5 for BGP. -Hank From fw at deneb.enyo.de Sun Jan 4 04:26:11 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 04 Jan 2009 11:26:11 +0100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> (Hank Nussbacher's message of "Sun, 04 Jan 2009 09:22:06 +0200") References: <200901021558.n02Fw5bs040941@aurora.sol.net> <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> Message-ID: <87ljtrjrjw.fsf@mid.deneb.enyo.de> * Hank Nussbacher: > Who is working on this? I don't find anything here: > http://www.ietf.org/html.charters/idr-charter.html I think this belongs to the tcpm WG or the btns WG. From rubensk at gmail.com Sun Jan 4 08:13:50 2009 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 4 Jan 2009 12:13:50 -0200 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <87ljtrjrjw.fsf@mid.deneb.enyo.de> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> <87ljtrjrjw.fsf@mid.deneb.enyo.de> Message-ID: <6bb5f5b10901040613l687d0d3al7a5a4a5fe4020a0c@mail.gmail.com> Yeap: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-02.txt TCPM WG J. Touch Internet Draft USC/ISI Obsoletes: 2385 A. Mankin Intended status: Proposed Standard Johns Hopkins Univ. Expires: May 2009 R. Bonica Juniper Networks November 3, 2008 Rubens On Sun, Jan 4, 2009 at 8:26 AM, Florian Weimer wrote: > * Hank Nussbacher: > >> Who is working on this? I don't find anything here: >> http://www.ietf.org/html.charters/idr-charter.html > > I think this belongs to the tcpm WG or the btns WG. > > From tme at multicasttech.com Sun Jan 4 08:37:20 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 4 Jan 2009 09:37:20 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> Message-ID: There is a discussion of this going on in CFRG. https://www.irtf.org/mailman/listinfo/cfrg Regards Marshall On Jan 4, 2009, at 2:22 AM, Hank Nussbacher wrote: > At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: >> On Sat, 3 Jan 2009, Hank Nussbacher wrote: >> >>> You mean like for BGP neighbors? Wanna suggest an alternative? :-) >> >> Well, most likely MD5 is better than the alterantive today which is >> to run no authentication/encryption at all. >> >> But we should push whoever is developing these standards to go for >> SHA-1 or equivalent instead of MD5 in the longer term. > > Who is working on this? I don't find anything here: > http://www.ietf.org/html.charters/idr-charter.html > > All I can find is: > http://www.ietf.org/rfc/rfc2385.txt > http://www.ietf.org/rfc/rfc3562.txt > http://www.ietf.org/rfc/rfc4278.txt > > Nothing on replacing MD5 for BGP. > > -Hank > > From thomas at habets.pp.se Sun Jan 4 09:09:59 2009 From: thomas at habets.pp.se (Thomas Habets) Date: Sun, 4 Jan 2009 16:09:59 +0100 (CET) Subject: Leap second tonight In-Reply-To: <20090101161351.GU14718@virtual.bogons.net> References: <20090101091551.GS14718@virtual.bogons.net> <7ff145960901010129s1bfb74cdrd080cd6c454ae226@mail.gmail.com> <20090101103646.GT14718@virtual.bogons.net> <10CBFB91-7B4D-44BE-80EA-EC8949CE40E2@bsdboy.com> <20090101161351.GU14718@virtual.bogons.net> Message-ID: On Thu, 1 Jan 2009, Simon Lockhart wrote: > My Oracle boxes that rebooted were running RAC (version 10G R2), too. Another > Solaris 10 box running the same version of Oracle, but not RAC, did not reboot. > > Looks rather like an Oracle 10 RAC bug. It's a known bug in Oracle 10. When the time is set backwards the system reboots. I don't have the bug id at hand but there is one, and a patch. Either patch or don't run NTP on Oracle servers. --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From morrowc.lists at gmail.com Sun Jan 4 10:40:00 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Jan 2009 11:40:00 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: References: <200901021558.n02Fw5bs040941@aurora.sol.net> <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> Message-ID: <75cb24520901040840y5dbad821l62010f0975afaf80@mail.gmail.com> On Sun, Jan 4, 2009 at 9:37 AM, Marshall Eubanks wrote: > There is a discussion of this going on in CFRG. > > https://www.irtf.org/mailman/listinfo/cfrg > sadly, and apropos I suppose, www.irtf.org is serving up a *.ietf.org ssl cert :( and the archives require membership to view them. -chris From morrowc.lists at gmail.com Sun Jan 4 10:45:38 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 4 Jan 2009 11:45:38 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: <75cb24520901040840y5dbad821l62010f0975afaf80@mail.gmail.com> References: <200901021558.n02Fw5bs040941@aurora.sol.net> <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> <75cb24520901040840y5dbad821l62010f0975afaf80@mail.gmail.com> Message-ID: <75cb24520901040845u4b306935k5214fddbf53c29d6@mail.gmail.com> On Sun, Jan 4, 2009 at 11:40 AM, Christopher Morrow wrote: > On Sun, Jan 4, 2009 at 9:37 AM, Marshall Eubanks wrote: >> There is a discussion of this going on in CFRG. >> >> https://www.irtf.org/mailman/listinfo/cfrg >> > > sadly, and apropos I suppose, www.irtf.org is serving up a *.ietf.org > ssl cert :( and the archives require membership to view them. oops I should have included the cert ... subject=/O=*.ietf.org/CN=*.ietf.org/OU=Domain Control Validated issuer=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435 with the chain: Certificate chain 0 s:/O=*.ietf.org/CN=*.ietf.org/OU=Domain Control Validated i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/ CN=Starfield Secure Certification Authority/serialNumber=10688435 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/ CN=Starfield Secure Certification Authority/serialNumber=10688435 i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority 2 s:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.val icert.com//emailAddress=info at valicert.com 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.val icert.com//emailAddress=info at valicert.com i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.val icert.com//emailAddress=info at valicert.com -chris From ebw at abenaki.wabanaki.net Sun Jan 4 12:48:29 2009 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Sun, 04 Jan 2009 13:48:29 -0500 Subject: Gaza telecommunication systems offline Message-ID: <4961047D.2060306@abenaki.wabanaki.net> This is sort of a rinse and repeat of the degradation of the Iraqi voice and data networks we annotated in March of 2003. The first is Ma'an (Turkish), the second is AP (American). Cell service is at the point of failure. Data is coming close to failure, and landline voice is problematic too. http://www.turkishweekly.net/news/62744/gaza-telecommunication-systems-offline.html and http://www.google.com/hostednews/ukpress/article/ALeqM5iv4xv2KNWjkm8Ixw60eD52Va5zTw Eric From jgreco at ns.sol.net Sun Jan 4 14:05:44 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 4 Jan 2009 14:05:44 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <87eizk8kax.fsf@mid.deneb.enyo.de> from "Florian Weimer" at Jan 03, 2009 04:45:58 PM Message-ID: <200901042005.n04K5iA4044524@aurora.sol.net> > * Brian Keefer: > > My apologies if you were commenting on some other aspect, or if my > > understand is in some way flawed. > > I don't think so. > > There's a rule of thumb which is easy to remembe: Never revoke > anything just because some weak algorithm is involved. The rationale > is that that revocation is absolute and (usually) retroactive, but we > generally want a more nuanced approach. If certain algorithms are too > weak to be used, this is up to the relying party to decide whether > it's fine in a particular case. On the other hand, replacing > MD5-signed certificates in the browser PKI is costly, but the overhead > is very finely dispersed (assuming that reissuing certificates has > very little overhead at the CA). I think it's doable if the browser > vendors could agree on a flag date after which MD5 signatures on > certificates are no longer considered valid. > > (The implicit assumptions in that rule of thumb do not always apply. > For instance, if weak RSA keys are discovered which occur with > sufficiently high probability as the result of the standard key > generating algorithms to pose a real problem, the public key may not > reveal this property immediately, it may only be evident from the > private key, or only after a rather expensive computation. In the > latter case, we would be in very deep trouble.) Other faulty assumptions are that the "relying party" (usually part/ies/) are actually made aware, and actually make an informed decision, or that revocation is the first step in efforts to motivate replacement of a cert, which probably is exactly opposite what I have suggested... Rules of thumbs about weakness of algorithms are suspect because things change over time; your rule of thumb above might have been applied to 40-bit encryption, but I don't see much 40-bit stuff around anymore. :-) The opinions on whether or not it is necessary to replace certs seems to vary depending on whose opinion you're listening to, but a relatively safe rule of thumb for this sort of security issue is to take the path that is most likely to avoid risk, which would seem to be replacing certs. To the extent that VeriSign is already doing this, it would seem that there is a certain level of agreement with that assessment. ... 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. From oberman at es.net Sun Jan 4 14:38:35 2009 From: oberman at es.net (Kevin Oberman) Date: Sun, 04 Jan 2009 12:38:35 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. In-Reply-To: Your message of "Sun, 04 Jan 2009 09:22:06 +0200." <5.1.0.14.2.20090104091544.05741e78@efes.iucc.ac.il> Message-ID: <20090104203835.9F05F45021@ptavv.es.net> > Date: Sun, 04 Jan 2009 09:22:06 +0200 > From: Hank Nussbacher > > At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: > >On Sat, 3 Jan 2009, Hank Nussbacher wrote: > > > >>You mean like for BGP neighbors? Wanna suggest an alternative? :-) > > > >Well, most likely MD5 is better than the alterantive today which is to run > >no authentication/encryption at all. > > > >But we should push whoever is developing these standards to go for SHA-1 > >or equivalent instead of MD5 in the longer term. > > Who is working on this? I don't find anything here: > http://www.ietf.org/html.charters/idr-charter.html > > All I can find is: > http://www.ietf.org/rfc/rfc2385.txt > http://www.ietf.org/rfc/rfc3562.txt > http://www.ietf.org/rfc/rfc4278.txt > > Nothing on replacing MD5 for BGP. I don't see why this is an issue (today). As far as I understand it, the vulnerability in MD5 is that, with time and cycles, it is possible to create a collision where two files have the same MD5 hash, so the counterfeit cert would check as valid. For the MD5 signature on a TCP packet, this is not relevant. Am I missing something? (I will admit to not being a cryptography person, so I may totally misunderstand.) I don't object to moving to a stronger hash, but, considering the expense and time involved, I'd suggest waiting for the new hash algorithm that the NIST challenge will hopefully provide. In other words, stick to MD5 in places where it is not believed to be vulnerable and where converting to SHA-1 or SHA-256 would be expensive. Where it IS believed vulnerable, the cost/benefit ratio would have to determine when the conversion is justified. For X.509 certs, I believe the answer is clearly that it is justified and has been for at least 2 years. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From chort at smtps.net Sun Jan 4 15:02:06 2009 From: chort at smtps.net (Brian Keefer) Date: Sun, 4 Jan 2009 13:02:06 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901042005.n04K5iA4044524@aurora.sol.net> References: <200901042005.n04K5iA4044524@aurora.sol.net> Message-ID: <2DA428CB-0CAB-4181-913D-6161A8F00A6E@smtps.net> On Jan 4, 2009, at 12:05 PM, Joe Greco wrote: > > The opinions on whether or not it is necessary to replace certs > seems to > vary depending on whose opinion you're listening to, but a > relatively safe > rule of thumb for this sort of security issue is to take the path > that is > most likely to avoid risk, which would seem to be replacing certs. > To the > extent that VeriSign is already doing this, it would seem that there > is a > certain level of agreement with that assessment. > I would attribute that much more to desire to avoid the risk of bad PR, rather than the risk that it's possible to clone existing certs. "SSL is cracked, VeriSign to blame!" was pretty much the top security story for several days. They had to do something to turn around the perception, despite accurate analysis and publications by organizations such as Microsoft. Perception is reality, and regardless of the technical merits, a significant amount of people seemed to believe that any certificates that mentioned MD5 anywhere in them are at risk of some unknown, but really scary Badness(tm). I agree with VeriSign that offering to reissue certs is the smartest business decision they can make, considering their tagline is "The Value of Trust". I disagree that it was technically necessary. Reissuing existing certificates signed by MD5 accomplishes nothing. Participation is voluntary, so if someone had managed to create a rogue CA, they certainly would not voluntarily destroy it by having their cert reissued! Technically the only thing necessary to prevent this attack has already been done, and that is to stop issuing certs signed with MD5 so that no one else can create a rogue CA via this means. If they truly believed that there was a risk anyone else had done this already, they would need to revoke the CA cert, i.e. every vendor who shipped their CA cert in the default trusted issuer bundle would need to remove or invalidate it with a software update, but that would break _all_ the valid certificates signed by the CA. In order to do that, they would need to proactively contact every customer with a valid cert to make sure they were updated. What percentage of their customers do you think they would be able to reach (haven't changed contact information, etc)? How many application vendors would actually remove the old CA and add the new one in a timely manner? How many of those vendors' customers would actually upgrade to the new version? So they've done what they need to in order to prevent future exploits, and obviously they aren't that worried that the exploit has actually been performed maliciously in the past. Offering to reissue existing certs is a PR smokescreen (although a necessary one). I think there's a huge fundamental misunderstanding. It seems that the popular belief is that it's possible to use an existing MD5 signature for any evil bits that you choose, which is not the case. The actual exploit in this case is the ability to "unlock" a normal certificate to make it a CA certificate. Of course phrasing it that way wouldn't be quite so sensational (and wouldn't have accomplished the researcher's goal of raising awareness to the weakness of MD5), so now we have mass misperception, which has become reality since anything that is published is automatically true. I'm not saying it's bad that people are shying aware from MD5, I just like to be accurate. In any case, it has spawned some healthy discussions so I would say it was worthwhile. -- bk CA cert: http://www.smtps.net/pub/smtps-dot-net-ca-2.pem -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1613 bytes Desc: not available URL: From tme at multicasttech.com Sun Jan 4 15:06:53 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 4 Jan 2009 16:06:53 -0500 Subject: Sprint Leap Second Message-ID: <219977D2-9EF5-4806-A898-D34483E216BC@multicasttech.com> Has anyone seen evidence that Sprint's cellular network has not adopted the leap second yet ? (I have reports, but cannot check myself.) Marshall From jgreco at ns.sol.net Sun Jan 4 15:58:34 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 4 Jan 2009 15:58:34 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <2DA428CB-0CAB-4181-913D-6161A8F00A6E@smtps.net> from "Brian Keefer" at Jan 04, 2009 01:02:06 PM Message-ID: <200901042158.n04LwYgp048368@aurora.sol.net> > "SSL is cracked, VeriSign to blame!" was pretty much the top security > story for several days. They had to do something to turn around the > perception, despite accurate analysis and publications by > organizations such as Microsoft. Perception is reality, and > regardless of the technical merits, a significant amount of people > seemed to believe that any certificates that mentioned MD5 anywhere in > them are at risk of some unknown, but really scary Badness(tm). Perception is, sadly, not reality, no matter what you wish to argue. (Sorry!) For years, some people had a "perception" that DNS was reasonably safe and secure by virtue of the transaction ID and the difficulty in slipping in a bad update. Some of us were aware that increases in bandwidth and processor power would reduce the difficulty, and certainly the issue had been discussed in some detail even back in the 1990's. The "perception" of DNS security turned into the reality of Our-DNS-House-Is-On-Fire last year. > I agree with VeriSign that offering to reissue certs is the smartest > business decision they can make, considering their tagline is "The > Value of Trust". I disagree that it was technically necessary. > > Reissuing existing certificates signed by MD5 accomplishes nothing. Incorrect. As the number of MD5-signed certificates dwindles, the feasibility of removing or disabling support for MD5-signed certs increases. Of course that assumes the reissues are signed by SHA. > Participation is voluntary, so if someone had managed to create a > rogue CA, they certainly would not voluntarily destroy it by having > their cert reissued! Of course. > Technically the only thing necessary to prevent > this attack has already been done, and that is to stop issuing certs > signed with MD5 so that no one else can create a rogue CA via this > means. Are we certain that existing certs cannot be subverted? > If they truly believed that there was a risk anyone else had done this > already, they would need to revoke the CA cert, i.e. every vendor who > shipped their CA cert in the default trusted issuer bundle would need > to remove or invalidate it with a software update, but that would > break _all_ the valid certificates signed by the CA. In order to do > that, they would need to proactively contact every customer with a > valid cert to make sure they were updated. What percentage of their > customers do you think they would be able to reach (haven't changed > contact information, etc)? How many application vendors would > actually remove the old CA and add the new one in a timely manner? > How many of those vendors' customers would actually upgrade to the new > version? I don't know. We've had fires before. Fires with less obvious solutions and higher costs-to-implement/fix. > So they've done what they need to in order to prevent future exploits, > and obviously they aren't that worried that the exploit has actually > been performed maliciously in the past. Offering to reissue existing > certs is a PR smokescreen (although a necessary one). I would disagree; we are simply *aware* that MD5 certs have been subverted in this particular way, but clearly this shows a weakness exists, and are you prepared to guarantee that there are no other ways to subvert the current MD5 system, possibly in a much different way? Getting rid of the bad crypto - and come on, it's crypto we have known for several years is bad - is not a PR smokescreen. It's a smart move. Why wait for something truly bad to happen? > I think there's a huge fundamental misunderstanding. It seems that > the popular belief is that it's possible to use an existing MD5 > signature for any evil bits that you choose, which is not the case. > The actual exploit in this case is the ability to "unlock" a normal > certificate to make it a CA certificate. Of course phrasing it that > way wouldn't be quite so sensational (and wouldn't have accomplished > the researcher's goal of raising awareness to the weakness of MD5), so > now we have mass misperception, which has become reality since > anything that is published is automatically true. So, any current MD5-signed cert carries with it some vague risk that it could potentially be subverted. I'm ... failing ... to see the huge fundamental misunderstanding you refer to. > I'm not saying it's bad that people are shying aware from MD5, I just > like to be accurate. > > In any case, it has spawned some healthy discussions so I would say it > was worthwhile. Certainly. ... 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. From Valdis.Kletnieks at vt.edu Sun Jan 4 16:52:10 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 04 Jan 2009 17:52:10 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: Your message of "Sun, 04 Jan 2009 15:58:34 CST." <200901042158.n04LwYgp048368@aurora.sol.net> References: <200901042158.n04LwYgp048368@aurora.sol.net> Message-ID: <14744.1231109530@turing-police.cc.vt.edu> On Sun, 04 Jan 2009 15:58:34 CST, Joe Greco said: > > Technically the only thing necessary to prevent > > this attack has already been done, and that is to stop issuing certs > > signed with MD5 so that no one else can create a rogue CA via this > > means. > > Are we certain that existing certs cannot be subverted? The attack depends on being able to to jigger up *two* certs that have the same MD5 hash. Therefor, attacking an existing cert would require either: 1) That the existing cert be one of a pair (in other words, somebody else already knew about the current attack and also did it). or 2) Somebody has found a way to cause a collision to a specified MD5 hash (which is still impractical, AFAIK). If anybody has a subvertible cert, it's pretty safe to guess that they *know* they have such a cert, because they themselves *built* the cert that way. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From gds at gds.best.vwh.net Sun Jan 4 17:52:15 2009 From: gds at gds.best.vwh.net (Greg Skinner) Date: Sun, 4 Jan 2009 23:52:15 +0000 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: ; from martin@theicelandguy.com on Sat, Jan 03, 2009 at 01:31:28AM -0500 References: <77e4079b0901021530l4c22a28fv392d87cf9c21e644@mail.gmail.com> Message-ID: <20090104235215.A73128@gds.best.vwh.net> On Sat, Jan 03, 2009 at 01:31:28AM -0500, Martin Hannigan wrote: > Overall, geo location has turned out to be a somewhat valuable tool in terms > of language, fraud, and localization. I think that it's important to > continue to urge improvements in this technology, not divestment. I don't see how this technology can be improved past a certain point, because the criteria that are used to determine location are only coincidentally tied to location (they are the result of administrative policy and/or configuration). At best, they provide a false sense of "security". --gregbo From Skywing at valhallalegends.com Sun Jan 4 18:23:39 2009 From: Skywing at valhallalegends.com (Skywing) Date: Sun, 4 Jan 2009 18:23:39 -0600 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA26009@caralain.haven.nynaeve.net> Any "security" provided (I must assume that you speak of fraud prevention services) is the probablistic sort, of reducing, for example, aggregate (and not specific) losses. ? S -----Original Message----- From: Greg Skinner Sent: Sunday, January 04, 2009 15:52 To: Martin Hannigan Cc: nanog at nanog.org Subject: Re: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly On Sat, Jan 03, 2009 at 01:31:28AM -0500, Martin Hannigan wrote: > Overall, geo location has turned out to be a somewhat valuable tool in terms > of language, fraud, and localization. I think that it's important to > continue to urge improvements in this technology, not divestment. I don't see how this technology can be improved past a certain point, because the criteria that are used to determine location are only coincidentally tied to location (they are the result of administrative policy and/or configuration). At best, they provide a false sense of "security". --gregbo From meekjt at gmail.com Sun Jan 4 18:59:43 2009 From: meekjt at gmail.com (Jon Meek) Date: Sun, 4 Jan 2009 19:59:43 -0500 Subject: Sprint Leap Second In-Reply-To: <219977D2-9EF5-4806-A898-D34483E216BC@multicasttech.com> References: <219977D2-9EF5-4806-A898-D34483E216BC@multicasttech.com> Message-ID: A visual comparison of my Sprint phone and xclock with second hand on a synchronized workstation suggests that they have not yet implemented the leap second. Our single CDMA NTP clock did handle the leap second at the correct moment. However, that CDMA clock is West of Philadelphia and I am in New Jersey. As I mentioned in a previous message, in 2005 our CDMA clock "got" the leap second a few hours early. Jon On Sun, Jan 4, 2009 at 4:06 PM, Marshall Eubanks wrote: > Has anyone seen evidence that Sprint's cellular network has not > adopted the leap second yet ? > > (I have reports, but cannot check myself.) > > Marshall > > From jeffrey.lyon at blacklotus.net Sun Jan 4 20:06:34 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 4 Jan 2009 21:06:34 -0500 Subject: Ethical DDoS drone network Message-ID: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Say for instance one wanted to create an "ethical botnet," how would this be done in a manner that is legal, non-abusive toward other networks, and unquestionably used for legitimate internal security purposes? How does your company approach this dilemma? Our company for instance has always relied on outside attacks to spot check our security and i'm beginning to think there may be a more user friendly alternative. Thoughts? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From martin at theicelandguy.com Sun Jan 4 20:13:54 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sun, 4 Jan 2009 21:13:54 -0500 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA26009@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA26009@caralain.haven.nynaeve.net> Message-ID: On Sun, Jan 4, 2009 at 7:23 PM, Skywing wrote: > Any "security" provided (I must assume that you speak of fraud prevention > services) is the probablistic sort, of reducing, for example, aggregate (and > not specific) losses. Yes, probablistic in a wholistic fashion i.e. correlated against other datasets and used as a weight in a routine, for example, not necessarily a deciding factor. Best, -M< From admin at racksecurity.net Sun Jan 4 20:14:47 2009 From: admin at racksecurity.net (Zach) Date: Sun, 4 Jan 2009 20:14:47 -0600 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: <3918cf170901041814j68e62414v95b825aa49d883eb@mail.gmail.com> I would say to roll your own binary hardcoded to only hit 1 IP address, and have it held on a law enforcement approved network under the supervision of a qualified agent. 0.02 On Sun, Jan 4, 2009 at 8:06 PM, Jeffrey Lyon wrote: > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? > > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. > > Thoughts? > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > From fergdawgster at gmail.com Sun Jan 4 20:15:35 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 4 Jan 2009 18:15:35 -0800 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: <6cd462c00901041815r3bb5427co8c8f3a40ccfab4cc@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jan 4, 2009 at 6:06 PM, Jeffrey Lyon wrote: > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? Well, for starters, you wold have to own (in the traditional sense) all of the hosts involved. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJYW08q1pz9mNUZTMRApqvAJ9cctPxYzLqqeJyzO+k0cmnFpPn/QCgkI+V /jMXCouqNrsCCluieKHegdk= =jUJU -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From deleskie at gmail.com Sun Jan 4 20:18:35 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 5 Jan 2009 02:18:35 +0000 Subject: Ethical DDoS drone network Message-ID: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> Super risky. This would be a 99% legal worry plus. Unless all the end points and networks they cross sign off on it the risk is beyond huge. -jim ------Original Message------ From: Jeffrey Lyon Sender: To: nanog at merit.edu Subject: Ethical DDoS drone network Sent: Jan 4, 2009 10:06 PM Say for instance one wanted to create an "ethical botnet," how would this be done in a manner that is legal, non-abusive toward other networks, and unquestionably used for legitimate internal security purposes? How does your company approach this dilemma? Our company for instance has always relied on outside attacks to spot check our security and i'm beginning to think there may be a more user friendly alternative. Thoughts? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. Sent from my BlackBerry device on the Rogers Wireless Network From marc at let.de Sun Jan 4 20:25:44 2009 From: marc at let.de (macbroadcast) Date: Mon, 5 Jan 2009 03:25:44 +0100 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: Am 05.01.2009 um 03:06 schrieb Jeffrey Lyon: > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? > > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. > > Thoughts? hello, , http://mirror.informatik.uni-mannheim.de/pub/ccc/streamdump/saal3/Tag3-Saal3-Slot15%3a30--ID3000-hacking_into_botnets-Main-2008-12-29T15%3a30%3a04%2b0100.ogm and http://mirror.informatik.uni-mannheim.de/pub/ccc/streamdump/saal3/Tag3-Saal3-Slot16%3a45--ID3000-hacking_into_botnets-Pause-2008-12-29T18%3a30%3a01%2b0100.ogm have fun!!! Marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From blakjak at blakjak.net Sun Jan 4 20:26:03 2009 From: blakjak at blakjak.net (Mark Foster) Date: Mon, 5 Jan 2009 15:26:03 +1300 (NZDT) Subject: Ethical DDoS drone network In-Reply-To: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> Message-ID: Refer earlier posts. End points ('drones') would have to be legitimate endpoints, not drones on random boxes. That eliminates legal liability client-side. If the traffic is non abusive then I don't see the risk for the network providers in the middle either. If it's clearly established that the source (drones), destination (target) are all 'opted in' and there's no 'collateral damage' (in bandwidth terms or otherwise, being the ways in which I see other parties potentially being impacted) I don't know that it's anywhere near as risky as you imply. You'd have to be careful not to trip IDS or similar for all the networks you transit, to avoid impacting on others in the event of some mis-fired responses... What would be an example legitimate security purpose, except to perhaps drill responses to illegitimate botnets? Mark. On Mon, 5 Jan 2009, deleskie at gmail.com wrote: > Super risky. This would be a 99% legal worry plus. Unless all the end points and networks they cross sign off on it the risk is beyond huge. > > -jim > ------Original Message------ > From: Jeffrey Lyon > Sender: > To: nanog at merit.edu > Subject: Ethical DDoS drone network > Sent: Jan 4, 2009 10:06 PM > > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? > > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. > > Thoughts? > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > > > Sent from my BlackBerry device on the Rogers Wireless Network From streiner at cluebyfour.org Sun Jan 4 20:31:46 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 4 Jan 2009 21:31:46 -0500 (EST) Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: On Sun, 4 Jan 2009, Jeffrey Lyon wrote: > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? The company I work for has not approached this particular dilemma yet. I'm not sure what legitimate internal security purposes you're looking to fulfill, but I think you need to ask yourself a few questions first (not an all-inclusive list, but food for thought nonetheless): 1. What is the purpose of this legit botnet? In other words, what business objective does it achieve? 2. Do you have the people in-house to write the software, or would you be willing to take a chance on using something that exists 'in the wild'? Depending on how security-minded your shop is, your corporate security folks and legal counsel might take a dim view toward using untrusted software on your internal network, especially if source code is not available. That particular monster can get out of control very quickly. 3. Do you have a sufficient number of machines that are controlled by you to populate this botnet and achieve my goals (see point 1)? 4. How will this botnet be isolated from the rest of your internal network, and would that isolation limit or even negate the botnet's usefulness? 5. If the answer to question 4 is "no isolation", how will you demonstrably control the botnet's propagation? 6. Depending on the answer to question 5, there might be regulatory compliance (HIPAA, FERPA, GLB, SOX, internal security/privacy policies, contractual obligations, etc...) issues to consider. > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. Infection, even for ethical purposes, is still infection. jms From deleskie at gmail.com Sun Jan 4 20:32:06 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 5 Jan 2009 02:32:06 +0000 Subject: Ethical DDoS drone network Message-ID: <776816704-1231122807-cardhu_decombobulator_blackberry.rim.net-1072639310-@bxe125.bisx.prod.on.blackberry> If the drones send a few packets a seconds even say 1000's of pkts per second its value is not likely to be very meaningful, atleast no more so then building an on net resourse. To be meaningful you'd want/need something that could simulate a DDoS. Maybe my assumptions are way off base. You'd also have the concern that if someone 'owned' you 'ethical' botnet being potentially responsible for any damage it caused. Maybe I'm just extra paranoid :) -jim ------Original Message------ From: Mark Foster To: deleskie at gmail.com Cc: Jeffrey Lyon Cc: nanog at merit.edu Subject: Re: Ethical DDoS drone network Sent: Jan 4, 2009 10:26 PM Refer earlier posts. End points ('drones') would have to be legitimate endpoints, not drones on random boxes. That eliminates legal liability client-side. If the traffic is non abusive then I don't see the risk for the network providers in the middle either. If it's clearly established that the source (drones), destination (target) are all 'opted in' and there's no 'collateral damage' (in bandwidth terms or otherwise, being the ways in which I see other parties potentially being impacted) I don't know that it's anywhere near as risky as you imply. You'd have to be careful not to trip IDS or similar for all the networks you transit, to avoid impacting on others in the event of some mis-fired responses... What would be an example legitimate security purpose, except to perhaps drill responses to illegitimate botnets? Mark. On Mon, 5 Jan 2009, deleskie at gmail.com wrote: > Super risky. This would be a 99% legal worry plus. Unless all the end points and networks they cross sign off on it the risk is beyond huge. > > -jim > ------Original Message------ > From: Jeffrey Lyon > Sender: > To: nanog at merit.edu > Subject: Ethical DDoS drone network > Sent: Jan 4, 2009 10:06 PM > > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? > > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. > > Thoughts? > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > > > Sent from my BlackBerry device on the Rogers Wireless Network Sent from my BlackBerry device on the Rogers Wireless Network From jtk at cymru.com Sun Jan 4 21:53:18 2009 From: jtk at cymru.com (John Kristoff) Date: Sun, 4 Jan 2009 21:53:18 -0600 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: <20090104215318.02cc355e@t61p> On Sun, 4 Jan 2009 21:06:34 -0500 "Jeffrey Lyon" wrote: > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? As long as some part of the system (hosts/networks) from the bots to the target is not under your control or prepared for this sort of activity, you may not get a satisfactory answer on this. Its quite likely these days a third party playing the unwitting participant in this botnet may find it objectionable. Is creating and running a botnet the answer? What exactly are you trying to protect against? DDoS? There are potentially various sorts of penetration tests and design reviews you could go through as an alternative to running a so-called "ethical" botnet. Further information on what you're trying to protect against may solicit some useful strategies. John From ge at linuxbox.org Sun Jan 4 21:55:20 2009 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 4 Jan 2009 21:55:20 -0600 (CST) Subject: Ethical DDoS drone network In-Reply-To: <20090104215318.02cc355e@t61p> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> <20090104215318.02cc355e@t61p> Message-ID: On Sun, 4 Jan 2009, John Kristoff wrote: > On Sun, 4 Jan 2009 21:06:34 -0500 > "Jeffrey Lyon" wrote: > >> Say for instance one wanted to create an "ethical botnet," how would >> this be done in a manner that is legal, non-abusive toward other >> networks, and unquestionably used for legitimate internal security >> purposes? How does your company approach this dilemma? > > As long as some part of the system (hosts/networks) from the bots to > the target is not under your control or prepared for this sort of > activity, you may not get a satisfactory answer on this. Its quite > likely these days a third party playing the unwitting participant in > this botnet may find it objectionable. > > Is creating and running a botnet the answer? What exactly are you > trying to protect against? DDoS? > > There are potentially various sorts of penetration tests and design > reviews you could go through as an alternative to running a so-called > "ethical" botnet. Further information on what you're trying to protect > against may solicit some useful strategies. A legal botnet is a distributed system you own. A legal DDoS network doesn't exist. The question is set wrong, no? > John > From admin at racksecurity.net Sun Jan 4 22:00:27 2009 From: admin at racksecurity.net (Zach) Date: Sun, 4 Jan 2009 22:00:27 -0600 Subject: Ethical DDoS drone network In-Reply-To: References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> <20090104215318.02cc355e@t61p> Message-ID: <3918cf170901042000g3728a609v23825d4e108659f4@mail.gmail.com> Agreed, Gadi. It wouldn't be an attack if it were ethical. Technically, that would be "load testing" or "stress testing". Might I suggest this to help? http://www.opensourcetesting.org/performance.php On Sun, Jan 4, 2009 at 9:55 PM, Gadi Evron wrote: > On Sun, 4 Jan 2009, John Kristoff wrote: > >> On Sun, 4 Jan 2009 21:06:34 -0500 >> "Jeffrey Lyon" wrote: >> >> Say for instance one wanted to create an "ethical botnet," how would >>> this be done in a manner that is legal, non-abusive toward other >>> networks, and unquestionably used for legitimate internal security >>> purposes? How does your company approach this dilemma? >>> >> >> As long as some part of the system (hosts/networks) from the bots to >> the target is not under your control or prepared for this sort of >> activity, you may not get a satisfactory answer on this. Its quite >> likely these days a third party playing the unwitting participant in >> this botnet may find it objectionable. >> >> Is creating and running a botnet the answer? What exactly are you >> trying to protect against? DDoS? >> >> There are potentially various sorts of penetration tests and design >> reviews you could go through as an alternative to running a so-called >> "ethical" botnet. Further information on what you're trying to protect >> against may solicit some useful strategies. >> > > A legal botnet is a distributed system you own. > > A legal DDoS network doesn't exist. The question is set wrong, no? > > > > John >> >> > From bmanning at vacation.karoshi.com Sun Jan 4 22:27:02 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Jan 2009 04:27:02 +0000 Subject: Ethical DDoS drone network In-Reply-To: References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> <20090104215318.02cc355e@t61p> Message-ID: <20090105042702.GA28889@vacation.karoshi.com.> On Sun, Jan 04, 2009 at 09:55:20PM -0600, Gadi Evron wrote: > > A legal botnet is a distributed system you own. > > A legal DDoS network doesn't exist. The question is set wrong, no? > kind of depends on what the model is. a botnet for hire to "red-team" my network might be just the ticket. --bill From patrick at ianai.net Mon Jan 5 00:08:24 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Jan 2009 01:08:24 -0500 Subject: Ethical DDoS drone network In-Reply-To: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> Message-ID: On Jan 4, 2009, at 9:18 PM, deleskie at gmail.com wrote: > Super risky. This would be a 99% legal worry plus. Unless all the > end points and networks they cross sign off on it the risk is beyond > huge. Since when do I need permission of "networks they cross" to send data from a machine I (legitimately) own to another machine I own? If this were an FTP or other data transfer, would I have any legal issues? And if not, how is that different from load testing using a random protocol? Before anyone jumps up & down, I know that all networks reserve the right to filter, use TE, or otherwise alter traffic passing over their infrastructure to avoid damage to the whole. But if I want to (for instance) stream a few 100 Gbps and am paying transit for all bits sent or received, since when do I have any legal worries? You want to 'attack' yourself, I do not see any problems. And I see lots of possible benefits. Hell, just figuring out which intermediate networks cannot handle the added load is useful information. -- TTFN, patrick > ------Original Message------ > From: Jeffrey Lyon > Sender: > To: nanog at merit.edu > Subject: Ethical DDoS drone network > Sent: Jan 4, 2009 10:06 PM > > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? > > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. > > Thoughts? > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > > > Sent from my BlackBerry device on the Rogers Wireless Network From mysidia at gmail.com Mon Jan 5 00:12:13 2009 From: mysidia at gmail.com (James Hess) Date: Mon, 5 Jan 2009 00:12:13 -0600 Subject: Ethical DDoS drone network In-Reply-To: <20090105042702.GA28889@vacation.karoshi.com.> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> <20090104215318.02cc355e@t61p> <20090105042702.GA28889@vacation.karoshi.com.> Message-ID: <6eb799ab0901042212i149e106gd9a8164a965d31cf@mail.gmail.com> On Sun, Jan 4, 2009 at 10:27 PM, wrote: > On Sun, Jan 04, 2009 at 09:55:20PM -0600, Gadi Evron wrote: >> A legal botnet is a distributed system you own. >> A legal DDoS network doesn't exist. The question is set wrong, no? > kind of depends on what the model is. a botnet for hire > to "red-team" my network might be just the ticket. You probably don't have to entirely "own" the distributed system for it to be legal. You could just control it with proper authorization. A legal botnet is one whose deployment and operations doesn't break any laws in any of the relevant jurisdictions. The ways to achieve this are legal considerations, not technical considerations. I'm not thinking this list is really a good place to ask a question about legality and get an answer you can rely on. You need to confer with your lawyers about how exactly your botnet can or can't be built and still be legal. This may depend on what country your botnet operates in, where you are, where your nodes are, etc. But thoroughly control and restrain every possible factor that could ever make your botnet illegal, and the result should (imho) be legal... This is not an exhaustive enumeration, but some situations that often make illegal botnets illegal are: (A) The botnet operator runs code on computers without authorization, or the botnet software exploits security vulnerabilities in victim computers to install without permission i.e. operator gains unauthorized access to a computer to deploy botnet nodes, or the software is a worm. This problem is avoided if you take measures to guarantee you own every node, or if you guarantee you have full permission for every computer you will possibly run botnet software on, to the full extent of the botnet node's activities. And you ensure botnet software used never automatically "spreads itself" like a worm. This way, all access you gain to node PCs is authorized. (B) Botnet node software conducts unauthorized activities after it is installed on the host PC. e.g. Theft of services. Perhaps an authorized user of the PC did install the software, but they installed it for an entirely different purpose, the botnet node is hidden software, not noted in the product brochure or other prominent information about the software. This problem is avoided if you make sure the person giving permission to install the software is aware of the botnet node and all its expected activities, before a botnet node can be brought up. (C) Traffic generated by a botnet could be illegal. For example, traffic in excess of agreements you have in place, or in violation of your ISP's TOS, TOU, or AUP, may be questionable. Ethically: You need permission from owners of the source and destination networks the botnet generates traffic on, not just the source and destination computers. For example, you have agreements for 10 gigs, but your botnet test accidentally sends 50 gigs towards your remote site, or one of the thousands of nodes saturates a shared link at its local site that belongs to someone else. An attempt to simulate a DDoS against your own network could inadvertently turn out to be a real DoS on someone else's network as well as yours, for example one of your providers' networks. This is best avoided by maintaining tight control over any distributed stress testing, and massively distributed stress testing should be quarantined by all available means. The destination of any testing must be a computer you have permission to blow up. And the amount of traffic generated by any botnet node on its LAN need be acceptable. Always retain rigid controls over any traffic generated, and very strong measures to prevent an unauthorized third party from ever being able to make your nodes generate any traffic. At a bare minimum, strong PKI (no MD5 or SHA-1) and digitally-signed timestamped commands for starting a test, with some mechanism to prevent unauthorized creation or replay of commands. Plus multiple failsafe mechanisms to allow a test to be rapidly halted. i.e. all nodes ping a "control point" once every 30 seconds. if two pings are dropped, the node stops in its tracks. So you can kill a runaway botnet by unplugging your control hosts. -- -J From rdobbins at cisco.com Mon Jan 5 00:33:11 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Mon, 5 Jan 2009 14:33:11 +0800 Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> Message-ID: <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: > You want to 'attack' yourself, I do not see any problems. And I see > lots of possible benefits. This can be done internally using various traffic-generation and exploit-testing tools (plenty of open-source and commercial ones available). No need to build a 'botnet', literally - more of a distributed test-harness And it must be *kept* internal; using non-routable space is key, along with ensuring that application-layer effects like recursive DNS requests don't end up leaking and causing problems for others. But before any testing is done on production systems (during maintenance windows scheduled for this type of testing, naturally), it should all be done on airgapped labs, first, IMHO. And prior to any testing of this sort, it makes sense to review the architecture(s), configuration(s), et. al. of the elements to be tested in order to ensure they incorporate the relevant BCPs, and then implement those which haven't yet been deployed, and *then* test. In general, I've found that folks tend to get excited about things like launching simulated attacks, setting up honeypots, and the like, because it's viewed as 'cool' and fun; the reality is that in most cases, analyzing and hardening the infrastructure and all participating nodes/elements/apps/services is a far wiser use of time and resources, even though it isn't nearly as entertaining. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From patrick at ianai.net Mon Jan 5 01:04:03 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Jan 2009 02:04:03 -0500 Subject: Ethical DDoS drone network In-Reply-To: <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> Message-ID: <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote: > On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: > >> You want to 'attack' yourself, I do not see any problems. And I >> see lots of possible benefits. > > This can be done internally using various traffic-generation and > exploit-testing tools (plenty of open-source and commercial ones > available). No need to build a 'botnet', literally - more of a > distributed test-harness > > And it must be *kept* internal; using non-routable space is key, > along with ensuring that application-layer effects like recursive > DNS requests don't end up leaking and causing problems for others. We disagree. I can think of several instances where it _must_ be external. For instance, as I said before, knowing which intermediate networks are incapable of handling the additional load is useful information. > But before any testing is done on production systems (during > maintenance windows scheduled for this type of testing, naturally), > it should all be done on airgapped labs, first, IMHO. Without arguing that point (and there are lots of scenarios where that is not at all necessary, IMHO), it does not change the fact that external testing can be extremely useful after "air-gap" testing. > And prior to any testing of this sort, it makes sense to review the > architecture(s), configuration(s), et. al. of the elements to be > tested in order to ensure they incorporate the relevant BCPs, and > then implement those which haven't yet been deployed, and *then* test. You live in a very structured world. Most people live in reality-land where there are too many variables to control, and not only is it impossible guarantee that everything involved is strict to BCP, but the opposite is almost certainly true. Remember, systems do not work in isolation, and when you touch other networks, weird things happen. > In general, I've found that folks tend to get excited about things > like launching simulated attacks, setting up honeypots, and the > like, because it's viewed as 'cool' and fun; the reality is that in > most cases, analyzing and hardening the infrastructure and all > participating nodes/elements/apps/services is a far wiser use of > time and resources, even though it isn't nearly as entertaining. Here we agree: Entertainment has (should have?) nothing to do with it. -- TTFN, patrick From ge at linuxbox.org Mon Jan 5 01:11:09 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 5 Jan 2009 01:11:09 -0600 (CST) Subject: Ethical DDoS drone network In-Reply-To: <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: On Mon, 5 Jan 2009, Patrick W. Gilmore wrote: > On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote: >> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: >> >>> You want to 'attack' yourself, I do not see any problems. And I see lots >>> of possible benefits. >> >> This can be done internally using various traffic-generation and >> exploit-testing tools (plenty of open-source and commercial ones >> available). No need to build a 'botnet', literally - more of a distributed >> test-harness >> >> And it must be *kept* internal; using non-routable space is key, along with >> ensuring that application-layer effects like recursive DNS requests don't >> end up leaking and causing problems for others. > > We disagree. > > I can think of several instances where it _must_ be external. For instance, > as I said before, knowing which intermediate networks are incapable of > handling the additional load is useful information. > > >> But before any testing is done on production systems (during maintenance >> windows scheduled for this type of testing, naturally), it should all be >> done on airgapped labs, first, IMHO. > > Without arguing that point (and there are lots of scenarios where that is not > at all necessary, IMHO), it does not change the fact that external testing > can be extremely useful after "air-gap" testing. Fine test it by simulation on you or the transit end of the pipes. Do not transmit your test sh?t data across the `net. That solves that question? :) From nonobvious at gmail.com Mon Jan 5 01:28:11 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Sun, 4 Jan 2009 23:28:11 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <49540B3C.8020709@west.net> References: <495274B8.9020806@west.net> <49540B3C.8020709@west.net> Message-ID: <18a5e7cb0901042328u1a02d311pcfceb97670ce3bd@mail.gmail.com> Assuming that what you're getting from Verizon is copper and not FIOS, there should be a number of small to medium-sized ISPs that will provide you with Layer 3 Internet Service using that copper. It will cost you a few dollars a month more, but not a lot more, and you'll not only have more chance of getting somebody with a clue to answer questions, but you'll be able to do things like running servers from home if you want. It looks like Sonic.net doesn't cover Long Beach, but Speakeasy does, and you should be able to find a range of other small clueful ISPs. The off-shore call-center business has changed a lot in the last decade; in addition to Bangalore undercutting the Nebraska and Utah call centers, there are cheaper places like the Phillipines undercutting Bangalore, and Canada's been trying to address unemployment in former fishing villages by promoting call centers (which has the advantage of good English), and VOIP has simplified work-at-home distributed call centers in the rural US. But still, if your company is outsourcing first-line support to script-readers, then they need to be good at recognizing when to get past the initial script and escalate to somebody with more training. On Thu, Dec 25, 2008 at 2:37 PM, Jay Hennigan wrote: > The person wasn't capable of getting the hint when > I asked after several minutes of frustration what the "A" in "AT&T" stood > for, and in fact claimed to have no idea. Actually, for the last N years, the "A" in "AT&T" is just a letter; the company name stopped being an acronym for "American Telephone & Telegraph" even before they were bought by the Company Formerly Known As SBC. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From kris.foster at gmail.com Mon Jan 5 01:43:08 2009 From: kris.foster at gmail.com (kris foster) Date: Sun, 4 Jan 2009 23:43:08 -0800 Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: On Jan 4, 2009, at 11:11 PM, Gadi Evron wrote: > On Mon, 5 Jan 2009, Patrick W. Gilmore wrote: >> On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote: >>> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: >> I can think of several instances where it _must_ be external. For >> instance, as I said before, knowing which intermediate networks are >> incapable of handling the additional load is useful information. >> >>> But before any testing is done on production systems (during >>> maintenance windows scheduled for this type of testing, >>> naturally), it should all be done on airgapped labs, first, IMHO. >> >> Without arguing that point (and there are lots of scenarios where >> that is not at all necessary, IMHO), it does not change the fact >> that external testing can be extremely useful after "air-gap" >> testing. > > Fine test it by simulation on you or the transit end of the pipes. > Do not transmit your test sh?t data across the `net. How do you propose a model is built for the simulation if you can't collect data from the real world? This is not "sh?t data". Performance testing across networks is very real and happening now. The more knowledge I have of a path the better decisions I can make about that path. Kris From rdobbins at cisco.com Mon Jan 5 01:54:50 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Mon, 5 Jan 2009 15:54:50 +0800 Subject: Ethical DDoS drone network In-Reply-To: <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: On Jan 5, 2009, at 3:04 PM, Patrick W. Gilmore wrote: > I can think of several instances where it _must_ be external. For > instance, as I said before, knowing which intermediate networks are > incapable of handling the additional load is useful information. AUPs are a big issue, here.. > Without arguing that point (and there are lots of scenarios where > that is not at all necessary, IMHO), it does not change the fact > that external testing can be extremely useful after "air-gap" testing. Agree completely. > You live in a very structured world. The idea is to instantiate structure in order to reduce the chaos. ;> > Most people live in reality-land where there are too many variables > to control, and not only is it impossible guarantee that everything > involved is strict to BCP, but the opposite is almost certainly true. Nothing's perfect, but one must do the basics before moving on to more advanced things. The low-hanging fruit, as it were (and of course, this is where scale becomes a major obstacle, in many cases; the fruit may be hanging low to the ground, but there can be a *lot* of it to pick). > Remember, systems do not work in isolation, and when you touch other > networks, weird things happen. One ought to get one's own house in order first, prior to looking at externalities. Agree with you 100% that they're important, but one must do what one can within one's own span of control, first. > Here we agree: Entertainment has (should have?) nothing to do with it. Implementing BCPs is drudgery; because of this, it often receives short shrift. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From ge at linuxbox.org Mon Jan 5 02:39:10 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 5 Jan 2009 02:39:10 -0600 (CST) Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: On Sun, 4 Jan 2009, kris foster wrote: > > On Jan 4, 2009, at 11:11 PM, Gadi Evron wrote: > >> On Mon, 5 Jan 2009, Patrick W. Gilmore wrote: >>> On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote: >>>> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: >>> I can think of several instances where it _must_ be external. For >>> instance, as I said before, knowing which intermediate networks are >>> incapable of handling the additional load is useful information. >>> >>>> But before any testing is done on production systems (during maintenance >>>> windows scheduled for this type of testing, naturally), it should all be >>>> done on airgapped labs, first, IMHO. >>> >>> Without arguing that point (and there are lots of scenarios where that is >>> not at all necessary, IMHO), it does not change the fact that external >>> testing can be extremely useful after "air-gap" testing. >> >> Fine test it by simulation on you or the transit end of the pipes. Do not >> transmit your test sh?t data across the `net. > > How do you propose a model is built for the simulation if you can't collect > data from the real world? > > This is not "sh?t data". Performance testing across networks is very real and > happening now. The more knowledge I have of a path the better decisions I can > make about that path. > I am sorry for joking, I was sure we were talking about DDoS testing? > Kris From leo.vegoda at icann.org Mon Jan 5 03:09:09 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 5 Jan 2009 01:09:09 -0800 Subject: 108/8 and 184/8 allocated to ARIN Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to ARIN in December 2008: 108/8 and 184/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.9.0.397 wj8DBQFJYcuzvBLymJnAzRwRAiHoAJ9ElxHBdXiQEYcWTE+QMKIA4+0rpwCgmbTy w5fYf3la3xtY5SjT5w+dS/w= =xUKB -----END PGP SIGNATURE----- From patrick at ianai.net Mon Jan 5 05:53:49 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Jan 2009 06:53:49 -0500 Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: On Jan 5, 2009, at 3:39 AM, Gadi Evron wrote: > On Sun, 4 Jan 2009, kris foster wrote: >> On Jan 4, 2009, at 11:11 PM, Gadi Evron wrote: >> >>> On Mon, 5 Jan 2009, Patrick W. Gilmore wrote: >>>> On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote: >>>>> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: >>>> I can think of several instances where it _must_ be external. >>>> For instance, as I said before, knowing which intermediate >>>> networks are incapable of handling the additional load is useful >>>> information. >>>>> But before any testing is done on production systems (during >>>>> maintenance windows scheduled for this type of testing, >>>>> naturally), it should all be done on airgapped labs, first, IMHO. >>>> Without arguing that point (and there are lots of scenarios where >>>> that is not at all necessary, IMHO), it does not change the fact >>>> that external testing can be extremely useful after "air-gap" >>>> testing. >>> Fine test it by simulation on you or the transit end of the pipes. >>> Do not transmit your test sh?t data across the `net. >> >> How do you propose a model is built for the simulation if you can't >> collect data from the real world? >> >> This is not "sh?t data". Performance testing across networks is >> very real and happening now. The more knowledge I have of a path >> the better decisions I can make about that path. > I am sorry for joking, I was sure we were talking about DDoS testing? I've been called by more one provider because I was "DDoS'ing" someone with traffic that someone requested. Strange how the word "DDoS" has morphed over time. But back to your original point, how can you tell it is shit data? DDoSes frequently use valid requests or even full connections. If I send my web server port 80 SYNs, why would you complain? Knowing whether the systems - internal _and_ external - can handle a certain load (and figuring out why not, then fixing it) is vital to many people / companies / applications. Despite the rhetoric here, it is simply not possible to "test" that in a lab. And I guarantee if you do not test it, there _will_ be unexpected problems when Bad Stuff happens. As mentioned before, Reality Land is not clean and structured. -- TTFN, patrick From patrick at ianai.net Mon Jan 5 05:55:44 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Jan 2009 06:55:44 -0500 Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: <6C6E5ECF-A345-4839-A4F0-563A9ED2A627@ianai.net> On Jan 5, 2009, at 2:54 AM, Roland Dobbins wrote: > On Jan 5, 2009, at 3:04 PM, Patrick W. Gilmore wrote: > >> I can think of several instances where it _must_ be external. For >> instance, as I said before, knowing which intermediate networks are >> incapable of handling the additional load is useful information. > > AUPs are a big issue, here.. No, they are not. AUPs do not stop me from sending traffic from my host to my host across links I am paying for. >> Without arguing that point (and there are lots of scenarios where >> that is not at all necessary, IMHO), it does not change the fact >> that external testing can be extremely useful after "air-gap" >> testing. > > Agree completely. > >> You live in a very structured world. > > The idea is to instantiate structure in order to reduce the chaos. > > ;> > >> Most people live in reality-land where there are too many variables >> to control, and not only is it impossible guarantee that everything >> involved is strict to BCP, but the opposite is almost certainly true. > > Nothing's perfect, but one must do the basics before moving on to > more advanced things. The low-hanging fruit, as it were (and of > course, this is where scale becomes a major obstacle, in many cases; > the fruit may be hanging low to the ground, but there can be a *lot* > of it to pick). Perhaps we are miscommunicating. You seem to think I am saying people should test externally before they know whether their internal systems work. Of course that is a silly idea. That does not invalidate the need for external testing. Nor does it guarantee everything will be "BCP compliant", especially since "everything" includes things outside your control. -- TTFN, patrick From frnkblk at iname.com Mon Jan 5 10:24:37 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 5 Jan 2009 10:24:37 -0600 Subject: Leap second tonight In-Reply-To: References: Message-ID: A report from a DHCP/DNS appliance vendor here: ==================== Several customers have reported a complete lock-up of their Proteus system around the beginning of January 1st 2009. We believe that we have traced this to a problem in the underlying kernel and NTP and the handling of the date change associated with 2008 being a Leap Year and therefore having 366 days. Several conditions must be met to trigger this problem: 1. The Proteus was originally installed as v2.1.x or earlier. 2. NTP is enabled as a client with 2 or more external source servers defined. 3. There is a discrepancy in the times reported back by these other NTP servers. There is no correction available at this time, and the resolution is to power cycle the system, after which it will run fine. If you experienced a similar problem at the indicated time, please submit a trouble ticket so that we can confirm that this occurred on your system. ==================== I don't know what the underlying OS is. Frank -----Original Message----- From: Kevin Day [mailto:toasty at dragondata.com] Sent: Wednesday, December 31, 2008 4:42 PM To: NANOG list Subject: Leap second tonight Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+r eminder+nanog&page=1&refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin From frnkblk at iname.com Mon Jan 5 10:28:31 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 5 Jan 2009 10:28:31 -0600 Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly In-Reply-To: References: Message-ID: Thanks for all those who responded on and off-list. Several persons confirmed for me using their Akamai account that the address space was correctly listed in Akamai's database, and between Google's quasi-generic online form (http://google.com/support/bin/request.py?contact_type=ip) and a Google employee, I think we'll get this straightened out. Frank -----Original Message----- From: Frank Bulk - iName.com [mailto:frnkblk at iname.com] Sent: Friday, January 02, 2009 8:37 AM To: nanog at nanog.org Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly We were assigned a new block from ARIN two weeks ago and are getting several reports from end users that the Spanish and German versions of Google's search page are coming up. IP2Location and Maxmind are mostly correct, but there appears to be no way for me to verify that Google and Akamai have 96.31.0.0/20 listed correctly. Perhaps someone can point me in the right direction so I can make an authoritative check. Thanks, Frank From adrian at creative.net.au Mon Jan 5 10:30:51 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 6 Jan 2009 01:30:51 +0900 Subject: Leap second tonight In-Reply-To: References: Message-ID: <20090105163051.GB18304@skywalker.creative.net.au> This begs the question - how the heck do timekeepers and politicians get away with last minute time changes? Surely there's -some- pushback from technology related interest groups to try and get more than four weeks warning? :) Adrian On Mon, Jan 05, 2009, Frank Bulk wrote: > A report from a DHCP/DNS appliance vendor here: > ==================== > Several customers have reported a complete lock-up of their Proteus system > around the beginning of January 1st 2009. We believe that we have traced > this to a problem in the underlying kernel and NTP and the handling of the > date change associated with 2008 being a Leap Year and therefore having 366 > days. > > Several conditions must be met to trigger this problem: > 1. The Proteus was originally installed as v2.1.x or earlier. > 2. NTP is enabled as a client with 2 or more external source servers > defined. > 3. There is a discrepancy in the times reported back by these other NTP > servers. > > There is no correction available at this time, and the resolution is to > power cycle the system, after which it will run fine. > > If you experienced a similar problem at the indicated time, please submit a > trouble ticket so that we can confirm that this occurred on your system. > ==================== > > I don't know what the underlying OS is. > > Frank > > -----Original Message----- > From: Kevin Day [mailto:toasty at dragondata.com] > Sent: Wednesday, December 31, 2008 4:42 PM > To: NANOG list > Subject: Leap second tonight > > > Just a reminder that there's a leap second tonight. > > Last time I watched for what happened on 01/01/2006, there was a > little bit of chaos: > http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+r > eminder+nanog&page=1&refer=cnkxb3iv7sls5axu > > I've been told that some of the causes of these problems are fixed on > any reasonably recent ntp distribution, but just in case, you might > wanna keep an eye out if you're seeing any weirdness. The worst damage > I'd heard from anyone after that event was their clock being > significantly off for several hours. > > -- Kevin > > > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA - From nick at foobar.org Mon Jan 5 10:36:38 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 05 Jan 2009 16:36:38 +0000 Subject: Leap second tonight In-Reply-To: <20090105163051.GB18304@skywalker.creative.net.au> References: <20090105163051.GB18304@skywalker.creative.net.au> Message-ID: <49623716.9000805@foobar.org> Adrian Chadd wrote: > This begs the question - how the heck do timekeepers and politicians get > away with last minute time changes? > > Surely there's -some- pushback from technology related interest groups to > try and get more than four weeks warning? :) ? Notice for the leap second was issued on July 4 2008. http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.36 Nick From msa at latt.net Mon Jan 5 10:43:17 2009 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 5 Jan 2009 16:43:17 +0000 Subject: Leap second tonight In-Reply-To: <20090105163051.GB18304@skywalker.creative.net.au> References: <20090105163051.GB18304@skywalker.creative.net.au> Message-ID: <20090105164317.GA90661@mx1.latt.net> On Tue, Jan 06, 2009 at 01:30:51AM +0900, Adrian Chadd wrote: > This begs the question - how the heck do timekeepers and politicians get > away with last minute time changes? > > Surely there's -some- pushback from technology related interest groups to > try and get more than four weeks warning? :) Try six months. NTP itself sets the leap indicator by 28 days prior to the leap and clears it before the end of the following day, so in theory the appliance itself had at least 4 weeks notice and the rest of us had an additional five months. IERS announces a pending leap second six months in advance. The announcement for this one was dated July 4th. System vendors have only had 37 years since the first leap second to figure this out; please be patient. However, I can't excuse them for bugs surrounding the final day of a leap year. The Julian calendar is not exactly a new phenomenon. --msa From adrian at creative.net.au Mon Jan 5 10:44:50 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 6 Jan 2009 01:44:50 +0900 Subject: Leap second tonight In-Reply-To: <49623716.9000805@foobar.org> References: <20090105163051.GB18304@skywalker.creative.net.au> <49623716.9000805@foobar.org> Message-ID: <20090105164450.GC18304@skywalker.creative.net.au> On Mon, Jan 05, 2009, Nick Hilliard wrote: > Notice for the leap second was issued on July 4 2008. > > http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.36 > Wow, how'd I miss that, I wonder? :) I'm just angry at the jack moves pulled by last minute timezone changes back in Australia, and the massively stupid repercussions seen throughout chunks of IT (incl. network auditing setups I had to poke at the time.) I'll add "handling second == 60" to the list of things I should check for in my code. Thanks. :) Adrian From r.engehausen at gmail.com Mon Jan 5 10:46:55 2009 From: r.engehausen at gmail.com (Roy) Date: Mon, 05 Jan 2009 08:46:55 -0800 Subject: Leap second tonight In-Reply-To: <20090105163051.GB18304@skywalker.creative.net.au> References: <20090105163051.GB18304@skywalker.creative.net.au> Message-ID: <4962397F.2020301@gmail.com> Adrian Chadd wrote: > This begs the question - how the heck do timekeepers and politicians get > away with last minute time changes? > > Surely there's -some- pushback from technology related interest groups to > try and get more than four weeks warning? :) > > > > Adrian > > .... The first notice I found was dated July 4th 2008 http://tycho.usno.navy.mil/bulletinc2008.html From tmbattles at att.com Mon Jan 5 10:54:06 2009 From: tmbattles at att.com (BATTLES, TIMOTHY A (TIM), ATTLABS) Date: Mon, 5 Jan 2009 11:54:06 -0500 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1735@gaalpa1msgusr7a.ugd.att.com> There are some assumptions here. First are you considering volumetric DDOS attacks? Second, if you plan on harvesting wild bots and using them to serve your purpose then I don't see how this can be ethical unless they are just clients from your own network making it less distributed. You would then have to have this in your AUP allowing you to do this. Hmm, I really don't know what you would gain by this. Not knowing what your network looks like...but assuming your somewhat scaled, I would think this could all be done in the lab. -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: Sunday, January 04, 2009 8:07 PM To: nanog at merit.edu Subject: Ethical DDoS drone network Say for instance one wanted to create an "ethical botnet," how would this be done in a manner that is legal, non-abusive toward other networks, and unquestionably used for legitimate internal security purposes? How does your company approach this dilemma? Our company for instance has always relied on outside attacks to spot check our security and i'm beginning to think there may be a more user friendly alternative. Thoughts? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From nick at foobar.org Mon Jan 5 11:01:58 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 05 Jan 2009 17:01:58 +0000 Subject: Leap second tonight In-Reply-To: <20090105164450.GC18304@skywalker.creative.net.au> References: <20090105163051.GB18304@skywalker.creative.net.au> <49623716.9000805@foobar.org> <20090105164450.GC18304@skywalker.creative.net.au> Message-ID: <49623D06.2070702@foobar.org> Adrian Chadd wrote: > Wow, how'd I miss that, I wonder? :) I would recommend lodging a complaint to the relevant authorities. That's sure to help. But seriously. Leap seconds occur every couple of years, either on July 30th and Dec 31. Sometimes both. And sometimes every consecutive year for a couple of years on the run. If your code insists on exactly 60 seconds in all minutes, or 86400 seconds in a hour, your code is wrong. You need to take this into account, because leap seconds are actually pretty common occurrences. > I'm just angry at the jack moves pulled by last minute timezone changes > back in Australia, and the massively stupid repercussions seen throughout > chunks of IT (incl. network auditing setups I had to poke at the time.) > > I'll add "handling second == 60" to the list of things I should check > for in my code. Thanks. :) Yeah, last minute declarations are annoying. Like the british government's mad-cap idea to change VAT for the first time in donkey's years from 17.5% to 15% with 7 days warning. Now that's screwed up. Nick From tme at multicasttech.com Mon Jan 5 11:21:22 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 5 Jan 2009 12:21:22 -0500 Subject: Leap second tonight In-Reply-To: <20090105163051.GB18304@skywalker.creative.net.au> References: <20090105163051.GB18304@skywalker.creative.net.au> Message-ID: <6F0A37B2-75B8-4E71-A3F3-40DC100B2D7B@multicasttech.com> On Jan 5, 2009, at 11:30 AM, Adrian Chadd wrote: > This begs the question - how the heck do timekeepers and politicians > get > away with last minute time changes? > > Surely there's -some- pushback from technology related interest > groups to > try and get more than four weeks warning? :) > > Having been involved in the leap second business, I can tell you that Daniel Gambis strictly follows the rules, which are Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. If you want more lead time warning, pay attention to the LOD graph in http://hpiers.obspm.fr/eop-pc/ The long term LOD offset is about 1 msec now. That means that every day, Earth time and atomic time will drift off by 1 msec. Since there are 1000 msec in the second, and since the rule is that a leap second is chosen when the difference (UT1?UTC) approaches 0.9 seconds, projected out to the next period, and since the strong preference is to have leap seconds in January, you can generally figure out what will happen before Daniel announces it. For example, in one year the offset should be ~ 400 msec, so I will informally predict another leap second in January, 2011, not 2010. Keep watching that graph. Anyone who is dealing with Leap Second code should keep in mind that negative leap seconds (i.e., no second # 59, instead of an extra second called 60) are a distinct possibility. It all depends on the "weather" at the core mantle boundary - note that the LOD offset was almost 3 msec not too long ago. Regards Marshall > > Adrian > > On Mon, Jan 05, 2009, Frank Bulk wrote: >> A report from a DHCP/DNS appliance vendor here: >> ==================== >> Several customers have reported a complete lock-up of their Proteus >> system >> around the beginning of January 1st 2009. We believe that we have >> traced >> this to a problem in the underlying kernel and NTP and the handling >> of the >> date change associated with 2008 being a Leap Year and therefore >> having 366 >> days. >> >> Several conditions must be met to trigger this problem: >> 1. The Proteus was originally installed as v2.1.x or earlier. >> 2. NTP is enabled as a client with 2 or more external source servers >> defined. >> 3. There is a discrepancy in the times reported back by these other >> NTP >> servers. >> >> There is no correction available at this time, and the resolution >> is to >> power cycle the system, after which it will run fine. >> >> If you experienced a similar problem at the indicated time, please >> submit a >> trouble ticket so that we can confirm that this occurred on your >> system. >> ==================== >> >> I don't know what the underlying OS is. >> >> Frank >> >> -----Original Message----- >> From: Kevin Day [mailto:toasty at dragondata.com] >> Sent: Wednesday, December 31, 2008 4:42 PM >> To: NANOG list >> Subject: Leap second tonight >> >> >> Just a reminder that there's a leap second tonight. >> >> Last time I watched for what happened on 01/01/2006, there was a >> little bit of chaos: >> http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+r >> eminder+nanog&page=1&refer=cnkxb3iv7sls5axu >> >> I've been told that some of the causes of these problems are fixed on >> any reasonably recent ntp distribution, but just in case, you might >> wanna keep an eye out if you're seeing any weirdness. The worst >> damage >> I'd heard from anyone after that event was their clock being >> significantly off for several hours. >> >> -- Kevin >> >> >> > > -- > - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial > Squid Support - > - $25/pm entry-level VPSes w/ capped bandwidth charges available in > WA - > From Valdis.Kletnieks at vt.edu Mon Jan 5 11:19:24 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Jan 2009 12:19:24 -0500 Subject: Ethical DDoS drone network In-Reply-To: Your message of "Mon, 05 Jan 2009 06:53:49 EST." References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: <20157.1231175964@turing-police.cc.vt.edu> On Mon, 05 Jan 2009 06:53:49 EST, "Patrick W. Gilmore" said: > Knowing whether the systems - internal _and_ external - can handle a > certain load (and figuring out why not, then fixing it) is vital to > many people / companies / applications. Despite the rhetoric here, it > is simply not possible to "test" that in a lab. And I guarantee if > you do not test it, there _will_ be unexpected problems when Bad Stuff > happens. Amen to that, brother. Trust me, you definitely want to do your load testing at a 2AM (or other usually dead time) of your own choosing, when you have the ability to pull the switch on the test almost instantly if it gets out of hand. The *last* think you want is to get a surprise slashdotting of your web servers while the police have your entire site under lockdown. Been there, done that, it's not fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From eddy+public+spam at noc.everquick.net Mon Jan 5 11:41:51 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 5 Jan 2009 17:41:51 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: PWG> Date: Mon, 5 Jan 2009 06:53:49 -0500 PWG> From: Patrick W. Gilmore PWG> But back to your original point, how can you tell it is shit data? AFAIK, RFC 3514 is the only standards document that has addressed this. I have yet to see it implemented. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From justin at justinshore.com Mon Jan 5 11:43:25 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 05 Jan 2009 11:43:25 -0600 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <20081227043742.008B44500F@ptavv.es.net> References: <20081227043742.008B44500F@ptavv.es.net> Message-ID: <496246BD.6090308@justinshore.com> Kevin Oberman wrote: > I would hope you have a backbone well enough secured that you don't need > to rely on this, but it does make me a bit more relaxed and makes me > wish we were using ISIS for IPv4, as well. The time and disruption > involved in converting is something that will keep us running OSPF for > IPv4 for a long time, though. I remember the 'fun' of converting from > IGRP to OSPF about 13 years ago and I'd prefer to retire before a > repeat. I did the OSPF --> IS-IS migration some time back and here's some of the info I found at the time. http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=&nm=nanog29 Vijay did a nice presentation on AOL's migration to IS-IS. IIRC AOL migrated everything in 2 days. Day 1 was to migrate their test POP and hone their script. All remaining POPs were migrated on Day 2. I believe he said it went well. There have been several other documented migrations too: http://www.geant.net/upload/pdf/GEANT-OSPF-to-ISIS-Migration.pdf http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof-ospf.pdf I migrated my SP from a flat OSPF network (end to end area 0) to IS-IS. The OSPF setup was seriously screwed up. Someone got the bright idea to changes admin distances on some OSPF speakers, introduce a default in some places with static defaults in others, redistributing like it was going out of style, redisting a static for a large customer subnet on P2 instead of P1 which is what PE1 actually connected to (and not advertising the route from PE1 for some unknown reason), etc. The old setup was a nightmare. The IS-IS migration went fairly well after I got some major bugs worked out on our 7600s. I implemented IS-IS overtop of OSPF. Some OSPF speakers had admin distances of 80 and some were default. IS-IS slipped in over top with no problems. I raised IS-IS to 254 for the initial phase anyway just to be safe. Once I had IS-IS up I verified it learned all the expected routes via IS-IS. Then I lowered its admin distance back to the default and bumped OSPF up to 254. Shortly thereafter I nuked OSPF from each device. It was hitless. I never could get IS-IS to work with multiple areas. The 7600s made a smelly mess on the CO floor every time I tried. In the end I went with a L2-only IS-IS network. Still it works well for the most part. I've had about as much trouble with IS-IS as I have had with OSPF. Occasionally some random router will get a burr under it's saddle and jack up the MTU on the CLNS packets beyond the interface's max. The receiving router will drop the padded frame as too big. Fixing this can sometimes happen with a shut/no shut. Sometimes I can nuke the entire IS-IS config and re-add the config. Other times I simply have to reboot. This doesn't happen too often; it's usually several hours after I rock the IS-IS boat so to speak. Still, I wouldn't go back to OSPF for this SP. Justin From eddy+public+spam at noc.everquick.net Mon Jan 5 11:51:38 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 5 Jan 2009 17:51:38 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: RD> Date: Mon, 5 Jan 2009 15:54:50 +0800 RD> From: Roland Dobbins RD> AUPs are a big issue, here.. And AUPs [theoretically] set forth definitions. Of course, there exist colo providers with "unlimited 10 Gbps bandwidth" whose AUPs read "do not use 'too much' bandwith or we will get angry", thus introducing ambiguity regarding just _for what_ one is paying... Perhaps "abuse" is best _operationally_ defined as "something that angers someone enough that it's at least sort of likely to cost you some money -- and maybe even a lot"? Were the definition clear, I doubt there'd be such a long NANOG thread. (Yes, I'm feeling optimistic today.) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From leo.vegoda at icann.org Mon Jan 5 11:52:54 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 5 Jan 2009 09:52:54 -0800 Subject: Leap second tonight In-Reply-To: <49623D06.2070702@foobar.org> Message-ID: On 05/01/2009 6:01, "Nick Hilliard" wrote: [...] > But seriously. Leap seconds occur every couple of years, either on July > 30th and Dec 31. Sometimes both. And sometimes every consecutive year for > a couple of years on the run. It's theoretically possible for leap seconds to be introduced at the end of March and September. It's never happened but it might, so I suppose software should allow for the possibility. Regards, Leo From jeffrey.lyon at blacklotus.net Mon Jan 5 11:54:24 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 5 Jan 2009 12:54:24 -0500 Subject: Ethical DDoS drone network In-Reply-To: References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> Message-ID: <16720fe00901050954n3df0857cq7b89f732889b9a4f@mail.gmail.com> FWIW, I'm primarily concerned about testing PPS loads and not brute force bandwidth. Best regards, Jeff On Mon, Jan 5, 2009 at 12:51 PM, Edward B. DREGER wrote: > RD> Date: Mon, 5 Jan 2009 15:54:50 +0800 > RD> From: Roland Dobbins > > RD> AUPs are a big issue, here.. > > And AUPs [theoretically] set forth definitions. > > Of course, there exist colo providers with "unlimited 10 Gbps bandwidth" > whose AUPs read "do not use 'too much' bandwith or we will get angry", > thus introducing ambiguity regarding just _for what_ one is paying... > > Perhaps "abuse" is best _operationally_ defined as "something that > angers someone enough that it's at least sort of likely to cost you some > money -- and maybe even a lot"? > > Were the definition clear, I doubt there'd be such a long NANOG thread. > (Yes, I'm feeling optimistic today.) > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From eddy+public+spam at noc.everquick.net Mon Jan 5 12:02:37 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 5 Jan 2009 18:02:37 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1735@gaalpa1msgusr7a.ugd.att.com> References: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1735@gaalpa1msgusr7a.ugd.att.com> Message-ID: TAB> Date: Mon, 5 Jan 2009 11:54:06 -0500 TAB> From: "BATTLES, TIMOTHY A (TIM), ATTLABS" TAB> assuming your somewhat scaled, I would think this could all be done TAB> in the lab. And end up with a network that works in the lab. :-) - bw * delay - effects of flow caching, where applicable - jitter (esp. under load) - packet dups and loss (esp. under load) - packet reordering and assiciated side-effects - upstream/sidestream throughput (esp. under load) No, reality is far more complex. Some things do not lend themselves to _a priori_ models, nor even "TFAR" generalizations. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From mike.gazzerro at nobistech.net Mon Jan 5 12:13:59 2009 From: mike.gazzerro at nobistech.net (Michael Gazzerro) Date: Mon, 5 Jan 2009 12:13:59 -0600 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901050954n3df0857cq7b89f732889b9a4f@mail.gmail.com> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> <16720fe00901050954n3df0857cq7b89f732889b9a4f@mail.gmail.com> Message-ID: <02c001c96f61$61b480a0$251d81e0$@gazzerro@nobistech.net> You could just troll people on IRC until you get DDOS'd. All the fun, none of the work! -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: Monday, January 05, 2009 11:54 AM To: nanog at merit.edu Subject: Re: Ethical DDoS drone network FWIW, I'm primarily concerned about testing PPS loads and not brute force bandwidth. Best regards, Jeff On Mon, Jan 5, 2009 at 12:51 PM, Edward B. DREGER wrote: > RD> Date: Mon, 5 Jan 2009 15:54:50 +0800 > RD> From: Roland Dobbins > > RD> AUPs are a big issue, here.. > > And AUPs [theoretically] set forth definitions. > > Of course, there exist colo providers with "unlimited 10 Gbps bandwidth" > whose AUPs read "do not use 'too much' bandwith or we will get angry", > thus introducing ambiguity regarding just _for what_ one is paying... > > Perhaps "abuse" is best _operationally_ defined as "something that > angers someone enough that it's at least sort of likely to cost you some > money -- and maybe even a lot"? > > Were the definition clear, I doubt there'd be such a long NANOG thread. > (Yes, I'm feeling optimistic today.) > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From eddy+public+spam at noc.everquick.net Mon Jan 5 12:14:41 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 5 Jan 2009 18:14:41 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901050954n3df0857cq7b89f732889b9a4f@mail.gmail.com> References: <430358952-1231121996-cardhu_decombobulator_blackberry.rim.net-2026598920-@bxe125.bisx.prod.on.blackberry> <89252B2B-BB9B-45AB-A300-B28FA6715A5D@cisco.com> <49D22BC9-F5DD-4CD5-BF61-8762D008D92D@ianai.net> <16720fe00901050954n3df0857cq7b89f732889b9a4f@mail.gmail.com> Message-ID: JL> Date: Mon, 5 Jan 2009 12:54:24 -0500 JL> From: Jeffrey Lyon JL> FWIW, I'm primarily concerned about testing PPS loads and not brute JL> force bandwidth. Which underscores my point: bps with minimally-sized packets is even higher pps than bps with "normal"-sized packets, for any non-minimal value of "normal". Thus, the potential for breaking something that scales based on pps instead of bps _increases_ under such testing. I've not [yet] seen an AUP that reads "customer shall maintain a minimum packet size of 400 bytes (combined IP header and payload) averaged over a moving one-hour window". ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From rcorbin at traffiq.com Mon Jan 5 12:19:06 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Mon, 5 Jan 2009 12:19:06 -0600 Subject: Ethical DDoS drone network In-Reply-To: <02c001c96f61$61b480a0$251d81e0$@gazzerro@nobistech.net> Message-ID: Until you get hit at 8GB/s and then don't have a nice 'off' button.. -r -----Original Message----- From: Michael Gazzerro [mailto:mike.gazzerro at nobistech.net] Sent: Monday, January 05, 2009 1:14 PM To: 'Jeffrey Lyon'; nanog at merit.edu Subject: RE: Ethical DDoS drone network You could just troll people on IRC until you get DDOS'd. All the fun, none of the work! -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: Monday, January 05, 2009 11:54 AM To: nanog at merit.edu Subject: Re: Ethical DDoS drone network FWIW, I'm primarily concerned about testing PPS loads and not brute force bandwidth. Best regards, Jeff On Mon, Jan 5, 2009 at 12:51 PM, Edward B. DREGER wrote: > RD> Date: Mon, 5 Jan 2009 15:54:50 +0800 > RD> From: Roland Dobbins > > RD> AUPs are a big issue, here.. > > And AUPs [theoretically] set forth definitions. > > Of course, there exist colo providers with "unlimited 10 Gbps bandwidth" > whose AUPs read "do not use 'too much' bandwith or we will get angry", > thus introducing ambiguity regarding just _for what_ one is paying... > > Perhaps "abuse" is best _operationally_ defined as "something that > angers someone enough that it's at least sort of likely to cost you some > money -- and maybe even a lot"? > > Were the definition clear, I doubt there'd be such a long NANOG thread. > (Yes, I'm feeling optimistic today.) > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From devangnp at gmail.com Mon Jan 5 12:23:11 2009 From: devangnp at gmail.com (devang patel) Date: Mon, 5 Jan 2009 12:23:11 -0600 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <496246BD.6090308@justinshore.com> References: <20081227043742.008B44500F@ptavv.es.net> <496246BD.6090308@justinshore.com> Message-ID: Thanks all for sharing information! regards Devang Patel On Mon, Jan 5, 2009 at 11:43 AM, Justin Shore wrote: > Kevin Oberman wrote: > >> I would hope you have a backbone well enough secured that you don't need >> to rely on this, but it does make me a bit more relaxed and makes me >> wish we were using ISIS for IPv4, as well. The time and disruption >> involved in converting is something that will keep us running OSPF for >> IPv4 for a long time, though. I remember the 'fun' of converting from >> IGRP to OSPF about 13 years ago and I'd prefer to retire before a >> repeat. >> > > I did the OSPF --> IS-IS migration some time back and here's some of the > info I found at the time. > > > http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=&nm=nanog29 > > Vijay did a nice presentation on AOL's migration to IS-IS. IIRC AOL > migrated everything in 2 days. Day 1 was to migrate their test POP and hone > their script. All remaining POPs were migrated on Day 2. I believe he said > it went well. There have been several other documented migrations too: > > http://www.geant.net/upload/pdf/GEANT-OSPF-to-ISIS-Migration.pdf > http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof-ospf.pdf > > I migrated my SP from a flat OSPF network (end to end area 0) to IS-IS. > The OSPF setup was seriously screwed up. Someone got the bright idea to > changes admin distances on some OSPF speakers, introduce a default in some > places with static defaults in others, redistributing like it was going out > of style, redisting a static for a large customer subnet on P2 instead of P1 > which is what PE1 actually connected to (and not advertising the route from > PE1 for some unknown reason), etc. The old setup was a nightmare. > > The IS-IS migration went fairly well after I got some major bugs worked out > on our 7600s. I implemented IS-IS overtop of OSPF. Some OSPF speakers had > admin distances of 80 and some were default. IS-IS slipped in over top with > no problems. I raised IS-IS to 254 for the initial phase anyway just to be > safe. Once I had IS-IS up I verified it learned all the expected routes via > IS-IS. Then I lowered its admin distance back to the default and bumped > OSPF up to 254. Shortly thereafter I nuked OSPF from each device. It was > hitless. I never could get IS-IS to work with multiple areas. The 7600s > made a smelly mess on the CO floor every time I tried. In the end I went > with a L2-only IS-IS network. Still it works well for the most part. I've > had about as much trouble with IS-IS as I have had with OSPF. Occasionally > some random router will get a burr under it's saddle and jack up the MTU on > the CLNS packets beyond the interface's max. The receiving router will drop > the padded frame as too big. Fixing this can sometimes happen with a > shut/no shut. Sometimes I can nuke the entire IS-IS config and re-add the > config. Other times I simply have to reboot. This doesn't happen too > often; it's usually several hours after I rock the IS-IS boat so to speak. > Still, I wouldn't go back to OSPF for this SP. > > Justin > From sethm at rollernet.us Mon Jan 5 12:35:51 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 05 Jan 2009 10:35:51 -0800 Subject: Ethical DDoS drone network In-Reply-To: References: Message-ID: <49625307.4050806@rollernet.us> Ray Corbin wrote: > Until you get hit at 8GB/s and then don't have a nice 'off' button.. > However, it would very accurately simulate a real-world attack where you don't get to have an "off" button. ~Seth From rcorbin at traffiq.com Mon Jan 5 12:45:02 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Mon, 5 Jan 2009 12:45:02 -0600 Subject: Ethical DDoS drone network In-Reply-To: <49625307.4050806@rollernet.us> Message-ID: But I don't think his boss would be too happy when their network is up and down for days because he irk'ed a scriptkiddie on irc just to test their limits :) -r -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, January 05, 2009 1:36 PM To: nanog at merit.edu Subject: Re: Ethical DDoS drone network Ray Corbin wrote: > Until you get hit at 8GB/s and then don't have a nice 'off' button.. > However, it would very accurately simulate a real-world attack where you don't get to have an "off" button. ~Seth From gtb at slac.stanford.edu Mon Jan 5 12:50:29 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Mon, 5 Jan 2009 10:50:29 -0800 Subject: Leap second tonight In-Reply-To: References: <49623D06.2070702@foobar.org> Message-ID: > It's theoretically possible for leap seconds to be introduced > at the end of March and September. As I recall, NTP supports leap seconds every month, for which there is a prediction that even this would be insufficient at some point in this millennium (depending, of course, on the actual rotation speed). There have been on again/off again talks to abolish the leap second for quite a number of years. Gary From tkernen at deckpoint.ch Mon Jan 5 13:02:36 2009 From: tkernen at deckpoint.ch (Thomas Kernen) Date: Mon, 05 Jan 2009 20:02:36 +0100 Subject: Seeking AIM/ICQ security contact Message-ID: <4962594C.8020805@deckpoint.ch> I'm looking for an AIM/ICQ security contact. If someone has any names I can direct my requests to please contact me unicast so we can keep the S/N as low as possible. Thanks Thomas From michael.dillon at bt.com Mon Jan 5 13:39:18 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Jan 2009 19:39:18 -0000 Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901050954n3df0857cq7b89f732889b9a4f@mail.gmail.com> Message-ID: > FWIW, I'm primarily concerned about testing PPS loads and not > brute force bandwidth. Simple solution. Write some DDoS software that folks can install on their own machines. Make its so that the software is only triggered by commands from a device under the same administrative control, i.e. it uses a shared secret that is set up when folks install the software. So far there are two pieces of software, one pieces does the DDoSing, and the other piece controls it. You now need a third bit of software that sends DDoS requests to the controllers, and the controllers don't actually act upon such requests, but queue them until their administrators OK the DDoSing. Think of it a bit like a moderated mailing list. If you product that set of software, I'll bet that a lot of folks would be interested in working together to do DDoS stress testing of each others networks, at times of their own choosing. --Michael Dillon From jasonuhl at jasonuhl.org Mon Jan 5 14:18:59 2009 From: jasonuhl at jasonuhl.org (Jason Uhlenkott) Date: Mon, 5 Jan 2009 12:18:59 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <200901022133.n02LX5G5057940@aurora.sol.net> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> Message-ID: <20090105201859.GC15107@ferrum.uhlenkott.net> On Fri, Jan 02, 2009 at 15:33:05 -0600, Joe Greco wrote: > This would seem to point out some critical shortcomings in the current SSL > system; these shortcomings are not necessarily technological, but rather > social/psychological. We need the ability for Tom, Dick, or Harry to be > able to crank out a SSL cert with a minimum of fuss or cost; having to > learn the complexities of SSL is itself a "fuss" which has significantly > and negatively impacted Internet security. > > Somehow, we managed to figure out how to do this with PGP and keysigning, > but it all fell apart (I can hear the "it doesn't scale" already) with SSL. If we had DNSSEC, we could do away with SSL CAs entirely. The owner of each domain or host could publish a self-signed cert in a TXT RR, and the DNS chain of trust would be the only form of validation needed. From jabley at hopcount.ca Mon Jan 5 14:39:37 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 5 Jan 2009 15:39:37 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <20090105201859.GC15107@ferrum.uhlenkott.net> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> Message-ID: <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> On 2009-01-05, at 15:18, Jason Uhlenkott wrote: > If we had DNSSEC, we could do away with SSL CAs entirely. The owner > of each domain or host could publish a self-signed cert in a TXT RR, ... or even in a CERT RR, as I heard various clever people talking about in some virtual hallway the other day. . > and the DNS chain of trust would be the only form of validation > needed. Joe From randy at psg.com Mon Jan 5 14:47:22 2009 From: randy at psg.com (Randy Bush) Date: Tue, 06 Jan 2009 05:47:22 +0900 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> Message-ID: <496271DA.7040708@psg.com> perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? randy From jabley at hopcount.ca Mon Jan 5 14:59:54 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 5 Jan 2009 15:59:54 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <496271DA.7040708@psg.com> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> Message-ID: <8A9328FD-EEAB-4CCB-A073-0775D71BFB2E@hopcount.ca> On 2009-01-05, at 15:47, Randy Bush wrote: > perhaps i am a bit slow. but could someone explain to me how trust > in dns data transfers to trust in an http partner and other uses to > which ssl is put? If I can get secure answers to "www.bank.example IN CERT?" and "www.bank.example IN A?" then perhaps when I connect to www.bank.example:443 I can decide to trust the certificate presented by the server based on the trust anchor I extracted from the DNS, rather than whatever trust anchors were bundled with my browser. That presumably would mean that the organisation responsible for bank.example could run their own CA and publish their own trust anchor, without having to buy that service from one of the traditional CA companies. No doubt there is more to it than that. I don't know anything much about X.509. Joe From randy at psg.com Mon Jan 5 15:09:34 2009 From: randy at psg.com (Randy Bush) Date: Tue, 06 Jan 2009 06:09:34 +0900 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <8A9328FD-EEAB-4CCB-A073-0775D71BFB2E@hopcount.ca> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> <8A9328FD-EEAB-4CCB-A073-0775D71BFB2E@hopcount.ca> Message-ID: <4962770E.7060000@psg.com> On 09.01.06 05:59, Joe Abley wrote: >> perhaps i am a bit slow. but could someone explain to me how trust in >> dns data transfers to trust in an http partner and other uses to which >> ssl is put? > > If I can get secure answers to "www.bank.example IN CERT?" and > "www.bank.example IN A?" then perhaps when I connect to > www.bank.example:443 I can decide to trust the certificate presented by > the server based on the trust anchor I extracted from the DNS, rather > than whatever trust anchors were bundled with my browser. > > That presumably would mean that the organisation responsible for > bank.example could run their own CA and publish their own trust anchor, > without having to buy that service from one of the traditional CA > companies. > > No doubt there is more to it than that. I don't know anything much about > X.509. x.509 is not the issue. it is your assumption that dns trust is formally transferrable to ssl/tls cert trust. to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail. and i am not interested in quibbling about banks and who issues root cas. the point is that there are two different trust models here, and trust is not transitive. but then again, i have not even had coffee yet this morning. randy From tmbattles at att.com Mon Jan 5 15:16:33 2009 From: tmbattles at att.com (BATTLES, TIMOTHY A (TIM), ATTLABS) Date: Mon, 5 Jan 2009 16:16:33 -0500 Subject: Ethical DDoS drone network In-Reply-To: Message-ID: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1957@gaalpa1msgusr7a.ugd.att.com> True, real world events differ, but so do denial of service attacks. Distribution in the network, PPS, BPS, Packet Type, Packet Size, etc.. Etc.. Etc.. So really I don't get the point either in staging a real life do it yourself test. So, you put pieces of your network in jeopardy night after night during maintenance windows to determine if what?? Your vulnerable to DDOS? We all know we are, it's just a question of what type and how much right? So we identify our choke points. We all know them. We look at the vendor data on how much PPS it can handle and quickly dismiss that. So what's the next step? Put the device that IS the choke point and pump it full of all different flavors until it fails. No harm no foul an now we have data regarding how much and what takes the device out. If the network is scaled, well we now know that we have x amount of devices that can fail if the DDOS goes X PPS with Y packet types. What I don't get is what you would be doing trying to accomplish this on a production network. Worse case is you break something. Best case is you don't. So if best case scenario is reach, what have you learned? Nothing! So what do you do next ramp it up? Seems silly. -----Original Message----- From: Edward B. DREGER [mailto:eddy+public+spam at noc.everquick.net] Sent: Monday, January 05, 2009 12:03 PM To: nanog at merit.edu Subject: RE: Ethical DDoS drone network TAB> Date: Mon, 5 Jan 2009 11:54:06 -0500 TAB> From: "BATTLES, TIMOTHY A (TIM), ATTLABS" TAB> assuming your somewhat scaled, I would think this could all be done TAB> in the lab. And end up with a network that works in the lab. :-) - bw * delay - effects of flow caching, where applicable - jitter (esp. under load) - packet dups and loss (esp. under load) - packet reordering and assiciated side-effects - upstream/sidestream throughput (esp. under load) No, reality is far more complex. Some things do not lend themselves to _a priori_ models, nor even "TFAR" generalizations. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From beckman at angryox.com Mon Jan 5 15:19:28 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 5 Jan 2009 16:19:28 -0500 Subject: Leap second tonight In-Reply-To: <6F0A37B2-75B8-4E71-A3F3-40DC100B2D7B@multicasttech.com> References: <20090105163051.GB18304@skywalker.creative.net.au> <6F0A37B2-75B8-4E71-A3F3-40DC100B2D7B@multicasttech.com> Message-ID: I've gleened from this thread that: * everyone uses UTC, or should, because UTC is a uniform time scale, except for those leap seconds * UTC is sourced from the frequence of a radio emission from cesium atoms which are extremely constant * UTC can get out of whack with the rotation of the earth around the sun, because our rotation is not uniform, but is calculated rather than measured (well, sort of) * UTC is TAI plus leap seconds. In 1972, when leap seconds were first introduced, UTC was TAI - 10 seconds. UTC is now TAI - 34 seconds. TAI ticks exactly as fast as UTC, ignoring leap second adjustments. * UTC is slower than UT1 by about 1ms per day. * On 12/31/2008 UTC was (-) 591.8ms behind UT1. On 1/1/2008 UTC was 407.1ms ahead of UT1. * Leap seconds are applied to UTC every few years to remain in line with UT1, the time based on the rotation of the earth around the sun. * GMT is used to imply UT1, but sometimes UTC, but really GMT is just massively confusing and you shouldn't use it, either in conversation or in your servers/routers, because nobody is really sure without reading a lot of documentation what GMT means for each manufacturer/OS/software. * When writing code regarding dates and times, know that any year may have 366 days, and any minute may have 61 seconds. * When in doubt, Dr. Daniel Gambis is always right. Beckman On Mon, 5 Jan 2009, Marshall Eubanks wrote: > Having been involved in the leap second business, I can tell you that > Daniel Gambis strictly follows the rules, which are Bulletin C is mailed > every six months, either to announce a time step in UTC or to confirm > that there will be no time step at the next possible date. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From Valdis.Kletnieks at vt.edu Mon Jan 5 15:23:22 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Jan 2009 16:23:22 -0500 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: Your message of "Tue, 06 Jan 2009 06:09:34 +0900." <4962770E.7060000@psg.com> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> <8A9328FD-EEAB-4CCB-A073-0775D71BFB2E@hopcount.ca> <4962770E.7060000@psg.com> Message-ID: <3388.1231190602@turing-police.cc.vt.edu> On Tue, 06 Jan 2009 06:09:34 +0900, Randy Bush said: > to use your example, the contractor who serves dns for www.bank.example > could insert a cert and then fake the web site having (a child of) that > cert. whereas, if the site had its cert a descendant of the ca for all > banks, this attack would fail. All you've done *there* is transfer the trust from the contractor to the company that's the "ca for the bank". Yes, the ca-for-banks.com has a vested interest in making sure none of its employees go rogue and do something naughty - but so does the DNS contractor. One could equally well argue that if a site was using the DNS for certs would be immune to an attack on a CA. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jgreco at ns.sol.net Mon Jan 5 15:32:11 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 5 Jan 2009 15:32:11 -0600 (CST) Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <4962770E.7060000@psg.com> from "Randy Bush" at Jan 06, 2009 06:09:34 AM Message-ID: <200901052132.n05LWBfZ024830@aurora.sol.net> > On 09.01.06 05:59, Joe Abley wrote: > >> perhaps i am a bit slow. but could someone explain to me how trust in > >> dns data transfers to trust in an http partner and other uses to which > >> ssl is put? > > > > If I can get secure answers to "www.bank.example IN CERT?" and > > "www.bank.example IN A?" then perhaps when I connect to > > www.bank.example:443 I can decide to trust the certificate presented by > > the server based on the trust anchor I extracted from the DNS, rather > > than whatever trust anchors were bundled with my browser. > > > > That presumably would mean that the organisation responsible for > > bank.example could run their own CA and publish their own trust anchor, > > without having to buy that service from one of the traditional CA > > companies. > > > > No doubt there is more to it than that. I don't know anything much about > > X.509. > > x.509 is not the issue. it is your assumption that dns trust is > formally transferrable to ssl/tls cert trust. > > to use your example, the contractor who serves dns for www.bank.example > could insert a cert and then fake the web site having (a child of) that > cert. whereas, if the site had its cert a descendant of the ca for all > banks, this attack would fail. > > and i am not interested in quibbling about banks and who issues root > cas. the point is that there are two different trust models here, and > trust is not transitive. Sure it is. At least, sometimes it is. One of the problems I mentioned previously was that there's such an amount of fuss involved in obtaining SSL certs for relatively-low-value uses, and the end result is that many sites self-sign or simply don't bother. In the case where I've hosted a box with $BigHosterInc, and they've got DNS control of my zones, and they've got hands on the physical box(es), it becomes difficult to determine just how to prevent a bad actor at $BigHosterInc from do malicious things. On the flip side, there is very clearly value in differentiating between "a certificate that merely guarantees that the communications between the server and your client is secure" and "not only that, but we certify that you are talking to a FooBank-owned web server." Trust is all relative. I might trust you, Randy Bush, in some particular way. But if a group of gunmen storm your home and force you to reveal some bit of confidential data I've given to you, is my trust misplaced, or is it simply that there are necessarily some limits and risks in sharing with you that confidential data? What is the difference if the information is something that gets someone killed, vs information that merely results in my company's business plans being known to a competitor? With that in mind, there could certainly be great uses for delegating some forms of trust through the DNS chain. Not all, though, not all. Banks are a good example of the circumstance where you'd want separation. > but then again, i have not even had coffee yet this morning. Then have some coffee. ;-) ... 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. From matthew at eeph.com Mon Jan 5 15:39:08 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 05 Jan 2009 13:39:08 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <496271DA.7040708@psg.com> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> Message-ID: <49627DFC.2080705@eeph.com> Randy Bush wrote: > perhaps i am a bit slow. but could someone explain to me how trust in > dns data transfers to trust in an http partner and other uses to which > ssl is put? > > randy > It wouldn't, which is why the original suggestion is a bad idea. They're different issues (finding the actual address of the server you want to talk to vs. authenticating that the server is the server you want to talk to), and the trust doesn't transfer for multiple reasons. Mostly it isn't a good idea because there's a big "too many eggs in one basket" problem here... compromise of the DNS root keys not only would cause address lookups to be as insecure as they are now (which still works much of the time for many people), but inserting fake self-signed certs becomes trivial. This is nearly as bad as the argument I've seen that if we had DNSSEC we wouldn't even need SSL's authentication, because you'd be sure you were talking to the right server (never mind that there's demonstrated examples of just how easy it is to reroute someone else's packets from far away). Of course we could secure the entire routing system as well... Matthew Kaufman From Crist.Clark at globalstar.com Mon Jan 5 16:04:51 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Mon, 05 Jan 2009 14:04:51 -0800 Subject: Leap second tonight In-Reply-To: References: <20090105163051.GB18304@skywalker.creative.net.au> <6F0A37B2-75B8-4E71-A3F3-40DC100B2D7B@multicasttech.com> Message-ID: <4962137F.33E4.0097.0@globalstar.com> >>> On 1/5/2009 at 1:19 PM, Peter Beckman wrote: > I've gleened from this thread that: > > * everyone uses UTC, or should, because UTC is a uniform time scale, > except for those leap seconds Local time is totally appropriate in some circumstances, but it is pretty much always defined as just an offset to UTC. UT1 is important when you are doing astronomical observations or depend on such things. > * UTC is sourced from the frequence of a radio emission from cesium > atoms which are extremely constant There is nothing too special about cesium. It's properties and the properties of the particular transition are convenient from an engineering standpoint. > * UTC can get out of whack with the rotation of the earth around the > sun, because our rotation is not uniform, but is calculated rather > than measured (well, sort of) No its not about years, that's what February 29th is for, it's about days. As the Earth rotates (there's a "rotation" versus "revolution" nomenclature), the sun appears to move around it daily. This is the solar day. At a certain point, at a certain location, the sun is at the highest it will be in the sky for that rotation. This is solar noon. The time between two consecutive noons at any location is not constant mostly due to the Earth's orbit being elliptical and the tilt of the Earth's axis. But for any place on Earth, the mean solar day, the average of the solar day over the year, is the same. If the Earth was a solid sphere rotating at a constant speed, that would be the end of the story. But it's not and for a variety of reasons, the rotation of the Earth changes with time (mostly slows). This causes the mean solar day to get longer. > * UTC is TAI plus leap seconds. In 1972, when leap seconds were first > introduced, UTC was TAI - 10 seconds. UTC is now TAI - 34 seconds. > TAI ticks exactly as fast as UTC, ignoring leap second adjustments. > * UTC is slower than UT1 by about 1ms per day. That's a very tricky sentence. I think that the mean solar day right now is about 86400.002 s long. The mean solar day was actually exactly 86400 s long sometime around 1820. > * On 12/31/2008 UTC was (-) 591.8ms behind UT1. On 1/1/2008 UTC was > 407.1ms ahead of UT1. > * Leap seconds are applied to UTC every few years to remain in line > with UT1, the time based on the rotation of the earth around the sun. A time based on the rotation of the Earth.(period) As mentioned above, it doesn't really have anything directly to do with Earth's location in its orbit. > * GMT is used to imply UT1, but sometimes UTC, but really GMT is just > massively confusing and you shouldn't use it, either in conversation > or in your servers/routers, because nobody is really sure without > reading a lot of documentation what GMT means for each > manufacturer/OS/software. > * When writing code regarding dates and times, know that any year may > have 366 days, and any minute may have 61 seconds. Also remember that an administrator or automated clock recalibration may take you forward or back in time any arbitrary amount. > * When in doubt, Dr. Daniel Gambis is always right. Very, very few should not defer to his judgement on such matters. From michael at rancid.berkeley.edu Mon Jan 5 16:30:11 2009 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 05 Jan 2009 14:30:11 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <496271DA.7040708@psg.com> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> Message-ID: <496289F3.3070006@rancid.berkeley.edu> On 01/05/09 12:47, Randy Bush wrote: > perhaps i am a bit slow. but could someone explain to me how trust in > dns data transfers to trust in an http partner and other uses to which > ssl is put? Because I have to trust the DNS anyway. If the DNS redirects my users to a bad site, they may not notice that they are actually entering their personal information into the perfectly-SSL-secured www.bankofamerca.com. Given the willingness of some CAs (which are trusted by browsers) to give out certs with no verification at all[1], I am not sure there is much to be trusted in the current CA-cartel arrangement, with the exception of EV certs. So banks can continue to use the equivalent of EV certs, and the rest of us who don't need an extra layer of trust can switch to using root certs in the DNS secured via DNSSEC. The trust hierarchy is already there. I agree that there are two different trust models, one of which I am required to trust and the other of which I don't trust at all. michael [1]http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ From jasonuhl at jasonuhl.org Mon Jan 5 16:41:29 2009 From: jasonuhl at jasonuhl.org (Jason Uhlenkott) Date: Mon, 5 Jan 2009 14:41:29 -0800 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <4962770E.7060000@psg.com> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> <8A9328FD-EEAB-4CCB-A073-0775D71BFB2E@hopcount.ca> <4962770E.7060000@psg.com> Message-ID: <20090105224129.GA15001@ferrum.uhlenkott.net> On Tue, Jan 06, 2009 at 06:09:34 +0900, Randy Bush wrote: > to use your example, the contractor who serves dns for www.bank.example > could insert a cert and then fake the web site having (a child of) that > cert. whereas, if the site had its cert a descendant of the ca for all > banks, this attack would fail. To be pedantic, it'd have to be the contractor who holds the signing key for the bank.example zone (which may be a separate entity from whoever has operational control of the nameservers). You're correct that this proposal treats control of a DNS zone as a strong proof of identity, but I'd argue that that's the case already -- whoever controls the zone can easily get a CA to issue them a cert which is valid for the host "www.bank.example". Whether the organization name is "Example Bancorp" or "DomainSquatters'R'Us, Inc." is irrelevant, since nobody ever looks at that. I'd go so far as to argue that the hostname is the proper *definition* of identity in this context. The client identifies the destination it wishes to connect to by hostname, not by organization name. The purpose of the cert ought to be to ensure that we're talking to the host identified by that hostname (according to a necessarily trusted DNS). Ensuring that the hostname belongs to someone the user really wants to speak to is an orthogonal problem which is impossible to solve without a clueful user in the loop, and at which the current model is failing miserably. From Mark_Andrews at isc.org Mon Jan 5 16:43:51 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue, 06 Jan 2009 09:43:51 +1100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: Your message of "Mon, 05 Jan 2009 12:18:59 -0800." <20090105201859.GC15107@ferrum.uhlenkott.net> Message-ID: <200901052243.n05Mhpj4063891@drugs.dv.isc.org> In message <20090105201859.GC15107 at ferrum.uhlenkott.net>, Jason Uhlenkott write s: > On Fri, Jan 02, 2009 at 15:33:05 -0600, Joe Greco wrote: > > This would seem to point out some critical shortcomings in the current SSL > > system; these shortcomings are not necessarily technological, but rather > > social/psychological. We need the ability for Tom, Dick, or Harry to be > > able to crank out a SSL cert with a minimum of fuss or cost; having to > > learn the complexities of SSL is itself a "fuss" which has significantly > > and negatively impacted Internet security. > > > > Somehow, we managed to figure out how to do this with PGP and keysigning, > > but it all fell apart (I can hear the "it doesn't scale" already) with SSL. > > If we had DNSSEC, we could do away with SSL CAs entirely. The owner > of each domain or host could publish a self-signed cert in a TXT RR, > and the DNS chain of trust would be the only form of validation needed. Or one could use the CERT to publish a cert :-) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jbates at brightok.net Mon Jan 5 16:52:42 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 05 Jan 2009 16:52:42 -0600 Subject: Ethical DDoS drone network In-Reply-To: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1957@gaalpa1msgusr7a.ugd.att.com> References: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1957@gaalpa1msgusr7a.ugd.att.com> Message-ID: <49628F3A.10103@brightok.net> BATTLES, TIMOTHY A (TIM), ATTLABS wrote: > True, real world events differ, but so do denial of service attacks. > Distribution in the network, PPS, BPS, Packet Type, Packet Size, etc.. > Etc.. Etc.. So really I don't get the point either in staging a real > life do it yourself test. So, you put pieces of your network in > jeopardy night after night during maintenance windows to determine if > what?? Your vulnerable to DDOS? We all know we are, it's just a question > of what type and how much right? So we identify our choke points. We all > packet types. What I don't get is what you would be doing trying to > accomplish this on a production network. Worse case is you break > something. Best case is you don't. So if best case scenario is reach, > what have you learned? Nothing! So what do you do next ramp it up? Seems > silly. I'll personally agree with you, though there are fringe cases. For example, one or more of your peers might falter before you do. While I'm sure they won't enjoy you hurting their other customers, knowing that your peer's router is going to crater before your expensive piece of hardware is usually good knowledge. Since it's controlled, you can minimize the damage of testing that fact. Another test is automatic measures and how well they perform. This may or may not be useful in a closed environment, though in a closed environment, they'll definitely need to mirror the production environment depending on what criteria they use for automatic measures. A non-forging botnet which sends packets (valid or malformed) to an accepting recipient is strictly another internet app, and has a harm ratio related to some p2p apps. IP forging, of course, could cause unintended blowback, which could have severe legal ramifications. That being said, I'd quit calling it a botnet. I'd call it a distributed application that stress tests DDoS protection measures, and it's advisable to let your direct peers know when you plan to run it. They might even be interested in monitoring their equipment (or tell you up front that you'll crater their equipment). Jack From nick at foobar.org Mon Jan 5 16:57:38 2009 From: nick at foobar.org (Nick Hilliard) Date: Mon, 05 Jan 2009 22:57:38 +0000 Subject: Leap second tonight In-Reply-To: References: <20090105163051.GB18304@skywalker.creative.net.au> <6F0A37B2-75B8-4E71-A3F3-40DC100B2D7B@multicasttech.com> Message-ID: <49629062.2050800@foobar.org> Peter Beckman wrote: > * GMT is used to imply UT1, but sometimes UTC, but really GMT is just > massively confusing and you shouldn't use it, either in conversation > or in your servers/routers, because nobody is really sure without > reading a lot of documentation what GMT means for each > manufacturer/OS/software. WET/WEST is a little more precise and less confusing than GMT/BST (or IST if you're of a more celtic nature, although this confuses people living on the Indian subcontinent) although in tz-land, GMT has a specific and pretty consistent definition. But it is generally a bad idea to use it. People get confused. > * When writing code regarding dates and times, know that any year may > have 366 days, and any minute may have 61 seconds. Or 59 seconds in the case of a negative leap second. Nick From thegameiam at yahoo.com Mon Jan 5 17:23:39 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 5 Jan 2009 15:23:39 -0800 (PST) Subject: Ethical DDoS drone network In-Reply-To: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1957@gaalpa1msgusr7a.ugd.att.com> Message-ID: <323710.85230.qm@web31813.mail.mud.yahoo.com> In my opinion, the real thing you can puzzle out of this kind of testing is the occasional hidden dependency. I've seen ultra-robust servers fail because a performance monitoring application living on them was timing out in a remote query, and I've also seen devices fail well below their expected load because they were using multiple layers of encapsulation (IP over MPLS over IP over Ethernet over MPLS over Frame-Relay ...) and one of the hidden middle-layers was badly optimized. The advantage of performing this DDoS-style load testing on yourself is that *you can turn it off once you experience the failure* and then go figure out why it broke when it did. This is a lot more pleasant than trying to figure it out at 2:30 in the morning with insufficient coffee. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Mon, 1/5/09, BATTLES, TIMOTHY A (TIM), ATTLABS wrote: > From: BATTLES, TIMOTHY A (TIM), ATTLABS > Subject: RE: Ethical DDoS drone network > To: "Edward B. DREGER" , nanog at merit.edu > Date: Monday, January 5, 2009, 4:16 PM > True, real world events differ, but so do denial of service > attacks. > Distribution in the network, PPS, BPS, Packet Type, Packet > Size, etc.. > Etc.. Etc.. So really I don't get the point either in > staging a real > life do it yourself test. So, you put pieces of your > network in > jeopardy night after night during maintenance windows to > determine if > what?? Your vulnerable to DDOS? We all know we are, > it's just a question > of what type and how much right? So we identify our choke > points. We all > know them. We look at the vendor data on how much PPS it > can handle and > quickly dismiss that. So what's the next step? Put the > device that IS > the choke point and pump it full of all different flavors > until it > fails. No harm no foul an now we have data regarding how > much and what > takes the device out. If the network is scaled, well we now > know that we > have x amount of devices that can fail if the DDOS goes X > PPS with Y > packet types. What I don't get is what you would be > doing trying to > accomplish this on a production network. Worse case is you > break > something. Best case is you don't. So if best case > scenario is reach, > what have you learned? Nothing! So what do you do next ramp > it up? Seems > silly. > > > > -----Original Message----- > From: Edward B. DREGER > [mailto:eddy+public+spam at noc.everquick.net] > Sent: Monday, January 05, 2009 12:03 PM > To: nanog at merit.edu > Subject: RE: Ethical DDoS drone network > > TAB> Date: Mon, 5 Jan 2009 11:54:06 -0500 > TAB> From: "BATTLES, TIMOTHY A (TIM), ATTLABS" > > TAB> assuming your somewhat scaled, I would think this > could all be done > TAB> in the lab. > > And end up with a network that works in the lab. :-) > > - bw * delay > - effects of flow caching, where applicable > - jitter (esp. under load) > - packet dups and loss (esp. under load) > - packet reordering and assiciated side-effects > - upstream/sidestream throughput (esp. under load) > > No, reality is far more complex. Some things do not lend > themselves to > _a priori_ models, nor even "TFAR" > generalizations. > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - > http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network > building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- > sam at everquick.net > Sending mail to spambait addresses is a great way to get > blocked. > Ditto for broken OOO autoresponders and foolish AV software > backscatter. From rdobbins at cisco.com Mon Jan 5 17:37:55 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 6 Jan 2009 07:37:55 +0800 Subject: Ethical DDoS drone network In-Reply-To: <49628F3A.10103@brightok.net> References: <3AAAFB6D2C54CE4BAA71200C10F4EBB4CF1957@gaalpa1msgusr7a.ugd.att.com> <49628F3A.10103@brightok.net> Message-ID: On Jan 6, 2009, at 6:52 AM, Jack Bates wrote: > (or tell you up front that you'll crater their equipment). This is the AUP danger to which I was referring earlier. Also, note that the miscreants will attack intermediate systems such as routers they identify via tracerouting from multiple points to the victim - there's no way to test that externally without violating AUPs and/or various criminal statutes in multiple jurisdictions. And then there are managed-CPE and hosting scenarios, which complicate matters further. Tim's comments about understanding the performance envelopes of all the system/infrastructure elements are spot-on - that's a primary input into design criteria (or should be). With this knowledge in hand, one can test the most important things internally. But prior to testing, one should ensure that the architecture and the element configurations are hardened with all the relevant BCPs, and scaled for capacity. The main purpose of the testing would be to verify correct implementation and ensure all the failure modes have been accounted for and ameliorated to the degree possible, and also as an opsec drill. What I've seen over and over again is a desire to test because it's 'cool', but no desire to spend the time in the design and implementation (or re-implementation) phases to ensure that things are hardened in the first place, nor to spell out security policies and procedures, train, etc. Actual *security* (as opposed to checklisting) consists of attention to lots of tedious details, drudgery and scut-work, involving the coordination of multiple groups and the attendant politics. It isn't 'sexy', it isn't 'cool', it isn't 'fun', but it pays off at 4AM on a holiday weekend. Testing should become a priority only after one has done everything one knows to do within one's span of control, IMHO - and I've yet to run across this happy circumstance in any organization who've asked me about this kind testing, FWIW. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From rdobbins at cisco.com Mon Jan 5 17:39:54 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 6 Jan 2009 07:39:54 +0800 Subject: Ethical DDoS drone network In-Reply-To: <323710.85230.qm@web31813.mail.mud.yahoo.com> References: <323710.85230.qm@web31813.mail.mud.yahoo.com> Message-ID: <96E3F2A8-25D9-4399-8DC4-05DBA2ED6FB1@cisco.com> On Jan 6, 2009, at 7:23 AM, David Barak wrote: > In my opinion, the real thing you can puzzle out of this kind of > testing is the occasional hidden dependency. Yes - but if your lab accurately reflects production, you can discover this kind of thing in the lab (and one ought to already have a lab setup which reflects production for many reasons having nothing to do with security). ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From mtinka at globaltransit.net Mon Jan 5 17:45:28 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 6 Jan 2009 07:45:28 +0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <496246BD.6090308@justinshore.com> References: <20081227043742.008B44500F@ptavv.es.net> <496246BD.6090308@justinshore.com> Message-ID: <200901060745.33996.mtinka@globaltransit.net> On Tuesday 06 January 2009 01:43:25 am Justin Shore wrote: > I never could get > IS-IS to work with multiple areas. The 7600s made a > smelly mess on the CO floor every time I tried. In the > end I went with a L2-only IS-IS network. How so? Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mailvortex at gmail.com Mon Jan 5 17:59:49 2009 From: mailvortex at gmail.com (Ben Scott) Date: Mon, 5 Jan 2009 18:59:49 -0500 Subject: Leap second tonight In-Reply-To: References: <20090105163051.GB18304@skywalker.creative.net.au> <6F0A37B2-75B8-4E71-A3F3-40DC100B2D7B@multicasttech.com> Message-ID: <59f980d60901051559o6cb2a3b6o5064761aaf5ec5c7@mail.gmail.com> On Mon, Jan 5, 2009 at 4:19 PM, Peter Beckman wrote: > * UTC can get out of whack with the rotation of the earth around the > sun, because our rotation is not uniform, but is calculated rather > than measured (well, sort of) As Crist Clark points out, leap seconds are about the Earth's rotation about its own axis, not its revolution (orbit) around the sun. Atomic clocks are much more consistent and uniform than the Earth's rotation. If we don't correct for the differences somehow, eventually wall clock time would get out of sync with the day/night cycle. In $LARGE_NUMBER years, 1:00 PM would be in the middle of the night. Earth's orbit and the Julian calendar have the same problem, which is why we have leap days. Otherwise, the calendar would get out of sync with the seasons. > * When writing code regarding dates and times, know that any year may > have 366 days, and any minute may have 61 seconds. I wouldn't even define it that narrowly. We might end up with 62 or 63 or 57 seconds in a minute, or 364 or 367 days in a year. Internally, store everything using a fixed-unit offset (e.g., traditional Unix time, i.e., seconds from 1 Jan 1970). Use OS provided facilities to translate to and from human-friendly representations, and thus make it the OS's problem. (If the OS is your problem... sucks to be you. You'll need lots of tables of historic, idiosyncratic clock/calendar changes to get it right.) For program timers (timeouts, etc.), don't use wall clock time at all, since the wall clock may be wrong, and the admin may fix it, yielding time travel. Most OSes provide something like a "seconds since boot" value, which should always monotonically increase (unless you're running Windows 95, heh), regardless of what the admin is doing to confuse matters. From the other side of the coin: As an admin, avoid advancing the wall clock in large steps, or going backwards at all. If you must do either, do it in single-user mode, or whatever your platform's equivalent is. Don't assume the programmers got it right. Another programmer tip: When storing dates and times in a file, database, etc., and you have to care about multiple timezones: Store at least three of UTC, local time, calculated difference, logical local timezone. The extra information lets one figure out after-the-fact what the timezone tables on the system said when the user entered the information. When the gov'mint monkeys with the time zones, there's always a lag between official announcement and local implementation. Without knowing what the time zone tables said, it can be hard to know if you should apply a correction later. -- Ben From thegameiam at yahoo.com Mon Jan 5 18:01:36 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 5 Jan 2009 16:01:36 -0800 (PST) Subject: Ethical DDoS drone network In-Reply-To: <96E3F2A8-25D9-4399-8DC4-05DBA2ED6FB1@cisco.com> Message-ID: <557715.13157.qm@web31805.mail.mud.yahoo.com> -- On Mon, 1/5/09, Roland Dobbins wrote: > From: Roland Dobbins > Subject: Re: Ethical DDoS drone network > To: "NANOG list" > Date: Monday, January 5, 2009, 6:39 PM > On Jan 6, 2009, at 7:23 AM, David Barak wrote: > > > In my opinion, the real thing you can puzzle out of > this kind of testing is the occasional hidden dependency. > > Yes - but if your lab accurately reflects production, you > can discover this kind of thing in the lab (and one ought to > already have a lab setup which reflects production for many > reasons having nothing to do with security). I agree - having a lab of that type is absolutely ideal. However, the ideal and the real diverge tremendously in large and mid-size enterprise networks, because most enterprises just don't have enough lab equipment to adequately model all of the possible scenarios, and including the cost of a lab in the rollout immediately doubles all capital expenditures. The types of problems that the ultra-large DoS can ferret out are the kind which *don't* show up in anything smaller than a 1:1 or 1:2 scale model. Consider for a moment a large retail chain, with several hundred or a couple thousand locations. How big a lab should they have before deciding to roll out a new network something-or-other? Should their lab be 1:10 scale? A more realistic figure is that they'll consider themselves lucky to be between 1:50 and 1:100, and that lab is probably understaffed at best. Having a dedicated lab manager is often seen as an expensive luxury, and many businesses don't have the margin to support it. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From kch670 at eecs.northwestern.edu Mon Jan 5 18:05:48 2009 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Mon, 5 Jan 2009 18:05:48 -0600 Subject: question about BGP default routing Message-ID: Hi all I have a question: I see very few prefixes in a routing table and combining the prefixes does not cover addresses space, for example, {78.41.184.0/21, 91.103.239.0/24, 91.103.232.0/22, 82.138.64.0/23, 91.103.232.0/21, 77.95.71.0/24} are all prefixes I observed from a BGP speaking router, I am just asking is this router using a default routing for all the other destinations? Thanks a lot From jasper at unleash.co.nz Mon Jan 5 18:08:40 2009 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Tue, 6 Jan 2009 13:08:40 +1300 Subject: question about BGP default routing In-Reply-To: References: Message-ID: If it has a default route, 0.0.0.0/0, in its routing table, then yes, it is. If it does not, then no, it is not. -jasper On 6/01/2009, at 1:05 PM, Kai Chen wrote: > Hi all I have a question: > > I see very few prefixes in a routing table and combining the prefixes > does not cover addresses space, for example, {78.41.184.0/21, > 91.103.239.0/24, 91.103.232.0/22, 82.138.64.0/23, 91.103.232.0/21, > 77.95.71.0/24} are all prefixes I observed from a BGP speaking router, > I am just asking is this router using a default routing for all the > other destinations? > > Thanks a lot > -- Jasper Bryant-Greene Network Engineer, Unleash ddi: +64 3 978 1222 mob: +64 21 129 9458 From rdobbins at cisco.com Mon Jan 5 18:11:19 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 6 Jan 2009 08:11:19 +0800 Subject: Ethical DDoS drone network In-Reply-To: <557715.13157.qm@web31805.mail.mud.yahoo.com> References: <557715.13157.qm@web31805.mail.mud.yahoo.com> Message-ID: On Jan 6, 2009, at 8:01 AM, David Barak wrote: > The types of problems that the ultra-large DoS can ferret out are > the kind which *don't* show up in anything smaller than a 1:1 or 1:2 > scale model. In my experience, once one has an understanding of the performance envelopes and has built a lab which contains examples of the functional elements of the system (network infrastructure, servers, apps, databases, clients, et. al.), one can extrapolate pretty accurately well out to orders of magnitude. The problem is that many organizations don't do the above prior to freezing the design and initiating deployment. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From jbates at brightok.net Mon Jan 5 18:45:40 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 05 Jan 2009 18:45:40 -0600 Subject: Ethical DDoS drone network In-Reply-To: References: <557715.13157.qm@web31805.mail.mud.yahoo.com> Message-ID: <4962A9B4.6040305@brightok.net> Roland Dobbins wrote: > In my experience, once one has an understanding of the performance > envelopes and has built a lab which contains examples of the functional > elements of the system (network infrastructure, servers, apps, > databases, clients, et. al.), one can extrapolate pretty accurately well > out to orders of magnitude. > > The problem is that many organizations don't do the above prior to > freezing the design and initiating deployment. > Sadly, I think money and time have a lot to do with this. Technology is a moving target, and everyone is constantly struggling to keep up while maintaining performance/security. I've seen this out of software developers, too. I'd say I've seen more outages due to a simple command typed into a router cli crashing the router than DDoS traffic. Perhaps I've been lucky with the latter. Jack From ops.lists at gmail.com Mon Jan 5 18:55:16 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 6 Jan 2009 06:25:16 +0530 Subject: Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network Message-ID: On Mon, Jan 5, 2009 at 10:24 PM, BATTLES, TIMOTHY A (TIM), ATTLABS wrote: > There are some assumptions here. First are you considering volumetric > DDOS attacks? Second, if you plan on harvesting wild bots and using them > to serve your purpose then I don't see how this can be ethical unless > they are just clients from your own network making it less distributed. I cant believe this .. http://www.iprental.com Looks like anonymizer combined with what looks almost like a "rent a botnet", legit nodes (you sign up to download a client that makes you part of this botnet, etc) http://www.iprental.com/technical/ Speaking of a "commercial botnet"", there was something similar earlier - but that was a "download this bulk mailer" type operation, guys called Atriks, who got tracked so extensively by spamhaus that they seem to have kind of disappeared now. --srs From rdobbins at cisco.com Mon Jan 5 18:57:10 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 6 Jan 2009 08:57:10 +0800 Subject: Ethical DDoS drone network In-Reply-To: <4962A9B4.6040305@brightok.net> References: <557715.13157.qm@web31805.mail.mud.yahoo.com> <4962A9B4.6040305@brightok.net> Message-ID: <154F67DC-1CA1-4FBD-8A31-9093CDE948B8@cisco.com> On Jan 6, 2009, at 8:45 AM, Jack Bates wrote: > Sadly, I think money and time have a lot to do with this. Even more than this, it's a skillset and mindset issue. Many organizations don't know enough about how the underlying technologies work to understand that they need to incorporate these costs and allocate these resources as part of the project spend, nor do they think to ask around (or even use the Search Engine of Their Choice) to find out about the 'unknown unknowns'. To mount a successful defense, one must learn to think like an attacker. This seems to be a relatively rare attitude, unfortunately. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From smb at cs.columbia.edu Mon Jan 5 19:54:52 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 5 Jan 2009 20:54:52 -0500 Subject: generic attack on Cisco routers Message-ID: <20090105205452.21170083@cs.columbia.edu> http://www.theregister.co.uk/2009/01/05/cisco_router_hijacking/ --Steve Bellovin, http://www.cs.columbia.edu/~smb From eddy+public+spam at noc.everquick.net Mon Jan 5 20:49:24 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Tue, 6 Jan 2009 02:49:24 +0000 (GMT) Subject: question about BGP default routing In-Reply-To: References: Message-ID: KC> Date: Mon, 5 Jan 2009 18:05:48 -0600 KC> From: Kai Chen KC> is this router using a default routing for all the other KC> destinations? Either that: router> sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet or partial tables with no default: router> sh ip route 0.0.0.0 % Network not in table is what you'd expect. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From kch670 at eecs.northwestern.edu Mon Jan 5 21:52:12 2009 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Mon, 5 Jan 2009 21:52:12 -0600 Subject: question about BGP default routing In-Reply-To: References: Message-ID: Will this default route 0.0.0.0/0 be exporting to AS-level neighbors? On Mon, Jan 5, 2009 at 8:49 PM, Edward B. DREGER wrote: > KC> Date: Mon, 5 Jan 2009 18:05:48 -0600 > KC> From: Kai Chen > > KC> is this router using a default routing for all the other > KC> destinations? > > Either that: > > router> sh ip route 0.0.0.0 > Routing entry for 0.0.0.0/0, supernet > > or partial tables with no default: > > router> sh ip route 0.0.0.0 > % Network not in table > > is what you'd expect. > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > From karnaugh at karnaugh.za.net Mon Jan 5 22:39:50 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 06 Jan 2009 06:39:50 +0200 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: <496271DA.7040708@psg.com> References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> <496271DA.7040708@psg.com> Message-ID: <4962E096.7070409@karnaugh.za.net> On 2009/01/05 10:47 PM Randy Bush wrote: > perhaps i am a bit slow. but could someone explain to me how trust in > dns data transfers to trust in an http partner and other uses to which > ssl is put? I must also be slow. Can someone tell me how DNSSEC is supposed to encrypt my TCP/IP traffic? From martin at theicelandguy.com Mon Jan 5 22:54:33 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 5 Jan 2009 23:54:33 -0500 Subject: Northern Ireland undersea branch to be implemented Message-ID: Hibernia has been busy. "THE COMMUNICATIONS minister Eamon Ryan and the North's Enterprise Minister Arlene Foster have announced the awarding of a ?30 million (?32 million) contract to construct a new direct telecommunications link to North America that will benefit Northern Ireland and the Republic" http://www.irishtimes.com/newspaper/finance/2009/0106/1230936699678.html -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From jeffrey.lyon at blacklotus.net Mon Jan 5 23:24:18 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 6 Jan 2009 00:24:18 -0500 Subject: Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network In-Reply-To: References: Message-ID: <16720fe00901052124x5b8b6ddfxdab09322367db7fe@mail.gmail.com> This is new to you? Polymorphic anonymizers have been a way of life for a while now. Jeff On Mon, Jan 5, 2009 at 7:55 PM, Suresh Ramasubramanian wrote: > On Mon, Jan 5, 2009 at 10:24 PM, BATTLES, TIMOTHY A (TIM), ATTLABS > wrote: >> There are some assumptions here. First are you considering volumetric >> DDOS attacks? Second, if you plan on harvesting wild bots and using them >> to serve your purpose then I don't see how this can be ethical unless >> they are just clients from your own network making it less distributed. > > I cant believe this .. http://www.iprental.com > > Looks like anonymizer combined with what looks almost like a "rent a > botnet", legit nodes (you sign up to download a client that makes you > part of this botnet, etc) > > http://www.iprental.com/technical/ > > Speaking of a "commercial botnet"", there was something similar > earlier - but that was a "download this bulk mailer" type operation, > guys called Atriks, who got tracked so extensively by spamhaus that > they seem to have kind of disappeared now. > > --srs > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From pauldotwall at gmail.com Mon Jan 5 23:27:06 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 6 Jan 2009 00:27:06 -0500 Subject: Hirschmann Switches? Message-ID: <620fd17c0901052127g65320096u5ac40da39b9716e7@mail.gmail.com> I'm looking for feedback from users of the Hirschmann (Belden) ethernet switches in a service provider environment. Private or public appreciated. Drive Slow, Paul Wall From ops.lists at gmail.com Mon Jan 5 23:29:17 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 6 Jan 2009 10:59:17 +0530 Subject: Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network In-Reply-To: <16720fe00901052124x5b8b6ddfxdab09322367db7fe@mail.gmail.com> References: <16720fe00901052124x5b8b6ddfxdab09322367db7fe@mail.gmail.com> Message-ID: On Tue, Jan 6, 2009 at 10:54 AM, Jeffrey Lyon wrote: > This is new to you? Polymorphic anonymizers have been a way of life > for a while now. > > Jeff I just thought I'd cite an example. These have been around for a while, as you say. -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Mon Jan 5 23:30:42 2009 From: randy at psg.com (Randy Bush) Date: Tue, 06 Jan 2009 14:30:42 +0900 Subject: Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network In-Reply-To: References: Message-ID: <4962EC82.9050408@psg.com> > I cant believe this .. http://www.iprental.com sheesh! and i thought the rirs had a monopoly on ip address rental. :) randy From vixie at isc.org Mon Jan 5 23:32:36 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 06 Jan 2009 05:32:36 +0000 Subject: DNSSEC vs. X509 (Re: Security team successfully cracks SSL...) In-Reply-To: <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> (Joe Abley's message of "Mon\, 5 Jan 2009 15\:39\:37 -0500") References: <557D3E2B-FE59-49DF-B54E-D6E810F8B94F@hopcount.ca> <200901022133.n02LX5G5057940@aurora.sol.net> <20090105201859.GC15107@ferrum.uhlenkott.net> <443E4CB9-B788-4D59-9139-1F44324EFA0C@hopcount.ca> Message-ID: Joe Abley writes: > On 2009-01-05, at 15:18, Jason Uhlenkott wrote: > >> If we had DNSSEC, we could do away with SSL CAs entirely. The owner >> of each domain or host could publish a self-signed cert in a TXT RR, > > ... or even in a CERT RR, as I heard various clever people talking about > in some virtual hallway the other day. > . i wasn't clever but i was in that hallway. it's more complicated than RFC 2538, but there does seem to be a way forward involving SSL/TLS (to get channel encryption) but where a self-signed key could be verified using a CERT RR (to get endpoint identity authentication). the attacks recently have been against MD5 (used by some X.509 CA's) and against an X.509 CA's identity verification methods (used at certificate granting time). no recent attack has shaken my confidence in SSL/TLS negotiation or encryption, but frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down. i don't have a specific proposal. (yet.) but i'm investigating, and i recommend others do likewise. -- Paul Vixie From martin at airwire.ie Tue Jan 6 00:02:52 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 06 Jan 2009 06:02:52 +0000 Subject: Northern Ireland undersea branch to be implemented In-Reply-To: References: Message-ID: <4962F40C.6050603@airwire.ie> Martin Hannigan wrote: > Hibernia has been busy. > > "THE COMMUNICATIONS minister Eamon Ryan and the North's Enterprise Minister > Arlene Foster have announced the awarding of a ?30 million (?32 million) > contract to construct a new direct telecommunications link to North America > that will benefit Northern Ireland and the Republic" > > http://www.irishtimes.com/newspaper/finance/2009/0106/1230936699678.html > That's just a spur from the existing Hibernia Atlantic fibre that goes from Halifax to Dublin. In my opinion, that should have been done from the very beginning. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From Mark_Andrews at isc.org Tue Jan 6 00:10:47 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Tue, 06 Jan 2009 17:10:47 +1100 Subject: Security team successfully cracks SSL using 200 PS3's and MD5 In-Reply-To: Your message of "Tue, 06 Jan 2009 06:39:50 +0200." <4962E096.7070409@karnaugh.za.net> Message-ID: <200901060610.n066AlZt066935@drugs.dv.isc.org> In message <4962E096.7070409 at karnaugh.za.net>, Colin Alston writes: > On 2009/01/05 10:47 PM Randy Bush wrote: > > perhaps i am a bit slow. but could someone explain to me how trust in > > dns data transfers to trust in an http partner and other uses to which > > ssl is put? > > I must also be slow. Can someone tell me how DNSSEC is supposed to > encrypt my TCP/IP traffic? DNSSEC allows you to go from dns name -> CERT in a secure manner. The application then checks that the cert used to establish the ssl session is one from the CERT RRset. Basically when you pay your $70 or whatever for the CERT record you are asking the CA to assert that you have the right to use the domain name. It's expensive because they are not part of existing DNS trust relationship setup when the domain was delegated in the first place. The natural place to look for DNS trust is in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From tvhawaii at shaka.com Tue Jan 6 01:22:27 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 5 Jan 2009 21:22:27 -1000 Subject: Where there's a nanog thread there'll be a vendor solution ..Re: Ethical DDoS drone network References: <4962EC82.9050408@psg.com> Message-ID: <416CDB799EDE4B089341382EA14AB8E9@DELL16> ----- Original Message ----- From: "Randy Bush" Sent: Monday, January 05, 2009 7:30 PM Subject: Re: Where there's a nanog thread there'll be a vendor solution ..Re: Ethical DDoS drone network >> I cant believe this .. http://www.iprental.com > > sheesh! and i thought the rirs had a monopoly on ip address rental. :) > > randy > I watched the 'Demo Video' and the addresses shown were from AT&T and Comcast space. Any idea of what space they might be from in real life or is that part of their secret sauce? Thanks, --Michael From ops.lists at gmail.com Tue Jan 6 01:26:42 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 6 Jan 2009 12:56:42 +0530 Subject: Where there's a nanog thread there'll be a vendor solution ..Re: Ethical DDoS drone network In-Reply-To: <416CDB799EDE4B089341382EA14AB8E9@DELL16> References: <4962EC82.9050408@psg.com> <416CDB799EDE4B089341382EA14AB8E9@DELL16> Message-ID: On Tue, Jan 6, 2009 at 12:52 PM, Michael Painter wrote: > > I watched the 'Demo Video' and the addresses shown were from AT&T and > Comcast space. Any idea of what space they might be from in real life or > is that part of their secret sauce? > J.Random ADSL / cable space I dare say. Though what said cable / adsl SPs would have to say about "reselling of service is an AUP violation" is anybody's guess :) --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From martin at theicelandguy.com Tue Jan 6 05:20:05 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 6 Jan 2009 06:20:05 -0500 Subject: Northern Ireland undersea branch to be implemented In-Reply-To: <4962F40C.6050603@airwire.ie> References: <4962F40C.6050603@airwire.ie> Message-ID: On Tue, Jan 6, 2009 at 1:02 AM, Martin List-Petersen wrote: > Martin Hannigan wrote: > > Hibernia has been busy. > > > > "THE COMMUNICATIONS minister Eamon Ryan and the North's Enterprise > Minister > > Arlene Foster have announced the awarding of a ?30 million (?32 million) > > contract to construct a new direct telecommunications link to North > America > > that will benefit Northern Ireland and the Republic" > > > > http://www.irishtimes.com/newspaper/finance/2009/0106/1230936699678.html > > > > That's just a spur from the existing Hibernia Atlantic fibre that goes > from Halifax to Dublin. In my opinion, that should have been done from > the very beginning. > > Is all of this terrestrial network already in place? http://www.hiberniaatlantic.com/maps/HA_NIreland_Routes.pdf -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From pzhao.cn at gmail.com Tue Jan 6 05:26:02 2009 From: pzhao.cn at gmail.com (Zhao Ping) Date: Tue, 06 Jan 2009 19:26:02 +0800 Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets Message-ID: <49633FCA.8090606@gmail.com> Hi, Does someone happen to know how the Cisco IOS handle the out-of-order ICMP echo-reply packets? print it as success or lose? Thanks, Zhao Ping From Rod.Beck at hiberniaatlantic.com Tue Jan 6 05:32:31 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Tue, 6 Jan 2009 11:32:31 -0000 Subject: [SPAM-HEADER] - Re: Northern Ireland undersea branch to be implemented - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <4962F40C.6050603@airwire.ie> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB9F6880@bert.HiberniaAtlantic.local> Actually, it is a big deal. Hibernia is already the only cable system that can send Irish traffic directly to North American without backhauling to the UK. That's a significantly latency and diversity advantage. We can now send traffic directly to the US on both cables without UK backhaul and hence provide more physical diversity. It also enables us to serve an underserved market, Northern Ireland, and provide low latency and protected services betweeen the UK and Ireland. And we beat the who-whos of telecom in winning this RFP. :) Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Martin Hannigan [mailto:martin at theicelandguy.com] Sent: Tue 1/6/2009 11:20 AM To: Martin List-Petersen Cc: nanog at nanog.org Subject: [SPAM-HEADER] - Re: Northern Ireland undersea branch to be implemented - Email has different SMTP TO: and MIME TO: fields in the email addresses On Tue, Jan 6, 2009 at 1:02 AM, Martin List-Petersen wrote: > Martin Hannigan wrote: > > Hibernia has been busy. > > > > "THE COMMUNICATIONS minister Eamon Ryan and the North's Enterprise > Minister > > Arlene Foster have announced the awarding of a ?30 million (?32 million) > > contract to construct a new direct telecommunications link to North > America > > that will benefit Northern Ireland and the Republic" > > > > http://www.irishtimes.com/newspaper/finance/2009/0106/1230936699678.html > > > > That's just a spur from the existing Hibernia Atlantic fibre that goes > from Halifax to Dublin. In my opinion, that should have been done from > the very beginning. > > Is all of this terrestrial network already in place? http://www.hiberniaatlantic.com/maps/HA_NIreland_Routes.pdf -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From tom at snnap.net Tue Jan 6 06:39:50 2009 From: tom at snnap.net (Tom Storey) Date: Tue, 6 Jan 2009 23:09:50 +1030 Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets In-Reply-To: <49633FCA.8090606@gmail.com> References: <49633FCA.8090606@gmail.com> Message-ID: <5815D7DA-988C-4432-A57E-BB4983DCB215@snnap.net> Considering that Ciscos wait for a response before sending the next echo-request, you should never end up in a situation where replys are received out of order. That is going by my knowledge of traditional IOS. Ive not yet had any experience with IOS XE or XR to be able to quote any other experience. Tom On 06/01/2009, at 9:56 PM, Zhao Ping wrote: > Hi, > > Does someone happen to know how the Cisco IOS handle the out-of- > order ICMP echo-reply packets? print it as success or lose? > > Thanks, > > Zhao Ping > > > From chloekcy2000 at yahoo.ca Tue Jan 6 06:40:16 2009 From: chloekcy2000 at yahoo.ca (chloe K) Date: Tue, 6 Jan 2009 07:40:16 -0500 (EST) Subject: question about BGP default routing In-Reply-To: Message-ID: <722214.74526.qm@web57414.mail.re1.yahoo.com> Sorry I have question Why it needs default routes when running BGP? Thank you Kai Chen wrote: Will this default route 0.0.0.0/0 be exporting to AS-level neighbors? On Mon, Jan 5, 2009 at 8:49 PM, Edward B. DREGER wrote: > KC> Date: Mon, 5 Jan 2009 18:05:48 -0600 > KC> From: Kai Chen > > KC> is this router using a default routing for all the other > KC> destinations? > > Either that: > > router> sh ip route 0.0.0.0 > Routing entry for 0.0.0.0/0, supernet > > or partial tables with no default: > > router> sh ip route 0.0.0.0 > % Network not in table > > is what you'd expect. > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > ________________________________________________________________________ > DO NOT send mail to the following addresses: > davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > --------------------------------- Ask a question on any topic and get answers from real people. Go to Yahoo! Answers. --------------------------------- Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now! From swm at emanon.com Tue Jan 6 07:08:54 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 6 Jan 2009 08:08:54 -0500 Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets In-Reply-To: <49633FCA.8090606@gmail.com> References: <49633FCA.8090606@gmail.com> Message-ID: <008b01c97000$034defc0$09e9cf40$@com> There aren't sequence numbers with ICMP. And the timeout value is watched/triggered before the next ICMP is sent, so there shouldn't really be any ordering problem/interpretation anyway. HTH, Scott -----Original Message----- From: Zhao Ping [mailto:pzhao.cn at gmail.com] Sent: Tuesday, January 06, 2009 6:26 AM To: nanog at merit.edu Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets Hi, Does someone happen to know how the Cisco IOS handle the out-of-order ICMP echo-reply packets? print it as success or lose? Thanks, Zhao Ping From swmike at swm.pp.se Tue Jan 6 07:26:44 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 6 Jan 2009 14:26:44 +0100 (CET) Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets In-Reply-To: <008b01c97000$034defc0$09e9cf40$@com> References: <49633FCA.8090606@gmail.com> <008b01c97000$034defc0$09e9cf40$@com> Message-ID: On Tue, 6 Jan 2009, Scott Morris wrote: > There aren't sequence numbers with ICMP. And the timeout value is > watched/triggered before the next ICMP is sent, so there shouldn't really be > any ordering problem/interpretation anyway. Linux ping command does sequencing (so that part of your statement isn't accurate), and you can get out of order packets. It'll say a sequence number and ping time, and there really isn't any "timeout", an ICMP packet can come back 60 seconds later and it'll be counted, even though there were 59 other packets send and returned in the meantime. $ ping localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.023 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.020 ms In IOS, my interpretation anyway, is that the timeout value (2 seconds) mean that it really considers this packet as dropped, so no, in IOS you cannot get out of order packets, at least not that the CLI will show. If the ICMP response packet comes back after timeout value has triggered, it's considered lost. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Tue Jan 6 07:28:52 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 06 Jan 2009 13:28:52 +0000 Subject: Northern Ireland undersea branch to be implemented In-Reply-To: References: <4962F40C.6050603@airwire.ie> Message-ID: <49635C94.9060600@foobar.org> Martin Hannigan wrote: > Is all of this terrestrial network already in place? > > http://www.hiberniaatlantic.com/maps/HA_NIreland_Routes.pdf I understand that it isn't yet, but that it can be built out relatively quickly. Nick From steve at ibctech.ca Tue Jan 6 07:52:02 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 06 Jan 2009 08:52:02 -0500 Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets In-Reply-To: <008b01c97000$034defc0$09e9cf40$@com> References: <49633FCA.8090606@gmail.com> <008b01c97000$034defc0$09e9cf40$@com> Message-ID: <49636202.6030000@ibctech.ca> Scott Morris wrote: > There aren't sequence numbers with ICMP. And the timeout value is > watched/triggered before the next ICMP is sent, so there shouldn't really be > any ordering problem/interpretation anyway. FYI, from RFC 792: Sequence Number Description The data received in the echo message must be returned in the echo reply message. The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. The echoer returns these same values in the echo reply. Steve From steve at ibctech.ca Tue Jan 6 07:54:34 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 06 Jan 2009 08:54:34 -0500 Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets In-Reply-To: <49636202.6030000@ibctech.ca> References: <49633FCA.8090606@gmail.com> <008b01c97000$034defc0$09e9cf40$@com> <49636202.6030000@ibctech.ca> Message-ID: <4963629A.4060209@ibctech.ca> Steve Bertrand wrote: > Scott Morris wrote: >> There aren't sequence numbers with ICMP. And the timeout value is >> watched/triggered before the next ICMP is sent, so there shouldn't really be >> any ordering problem/interpretation anyway. > > FYI, from RFC 792: My apologies. I should have actually used the subject to scope what you were saying. Steve From swm at emanon.com Tue Jan 6 07:58:33 2009 From: swm at emanon.com (Scott Morris) Date: Tue, 6 Jan 2009 08:58:33 -0500 Subject: ? how cisco router handle the out-of-order ICMP echo-reply packets In-Reply-To: <49636202.6030000@ibctech.ca> References: <49633FCA.8090606@gmail.com> <008b01c97000$034defc0$09e9cf40$@com> <49636202.6030000@ibctech.ca> Message-ID: <00c301c97006$f2eea2d0$d8cbe870$@com> Guess I'll have to go back and look at wireshark output again... I didn't recall seeing sequence number used in pings between Cisco devices, although that may just be the implementation ('may be used') part. I'll stand corrected. ;) Scott -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Tuesday, January 06, 2009 8:52 AM To: swm at emanon.com Cc: 'Zhao Ping'; nanog at merit.edu Subject: Re: ? how cisco router handle the out-of-order ICMP echo-reply packets Scott Morris wrote: > There aren't sequence numbers with ICMP. And the timeout value is > watched/triggered before the next ICMP is sent, so there shouldn't really be > any ordering problem/interpretation anyway. FYI, from RFC 792: Sequence Number Description The data received in the echo message must be returned in the echo reply message. The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP to identify a session, and the sequence number might be incremented on each echo request sent. The echoer returns these same values in the echo reply. Steve From cbredi at bofhserver.net Tue Jan 6 09:27:05 2009 From: cbredi at bofhserver.net (Cristian Bradiceanu) Date: Tue, 6 Jan 2009 18:27:05 +0300 Subject: Hirschmann Switches? In-Reply-To: <620fd17c0901052127g65320096u5ac40da39b9716e7@mail.gmail.com> References: <620fd17c0901052127g65320096u5ac40da39b9716e7@mail.gmail.com> Message-ID: <2f12f40a0901060727q705aeb7k6c3e3570a56728d9@mail.gmail.com> We have a good experience with Hirschmann (now Belden) industrial switches, OpenRail RS30 and Modular MICE series. They had some pretty funny software bugs with older software versions. We are using them in MAN ring networks with heavy multicast traffic. Cristian On Tue, Jan 6, 2009 at 8:27 AM, Paul Wall wrote: > I'm looking for feedback from users of the Hirschmann (Belden) > ethernet switches in a service provider environment. Private or > public appreciated. > > Drive Slow, > Paul Wall > > From niels=nanog at bakker.net Tue Jan 6 09:30:52 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 6 Jan 2009 16:30:52 +0100 Subject: Hirschmann Switches? In-Reply-To: <2f12f40a0901060727q705aeb7k6c3e3570a56728d9@mail.gmail.com> References: <620fd17c0901052127g65320096u5ac40da39b9716e7@mail.gmail.com> <2f12f40a0901060727q705aeb7k6c3e3570a56728d9@mail.gmail.com> Message-ID: <20090106153052.GB56621@burnout.tpb.net> Used a MACH4002 as multicast router at 25C3 (among many other locations in the conference/building network as pure L2 devices). Worked flawlessly. -- Niels. * cbredi at bofhserver.net (Cristian Bradiceanu) [Tue 06 Jan 2009, 16:27 CET]: >We have a good experience with Hirschmann (now Belden) industrial >switches, OpenRail RS30 and Modular MICE series. They had some pretty >funny software bugs with older software versions. We are using them in >MAN ring networks with heavy multicast traffic. > >Cristian > > >On Tue, Jan 6, 2009 at 8:27 AM, Paul Wall wrote: >> I'm looking for feedback from users of the Hirschmann (Belden) >> ethernet switches in a service provider environment. Private or >> public appreciated. >> >> Drive Slow, >> Paul Wall >> >> From justin at justinshore.com Tue Jan 6 10:55:31 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 06 Jan 2009 10:55:31 -0600 Subject: Ethical DDoS drone network In-Reply-To: <557715.13157.qm@web31805.mail.mud.yahoo.com> References: <557715.13157.qm@web31805.mail.mud.yahoo.com> Message-ID: <49638D03.4050901@justinshore.com> David Barak wrote: > Consider for a moment a large retail chain, with several hundred or a couple thousand locations. How big a lab should they have before deciding to roll out a new network something-or-other? Should their lab be 1:10 scale? A more realistic figure is that they'll consider themselves lucky to be between 1:50 and 1:100, and that lab is probably understaffed at best. Having a dedicated lab manager is often seen as an expensive luxury, and many businesses don't have the margin to support it. At the very least they should have a complete mock location (for an IT perspective) in a lab. Identical copies of all local servers and a carbon copy of their official template network. This is how AOL does it. Every change is tested in the mock remote site before the official template is changed and the template is pushed out to all the production sites. Justin From stephen at sprunk.org Tue Jan 6 11:05:14 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 06 Jan 2009 11:05:14 -0600 Subject: Ethical DDoS drone network In-Reply-To: <49638D03.4050901@justinshore.com> References: <557715.13157.qm@web31805.mail.mud.yahoo.com> <49638D03.4050901@justinshore.com> Message-ID: <49638F4A.1070205@sprunk.org> Justin Shore wrote: > David Barak wrote: >> Consider for a moment a large retail chain, with several hundred or a >> couple thousand locations. How big a lab should they have before >> deciding to roll out a new network something-or-other? Should their >> lab be 1:10 scale? A more realistic figure is that they'll consider >> themselves lucky to be between 1:50 and 1:100, and that lab is >> probably understaffed at best. Having a dedicated lab manager is >> often seen as an expensive luxury, and many businesses don't have the >> margin to support it. > > At the very least they should have a complete mock location (for an IT > perspective) in a lab. Identical copies of all local servers and a > carbon copy of their official template network. This is how AOL does > it. Every change is tested in the mock remote site before the > official template is changed and the template is pushed out to all the > production sites. That's useful for testing changes to the remote site itself, but it doesn't do anything for testing changes to the entire WAN. I've seen _many_ routing problems appear in large WANs that simply can't be replicated with fewer than a hundred or even a thousand routers. The vendors may have tools to simulate such, since they need them for their own QA, support, etc. but they rarely give them to customers because that'd be another product they have to support... S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From dholmes at mwdh2o.com Tue Jan 6 11:17:38 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 6 Jan 2009 09:17:38 -0800 Subject: Hirschmann Switches? In-Reply-To: <620fd17c0901052127g65320096u5ac40da39b9716e7@mail.gmail.com> References: <620fd17c0901052127g65320096u5ac40da39b9716e7@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E081E7C8F@usmsxt104.mwd.h2o> If an Industrial Ethernet switch is required it may be productive to look at Ruggedcom products. Ruggedcom has a published upper operating range of +85 C, which we have deployed in outside non-HVAC enclosures in environments where the outside ambient temperature can reach +49 to +55 C for extended periods. The L2 software is reliable, supporting rapid spanning tree, and IGMP snooping, among other features. Short and Long range SFP optics (up to 80 Km) are available that are also spec'd out at +85 C operating range. -----Original Message----- From: Paul Wall [mailto:pauldotwall at gmail.com] Sent: Monday, January 05, 2009 9:27 PM To: NANOG list Subject: Hirschmann Switches? I'm looking for feedback from users of the Hirschmann (Belden) ethernet switches in a service provider environment. Private or public appreciated. Drive Slow, Paul Wall From thegameiam at yahoo.com Tue Jan 6 11:25:36 2009 From: thegameiam at yahoo.com (David Barak) Date: Tue, 6 Jan 2009 09:25:36 -0800 (PST) Subject: Ethical DDoS drone network In-Reply-To: <49638D03.4050901@justinshore.com> Message-ID: <871130.31699.qm@web31811.mail.mud.yahoo.com> --- On Tue, 1/6/09, Justin Shore wrote: > David Barak wrote: > > Consider for a moment a large retail chain, with > several hundred or a couple thousand locations. How big a > lab should they have before deciding to roll out a new > network something-or-other? Should their lab be 1:10 scale? > A more realistic figure is that they'll consider > themselves lucky to be between 1:50 and 1:100, and that lab > is probably understaffed at best. Having a dedicated lab > manager is often seen as an expensive luxury, and many > businesses don't have the margin to support it. > > At the very least they should have a complete mock location > (for an IT perspective) in a lab. Identical copies of all > local servers and a carbon copy of their official template > network. This is how AOL does it. Every change is tested > in the mock remote site before the official template is > changed and the template is pushed out to all the production > sites. I don't disagree at all: that is a straightforward way to anticipate *most* problems. What is does not and cannot validate is whether there is a scaling issue, and this is what doing "live" testing does give you. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From eddy+public+spam at noc.everquick.net Tue Jan 6 13:23:48 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Tue, 6 Jan 2009 19:23:48 +0000 (GMT) Subject: question about BGP default routing In-Reply-To: References: Message-ID: KC> Date: Mon, 5 Jan 2009 21:52:12 -0600 KC> From: Kai Chen KC> Will this default route 0.0.0.0/0 be exporting to AS-level KC> neighbors? You can have it exported, or you can have it not exported. It depends how the route is known (eBGP? OSPF? static?) and what you set BGP to redistribute. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From eddy+public+spam at noc.everquick.net Tue Jan 6 13:34:36 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Tue, 6 Jan 2009 19:34:36 +0000 (GMT) Subject: question about BGP default routing In-Reply-To: <722214.74526.qm@web57414.mail.re1.yahoo.com> References: <722214.74526.qm@web57414.mail.re1.yahoo.com> Message-ID: cK> Date: Tue, 6 Jan 2009 07:40:16 -0500 (EST) cK> From: chloe K cK> Why it needs default routes when running BGP? If you have a full table, you do not need default. It's even desirable to drop road-to-nowhere packets inside your network, before they clog up your connections. However, consider that you may encounter some problems -- such as insufficient RAM to deal with growing table size -- that leave you forced to take a partial table. Then what? If you're running BGP, you probably have more than one upstream, so you don't want static defaults (unless the next hop is a serial interface). To deal with this, you can have your providers originate default _and_ send a full table. Under normal circumstances, use a route map that nukes 0/0. If you find yourself in a jam, replace the route map with one that allows 0/0 and discard long paths, AS_PATHs that you consider troublesome, et cetera. You still have the benefit of directing certain routes to a specific provider, but with a smaller (partial) table. Finally, note that not every router needs full tables. Consider a peering router that exchanges traffic between a network's peers and customers. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From Rod.Beck at hiberniaatlantic.com Tue Jan 6 13:58:37 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Tue, 6 Jan 2009 19:58:37 -0000 Subject: [SPAM-HEADER] - Re: Northern Ireland undersea branch to be implemented - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <4962F40C.6050603@airwire.ie> <49635C94.9060600@foobar.org> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB9F6895@bert.HiberniaAtlantic.local> It can be done very quickly. We've committed to fast delivery. The terrestrial conduit and fibre is ready to go ... Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Tue 1/6/2009 1:28 PM To: Martin Hannigan Cc: nanog at nanog.org Subject: [SPAM-HEADER] - Re: Northern Ireland undersea branch to be implemented - Email has different SMTP TO: and MIME TO: fields in the email addresses Martin Hannigan wrote: > Is all of this terrestrial network already in place? > > http://www.hiberniaatlantic.com/maps/HA_NIreland_Routes.pdf I understand that it isn't yet, but that it can be built out relatively quickly. Nick From Kevin.Smith at dca.state.fl.us Tue Jan 6 14:34:31 2009 From: Kevin.Smith at dca.state.fl.us (Kevin.Smith at dca.state.fl.us) Date: Tue, 6 Jan 2009 15:34:31 -0500 Subject: Estimate of satellite vs. Land-based traffic Message-ID: All, Participting in a severe solar event EXERCISE. Can anyone give me an educated guesstimate of the percentage of backbone traffic that is satellite dependent vs. that which is totally land-based? Thanks Kevin Smith Information Systems & Services Department of Community Affairs kevin.smith at dca.state.fl.us [preferred] 850.922.9921 [voice] 850.487.3376 [fax] -------------------------- Sent from a BlackBerry Wireless Handheld Florida has a broad public records law and all correspondence, including email addresses, may be subject to disclosure. From simon at slimey.org Tue Jan 6 14:36:23 2009 From: simon at slimey.org (Simon Lockhart) Date: Tue, 6 Jan 2009 20:36:23 +0000 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: References: Message-ID: <20090106203623.GH14718@virtual.bogons.net> On Tue Jan 06, 2009 at 03:34:31PM -0500, Kevin.Smith at dca.state.fl.us wrote: > Participting in a severe solar event EXERCISE. Can anyone give me an > educated guesstimate of the percentage of backbone traffic that is > satellite dependent vs. that which is totally land-based? Depends on the country. I suspect in the USA, it's close to 100% land-based. In places in central Africa, it's probably close to 100% satellite based. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From jeffrey.lyon at blacklotus.net Tue Jan 6 14:40:28 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 6 Jan 2009 15:40:28 -0500 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: References: Message-ID: <16720fe00901061240o70199b4fxed2c0621c075fbec@mail.gmail.com> Kevin, Satellite transport is common mainly in areas where land based infrastructure is not feasible. In developed nations this is almost exclusively the case. Satellite latency is far too high to rely on it for routine communications unless used as a last resort. Best regards, Jeff On Tue, Jan 6, 2009 at 3:34 PM, wrote: > > > All, > > Participting in a severe solar event EXERCISE. Can anyone give me an > educated guesstimate of the percentage of backbone traffic that is > satellite dependent vs. that which is totally land-based? > > Thanks > > > > Kevin Smith > Information Systems & Services > Department of Community Affairs > kevin.smith at dca.state.fl.us [preferred] > 850.922.9921 [voice] > 850.487.3376 [fax] > > -------------------------- > Sent from a BlackBerry Wireless Handheld > > Florida has a broad public records law and all correspondence, including > email addresses, may be subject to disclosure. > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From sean at donelan.com Tue Jan 6 14:46:29 2009 From: sean at donelan.com (Sean Donelan) Date: Tue, 6 Jan 2009 15:46:29 -0500 (EST) Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: References: Message-ID: <200901061544490.32BF5B92.3737@clifden.donelan.com> On Tue, 6 Jan 2009, Kevin.Smith at dca.state.fl.us wrote: > Participting in a severe solar event EXERCISE. Can anyone give me an > educated guesstimate of the percentage of backbone traffic that is > satellite dependent vs. that which is totally land-based? The last FCC statistics I found researching this last year. 2006 Satellites carry 0.22% of US international circuits. There are 14,346 US international circuits via satellite. From rdobbins at cisco.com Tue Jan 6 18:50:46 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Wed, 7 Jan 2009 08:50:46 +0800 Subject: Ethical DDoS drone network In-Reply-To: <49638F4A.1070205@sprunk.org> References: <557715.13157.qm@web31805.mail.mud.yahoo.com> <49638D03.4050901@justinshore.com> <49638F4A.1070205@sprunk.org> Message-ID: <2DB07672-2038-4D2A-974F-D1195545BD3D@cisco.com> On Jan 7, 2009, at 1:05 AM, Stephen Sprunk wrote: > I've seen _many_ routing problems appear in large WANs that simply > can't be replicated with fewer than a hundred or even a thousand > routers. Users can simulate many of these conditions themselves using various open-source and commercial tools, which've been available for many years. And again, it comes back to understanding the performance envelope of one's equipment, even without simulation. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From eddy+public+spam at noc.everquick.net Tue Jan 6 19:40:13 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Wed, 7 Jan 2009 01:40:13 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: <2DB07672-2038-4D2A-974F-D1195545BD3D@cisco.com> References: <557715.13157.qm@web31805.mail.mud.yahoo.com> <49638D03.4050901@justinshore.com> <49638F4A.1070205@sprunk.org> <2DB07672-2038-4D2A-974F-D1195545BD3D@cisco.com> Message-ID: RD> Date: Wed, 7 Jan 2009 08:50:46 +0800 RD> From: Roland Dobbins RD> > I've seen _many_ routing problems appear in large WANs that simply RD> > can't be replicated with fewer than a hundred or even a thousand RD> > routers. RD> Users can simulate many of these conditions themselves using various many != all It appears to be a question of what incremental benefit does one gain from real-world testing? RD> open-source and commercial tools, which've been available for many RD> years. I think that everyone agrees: No live testing until "adequate" lab testing has been performed. The disagreement seems to be over when/if live testing is necessary, and how much. Because it just wouldn't be a NANOG thread without analogies *grin*, I offer the following: drug certification, aircraft certification, automobile crash testing, database benchmarking. Even when a system is highly deterministic, such as a database, one still expects _real-world_ testing. Traffic flows on large networks are highly stochastic... and this includes OPNs, which I posit are futile to attempt to model. RD> And again, it comes back to understanding the performance envelope RD> of one's equipment, even without simulation. Very true. If one deploys an OSPF-happy network thinking that it scales O(n), one is in for a rude shock. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From eddy+public+spam at noc.everquick.net Tue Jan 6 19:44:02 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Wed, 7 Jan 2009 01:44:02 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> References: <16720fe00901041806m395fd949h1dafdfaf3c2aa520@mail.gmail.com> Message-ID: I propose that we create two Internets. One can be the "testing" Internet, and the other can be "production". To ensure that both receive adequate treatment, they can trade places every few days. If something breaks, it can be moved from "production" to "testing". The detection of hyperbole, sarcasm, and mathematical invalidity is left as an exercise to the reader. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From rdobbins at cisco.com Tue Jan 6 19:48:16 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Wed, 7 Jan 2009 09:48:16 +0800 Subject: Ethical DDoS drone network In-Reply-To: References: <557715.13157.qm@web31805.mail.mud.yahoo.com> <49638D03.4050901@justinshore.com> <49638F4A.1070205@sprunk.org> <2DB07672-2038-4D2A-974F-D1195545BD3D@cisco.com> Message-ID: On Jan 7, 2009, at 9:40 AM, Edward B. DREGER wrote: > Even when a system is highly deterministic, such as a database, one > still expects _real-world_ testing. Traffic flows on large networks > are > highly stochastic... and this includes OPNs, which I posit are > futile to > attempt to model. Sure. In many cases, it seems that there's a lot of talk about testing, after-the-fact, with relatively little analysis performed prior-to-the- fact to inform the design, including baseline security requirements. When one has a network/system in which the basic security BCPs haven't been implemented, it makes little sense to expend scarce resources testing when those resources could be better-employed hardening and increasing the resiliency and robustness of said network/system. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From eddy+public+spam at noc.everquick.net Tue Jan 6 20:13:19 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Wed, 7 Jan 2009 02:13:19 +0000 (GMT) Subject: Ethical DDoS drone network In-Reply-To: References: <557715.13157.qm@web31805.mail.mud.yahoo.com> <49638D03.4050901@justinshore.com> <49638F4A.1070205@sprunk.org> <2DB07672-2038-4D2A-974F-D1195545BD3D@cisco.com> Message-ID: RD> Date: Wed, 7 Jan 2009 09:48:16 +0800 RD> From: Roland Dobbins RD> When one has a network/system in which the basic security BCPs RD> haven't been implemented, it makes little sense to expend scarce RD> resources testing when those resources could be better-employed RD> hardening and increasing the resiliency and robustness of said RD> network/system. Very true. "Hey, it really _did_ break!" is hardly a useful approach. Your post awakened my inner cynic: Perhaps there are people who look to stress-testing OPNs in hopes that the weakest link is elsewhere, so that they may point the proverbial finger instead of fixing internal problems. #include "cost-shifting/patchining,smtp-auth,spf,urpf,et-cetera.h" Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From pdonner at cisco.com Tue Jan 6 21:14:14 2009 From: pdonner at cisco.com (Paul Donner) Date: Tue, 06 Jan 2009 20:14:14 -0700 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <16720fe00901061240o70199b4fxed2c0621c075fbec@mail.gmail.com> References: <16720fe00901061240o70199b4fxed2c0621c075fbec@mail.gmail.com> Message-ID: <49641E06.9050605@cisco.com> Jeffrey, While technically you are correct, I would say that you probably should also add a category for mobile communications LAND/SEA/AIR. The traffic for these will be increasing in time as vendors are starting to put switches and routers on-board spacecraft making applications that were once borderline, because of delay, more acceptable. Depending on what you are doing (eg. comm between two satellite ground stations, mobile or stationary) the application can benefit from from reduced RTT due to this innovation. One-way delay would thus be about 250ms. This is greater than the generally accepted 150ms for a voice call but with good voice quality 250ms is not bad. This of course is based on GEO sats. LEO or MEO satellites are much closer to the earth so the delay would be less but they present a whole host of other complexities. While satellites will probably never come close to the volume of ground-based comm, they will cater to niche markets, military, mobile and disadvantaged users. WRT Kevin's query, if you are concerned about a solar incident and it's affects on satcom, you might want to take a look at what user base (e.g. which mobile users and what impact loss of comm will have on what they are doing) is affected rather than understanding the volumes that are affected as this might provide a much more thorough understanding of any impact. But that is merely my two cents worth. -Donner Jeffrey Lyon wrote: > Kevin, > > Satellite transport is common mainly in areas where land based > infrastructure is not feasible. In developed nations this is almost > exclusively the case. Satellite latency is far too high to rely on it > for routine communications unless used as a last resort. > > Best regards, Jeff > > On Tue, Jan 6, 2009 at 3:34 PM, wrote: >> >> All, >> >> Participting in a severe solar event EXERCISE. Can anyone give me an >> educated guesstimate of the percentage of backbone traffic that is >> satellite dependent vs. that which is totally land-based? >> >> Thanks >> >> >> >> Kevin Smith >> Information Systems & Services >> Department of Community Affairs >> kevin.smith at dca.state.fl.us [preferred] >> 850.922.9921 [voice] >> 850.487.3376 [fax] >> >> -------------------------- >> Sent from a BlackBerry Wireless Handheld >> >> Florida has a broad public records law and all correspondence, including >> email addresses, may be subject to disclosure. >> >> >> > > > From jfmezei at vaxination.ca Wed Jan 7 00:00:58 2009 From: jfmezei at vaxination.ca (JF Mezei) Date: Wed, 07 Jan 2009 01:00:58 -0500 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: References: Message-ID: <4964451A.3070902@vaxination.ca> Northern communities in Canada's arctic rely exclusively on satellite for voice/data. Not a lot of data flowing comparatively, but it is their only option so it is more of a "mission critical" thing than a backup. From sean at donelan.com Wed Jan 7 00:26:48 2009 From: sean at donelan.com (Sean Donelan) Date: Wed, 7 Jan 2009 01:26:48 -0500 (EST) Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <49641E06.9050605@cisco.com> References: <16720fe00901061240o70199b4fxed2c0621c075fbec@mail.gmail.com> <49641E06.9050605@cisco.com> Message-ID: <200901070119230.32BF5B92.4731@clifden.donelan.com> On Tue, 6 Jan 2009, Paul Donner wrote: > WRT Kevin's query, if you are concerned about a solar incident and it's > affects on satcom, you might want to take a look at what user base (e.g. > which mobile users and what impact loss of comm will have on what they are > doing) is affected rather than understanding the volumes that are affected as > this might provide a much more thorough understanding of any impact. But > that is merely my two cents worth. Yep, consider the Galaxy IV satellite incident. The loss of a single satellite had a significant impact on its user population for several days/month. Other satellites can be moved into an orbital slot, and dishes can be re-pointed; but Galaxy IV lead to some interesting (i.e. unexpected to some users) failures. I'm not sure how many hospitals realized their "in-house" pager systems relied on a satellite. From joelja at bogus.com Wed Jan 7 01:03:20 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 06 Jan 2009 23:03:20 -0800 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <4964451A.3070902@vaxination.ca> References: <4964451A.3070902@vaxination.ca> Message-ID: <496453B8.1080203@bogus.com> JF Mezei wrote: > Northern communities in Canada's arctic rely exclusively on satellite > for voice/data. > > Not a lot of data flowing comparatively, but it is their only option so > it is more of a "mission critical" thing than a backup. Also high latitudes are problematic as far as your link budget to geostationary satellites goes in the first place. Switching to an alternative satellite in the event of a failure may be more challenging as a result. From pdonner at cisco.com Wed Jan 7 01:59:32 2009 From: pdonner at cisco.com (Paul Donner) Date: Wed, 07 Jan 2009 00:59:32 -0700 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <200901070119230.32BF5B92.4731@clifden.donelan.com> References: <16720fe00901061240o70199b4fxed2c0621c075fbec@mail.gmail.com> <49641E06.9050605@cisco.com> <200901070119230.32BF5B92.4731@clifden.donelan.com> Message-ID: <496460E4.3070304@cisco.com> Satellites often sit at the edge of the network. The "orbital last mile" for individual users as well as in-country (Africa for e.g.) ISPs and Enterprise networks. When they go, often there is no backup (except maybe another satellite connection). Sean Donelan wrote: > On Tue, 6 Jan 2009, Paul Donner wrote: >> WRT Kevin's query, if you are concerned about a solar incident and >> it's affects on satcom, you might want to take a look at what user >> base (e.g. which mobile users and what impact loss of comm will have >> on what they are doing) is affected rather than understanding the >> volumes that are affected as this might provide a much more thorough >> understanding of any impact. But that is merely my two cents worth. > > Yep, consider the Galaxy IV satellite incident. The loss of a single > satellite had a significant impact on its user population for several > days/month. Other satellites can be moved into an orbital slot, and > dishes can be re-pointed; but Galaxy IV lead to some interesting (i.e. > unexpected to some users) failures. I'm not sure how many hospitals > realized their "in-house" pager systems relied on a satellite. > > From jabley at hopcount.ca Wed Jan 7 03:51:35 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 7 Jan 2009 04:51:35 -0500 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <4964451A.3070902@vaxination.ca> References: <4964451A.3070902@vaxination.ca> Message-ID: On 2009-01-07, at 01:00, JF Mezei wrote: > Northern communities in Canada's arctic rely exclusively on satellite > for voice/data. Ditto most Pacific Island nations... > Not a lot of data flowing comparatively, but it is their only option > so > it is more of a "mission critical" thing than a backup. ... although most Pacific Islanders I have met who are not on cable routes are somewhat tolerant about multi-week outages, perhaps because the alternative to tolerance is not obvious. Joe From tme at multicasttech.com Wed Jan 7 07:08:55 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 7 Jan 2009 08:08:55 -0500 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <4964451A.3070902@vaxination.ca> References: <4964451A.3070902@vaxination.ca> Message-ID: <3458F419-CAF7-4C8C-9D0E-2DDA00219521@multicasttech.com> French Polynesia has no fiber links at all and relies exclusively on satellite and maybe radio for internet access. It looks, though, like they may finally get fiber sometime in the next decade : http://www.newstin.com/tag/us/95233925 Marshall On Jan 7, 2009, at 1:00 AM, JF Mezei wrote: > Northern communities in Canada's arctic rely exclusively on satellite > for voice/data. > > Not a lot of data flowing comparatively, but it is their only option > so > it is more of a "mission critical" thing than a backup. > From frnkblk at iname.com Wed Jan 7 09:06:42 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 7 Jan 2009 09:06:42 -0600 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <496460E4.3070304@cisco.com> References: <16720fe00901061240o70199b4fxed2c0621c075fbec@mail.gmail.com> <49641E06.9050605@cisco.com> <200901070119230.32BF5B92.4731@clifden.donelan.com> <496460E4.3070304@cisco.com> Message-ID: I lived in a Caribbean country where, at the time, most of their LD traffic was over satellite. While people didn't like it, there were times that there was no public off-island access for a few hours at a time. It's just a fact of life, and people get used to it. Those who don't buy a satellite phone. Frank -----Original Message----- From: Paul Donner [mailto:pdonner at cisco.com] Sent: Wednesday, January 07, 2009 2:00 AM To: Sean Donelan Cc: nanog at nanog.org Subject: Re: Estimate of satellite vs. Land-based traffic Satellites often sit at the edge of the network. The "orbital last mile" for individual users as well as in-country (Africa for e.g.) ISPs and Enterprise networks. When they go, often there is no backup (except maybe another satellite connection). Sean Donelan wrote: > On Tue, 6 Jan 2009, Paul Donner wrote: >> WRT Kevin's query, if you are concerned about a solar incident and >> it's affects on satcom, you might want to take a look at what user >> base (e.g. which mobile users and what impact loss of comm will have >> on what they are doing) is affected rather than understanding the >> volumes that are affected as this might provide a much more thorough >> understanding of any impact. But that is merely my two cents worth. > > Yep, consider the Galaxy IV satellite incident. The loss of a single > satellite had a significant impact on its user population for several > days/month. Other satellites can be moved into an orbital slot, and > dishes can be re-pointed; but Galaxy IV lead to some interesting (i.e. > unexpected to some users) failures. I'm not sure how many hospitals > realized their "in-house" pager systems relied on a satellite. > > From hannigan at verneglobal.com Wed Jan 7 13:38:30 2009 From: hannigan at verneglobal.com (Martin Hannigan) Date: Wed, 7 Jan 2009 19:38:30 +0000 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: References: Message-ID: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> It depends on where in some cases. Take Greenland for example. Prior to Tele Greenland possibly completing the Greenland Connect cable[1] real soon now (Halifax to Nuuk, Nuuk to Iceland, branched to Qaqortoq, with xcon to UK and Denmark) I seem to recall that a large amount of their capacity was via satellite from Godthab(Nuuk) to Denmark. In this case, you're likely talking 100%. Almost all of your remote cases are going to be in a similiar situation ie. Svarlsbad, most stuff above t~N60^ parallel (or so) etc. [1] Tele Greenland IT News Item (see last paragraph, Brian Buus Pedersen is Tele's CEO) Best, Martin Hannigan -- Martin Hannigan http://www.verneglobal.com/ Senior Director e: hannigan at verneglobal.com Verne Global Datacenters c: +16178216079 Keflavik, Iceland f: +16172347098 ________________________________________ From: Kevin.Smith at dca.state.fl.us [Kevin.Smith at dca.state.fl.us] Sent: Tuesday, January 06, 2009 15:34 To: nanog at nanog.org Subject: Estimate of satellite vs. Land-based traffic All, Participting in a severe solar event EXERCISE. Can anyone give me an educated guesstimate of the percentage of backbone traffic that is satellite dependent vs. that which is totally land-based? Thanks Kevin Smith Information Systems & Services Department of Community Affairs kevin.smith at dca.state.fl.us [preferred] 850.922.9921 [voice] 850.487.3376 [fax] -------------------------- Sent from a BlackBerry Wireless Handheld Florida has a broad public records law and all correspondence, including email addresses, may be subject to disclosure. From aaron.millisor at bright.net Wed Jan 7 13:53:25 2009 From: aaron.millisor at bright.net (Aaron Millisor) Date: Wed, 07 Jan 2009 14:53:25 -0500 Subject: Single carrier multi-circuit asynchronous routing issue Message-ID: <49650835.8090308@bright.net> I am curious to know if anyone has else has hit a problem like the one I am running into right now. I have two DS3 DIA's in my router, terminating on two separate routers at Sprint. We peer with BGP and I am prepending certain of my prefixes to balance the traffic load. src __________ dst 1.1.1.0 |----|- ds3 #1 -| sprint 1 |--( ) 2.2.2.0 ------- |me | ( internet ) ------- | | ( ) | | __________ ( ) |----|- ds3 #2 -| sprint 2 |--( ) If I were to prepend the network 1.1.1.0 to come in on 'sprint 1', but have a route to 2.2.2.0 via 'sprint 2' so that traffic comes in on one circuit but returns on the other, routing is broken. If I change my route so that packets directed to 2.2.2.0 return on the same circuit that the traffic is received on, everything works fine. Has anyone else run into an issue like this before? -- am From niels=nanog at bakker.net Wed Jan 7 14:05:56 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 7 Jan 2009 21:05:56 +0100 Subject: Single carrier multi-circuit asynchronous routing issue In-Reply-To: <49650835.8090308@bright.net> References: <49650835.8090308@bright.net> Message-ID: <20090107200556.GJ56621@burnout.tpb.net> * aaron.millisor at bright.net (Aaron Millisor) [Wed 07 Jan 2009, 20:53 CET]: [..] >If I were to prepend the network 1.1.1.0 to come in on 'sprint 1', but >have a route to 2.2.2.0 via 'sprint 2' so that traffic comes in on one >circuit but returns on the other, routing is broken. If I change my >route so that packets directed to 2.2.2.0 return on the same circuit >that the traffic is received on, everything works fine. You might be running into uRPF (unicast reverse path forward verification). -- Niels. From tme at multicasttech.com Wed Jan 7 14:29:58 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 7 Jan 2009 15:29:58 -0500 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> References: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> Message-ID: <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> When I was working with Svalbard, Internet connectivity was through a satellite link at about 2.5 degrees elevation looking through a notch in the mountains. I don't think it has changed Regards Marshall On Jan 7, 2009, at 2:38 PM, Martin Hannigan wrote: > > > It depends on where in some cases. Take Greenland for example. Prior > to Tele Greenland possibly completing the Greenland Connect cable[1] > real soon now (Halifax to Nuuk, Nuuk to Iceland, branched to > Qaqortoq, with xcon to UK and Denmark) I seem to recall that a large > amount of their capacity was via satellite from Godthab(Nuuk) to > Denmark. > > In this case, you're likely talking 100%. Almost all of your remote > cases are going to be in a similiar situation ie. Svarlsbad, most > stuff above t~N60^ parallel (or so) etc. > > [1] Tele Greenland IT News Item (see last paragraph, Brian Buus > Pedersen is Tele's CEO) > > > Best, > > Martin Hannigan > > -- > Martin Hannigan http://www.verneglobal.com/ > Senior Director e: hannigan at verneglobal.com > Verne Global Datacenters c: +16178216079 > Keflavik, Iceland f: +16172347098 > ________________________________________ > From: Kevin.Smith at dca.state.fl.us [Kevin.Smith at dca.state.fl.us] > Sent: Tuesday, January 06, 2009 15:34 > To: nanog at nanog.org > Subject: Estimate of satellite vs. Land-based traffic > > All, > > Participting in a severe solar event EXERCISE. Can anyone give me an > educated guesstimate of the percentage of backbone traffic that is > satellite dependent vs. that which is totally land-based? > > Thanks > > > > Kevin Smith > Information Systems & Services > Department of Community Affairs > kevin.smith at dca.state.fl.us [preferred] > 850.922.9921 [voice] > 850.487.3376 [fax] > > -------------------------- > Sent from a BlackBerry Wireless Handheld > > Florida has a broad public records law and all correspondence, > including > email addresses, may be subject to disclosure. From sthaug at nethelp.no Wed Jan 7 14:51:12 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 07 Jan 2009 21:51:12 +0100 (CET) Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> References: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> Message-ID: <20090107.215112.74726470.sthaug@nethelp.no> > When I was working with Svalbard, Internet connectivity was through a > satellite link at about 2.5 degrees > elevation looking through a notch in the mountains. I don't think it > has changed It has. Svalbard now has undersea cable connection to the Norwegian mainland. See http://en.wikipedia.org/wiki/Svalbard_Undersea_Cable_System Steinar Haug, Nethelp consulting, sthaug at nethelp.no From list-only at dnz.se Wed Jan 7 15:00:28 2009 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Wed, 7 Jan 2009 22:00:28 +0100 Subject: Single carrier multi-circuit asynchronous routing issue In-Reply-To: <20090107200556.GJ56621@burnout.tpb.net> References: <49650835.8090308@bright.net> <20090107200556.GJ56621@burnout.tpb.net> Message-ID: <914FFB80-2AFA-4D0C-AFE1-4F4B5A09FCFD@dnz.se> On 7 jan 2009, at 21.05, Niels Bakker wrote: > * aaron.millisor at bright.net (Aaron Millisor) [Wed 07 Jan 2009, > 20:53 CET]: > [..] >> If I were to prepend the network 1.1.1.0 to come in on 'sprint 1', >> but have a route to 2.2.2.0 via 'sprint 2' so that traffic comes >> in on one circuit but returns on the other, routing is broken. If >> I change my route so that packets directed to 2.2.2.0 return on >> the same circuit that the traffic is received on, everything works >> fine. > > You might be running into uRPF (unicast reverse path forward > verification). > > > -- Niels. > Strict-mode uRPF will couse this, I am sure sprint support can help you with it.. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se From nonobvious at gmail.com Wed Jan 7 16:46:52 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 7 Jan 2009 14:46:52 -0800 Subject: Ethical DDoS drone network In-Reply-To: References: <557715.13157.qm@web31805.mail.mud.yahoo.com> Message-ID: <18a5e7cb0901071446h9b01bc3i4549849024291d3c@mail.gmail.com> On Mon, Jan 5, 2009 at 4:11 PM, Roland Dobbins wrote: > In my experience, once one has an understanding of the performance envelopes > and has built a lab which contains examples of the functional elements of > the system (network infrastructure, servers, apps, databases, clients, et. > al.), one can extrapolate pretty accurately well out to orders of magnitude. It's one of those things where the difference between theory and practice is smaller in theory than it is in practice, though... But yeah, sometimes things like load balancers fail, or routers run out of table space, or whatever. I've had enough enterprise customers worry about what will happen to their VPN sites if some neighborhood kid annoys his gamer buddies and gets a few Gbps of traffic to knock down their DSLAM and its upstream feeds or whatever. > The problem is that many organizations don't do the above prior to freezing > the design and initiating deployment. Back in the mid-90s I had one networking software development customer that had a room with 500 PCs on racks, and some switches that would let them dump groups of 50s of them together with whatever server they were testing. That was a lot more impressive back then when PCs were full-sized devices that needed keyboards and monitors (grouped on KVMs, at least), as opposed to being 1Us or blades or virtual machines. ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Wed Jan 7 18:20:50 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 7 Jan 2009 16:20:50 -0800 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <20090107.215112.74726470.sthaug@nethelp.no> References: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> <20090107.215112.74726470.sthaug@nethelp.no> Message-ID: <18a5e7cb0901071620o50b97ae1n6cc841f403cc3cfc@mail.gmail.com> At least in the US, satellite use is fairly limited compared to fiber and copper, mainly in the following areas - TV broadcast - Data and voice to remote areas (a few hundred Alaska villages, some connectivity up to oil drilling areas in Alaska, though there's also fiber, plus some Internet in non-wired parts of the US. I'm not aware of regular telco use of satellites for service in the middle 48 states. Is Alohanet or something like it still running in Hawaii?) - Some emergency backup applications such as restoration for carriers (redundant cables are nice, but you need access in multiple failure scenarios such as floods and earthquakes.) - Specialized enterprise applications (some years ago, VSAT was fairly common for credit-card support at gas stations, malls, etc. I know one grocery store chain that finally moved to terrestrial in the late 90s, forced by Microsoft application protocols that couldn't handle the VSAT latency.) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From bjorn at mork.no Thu Jan 8 05:29:23 2009 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 08 Jan 2009 12:29:23 +0100 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> (Marshall Eubanks's message of "Wed, 7 Jan 2009 15:29:58 -0500") References: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> Message-ID: <874p0aqbn0.fsf@obelix.mork.no> Marshall Eubanks writes: > When I was working with Svalbard, Internet connectivity was through a > satellite link at about 2.5 degrees > elevation looking through a notch in the mountains. I don't think it > has changed It has, as Steinar says. For those interested in the necessary elevation at 78 degrees north, I found a nice picture of the antennas here: http://www.mydarc.de/la0by/isfjord.jpg There aren't any mountains in front of the the antennas. However there is a mountain between Isfjord Radio and Longyearbyen (the main settlement), requiring a relay station on the radio link between these. Bj?rn From tme at multicasttech.com Thu Jan 8 06:00:54 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 8 Jan 2009 07:00:54 -0500 Subject: Estimate of satellite vs. Land-based traffic In-Reply-To: <874p0aqbn0.fsf@obelix.mork.no> References: <276F91D984907C4583F300AC9D4BBC5D03CFD09826@iskefkefdcexc01> <8848346F-B2A8-490D-88C1-7B8DA25A7E81@multicasttech.com> <874p0aqbn0.fsf@obelix.mork.no> Message-ID: <1F809F33-85CE-421C-B9CF-3AF563DBDF90@multicasttech.com> On Jan 8, 2009, at 6:29 AM, Bj?rn Mork wrote: > Marshall Eubanks writes: > >> When I was working with Svalbard, Internet connectivity was through a >> satellite link at about 2.5 degrees >> elevation looking through a notch in the mountains. I don't think it >> has changed > > It has, as Steinar says. > > For those interested in the necessary elevation at 78 degrees north, I > found a nice picture of the antennas here: > http://www.mydarc.de/la0by/isfjord.jpg > > There aren't any mountains in front of the the antennas. However > there > is a mountain between Isfjord Radio and Longyearbyen (the main > settlement), requiring a relay station on the radio link between > these. > The NyAlesund SGO http://siempre.arcus.org/4DACTION/wi_alias_fsDrawPage/1/107 is some distance North of Longyearbyen (how many places can say that ?), and I used to have a nice picture, which alas I cannot find, of the satellite link (not the 20 meter dish in the picture) apparently pointing at the mountains. It does indeed have fiber now, and has been used for eVLBI http://www.haystack.mit.edu/tech/vlbi/evlbi/index.html Regards Marshall > > > Bj?rn From toddunder at gmail.com Thu Jan 8 11:03:04 2009 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 8 Jan 2009 12:03:04 -0500 Subject: NANOG 45 Lightning Talks Open Message-ID: <65b1fd2e0901080903x982752age30fbd9181ec822@mail.gmail.com> On behalf of the rest of the NANOG Program Committee, I'm pleased to announce that submissions for Lightning talks for NANOG 45 are open at: http://www.nanogpc.org/lightning/ Lightning talks are short presentations (no more than 10 minutes, including questions) of topics that are either too short, too timely or too preliminary to include on the general agenda. In the past, these have been some of the most popular presentations at NANOG, For this upcoming conference in Santo Domingo, we have lightning talk slots available on all three days. The Program Committee will pick the first three of these prior to the conference (by the end of next week, in fact), so please get your submissions in by Wed, 14 January for the best possible consideration. We already have several submissions, but would appreciate more, of course. Rest assured, however, that we will continue accepting lightnings talk proposals (and voting on them) through the conference, as timeliness is part of what makes lightning talks so great. The sooner you submit, though, the better your chance to present. See all of you in Santo Domingo. Todd Underwood Chair, Program Committee, NANOG From dennis at thenose.net Thu Jan 8 16:30:13 2009 From: dennis at thenose.net (Dennis Dayman) Date: Thu, 8 Jan 2009 17:30:13 -0500 Subject: Test Message-ID: this still working? From jthomas at crucialservers.net Thu Jan 8 16:46:52 2009 From: jthomas at crucialservers.net (James Thomas) Date: Thu, 8 Jan 2009 17:46:52 -0500 Subject: Test In-Reply-To: References: Message-ID: <00f301c971e2$fffce080$fff6a180$@net> Yes :) James -----Original Message----- From: Dennis Dayman [mailto:dennis at thenose.net] Sent: Thursday, January 08, 2009 5:30 PM To: Nanog Subject: Test this still working? From dennis at thenose.net Thu Jan 8 16:48:06 2009 From: dennis at thenose.net (Dennis Dayman) Date: Thu, 8 Jan 2009 17:48:06 -0500 Subject: List Help Message-ID: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> So I apologize for that test, but I can no longer see posts to the list. I can send to the list, but I don't get a copy of my posts or anyone else's. My MTA is not blocking anything nor does it ever get a connection from MERIT mail servers to send me a copy of the posts. I also don't receive PSWD reset emails. Anyone know who I can talk to? -Dennis From jabley at hopcount.ca Thu Jan 8 16:51:19 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 8 Jan 2009 17:51:19 -0500 Subject: List Help In-Reply-To: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> References: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> Message-ID: <38FBB6E7-C231-4827-988A-18DA92FBFFF8@hopcount.ca> On 2009-01-08, at 17:48, Dennis Dayman wrote: > So I apologize for that test, but I can no longer see posts to the > list. I can send to the list, but I don't get a copy of my posts or > anyone else's. My MTA is not blocking anything nor does it ever get > a connection from MERIT mail servers to send me a copy of the posts. > I also don't receive PSWD reset emails. > > Anyone know who I can talk to? http://www.google.com/search?q=nanog+list+administrators Top hit for me is http://www.nanog.org/mailinglist/listadmins/ Joe From jthomas at crucialservers.net Thu Jan 8 17:10:36 2009 From: jthomas at crucialservers.net (James Thomas) Date: Thu, 8 Jan 2009 18:10:36 -0500 Subject: List Help In-Reply-To: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> References: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> Message-ID: <00fc01c971e6$50bb51c0$f231f540$@net> Final-Recipient: rfc822;dennis at thenose.net Action: failed Status: 5.5.0 Diagnostic-Code: smtp;550 failed to meet SPF requirements I wish I could help :) -----Original Message----- From: Dennis Dayman [mailto:dennis at thenose.net] Sent: Thursday, January 08, 2009 5:48 PM To: Nanog Subject: List Help So I apologize for that test, but I can no longer see posts to the list. I can send to the list, but I don't get a copy of my posts or anyone else's. My MTA is not blocking anything nor does it ever get a connection from MERIT mail servers to send me a copy of the posts. I also don't receive PSWD reset emails. Anyone know who I can talk to? -Dennis From nick at foobar.org Thu Jan 8 17:15:26 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 08 Jan 2009 23:15:26 +0000 Subject: List Help In-Reply-To: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> References: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> Message-ID: <4966890E.90404@foobar.org> Dennis Dayman wrote: > So I apologize for that test, but I can no longer see posts to the list. > I can send to the list, but I don't get a copy of my posts or anyone > else's. My MTA is not blocking anything nor does it ever get a > connection from MERIT mail servers to send me a copy of the posts. I > also don't receive PSWD reset emails. > > Anyone know who I can talk to? Dennis, As you've already found out, the most important thing when dealing with a situation like this is to mail the list itself with a test message. If the first one doesn't come through, it's considered quite acceptable to send a couple of others, just to test out various mods at your end. Don't worry that your junk is going to end up in five thousand peoples' mailboxes. They won't mind - after all, your subscription to the mailing list is really important, and they all realise this! Real NANOG m/l subscribers don't bother with search engines to find out how to deal with problems like this. This is because it's much faster and more efficient to mail the list with a request for help. Forget the fact that NANOG uses standard mailman conventions. Other mailing list subscribers will fall over themselves in the rush to help users like you who are having email trouble because of issues unrelated to the mailing list. But you've done this too! Congrats, you're one heck of a power user! Now that you've taken the two most important steps towards getting your issues dealt with, the next step is to wait for other people to diagnose and hopefully fix your problem for free. Remember that this is the internet and everything is free on the internet, including expert consultancy on mail problems and most importantly, peoples' time. And as before, if it doesn't get fixed soon, just remember to send a couple more emails to the list to embarrass the list administrators into finally fixing your problems. This is a sure-fire way of getting the problem dealt with in a timely manner. hope this helps, Nick From jeremy.furr at twcable.com Thu Jan 8 17:17:04 2009 From: jeremy.furr at twcable.com (Furr, Jeremy) Date: Thu, 8 Jan 2009 18:17:04 -0500 Subject: List Help In-Reply-To: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> References: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> Message-ID: <58174FA985B92A42B9E3142C4DD2CC0402EDC2EE@PRVPVSMAIL07.corp.twcable.com> If you can't see posts to the list or responses, why would you go to the list for help? P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible. -----Original Message----- From: Dennis Dayman [mailto:dennis at thenose.net] Sent: Thursday, January 08, 2009 5:48 PM To: Nanog Subject: List Help So I apologize for that test, but I can no longer see posts to the list. I can send to the list, but I don't get a copy of my posts or anyone else's. My MTA is not blocking anything nor does it ever get a connection from MERIT mail servers to send me a copy of the posts. I also don't receive PSWD reset emails. Anyone know who I can talk to? -Dennis This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From dennis at thenose.net Thu Jan 8 17:21:32 2009 From: dennis at thenose.net (Dennis Dayman) Date: Thu, 8 Jan 2009 18:21:32 -0500 Subject: List Help In-Reply-To: <58174FA985B92A42B9E3142C4DD2CC0402EDC2EE@PRVPVSMAIL07.corp.twcable.com> References: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> <58174FA985B92A42B9E3142C4DD2CC0402EDC2EE@PRVPVSMAIL07.corp.twcable.com> Message-ID: cause nice people like you respond directly ;) -Dennis On Jan 8, 2009, at January 8,6:17 PM, Furr, Jeremy wrote: > If you can't see posts to the list or responses, why would you go to > the > list for help? > > > P Go Green! Print this email only when necessary. Thank you for > helping Time Warner Cable be environmentally responsible. > > > -----Original Message----- > From: Dennis Dayman [mailto:dennis at thenose.net] > Sent: Thursday, January 08, 2009 5:48 PM > To: Nanog > Subject: List Help > > So I apologize for that test, but I can no longer see posts to the > list. I can send to the list, but I don't get a copy of my posts or > anyone else's. My MTA is not blocking anything nor does it ever get a > connection from MERIT mail servers to send me a copy of the posts. I > also don't receive PSWD reset emails. > > Anyone know who I can talk to? > > -Dennis > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. From jzp-sc at rsuc.gweep.net Thu Jan 8 18:50:05 2009 From: jzp-sc at rsuc.gweep.net (Joe Provo) Date: Thu, 8 Jan 2009 19:50:05 -0500 Subject: [NANOG-announce] New Year NANOG 45 Reminders Message-ID: <20090109005005.GA9264@gweep.net> Happy New Year, NANOGers! I hope you all had a good [operationally quiet] end to 2008, and look forward to 2009 along with this January's meeting in the Dominican Republic. Registered NANOG45 attendees will get further updates sent to the , so please do subscribe to it if you had opted out at the time of registration, either by mailing or dropping http://mailman.nanog.org/mailman/listinfo/nanog-attendee into your web browser. We have been working through our generous host Terremark with the Dominican Republic's government to make entry a smooth process. The NANOG Program Committee has once again provided an excellent agenda (http://nanog.org/meetings/nanog45/agenda.php) for the conference. Our sponsors (http://nanog.org/meetings/nanog45/sponsors.php) have also received assistance with customs issues, and are ready to meet and talk with you, our clued attendees. Should you need a formal Letter of Invitation, please contact Merit staff at . Information regarding entrance and exit requirements (with links to official DR sites) are available on the meeting website (see http://www.nanog.org/meetings/nanog45/entry.php). For those still sorting out their travel, be aware that the registration fee will increase on January 16 (see https://nanog.merit.edu/registration/). Flight costs are about the same as domestic travel within the US, and the hotel rates are less than many of our other locations, but the NANOG group rate ends January 9 (see http://www.nanog.org/meetings/nanog45/hotel.php), so if you haven't booked yet, time is of the essence. Merit staff and members of the Steering, Program and Mailing List Committees are all working hard to support the NANOG community. As always, we encourage you to send any questions or concerns via email, or by voice at Merit 1.734.527.5700. Looking forward to seeing you there! Joe Provo SC Chair -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mdavids at forfun.net Fri Jan 9 03:48:41 2009 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Fri, 9 Jan 2009 10:48:41 +0100 (CET) Subject: Looking for 'websitewelcome.com' contact Message-ID: Hi, Could anyone responsible for ns[12].websitewelcome.com please contact me off-list? Or, can anyone give me a good pointer on how to contact the technical staff of websitewelcome.com? Thank you so much, -- Marco Davids From cidr-report at potaroo.net Fri Jan 9 05:00:07 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Jan 2009 22:00:07 +1100 (EST) Subject: BGP Update Report Message-ID: <200901091100.n09B07SS046812@wattle.apnic.net> BGP Update Report Interval: 08-Dec-08 -to- 08-Jan-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35805 220394 4.0% 792.8 -- UTG-AS United Telecom AS 2 - AS4323 114511 2.1% 26.9 -- TWTC - tw telecom holdings, inc. 3 - AS209 74238 1.3% 24.5 -- ASN-QWEST - Qwest Communications Corporation 4 - AS9583 65350 1.2% 53.0 -- SIFY-AS-IN Sify Limited 5 - AS8452 45626 0.8% 27.7 -- TEDATA TEDATA 6 - AS24863 43186 0.8% 62.0 -- LINKdotNET-AS 7 - AS17488 41723 0.8% 26.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 8 - AS17974 39962 0.7% 81.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS4755 32644 0.6% 26.7 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 10 - AS29571 32463 0.6% 255.6 -- CITelecom-AS 11 - AS6458 29885 0.5% 74.5 -- Telgua 12 - AS5237 28515 0.5% 648.1 -- DODNIC - DoD Network Information Center 13 - AS7643 27380 0.5% 25.9 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 14 - AS20115 27196 0.5% 12.1 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS29372 25880 0.5% 281.3 -- SFR-NETWORK SFR 16 - AS6389 25651 0.5% 5.8 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 17 - AS1221 25004 0.5% 35.0 -- ASN-TELSTRA Telstra Pty Ltd 18 - AS30969 24251 0.4% 3031.4 -- TAN-NET TransAfrica Networks 19 - AS18101 24157 0.4% 29.9 -- RIL-IDC Reliance Infocom Ltd Internet Data Centre, 20 - AS7545 23398 0.4% 34.2 -- TPG-INTERNET-AP TPG Internet Pty Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 6252 0.1% 6252.0 -- ALON-USA - ALON USA, LP 2 - AS30306 20288 0.4% 5072.0 -- AfOL-Sz-AS 3 - AS30969 24251 0.4% 3031.4 -- TAN-NET TransAfrica Networks 4 - AS48129 2828 0.1% 2828.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 5 - AS32398 15709 0.3% 2618.2 -- REALNET-ASN-1 6 - AS29282 7123 0.1% 2374.3 -- EMENTOR-AS Enfo Oyj 7 - AS28194 6826 0.1% 2275.3 -- 8 - AS8599 2075 0.0% 2075.0 -- Ulyanovsk State University Network 9 - AS32753 1915 0.0% 1915.0 -- GLOBEOP-FINANCIAL-SERVICES-NYC1 - GlobeOp Financial Services 10 - AS23917 1774 0.0% 1774.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 11 - AS19017 1568 0.0% 1568.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 12 - AS41007 7539 0.1% 1507.8 -- CTCASTANA CTC ASTANA, KZ 13 - AS8668 5984 0.1% 854.9 -- TELONE-AS TelOne Zimbabwe P/L 14 - AS11816 13666 0.2% 854.1 -- SetarNet 15 - AS5691 10481 0.2% 806.2 -- MITRE-AS-5 - The MITRE Corporation 16 - AS35805 220394 4.0% 792.8 -- UTG-AS United Telecom AS 17 - AS16214 4584 0.1% 764.0 -- CERIST 18 - AS3944 1948 0.0% 649.3 -- PARTAN-LAB - Partan & Partan 19 - AS5237 28515 0.5% 648.1 -- DODNIC - DoD Network Information Center 20 - AS47123 5777 0.1% 641.9 -- MEDNAUTILUS Mednautilus Autonomous System TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 41.204.2.0/24 15651 0.3% AS32398 -- REALNET-ASN-1 2 - 210.214.151.0/24 15049 0.3% AS9583 -- SIFY-AS-IN Sify Limited 3 - 199.2.119.0/24 13542 0.2% AS11816 -- SetarNet 4 - 196.27.104.0/21 11944 0.2% AS30969 -- TAN-NET TransAfrica Networks 5 - 196.27.108.0/22 11883 0.2% AS30969 -- TAN-NET TransAfrica Networks 6 - 192.12.120.0/24 10434 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 7 - 221.134.222.0/24 10247 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 212.85.223.0/24 10121 0.2% AS30306 -- AfOL-Sz-AS 9 - 212.85.220.0/24 10119 0.2% AS30306 -- AfOL-Sz-AS 10 - 118.95.130.0/23 9709 0.2% AS9583 -- SIFY-AS-IN Sify Limited 11 - 195.189.68.0/24 7020 0.1% AS41007 -- CTCASTANA CTC ASTANA, KZ 12 - 221.135.80.0/24 6787 0.1% AS9583 -- SIFY-AS-IN Sify Limited 13 - 65.214.174.0/24 6252 0.1% AS30287 -- ALON-USA - ALON USA, LP 14 - 89.4.131.0/24 5979 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 15 - 222.255.51.64/26 5728 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - 91.68.238.0/24 5326 0.1% AS29372 -- SFR-NETWORK SFR 17 - 64.162.116.0/24 5277 0.1% AS5033 -- ISW - Internet Specialties West Inc. 18 - 91.68.242.0/24 5181 0.1% AS29372 -- SFR-NETWORK SFR 19 - 205.106.88.0/22 4421 0.1% AS5237 -- DODNIC - DoD Network Information Center 20 - 189.90.80.0/20 4279 0.1% AS28194 -- Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 9 05:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Jan 2009 22:00:03 +1100 (EST) Subject: The Cidr Report Message-ID: <200901091100.n09B03FU046804@wattle.apnic.net> This report has been generated at Fri Jan 9 21:13:41 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 Prefixes CIDR Agg 02-01-09 283623 175637 03-01-09 283602 175700 04-01-09 283670 175635 05-01-09 283909 176295 06-01-09 283855 176406 07-01-09 283951 176430 08-01-09 284121 176471 09-01-09 284392 176424 AS Summary 30340 Number of ASes in routing system 12915 Number of ASes announcing only one prefix 4389 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89820672 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'). --- 09Jan09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 284312 176403 107909 38.0% All ASes AS6389 4389 357 4032 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4204 1728 2476 58.9% TWTC - tw telecom holdings, inc. AS209 2845 1268 1577 55.4% ASN-QWEST - Qwest Communications Corporation AS4766 1755 493 1262 71.9% KIXS-AS-KR Korea Telecom AS17488 1482 358 1124 75.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1181 217 964 81.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 996 63 933 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1407 523 884 62.8% Uninet S.A. de C.V. AS1785 1706 841 865 50.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS11492 1232 466 766 62.2% CABLEONE - CABLE ONE, INC. AS2386 1582 902 680 43.0% INS-AS - AT&T Data Communications Services AS19262 922 244 678 73.5% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 781 141 640 81.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1110 473 637 57.4% LEVEL3 Level 3 Communications AS6478 1192 604 588 49.3% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1060 501 559 52.7% COVAD - Covad Communications Co. AS17908 599 69 530 88.5% TCISL Tata Communications AS2706 545 23 522 95.8% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS7545 682 172 510 74.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 624 157 467 74.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 593 133 460 77.6% CANET-ASN-4 - Bell Aliant AS17676 525 65 460 87.6% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 127 438 77.5% VTR BANDA ANCHA S.A. AS7018 1430 993 437 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS20115 1852 1417 435 23.5% CHARTER-NET-HKY-NC - Charter Communications AS4134 896 463 433 48.3% CHINANET-BACKBONE No.31,Jin-rong Street AS9443 503 81 422 83.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS24560 659 239 420 63.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 694 278 416 59.9% LGNET-AS-KR LG CNS AS7011 937 541 396 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 38948 13937 25011 64.2% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.223.112.0/22 AS5713 SAIX-NET 41.223.132.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.133.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.134.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.135.0/24 AS12491 IPPLANET-AS IPPlanet 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 95.192.0.0/12 AS3301 TELIANET-SWEDEN TeliaNet Sweden 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.9.30.0/24 AS41457 A1-AS A1 Ltd. 193.9.31.0/24 AS41457 A1-AS A1 Ltd. 193.23.143.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.181.205.0/24 AS19778 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.68.96.0/19 AS17657 IBM-HK-AP e-Business Hosting Services 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.131.17.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.131.18.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.131.19.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.131.20.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.131.21.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.131.22.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.131.23.0/24 AS4314 XFONE-ASN1 - XFone USA, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From rsk at gsp.org Fri Jan 9 05:29:15 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 9 Jan 2009 06:29:15 -0500 Subject: List Help In-Reply-To: <4966890E.90404@foobar.org> References: <3B2E1B33-CC01-405A-BEF5-27D1CF7F1222@thenose.net> <4966890E.90404@foobar.org> Message-ID: <20090109112915.GA3623@gsp.org> On Thu, Jan 08, 2009 at 11:15:26PM +0000, Nick Hilliard wrote: > As you've already found out, the most important thing when dealing with a > situation like this is to mail the list itself with a test message. If the > first one doesn't come through, it's considered quite acceptable to send a > couple of others, just to test out various mods at your end. It sounds like you're channelling Miss Mailers: Miss Mailers Answers Your Questions on Mailing Lists http://www.faqs.org/faqs/mail/miss-mailers ---Rsk From nanog at myzionetworks.com Fri Jan 9 06:55:27 2009 From: nanog at myzionetworks.com (Todd) Date: Fri, 9 Jan 2009 07:55:27 -0500 Subject: Looking for 'websitewelcome.com' contact In-Reply-To: References: Message-ID: <8B1506CD-F022-4662-9BE7-CD9AEF578F80@myzionetworks.com> Websitewelcome.com is hostgators reseller network. Contact Hostgator for issues with a websitewelcome.com server. On Jan 9, 2009, at 4:48 AM, "Marco Davids (Prive)" wrote: > Hi, > > Could anyone responsible for ns[12].websitewelcome.com please > contact me > off-list? > > Or, can anyone give me a good pointer on how to contact the technical > staff of websitewelcome.com? > > Thank you so much, > > -- > Marco Davids > > > From cscora at apnic.net Fri Jan 9 12:10:22 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Jan 2009 04:10:22 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200901091810.n09IAMRx011684@thyme.apnic.net> 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-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 Jan, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 276748 Prefixes after maximum aggregation: 132415 Deaggregation factor: 2.09 Unique aggregates announced to Internet: 135537 Total ASes present in the Internet Routing Table: 30275 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26332 Origin ASes announcing only one prefix: 12831 Transit ASes present in the Internet Routing Table: 3943 Transit-only ASes present in the Internet Routing Table: 92 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN (33868) 19 Prefixes from unregistered ASNs in the Routing Table: 493 Unregistered ASNs in the Routing Table: 182 Number of 32-bit ASNs allocated by the RIRs: 71 Prefixes from 32-bit ASNs in the Routing Table: 11 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 254 Number of addresses announced to Internet: 1981613920 Equivalent to 118 /8s, 29 /16s and 7 /24s Percentage of available address space announced: 53.5 Percentage of allocated address space announced: 63.2 Percentage of available address space allocated: 84.6 Percentage of address space in use by end-sites: 75.1 Total number of prefixes smaller than registry allocations: 135621 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 64123 Total APNIC prefixes after maximum aggregation: 23155 APNIC Deaggregation factor: 2.77 Prefixes being announced from the APNIC address blocks: 60992 Unique aggregates announced from the APNIC address blocks: 27681 APNIC Region origin ASes present in the Internet Routing Table: 3503 APNIC Prefixes per ASN: 17.41 APNIC Region origin ASes announcing only one prefix: 955 APNIC Region transit ASes present in the Internet Routing Table: 538 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 394564832 Equivalent to 23 /8s, 132 /16s and 148 /24s Percentage of available APNIC address space announced: 78.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/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: 123262 Total ARIN prefixes after maximum aggregation: 64979 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92772 Unique aggregates announced from the ARIN address blocks: 35437 ARIN Region origin ASes present in the Internet Routing Table: 12709 ARIN Prefixes per ASN: 7.30 ARIN Region origin ASes announcing only one prefix: 4893 ARIN Region transit ASes present in the Internet Routing Table: 1217 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 405753632 Equivalent to 24 /8s, 47 /16s and 79 /24s Percentage of available ARIN address space announced: 78.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 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, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 61632 Total RIPE prefixes after maximum aggregation: 36822 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 57016 Unique aggregates announced from the RIPE address blocks: 38082 RIPE Region origin ASes present in the Internet Routing Table: 12474 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6561 RIPE Region transit ASes present in the Internet Routing Table: 1905 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 384010848 Equivalent to 22 /8s, 227 /16s and 138 /24s Percentage of available RIPE address space announced: 88.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22922 Total LACNIC prefixes after maximum aggregation: 5700 LACNIC Deaggregation factor: 4.02 Prefixes being announced from the LACNIC address blocks: 21035 Unique aggregates announced from the LACNIC address blocks: 11598 LACNIC Region origin ASes present in the Internet Routing Table: 1047 LACNIC Prefixes per ASN: 20.09 LACNIC Region origin ASes announcing only one prefix: 338 LACNIC Region transit ASes present in the Internet Routing Table: 172 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 59650432 Equivalent to 3 /8s, 142 /16s and 49 /24s Percentage of available LACNIC address space announced: 59.3 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4335 Total AfriNIC prefixes after maximum aggregation: 1363 AfriNIC Deaggregation factor: 3.18 Prefixes being announced from the AfriNIC address blocks: 4772 Unique aggregates announced from the AfriNIC address blocks: 2189 AfriNIC Region origin ASes present in the Internet Routing Table: 276 AfriNIC Prefixes per ASN: 17.29 AfriNIC Region origin ASes announcing only one prefix: 84 AfriNIC Region transit ASes present in the Internet Routing Table: 60 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC addresses announced to Internet: 13108480 Equivalent to 0 /8s, 200 /16s and 5 /24s Percentage of available AfriNIC address space announced: 26.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1649 6410 374 Korea Telecom (KIX) 17488 1482 104 100 Hathway IP Over Cable Interne 4755 1181 435 170 TATA Communications formerly 9583 1107 87 523 Sify Limited 4134 896 15977 361 CHINANET-BACKBONE 18101 782 168 30 Reliance Infocom Ltd Internet 4780 720 358 65 Digital United Inc. 9498 688 297 52 BHARTI BT INTERNET LTD. 7545 662 152 81 TPG Internet Pty Ltd 24560 659 224 180 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4389 3435 345 bellsouth.net, inc. 209 2847 4033 622 Qwest 20115 1852 1458 743 Charter Communications 1785 1711 718 158 PaeTec Communications, Inc. 4323 1614 1051 382 Time Warner Telecom 2386 1582 706 896 AT&T Data Communications Serv 7018 1429 5871 990 AT&T WorldNet Services 11492 1232 192 12 Cable One 6478 1191 298 444 AT&T Worldnet Services 3356 1108 10994 432 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 446 188 7 TEDATA 3292 436 1764 383 TDC Tele Danmark 12479 386 578 6 Uni2 Autonomous System 30890 386 85 198 SC Kappa Invexim SRL 3301 336 1669 303 TeliaNet Sweden 3320 332 7065 281 Deutsche Telekom AG 8866 330 109 22 Bulgarian Telecommunication C 3215 327 2857 96 France Telecom Transpac 29049 325 26 3 AzerSat LLC. 8551 304 287 35 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1406 2833 222 UniNet S.A. de C.V. 10620 698 151 58 TVCABLE BOGOTA 11830 671 299 9 Instituto Costarricense de El 22047 565 302 14 VTR PUNTO NET S.A. 7303 507 251 77 Telecom Argentina Stet-France 6471 429 86 40 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 409 118 72 Servicios Alestra S.A de C.V 28573 369 493 20 NET Servicos de Comunicao S.A 7738 360 730 27 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 591 72 41 LINKdotNET AS number 3741 270 857 227 The Internet Solution 20858 262 34 3 This AS will be used to conne 2018 239 215 140 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 126 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 5713 118 555 67 Telkom SA Ltd 33776 118 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4389 3435 345 bellsouth.net, inc. 209 2847 4033 622 Qwest 20115 1852 1458 743 Charter Communications 1785 1711 718 158 PaeTec Communications, Inc. 4766 1649 6410 374 Korea Telecom (KIX) 4323 1614 1051 382 Time Warner Telecom 2386 1582 706 896 AT&T Data Communications Serv 17488 1482 104 100 Hathway IP Over Cable Interne 7018 1429 5871 990 AT&T WorldNet Services 8151 1406 2833 222 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2847 2225 Qwest 1785 1711 1553 PaeTec Communications, Inc. 17488 1482 1382 Hathway IP Over Cable Interne 4766 1649 1275 Korea Telecom (KIX) 4323 1614 1232 Time Warner Telecom 11492 1232 1220 Cable One 8151 1406 1184 UniNet S.A. de C.V. 20115 1852 1109 Charter Communications 18566 1060 1050 Covad Communications 4755 1181 1011 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.223.112.0/22 5713 Telkom SA Ltd 41.223.132.0/24 12491 IPPlanet 41.223.133.0/24 12491 IPPlanet 41.223.134.0/24 12491 IPPlanet Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:20 /11:54 /12:159 /13:310 /14:561 /15:1101 /16:10300 /17:4531 /18:7788 /19:16707 /20:19620 /21:19250 /22:24350 /23:24760 /24:145115 /25:647 /26:822 /27:514 /28:95 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2866 4389 bellsouth.net, inc. 209 1588 2847 Qwest 4766 1384 1649 Korea Telecom (KIX) 17488 1267 1482 Hathway IP Over Cable Interne 2386 1261 1582 AT&T Data Communications Serv 11492 1200 1232 Cable One 1785 1170 1711 PaeTec Communications, Inc. 18566 1041 1060 Covad Communications 9583 967 1107 Sify Limited 20115 931 1852 Charter Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:174 12:2188 13:2 15:21 16:3 17:5 20:36 24:1106 32:54 38:533 40:96 41:1017 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:518 59:607 60:455 61:1112 62:1128 63:2007 64:3398 65:2459 66:3618 67:1446 68:654 69:2436 70:531 71:175 72:1589 73:7 74:1348 75:194 76:306 77:792 78:527 79:303 80:944 81:850 82:580 83:381 84:598 85:1069 86:399 87:641 88:352 89:1368 90:44 91:1837 92:306 93:1097 94:859 95:155 96:97 97:158 98:175 99:10 110:1 111:1 112:5 113:57 114:153 115:188 116:1114 117:464 118:247 119:603 120:129 121:713 122:920 123:494 124:868 125:1281 128:358 129:222 130:135 131:411 132:70 133:9 134:325 135:35 136:224 137:136 138:145 139:92 140:412 141:109 142:384 143:309 144:323 145:53 146:372 147:142 148:610 149:222 150:139 151:208 152:149 153:125 154:10 155:242 156:168 157:270 158:140 159:300 160:276 161:133 162:255 163:145 164:518 165:504 166:364 167:348 168:678 169:161 170:461 171:38 172:10 173:193 174:50 187:17 188:1 189:357 190:2498 192:5816 193:4182 194:3309 195:2666 196:1069 198:3692 199:3305 200:5507 201:1476 202:7820 203:8105 204:3931 205:2168 206:2333 207:2772 208:3803 209:3534 210:2744 211:1164 212:1551 213:1640 214:67 215:29 216:4541 217:1210 218:369 219:403 220:1231 221:464 222:296 End of report From nrauhauser at gmail.com Fri Jan 9 14:06:27 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Fri, 9 Jan 2009 15:06:27 -0500 Subject: Cogent haiku Message-ID: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> Cogent drops packets. Angry customers call. Twice. Admin writes haiku. From jbates at brightok.net Fri Jan 9 14:10:00 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 09 Jan 2009 14:10:00 -0600 Subject: ebay dropping asymmetric traffic? Message-ID: <4967AF18.4040606@brightok.net> Ever notice you can't reach routing peeps by phone anymore? I have a few networks which are routing out one provider and return another. Not general practice, but it's ended up that way. As of last night I've had reports flowing in of these networks unable to hit ebay. The other networks in that area which leave and return via the same route seem to be working, and the broken networks returned to operation status when we forced ebay traffic around the network to make the flows symmetrical. I've heard this is causing problems in other networks as well. Has anyone seen this? Any idea of the specifics? I'm almost tempted to believe it's some form of RPF on inbound traffic (the observed path was via their cox interconnect). Jack From sfischer1967 at gmail.com Fri Jan 9 17:12:16 2009 From: sfischer1967 at gmail.com (Steve Fischer) Date: Fri, 9 Jan 2009 18:12:16 -0500 Subject: Cogent haiku In-Reply-To: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> References: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> Message-ID: <02f601c972af$b73a8a00$25af9e00$@com> That is too funny! -----Original Message----- From: neal rauhauser [mailto:nrauhauser at gmail.com] Sent: Friday, January 09, 2009 3:06 PM To: nanog at nanog.org Subject: Cogent haiku Cogent drops packets. Angry customers call. Twice. Admin writes haiku. From sking at kingrst.com Fri Jan 9 17:43:27 2009 From: sking at kingrst.com (Steven King) Date: Fri, 09 Jan 2009 18:43:27 -0500 Subject: Cogent haiku In-Reply-To: <02f601c972af$b73a8a00$25af9e00$@com> References: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> <02f601c972af$b73a8a00$25af9e00$@com> Message-ID: <4967E11F.5050404@kingrst.com> LMAO thats great. I am so glad we don't peer with Cogent. Steve Fischer wrote: > That is too funny! > > -----Original Message----- > From: neal rauhauser [mailto:nrauhauser at gmail.com] > Sent: Friday, January 09, 2009 3:06 PM > To: nanog at nanog.org > Subject: Cogent haiku > > Cogent drops packets. > Angry customers call. Twice. > Admin writes haiku. > > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From mike.lyon at gmail.com Fri Jan 9 18:41:04 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 9 Jan 2009 16:41:04 -0800 Subject: Any ATT DNS admins out there? Message-ID: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> If so, would you mind hitting me up offlist? I have a few questions that i am unable to get answered through normal channels. Cheers, Mike From ge at linuxbox.org Fri Jan 9 21:48:18 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 9 Jan 2009 21:48:18 -0600 (CST) Subject: Cogent haiku In-Reply-To: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> References: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> Message-ID: hehe On Fri, 9 Jan 2009, neal rauhauser wrote: > Cogent drops packets. > Angry customers call. Twice. > Admin writes haiku. > From ge at linuxbox.org Fri Jan 9 21:50:49 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 9 Jan 2009 21:50:49 -0600 (CST) Subject: Cogent haiku In-Reply-To: <02f601c972af$b73a8a00$25af9e00$@com> References: <9515c62d0901091206p4ec25665nb012b4feec822fa0@mail.gmail.com> <02f601c972af$b73a8a00$25af9e00$@com> Message-ID: On Fri, 9 Jan 2009, Steve Fischer wrote: > That is too funny! He cheated by adding periods :P > -----Original Message----- > From: neal rauhauser [mailto:nrauhauser at gmail.com] > Sent: Friday, January 09, 2009 3:06 PM > To: nanog at nanog.org > Subject: Cogent haiku > > Cogent drops packets. > Angry customers call. Twice. > Admin writes haiku. > > From owen at delong.com Sat Jan 10 12:19:27 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Jan 2009 10:19:27 -0800 Subject: XO -- Plea for engineer to contact me Message-ID: <82293F66-38D5-45F2-850B-4A8C7CC52033@delong.com> I apologize to the list, but, I'm at my wits end. Can an engineer with clue PLEASE contact me regarding ticket 1781923. I cannot get past the phone operators to speak to an engineer about a misconfiguration on the XO side with my service. I don't know what's actually in the ticket, but, I'm not requesting a major configuration change. The BGP session _IS_ working, except XO is failing to accept a single prefix from us which XO assigned to us. The response I'm getting from customer care is not matching these facts. Thank you, Owen From lists at quux.de Sat Jan 10 12:37:02 2009 From: lists at quux.de (Jens Link) Date: Sat, 10 Jan 2009 19:37:02 +0100 Subject: generic attack on Cisco routers In-Reply-To: <20090105205452.21170083@cs.columbia.edu> (Steven M. Bellovin's message of "Mon\, 5 Jan 2009 20\:54\:52 -0500") References: <20090105205452.21170083@cs.columbia.edu> Message-ID: <87hc47ypm9.fsf@laphroiag.quux.de> "Steven M. Bellovin" writes: > http://www.theregister.co.uk/2009/01/05/cisco_router_hijacking/ There's also a video of the talk at 25c3: cheers, Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From EMort at xo.com Sat Jan 10 13:38:05 2009 From: EMort at xo.com (Mort, Eric) Date: Sat, 10 Jan 2009 13:38:05 -0600 Subject: XO -- Plea for engineer to contact me In-Reply-To: <82293F66-38D5-45F2-850B-4A8C7CC52033@delong.com> References: <82293F66-38D5-45F2-850B-4A8C7CC52033@delong.com> Message-ID: <2E209CF1536C0C42A260E215DA598E9605C53566@TXPLANMAIL02.mail.inthosts.net> Took a gander and you're not stipping private ASN space before sending us your announcement and as such your announcement is failing on our AS-PATH filter. Fix that and it work: CVR1.SanJose2-CA# sho ip bgp neigh 207.88.187.162 received-ro BGP table version is 18060975, local router ID is 65.106.7.214 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 64.245.4.128/25 207.88.187.162 0 7014 i * 64.245.6.128/25 207.88.187.162 0 7014 64512 64513 i CVR1.SanJose2-CA# sho ip bgp neigh 207.88.187.166 received-ro BGP table version is 18061137, local router ID is 65.106.7.214 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 64.245.4.128/25 207.88.187.166 0 7014 i * 64.245.6.128/25 207.88.187.166 0 7014 64512 64513 i Thanks, Eric J. Mort Sr. Manager - IP Operations Desk - 314-787-7826 Cell - 314.486-9057 emort at xo.com -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Saturday, January 10, 2009 12:19 PM To: NANOG list Subject: XO -- Plea for engineer to contact me I apologize to the list, but, I'm at my wits end. Can an engineer with clue PLEASE contact me regarding ticket 1781923. I cannot get past the phone operators to speak to an engineer about a misconfiguration on the XO side with my service. I don't know what's actually in the ticket, but, I'm not requesting a major configuration change. The BGP session _IS_ working, except XO is failing to accept a single prefix from us which XO assigned to us. The response I'm getting from customer care is not matching these facts. Thank you, Owen From gds at gds.best.vwh.net Sun Jan 11 01:40:20 2009 From: gds at gds.best.vwh.net (Greg Skinner) Date: Sun, 11 Jan 2009 07:40:20 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: ; from blakjak@blakjak.net on Fri, Dec 26, 2008 at 08:01:59PM +1300 References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> Message-ID: <20090111074020.A77331@gds.best.vwh.net> On Fri, Dec 26, 2008 at 08:01:59PM +1300, Mark Foster wrote: > On Fri, 26 Dec 2008, Martin Hannigan wrote: > > On Thu, Dec 25, 2008 at 6:00 PM, Frank Bulk - iName.com > > wrote: > > > >> I don't think there would be a concern about off-shore support if we > >> couldn't tell it was "off-shore". > > > > You can't tell most of the time. > > > > The point that is relevant operationally is that off shoring can be a solid > > method to help significantly reduce costs. It can work easier for some > > functions than others. Level 1/Tier1 support seems like an excellent > > candidate for off shoring and I think that the measure is still quality of > > service from the provider verses if they off shore or not. > > > > Just my humble opinion. > > > > Hi Martin, > Seemingly a rational viewpoint (what, on NANOG? Surely not!) but the > problem with the gradual depletion of Level/Tier 1 support environments in > your home country is the (eventual) gradual depletion of expertise > available to the higher levels. > > A hellovalot of the clueful engineers that i've come to know over the past > few years are people who started off on Helpdesks, and moved up the tiers, > to finally land in NOC type slots and from there to engineering and > design, perhaps skipping some or all of the 'tiers'... but you've gotta > start somewhere. > > Aside from the typical Degree or Diploma that tertiary outfits offer, > there's not a lot of good ways to 'break in' to the Network and Systems > Operations communities other than good ol experience, > working-from-the-bottom-up. > > So as you move your Tier 1's offshore, you cut off the channel by which > people can gain experience and move on up the chain... > > (The issues around the advantages from a cultural sense of having access > to people who actually know your environs, current events, etc, are > probably far more obvious..) > > Could offshoring be considered a 'short term fix' and be hindering our > ability to employ clooful operators in a few years time? (else, are we > limiting ourselves to employing immigrants from 'offshore locations' > because we don't locally build the right experience?) > > Mark. The fact that work is offshored also acts as a disincentive to people who might otherwise enter the field. Instead, they pursue work that is much less likely to be offshored. Witness the increase of healthcare workers in the US who might have otherwise entered various engineering professions, but do not, because they are concerned that they may not keep their engineering jobs. --gregbo From nrauhauser at gmail.com Sun Jan 11 20:59:23 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Sun, 11 Jan 2009 21:59:23 -0500 Subject: Cogent Haiku v2.0 Message-ID: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> Cogent makes a mess My phone rings and rings Unfornicate this! From aimbrock at gmail.com Mon Jan 12 00:11:50 2009 From: aimbrock at gmail.com (Aaron Imbrock) Date: Sun, 11 Jan 2009 22:11:50 -0800 Subject: No subject Message-ID: <000301c9747c$a9087400$fb195c00$@com> Stop From neito at nerdramblingz.com Mon Jan 12 00:12:15 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Mon, 12 Jan 2009 01:12:15 -0500 Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: Hammertime. On Mon, Jan 12, 2009 at 1:11 AM, Aaron Imbrock wrote: > Stop > > > > From wschultz at bsdboy.com Mon Jan 12 00:15:16 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Sun, 11 Jan 2009 22:15:16 -0800 Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: <37258AC7-17AA-486D-9A47-604EB45DE233@bsdboy.com> It's hammer time On Jan 11, 2009, at 10:11 PM, Aaron Imbrock wrote: > Stop > > > From ops.lists at gmail.com Mon Jan 12 03:24:52 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Jan 2009 17:24:52 +0800 Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: On Mon, Jan 12, 2009 at 2:11 PM, Aaron Imbrock wrote: > Stop Do not pass Go. Do not collect $200. -- Suresh Ramasubramanian (ops.lists at gmail.com) From thegameiam at yahoo.com Mon Jan 12 06:13:20 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 12 Jan 2009 04:13:20 -0800 (PST) Subject: In-Reply-To: Message-ID: <218765.18576.qm@web31802.mail.mud.yahoo.com> Collaborate & Listen http://xkcd.com/210/ David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Mon, 1/12/09, Nathan Malynn wrote: > From: Nathan Malynn > Subject: Re: > To: "Aaron Imbrock" > Cc: NANOG at nanog.org > Date: Monday, January 12, 2009, 1:12 AM > Hammertime. > > On Mon, Jan 12, 2009 at 1:11 AM, Aaron Imbrock > wrote: > > Stop > > > > > > > > From kratzers at pa.net Mon Jan 12 07:21:31 2009 From: kratzers at pa.net (Stephen Kratzer) Date: Mon, 12 Jan 2009 08:21:31 -0500 Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: <200901120821.32240.kratzers@pa.net> On Monday 12 January 2009 01:11:50 Aaron Imbrock wrote: > Stop in the name of love From scott.berkman at reignmaker.net Mon Jan 12 08:31:35 2009 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Mon, 12 Jan 2009 09:31:35 -0500 (EST) Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> , drop, and roll? -----Original Message----- From: Aaron Imbrock [mailto:aimbrock at gmail.com] Sent: Monday, January 12, 2009 1:12 AM To: NANOG at nanog.org Subject: Stop From a.harrowell at gmail.com Mon Jan 12 08:39:45 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 12 Jan 2009 14:39:45 +0000 Subject: In-Reply-To: <-2927819189854721054@unknownmsgid> References: <000301c9747c$a9087400$fb195c00$@com> <-2927819189854721054@unknownmsgid> Message-ID: > Stop Making sense? From yahoo at jimpop.com Mon Jan 12 08:42:25 2009 From: yahoo at jimpop.com (Jim Popovitch) Date: Mon, 12 Jan 2009 09:42:25 -0500 Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: <7ff145960901120642l67171731oae1f129cc0ec536@mail.gmail.com> > Stop the insanity. (please) From Ray.Sanders at VillageVoiceMedia.com Mon Jan 12 08:45:44 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Mon, 12 Jan 2009 07:45:44 -0700 Subject: In-Reply-To: <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> References: <000301c9747c$a9087400$fb195c00$@com> <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> Message-ID: <1231771544.3628.8.camel@artoo.vvmedia.com> Draggin my heart around. > > -----Original Message----- > From: Aaron Imbrock [mailto:aimbrock at gmail.com] > Sent: Monday, January 12, 2009 1:12 AM > To: NANOG at nanog.org > Subject: > > Stop > > > > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From ksimpson at mailchannels.com Mon Jan 12 11:26:09 2009 From: ksimpson at mailchannels.com (Ken Simpson) Date: Mon, 12 Jan 2009 09:26:09 -0800 Subject: In-Reply-To: <1231771544.3628.8.camel@artoo.vvmedia.com> References: <000301c9747c$a9087400$fb195c00$@com> <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> <1231771544.3628.8.camel@artoo.vvmedia.com> Message-ID: <8F0A187C-E625-40E1-80B5-E7C3A3636E06@mailchannels.com> On 12-Jan-09, at 6:45 AM, Ray Sanders wrote: > Draggin my heart around. > >> >> -----Original Message----- >> From: Aaron Imbrock [mailto:aimbrock at gmail.com] >> Sent: Monday, January 12, 2009 1:12 AM >> To: NANOG at nanog.org >> Subject: >> >> Stop >> >> >> >> > -- > "Prediction is very difficult, especially about the future." Niels > Bohr > -- > Ray Sanders > Linux Administrator > Village Voice Media > Office: 602-744-6547 > Cell: 602-300-4344 > > -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From Jay.Murphy at state.nm.us Mon Jan 12 11:25:21 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 12 Jan 2009 10:25:21 -0700 Subject: In-Reply-To: <1231771544.3628.8.camel@artoo.vvmedia.com> References: <000301c9747c$a9087400$fb195c00$@com><004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> <1231771544.3628.8.camel@artoo.vvmedia.com> Message-ID: around the world in 80 days... Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Ray Sanders [mailto:Ray.Sanders at VillageVoiceMedia.com] Sent: Monday, January 12, 2009 7:46 AM To: NANOG at nanog.org Subject: Re: RE: Draggin my heart around. > > -----Original Message----- > From: Aaron Imbrock [mailto:aimbrock at gmail.com] > Sent: Monday, January 12, 2009 1:12 AM > To: NANOG at nanog.org > Subject: > > Stop > > > > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From Jay.Murphy at state.nm.us Mon Jan 12 11:41:28 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 12 Jan 2009 10:41:28 -0700 Subject: Cogent Haiku v2.0 In-Reply-To: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> Message-ID: NANOG is too cool. Rhyming with net engineers. Poet don't know it. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: neal rauhauser [mailto:nrauhauser at gmail.com] Sent: Sunday, January 11, 2009 7:59 PM To: nanog at nanog.org Subject: Cogent Haiku v2.0 Cogent makes a mess My phone rings and rings Unfornicate this! ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From zaid at zaidali.com Mon Jan 12 11:47:00 2009 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 12 Jan 2009 09:47:00 -0800 (PST) Subject: recommendation for SIP integration In-Reply-To: <14281190.7211231782274652.JavaMail.zaid@turing-2.local> Message-ID: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> Hi, I am looking for a solution where I can tie a US number to a SIP solution. Has anyone had experience with this and if so can you make some recommendations? Zaid From jeffrey.lyon at blacklotus.net Mon Jan 12 11:48:02 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 12 Jan 2009 12:48:02 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> Message-ID: <16720fe00901120948w6d3b948fub4d1842ab52e6b1@mail.gmail.com> The XO version: XO is low cost The cabinets had no power Service was useless Jeff On Mon, Jan 12, 2009 at 12:41 PM, Murphy, Jay, DOH wrote: > NANOG is too cool. > Rhyming with net engineers. > Poet don't know it. > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fe, New Mexico 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." > > > > > > > -----Original Message----- > From: neal rauhauser [mailto:nrauhauser at gmail.com] > Sent: Sunday, January 11, 2009 7:59 PM > To: nanog at nanog.org > Subject: Cogent Haiku v2.0 > > Cogent makes a mess > My phone rings and rings > Unfornicate this! > > ______________________________________________________________________ > This inbound email has been scanned by the MessageLabs Email Security > System. > ______________________________________________________________________ > > > Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From ddunkin at netos.net Mon Jan 12 11:49:39 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Mon, 12 Jan 2009 09:49:39 -0800 Subject: Cogent Haiku v2.0 References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> Customers thank me I will not stoop much lower Pay dirt for transit -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, January 12, 2009 09:41 To: neal rauhauser; nanog at nanog.org Subject: RE: Cogent Haiku v2.0 NANOG is too cool. Rhyming with net engineers. Poet don't know it. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: neal rauhauser [mailto:nrauhauser at gmail.com] Sent: Sunday, January 11, 2009 7:59 PM To: nanog at nanog.org Subject: Cogent Haiku v2.0 Cogent makes a mess My phone rings and rings Unfornicate this! ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From Jay.Murphy at state.nm.us Mon Jan 12 11:51:14 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 12 Jan 2009 10:51:14 -0700 Subject: Cogent Haiku v2.0 In-Reply-To: <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> Message-ID: good stuff Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Darryl Dunkin [mailto:ddunkin at netos.net] Sent: Monday, January 12, 2009 10:50 AM To: Murphy, Jay, DOH; neal rauhauser; nanog at nanog.org Subject: RE: Cogent Haiku v2.0 Customers thank me I will not stoop much lower Pay dirt for transit -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, January 12, 2009 09:41 To: neal rauhauser; nanog at nanog.org Subject: RE: Cogent Haiku v2.0 NANOG is too cool. Rhyming with net engineers. Poet don't know it. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: neal rauhauser [mailto:nrauhauser at gmail.com] Sent: Sunday, January 11, 2009 7:59 PM To: nanog at nanog.org Subject: Cogent Haiku v2.0 Cogent makes a mess My phone rings and rings Unfornicate this! ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From mob at bartzfamily.net Mon Jan 12 11:54:15 2009 From: mob at bartzfamily.net (Mike Bartz) Date: Mon, 12 Jan 2009 12:54:15 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> Message-ID: <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> I like the haiku! On a serious note, we are considering getting a connection from Cogent. We currently have connections to at&t, Level 3 and TW Telecom. The low cost and high number of peer AS number's seems appealing to us. Every carrier has its issues, so I don't know what to make of the apparent negativity that I am seeing in these haiku threads. I am looking for some first hand experiences to help me make this decision. Thanks for any assistance! Mike On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: > Cogent makes a mess > My phone rings and rings > Unfornicate this! > -- Mike Bartz mob at bartzfamily.net From joshpotter at gmail.com Mon Jan 12 11:55:03 2009 From: joshpotter at gmail.com (Josh Potter) Date: Mon, 12 Jan 2009 11:55:03 -0600 Subject: Cogent Haiku v2.0 In-Reply-To: <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> Message-ID: <4a64e2f70901120955g70989e5cw95e39b97aec0d787@mail.gmail.com> Cisco 7k nodes Cascading VIP card failures Reload the router On Mon, Jan 12, 2009 at 11:49 AM, Darryl Dunkin wrote: > Customers thank me > I will not stoop much lower > Pay dirt for transit > > -----Original Message----- > From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] > Sent: Monday, January 12, 2009 09:41 > To: neal rauhauser; nanog at nanog.org > Subject: RE: Cogent Haiku v2.0 > > NANOG is too cool. > Rhyming with net engineers. > Poet don't know it. > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fe, New Mexico 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." > > > > > > > -----Original Message----- > From: neal rauhauser [mailto:nrauhauser at gmail.com] > Sent: Sunday, January 11, 2009 7:59 PM > To: nanog at nanog.org > Subject: Cogent Haiku v2.0 > > Cogent makes a mess > My phone rings and rings > Unfornicate this! > > ______________________________________________________________________ > This inbound email has been scanned by the MessageLabs Email Security > System. > ______________________________________________________________________ > > > Confidentiality Notice: This e-mail, including all attachments is for > the sole use of the intended recipient(s) and may contain confidential > and privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited unless specifically provided under the New > Mexico Inspection of Public Records Act. If you are not the intended > recipient, please contact the sender and destroy all copies of this > message. -- This email has been scanned by the Sybari - Antigen Email > System. > > > > > > -- Josh Potter From rcorbin at traffiq.com Mon Jan 12 11:55:13 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Mon, 12 Jan 2009 11:55:13 -0600 Subject: Cogent Haiku v2.0 In-Reply-To: <16720fe00901120948w6d3b948fub4d1842ab52e6b1@mail.gmail.com> Message-ID: Net admins are bored Nanog lists run wild Useless spam blows up phone :) -r -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: Monday, January 12, 2009 12:48 PM To: Murphy, Jay, DOH Cc: nanog at nanog.org Subject: Re: Cogent Haiku v2.0 The XO version: XO is low cost The cabinets had no power Service was useless Jeff On Mon, Jan 12, 2009 at 12:41 PM, Murphy, Jay, DOH wrote: > NANOG is too cool. > Rhyming with net engineers. > Poet don't know it. > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fe, New Mexico 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." > > > > > > > -----Original Message----- > From: neal rauhauser [mailto:nrauhauser at gmail.com] > Sent: Sunday, January 11, 2009 7:59 PM > To: nanog at nanog.org > Subject: Cogent Haiku v2.0 > > Cogent makes a mess > My phone rings and rings > Unfornicate this! > > ______________________________________________________________________ > This inbound email has been scanned by the MessageLabs Email Security > System. > ______________________________________________________________________ > > > Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From Jay.Murphy at state.nm.us Mon Jan 12 11:57:29 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 12 Jan 2009 10:57:29 -0700 Subject: Cogent Haiku v2.0 In-Reply-To: <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> Message-ID: Level 3 has gear. Bleeding edge technology. Get huge pipes right now. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Mike Bartz [mailto:mob at bartzfamily.net] Sent: Monday, January 12, 2009 10:54 AM To: neal rauhauser Cc: nanog at nanog.org Subject: Re: Cogent Haiku v2.0 I like the haiku! On a serious note, we are considering getting a connection from Cogent. We currently have connections to at&t, Level 3 and TW Telecom. The low cost and high number of peer AS number's seems appealing to us. Every carrier has its issues, so I don't know what to make of the apparent negativity that I am seeing in these haiku threads. I am looking for some first hand experiences to help me make this decision. Thanks for any assistance! Mike On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: > Cogent makes a mess > My phone rings and rings > Unfornicate this! > -- Mike Bartz mob at bartzfamily.net ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From randy.whitney at verizonbusiness.com Mon Jan 12 11:59:16 2009 From: randy.whitney at verizonbusiness.com (Randy Whitney) Date: Mon, 12 Jan 2009 12:59:16 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: <4a64e2f70901120955g70989e5cw95e39b97aec0d787@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> <4a64e2f70901120955g70989e5cw95e39b97aec0d787@mail.gmail.com> Message-ID: <496B84F4.2020508@verizonbusiness.com> All... Please stop this off-topic WOB. -- Randy. Josh Potter wrote: > Cisco 7k nodes > Cascading VIP card failures > Reload the router > > On Mon, Jan 12, 2009 at 11:49 AM, Darryl Dunkin wrote: > >> Customers thank me >> I will not stoop much lower >> Pay dirt for transit >> >> -----Original Message----- >> From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] >> Sent: Monday, January 12, 2009 09:41 >> To: neal rauhauser; nanog at nanog.org >> Subject: RE: Cogent Haiku v2.0 >> >> NANOG is too cool. >> Rhyming with net engineers. >> Poet don't know it. >> >> >> Jay Murphy >> IP Network Specialist >> NM Department of Health >> ITSD - IP Network Operations >> Santa Fe, New Mexico 87502 >> Bus. Ph.: 505.827.2851 >> >> "We move the information that moves your world." >> >> >> >> >> >> >> -----Original Message----- >> From: neal rauhauser [mailto:nrauhauser at gmail.com] >> Sent: Sunday, January 11, 2009 7:59 PM >> To: nanog at nanog.org >> Subject: Cogent Haiku v2.0 >> >> Cogent makes a mess >> My phone rings and rings >> Unfornicate this! >> >> ______________________________________________________________________ >> This inbound email has been scanned by the MessageLabs Email Security >> System. >> ______________________________________________________________________ >> >> >> Confidentiality Notice: This e-mail, including all attachments is for >> the sole use of the intended recipient(s) and may contain confidential >> and privileged information. Any unauthorized review, use, disclosure or >> distribution is prohibited unless specifically provided under the New >> Mexico Inspection of Public Records Act. If you are not the intended >> recipient, please contact the sender and destroy all copies of this >> message. -- This email has been scanned by the Sybari - Antigen Email >> System. >> >> >> >> >> >> > > From ksimpson at mailchannels.com Mon Jan 12 12:02:35 2009 From: ksimpson at mailchannels.com (Ken Simpson) Date: Mon, 12 Jan 2009 10:02:35 -0800 Subject: Cogent Haiku v2.0 In-Reply-To: <4a64e2f70901120955g70989e5cw95e39b97aec0d787@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF20BE88D7@MAIL.nosi.netos.com> <4a64e2f70901120955g70989e5cw95e39b97aec0d787@mail.gmail.com> Message-ID: > Cisco 7k nodes > Cascading VIP card failures > Reload the router McColo shuts down Spammers enjoy holiday .. and then recommence > On Mon, Jan 12, 2009 at 11:49 AM, Darryl Dunkin > wrote: > >> Customers thank me >> I will not stoop much lower >> Pay dirt for transit >> >> -----Original Message----- >> From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] >> Sent: Monday, January 12, 2009 09:41 >> To: neal rauhauser; nanog at nanog.org >> Subject: RE: Cogent Haiku v2.0 >> >> NANOG is too cool. >> Rhyming with net engineers. >> Poet don't know it. >> >> >> Jay Murphy >> IP Network Specialist >> NM Department of Health >> ITSD - IP Network Operations >> Santa Fe, New Mexico 87502 >> Bus. Ph.: 505.827.2851 >> >> "We move the information that moves your world." >> >> >> >> >> >> >> -----Original Message----- >> From: neal rauhauser [mailto:nrauhauser at gmail.com] >> Sent: Sunday, January 11, 2009 7:59 PM >> To: nanog at nanog.org >> Subject: Cogent Haiku v2.0 >> >> Cogent makes a mess >> My phone rings and rings >> Unfornicate this! >> >> ______________________________________________________________________ >> This inbound email has been scanned by the MessageLabs Email Security >> System. >> ______________________________________________________________________ >> >> >> Confidentiality Notice: This e-mail, including all attachments is for >> the sole use of the intended recipient(s) and may contain >> confidential >> and privileged information. Any unauthorized review, use, >> disclosure or >> distribution is prohibited unless specifically provided under the New >> Mexico Inspection of Public Records Act. If you are not the intended >> recipient, please contact the sender and destroy all copies of this >> message. -- This email has been scanned by the Sybari - Antigen Email >> System. >> >> >> >> >> >> > > > -- > Josh Potter -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From jeffrey.lyon at blacklotus.net Mon Jan 12 12:02:06 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 12 Jan 2009 13:02:06 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> Message-ID: <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> Mike, Aside from the occasional peering wars i've never had or witnessed any serious issues with Cogent. If you want some redundancy you might also try some other similarly priced providers like WBS Connect, HE, or BtN. Best regards, Jeff On Mon, Jan 12, 2009 at 12:54 PM, Mike Bartz wrote: > I like the haiku! On a serious note, we are considering getting a > connection from Cogent. We currently have connections to at&t, Level > 3 and TW Telecom. The low cost and high number of peer AS number's > seems appealing to us. Every carrier has its issues, so I don't know > what to make of the apparent negativity that I am seeing in these > haiku threads. I am looking for some first hand experiences to help > me make this decision. > > Thanks for any assistance! > > Mike > > > On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: >> Cogent makes a mess >> My phone rings and rings >> Unfornicate this! >> > > > > -- > Mike Bartz > mob at bartzfamily.net > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From aaron at wholesaleinternet.net Mon Jan 12 12:05:18 2009 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 12 Jan 2009 12:05:18 -0600 Subject: Cogent Haiku v2.0 In-Reply-To: References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> Message-ID: <056601c974e0$53994620$facbd260$@net> NANOG has admins They waste a lot of time now Maybe paid to much -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, January 12, 2009 11:57 AM To: Mike Bartz; neal rauhauser Cc: nanog at nanog.org Subject: RE: Cogent Haiku v2.0 Level 3 has gear. Bleeding edge technology. Get huge pipes right now. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Mike Bartz [mailto:mob at bartzfamily.net] Sent: Monday, January 12, 2009 10:54 AM To: neal rauhauser Cc: nanog at nanog.org Subject: Re: Cogent Haiku v2.0 I like the haiku! On a serious note, we are considering getting a connection from Cogent. We currently have connections to at&t, Level 3 and TW Telecom. The low cost and high number of peer AS number's seems appealing to us. Every carrier has its issues, so I don't know what to make of the apparent negativity that I am seeing in these haiku threads. I am looking for some first hand experiences to help me make this decision. Thanks for any assistance! Mike On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: > Cogent makes a mess > My phone rings and rings > Unfornicate this! > -- Mike Bartz mob at bartzfamily.net ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From jeffrey.lyon at blacklotus.net Mon Jan 12 12:02:06 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 12 Jan 2009 13:02:06 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> Message-ID: <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> Mike, Aside from the occasional peering wars i've never had or witnessed any serious issues with Cogent. If you want some redundancy you might also try some other similarly priced providers like WBS Connect, HE, or BtN. Best regards, Jeff On Mon, Jan 12, 2009 at 12:54 PM, Mike Bartz wrote: > I like the haiku! On a serious note, we are considering getting a > connection from Cogent. We currently have connections to at&t, Level > 3 and TW Telecom. The low cost and high number of peer AS number's > seems appealing to us. Every carrier has its issues, so I don't know > what to make of the apparent negativity that I am seeing in these > haiku threads. I am looking for some first hand experiences to help > me make this decision. > > Thanks for any assistance! > > Mike > > > On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: >> Cogent makes a mess >> My phone rings and rings >> Unfornicate this! >> > > > > -- > Mike Bartz > mob at bartzfamily.net > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From adam.young at mountaincable.on.ca Mon Jan 12 12:07:45 2009 From: adam.young at mountaincable.on.ca (Adam Young) Date: Mon, 12 Jan 2009 13:07:45 -0500 Subject: Cogent Considerations [was: Re: Cogent Haiku v2.0] In-Reply-To: <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> Message-ID: <496B86F1.60506@mountaincable.on.ca> Mike Bartz wrote: > I like the haiku! On a serious note, we are considering getting a > connection from Cogent. We currently have connections to at&t, Level > 3 and TW Telecom. The low cost and high number of peer AS number's > seems appealing to us. Every carrier has its issues, so I don't know > what to make of the apparent negativity that I am seeing in these > haiku threads. I am looking for some first hand experiences to help > me make this decision. > > Thanks for any assistance! Hey Mike, I wouldn't take my word for it but truthfully, you get what you pay for. Given you have other, more reliable transit, adding Cogent may be ok. I wouldn't rely on it for anything serious though. Hope this helps, -- Adam Young From sethm at rollernet.us Mon Jan 12 12:17:23 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Jan 2009 10:17:23 -0800 Subject: Cogent (was the poetry thread) In-Reply-To: <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> Message-ID: <496B8933.5050605@rollernet.us> Jeffrey Lyon wrote: > Mike, > > Aside from the occasional peering wars i've never had or witnessed any > serious issues with Cogent. If you want some redundancy you might also > try some other similarly priced providers like WBS Connect, HE, or > BtN. > (resend due to subject filter) Plus if you had direct connectivity to Cogent, their peering status with others wouldn't affect you anymore. Personally, I've seriously considered this as a reason to get a connection from Cogent. ~Seth From sethm at rollernet.us Mon Jan 12 12:15:43 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Jan 2009 10:15:43 -0800 Subject: Cogent Haiku v2.0 In-Reply-To: <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> Message-ID: <496B88CF.9090800@rollernet.us> Jeffrey Lyon wrote: > Mike, > > Aside from the occasional peering wars i've never had or witnessed any > serious issues with Cogent. If you want some redundancy you might also > try some other similarly priced providers like WBS Connect, HE, or > BtN. > Plus if you had direct connectivity to Cogent, their peering status with others wouldn't affect you anymore. Personally, I've seriously considered this as a reason to get a connection from Cogent. ~Seth From martin at airwire.ie Mon Jan 12 12:14:29 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 12 Jan 2009 18:14:29 +0000 Subject: Cogent Haiku v2.0 In-Reply-To: <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> Message-ID: <496B8885.4090506@airwire.ie> Jeffrey Lyon wrote: > Mike, > > Aside from the occasional peering wars i've never had or witnessed any > serious issues with Cogent. If you want some redundancy you might also > try some other similarly priced providers like WBS Connect, HE, or > BtN. I can second that. For the amount of money they charge, you get a very good deal and their techs are competent. However, due to peering wars, never rely on them alone. Any decent ISP should anyway at least have connections from n+1 carriers. Kind regards, Martin List-Petersen > > Best regards, Jeff > > On Mon, Jan 12, 2009 at 12:54 PM, Mike Bartz wrote: >> I like the haiku! On a serious note, we are considering getting a >> connection from Cogent. We currently have connections to at&t, Level >> 3 and TW Telecom. The low cost and high number of peer AS number's >> seems appealing to us. Every carrier has its issues, so I don't know >> what to make of the apparent negativity that I am seeing in these >> haiku threads. I am looking for some first hand experiences to help >> me make this decision. >> >> Thanks for any assistance! >> >> Mike >> >> >> On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: >>> Cogent makes a mess >>> My phone rings and rings >>> Unfornicate this! >>> >> >> >> -- >> Mike Bartz >> mob at bartzfamily.net >> >> > > > -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From jabley at hopcount.ca Mon Jan 12 12:25:52 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 12 Jan 2009 13:25:52 -0500 Subject: recommendation for SIP integration In-Reply-To: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> References: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> Message-ID: On 2009-01-12, at 12:47, Zaid Ali wrote: > Hi, I am looking for a solution where I can tie a US number to a SIP > solution. Has anyone had experience with this and if so can you make > some recommendations? I've used broadvoice before for personal telephony, and they were competent and asterisk-friendly, and seemed to have DIDs in many US LCAs. Joe From nanog at shankland.org Mon Jan 12 12:27:54 2009 From: nanog at shankland.org (Jim Shankland) Date: Mon, 12 Jan 2009 10:27:54 -0800 Subject: Cogent Considerations [was: Re: Cogent Haiku v2.0] In-Reply-To: <496B86F1.60506@mountaincable.on.ca> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <496B86F1.60506@mountaincable.on.ca> Message-ID: <496B8BAA.4090901@shankland.org> Adam Young wrote: > I wouldn't take my word for it but truthfully, you get what you pay for. > Given you have other, more reliable transit, adding Cogent may be ok. > I wouldn't rely on it for anything serious though. That has not been my experience. Peering wars have been an issue, but aside from that, they've been fine. (This is transit in San Francisco at the gigabit-plus level.) Jim Shankland From mdixon at nkc.org Mon Jan 12 12:40:42 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 12:40:42 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> I'm not entirely certain what is going on but has anyone noticed some strange announcements for 174.128.31.0/24? I received a hijack notice that my AS (AS11708) was announcing the above IP range. I verified that I was not when I started noticing some strange announcements for that range. Around 10 Am CST AS11911 was announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). Interestingly enough, ARIN indicates this is a part of range they have assigned for reachability testing. http://ws.arin.net/whois/?queryinput=174.128.31.0 This was from this AM around 10 AM CST: telnet at MLX4AP3#sho ip bgp route 174.128.31.0/24 Number of BGP Routes matching display condition : 1 Prefix Next Hop Metric LocPrf Weight Status 1 174.128.31.0/24 160.81.151.109 88 200 100 BE AS_PATH: 1239 2914 3130 11911 Last update to IP routing table: 2h24m33s, 1 path(s) installed: This was from this AM around 11:30 AM CST: Number of BGP Routes matching display condition : 1 Prefix Next Hop Metric LocPrf Weight Status 1 174.128.31.0/24 160.81.151.109 88 200 100 BE AS_PATH: 1239 2914 3130 12083 Last update to IP routing table: 0h0m43s, 1 path(s) installed: - Michienne Dixon liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 From joe at via.net Mon Jan 12 12:41:35 2009 From: joe at via.net (joe mcguckin) Date: Mon, 12 Jan 2009 10:41:35 -0800 Subject: Cogent (was the poetry thread) In-Reply-To: <496B8933.5050605@rollernet.us> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> Message-ID: <66EEA3A0-C00C-4F7C-A2AC-977705D9AD77@via.net> So, you're essentially getting paid peering from Cogent then ? Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Jan 12, 2009, at 10:17 AM, Seth Mattinen wrote: > Jeffrey Lyon wrote: >> Mike, >> Aside from the occasional peering wars i've never had or witnessed >> any >> serious issues with Cogent. If you want some redundancy you might >> also >> try some other similarly priced providers like WBS Connect, HE, or >> BtN. > > (resend due to subject filter) > > Plus if you had direct connectivity to Cogent, their peering status > with > others wouldn't affect you anymore. Personally, I've seriously > considered this as a reason to get a connection from Cogent. > > ~Seth > From msa at latt.net Mon Jan 12 12:48:42 2009 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 12 Jan 2009 18:48:42 +0000 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> Message-ID: <20090112184842.GA52263@mx1.latt.net> On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote: > I'm not entirely certain what is going on but has anyone noticed some > strange announcements for 174.128.31.0/24? > > I received a hijack notice that my AS (AS11708) was announcing the above > IP range. I verified that I was not when I started noticing some > strange announcements for that range. Around 10 Am CST AS11911 was > announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST > I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). > > Interestingly enough, ARIN indicates this is a part of range they have > assigned for reachability testing. > http://ws.arin.net/whois/?queryinput=174.128.31.0 randy lied but no packets died enough now More seriously, this is indeed reachability research. Try emailing the AS 3130 contacts although I'd imagine Randy will see this. Thanks, --msa From pstewart at nexicomgroup.net Mon Jan 12 12:52:17 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 12 Jan 2009 13:52:17 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090112184842.GA52263@mx1.latt.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul -----Original Message----- From: Majdi S. Abbas [mailto:msa at latt.net] Sent: Monday, January 12, 2009 1:49 PM To: Michienne Dixon Cc: nanog at nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote: > I'm not entirely certain what is going on but has anyone noticed some > strange announcements for 174.128.31.0/24? > > I received a hijack notice that my AS (AS11708) was announcing the above > IP range. I verified that I was not when I started noticing some > strange announcements for that range. Around 10 Am CST AS11911 was > announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST > I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). > > Interestingly enough, ARIN indicates this is a part of range they have > assigned for reachability testing. > http://ws.arin.net/whois/?queryinput=174.128.31.0 randy lied but no packets died enough now More seriously, this is indeed reachability research. Try emailing the AS 3130 contacts although I'd imagine Randy will see this. Thanks, --msa ---------------------------------------------------------------------------- "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." From karlinjf at cs.unm.edu Mon Jan 12 12:56:40 2009 From: karlinjf at cs.unm.edu (Josh Karlin) Date: Mon, 12 Jan 2009 11:56:40 -0700 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> Message-ID: <71051fe20901121056r351d3485h95b8fe8ae764f45e@mail.gmail.com> At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS" Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart wrote: > Same here.. got a notice this morning and while it's false, I still have > no response from Randy neither on this matter... > > If they are going to involve our AS numbers and trigger alarms it would > be nice to notify us first... especially on something as major as a > prefix hijacking (potentially) > > Paul > > > > -----Original Message----- > From: Majdi S. Abbas [mailto:msa at latt.net] > Sent: Monday, January 12, 2009 1:49 PM > To: Michienne Dixon > Cc: nanog at nanog.org > Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote: > > I'm not entirely certain what is going on but has anyone noticed some > > strange announcements for 174.128.31.0/24? > > > > I received a hijack notice that my AS (AS11708) was announcing the > above > > IP range. I verified that I was not when I started noticing some > > strange announcements for that range. Around 10 Am CST AS11911 was > > announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM > CST > > I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). > > > > Interestingly enough, ARIN indicates this is a part of range they have > > assigned for reachability testing. > > http://ws.arin.net/whois/?queryinput=174.128.31.0 > > randy lied but > no packets died > enough now > > More seriously, this is indeed reachability research. Try > emailing > the AS 3130 contacts although I'd imagine Randy will see this. > > Thanks, > > --msa > > > > > > > ---------------------------------------------------------------------------- > > "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." > > From brandon.galbraith at gmail.com Mon Jan 12 12:59:23 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 12 Jan 2009 12:59:23 -0600 Subject: Cogent Considerations [was: Re: Cogent Haiku v2.0] In-Reply-To: <496B8BAA.4090901@shankland.org> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <496B86F1.60506@mountaincable.on.ca> <496B8BAA.4090901@shankland.org> Message-ID: <366100670901121059p10a1aaddu3e89f09ffba0aba2@mail.gmail.com> On 1/12/09, Jim Shankland wrote: > > Adam Young wrote: > >> I wouldn't take my word for it but truthfully, you get what you pay for. >> Given you have other, more reliable transit, adding Cogent may be ok. >> I wouldn't rely on it for anything serious though. >> > > That has not been my experience. Peering wars have been an issue, but > aside from that, they've been fine. (This is transit in San Francisco > at the gigabit-plus level.) > > Jim Shankland > > Seconded. We also have Cogent for gigabit transit. I had far more problems in the short time we used Level3 for transit than I've had with Cogent. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From rays at maine.edu Mon Jan 12 12:58:30 2009 From: rays at maine.edu (Soucy, Ray) Date: Mon, 12 Jan 2009 13:58:30 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> Message-ID: <36243D984F88BA4ABD1E0EFC1E61B989652091@fudd.ad.maine.edu> We peer with Cogent. They are very competitive in terms of pricing. To be honest, Cogent has been pretty good to us. As long as you have a 2nd peer (which it sounds like you do) for backup I'd say they're a pretty safe bet. The only problem I've had with Cogent is that they're still not ready to route IPv6. The whole "you get what you pay for" talk is nonsense in my book, you're paying top dollar with places like Sprint because they use the income to subsidize their other efforts that are taking a loss. Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ -----Original Message----- From: Mike Bartz [mailto:mob at bartzfamily.net] Sent: Monday, January 12, 2009 12:54 PM To: neal rauhauser Cc: nanog at nanog.org Subject: Re: Cogent Haiku v2.0 I like the haiku! On a serious note, we are considering getting a connection from Cogent. We currently have connections to at&t, Level 3 and TW Telecom. The low cost and high number of peer AS number's seems appealing to us. Every carrier has its issues, so I don't know what to make of the apparent negativity that I am seeing in these haiku threads. I am looking for some first hand experiences to help me make this decision. Thanks for any assistance! Mike On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: > Cogent makes a mess > My phone rings and rings > Unfornicate this! > -- Mike Bartz mob at bartzfamily.net From oberman at es.net Mon Jan 12 13:07:40 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 12 Jan 2009 11:07:40 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: Your message of "Mon, 12 Jan 2009 13:52:17 EST." <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> Message-ID: <20090112190740.9A7E41CC0B@ptavv.es.net> > Date: Mon, 12 Jan 2009 13:52:17 -0500 > From: "Paul Stewart" > > Same here.. got a notice this morning and while it's false, I still have > no response from Randy neither on this matter... > > If they are going to involve our AS numbers and trigger alarms it would > be nice to notify us first... especially on something as major as a > prefix hijacking (potentially) > > Paul > > > > -----Original Message----- > From: Majdi S. Abbas [mailto:msa at latt.net] > Sent: Monday, January 12, 2009 1:49 PM > To: Michienne Dixon > Cc: nanog at nanog.org > Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote: > > I'm not entirely certain what is going on but has anyone noticed some > > strange announcements for 174.128.31.0/24? > > > > I received a hijack notice that my AS (AS11708) was announcing the > above > > IP range. I verified that I was not when I started noticing some > > strange announcements for that range. Around 10 Am CST AS11911 was > > announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM > CST > > I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). > > > > Interestingly enough, ARIN indicates this is a part of range they have > > assigned for reachability testing. > > http://ws.arin.net/whois/?queryinput=174.128.31.0 > > randy lied but > no packets died > enough now > > More seriously, this is indeed reachability research. Try > emailing > the AS 3130 contacts although I'd imagine Randy will see this. http://psg.com/173-174/ explains what is going on. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From mdixon at nkc.org Mon Jan 12 13:20:10 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 13:20:10 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> <71051fe20901121056r351d3485h95b8fe8ae764f45e@mail.gmail.com> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16BF@nkc-mailsrv.nkc.org> The IAR was the source of my notice as well and is what started me down this path of cat herding. I would think that it would only be polite to notify people about what is going on so that other people do not waste their time looking for phantom issues. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 ________________________________ From: karlinjf at gmail.com [mailto:karlinjf at gmail.com] On Behalf Of Josh Karlin Sent: Monday, January 12, 2009 12:57 PM To: Paul Stewart Cc: Majdi S. Abbas; Michienne Dixon; nanog at nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS" Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart wrote: Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul From eddy+public+spam at noc.everquick.net Mon Jan 12 13:20:27 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 12 Jan 2009 19:20:27 +0000 (GMT) Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090112184842.GA52263@mx1.latt.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> Message-ID: MSA> Date: Mon, 12 Jan 2009 18:48:42 +0000 MSA> From: Majdi S. Abbas MSA> More seriously, this is indeed reachability research. Try emailing MSA> the AS 3130 contacts although I'd imagine Randy will see this. Why not do this in a lab instead? ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From mailinglists at expresswebsystems.com Mon Jan 12 13:25:52 2009 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Mon, 12 Jan 2009 13:25:52 -0600 Subject: recommendation for SIP integration In-Reply-To: References: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> Message-ID: <56403B6B43A14A41B530593D66302C1B@Slim> > I've used broadvoice before for personal telephony, and they were > competent and asterisk-friendly, and seemed to have DIDs in many US > LCAs. Just to throw another name into the arena http://voicepulse.com/ Pros: SIP and IAX termination Many US NPP/NXX exchanges and 800 numbers Config examples for many PBXs POPs on both coasts Good knowledgeable customer support Cons: Not all NPP/NXX offer LNP (Local Number Portability) Credit card verification process is annoying, but I understand why We have used them for several customers as well as our own SIP termination. Disclaimer: I am not affiliated with them in anyway, just a satisfied customer. Tom Walsh From pstewart at nexicomgroup.net Mon Jan 12 13:29:11 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 12 Jan 2009 14:29:11 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16BF@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><20090112184842.GA52263@mx1.latt.net><89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net><71051fe20901121056r351d3485h95b8fe8ae764f45e@mail.gmail.com> <6316CD198EC8BC44A9D200F375869F1E4A16BF@nkc-mailsrv.nkc.org> Message-ID: <89D27DE3375BB6428DDCC2927489826A01E706B0@nexus.nexicomgroup.net> Absolutely - according to their website " No real or production prefixes or data packets are being harmed in this experiment. If you become aware that this experiment causes any actual real operational problem, please write to us immediately. " I have asked them to have some courtesy next time before wasting a lot of people's time... Paul -----Original Message----- From: Michienne Dixon [mailto:mdixon at nkc.org] Sent: Monday, January 12, 2009 2:20 PM To: nanog at nanog.org Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 The IAR was the source of my notice as well and is what started me down this path of cat herding. I would think that it would only be polite to notify people about what is going on so that other people do not waste their time looking for phantom issues. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 ________________________________ From: karlinjf at gmail.com [mailto:karlinjf at gmail.com] On Behalf Of Josh Karlin Sent: Monday, January 12, 2009 12:57 PM To: Paul Stewart Cc: Majdi S. Abbas; Michienne Dixon; nanog at nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS" Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart wrote: Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul ---------------------------------------------------------------------------- "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." From sethm at rollernet.us Mon Jan 12 13:30:12 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 12 Jan 2009 11:30:12 -0800 Subject: Cogent (was the poetry thread) In-Reply-To: <66EEA3A0-C00C-4F7C-A2AC-977705D9AD77@via.net> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> <66EEA3A0-C00C-4F7C-A2AC-977705D9AD77@via.net> Message-ID: <496B9A44.8010101@rollernet.us> joe mcguckin wrote: > So, you're essentially getting paid peering from Cogent then ? > > I guess you could do that. Normally I'd just throw it in the mix with the rest and let BGP figure it out if there's another depeering. ~Seth From reese at inkworkswell.com Mon Jan 12 13:34:25 2009 From: reese at inkworkswell.com (Reese) Date: Mon, 12 Jan 2009 14:34:25 -0500 Subject: In-Reply-To: <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> References: <000301c9747c$a9087400$fb195c00$@com> <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> Message-ID: <496B9B41.8020104@inkworkswell.com> I once had a legitimate difficulty and posted to this list as a direct result. As I was moderated at the time, my post was denied with the provided reason that it was not appropriate for this list. An attempt to identify the source ISP of a troublesome IP was not "appropriate" but the below (and etc.) is? Still, still, exercising undue discipline - unlike others. -- Scott Berkman wrote: > , drop, and roll? > > -----Original Message----- > From: Aaron Imbrock [mailto:aimbrock at gmail.com] > Sent: Monday, January 12, 2009 1:12 AM > To: NANOG at nanog.org > Subject: > > Stop > From randy at psg.com Mon Jan 12 13:37:07 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 04:37:07 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> Message-ID: <496B9BE3.8020700@psg.com> On 09.01.13 03:40, Michienne Dixon wrote: > I'm not entirely certain what is going on but has anyone noticed some > strange announcements for 174.128.31.0/24? see http://psg.com/173-174/ randy From randy at psg.com Mon Jan 12 13:42:10 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 04:42:10 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> Message-ID: <496B9D12.8000808@psg.com> On 09.01.13 03:52, Paul Stewart wrote: > Same here.. got a notice this morning and while it's false, I still have > no response from Randy neither on this matter.. guy's gotta sleep some time. it's 04:40 here. if you wrote me directly, you would have a response by now. almost to the bottom of my mailbox. part of the experiment is to measure the difference between the amount of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we get in 2009 while not pre-announcing. :) randy From patrick at ianai.net Mon Jan 12 13:47:11 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Jan 2009 14:47:11 -0500 Subject: Cogent (was the poetry thread) In-Reply-To: <496B8933.5050605@rollernet.us> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> Message-ID: <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> On Jan 12, 2009, at 1:17 PM, Seth Mattinen wrote: > Jeffrey Lyon wrote: >> Mike, >> Aside from the occasional peering wars i've never had or witnessed >> any >> serious issues with Cogent. If you want some redundancy you might >> also >> try some other similarly priced providers like WBS Connect, HE, or >> BtN. > > (resend due to subject filter) > > Plus if you had direct connectivity to Cogent, their peering status > with > others wouldn't affect you anymore. Personally, I've seriously > considered this as a reason to get a connection from Cogent. If you are not single-homed, you have no issues reaching Cogent even during a "peering war" - unless Cogent depeers / gets depeered from - both- (all) of your upstreams at the same time. So what value is there to add Cogent? If you are not single-homed, then reaching Cogent is not even close to your only problem. -- TTFN, patrick From patrick at ianai.net Mon Jan 12 13:51:49 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Jan 2009 14:51:49 -0500 Subject: Cogent (was the poetry thread) In-Reply-To: <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> Message-ID: On Jan 12, 2009, at 2:47 PM, Patrick W. Gilmore wrote: > On Jan 12, 2009, at 1:17 PM, Seth Mattinen wrote: >> Jeffrey Lyon wrote: >>> Mike, >>> Aside from the occasional peering wars i've never had or witnessed >>> any >>> serious issues with Cogent. If you want some redundancy you might >>> also >>> try some other similarly priced providers like WBS Connect, HE, or >>> BtN. >> >> (resend due to subject filter) >> >> Plus if you had direct connectivity to Cogent, their peering status >> with >> others wouldn't affect you anymore. Personally, I've seriously >> considered this as a reason to get a connection from Cogent. > > > If you are not single-homed, you have no issues reaching Cogent even > during a "peering war" - unless Cogent depeers / gets depeered from - > both- (all) of your upstreams at the same time. So what value is > there to add Cogent? > > If you are not single-homed, then reaching Cogent is not even close > to your only problem. s/not// Sorry for confusion. -- TTFN, patrick From martin at airwire.ie Mon Jan 12 13:53:00 2009 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 12 Jan 2009 19:53:00 +0000 Subject: Cogent (was the poetry thread) In-Reply-To: <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> Message-ID: <496B9F9C.7000205@airwire.ie> Patrick W. Gilmore wrote: > On Jan 12, 2009, at 1:17 PM, Seth Mattinen wrote: >> Jeffrey Lyon wrote: >>> Mike, >>> Aside from the occasional peering wars i've never had or witnessed any >>> serious issues with Cogent. If you want some redundancy you might also >>> try some other similarly priced providers like WBS Connect, HE, or >>> BtN. >> >> (resend due to subject filter) >> >> Plus if you had direct connectivity to Cogent, their peering status with >> others wouldn't affect you anymore. Personally, I've seriously >> considered this as a reason to get a connection from Cogent. > > > If you are not single-homed, you have no issues reaching Cogent even > during a "peering war" - unless Cogent depeers / gets depeered from > -both- (all) of your upstreams at the same time. So what value is there > to add Cogent? The value is, that Cogent pretty much is the cheapest transit you can get out there vs. paying a premium for carriers that have less clue and more outages. And if you do that in a multi-homed scenario you shouldn't have issues, having Cogent or not having it, correct. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From jeremy at evilrouters.net Mon Jan 12 13:59:33 2009 From: jeremy at evilrouters.net (Jeremy L. Gaddis) Date: Mon, 12 Jan 2009 14:59:33 -0500 (EST) Subject: In-Reply-To: <496B9B41.8020104@inkworkswell.com> References: <000301c9747c$a9087400$fb195c00$@com> <004401c974c3$0e60f610$2b22e230$@berkman@reignmaker.net> <496B9B41.8020104@inkworkswell.com> Message-ID: On Mon, 12 Jan 2009, Reese wrote: > I once had a legitimate difficulty and posted to this list as a > direct result. As I was moderated at the time, my post was denied > with the provided reason that it was not appropriate for this > list. An attempt to identify the source ISP of a troublesome IP > was not "appropriate" but the below (and etc.) is? > > Still, still, exercising undue discipline - unlike others. http://tinyurl.com/6q7g3m ? -- Jeremy L. Gaddis http://evilrouters.net From michael.holstein at csuohio.edu Mon Jan 12 14:01:43 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 12 Jan 2009 15:01:43 -0500 Subject: recommendation for SIP integration In-Reply-To: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> References: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> Message-ID: <496BA1A7.4040500@csuohio.edu> > Hi, I am looking for a solution where I can tie a US number to a SIP solution. Has anyone had experience with this and if so can you make some recommendations? > I use Flowroute myself (www.flowroute.com) .. you can do single DIDs tied to a SIP peer, virtual PRIs, and a number of other things. You can even get a free account to test your setup. Here's the list of area codes they offer them in : http://www.flowroute.com/services/dids/ I'm just using it for my personal Asterisk setup, so I'm not sure how they scale out. They claim to support thousands of simultaneous calls to most international destinations. Here's a link to a bunch of others : http://www.voip-info.org/wiki/view/DID+Service+Providers Cheers, Michael Holstein Cleveland State University From patrick at ianai.net Mon Jan 12 14:05:44 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Jan 2009 15:05:44 -0500 Subject: Cogent (was the poetry thread) In-Reply-To: <496B9F9C.7000205@airwire.ie> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> <496B9F9C.7000205@airwire.ie> Message-ID: <2764F5F0-076C-4F2B-9EB6-74D5A2498393@ianai.net> On Jan 12, 2009, at 2:53 PM, Martin List-Petersen wrote: > Patrick W. Gilmore wrote: >> On Jan 12, 2009, at 1:17 PM, Seth Mattinen wrote: >>> Jeffrey Lyon wrote: >>>> Mike, >>>> Aside from the occasional peering wars i've never had or >>>> witnessed any >>>> serious issues with Cogent. If you want some redundancy you might >>>> also >>>> try some other similarly priced providers like WBS Connect, HE, or >>>> BtN. >>> >>> (resend due to subject filter) >>> >>> Plus if you had direct connectivity to Cogent, their peering >>> status with >>> others wouldn't affect you anymore. Personally, I've seriously >>> considered this as a reason to get a connection from Cogent. >> >> If you are not single-homed, you have no issues reaching Cogent even >> during a "peering war" - unless Cogent depeers / gets depeered from >> -both- (all) of your upstreams at the same time. So what value is >> there >> to add Cogent? > > The value is, that Cogent pretty much is the cheapest transit you can > get out there vs. paying a premium for carriers that have less clue > and > more outages. Sorry for being imprecise. I meant that adding Cogent does not significantly improve your reachability. Choosing to buy from Cogent because they depeer / get depeered occasionally is silly, IMHO. To be clear, I am making no comment on Cogent's overall performance. If you find value in adding a provider for other reasons (cost, performance, etc.), I would not argue against it. -- TTFN, patrick From patrick at ianai.net Mon Jan 12 13:45:32 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Jan 2009 14:45:32 -0500 Subject: Cogent Haiku v2.0 In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B989652091@fudd.ad.maine.edu> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <36243D984F88BA4ABD1E0EFC1E61B989652091@fudd.ad.maine.edu> Message-ID: <143C07C0-466E-424E-8C39-EBCFA7ABA302@ianai.net> On Jan 12, 2009, at 1:58 PM, Soucy, Ray wrote: > We peer with Cogent. They are very competitive in terms of pricing. > To be honest, Cogent has been pretty good to us. As long as you > have a > 2nd peer (which it sounds like you do) for backup I'd say they're a > pretty safe bet. I think you mean s/peer/transit. -- TTFN, patrick > The only problem I've had with Cogent is that they're still not > ready to > route IPv6. > > The whole "you get what you pay for" talk is nonsense in my book, > you're > paying top dollar with places like Sprint because they use the > income to > subsidize their other efforts that are taking a loss. > > Ray Soucy > Communications Specialist > > +1 (207) 561-3526 > > Communications and Network Services > > University of Maine System > http://www.maine.edu/ > > > -----Original Message----- > From: Mike Bartz [mailto:mob at bartzfamily.net] > Sent: Monday, January 12, 2009 12:54 PM > To: neal rauhauser > Cc: nanog at nanog.org > Subject: Re: Cogent Haiku v2.0 > > I like the haiku! On a serious note, we are considering getting a > connection from Cogent. We currently have connections to at&t, Level > 3 and TW Telecom. The low cost and high number of peer AS number's > seems appealing to us. Every carrier has its issues, so I don't know > what to make of the apparent negativity that I am seeing in these > haiku threads. I am looking for some first hand experiences to help > me make this decision. > > Thanks for any assistance! > > Mike > > > On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser > wrote: >> Cogent makes a mess >> My phone rings and rings >> Unfornicate this! >> > > > > -- > Mike Bartz > mob at bartzfamily.net > > From mdixon at nkc.org Mon Jan 12 14:32:20 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 14:32:20 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> <496B9D12.8000808@psg.com> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16C7@nkc-mailsrv.nkc.org> My apologizes for jumping the gun. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, January 12, 2009 1:42 PM To: Paul Stewart Cc: Majdi S. Abbas; Michienne Dixon; nanog at nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 09.01.13 03:52, Paul Stewart wrote: > Same here.. got a notice this morning and while it's false, I still > have no response from Randy neither on this matter.. guy's gotta sleep some time. it's 04:40 here. if you wrote me directly, you would have a response by now. almost to the bottom of my mailbox. part of the experiment is to measure the difference between the amount of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we get in 2009 while not pre-announcing. :) randy From jfiske at clarkson.edu Mon Jan 12 14:33:00 2009 From: jfiske at clarkson.edu (Josh Fiske) Date: Mon, 12 Jan 2009 15:33:00 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01E706B0@nexus.nexicomgroup.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><20090112184842.GA52263@mx1.latt.net><89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net><71051fe20901121056r351d3485h95b8fe8ae764f45e@mail.gmail.com><6316CD198EC8BC44A9D200F375869F1E4A16BF@nkc-mailsrv.nkc.org> <89D27DE3375BB6428DDCC2927489826A01E706B0@nexus.nexicomgroup.net> Message-ID: <6708B7A5C8087B4AA393C1CDD1D56200106FF1@mbox1.ad.clarkson.edu> I agree with Paul and Michienne, having the courtesy to notify next time would be very much appreciated. I was headed into a family member's funeral when I received the hijack notification. I took the 15 minutes to do some quick investigation, fire off a few emails informing my colleagues of the issue and "arrived" at the funeral a bit late. Perhaps in the future it would be better not to play with my toys without asking my permission first? - - - - Joshua Fiske '03, '04 Network and Security Engineer Clarkson University, Office of Information Technology (315) 268-6722 -- Fax: (315) 268-6570 I route, therefore you are. Think before you print. CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: Monday, January 12, 2009 2:29 PM To: Michienne Dixon; nanog at nanog.org Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Absolutely - according to their website " No real or production prefixes or data packets are being harmed in this experiment. If you become aware that this experiment causes any actual real operational problem, please write to us immediately. " I have asked them to have some courtesy next time before wasting a lot of people's time... Paul -----Original Message----- From: Michienne Dixon [mailto:mdixon at nkc.org] Sent: Monday, January 12, 2009 2:20 PM To: nanog at nanog.org Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 The IAR was the source of my notice as well and is what started me down this path of cat herding. I would think that it would only be polite to notify people about what is going on so that other people do not waste their time looking for phantom issues. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 ________________________________ From: karlinjf at gmail.com [mailto:karlinjf at gmail.com] On Behalf Of Josh Karlin Sent: Monday, January 12, 2009 12:57 PM To: Paul Stewart Cc: Majdi S. Abbas; Michienne Dixon; nanog at nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS" Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart wrote: Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul ------------------------------------------------------------------------ ---- "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." From marcus at gangusinternet.com Mon Jan 12 14:33:30 2009 From: marcus at gangusinternet.com (Marcus Marinelli) Date: Mon, 12 Jan 2009 12:33:30 -0800 Subject: recommendation for SIP integration In-Reply-To: <496BA1A7.4040500@csuohio.edu> References: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> <496BA1A7.4040500@csuohio.edu> Message-ID: I have used the CallWithUs guys (http://callwithus.com) and they seem to very reasonable. They have an emphasis on keeping things simple, and are happy to chat with you on a technical level if needed. On Mon, Jan 12, 2009 at 12:01 PM, Michael Holstein < michael.holstein at csuohio.edu> wrote: > > Hi, I am looking for a solution where I can tie a US number to a SIP >> solution. Has anyone had experience with this and if so can you make some >> recommendations? >> > > I use Flowroute myself (www.flowroute.com) .. you can do single DIDs tied > to a SIP peer, virtual PRIs, and a number of other things. You can even get > a free account to test your setup. Here's the list of area codes they offer > them in : http://www.flowroute.com/services/dids/ > > I'm just using it for my personal Asterisk setup, so I'm not sure how they > scale out. They claim to support thousands of simultaneous calls to most > international destinations. > > Here's a link to a bunch of others : > http://www.voip-info.org/wiki/view/DID+Service+Providers > > Cheers, > > Michael Holstein > Cleveland State University > > From randy at psg.com Mon Jan 12 14:34:24 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 05:34:24 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16C7@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> <496B9D12.8000808@psg.com> <6316CD198EC8BC44A9D200F375869F1E4A16C7@nkc-mailsrv.nkc.org> Message-ID: <496BA950.8060409@psg.com> On 09.01.13 05:32, Michienne Dixon wrote: >> guy's gotta sleep some time. it's 04:40 here. > My apologizes for jumping the gun. i demand a full refund! :) but that's about the best use for guns i can think of. randy From rays at maine.edu Mon Jan 12 14:36:02 2009 From: rays at maine.edu (Soucy, Ray) Date: Mon, 12 Jan 2009 15:36:02 -0500 Subject: Fiber Plant Tracking Database Message-ID: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> Does anyone know of any software offerings to track your fiber plant (inside and outdoor) besides the OptiCon Systems offering (formerly Corning)? Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From fw at deneb.enyo.de Mon Jan 12 14:39:33 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 12 Jan 2009 21:39:33 +0100 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496B9BE3.8020700@psg.com> (Randy Bush's message of "Tue, 13 Jan 2009 04:37:07 +0900") References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> Message-ID: <87k590xnqy.fsf@mid.deneb.enyo.de> * Randy Bush: > On 09.01.13 03:40, Michienne Dixon wrote: >> I'm not entirely certain what is going on but has anyone noticed some >> strange announcements for 174.128.31.0/24? > > see http://psg.com/173-174/ So does "academic" mean "unethical" these days? I think this is over the line. You can't put other people's IDs into routing data on production networks. (Well, technically you can, obviously, but you shouldn't.) From bpfankuch at cpgreeley.com Mon Jan 12 14:46:37 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Mon, 12 Jan 2009 13:46:37 -0700 Subject: In-Reply-To: <000301c9747c$a9087400$fb195c00$@com> References: <000301c9747c$a9087400$fb195c00$@com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540C2B6B3D@CPExchange1.cpgreeley.com> Laughing at me. You make me cry on the inside. -----Original Message----- From: Aaron Imbrock [mailto:aimbrock at gmail.com] Sent: Sunday, January 11, 2009 11:12 PM To: NANOG at nanog.org Subject: Stop From frnkblk at iname.com Mon Jan 12 14:50:35 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 12 Jan 2009 14:50:35 -0600 Subject: Fiber Plant Tracking Database In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> Message-ID: We use the Innovative Systems mapping product: http://www.innovsys.com/Products/eLation/Features.html It may be too comprehensive/expensive for your needs. Frank -----Original Message----- From: Soucy, Ray [mailto:rays at maine.edu] Sent: Monday, January 12, 2009 2:36 PM To: nanog at nanog.org Subject: Fiber Plant Tracking Database Does anyone know of any software offerings to track your fiber plant (inside and outdoor) besides the OptiCon Systems offering (formerly Corning)? Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/ From jackson.tim at gmail.com Mon Jan 12 14:50:42 2009 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 12 Jan 2009 14:50:42 -0600 Subject: Fiber Plant Tracking Database In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> Message-ID: <4407932e0901121250p1185cc1bk5752fa14787390a6@mail.gmail.com> Lots of companies offer stuff like this... http://www.mapcom.con/ http://www.sapience360.com/ http://www.innovsys.com/ http://www.telecom-america.com/ -- Tim On Mon, Jan 12, 2009 at 2:36 PM, Soucy, Ray wrote: > Does anyone know of any software offerings to track your fiber plant > (inside and outdoor) besides the OptiCon Systems offering (formerly > Corning)? > > > > Ray Soucy > > Communications Specialist > > > > +1 (207) 561-3526 > > > > Communications and Network Services > > > > University of Maine System > > http://www.maine.edu/ > > > > From jbates at brightok.net Mon Jan 12 14:58:40 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 12 Jan 2009 14:58:40 -0600 Subject: Cogent Haiku v2.0 In-Reply-To: <143C07C0-466E-424E-8C39-EBCFA7ABA302@ianai.net> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <36243D984F88BA4ABD1E0EFC1E61B989652091@fudd.ad.maine.edu> <143C07C0-466E-424E-8C39-EBCFA7ABA302@ianai.net> Message-ID: <496BAF00.3090703@brightok.net> Patrick W. Gilmore wrote: > On Jan 12, 2009, at 1:58 PM, Soucy, Ray wrote: > >> We peer with Cogent. They are very competitive in terms of pricing. >> To be honest, Cogent has been pretty good to us. As long as you have a >> 2nd peer (which it sounds like you do) for backup I'd say they're a >> pretty safe bet. > > I think you mean s/peer/transit. > Perhaps he is running PPP, and meant peer. :P http://www.freesoft.org/CIE/RFC/1661/3.htm Obviously he's paying for transit with his peer, which is still technically a peering agreement; just not a free one. ;) From kris.foster at gmail.com Mon Jan 12 15:03:05 2009 From: kris.foster at gmail.com (kris foster) Date: Mon, 12 Jan 2009 13:03:05 -0800 Subject: Cogent Haiku v2.0 In-Reply-To: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> Message-ID: Hi everyone The Mailing List Committee would like to remind everyone that threads of this sort are not operationally relevant and go against the spirit of the AUP [1]. Haikus, one line jokes, and "me too" replies simply do not provide enough information for each of NANOG's 10,000 subscribers to determine if there is something operational they should be acting on. The MLC will be contacting the majority of participants in this thread to remind them of this. Please respect the inboxes of others. Kris Foster MLC Chair [1] #2: Postings of issues inconsistent with the charter are prohibited. Mailing list AUP: http://www.nanog.org/mailinglist/ NANOG Charter: http://www.nanog.org/governance/charter/ From jbates at brightok.net Mon Jan 12 15:09:40 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 12 Jan 2009 15:09:40 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <87k590xnqy.fsf@mid.deneb.enyo.de> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> Message-ID: <496BB194.4070508@brightok.net> Florian Weimer wrote: > I think this is over the line. You can't put other people's IDs into > routing data on production networks. (Well, technically you can, > obviously, but you shouldn't.) Actually, the placement of the ASN is exactly what they need to do the test, as it is treated as a routing loop and discarded. This allows for fancy reachability tests while a portion of the network cannot see the route in question. Of course, people track their ASN usage these days and get red alarms when their ASN shows up in ways unexpected. I'm not completely sure why the ASN matters, except it's probably just a bonus service to route hijacking detection (since ASN hijacking doesn't exactly serve a purpose except to limit the route being advertised and perhaps leave someone complaining to the wrong person if the hijacker is doing bad things). Jack From jabley at hopcount.ca Mon Jan 12 15:12:02 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 12 Jan 2009 16:12:02 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <87k590xnqy.fsf@mid.deneb.enyo.de> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> Message-ID: <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> On 2009-01-12, at 15:39, Florian Weimer wrote: > So does "academic" mean "unethical" these days? > > I think this is over the line. You can't put other people's IDs into > routing data on production networks. (Well, technically you can, > obviously, but you shouldn't.) The AS_PATH attribute is a loop-avoidance mechanism, not a signature on a cheque. AS_PATH prepending with your own and with others' AS numbers (the latter intended to effect "don't let this prefix leak into that AS") has been sitting in the inter-domain traffic engineering toolbox for years. I see no lack of ethics in the simple act of the as-path prepend as part of a route export policy. Joe From fw at deneb.enyo.de Mon Jan 12 15:14:21 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 12 Jan 2009 22:14:21 +0100 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496BB194.4070508@brightok.net> (Jack Bates's message of "Mon, 12 Jan 2009 15:09:40 -0600") References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <496BB194.4070508@brightok.net> Message-ID: <87zlhwut02.fsf@mid.deneb.enyo.de> * Jack Bates: > Florian Weimer wrote: >> I think this is over the line. You can't put other people's IDs into >> routing data on production networks. (Well, technically you can, >> obviously, but you shouldn't.) > > Actually, the placement of the ASN is exactly what they need to do the > test, as it is treated as a routing loop and discarded. Sorry, I fail to see how apparent necessity justifies anything, especially in an academic context. From patrick at ianai.net Mon Jan 12 15:16:00 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Jan 2009 16:16:00 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> Message-ID: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> On Jan 12, 2009, at 4:12 PM, Joe Abley wrote: > On 2009-01-12, at 15:39, Florian Weimer wrote: > >> So does "academic" mean "unethical" these days? >> >> I think this is over the line. You can't put other people's IDs into >> routing data on production networks. (Well, technically you can, >> obviously, but you shouldn't.) > > The AS_PATH attribute is a loop-avoidance mechanism, not a signature > on a cheque. > > AS_PATH prepending with your own and with others' AS numbers (the > latter intended to effect "don't let this prefix leak into that AS") > has been sitting in the inter-domain traffic engineering toolbox for > years. > > I see no lack of ethics in the simple act of the as-path prepend as > part of a route export policy. People have been doing it forever. However, it has been considered sketchy at best. If this were not Randy doing a research project, but, say, Cogent prepending the ASN of $LATEST_DEPEERED_NETWORK on announcements to Verio, how different would the tone of this thread have been? If A cannot / should not do it, then the same should go for B. -- TTFN, patrick From randy at psg.com Mon Jan 12 15:30:37 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 06:30:37 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> Message-ID: <496BB67D.6000809@psg.com> > If this were not Randy doing a research project, but, say, Cogent > prepending the ASN of $LATEST_DEPEERED_NETWORK on announcements to > Verio, how different would the tone of this thread have been? yep, tools can be used for both good and bad. randy From martin at theicelandguy.com Mon Jan 12 15:40:49 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 12 Jan 2009 16:40:49 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496BA950.8060409@psg.com> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> <496B9D12.8000808@psg.com> <6316CD198EC8BC44A9D200F375869F1E4A16C7@nkc-mailsrv.nkc.org> <496BA950.8060409@psg.com> Message-ID: On Mon, Jan 12, 2009 at 3:34 PM, Randy Bush wrote: > On 09.01.13 05:32, Michienne Dixon wrote: > >> guy's gotta sleep some time. it's 04:40 here. >>> >> My apologizes for jumping the gun. >> > > i demand a full refund! :) > > but that's about the best use for guns i can think of. > > randy > > Might be helpful to update the WHOIS data: NetRange: 174.128.0.0 - 174.128.255.255 CIDR: 174.128.0.0/16 NetName: ARIN-REACHABILITY-TESTING NetHandle: NET-174-128-0-0-1 Parent: NET-174-0-0-0-0 NetType: Direct Assignment NameServer: RIP.PSG.COM NameServer: NS0.REM.COM Comment: This IP address block is being used by ARIN to conduct reachability testing in networks 173.0.0.0/8 and 174.0.0.0/8. Please contact randy at psg.com with feedback or questions on the testing. RegDate: 2008-02-27 Updated: 2008-02-27 -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From randy at psg.com Mon Jan 12 15:45:12 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 06:45:12 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <20090112184842.GA52263@mx1.latt.net> <89D27DE3375BB6428DDCC2927489826A01E70678@nexus.nexicomgroup.net> <496B9D12.8000808@psg.com> <6316CD198EC8BC44A9D200F375869F1E4A16C7@nkc-mailsrv.nkc.org> <496BA950.8060409@psg.com> Message-ID: <496BB9E8.5040306@psg.com> > Might be helpful to update the WHOIS data: arin's good folk say it will be updated in tonight's (stateside night) run. randy From andrey.gordon at gmail.com Mon Jan 12 15:47:15 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Mon, 12 Jan 2009 16:47:15 -0500 Subject: recommendation for SIP integration In-Reply-To: References: <7186399.7231231782415485.JavaMail.zaid@turing-2.local> <496BA1A7.4040500@csuohio.edu> Message-ID: <90ccfc90901121347j4b351626ue5e1c26e887bb1b3@mail.gmail.com> Does anyone have any opinion on bandwidth.com as a SIP trunk provider by any chance? ----- Andrey Gordon [andrey.gordon at gmail.com] From streiner at cluebyfour.org Mon Jan 12 15:51:59 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 12 Jan 2009 16:51:59 -0500 (EST) Subject: Fiber Plant Tracking Database In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> Message-ID: On Mon, 12 Jan 2009, Soucy, Ray wrote: > Does anyone know of any software offerings to track your fiber plant > (inside and outdoor) besides the OptiCon Systems offering (formerly > Corning)? Mapcom came in awhile back to give us a presentation on their platform. It looked decent, but we ended up not buying it. jms From jabley at hopcount.ca Mon Jan 12 15:51:36 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 12 Jan 2009 16:51:36 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> Message-ID: <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> On 2009-01-12, at 16:16, Patrick W. Gilmore wrote: > People have been doing it forever. However, it has been considered > sketchy at best. This all seems highly subjective. Considered that way by some, sure (including you, it seems). In my experience prepending someone else's AS to a prefix has only been useful operationally only as a short-term, emergency measure (e.g. when trying to avoid a black-hole between two remote ASes, neither of whom shows any signs of fixing the problem). Randy's application, and Lorenzo's before him also seem like short- term applications designed to explore answering operational questions. Just because something is generally not used, or even if it's only worth using in an emergency, doesn't make it "sketchy". Most knee-jerk reactions to AS_PATH manipulation sound to me like fear of the unusual. Joe From nanog-post at rsuc.gweep.net Mon Jan 12 16:23:22 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 12 Jan 2009 17:23:22 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> Message-ID: <20090112222320.GA37803@gweep.net> On Mon, Jan 12, 2009 at 04:51:36PM -0500, Joe Abley wrote: [snip] > In my experience prepending someone else's AS to a prefix has only > been useful operationally only as a short-term, emergency measure > (e.g. when trying to avoid a black-hole between two remote ASes, > neither of whom shows any signs of fixing the problem). > > Randy's application, and Lorenzo's before him also seem like short- > term applications designed to explore answering operational questions. Nit, weird paths (this one) and long paths (Lorenzo's) are different. There were known BGP implementations which choked and died on long as-paths, which (w|c)ould trigger outages. Weird paths which appear to involve your network triggers -at least- work. > Just because something is generally not used, or even if it's only > worth using in an emergency, doesn't make it "sketchy". Given the prevalence of BGP community-based remote control over your direct neighbor's neighbors, it has seemed to (to me) to decrease. Using a label allocated to someone else does indeed seem sketchy to many of us; while the injector knows they are doing it and the injectee can figure it out, there's a heck of a lot of other parties (and archives) without context. Encouraging the use of such approaches, rather than encouraging providers to provision customers without the ability to forge AS paths, is a step in the wrong direction. > Most knee-jerk reactions to AS_PATH manipulation sound to me like fear > of the unusual. Less fear and more annoyance; the waters are muddied and the unusual requires investigation, and in some cases explanation internally & externally. Propagating bad table hygiene doesn't promote network use, increase stability/robustness, or anything that could be viewed as best practice. All IMO, of course. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bicknell at ufp.org Mon Jan 12 16:24:04 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 12 Jan 2009 17:24:04 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> Message-ID: <20090112222404.GA5587@ussenterprise.ufp.org> In a message written on Mon, Jan 12, 2009 at 04:51:36PM -0500, Joe Abley wrote: > Randy's application, and Lorenzo's before him also seem like short- > term applications designed to explore answering operational questions. > > Just because something is generally not used, or even if it's only > worth using in an emergency, doesn't make it "sketchy". > > Most knee-jerk reactions to AS_PATH manipulation sound to me like fear > of the unusual. I have no issues with people doing research and reporting on the findings, however I think this statement by Randy is where I believe it went over the line: ] part of the experiment is to measure the difference between the amount ] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we ] get in 2009 while not pre-announcing. :) This statement is an admission that he set out to annoy people, annoy them enough they would complain on a public mailing list. More over, I can't see how any researcher could use "the amount of nanog mail" as a valid indicator of anything. It has as much to do with how many engineers are bored on a given day as it does with the severity of the problem. So the goal of this research seemed to be to see how many people the researchers could panic, and then see how 10,000 people reacted to the panic. Sounds a lot like yelling "fire" in a crowded movie house just to "research" what the results might be, and then measuring success by the number of words in the article on the front page of the paper, or perhaps the number of people trampled to death, or both. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From randy at psg.com Mon Jan 12 16:30:39 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 07:30:39 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090112222404.GA5587@ussenterprise.ufp.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> Message-ID: <496BC48F.3050000@psg.com> > ] part of the experiment is to measure the difference between the amount > ] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we > ] get in 2009 while not pre-announcing. :) > > This statement is an admission that he set out to annoy people, > annoy them enough they would complain on a public mailing list. while you managed to quote the smiley, you somehow did not manage to parse it. do not leave your sense of humor at the door with your guns. randy From christian at broknrobot.com Mon Jan 12 16:34:01 2009 From: christian at broknrobot.com (Christian Koch) Date: Mon, 12 Jan 2009 17:34:01 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090112222404.GA5587@ussenterprise.ufp.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> Message-ID: > > ] part of the experiment is to measure the difference between the amount > ] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we > ] get in 2009 while not pre-announcing. :) > > This statement is an admission that he set out to annoy people, > annoy them enough they would complain on a public mailing list. > More over, I can't see how any researcher could use "the amount of > nanog mail" as a valid indicator of anything. It has as much to > do with how many engineers are bored on a given day as it does with > the severity of the problem. > > So the goal of this research seemed to be to see how many people > the researchers could panic, and then see how 10,000 people reacted > to the panic. Sounds a lot like yelling "fire" in a crowded movie > house just to "research" what the results might be, and then measuring > success by the number of words in the article on the front page of > the paper, or perhaps the number of people trampled to death, or > both. > maybe not so much annoy people, rather see how many people actually noticed the announcements and were aware that their AS was being used as an origin in the path From pstewart at nexicomgroup.net Mon Jan 12 16:42:44 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 12 Jan 2009 17:42:44 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net><882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca><20090112222404.GA5587@ussenterprise.ufp.org> Message-ID: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> For us, it was annoying - we look for prefix hijackings or what appear to be. In this case it was a false alarm but one that consumed NOC resources to troubleshoot and resolve... later to find out it was an "academic test" and nothing was really going on. Paul -----Original Message----- From: Christian Koch [mailto:christian at broknrobot.com] Sent: January 12, 2009 5:34 PM To: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > ] part of the experiment is to measure the difference between the amount > ] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we > ] get in 2009 while not pre-announcing. :) > > This statement is an admission that he set out to annoy people, > annoy them enough they would complain on a public mailing list. > More over, I can't see how any researcher could use "the amount of > nanog mail" as a valid indicator of anything. It has as much to > do with how many engineers are bored on a given day as it does with > the severity of the problem. > > So the goal of this research seemed to be to see how many people > the researchers could panic, and then see how 10,000 people reacted > to the panic. Sounds a lot like yelling "fire" in a crowded movie > house just to "research" what the results might be, and then measuring > success by the number of words in the article on the front page of > the paper, or perhaps the number of people trampled to death, or > both. > maybe not so much annoy people, rather see how many people actually noticed the announcements and were aware that their AS was being used as an origin in the path ---------------------------------------------------------------------------- "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." From randy at psg.com Mon Jan 12 16:47:18 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 07:47:18 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net><882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca><20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> Message-ID: <496BC876.8070704@psg.com> On 09.01.13 07:42, Paul Stewart wrote: > For us, it was annoying - we look for prefix hijackings or what appear > to be. i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks. randy From mdixon at nkc.org Mon Jan 12 16:51:05 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 16:51:05 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16D4@nkc-mailsrv.nkc.org> The only exception I took with this morning's exercise is that had I known that Mr. Bush was doing legitimate testing I would have allocated my time differently. I would consider this analogous to a customer testing their home alarm system and not letting the alarm company know about the test. The alarm company is going to investigate and I would hope even attempt to call the customer. Upon not being able to reach the customer they decide to err on the side of caution and dispatch someone to investigate. As Mr. Bush said, tools can be used for good or bad. If someone was using my AS to hijack IP space that belonged someone else, I would want to know about it. Would that not be akin to using a stolen identity to commit a crime? Mr. Bush - I'm not trying to beat a dead horse here. (Un)fortunately, you have given a lot of us something to discuss today. ;) - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Monday, January 12, 2009 3:52 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 2009-01-12, at 16:16, Patrick W. Gilmore wrote: > People have been doing it forever. However, it has been considered > sketchy at best. This all seems highly subjective. Considered that way by some, sure (including you, it seems). In my experience prepending someone else's AS to a prefix has only been useful operationally only as a short-term, emergency measure (e.g. when trying to avoid a black-hole between two remote ASes, neither of whom shows any signs of fixing the problem). Randy's application, and Lorenzo's before him also seem like short- term applications designed to explore answering operational questions. Just because something is generally not used, or even if it's only worth using in an emergency, doesn't make it "sketchy". Most knee-jerk reactions to AS_PATH manipulation sound to me like fear of the unusual. Joe From ren.provo at gmail.com Mon Jan 12 16:54:00 2009 From: ren.provo at gmail.com (Ren Provo) Date: Mon, 12 Jan 2009 17:54:00 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496BC876.8070704@psg.com> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> Message-ID: <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> Hi Randy (and the cast of characters on this thread), Could you please put in a lightning talk for this experiment? It would be great to hear more about this in .DR. We're accepting submissions now for lightning talks on Monday the 26th of January. http://www.nanogpc.org is the best place. Cheers, -ren On Mon, Jan 12, 2009 at 5:47 PM, Randy Bush wrote: > On 09.01.13 07:42, Paul Stewart wrote: > >> For us, it was annoying - we look for prefix hijackings or what appear >> to be. >> > > i think herein lies the rub. it is not prefix hijacking and in no way > should it appear that way to you. i suggest tuning your detectors. i am > told that path poisoning is used (futilely, we hope to show) in day to day > ops by folk to try to avert dos attacks. > > randy > > From mdixon at nkc.org Mon Jan 12 16:55:49 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 16:55:49 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net><882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca><20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16D5@nkc-mailsrv.nkc.org> But isn't this method kind of related to how an network from the Mediterranean/Mid-east went about blocking what they felt was undesirable/offensive content from entering their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, January 12, 2009 4:47 PM To: Paul Stewart Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 09.01.13 07:42, Paul Stewart wrote: > For us, it was annoying - we look for prefix hijackings or what appear > to be. i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks. randy From jeffrey.lyon at blacklotus.net Mon Jan 12 16:56:59 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 12 Jan 2009 17:56:59 -0500 Subject: Cogent (was the poetry thread) In-Reply-To: <2764F5F0-076C-4F2B-9EB6-74D5A2498393@ianai.net> References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com> <82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> <496B8933.5050605@rollernet.us> <33DF98FC-8389-46D0-BF00-C29243AD7448@ianai.net> <496B9F9C.7000205@airwire.ie> <2764F5F0-076C-4F2B-9EB6-74D5A2498393@ianai.net> Message-ID: <16720fe00901121456pa31da79ld4377e1cc405c0c6@mail.gmail.com> Patrick, I'd contend that using Cogent is a good way to reduce your cost of doing business while maintaining an acceptable level of service, not to necessarily improve reach. If your network absolutely must have the best routes you may be better off adding some other providers regardless. Best regards, Jeff On Mon, Jan 12, 2009 at 3:05 PM, Patrick W. Gilmore wrote: > On Jan 12, 2009, at 2:53 PM, Martin List-Petersen wrote: >> >> Patrick W. Gilmore wrote: >>> >>> On Jan 12, 2009, at 1:17 PM, Seth Mattinen wrote: >>>> >>>> Jeffrey Lyon wrote: >>>>> >>>>> Mike, >>>>> Aside from the occasional peering wars i've never had or witnessed any >>>>> serious issues with Cogent. If you want some redundancy you might also >>>>> try some other similarly priced providers like WBS Connect, HE, or >>>>> BtN. >>>> >>>> (resend due to subject filter) >>>> >>>> Plus if you had direct connectivity to Cogent, their peering status with >>>> others wouldn't affect you anymore. Personally, I've seriously >>>> considered this as a reason to get a connection from Cogent. >>> >>> If you are not single-homed, you have no issues reaching Cogent even >>> during a "peering war" - unless Cogent depeers / gets depeered from >>> -both- (all) of your upstreams at the same time. So what value is there >>> to add Cogent? >> >> The value is, that Cogent pretty much is the cheapest transit you can >> get out there vs. paying a premium for carriers that have less clue and >> more outages. > > Sorry for being imprecise. I meant that adding Cogent does not > significantly improve your reachability. Choosing to buy from Cogent > because they depeer / get depeered occasionally is silly, IMHO. > > To be clear, I am making no comment on Cogent's overall performance. If you > find value in adding a provider for other reasons (cost, performance, etc.), > I would not argue against it. > > -- > TTFN, > patrick > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From randy at psg.com Mon Jan 12 16:57:51 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 07:57:51 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> Message-ID: <496BCAEF.6020401@psg.com> > Could you please put in a lightning talk for this experiment? It would > be great to hear more about this in .DR. We're accepting submissions now > for lightning talks on Monday the 26th of January. a - i will not be in dr. i really wanted to support the dr meeting, but it's hard to justify after four years of service. maybe i'll make the next one. b - we can not present results before papers are submitted. c - we hope to present results at ops fora, nanog included, if they are good enough to warrant as opposed to just good sensationalist blah blah. randy From patrick at ianai.net Mon Jan 12 16:59:38 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 12 Jan 2009 17:59:38 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16D5@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net><882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca><20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <6316CD198EC8BC44A9D200F375869F1E4A16D5@nkc-mailsrv.nkc.org> Message-ID: On Jan 12, 2009, at 5:55 PM, Michienne Dixon wrote: > But isn't this method kind of related to how an network from the > Mediterranean/Mid-east went about blocking what they felt was > undesirable/offensive content from entering their network? No. -- TTFN, patrick From deleskie at gmail.com Mon Jan 12 16:59:39 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 12 Jan 2009 22:59:39 +0000 Subject: Anyone notice strange announcements for 174.128.31.0/24 Message-ID: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> This was a test using unassigned IP block, unless I'm reading it wrong. If a noc alerted on this it should have still be a low priority issue. I don't see any issues with the way this was carried out at all. -jim ------Original Message------ From: Michienne Dixon To: NANOG list Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Sent: Jan 12, 2009 6:55 PM But isn't this method kind of related to how an network from the Mediterranean/Mid-east went about blocking what they felt was undesirable/offensive content from entering their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, January 12, 2009 4:47 PM To: Paul Stewart Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 09.01.13 07:42, Paul Stewart wrote: > For us, it was annoying - we look for prefix hijackings or what appear > to be. i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks. randy Sent from my BlackBerry device on the Rogers Wireless Network From mdixon at nkc.org Mon Jan 12 17:04:36 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 17:04:36 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net><882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca><20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net><496BC876.8070704@psg.com><6316CD198EC8BC44A9D200F375869F1E4A16D5@nkc-mailsrv.nkc.org> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16D9@nkc-mailsrv.nkc.org> I sit corrected. I thought they had started announcing someone else's AS and network range. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Monday, January 12, 2009 5:00 PM To: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Jan 12, 2009, at 5:55 PM, Michienne Dixon wrote: > But isn't this method kind of related to how an network from the > Mediterranean/Mid-east went about blocking what they felt was > undesirable/offensive content from entering their network? No. -- TTFN, patrick From ren.provo at gmail.com Mon Jan 12 17:04:50 2009 From: ren.provo at gmail.com (Ren Provo) Date: Mon, 12 Jan 2009 18:04:50 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496BCAEF.6020401@psg.com> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> Message-ID: <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> Fair enough. Unfortunate, and I'll miss you in .DR, but understood. Now that doesn't mean other operators can't put in a lightning talk about the impact or 'event' this triggered in their own NOC environments along with what they recommend operators do to reduce the spun cycles Cheers, -ren On Mon, Jan 12, 2009 at 5:57 PM, Randy Bush wrote: > Could you please put in a lightning talk for this experiment? It would >> be great to hear more about this in .DR. We're accepting submissions now >> for lightning talks on Monday the 26th of January. >> > > a - i will not be in dr. i really wanted to support the dr meeting, > but it's hard to justify after four years of service. maybe i'll > make the next one. > > b - we can not present results before papers are submitted. > > c - we hope to present results at ops fora, nanog included, if they > are good enough to warrant as opposed to just good sensationalist > blah blah. > > randy > From mdixon at nkc.org Mon Jan 12 17:13:10 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Mon, 12 Jan 2009 17:13:10 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org><7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca><16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net><882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca><20090112222404.GA5587@ussenterprise.ufp.org><89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net><496BC876.8070704@psg.com><787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com><496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A16DA@nkc-mailsrv.nkc.org> Now that doesn't mean other operators can't put in a lightning talk about the impact or 'event' this triggered in their own NOC environments along with what they recommend operators do to reduce the spun cycles Easy - Refer all anomalies that do not the result of a direct outage to Randy. :D - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 From pstewart at nexicomgroup.net Mon Jan 12 17:13:53 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 12 Jan 2009 18:13:53 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> Message-ID: <89D27DE3375BB6428DDCC2927489826A01E70792@nexus.nexicomgroup.net> The alerts we got were because our AS number was showing up somewhere else in the world. Whether it's "legit" IP space or not - it still warrants investigation on a high priority from my perspective. I have nothing against Randy or anyone else involved with this project .. to be quite honest I'd be interesting in seeing/hearing the results ... but I believe a more careful approach is in order with consideration for the folks effected. Paul -----Original Message----- From: deleskie at gmail.com [mailto:deleskie at gmail.com] Sent: January 12, 2009 6:00 PM To: Michienne Dixon; NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 This was a test using unassigned IP block, unless I'm reading it wrong. If a noc alerted on this it should have still be a low priority issue. I don't see any issues with the way this was carried out at all. -jim ------Original Message------ From: Michienne Dixon To: NANOG list Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Sent: Jan 12, 2009 6:55 PM But isn't this method kind of related to how an network from the Mediterranean/Mid-east went about blocking what they felt was undesirable/offensive content from entering their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, January 12, 2009 4:47 PM To: Paul Stewart Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 09.01.13 07:42, Paul Stewart wrote: > For us, it was annoying - we look for prefix hijackings or what appear > to be. i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks. randy Sent from my BlackBerry device on the Rogers Wireless Network ---------------------------------------------------------------------------- "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." From randy at psg.com Mon Jan 12 17:20:28 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2009 08:20:28 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> Message-ID: <496BD03C.4080203@psg.com> > Now that doesn't mean other operators can't put in a lightning talk > about the impact or 'event' this triggered in their own NOC environments > along with what they recommend operators do to reduce the spun cycles great idea! as i was about to send to someone else with a thinner skin than you :) path poisoning is used operationally, though we suspect somewhat ill-advisedly. but the proof of the latter will be in the pudding. imiho, alarm systems that raise a real alert about my asn being in the as path of *someone else's prefix* are systems i would repair. at most, it's a "when you're bored, take a look at this strangeness." of course, we're sorry we set off folk's broken alarm systems :-) [ sense of humor required, leo ] and, fwiw, i liked the haiku! randy From nanog-post at rsuc.gweep.net Mon Jan 12 17:23:25 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 12 Jan 2009 18:23:25 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16DA@nkc-mailsrv.nkc.org> References: <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <6316CD198EC8BC44A9D200F375869F1E4A16DA@nkc-mailsrv.nkc.org> Message-ID: <20090112232325.GA14719@gweep.net> On Mon, Jan 12, 2009 at 05:13:10PM -0600, Michienne Dixon wrote: [snip] > Easy - Refer all anomalies that do not the result of a direct outage to > Randy. :D ...if he's the contact or expressly mentioned in the registration, that makes sense. Oh look, he is. %whonum 174.128.31.0 OrgName: American Registry for Internet Numbers OrgID: ARIN Address: 3635 Concorde Parkway Address: Suite 200 City: Chantilly StateProv: VA PostalCode: 20151 Country: US NetRange: 174.128.0.0 - 174.128.255.255 CIDR: 174.128.0.0/16 NetName: ARIN-REACHABILITY-TESTING NetHandle: NET-174-128-0-0-1 Parent: NET-174-0-0-0-0 NetType: Direct Assignment NameServer: RIP.PSG.COM NameServer: NS0.REM.COM Comment: This IP address block is being used by ARIN to conduct reachability testing in networks 173.0.0.0/8 and 174.0.0.0/8. Please contact randy at psg.com with feedback or questions on the testing. RegDate: 2008-02-27 Updated: 2008-02-27 OrgNOCHandle: ARINN-ARIN OrgNOCName: ARIN NOC OrgNOCPhone: +1-703-227-9840 OrgNOCEmail: noc at arin.net OrgTechHandle: ARIN-HOSTMASTER OrgTechName: Registration Services Department OrgTechPhone: +1-703-227-0660 OrgTechEmail: hostmaster at arin.net # ARIN WHOIS database, last updated 2009-01-11 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. % -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jbates at brightok.net Mon Jan 12 17:32:05 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 12 Jan 2009 17:32:05 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01E70792@nexus.nexicomgroup.net> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> <89D27DE3375BB6428DDCC2927489826A01E70792@nexus.nexicomgroup.net> Message-ID: <496BD2F5.7050600@brightok.net> Paul Stewart wrote: > The alerts we got were because our AS number was showing up somewhere > else in the world. Whether it's "legit" IP space or not - it still > warrants investigation on a high priority from my perspective. > Given the use of the ASN, I'm surprised that you place high priority of it showing up in other AS Paths. Of course, I can understand the issue of it indicates that a network has definitely isolated itself on purpose from your network (if your network runs without a default). I suspect part of this test is to determine if there are enough defaults to allow traffic through even though the route isn't being processed by certain networks (ie, it does not good to poison AS_PATH if defaults in general will allow DOS traffic to continue). Path poisoning has been around awhile and is even taught in classes of some router vendors as a way to alter traffic patterns. Of course, your AS may never have come up in such a situation. What Randy is doing, I suspect, is seeing if it does have any applicable uses, or if their assumptions are wrong. > I have nothing against Randy or anyone else involved with this project > .. to be quite honest I'd be interesting in seeing/hearing the results > ... but I believe a more careful approach is in order with consideration > for the folks effected. > What you request would probably cost more money and time than the project can afford. Not saying that such time and money shouldn't be spent, but it is what it is. For you, an email to nanog might suffice, but I doubt that every ASN which is being path poisoned is going to have representatives on nanog, or even reading mail at their whois contacts. Jack From m.hallgren at free.fr Mon Jan 12 17:32:36 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 13 Jan 2009 00:32:36 +0100 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090112232325.GA14719@gweep.net> References: <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <6316CD198EC8BC44A9D200F375869F1E4A16DA@nkc-mailsrv.nkc.org> <20090112232325.GA14719@gweep.net> Message-ID: <1231803156.7450.12.camel@home> Le lundi 12 janvier 2009 ? 18:23 -0500, Joe Provo a ?crit : > On Mon, Jan 12, 2009 at 05:13:10PM -0600, Michienne Dixon wrote: > [snip] > > Easy - Refer all anomalies that do not the result of a direct outage to > > Randy. :D > > ...if he's the contact or expressly mentioned in the registration, that > makes sense. Oh look, he is. Should be sufficient, yes. mh > > %whonum 174.128.31.0 > > OrgName: American Registry for Internet Numbers > OrgID: ARIN > Address: 3635 Concorde Parkway > Address: Suite 200 > City: Chantilly > StateProv: VA > PostalCode: 20151 > Country: US > > NetRange: 174.128.0.0 - 174.128.255.255 > CIDR: 174.128.0.0/16 > NetName: ARIN-REACHABILITY-TESTING > NetHandle: NET-174-128-0-0-1 > Parent: NET-174-0-0-0-0 > NetType: Direct Assignment > NameServer: RIP.PSG.COM > NameServer: NS0.REM.COM > Comment: This IP address block is being used by ARIN to conduct > reachability testing in networks 173.0.0.0/8 and 174.0.0.0/8. Please > contact randy at psg.com with feedback or questions on the testing. > RegDate: 2008-02-27 > Updated: 2008-02-27 > > OrgNOCHandle: ARINN-ARIN > OrgNOCName: ARIN NOC > OrgNOCPhone: +1-703-227-9840 > OrgNOCEmail: noc at arin.net > > OrgTechHandle: ARIN-HOSTMASTER > OrgTechName: Registration Services Department > OrgTechPhone: +1-703-227-0660 > OrgTechEmail: hostmaster at arin.net > > # ARIN WHOIS database, last updated 2009-01-11 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > % > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nanog at daork.net Mon Jan 12 18:05:27 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 13 Jan 2009 13:05:27 +1300 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496BD2F5.7050600@brightok.net> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> <89D27DE3375BB6428DDCC2927489826A01E70792@nexus.nexicomgroup.net> <496BD2F5.7050600@brightok.net> Message-ID: <1991E0C2-68DA-447F-A8A6-5F11080EFEA1@daork.net> On 13/01/2009, at 12:32 PM, Jack Bates wrote: > I suspect part of this test is to determine if there are enough > defaults to allow traffic through even though the route isn't being > processed by certain networks (ie, it does not good to poison > AS_PATH if defaults in general will allow DOS traffic to continue). A suggestion I made to Randy at APRICOT in early 2007 when he was presenting his BGP beacon bogon filter detection stuff[1] was that he could use AS_PATH poisoning to detect broken filters and topology between two ASes, not just the best route back to him from each AS. I think he thought it was a silly idea at the time, probably because of the massive amount of BGP updates that it would need. Maybe he changed his mind? But yes, your suggestion seems reasonable as well - detect the existence of access lists, as opposed to prefix lists. The announcement is required to all the intermediary ASNs because of uRPF. -- Nathan Ward [1] http://www.apricot.net/apricot2007/presentation/conference/plenary3-randy-bogon.pdf From bicknell at ufp.org Mon Jan 12 18:29:55 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 12 Jan 2009 19:29:55 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496BD03C.4080203@psg.com> References: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> Message-ID: <20090113002954.GA10395@ussenterprise.ufp.org> In a message written on Tue, Jan 13, 2009 at 08:20:28AM +0900, Randy Bush wrote: > of course, we're sorry we set off folk's broken alarm systems :-) [ > sense of humor required, leo ] Ah, I get the smiley this time. That's the indication you're not serious about the sentence you just wrote! Ah ha! So you're not sorry you've wasted a whole bunch of people's time today. You really should make some friends Randy. You know, the type of people who might have a network, and an ASN, and be ok with you injecting their ASN in wierd places and reporting back to you what happens. You might even be able to then get them to provide data on what sensors alerted, why they alerted, and other useful things. That seems both a lot more useful and respectful than dragging random third parties into your research project by force and having them turn to 10,000 of their closest friends to figure out what's going on. And no, I don't have a sense of humor about it. 44 messages of (mostly bad) haiku, and another 42 messages about the collateral damage of Randy's research project and how it pulls network engineers out of funerals. Even at only 10 seconds per message to see there is no operationally useful content that's 14 minutes of my life wasted today I will never get back. The S/N ratio of the list day has been 0. I guess the up side is that is only down slightly from normal. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jbates at brightok.net Mon Jan 12 18:33:17 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 12 Jan 2009 18:33:17 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <1991E0C2-68DA-447F-A8A6-5F11080EFEA1@daork.net> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> <89D27DE3375BB6428DDCC2927489826A01E70792@nexus.nexicomgroup.net> <496BD2F5.7050600@brightok.net> <1991E0C2-68DA-447F-A8A6-5F11080EFEA1@daork.net> Message-ID: <496BE14D.4020803@brightok.net> Nathan Ward wrote: > A suggestion I made to Randy at APRICOT in early 2007 when he was > presenting his BGP beacon bogon filter detection stuff[1] was that he > could use AS_PATH poisoning to detect broken filters and topology > between two ASes, not just the best route back to him from each AS. I think a lot of the work done actually provided good results. AS_PATH poisoning might have provided a few more clues on the return path. One thing I didn't see in the interpretation was that while some AS's were inconsistent with outbound probes, this leads one to believe that the IPs selected for the probes were most likely firewalls providing bogon filtering, and not bogon-filtering at an AS level. Having dealt with quite a few reachability issues in 69/8, I got to talk to some really redneck organizations that barely knew a thing about their firewall. This promises to be a much more interesting study, though I suspect it's heavily scoped due to the time it takes to run tests without being dampened. I presume there's at least one route acting as an anchor to detect dampening. If not, we can send Randy off to do it again. ;) Jack From pauldotwall at gmail.com Mon Jan 12 23:05:42 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 13 Jan 2009 00:05:42 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090113002954.GA10395@ussenterprise.ufp.org> References: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> Message-ID: <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> On Mon, Jan 12, 2009 at 7:29 PM, Leo Bicknell wrote: > You really should make some friends Randy. He is, on Second Life. Seriously though... I've not seen any discussion of the application of "allowas-in", a valid neighbor configuration under certain topologies/scenarios, as relates to impact today. Also, I'd agree announcing other peoples' ASNs, without their permission, is in bad form. It's okay he's doing it to you, but I bet Randy would be a lot less smiley if you were to announce random paths with 3130. Drive Slow, Paul Wall From bmanning at vacation.karoshi.com Mon Jan 12 23:16:44 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 13 Jan 2009 05:16:44 +0000 Subject: Why no SIDR for 174.128.31.0/24 In-Reply-To: <20090113002954.GA10395@ussenterprise.ufp.org> References: <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> Message-ID: <20090113051644.GA31742@vacation.karoshi.com.> On Mon, Jan 12, 2009 at 07:29:55PM -0500, Leo Bicknell wrote: > In a message written on Tue, Jan 13, 2009 at 08:20:28AM +0900, Randy Bush wrote: > > of course, we're sorry we set off folk's broken alarm systems :-) [ > > sense of humor required, leo ] > > Ah, I get the smiley this time. That's the indication you're not > serious about the sentence you just wrote! Ah ha! So you're not > sorry you've wasted a whole bunch of people's time today. > > You really should make some friends Randy. You know, the type of > people who might have a network, and an ASN, and be ok with you > injecting their ASN in wierd places and reporting back to you what > happens. You might even be able to then get them to provide data > on what sensors alerted, why they alerted, and other useful things. > That seems both a lot more useful and respectful than dragging > random third parties into your research project by force and having > them turn to 10,000 of their closest friends to figure out what's > going on. > > And no, I don't have a sense of humor about it. 44 messages of > (mostly bad) haiku, and another 42 messages about the collateral > damage of Randy's research project and how it pulls network engineers > out of funerals. Even at only 10 seconds per message to see there > is no operationally useful content that's 14 minutes of my life > wasted today I will never get back. > > The S/N ratio of the list day has been 0. I guess the up side is that > is only down slightly from normal. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ there is some indication that this prefix was assigned for a specific experiment, the experiment ran, results published, and then the prefix was not properly reclaimed... and so was reused for something else. sounds like a poster child for SIDR. --bill From bradk at vitalsoft.com Tue Jan 13 01:33:02 2009 From: bradk at vitalsoft.com (Brad Kollmyer) Date: Mon, 12 Jan 2009 23:33:02 -0800 Subject: Fiber Plant Tracking Database In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B9896520A4@fudd.ad.maine.edu> Message-ID: <49895789-861B-43D4-BAC2-3BC57D2679BA@vitalsoft.com> You could also look at OSPInSight: http://ospinsight.com/osp/ Brad. From jeroen at unfix.org Tue Jan 13 02:17:24 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 13 Jan 2009 09:17:24 +0100 Subject: Why no SIDR for 174.128.31.0/24 In-Reply-To: <20090113051644.GA31742@vacation.karoshi.com.> References: <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <20090113051644.GA31742@vacation.karoshi.com.> Message-ID: <496C4E14.3040403@spaghetti.zurich.ibm.com> bmanning at vacation.karoshi.com wrote: [..] > there is some indication that this prefix was assigned for > a specific experiment, the experiment ran, results published, > and then the prefix was not properly reclaimed... and so was > reused for something else. Interresting that you say that. Still using 3ffe::/24 and ip6.int I guess? :) You clearly thought you needed to keep your 'customers' connected on the 6bone using that block of space. Yesterday I found in somebody's email the following traceroute: > 2: 10gigabitethernet3-2.core1.sjc2.he.net 64.435ms > 3: 10gigabitethernet3-2.core1.pao1.he.net 59.724ms > 4: 3ffe:80a::b2 64.184ms > 5: hitachi1.otemachi.wide.ad.jp 203.714ms Yeah, it is alive, 6bone LIVES!!!!! [*] Gee another address-playspace of a certain someone. Seriously, some ISP's should finally after more than 2,5 years after that experiment called 6bone got closed down realize that PEERING over PAIX which is still using 6bone addresses is quite silly and routing those addresses is simply not done. Then again, don't know if Bill can do anything about this one as clearly the ISPs involved who are still using those addresses are to blame that they clearly do not care about their network, even though they very well know from over the years that 6bone was closed down and the address space returned to IANA. Then again, for those ISPs involved uRPF is also something hard to understand it seems. Greets, Jeroen -- [*] ipv6-site: ISI-LAP origin: AS4554 descr: LAP-EXCHANGE Los Angeles country: US prefix: 3FFE:800::/24 [..] contact: BM2-6BONE person: Bill Manning address: po 12317, mdr, ca. usa phone: +1.310.322.8102 e-mail: bmanning at isi.edu nic-hdl: BM2-6BONE [..] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From bmanning at vacation.karoshi.com Tue Jan 13 04:42:23 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 13 Jan 2009 10:42:23 +0000 Subject: Why no SIDR for 174.128.31.0/24 In-Reply-To: <496C4E14.3040403@spaghetti.zurich.ibm.com> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <20090113051644.GA31742@vacation.karoshi.com.> <496C4E14.3040403@spaghetti.zurich.ibm.com> Message-ID: <20090113104223.GA1074@vacation.karoshi.com.> On Tue, Jan 13, 2009 at 09:17:24AM +0100, Jeroen Massar wrote: > bmanning at vacation.karoshi.com wrote: > [..] > > there is some indication that this prefix was assigned for > > a specific experiment, the experiment ran, results published, > > and then the prefix was not properly reclaimed... and so was > > reused for something else. > > Interresting that you say that. Still using 3ffe::/24 and ip6.int I > guess? :) You clearly thought you needed to keep your 'customers' > connected on the 6bone using that block of space. you guess wrong. --bill From jeroen at unfix.org Tue Jan 13 05:00:11 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 13 Jan 2009 12:00:11 +0100 Subject: Why no SIDR for 174.128.31.0/24 In-Reply-To: <20090113104223.GA1074@vacation.karoshi.com.> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <20090113051644.GA31742@vacation.karoshi.com.> <496C4E14.3040403@spaghetti.zurich.ibm.com> <20090113104223.GA1074@vacation.karoshi.com.> Message-ID: <496C743B.5070803@spaghetti.zurich.ibm.com> bmanning at vacation.karoshi.com wrote: > On Tue, Jan 13, 2009 at 09:17:24AM +0100, Jeroen Massar wrote: >> bmanning at vacation.karoshi.com wrote: >> [..] >>> there is some indication that this prefix was assigned for >>> a specific experiment, the experiment ran, results published, >>> and then the prefix was not properly reclaimed... and so was >>> reused for something else. >> Interresting that you say that. Still using 3ffe::/24 and ip6.int I >> guess? :) You clearly thought you needed to keep your 'customers' >> connected on the 6bone using that block of space. > > you guess wrong. Not a guess, it is what you wrote, long live archives: http://www.mail-archive.com/nanog at nanog.org/msg00270.html has: 8<----------------------------- bmanning wrote: [..] Sure... there are only a few left. Got rid of two a couple weeks back. That said.... I will announce the prefix as long as people are using it. (whine away) [..] ----------------------------->8 Other references you probably still have unread in your mailbox. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From john at sackheads.org Tue Jan 13 07:55:40 2009 From: john at sackheads.org (John Payne) Date: Tue, 13 Jan 2009 08:55:40 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> References: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> Message-ID: <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> On Jan 13, 2009, at 12:05 AM, Paul Wall wrote: > On Mon, Jan 12, 2009 at 7:29 PM, Leo Bicknell > wrote: >> You really should make some friends Randy. > > He is, on Second Life. > > Seriously though... I've not seen any discussion of the application of > "allowas-in", a valid neighbor configuration under certain > topologies/scenarios, as relates to impact today. Also, I'd agree > announcing other peoples' ASNs, without their permission, is in bad > form. It's okay he's doing it to you, but I bet Randy would be a lot > less smiley if you were to announce random paths with 3130. You should've seen the email storm and panic created when I prepended an AS to avoid a blackhole. I got the right people interested in talking to me at least, but boy-o-boy were people confused about what I was doing. I guess the problem is that AS PATH is overloaded and people forget that the primary purpose is loop-avoidance. Everything else is secondary and much like reading Received headers in SMTP mail, you really should take everything after your direct neighbor's AS with a grain of salt. From jhorn at terremark.com Tue Jan 13 08:25:11 2009 From: jhorn at terremark.com (Joshua Snowhorn) Date: Tue, 13 Jan 2009 08:25:11 -0600 Subject: NANOG 45 Updates - Santo Domingo, Dominican Republic Message-ID: Greetings! We are fast approaching the start to the first NANOG outside of mainland North America in beautiful Santo Domingo, Dominican Republic. We are excited about the agenda and the spectacular venue (especially the weather). The agenda can be found here: http://www.nanog.org/meetings/nanog45/agenda.php As a reminder, full payment for standard registration (US$525) must be postmarked by 01/15/2009. Registration on or after January 16th as well as payments processed on-site will be US$600, so please hurry up and make your plans. The Dominican government is throwing a welcome party for all NANOG attendees at Columbus Square in the colonial district of Santo Domingo. This venue is surrounded by structures built as early as the 1400?s. The national dancers will be performing along with traditional music, food and drink. Busses will leave the NANOG hotel beginning at 7:30pm on Sunday the 25th and will circulate approximately every 10 minutes (the journey is less than 10 minutes). This is something not to be missed! We would also like to remind you that Lightning talk submissions are open and the Program Committee will be selecting the first three talks this week. If you have an idea, please submit an abstract as soon as possible. The earlier you submit, the better your chances at getting your talk accepted. http://www.nanogpc.org/lightning/ We all look forward to seeing you in 12 days for the start of an exciting NANOG! Cheers, Josh Josh Snowhorn as the NANOG 45 Host and for the Program Committee From jabley at hopcount.ca Tue Jan 13 08:34:19 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Jan 2009 09:34:19 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> References: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> Message-ID: <004DD505-BE3C-4B18-86F8-36E4F2CC3D73@hopcount.ca> On 2009-01-13, at 00:05, Paul Wall wrote: > Also, I'd agree > announcing other peoples' ASNs, How do you announce an ASN? Joe From thegameiam at yahoo.com Tue Jan 13 09:00:34 2009 From: thegameiam at yahoo.com (David Barak) Date: Tue, 13 Jan 2009 07:00:34 -0800 (PST) Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> Message-ID: <5199.11537.qm@web31808.mail.mud.yahoo.com> --- On Mon, 1/12/09, deleskie at gmail.com wrote: > This was a test using unassigned IP block, unless I'm > reading it wrong. If a noc alerted on this it should have > still be a low priority issue. I don't see any issues > with the way this was carried out at all. > > -jim I completely agree with Jim: I have no idea why alert thresholds are set to a level of sensitivity which would cause this to become a "must be dealt with this minute" sort of issue. What exactly is the threat potential of someone else's IP space being announced with your ASN prepended? If the concern was a Pilosov/Kapela style hijack, wouldn't the first thing you'd check be what the address range was? That would lead you straight to Randy, and that should have cleared up the matter straightaway. Remember: the owner of the IP space is the victim, not the ASN which gets prepended into the path... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From jared at puck.nether.net Tue Jan 13 09:06:31 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 Jan 2009 10:06:31 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <5199.11537.qm@web31808.mail.mud.yahoo.com> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> <5199.11537.qm@web31808.mail.mud.yahoo.com> Message-ID: <20090113150631.GA16177@puck.nether.net> On Tue, Jan 13, 2009 at 07:00:34AM -0800, David Barak wrote: > If the concern was a Pilosov/Kapela style hijack, wouldn't the first thing you'd check be what the address range was? That would lead you straight to Randy, and that should have cleared up the matter straightaway. Remember: the owner of the IP space is the victim, not the ASN which gets prepended into the path... > No, they are both victims. If I inject a path that purports there is an edge between two networks which are engaged in a bitter dispute, (i'll use cogent & sprint as an example) - _1239_174_ that may create a situation where someone asserts that their routes are being filtered when infact no connectivity exists. Does that mean that I hijacked their identiy and forged it? What level of trust do you place in the AS_PATH for your routing, debugging and decision making process? Personally, I would be upset if someone injected a route with my ASN in the AS_PATH without my permission. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From cmadams at hiwaay.net Tue Jan 13 09:12:18 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 13 Jan 2009 09:12:18 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <5199.11537.qm@web31808.mail.mud.yahoo.com> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> <5199.11537.qm@web31808.mail.mud.yahoo.com> Message-ID: <20090113151218.GD1469688@hiwaay.net> Once upon a time, David Barak said: > I completely agree with Jim: I have no idea why alert thresholds are > set to a level of sensitivity which would cause this to become a "must > be dealt with this minute" sort of issue. What exactly is the threat > potential of someone else's IP space being announced with your ASN > prepended? The threat that it is the first prefix like that and maybe not the last. It could be an accidental (or intentional) mistake, and should be tracked down ASAP to make sure that is the only such prefix. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From drc at virtualized.org Tue Jan 13 09:29:58 2009 From: drc at virtualized.org (David Conrad) Date: Tue, 13 Jan 2009 07:29:58 -0800 Subject: Why no SIDR for 174.128.31.0/24 In-Reply-To: <496C4E14.3040403@spaghetti.zurich.ibm.com> References: <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <20090113051644.GA31742@vacation.karoshi.com.> <496C4E14.3040403@spaghetti.zurich.ibm.com> Message-ID: <7C60C5C5-3A58-4F1B-BDB5-8A98B6FE6E92@virtualized.org> On Jan 13, 2009, at 12:17 AM, Jeroen Massar wrote: > Interresting that you say that. Still using 3ffe::/24 and ip6.int I > guess? :) The delegation for ip6.int was removed quite some time ago. Regards, -drc From deleskie at gmail.com Tue Jan 13 09:33:57 2009 From: deleskie at gmail.com (jim deleskie) Date: Tue, 13 Jan 2009 11:33:57 -0400 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090113150631.GA16177@puck.nether.net> References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry> <5199.11537.qm@web31808.mail.mud.yahoo.com> <20090113150631.GA16177@puck.nether.net> Message-ID: Jared, Fine which makes it an interesting data point and something to look at after lunch when I'm not doing something else kinda issue. Not something I'm going to treat as a P1 and drop everything work or real life related for. I'm not say it shouldn't be looked it, just that in the grand scheme of the thing its not a huge issue. Kinda like when people feel the need to tune IGP time sub second convergence but do impactful maint on routers or circuits 3-4 times a yr. If you lock the doggie door but leave the front door open the bad guys can walk right in. :) -jim On Tue, Jan 13, 2009 at 11:06 AM, Jared Mauch wrote: > On Tue, Jan 13, 2009 at 07:00:34AM -0800, David Barak wrote: >> If the concern was a Pilosov/Kapela style hijack, wouldn't the first thing you'd check be what the address range was? That would lead you straight to Randy, and that should have cleared up the matter straightaway. Remember: the owner of the IP space is the victim, not the ASN which gets prepended into the path... >> > > No, they are both victims. If I inject a path that purports > there is an edge between two networks which are engaged in a bitter > dispute, (i'll use cogent & sprint as an example) - _1239_174_ that may > create a situation where someone asserts that their routes are > being filtered when infact no connectivity exists. > > Does that mean that I hijacked their identiy and forged it? What > level of trust do you place in the AS_PATH for your routing, debugging and > decision making process? > > Personally, I would be upset if someone injected a route with my > ASN in the AS_PATH without my permission. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > From pstewart at nexicomgroup.net Tue Jan 13 09:52:49 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 13 Jan 2009 10:52:49 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <819246436-1231801260-cardhu_decombobulator_blackberry.rim.net-1695438361-@bxe125.bisx.prod.on.blackberry><5199.11537.qm@web31808.mail.mud.yahoo.com><20090113150631.GA16177@puck.nether.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A01E708A1@nexus.nexicomgroup.net> Hi Jim... We treated it with P1 until we realized it was a total waste of our time. It was the point of it too... About 6 months ago we had a similar alarm (on the surface) where someone in Europe was advertising our AS number. After some careful checking it seemed to be simply a typo error but after about 20 minutes of it showing up in a path it disappeared and they started actually advertising one of our IP blocks and were able to do so due to lack of proper filtering on their upstream. If we had not been paying attention to this "little detail" it would have taken us more time to react and trace down what we going on - by paying attention we had several details already accounted for. The whole issue lasted about 30 minutes at which point their upstream provider had been notified and cut off their customer until proper filtering was put back into place. I'll admit that was the only time we've ever had an issue or until this new incident an alarm condition. So, now for "academic purposes" we see another alarm and fear the worst. Yes, treating it as a P1 makes sense for us so far - we're batting 50/50 for legit problems with this stuff. Paul -----Original Message----- From: jim deleskie [mailto:deleskie at gmail.com] Sent: Tuesday, January 13, 2009 10:34 AM To: Jared Mauch Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 Jared, Fine which makes it an interesting data point and something to look at after lunch when I'm not doing something else kinda issue. Not something I'm going to treat as a P1 and drop everything work or real life related for. I'm not say it shouldn't be looked it, just that in the grand scheme of the thing its not a huge issue. Kinda like when people feel the need to tune IGP time sub second convergence but do impactful maint on routers or circuits 3-4 times a yr. If you lock the doggie door but leave the front door open the bad guys can walk right in. :) -jim On Tue, Jan 13, 2009 at 11:06 AM, Jared Mauch wrote: > On Tue, Jan 13, 2009 at 07:00:34AM -0800, David Barak wrote: >> If the concern was a Pilosov/Kapela style hijack, wouldn't the first thing you'd check be what the address range was? That would lead you straight to Randy, and that should have cleared up the matter straightaway. Remember: the owner of the IP space is the victim, not the ASN which gets prepended into the path... >> > > No, they are both victims. If I inject a path that purports > there is an edge between two networks which are engaged in a bitter > dispute, (i'll use cogent & sprint as an example) - _1239_174_ that may > create a situation where someone asserts that their routes are > being filtered when infact no connectivity exists. > > Does that mean that I hijacked their identiy and forged it? What > level of trust do you place in the AS_PATH for your routing, debugging and > decision making process? > > Personally, I would be upset if someone injected a route with my > ASN in the AS_PATH without my permission. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > ---------------------------------------------------------------------------- "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." From bicknell at ufp.org Tue Jan 13 10:12:49 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Jan 2009 11:12:49 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> Message-ID: <20090113161248.GA64292@ussenterprise.ufp.org> In a message written on Tue, Jan 13, 2009 at 08:55:40AM -0500, John Payne wrote: > I guess the problem is that AS PATH is overloaded and people forget > that the primary purpose is loop-avoidance. Everything else is > secondary and much like reading Received headers in SMTP mail, you > really should take everything after your direct neighbor's AS with a > grain of salt. Actually, I'd suggest your not looking at the primary purpose close enough. Loop detection kicks in only when there is a loop. You see your own ASN coming back to you. In the case we're discussing THERE IS NO LOOP. Someone is mis-using this feature to control the propagation of routes. Were the victim to do a show ip bgp neighbor foo receive-routes and see their own path they would be reasonable to assume that there is a loop, and someone is reflecting their own route back to them. This is a human configuring a device to lie about the loop status in the network. That is also the problem with this method, it is exactly the opposite of what the attribute was meant to convey, and thus someone on the other end who doesn't know what you're doing is virtually guaranteed to make the wrong assumption. You're going to spin up network engineers looking for routing loops, route leaks, and other issues if you use this method. I'd also suggest, as Jared pointed out, there are potential libel / trade-dress / slander implications here. Sending out an AS-Path of "ASfoo ASbar" is the technological equivalent of the English statement "foo and bar are interconnected with BGP". Just because you hide a false statement in an AS-Path doesn't make it any less of a false statement. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From thegameiam at yahoo.com Tue Jan 13 10:53:42 2009 From: thegameiam at yahoo.com (David Barak) Date: Tue, 13 Jan 2009 08:53:42 -0800 (PST) Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090113150631.GA16177@puck.nether.net> Message-ID: <494779.53806.qm@web31810.mail.mud.yahoo.com> --- On Tue, 1/13/09, Jared Mauch wrote: > > No, they are both victims. If I inject a path that > purports > there is an edge between two networks which are engaged in > a bitter > dispute, (i'll use cogent & sprint as an example) - > _1239_174_ that may > create a situation where someone asserts that their routes > are > being filtered when infact no connectivity exists. That's a theoretical possibility, but who would be the one doing the asserting? I would argue that it would either be the owner of the announced space or someone trying to reach it. In this case, nobody was trying to reach the /24 in question, and the owner was the one doing the experiment. Victimless crime, at most. > > Does that mean that I hijacked their identiy and forged > it? What level of trust do you place in the AS_PATH for your > routing, debugging and > decision making process? AS_PATH != identity, and I would not recommend loading the latter onto the former. > > Personally, I would be upset if someone injected a route > with my ASN in the AS_PATH without my permission. Why? Is this a theoretical "because it's ugly" complaint, or is there a reason why manipulating this particular BGP attribute in this particular way is so bad? Organizations do filtering and routing manipulation all over the place. Is there something worse about doing it this way than others? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From matthew at eeph.com Tue Jan 13 11:11:15 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Tue, 13 Jan 2009 09:11:15 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <004DD505-BE3C-4B18-86F8-36E4F2CC3D73@hopcount.ca> References: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <20090112222404.GA5587@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <004DD505-BE3C-4B18-86F8-36E4F2CC3D73@hopcount.ca> Message-ID: <2D4461A7-39C6-463D-9C28-A1B5EA8A00F7@eeph.com> On Jan 13, 2009, at 6:34 AM, Joe Abley wrote: > > On 2009-01-13, at 00:05, Paul Wall wrote: > >> Also, I'd agree >> announcing other peoples' ASNs, > > How do you announce an ASN? > Clearly it means to use someone else's ASN without authorization in a way that is not intended by the org/person it I'd assigned to. In a place where people get arrested, charged, tried, *and convicted* of lying about who they are in a MySpace profile, I would be wary of injecting other people's IP adresses *or* ASNs, even if it seems like a good experiment. Personally, I think there's nothing to complain about here, and I'm looking forward to the published results and I'm glad there's people with the time/funding to conduct wide-scale experiments... But then I'm ok with people who don't put their real age in their MySpace profile too. Matthew Kaufman (sent from my copy/paste-free iPhone) From martin at theicelandguy.com Tue Jan 13 11:16:08 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 13 Jan 2009 12:16:08 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <2D4461A7-39C6-463D-9C28-A1B5EA8A00F7@eeph.com> References: <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <004DD505-BE3C-4B18-86F8-36E4F2CC3D73@hopcount.ca> <2D4461A7-39C6-463D-9C28-A1B5EA8A00F7@eeph.com> Message-ID: On Tue, Jan 13, 2009 at 12:11 PM, Matthew Kaufman wrote: > On Jan 13, 2009, at 6:34 AM, Joe Abley wrote: > > >> On 2009-01-13, at 00:05, Paul Wall wrote: >> >> Also, I'd agree >>> announcing other peoples' ASNs, >>> >> >> How do you announce an ASN? >> >> > Clearly it means to use someone else's ASN without authorization in a way > that is not intended by the org/person it I'd assigned to. > > I think that this is really a matter of being able to opt out, preferably in, to these public network experiments. This type of thing has a correlation to events past. No reason to raise dead bodies, but we've seen this before and have dealt swiftly, and decisively all based on choice. Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From patrick at ianai.net Tue Jan 13 11:31:12 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 12:31:12 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <494779.53806.qm@web31810.mail.mud.yahoo.com> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> Message-ID: <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> On Jan 13, 2009, at 11:53 AM, David Barak wrote: > --- On Tue, 1/13/09, Jared Mauch wrote: >> >> No, they are both victims. If I inject a path that >> purports >> there is an edge between two networks which are engaged in >> a bitter >> dispute, (i'll use cogent & sprint as an example) - >> _1239_174_ that may >> create a situation where someone asserts that their routes >> are >> being filtered when infact no connectivity exists. > > That's a theoretical possibility, but who would be the one doing the > asserting? I would argue that it would either be the owner of the > announced space or someone trying to reach it. In this case, nobody > was trying to reach the /24 in question, and the owner was the one > doing the experiment. Victimless crime, at most. Interesting. You think it is OK to use my my ASN for things as long as no one is trying to do those things? >> Does that mean that I hijacked their identiy and forged >> it? What level of trust do you place in the AS_PATH for your >> routing, debugging and >> decision making process? > > AS_PATH != identity, and I would not recommend loading the latter > onto the former. We disagree. When I am researching something, I frequently look at ASNs in the path to figure out not just where but who controls the path. >> Personally, I would be upset if someone injected a route >> with my ASN in the AS_PATH without my permission. > > Why? Is this a theoretical "because it's ugly" complaint, or is > there a reason why manipulating this particular BGP attribute in > this particular way is so bad? Organizations do filtering and > routing manipulation all over the place. Is there something worse > about doing it this way than others? Filtering and other manipulation happened on your router, prepending my ASN is putting that information into every router. That seems to be a serious qualitative difference to me. Do you disagree? This thread has been interesting & educational. So many people seem to be happy to explain why they should be allowed to use globally unique identifiers they do not own in ways which were not intended, then explain to the people who do own those identifiers how they should react, which alarms should go off, and even which priority the alarms should have. As I have repeated probably hundreds of times: Your network, your decision. I have yet to hear a credible argument against that stance. What you do _inside_ your network is _your_ decision. When it leaves your network, however, things change. Announcing an ASN which is not yours to eBGP peers means it is leaving your network, which means it is not just your business. Doing so and then telling the ASN owner that they should not worry about it afterwards - and in fact arguing when the owner repeatedly tells you this caused them problems - does not seem to be the proper course of action. I mentioned earlier in the thread if Cogent prepending Sprint's ASN to Verio, people would react differently. Randy said tools can be used for good or bad, obviously implying he's the good guy. He is not the good guy. He used someone else's resources without their permission and without even notifying them, costing them time & effort. Randy doesn't get to decide if the ASN owner should have alerted or investigated or whatever, and neither do any of you unless it is your ASN. How can anyone seriously argue the ASN owner is somehow wrong and keep a straight face? How can anyone else who actually runs a network not see that as ridiculous? -- TTFN, patrick From jcdill.lists at gmail.com Tue Jan 13 11:41:46 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 13 Jan 2009 09:41:46 -0800 Subject: Are you getting Spam from Crossfire Media? Message-ID: <496CD25A.8010504@gmail.com> 4 weeks ago I started getting weekly spam from Carl at crossfiremedia.com. I have been "subscribed" to this newsletter. Today's spam subject line is "Get to 4GWE and Participate in the Wireless Future, We'll help pay your way..." The address used is an address I used on NANOG some years back - I haven't used it in quite a while but still get an occasional private email from someone who has that address in their address book so the address is still active. Because there's a remote chance that some time long ago I "subscribed" to some message board and hidden in the message board settings is a pre-checked option (which I overlooked) to receive email from "partners", I privately emailed several friends in the IT/Security fields asking if they were getting this spam. The one friend who is also getting this spam is also someone who occasionally posts to NANOG, and who also has no idea why he was "subscribed" to this spam. Because of this coincidence, I think the spammer may have scarfed email addresses of people who posted to NANOG and added them to the "targeted" mailing list / spam list. I'm curious to know if other NANOG subscribers have started receiving spam from this person. I also found 2 sites that have web interfaces to their NANOG archives where they are not obscuring email addresses and who leaked posting addresses onto the web: http://www.google.com/search?q=lists05%40equinephotoart.com+nanog Is there someone at NANOG who can ask these sites to remove these archives, or at least purge/munge email addresses? Please reply via private email. Thanks! jc From thegameiam at yahoo.com Tue Jan 13 12:11:54 2009 From: thegameiam at yahoo.com (David Barak) Date: Tue, 13 Jan 2009 10:11:54 -0800 (PST) Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> Message-ID: <246673.59963.qm@web31807.mail.mud.yahoo.com> --- On Tue, 1/13/09, Patrick W. Gilmore wrote: > > AS_PATH != identity, and I would not recommend loading > the latter onto the former. > > We disagree. When I am researching something, I frequently > look at ASNs in the path to figure out not just where but > who controls the path. Oh, I certainly think that there is a loose coupling there, and the relationship is highly valuable from a troubleshooting point of view. However, I would counsel anyone investigating AS_Path relationships to remember that do not completely characterize the relationship between any two organizations, let alone the multipolar relationships between all organizations. It's a good first-cut, but it doesn't have the level of authority that you're implying. I'm not aware of any ASNs being trademarked... > >> Personally, I would be upset if someone injected > a route > >> with my ASN in the AS_PATH without my permission. > > > > Why? Is this a theoretical "because it's > ugly" complaint, or is there a reason why manipulating > this particular BGP attribute in this particular way is so > bad? Organizations do filtering and routing manipulation > all over the place. Is there something worse about doing it > this way than others? > > Filtering and other manipulation happened on your router, > prepending my ASN is putting that information into every > router. That seems to be a serious qualitative difference > to me. Do you disagree? This is qualitatively similar to an ASN announcing de-aggregated routes - it may be nice if they don't, and you don't have to accept them, but are they permitted? > > > This thread has been interesting & educational. So > many people seem to be happy to explain why they should be > allowed to use globally unique identifiers they do not own > in ways which were not intended, then explain to the people > who do own those identifiers how they should react, which > alarms should go off, and even which priority the alarms > should have. > > As I have repeated probably hundreds of times: Your > network, your decision. I have yet to hear a credible > argument against that stance. What you do _inside_ your > network is _your_ decision. When it leaves your network, > however, things change. Exactly! Provider RB announces $WEIRD. A bunch of providers receive alarms about the existence of $WEIRD, and they treated this as $IMPORTANT. The bunch of providers who treated this as $IMPORTANT are informing all of us about their monitoring thresholds and their responses to this threshold being met. Their networks, their decisions. It should be pointed out that pre-provisioned AS_Path filters and prefix-lists would actually be effective at defeating this and preventing someone who is actually malicious from using this technique. This is an excellent argument for implementing SIDR... > > Announcing an ASN which is not yours to eBGP peers means it > is leaving your network, which means it is not just your > business. Doing so and then telling the ASN owner that they > should not worry about it afterwards - and in fact arguing > when the owner repeatedly tells you this caused them > problems - does not seem to be the proper course of action. Understood, but if this is viewed as problematic, there is a very simple solution: don't allow a BGP customer (or peer!) to prepend someone else's ASN. > > > I mentioned earlier in the thread if Cogent prepending > Sprint's ASN to Verio, people would react differently. > Randy said tools can be used for good or bad, obviously > implying he's the good guy. He is not the good guy. He > used someone else's resources without their permission > and without even notifying them, costing them time & > effort. Randy doesn't get to decide if the ASN owner > should have alerted or investigated or whatever, and > neither do any of you unless it is your ASN. > > How can anyone seriously argue the ASN owner is somehow > wrong and keep a straight face? How can anyone else who > actually runs a network not see that as ridiculous? Are any providers going to implement ^ASN filtering as a result of this experiment? This could turn out to be a very inexpensive lesson, which is far preferable to more expensive lessons... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From matthew at eeph.com Tue Jan 13 12:18:13 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Tue, 13 Jan 2009 10:18:13 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> Message-ID: <496CDAE5.9060008@eeph.com> Patrick W. Gilmore wrote: > Filtering and other manipulation happened on your router, prepending my > ASN is putting that information into every router. That seems to be a > serious qualitative difference to me. Do you disagree? > I think the basic disagreement is whether you think that "your stuff" is "select from internet where ASN is mine AND IP_ADDRESS is mine" or your stuff is "select from internet where ASN is mine OR IP_ADDRESS is mine". The person conducting the experiment clearly thought it was ok to use "your ASN" as long as it was "his address" that was being announced, since as long as it is "his address" he's allowed to put whatever he wants in the AS PATH he announces to the world for it. ("I can list whatever I want as my age, it is my profile after all") Others clearly think it is not ok to use "their ASN" with *any* address, and that even though it is "his address" he is only allowed to put numbers in the AS PATH that he has permission to put there. ("The terms of service say you must state your actual age in your profile so that state laws about what minors can/can't do/see can be complied with") And of course nobody cares about the *other* integers that are involved in announcements, just the 32-bit ones that represent IP addresses and the 16- and 32-bit ones that represent ASNs. People who don't understand (like jurors) would probably be confused and/or think we're all crazy for arguing about this stuff. Matthew Kaufman From patrick at ianai.net Tue Jan 13 12:20:48 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 13:20:48 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <246673.59963.qm@web31807.mail.mud.yahoo.com> References: <246673.59963.qm@web31807.mail.mud.yahoo.com> Message-ID: On Jan 13, 2009, at 1:11 PM, David Barak wrote: > --- On Tue, 1/13/09, Patrick W. Gilmore wrote: >>>> Personally, I would be upset if someone injected >> a route >>>> with my ASN in the AS_PATH without my permission. >>> >>> Why? Is this a theoretical "because it's >> ugly" complaint, or is there a reason why manipulating >> this particular BGP attribute in this particular way is so >> bad? Organizations do filtering and routing manipulation >> all over the place. Is there something worse about doing it >> this way than others? >> >> Filtering and other manipulation happened on your router, >> prepending my ASN is putting that information into every >> router. That seems to be a serious qualitative difference >> to me. Do you disagree? > > This is qualitatively similar to an ASN announcing de-aggregated > routes - it may be nice if they don't, and you don't have to accept > them, but are they permitted? No it is not. You own the prefix in question, so you own the deaggregates of it. You do not own the ASN in question. That you do not see the difference explains a great deal. >> This thread has been interesting & educational. So >> many people seem to be happy to explain why they should be >> allowed to use globally unique identifiers they do not own >> in ways which were not intended, then explain to the people >> who do own those identifiers how they should react, which >> alarms should go off, and even which priority the alarms >> should have. >> >> As I have repeated probably hundreds of times: Your >> network, your decision. I have yet to hear a credible >> argument against that stance. What you do _inside_ your >> network is _your_ decision. When it leaves your network, >> however, things change. > > Exactly! Provider RB announces $WEIRD. A bunch of providers > receive alarms about the existence of $WEIRD, and they treated this > as $IMPORTANT. The bunch of providers who treated this as > $IMPORTANT are informing all of us about their monitoring thresholds > and their responses to this threshold being met. Their networks, > their decisions. Wow. Just .. wow. "Exactly, even though I do something with your resources, announcing to the whole world, that cause you issues, you shouldn't tell me about because the alarms are inside your network." Again, this explains a great deal. > It should be pointed out that pre-provisioned AS_Path filters and > prefix-lists would actually be effective at defeating this and > preventing someone who is actually malicious from using this > technique. This is an excellent argument for implementing SIDR... Finally we agree. Although I am not certain SIDR is the optimal answer, we agree it would solve the problem. >> Announcing an ASN which is not yours to eBGP peers means it >> is leaving your network, which means it is not just your >> business. Doing so and then telling the ASN owner that they >> should not worry about it afterwards - and in fact arguing >> when the owner repeatedly tells you this caused them >> problems - does not seem to be the proper course of action. > > Understood, but if this is viewed as problematic, there is a very > simple solution: don't allow a BGP customer (or peer!) to prepend > someone else's ASN. How do you suppose I stop Randy from prepending my ASN? -- TTFN, patrick From jared at puck.nether.net Tue Jan 13 12:24:05 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 Jan 2009 13:24:05 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <494779.53806.qm@web31810.mail.mud.yahoo.com> References: <20090113150631.GA16177@puck.nether.net> <494779.53806.qm@web31810.mail.mud.yahoo.com> Message-ID: <20090113182405.GA75380@puck.nether.net> On Tue, Jan 13, 2009 at 08:53:42AM -0800, David Barak wrote: > --- On Tue, 1/13/09, Jared Mauch wrote: > > Does that mean that I hijacked their identiy and forged > > it? What level of trust do you place in the AS_PATH for your > > routing, debugging and > > decision making process? > > AS_PATH != identity, and I would not recommend loading the latter > onto the former. But it does represent an interesting thing. Many people treat AS_PATH as identiy, when infact it's not congruent. > > Personally, I would be upset if someone injected a route > > with my ASN in the AS_PATH without my permission. > > Why? Is this a theoretical "because it's ugly" complaint, or is there a > reason why manipulating this particular BGP attribute in this particular > way is so bad? Organizations do filtering and routing manipulation all > over the place. Is there something worse about doing it this way than others? This is not "because it's ugly", but more complex to understand the interaction. People have asserted that injecting an as-path with 2914 will utilize the loop-detection mechanisim to prevent reachability if your transit is from 1239 or 174. Except that 174 filters out these asns from their customers. I've noticed zero complaints since my 'detecting routing leaks by counting' system was presented at nanog that were not actual leaks when too many SFI (tier-1?) asns showed up in a path. While most of the challenge could be uneducated readers of an as-path, without the protocol being changed, it really depends on the elements in the path being genuine. Without this trust, we should all configure our routers to allow our own as in, or work to make it the new default, and ask providers to change their filtering of other SFI asns from their customer as-paths. - jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From adrian at creative.net.au Tue Jan 13 12:27:04 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 14 Jan 2009 03:27:04 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> Message-ID: <20090113182704.GB30027@skywalker.creative.net.au> On Tue, Jan 13, 2009, Patrick W. Gilmore wrote: > How can anyone seriously argue the ASN owner is somehow wrong and keep > a straight face? How can anyone else who actually runs a network not > see that as ridiculous? Speaking purely as an outsider who hasn't had to pull such jack moves with his tiny corner of the world these days, I've frequently seen people pull exactly these jack moves for Traffic Engineering. So either they're not talking and wish to remain nameless, or they're talking and being hypocritical. But they do exist, and I'm pretty sure they see it as another way of "hacking" the routing system to achieve goals the original implementors didn't explicitly define, but have operational relevance today. But they're out there, injecting routes to peers to control traffic. I remember the first time I saw it and said "uhm wtf?" followed by "evil but clever." Much like other BGP tricks. :) (Ah, how the internet seems to have grown up. Sniff.) Adrian From patrick at ianai.net Tue Jan 13 12:56:25 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 13:56:25 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496CDAE5.9060008@eeph.com> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> <496CDAE5.9060008@eeph.com> Message-ID: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> On Jan 13, 2009, at 1:18 PM, Matthew Kaufman wrote: > Patrick W. Gilmore wrote: >> Filtering and other manipulation happened on your router, >> prepending my ASN is putting that information into every router. >> That seems to be a serious qualitative difference to me. Do you >> disagree? > > I think the basic disagreement is whether you think that "your > stuff" is "select from internet where ASN is mine AND IP_ADDRESS is > mine" or your stuff is "select from internet where ASN is mine OR > IP_ADDRESS is mine". There is no disagreement here. If you believe the ASN assigned to me for which I paid is not mine, you are confused. > The person conducting the experiment clearly thoughght it was ok to > use "your ASN" as long as it was "his address" that was being > announced, since as long as it is "his address" he's allowed to put > whatever he wants in the AS PATH he announces to the world for it. > ("I can list whatever I want as my age, it is my profile after all") Randy is well aware it was not his ASN, no matter whose prefix it was. > Others clearly think it is not ok to use "their ASN" with *any* > address, and that even though it is "his address" he is only allowed > to put numbers in the AS PATH that he has permission to put there. > ("The terms of service say you must state your actual age in your > profile so that state laws about what minors can/can't do/see can be > complied with") > > And of course nobody cares about the *other* integers that are > involved in announcements, just the 32-bit ones that represent IP > addresses and the 16- and 32-bit ones that represent ASNs. People > who don't understand (like jurors) would probably be confused and/or > think we're all crazy for arguing about this stuff. Fortunately, people who run networks are not clueless ("jurors"?). Or at least they are not supposed to be clueless. An ASN is a well defined resource, with publicly available ownership information. If anyone on this list does not understand this, I suggest they do some more studying. -- TTFN, patrick From patrick at ianai.net Tue Jan 13 13:06:10 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 14:06:10 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090113182704.GB30027@skywalker.creative.net.au> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> <20090113182704.GB30027@skywalker.creative.net.au> Message-ID: On Jan 13, 2009, at 1:27 PM, Adrian Chadd wrote: > On Tue, Jan 13, 2009, Patrick W. Gilmore wrote: > >> How can anyone seriously argue the ASN owner is somehow wrong and >> keep >> a straight face? How can anyone else who actually runs a network not >> see that as ridiculous? > > Speaking purely as an outsider who hasn't had to pull such jack moves > with his tiny corner of the world these days, I've frequently seen > people > pull exactly these jack moves for Traffic Engineering. > > So either they're not talking and wish to remain nameless, or they're > talking and being hypocritical. But they do exist, and I'm pretty sure > they see it as another way of "hacking" the routing system to achieve > goals the original implementors didn't explicitly define, but have > operational relevance today. > > But they're out there, injecting routes to peers to control traffic. > I remember the first time I saw it and said "uhm wtf?" followed by > "evil but clever." Much like other BGP tricks. :) The idea that you can do something and get away with it sometimes makes it OK all the time is erroneous. Extreme example: Sprint probably wouldn't post to NANOG or even complain if a little network announced one of their prefixes. Does that make it OK for any network to announce anyone else's prefix? Obviously not. The fact is someone -did- notice, and instead of saying "I'm sorry, I won't do it again", Randy just said "I'm a good guy, doing an experiment" and implied it could not possibly be wrong. Worse, others actually berated the ASN owner for spending time & effort on the issue. If you use my ASN for an experiment or anything else without permission, do not act surprised when I notice. And certainly do not try to act like it is just no big deal. Use your own autonomous system numbers if you want it to be "no big deal". -- TTFN, patrick From a.harrowell at gmail.com Tue Jan 13 13:19:08 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 13 Jan 2009 19:19:08 +0000 Subject: Hushmail postmaster Message-ID: If you're on the list, can you contact me? You're being used to send out spam through your tagline.hushmail.com service, which redirects to arbitrary URLs either by design or because it's been compromised. Google shows it's cropping up in list archives all over the place. ( http://www.google.co.uk/search?q=tagline.hushmail.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a ) PGP-encrypted spam....I would think this is a serious issue for a privacy/security-focused operation. I've filled in the web form a couple of days ago, but no joy and no ticket number. Alexander Harrowell From matthew at eeph.com Tue Jan 13 13:27:38 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Tue, 13 Jan 2009 11:27:38 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> <496CDAE5.9060008@eeph.com> <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> Message-ID: <496CEB2A.3040905@eeph.com> Patrick W. Gilmore wrote: > Fortunately, people who run networks are not clueless ("jurors"?). Or > at least they are not supposed to be clueless. If Randy were to be charged under any of the various computer abuse statutes (which, given the history of their (ab)use, he certainly could be), jurors are who would be trying to figure out whether or not it was ok to use "your" integer in a specific place in the BGP announcement he made. That's why *I* wouldn't have run such an experiment myself, because there's just too many cases these days where people have gotten convicted of doing things like putting the wrong integer in their MySpace profile. > An ASN is a well defined resource, with publicly available ownership > information. If anyone on this list does not understand this, I suggest > they do some more studying. It is an integer. Under ARIN policy you certainly don't "own" it, you just use it. In some places, that integer has meaning. How important that meaning is, and whether or not someone else can use the same integer in a similar place where it has that meaning without getting charged with a crime, we don't know. What we *do* know is that some people think it is valuable to try it out to get some experimental data, and other people are all up in arms about it. Matthew Kaufman From reygue at gmail.com Tue Jan 13 13:43:24 2009 From: reygue at gmail.com (Reynold Guerrier) Date: Tue, 13 Jan 2009 14:43:24 -0500 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <496CD25A.8010504@gmail.com> References: <496CD25A.8010504@gmail.com> Message-ID: <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> My subscription to NANOG aged 3 months ago and I am receiving this spam too. And this is my first post. I effectively think that someone might have crack the email database of the Nanog list. Reynold On Tue, Jan 13, 2009 at 12:41 PM, JC Dill wrote: > 4 weeks ago I started getting weekly spam from Carl at crossfiremedia.com. I > have been "subscribed" to this newsletter. Today's spam subject line is > "Get to 4GWE and Participate in the Wireless Future, We'll help pay your > way..." > > The address used is an address I used on NANOG some years back - I haven't > used it in quite a while but still get an occasional private email from > someone who has that address in their address book so the address is still > active. > > Because there's a remote chance that some time long ago I "subscribed" to > some message board and hidden in the message board settings is a pre-checked > option (which I overlooked) to receive email from "partners", I privately > emailed several friends in the IT/Security fields asking if they were > getting this spam. The one friend who is also getting this spam is also > someone who occasionally posts to NANOG, and who also has no idea why he was > "subscribed" to this spam. Because of this coincidence, I think the spammer > may have scarfed email addresses of people who posted to NANOG and added > them to the "targeted" mailing list / spam list. > > I'm curious to know if other NANOG subscribers have started receiving spam > from this person. > > I also found 2 sites that have web interfaces to their NANOG archives where > they are not obscuring email addresses and who leaked posting addresses onto > the web: > > http://www.google.com/search?q=lists05%40equinephotoart.com+nanog > > Is there someone at NANOG who can ask these sites to remove these archives, > or at least purge/munge email addresses? > > Please reply via private email. Thanks! > > jc > > From graeme at graemef.net Tue Jan 13 14:01:56 2009 From: graeme at graemef.net (Graeme Fowler) Date: Tue, 13 Jan 2009 20:01:56 +0000 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> Message-ID: <1231876916.32704.4.camel@ernie.internal.graemef.net> On Tue, 2009-01-13 at 14:43 -0500, Reynold Guerrier wrote: > My subscription to NANOG aged 3 months ago and I am receiving this spam too. > And this is my first post. I effectively think that someone might have crack > the email database of the Nanog list. Funny; I'm not in that sort of business and I haven't received that sort of spam. Funny also that both Reynold and JC have quite significant online presences (as determined from a quick Google) which reveal lots of interesting info - if you were a person interested in selling them something, anyway. Especially wireless kit. I think there's far less to this than meets the eye, personally. Just a predictably asinine salesperson believing that your presence online provides your consent for bulk email... have you contacted their CEO? Graeme From jabley at hopcount.ca Tue Jan 13 14:30:07 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Jan 2009 15:30:07 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090113161248.GA64292@ussenterprise.ufp.org> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> Message-ID: On 13 Jan 2009, at 11:12, Leo Bicknell wrote: > Loop detection kicks in only when there is a loop. You see your > own ASN coming back to you. > > In the case we're discussing THERE IS NO LOOP. Someone is mis-using > this feature to control the propagation of routes. Surely controlling the propagation of routes is what loop avoidance is all about. > Were the victim Heh, if only there was any sign of a victim. Joe From patrick at ianai.net Tue Jan 13 14:32:48 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 15:32:48 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> Message-ID: On Jan 13, 2009, at 3:30 PM, Joe Abley wrote: >> Were the victim > > Heh, if only there was any sign of a victim. The guy who spent time & effort investigating why his AS was misused announced it here. I'd call that at least a sign. -- TTFN, patrick From blakjak at blakjak.net Tue Jan 13 14:33:48 2009 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 14 Jan 2009 09:33:48 +1300 (NZDT) Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <1231876916.32704.4.camel@ernie.internal.graemef.net> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> Message-ID: <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> On Wed, January 14, 2009 9:01 am, Graeme Fowler wrote: > I think there's far less to this than meets the eye, personally. Just a > predictably asinine salesperson believing that your presence online > provides your consent for bulk email... have you contacted their CEO? > I do have to ask though, what's up with third-party systems creating a web accessible archive of the mailing list? Worse, with them not fudging email addresses when doing so? Strikes me as plain-old 'rude' to be honest... Are the standing official archives insufficient or something? From jabley at hopcount.ca Tue Jan 13 14:36:41 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Jan 2009 15:36:41 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> Message-ID: On 13 Jan 2009, at 15:32, Patrick W. Gilmore wrote: > On Jan 13, 2009, at 3:30 PM, Joe Abley wrote: > >>> Were the victim >> >> Heh, if only there was any sign of a victim. > > The guy who spent time & effort investigating why his AS was misused > announced it here. I'd call that at least a sign. I'd call it a sign that people need to be more selective about what they spend their time reacting to, and that pretty much wraps up the operational content of this thread, as far as I can see. Bring back the haikus! Joe From james at pcipros.com Tue Jan 13 14:38:33 2009 From: james at pcipros.com (James Laszko) Date: Tue, 13 Jan 2009 12:38:33 -0800 Subject: QWEST IP NOC Help Needed Message-ID: <0983540C7A6BC84DB0A5FEF8033C2BF42016DD@sandcaexch02.pcipros.net> We have just received notice that an old allocation from QWEST that was provided to our company in the early 2000's has been redirected from our current connectivity company. We had procured the homing of our IP space to our existing provider, but they recently terminated their relationship with QWEST. QWEST has since started announcing our address space, blackholing us. We've got a tremendous amount of customers and legacy equipment in that space and need someone from QWEST to please contact us to try and resolve this issue. The netblock in question is 65.126.208.0/22 Can a QWEST IP NOC Supervisor or someone else who can help me please contact me ASAP? Thank you, James Laszko Pipeline Communications james at pcipros.com 951-541-9688 x 1030 760-807-5129 cell From kngspook at gmail.com Tue Jan 13 14:39:40 2009 From: kngspook at gmail.com (Neil) Date: Tue, 13 Jan 2009 12:39:40 -0800 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> Message-ID: <77e4079b0901131239l62562885s432a7598192cb7a9@mail.gmail.com> On Tue, Jan 13, 2009 at 12:33 PM, Mark Foster wrote: > On Wed, January 14, 2009 9:01 am, Graeme Fowler wrote: > >> I think there's far less to this than meets the eye, personally. Just a >> predictably asinine salesperson believing that your presence online >> provides your consent for bulk email... have you contacted their CEO? >> > > > I do have to ask though, what's up with third-party systems creating a web > accessible archive of the mailing list? Worse, with them not fudging > email addresses when doing so? > > Strikes me as plain-old 'rude' to be honest... Are the standing official > archives insufficient or something? > > Strikes me as such as well. And once I accidentally sent two mails to a list with some information I would've preferred was not public, and that was a real headache... From patrick at ianai.net Tue Jan 13 14:39:52 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 15:39:52 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> Message-ID: <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> On Jan 13, 2009, at 3:36 PM, Joe Abley wrote: > On 13 Jan 2009, at 15:32, Patrick W. Gilmore wrote: >> On Jan 13, 2009, at 3:30 PM, Joe Abley wrote: >> >>>> Were the victim >>> >>> Heh, if only there was any sign of a victim. >> >> The guy who spent time & effort investigating why his AS was >> misused announced it here. I'd call that at least a sign. > > I'd call it a sign that people need to be more selective about what > they spend their time reacting to, and that pretty much wraps up the > operational content of this thread, as far as I can see. Bring back > the haikus! Joe, See my earlier posts about using someone else's resources without their permission or even notifying them, then telling them it is OK because they shouldn't care anyway. Really, this is not how I expected someone of your caliber to respond. -- TTFN, patrick From patrick at ianai.net Tue Jan 13 14:41:01 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 Jan 2009 15:41:01 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> Message-ID: Seriously, you believe it's OK to blame the guy whose ASN was spoofed for spending too long researching it? I was _literally_ shaking my head when I read that. -- TTFN, patrick From auser at mind.net Tue Jan 13 14:42:35 2009 From: auser at mind.net (S. Ryan) Date: Tue, 13 Jan 2009 12:42:35 -0800 Subject: Trouble reaching plaxo.com? Message-ID: <496CFCBB.10305@mind.net> Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't seem to get there via Level 3 or via 360 Networks. Both die around here: 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net [69.36.239.137] Here is a traceroute from 360: [id:~]$ traceroute 204.15.240.72 traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets 1 unused (x) 1.114 ms 1.258 ms 1.100 ms 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 ms 43.218 ms 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 ms 50.836 ms Thanks for any insight, Steve From sandy at tislabs.com Tue Jan 13 14:41:46 2009 From: sandy at tislabs.com (Sandy Murphy) Date: Tue, 13 Jan 2009 15:41:46 -0500 (EST) Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: Message-ID: <20090113204146.AB0603F4A2@pecan.tislabs.com> >> It should be pointed out that pre-provisioned AS_Path filters and >> prefix-lists would actually be effective at defeating this and >> preventing someone who is actually malicious from using this >> technique. This is an excellent argument for implementing SIDR... > >Finally we agree. Although I am not certain SIDR is the optimal >answer, we agree it would solve the problem. The sidr wg is working on protection of the origination of the route - so the origin AS in the AS_PATH is known to be authorized to originate routes to the prefix. That's not full AS_PATH protection. sidr is not doing full AS_PATH protection. Yet. Protecting the origination is not sufficient, everyone recognizes that. But protecting the origination is necessary for eventual full AS_PATH protection, so we're not wasting our time, either. Feel free to chime in on the sidr list about wanting full path protection. As loud as you like. --Sandy From Valdis.Kletnieks at vt.edu Tue Jan 13 14:47:01 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Jan 2009 15:47:01 -0500 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: Your message of "Wed, 14 Jan 2009 09:33:48 +1300." <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> Message-ID: <4205.1231879621@turing-police.cc.vt.edu> On Wed, 14 Jan 2009 09:33:48 +1300, Mark Foster said: > Strikes me as plain-old 'rude' to be honest... Are the standing official > archives insufficient or something? There's certainly the "Damn, I remember a Nanog posting about this router issue" case - but for that, you probably can't reach the 3rd-party archive either. The proper thing to do is save those postings on your laptop hard drive - and then back up the hard drive regularly. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From neito at nerdramblingz.com Tue Jan 13 14:51:04 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Tue, 13 Jan 2009 15:51:04 -0500 Subject: Trouble reaching plaxo.com? In-Reply-To: <496CFCBB.10305@mind.net> References: <496CFCBB.10305@mind.net> Message-ID: You're not the only one. I'm not getting anything from my home Verizon access, either. On Tue, Jan 13, 2009 at 3:42 PM, S. Ryan wrote: > Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't > seem to get there via Level 3 or via 360 Networks. > > Both die around here: > > 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net > [69.36.239.137] > > Here is a traceroute from 360: > > [id:~]$ traceroute 204.15.240.72 > traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets > 1 unused (x) 1.114 ms 1.258 ms 1.100 ms > 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms > 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms > 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms > 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms > 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms > 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms > 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 ms > 43.218 ms > 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 ms > 50.836 ms > > Thanks for any insight, > > Steve > > From pstewart at nexicomgroup.net Tue Jan 13 14:51:32 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 13 Jan 2009 15:51:32 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net><496BC876.8070704@psg.com><787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com><496BCAEF.6020401@psg.com><787581440901121504p755ee81k8584491026ebf598@mail.gmail.com><496BD03C.4080203@psg.com><20090113002954.GA10395@ussenterprise.ufp.org><620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com><9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org><20090113161248.GA64292@ussenterprise.ufp.org> Message-ID: <89D27DE3375BB6428DDCC2927489826A01E70A32@nexus.nexicomgroup.net> Ummmmm.. no. I can't speak for the others on this list who were effected like us - but we take this stuff very seriously and respectively you would too *if* you had a previous legit issue that appeared to the same **on the surface**. A cautious and indepth look at this was taken upon us hoping that history wasn't repeating itself (previously explained) and thankfully it wasn't ... but until the time is spent to make absolutely sure how do you know?? At the end of the day, it wasn't a serious operational issue but raised a number of concerns I believe.... Paul -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, January 13, 2009 3:37 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 13 Jan 2009, at 15:32, Patrick W. Gilmore wrote: > On Jan 13, 2009, at 3:30 PM, Joe Abley wrote: > >>> Were the victim >> >> Heh, if only there was any sign of a victim. > > The guy who spent time & effort investigating why his AS was misused > announced it here. I'd call that at least a sign. I'd call it a sign that people need to be more selective about what they spend their time reacting to, and that pretty much wraps up the operational content of this thread, as far as I can see. Bring back the haikus! Joe ---------------------------------------------------------------------------- "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." From dave at stayonline.com Tue Jan 13 14:52:08 2009 From: dave at stayonline.com (Dave Larter) Date: Tue, 13 Jan 2009 15:52:08 -0500 Subject: Trouble reaching plaxo.com? In-Reply-To: <496CFCBB.10305@mind.net> References: <496CFCBB.10305@mind.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB3DC032@MERCURY.socrdu.com> Yes, via twtelecom. -----Original Message----- From: S. Ryan [mailto:auser at mind.net] Sent: Tuesday, January 13, 2009 3:43 PM To: nanog at nanog.org Subject: Trouble reaching plaxo.com? Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't seem to get there via Level 3 or via 360 Networks. Both die around here: 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net [69.36.239.137] Here is a traceroute from 360: [id:~]$ traceroute 204.15.240.72 traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets 1 unused (x) 1.114 ms 1.258 ms 1.100 ms 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 ms 43.218 ms 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 ms 50.836 ms Thanks for any insight, Steve From ddunkin at netos.net Tue Jan 13 14:57:05 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 13 Jan 2009 12:57:05 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net><496BC876.8070704@psg.com><787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com><496BCAEF.6020401@psg.com><787581440901121504p755ee81k8584491026ebf598@mail.gmail.com><496BD03C.4080203@psg.com><20090113002954.GA10395@ussenterprise.ufp.org><620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com><9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org><20090113161248.GA64292@ussenterprise.ufp.org> Message-ID: <56F5BC5F404CF84896C447397A1AAF20BE8A1D@MAIL.nosi.netos.com> -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, January 13, 2009 12:37 To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > I'd call it a sign that people need to be more selective about what > they spend their time reacting to, and that pretty much wraps up the > operational content of this thread, as far as I can see. Bring back > the haikus! If I volunteer my own AS for Randy's research, can we end this? I have no alarms that would complain about this as it will not be using my prefixes. From jabley at hopcount.ca Tue Jan 13 14:57:47 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 13 Jan 2009 15:57:47 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> Message-ID: <80B4BF09-CC61-41CB-9CE0-83A15CAFE521@hopcount.ca> On 13 Jan 2009, at 15:39, Patrick W. Gilmore wrote: > See my earlier posts about using someone else's resources without > their permission or even notifying them, then telling them it is OK > because they shouldn't care anyway. I read them. Nobody is using anybody else's resources. None of the people who reacted did so because their prefixes had been hijacked. All that happened was that someone decided to attach an attribute to a non-hijacked prefix that made people scratch their heads, because to them it was an unusual use of the attribute. If I want to advertise a prefix, I'll attach whatever attributes I like to it. People can choose not to accept it if they want, as ever. What next? Am I "hijacking AS 701" if I attach the community string attribute 701:1000 to a prefix I originate, or even one I learn from a peer or customer? The fact that I choose to stick 701 in an AS_PATH attribute on a prefix I advertise in order to stop that prefix from propagating into 701 is entirely my own business, and it's a practice which, although apparently not commonplace, has been a well-known part of the IDTE toolbox for many years. The only real victims of this recent (non-)event are the people who have spent time wading through an enormous circular thread filled with people trying to convince others to change their minds about something that had no operational impact whatsoever to anybody, regardless of the fact that it's surely by now clear that nobody is interested in changing their mind. > Really, this is not how I expected someone of your caliber to respond. Then apparently you hadn't read any of my other comments in this thread (or perhaps this was intended just as weak ad-hominem wrist- slapping). Joe From Ray.Sanders at VillageVoiceMedia.com Tue Jan 13 14:59:18 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 13 Jan 2009 13:59:18 -0700 Subject: Trouble reaching plaxo.com? In-Reply-To: <496CFCBB.10305@mind.net> References: <496CFCBB.10305@mind.net> Message-ID: <1231880358.3608.9.camel@artoo.vvmedia.com> Not reaching plaxo.com either. We're on cogent and carpathia. On Tue, 2009-01-13 at 12:42 -0800, S. Ryan wrote: > Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't > seem to get there via Level 3 or via 360 Networks. > > Both die around here: > > 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net > [69.36.239.137] > > Here is a traceroute from 360: > > [id:~]$ traceroute 204.15.240.72 > traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets > 1 unused (x) 1.114 ms 1.258 ms 1.100 ms > 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms > 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms > 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms > 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms > 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms > 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms > 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 > ms 43.218 ms > 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 > ms 50.836 ms > > Thanks for any insight, > > Steve > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From sethm at rollernet.us Tue Jan 13 15:06:51 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 13 Jan 2009 13:06:51 -0800 Subject: Trouble reaching plaxo.com? In-Reply-To: <496CFCBB.10305@mind.net> References: <496CFCBB.10305@mind.net> Message-ID: <496D026B.9030201@rollernet.us> S. Ryan wrote: > Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't > seem to get there via Level 3 or via 360 Networks. > Works for me via Sprint. Can send traceroute privately if interested. ~Seth From rsk at gsp.org Tue Jan 13 15:44:14 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 13 Jan 2009 16:44:14 -0500 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> <51943.119.15.0.26.1231878828.squirrel@webmail.blakjak.net> Message-ID: <20090113214414.GA11138@gsp.org> On Wed, Jan 14, 2009 at 09:33:48AM +1300, Mark Foster wrote: > I do have to ask though, what's up with third-party systems creating a web > accessible archive of the mailing list? Worse, with them not fudging > email addresses when doing so? 1. (in reply to the original) I haven't received anything from them here yet, but it may have been rejected at the perimeter. When I get a chance this evening, I'll check logs and see if I turn up anything. 2. Yes, it's quite rude for third parties to set up (public) archives of mailing lists without the prior, express consent of the owner(s) of those lists. I don't see a problem with individual members of such lists maintaining their own (private) archives -- and I routinely do so for every list I'm on. 3. But it's utterly pointless to obfuscate addresses in such archives: spammers have long since set up quite efficient methods of harvesting any address used on any public mailng list or Usenet newsgroup. [1] The only people meaningfully impeded by these futile attempts at obfuscation are legitimate senders. ---Rsk [1] Someone should explain this to Google in re their Usenet archive: spammers have NNTP feeds, too. From m.hallgren at free.fr Tue Jan 13 15:55:00 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 13 Jan 2009 22:55:00 +0100 Subject: Trouble reaching plaxo.com? In-Reply-To: <1231880358.3608.9.camel@artoo.vvmedia.com> References: <496CFCBB.10305@mind.net> <1231880358.3608.9.camel@artoo.vvmedia.com> Message-ID: <1231883700.13776.2.camel@home> Le mardi 13 janvier 2009 ? 13:59 -0700, Ray Sanders a ?crit : > Not reaching plaxo.com either. > We're on cogent and carpathia. No prob reaching from the AS6453 backbone. mh > > On Tue, 2009-01-13 at 12:42 -0800, S. Ryan wrote: > > Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't > > seem to get there via Level 3 or via 360 Networks. > > > > Both die around here: > > > > 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net > > [69.36.239.137] > > > > Here is a traceroute from 360: > > > > [id:~]$ traceroute 204.15.240.72 > > traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets > > 1 unused (x) 1.114 ms 1.258 ms 1.100 ms > > 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms > > 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms > > 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms > > 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms > > 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms > > 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms > > 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 > > ms 43.218 ms > > 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 > > ms 50.836 ms > > > > Thanks for any insight, > > > > Steve > > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nanog at lazyworm.net Tue Jan 13 16:15:26 2009 From: nanog at lazyworm.net (Kenneth Cheung) Date: Tue, 13 Jan 2009 14:15:26 -0800 Subject: Trouble reaching plaxo.com? In-Reply-To: <1231883700.13776.2.camel@home> References: <496CFCBB.10305@mind.net> <1231880358.3608.9.camel@artoo.vvmedia.com> <1231883700.13776.2.camel@home> Message-ID: <6abc71b80901131415u4a8d224dk290c19ee630b8f30@mail.gmail.com> A contact asked me to relay that they're back up. The DC had a power issue. -kc On Tue, Jan 13, 2009 at 13:55, Michael Hallgren wrote: > Le mardi 13 janvier 2009 ? 13:59 -0700, Ray Sanders a ?crit : > > Not reaching plaxo.com either. > > We're on cogent and carpathia. > > No prob reaching from the AS6453 backbone. > > mh > > > > > On Tue, 2009-01-13 at 12:42 -0800, S. Ryan wrote: > > > Anyone else having trouble reaching plaxo.com? Nothing urgent. I > can't > > > seem to get there via Level 3 or via 360 Networks. > > > > > > Both die around here: > > > > > > 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net > > > [69.36.239.137] > > > > > > Here is a traceroute from 360: > > > > > > [id:~]$ traceroute 204.15.240.72 > > > traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte > packets > > > 1 unused (x) 1.114 ms 1.258 ms 1.100 ms > > > 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms > > > 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms > > > 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 > ms > > > 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 > ms > > > 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 > ms > > > 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 > ms > > > 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms > 43.264 > > > ms 43.218 ms > > > 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms > 44.153 > > > ms 50.836 ms > > > > > > Thanks for any insight, > > > > > > Steve > > > > -- > michael hallgren, mh2198-ripe > From jlloret at dcom.upv.es Tue Jan 13 16:57:45 2009 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Tue, 13 Jan 2009 23:57:45 +0100 Subject: Lastweek Reminder: CFP - NetWare 2009 [SENSORCOMM, SECURWARE, DEPEND, AFIN, MESH] / Athens-Vouliagmeni] Message-ID: <200901132257.n0DMvjWG004722@smtp.upv.es> INVITATION Please consider to contribute and encourage your team members and fellow scientists to contribute to the following federated events. Thanks for forwarding the information on this Call for Submissions to those potentially interested to submit. ===== Call for Submissions ======= NetWare 2009, June 18-23, 2009 - Athens/Vouliagmeni, Greece see: http://www.iaria.org/conferences2009/NetWare09.html NetWare 2009 is a federated event focusing on advances topics concerning the areas of sensors, security, mesh, dependability and future Internet. NetWare 2009 continues the tradition of well-established conferences SENSORCOMM, SECURWARE, MESH and DEPEND and adds new trends on advances in Future Internet (AFIN). Submission (full paper) deadline: January 20, 2009. Submissions must be electronically done using the ?Submit a Paper? button on the entry page of each conference. For details on the each conference's topics, see the individual Call for Papers for each conference. Unpublished high quality contributions in terms of Regular papers and Forum posters are welcome. Workshop proposals and Panel proposals on challenging topics are encouraged. Extended versions of selected papers will be published in IARIA on-line Journals (http://www.iariajournals.org) and in Special issues of different journals mentioned on the entry page of each conference. Submissions will be peer-reviewed, published by IEEE Computer Society Press, posted in IEEE Digital Library, and indexed via all the IEEE indexing agreements. All tracks/topics are open to both research and industry contributions. >> SENSORCOMM 2009, The Third International Conference on Sensor Technologies and Applications http://www.iaria.org/conferences2009/SENSORCOMM09.html >> SECURWARE 2009, The Third International Conference on Emerging Security Information, Systems and Technologies http://www.iaria.org/conferences2009/SECURWARE09.html >> AFIN 2009, The First International Conference on Advances in Future Internet http://www.iaria.org/conferences2009/AFIN09.html >> DEPEND 2009, The Second International Conference on Dependability http://www.iaria.org/conferences2009/DEPEND09.html >> MESH 2009, The Second International Conference on Advances in Mesh Networks http://www.iaria.org/conferences2009/MESH09.html -------------------------------- IARIA Publicity Board From jlloret at dcom.upv.es Tue Jan 13 16:57:46 2009 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Tue, 13 Jan 2009 23:57:46 +0100 Subject: Lastweek Reminder: CFP - NetWare 2009 [SENSORCOMM, SECURWARE, DEPEND, AFIN, MESH] / Athens-Vouliagmeni] Message-ID: <200901132257.n0DMvj1T004753@smtp.upv.es> INVITATION Please consider to contribute and encourage your team members and fellow scientists to contribute to the following federated events. Thanks for forwarding the information on this Call for Submissions to those potentially interested to submit. ===== Call for Submissions ======= NetWare 2009, June 18-23, 2009 - Athens/Vouliagmeni, Greece see: http://www.iaria.org/conferences2009/NetWare09.html NetWare 2009 is a federated event focusing on advances topics concerning the areas of sensors, security, mesh, dependability and future Internet. NetWare 2009 continues the tradition of well-established conferences SENSORCOMM, SECURWARE, MESH and DEPEND and adds new trends on advances in Future Internet (AFIN). Submission (full paper) deadline: January 20, 2009. Submissions must be electronically done using the ?Submit a Paper? button on the entry page of each conference. For details on the each conference's topics, see the individual Call for Papers for each conference. Unpublished high quality contributions in terms of Regular papers and Forum posters are welcome. Workshop proposals and Panel proposals on challenging topics are encouraged. Extended versions of selected papers will be published in IARIA on-line Journals (http://www.iariajournals.org) and in Special issues of different journals mentioned on the entry page of each conference. Submissions will be peer-reviewed, published by IEEE Computer Society Press, posted in IEEE Digital Library, and indexed via all the IEEE indexing agreements. All tracks/topics are open to both research and industry contributions. >> SENSORCOMM 2009, The Third International Conference on Sensor Technologies and Applications http://www.iaria.org/conferences2009/SENSORCOMM09.html >> SECURWARE 2009, The Third International Conference on Emerging Security Information, Systems and Technologies http://www.iaria.org/conferences2009/SECURWARE09.html >> AFIN 2009, The First International Conference on Advances in Future Internet http://www.iaria.org/conferences2009/AFIN09.html >> DEPEND 2009, The Second International Conference on Dependability http://www.iaria.org/conferences2009/DEPEND09.html >> MESH 2009, The Second International Conference on Advances in Mesh Networks http://www.iaria.org/conferences2009/MESH09.html -------------------------------- IARIA Publicity Board From braaen at zcorum.com Tue Jan 13 18:52:09 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 13 Jan 2009 19:52:09 -0500 Subject: QWEST IP NOC Help Needed In-Reply-To: <0983540C7A6BC84DB0A5FEF8033C2BF42016DD@sandcaexch02.pcipros.net> References: <0983540C7A6BC84DB0A5FEF8033C2BF42016DD@sandcaexch02.pcipros.net> Message-ID: <200901131952.09952.braaen@zcorum.com> You can give their IP NOC a call at (877)886-6515. They are faily responsive for me. ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Tuesday 13 January 2009, James Laszko wrote: > We have just received notice that an old allocation from QWEST that was > provided to our company in the early 2000's has been redirected from our > current connectivity company. We had procured the homing of our IP > space to our existing provider, but they recently terminated their > relationship with QWEST. QWEST has since started announcing our address > space, blackholing us. We've got a tremendous amount of customers and > legacy equipment in that space and need someone from QWEST to please > contact us to try and resolve this issue. > > > > The netblock in question is 65.126.208.0/22 > > > > > > Can a QWEST IP NOC Supervisor or someone else who can help me please > contact me ASAP? > > > > > > Thank you, > > > > > > James Laszko > > Pipeline Communications > > james at pcipros.com > > 951-541-9688 x 1030 > > 760-807-5129 cell > > From jcdill.lists at gmail.com Tue Jan 13 19:19:01 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 13 Jan 2009 17:19:01 -0800 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <1231876916.32704.4.camel@ernie.internal.graemef.net> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> Message-ID: <496D3D85.6060709@gmail.com> Graeme Fowler wrote: > On Tue, 2009-01-13 at 14:43 -0500, Reynold Guerrier wrote: > >> My subscription to NANOG aged 3 months ago and I am receiving this spam too. >> And this is my first post. I effectively think that someone might have crack >> the email database of the Nanog list. >> > > Funny; I'm not in that sort of business and I haven't received that sort > of spam. Funny also that both Reynold and JC have quite significant > online presences (as determined from a quick Google) which reveal lots > of interesting info - if you were a person interested in selling them > something, anyway. Especially wireless kit. The particular email address ceased being used (by me) over a year ago, but suddenly 4 weeks ago I was "subscribed" to their mailing list. Apparently the common theme is that we all registered for the VON conference at one point. Apparently they think it is OK to take an address that was used to register for VON several years ago and now, suddenly, and without MY PERMISSION "subscribe" me to a marketing spam list on a different topic. RSK wrote: > 3. But it's utterly pointless to obfuscate addresses in such archives: > spammers have long since set up quite efficient methods of harvesting > any address used on any public mailng list or Usenet newsgroup. [1] The > only people meaningfully impeded by these futile attempts at obfuscation > are legitimate senders. Rich, I know that spammers can get an address by subscribing and scarfing the emails that are used to post to the list. I just don't want to see it be made any easier for them by idiots making their own public web archives (when this list already has a web archive) and then not obfuscating the email addresses. As you and others have also noted, that's just plain rude. To tie in with another thread, those of you who don't see anything wrong with another network using someone's ASN in a way that triggered alerts to their network admins, and without permission (and causing said admin to miss part of a very important family event while he tracked down the source of the alert he received) probably didn't see anything wrong with the first unsolicited commercial email either. I mean, it's just one email, what's the harm.... you can just hit delete, right? I really can't understand why all of you are saying it's no big deal! jc From jbates at brightok.net Tue Jan 13 19:11:55 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 13 Jan 2009 19:11:55 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <20090113204146.AB0603F4A2@pecan.tislabs.com> References: <20090113204146.AB0603F4A2@pecan.tislabs.com> Message-ID: <496D3BDB.7020608@brightok.net> Sandy Murphy wrote: > > The sidr wg is working on protection of the origination of the > route - so the origin AS in the AS_PATH is known to be authorized > to originate routes to the prefix. > > That's not full AS_PATH protection. sidr is not doing full AS_PATH protection. > > Yet. > I always considered AS_PATH protection to be a waste of time. It does what it does, and has minor tweaking capabilities which I hope Randy will show are mostly pointless (ie, please quit doing this because it won't actually work as you want). heh. Someone should have added "modifying AS_PATH might confuse those people attempting to route IP traffic on the Internet." Similar to RFC 1930: There are few security concerns regarding the selection of ASes. AS number to owner mappings are public knowledge (in WHOIS), and attempting to change that would serve only to confuse those people attempting to route IP traffic on the Internet. I also like this statement from same RFC: ASX knows how to reach a prefix called NET1. It does not matter whether NET1 belongs to ASX or to some other AS which exchanges routing information with ASX, either directly or indirectly; we just assume that ASX knows how to direct packets towards NET1. Likewise ASY knows how to reach NET2. ie, We care about the AS we are peered with and all beyond it doesn't really matter (exception being the use of ASN in AS_PATH for loop detections). They wouldn't have even bothered assigning ASNs except to insure uniqueness when it comes to detecting routing loops in AS_PATH and for insuring two AS's that suddenly peer are unique. It is important that an ASN be unique, or loop detection on an AS_PATH would cause a possible lack of reachability (if 2 seperate AS's use the same ASN). That being said, the person advertising a route can change the AS_PATH to effect the reachability of their network in a variety of ways (most common is prepending their own ASN, least common is probably path truncating and use of atomic_aggregator). The real quirk is, given that an AS by definition has its own routing policy and announces it to peers, is path poisoning part of that AS's policy in order to not allow some routes via certain peers to be accepted by another AS to traffic engineer. Is not the point of BGP to define a routing policy? And just because this RFC cracks me up, one last quote: However, if the criteria applied above are adhered to, then there is no immediate danger of AS space exhaustion. It is expected that IDRP will be deployed before this becomes an issue. IDRP does not have a fixed limit on the size of an RDI. Let's switch already! ISIS and IDRP for life! Jack From ser at tch.org Tue Jan 13 22:31:19 2009 From: ser at tch.org (Steve Rubin) Date: Tue, 13 Jan 2009 20:31:19 -0800 Subject: Trouble reaching plaxo.com? In-Reply-To: <496CFCBB.10305@mind.net> References: <496CFCBB.10305@mind.net> Message-ID: <496D6A97.8000206@tch.org> S. Ryan wrote: > Anyone else having trouble reaching plaxo.com? Nothing urgent. I can't > seem to get there via Level 3 or via 360 Networks. > > Both die around here: > > 10 23 ms 21 ms 23 ms te3-2-928.core1.mpt.layer42.net > [69.36.239.137] > > Here is a traceroute from 360: > > [id:~]$ traceroute 204.15.240.72 > traceroute to 204.15.240.72 (204.15.240.72), 64 hops max, 44 byte packets > 1 unused (x) 1.114 ms 1.258 ms 1.100 ms > 2 core1-e3-1 (x) 0.882 ms 0.920 ms 0.943 ms > 3 66.62.136.85 (66.62.136.85) 10.859 ms 10.284 ms 10.291 ms > 4 pdx1-core-02.360.net (66.62.4.130) 12.702 ms 11.984 ms 11.078 ms > 5 lax1-core-01.360.net (66.62.3.68) 33.333 ms 35.922 ms 34.513 ms > 6 lax1-edge-01.360.net (66.62.5.131) 33.728 ms 33.910 ms 33.403 ms > 7 laiix.layer42.net (198.32.146.22) 62.471 ms 36.545 ms 51.932 ms > 8 g6-21-103.core2.eqx.layer42.net (69.36.239.105) 44.008 ms 43.264 > ms 43.218 ms > 9 te3-2-928.core1.mpt.layer42.net (69.36.239.137) 43.943 ms 44.153 > ms 50.836 ms > > Thanks for any insight, > > Steve MPT is CRG/Market Post Tower. There was a power outage on parts of 2 floors today. My guess is Plaxo's cage lost (partial?) power during the outage. -- Steve Rubin / AE6CH / http://www.altdb.net/ Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ From hank at efes.iucc.ac.il Wed Jan 14 01:59:14 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 14 Jan 2009 09:59:14 +0200 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496CEB2A.3040905@eeph.com> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> <496CDAE5.9060008@eeph.com> <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> Message-ID: <5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> At 11:27 AM 13-01-09 -0800, Matthew Kaufman wrote: >That's why *I* wouldn't have run such an experiment myself, because >there's just too many cases these days where people have gotten convicted >of doing things like putting the wrong integer in their MySpace profile. What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order. -Hank From graeme at graemef.net Wed Jan 14 02:19:39 2009 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 14 Jan 2009 08:19:39 +0000 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <496D3D85.6060709@gmail.com> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> <496D3D85.6060709@gmail.com> Message-ID: <1231921179.32704.10.camel@ernie.internal.graemef.net> On Tue, 2009-01-13 at 17:19 -0800, JC Dill wrote: > The particular email address ceased being used (by me) over a year ago, > but suddenly 4 weeks ago I was "subscribed" to their mailing list. > Apparently the common theme is that we all registered for the VON > conference at one point. Aha, list re-purposing. That's something completely different - I cannot speak for your local or federal laws on spam, but in the UK we could fairly well go to town on a company doing that (not in law, sadly, but certainly in terms of professional shame through whichever organisations they belong to). > I really can't understand why all of you are saying it's no big deal! Er... we're not. I'm not, certainly, and I haven't read anyone else as having done so. What we're saying is that there's nothing sinister (as the original reply to your message thought), that there's a simple explanation. As I said originally - if this is a company with any professional pride whatsoever, contact their CEO. Going from the top down can be instructive at the very least, if not actually productive. Graeme From simon at slimey.org Wed Jan 14 02:06:49 2009 From: simon at slimey.org (Simon Lockhart) Date: Wed, 14 Jan 2009 08:06:49 +0000 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> <496CDAE5.9060008@eeph.com> <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> <5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> Message-ID: <20090114080649.GM11420@virtual.bogons.net> On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: > What if, by doing some research experiment, the researcher discovers some > unknown and latent bug in IOS or JunOS that causes much of the Internet to > go belly up? 1 in a billion chance, but nonetheless, a headsup would have > been in order. Say we had a customer who connected to us over BGP, and they used some new experimental BGP daemon. Their announcement was "odd" in some way, but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up. Should we have given a heads up to the Internet at large that we were turning up this customer? Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From tim at pelican.org Wed Jan 14 04:50:23 2009 From: tim at pelican.org (Tim Franklin) Date: Wed, 14 Jan 2009 10:50:23 -0000 (GMT) Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <80B4BF09-CC61-41CB-9CE0-83A15CAFE521@hopcount.ca> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> <80B4BF09-CC61-41CB-9CE0-83A15CAFE521@hopcount.ca> Message-ID: <31f5977816cc97076ea7a2223627d30c.squirrel@webmail.pelican.org> On Tue, January 13, 2009 8:57 pm, Joe Abley wrote: > The fact that I choose to stick 701 in an AS_PATH attribute on a > prefix I advertise in order to stop that prefix from propagating into > 701 is entirely my own business, and it's a practice which, although > apparently not commonplace, has been a well-known part of the IDTE > toolbox for many years. This does seem to be an interesting question. I'm AS X, I have no contractual relationship with AS Y, or indeed any informal peering relationship with them. All of my connectivity with AS Y is via at least one other AS. For whatever reason, technical, political, or pure whim, I don't want AS Y to receive any of my announcements. What's the correct tool to do this? Other than AS-PATH, I can't see a reliable way to do this currently. Lots of my peers or transits may have communities I can set to request that they don't announce my routes in particular regions, at particular peering points etc, but they almost certainly don't have one to restrict announcements to a specific AS. Do we need a set of well-known communities XXXXX:AS that can be recognised everywhere as "do not announce to AS"? Regards, Tim. From kris.foster at gmail.com Wed Jan 14 05:00:47 2009 From: kris.foster at gmail.com (kris foster) Date: Wed, 14 Jan 2009 03:00:47 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <31f5977816cc97076ea7a2223627d30c.squirrel@webmail.pelican.org> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> <80B4BF09-CC61-41CB-9CE0-83A15CAFE521@hopcount.ca> <31f5977816cc97076ea7a2223627d30c.squirrel@webmail.pelican.org> Message-ID: On Jan 14, 2009, at 2:50 AM, Tim Franklin wrote: > On Tue, January 13, 2009 8:57 pm, Joe Abley wrote: > >> The fact that I choose to stick 701 in an AS_PATH attribute on a >> prefix I advertise in order to stop that prefix from propagating into >> 701 is entirely my own business, and it's a practice which, although >> apparently not commonplace, has been a well-known part of the IDTE >> toolbox for many years. > > For whatever reason, technical, political, or pure whim, I don't > want AS Y > to receive any of my announcements. > > What's the correct tool to do this? Exactly the method Randy used. > Do we need a set of well-known communities XXXXX:AS that can be > recognised > everywhere as "do not announce to AS"? Communities are optional transitive attributes. No one is required to act on well-known communities. Kris From jbates at brightok.net Wed Jan 14 07:26:03 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 14 Jan 2009 07:26:03 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> <80B4BF09-CC61-41CB-9CE0-83A15CAFE521@hopcount.ca> <31f5977816cc97076ea7a2223627d30c.squirrel@webmail.pelican.org> Message-ID: <496DE7EB.5010404@brightok.net> kris foster wrote: > > On Jan 14, 2009, at 2:50 AM, Tim Franklin wrote: > >> On Tue, January 13, 2009 8:57 pm, Joe Abley wrote: >> >>> The fact that I choose to stick 701 in an AS_PATH attribute on a >>> prefix I advertise in order to stop that prefix from propagating into >>> 701 is entirely my own business, and it's a practice which, although >>> apparently not commonplace, has been a well-known part of the IDTE >>> toolbox for many years. >> >> For whatever reason, technical, political, or pure whim, I don't want >> AS Y >> to receive any of my announcements. >> >> What's the correct tool to do this? > > Exactly the method Randy used. > Yes, but I see that Randy has switched over to 3130 3130, which should at least keep a few alarms going off since Randy's AS is the so called origin AS (as if people don't do aggregates or truncate AS Paths (actually, there are some sections of BGP4, which probably don't get used as often as others would like)). I'm now extremely curious if alarms were just going off since the right-most AS was the trigger, or if they go off just for the AS showing up in some unfamiliar path. Jack From rsk at gsp.org Wed Jan 14 08:24:50 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 14 Jan 2009 09:24:50 -0500 Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <496D3D85.6060709@gmail.com> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> <496D3D85.6060709@gmail.com> Message-ID: <20090114142450.GA25650@gsp.org> On Tue, Jan 13, 2009 at 05:19:01PM -0800, JC Dill wrote: > RSK wrote: >> 3. But it's utterly pointless to obfuscate addresses in such archives: >> spammers have long since set up quite efficient methods of harvesting >> any address used on any public mailng list or Usenet newsgroup. [1] The >> only people meaningfully impeded by these futile attempts at obfuscation >> are legitimate senders. > > Rich, I know that spammers can get an address by subscribing and > scarfing the emails that are used to post to the list. I just don't > want to see it be made any easier for them by idiots making their own > public web archives (when this list already has a web archive) and then > not obfuscating the email addresses. As you and others have also noted, > that's just plain rude. To be clear: I think setting up an unauthorized public archive of a mailing list, with or without email addresses, is rude. (I _might_ consider rare exceptions, such as very old mailing lists of historical interest whose owners are no longer around, but that's clearly not the case here.) List-owners should always be asked for their permission. But as far as making it easier for spammers: we're talking about the difference between lifting their pinky finger half a millimeter and grinding out, with tortuous effort, an entire millimeter. "Professional" address harvesters don't need and largely don't care about web-based archives: it's much simpler, easier and faster for them to go directly to the source and receive (so to speak) real-time feeds of valid addresses, which, as a bonus, come with "last time known-valid" data as well. Those feeds come from list subscriptions, NNTP feeds, malware infections, and other sources. So any address which: - is used on any public mailing list - is used in any Usenet newsgroup - is used to send mail to anyone who reads it on a Windows box - is used to send mail to any mail server running on a Windows box is going to be harvested -- it's only a question of when, and from there, it's only a question of when spammers will start trying to deliver to it. (Which probably means "shortly after they buy the latest address collection from the harvesters". The increasing division of labor and sophistication of the abuse industry has led to niche roles, i.e., it's cheaper and easier for spammers to just buy addresses than to do their own harvesting.) The best working assumption to make is that any email address that's actually used is going to be a target, and plan defenses accordingly. Once again, security by obscurity does not work -- which is why there is zero point in obfuscating addresses in list archives. ---Rsk From randy at psg.com Wed Jan 14 08:33:02 2009 From: randy at psg.com (Randy Bush) Date: Wed, 14 Jan 2009 23:33:02 +0900 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496DE7EB.5010404@brightok.net> References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net> <496BC876.8070704@psg.com> <787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com> <496BCAEF.6020401@psg.com> <787581440901121504p755ee81k8584491026ebf598@mail.gmail.com> <496BD03C.4080203@psg.com> <20090113002954.GA10395@ussenterprise.ufp.org> <620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com> <9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org> <20090113161248.GA64292@ussenterprise.ufp.org> <9D93A4BB-EDC2-4BFE-837F-C12988E2AAB8@ianai.net> <80B4BF09-CC61-41CB-9CE0-83A15CAFE521@hopcount.ca> <31f5977816cc97076ea7a2223627d30c.squirrel@webmail.pelican.org> <496DE7EB.5010404@brightok.net> Message-ID: <496DF79E.1060409@psg.com> > Yes, but I see that Randy has switched over to 3130 3130, when olaf first tested our his code in lab, it was against a quagga, which would not accept that. matt petach, in private email, asked why we were not doing it. as it seemed to be in spec, olaf did it against a crisco, and it works. thanks matt. randy From bill at edisys.co.uk Wed Jan 14 08:52:30 2009 From: bill at edisys.co.uk (William Hamilton) Date: Wed, 14 Jan 2009 14:52:30 -0000 (GMT) Subject: Are you getting Spam from Crossfire Media? In-Reply-To: <20090114142450.GA25650@gsp.org> References: <496CD25A.8010504@gmail.com> <9ab36b820901131143y42660757j7063c62a2e0cfa43@mail.gmail.com> <1231876916.32704.4.camel@ernie.internal.graemef.net> <496D3D85.6060709@gmail.com> <20090114142450.GA25650@gsp.org> Message-ID: <30834.83.104.210.137.1231944750.squirrel@shiva.edisys.co.uk> Rick, > - is used to send mail to anyone who reads it on a Windows box > - is used to send mail to any mail server running on a Windows box > > is going to be harvested -- it's only a question of when, and from there, > it's only a question of when spammers will start trying to deliver to it. Those are some quite sweeping generalisations there. What if I read my mail on a Windows box yet my mail service is a Linux host - does that mean I have a 50% chance of being harvested eventually? I also have a Macbook that I sometimes use to read my email on, what does that do to my chances? I agree that it *is* very rude when someone takes a mailing list and makes a public archive, but it has already been pointed out that anyone even remotely interested in obtaining addresses can join the list and get addressed and last-used data - plus a myriad other ways that addresses can be obtained. I have an email address and I have no real control over what a third party might do to my email address, ergo I am going to get spam eventually. >From looking back at the thread it seems that the spam was the result of a list being re-purposed for something else. If it was in the UK then there is legislation that would allow you to have a good go at the company, but all the technical and legal solutions in the world can't cure a lack of cluefulness. B From herrin-nanog at dirtside.com Wed Jan 14 09:47:23 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 14 Jan 2009 10:47:23 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A16D4@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <6316CD198EC8BC44A9D200F375869F1E4A16D4@nkc-mailsrv.nkc.org> Message-ID: <3c3e3fca0901140747i3f36b1caj1c0a2897ee0326@mail.gmail.com> On Mon, Jan 12, 2009 at 5:51 PM, Michienne Dixon wrote: > I would consider this analogous to a customer testing their home alarm > system and not letting the alarm company know about the test. It's more like one owner in a condominium deciding to "test" the fire alarm without first asking the condo association or letting the other owners know about it ahead of time. Or a charitable telemarketer demon-dialing at 5 am and, when you register your outrage, suggesting that if you don't want to be bothered you should turn off the ringer before you go to bed. On Mon, Jan 12, 2009 at 2:37 PM, Randy Bush wrote: >These prefixes are being used in academic routing research experiments. That's what the polling robocalls say around election time. They're just conducting research... Would you really want to harm the democratic process by insisting that they not call you? How hard is it to just hang up... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mdixon at nkc.org Wed Jan 14 09:50:39 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Wed, 14 Jan 2009 09:50:39 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> Interesting - So as a cyber criminal - I could setup a router, start announcing AS 16733, 18872, and maybe 6966 for good measure and their routers would ignore my announcements and IP ranges that I siphoned from searching IANA? Hm... Would that also prevent them from accessing my rogue network from their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Simon Lockhart [mailto:simon at slimey.org] Sent: Wednesday, January 14, 2009 2:07 AM To: Hank Nussbacher Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: > What if, by doing some research experiment, the researcher discovers > some unknown and latent bug in IOS or JunOS that causes much of the > Internet to go belly up? 1 in a billion chance, but nonetheless, a > headsup would have been in order. Say we had a customer who connected to us over BGP, and they used some new experimental BGP daemon. Their announcement was "odd" in some way, but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up. Should we have given a heads up to the Internet at large that we were turning up this customer? Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From bmanning at vacation.karoshi.com Wed Jan 14 09:54:48 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Jan 2009 15:54:48 +0000 Subject: orphan kit? Message-ID: <20090114155448.GB12525@vacation.karoshi.com.> Nortel board of directors vote to file bankruptcy http://www.nortel.com/corporate/restructuring.html From bmanning at vacation.karoshi.com Wed Jan 14 09:57:27 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Jan 2009 15:57:27 +0000 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> References: <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> Message-ID: <20090114155727.GA12642@vacation.karoshi.com.> welcome to the joys of anycast... :) --bill On Wed, Jan 14, 2009 at 09:50:39AM -0600, Michienne Dixon wrote: > > Interesting - So as a cyber criminal - I could setup a router, start > announcing AS 16733, 18872, and maybe 6966 for good measure and their > routers would ignore my announcements and IP ranges that I siphoned from > searching IANA? Hm... Would that also prevent them from accessing my > rogue network from their network? > > > > - > Michienne Dixon > Network Administrator > liNKCity > 312 Armour Rd. > North Kansas City, MO 64116 > www.linkcity.org > (816) 412-7990 > > -----Original Message----- > From: Simon Lockhart [mailto:simon at slimey.org] > Sent: Wednesday, January 14, 2009 2:07 AM > To: Hank Nussbacher > Cc: NANOG list > Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: > > What if, by doing some research experiment, the researcher discovers > > some unknown and latent bug in IOS or JunOS that causes much of the > > Internet to go belly up? 1 in a billion chance, but nonetheless, a > > headsup would have been in order. > > Say we had a customer who connected to us over BGP, and they used some > new experimental BGP daemon. Their announcement was "odd" in some way, > but appeared clean to us (a Cisco house). Once their announcement hit > the a Foundry router, it tickled a bug which caused the router to > propogate the announcement, but also start to blackhole traffic. Oh > dear, large chunks of the Internet have just gone belly up. > > Should we have given a heads up to the Internet at large that we were > turning up this customer? > > Simon > (Yes, I'm in the minority that thinks that Randy hasn't done anything > bad) > -- > > Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * > Director | * Domain & Web Hosting * Internet Consultancy * > Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * > > From frnkblk at iname.com Wed Jan 14 10:05:04 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 14 Jan 2009 10:05:04 -0600 Subject: Approach to allocating netblocks Message-ID: For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers. What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block? I was thinking of having one /24 for each block size, and then do the divide and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization. Ideas? Frank From mdixon at nkc.org Wed Jan 14 10:06:56 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Wed, 14 Jan 2009 10:06:56 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <89D27DE3375BB6428DDCC2927489826A01E70790@nexus.nexicomgroup.net><496BC876.8070704@psg.com><787581440901121454t71237c97uee9285df30e820d1@mail.gmail.com><496BCAEF.6020401@psg.com><787581440901121504p755ee81k8584491026ebf598@mail.gmail.com><496BD03C.4080203@psg.com><20090113002954.GA10395@ussenterprise.ufp.org><620fd17c0901122105jacd3aa3jaf88a5302503e52@mail.gmail.com><9FBD1A9D-4148-4284-80CE-C0F3B9159EEF@sackheads.org><20090113161248.GA64292@ussenterprise.ufp.org> <89D27DE3375BB6428DDCC2927489826A01E70A32@nexus.nexicomgroup.net> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A1739@nkc-mailsrv.nkc.org> Like Paul said below - On the surface it looked legit. I received a notice indicating my AS had done some wrong and that I should correct the issue. Of course I am going to investigate - Maybe I fat fingered something or one of my tech had done something like not clearing the code of a lab router when connecting it to the production network. Or....Maybe there was something nefarious going. When I attempted to contact the source of the notice and inform them that I was not hijacking IP space the message bounced. I did look up the owner of the netblock. I saw that it was an experimental range. I sent an email to Randy (sorry for the fire storm that followed) but did not receive a response. Being the reformed juvenile delinquent I am, my line of thought went to "Hm...Someone could be up to no-good. I better find out more." I could have chosen to ignore it and say "WTF, I'm not doing anything wrong. Why should I care?". Instead I chose to ask my peers, many of whom are much more knowledgeable than I am, because I feel as network engineers, administrators, and router-jocks, it is our responsibility to safe-guard internet traffic and insure reliable communication when we can. /My $.02 - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: Tuesday, January 13, 2009 2:52 PM To: Joe Abley; Patrick W. Gilmore Cc: NANOG list Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Ummmmm.. no. I can't speak for the others on this list who were effected like us - but we take this stuff very seriously and respectively you would too *if* you had a previous legit issue that appeared to the same **on the surface**. A cautious and indepth look at this was taken upon us hoping that history wasn't repeating itself (previously explained) and thankfully it wasn't ... but until the time is spent to make absolutely sure how do you know?? At the end of the day, it wasn't a serious operational issue but raised a number of concerns I believe.... Paul From jeroen at unfix.org Wed Jan 14 10:06:46 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 14 Jan 2009 17:06:46 +0100 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> Message-ID: <496E0D96.6070901@spaghetti.zurich.ibm.com> Simon Lockhart [mailto:simon at slimey.org] wrote: > On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: >> What if, by doing some research experiment, the researcher discovers >> some unknown and latent bug in IOS or JunOS that causes much of the >> Internet to go belly up? 1 in a billion chance, but nonetheless, a >> headsup would have been in order. > > Say we had a customer who connected to us over BGP, and they used some > new experimental BGP daemon. Their announcement was "odd" in some way, > but appeared clean to us (a Cisco house). Once their announcement hit > the a Foundry router, it tickled a bug which caused the router to > propogate the announcement, but also start to blackhole traffic. Oh > dear, large chunks of the Internet have just gone belly up. You mean like when people started using 32bit ASNs and all OpenBGPD implementations went belly up? See http://www.merit.edu/mail.archives/nanog/msg13416.html Happening clearly often. People should write proper implementations (Just in case, OpenBGPD acted correctly as it did it to the letter of the RFC, though it could have maybe warned the admins) > Should we have given a heads up to the Internet at large that we were > turning up this customer? ASN32 was known quite in advance, that doesn't mean that everybody updates or that all bugs are found. Vendors tend to deploy things into the wild which then break, simply because not all combinations of configuration can ever be tested. Infinite Monkeys etc ;) > Simon > (Yes, I'm in the minority that thinks that Randy hasn't done anything > bad) Nah, I agree with Randy's experiment too. People should protect their networks better and this is clearly showing that there are a lot of vulnerable places in the core internet structure. Btw folks, when do you start implementing RPSL based filtering? Clearly a lot are using the BGP monitoring already and seem to love it, thus take the next step go full SIDR :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From davei at otd.com Wed Jan 14 10:17:20 2009 From: davei at otd.com (Dave Israel) Date: Wed, 14 Jan 2009 11:17:20 -0500 Subject: Approach to allocating netblocks In-Reply-To: References: Message-ID: <496E1010.1030702@otd.com> If most of your allocations are small, and you don't plan on growing them very often, you'll probably do better with starting at the ends and working your way inward.For example,. for /30s, allocate 0/30, then 4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and 244/30. That way you're preserving larger netblocks for as long as possible before breaking them up. Frank Bulk wrote: > For the first time we have our own ARIN-assigned netblocks that we can now > split out and divide to our customers. > > What's the best approach to handing out /30's, /29's, etc. that is efficient > as possible but allows for customers to expand their allocation to a > neighboring block? > > I was thinking of having one /24 for each block size, and then do the divide > and conquer approach by allocating the first /30, for example, as 0 and 128, > then next two at 64 and 192, etc. Once there's only one /30 free between > each allocation, I would start using another /24. Of course, that would > mean 50% (or less) utilization. > > Ideas? > > Frank > > From frnkblk at iname.com Wed Jan 14 10:30:18 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 14 Jan 2009 10:30:18 -0600 Subject: Approach to allocating netblocks In-Reply-To: <496E1010.1030702@otd.com> References: <496E1010.1030702@otd.com> Message-ID: I see what you're saying, but what if the customer whom you assigned the 0/30 to wants a larger block...rather than making them renumber (which in the case of a small customer, is a very painful experience because of all the DNS and router/firewall reconfiguration issues that they don't normally deal with and therefore cause their service provider (us) and their consultant a lot of grief), I would want to give them 0/29. But if the 4/30 is already assigned to someone else, I'm stuck. But perhaps the BCP is to make the customer renumber, in which case I'm making things more complicated than they need to be. Frank -----Original Message----- From: Dave Israel [mailto:davei at otd.com] Sent: Wednesday, January 14, 2009 10:17 AM To: frnkblk at iname.com Cc: NANOG list Subject: Re: Approach to allocating netblocks If most of your allocations are small, and you don't plan on growing them very often, you'll probably do better with starting at the ends and working your way inward.For example,. for /30s, allocate 0/30, then 4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and 244/30. That way you're preserving larger netblocks for as long as possible before breaking them up. Frank Bulk wrote: > For the first time we have our own ARIN-assigned netblocks that we can now > split out and divide to our customers. > > What's the best approach to handing out /30's, /29's, etc. that is efficient > as possible but allows for customers to expand their allocation to a > neighboring block? > > I was thinking of having one /24 for each block size, and then do the divide > and conquer approach by allocating the first /30, for example, as 0 and 128, > then next two at 64 and 192, etc. Once there's only one /30 free between > each allocation, I would start using another /24. Of course, that would > mean 50% (or less) utilization. > > Ideas? > > Frank > > From jason at biel-tech.com Wed Jan 14 10:34:29 2009 From: jason at biel-tech.com (Jason Biel) Date: Wed, 14 Jan 2009 10:34:29 -0600 Subject: Approach to allocating netblocks In-Reply-To: References: <496E1010.1030702@otd.com> Message-ID: Customer should have the forethought to request the right amount of space to include for growth. If customer requested more space, rather than grow into another adjacent block, we would just assign them an additional block elsewhere in the overall subnet, and route both blocks to them. Jason On Wed, Jan 14, 2009 at 10:30 AM, Frank Bulk wrote: > I see what you're saying, but what if the customer whom you assigned the > 0/30 to wants a larger block...rather than making them renumber (which in > the case of a small customer, is a very painful experience because of all > the DNS and router/firewall reconfiguration issues that they don't normally > deal with and therefore cause their service provider (us) and their > consultant a lot of grief), I would want to give them 0/29. But if the > 4/30 > is already assigned to someone else, I'm stuck. > > But perhaps the BCP is to make the customer renumber, in which case I'm > making things more complicated than they need to be. > > Frank > > -----Original Message----- > From: Dave Israel [mailto:davei at otd.com] > Sent: Wednesday, January 14, 2009 10:17 AM > To: frnkblk at iname.com > Cc: NANOG list > Subject: Re: Approach to allocating netblocks > > > If most of your allocations are small, and you don't plan on growing > them very often, you'll probably do better with starting at the ends and > working your way inward.For example,. for /30s, allocate 0/30, then > 4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and > 244/30. That way you're preserving larger netblocks for as long as > possible before breaking them up. > > > Frank Bulk wrote: > > For the first time we have our own ARIN-assigned netblocks that we can > now > > split out and divide to our customers. > > > > What's the best approach to handing out /30's, /29's, etc. that is > efficient > > as possible but allows for customers to expand their allocation to a > > neighboring block? > > > > I was thinking of having one /24 for each block size, and then do the > divide > > and conquer approach by allocating the first /30, for example, as 0 and > 128, > > then next two at 64 and 192, etc. Once there's only one /30 free between > > each allocation, I would start using another /24. Of course, that would > > mean 50% (or less) utilization. > > > > Ideas? > > > > Frank > > > > > > > -- Jason Biel jason at biel-tech.com From greg at bestnet.kharkov.ua Wed Jan 14 10:37:20 2009 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Wed, 14 Jan 2009 18:37:20 +0200 Subject: flattengraph.pl Message-ID: <496E14C0.4090803@bestnet.kharkov.ua> Hello, I have some problems with peaks on my mrtg, therefore I went to list archives on mrtg,org, and saw what's available. Then I found out that there is some script called flattengraph.pl, which I believe could help me with the situation. However this program is not available anymore and I cannot find and download it anywhere. So if some good soul will give me a link, or send me the file, I will be really grateful. Thanks a lot in advance. -- With best regards, Gregory Edigarov From streiner at cluebyfour.org Wed Jan 14 10:40:40 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 Jan 2009 11:40:40 -0500 (EST) Subject: flattengraph.pl In-Reply-To: <496E14C0.4090803@bestnet.kharkov.ua> References: <496E14C0.4090803@bestnet.kharkov.ua> Message-ID: On Wed, 14 Jan 2009, Gregory Edigarov wrote: > I have some problems with peaks on my mrtg, therefore I went to list archives > on mrtg,org, and saw what's available. > Then I found out that there is some script called flattengraph.pl, which I > believe could help me > with the situation. However this program is not available anymore and I > cannot find and download it anywhere. > So if some good soul will give me a link, or send me the file, I will be > really grateful. While it is entirely possible that someone on NANOG has this script, or has a pointer to a download location, you would probably be better off checking on the MRTG mailing list. https://lists.oetiker.ch/cgi-bin/listinfo/mrtg jms From cgrundemann at gmail.com Wed Jan 14 10:50:21 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 14 Jan 2009 09:50:21 -0700 Subject: Approach to allocating netblocks In-Reply-To: References: Message-ID: <443de7ad0901140850y1f269aa0rbd0e7a9ae839004c@mail.gmail.com> On Wed, Jan 14, 2009 at 09:05, Frank Bulk wrote: > For the first time we have our own ARIN-assigned netblocks that we can now > split out and divide to our customers. > > What's the best approach to handing out /30's, /29's, etc. that is efficient > as possible but allows for customers to expand their allocation to a > neighboring block? We pay much more attn to efficient utilization and advertisement aggregation than to ensuring that customers have contiguous blocks. For example, we internally assign a /24 to a given PE router and then assign from it straight through; 0/30, 4/30, 8/29, etc. as customers get turned up or request more space. Then when it's used up, we add another... Although it is neat and tidy to have contiguous blocks everywhere, the cost to benefit doesn't seem to be there so we focus on aggregation at transition points such as edge to backbone, backbone to peers, etc. ~Chris > I was thinking of having one /24 for each block size, and then do the divide > and conquer approach by allocating the first /30, for example, as 0 and 128, > then next two at 64 and 192, etc. Once there's only one /30 free between > each allocation, I would start using another /24. Of course, that would > mean 50% (or less) utilization. > > Ideas? > > Frank > > > -- Chris Grundemann www.chrisgrundemann.com From xmin0s at gmail.com Wed Jan 14 11:04:38 2009 From: xmin0s at gmail.com (Tim Eberhard) Date: Wed, 14 Jan 2009 11:04:38 -0600 Subject: flattengraph.pl In-Reply-To: <496E14C0.4090803@bestnet.kharkov.ua> References: <496E14C0.4090803@bestnet.kharkov.ua> Message-ID: <2c52b84e0901140904v798e0d77m5e901e20c34c74d7@mail.gmail.com> I would suggest looking at Killspike. Works wonders in Cacti (A mtrg based app) Good luck, -Tim Eberhard On Wed, Jan 14, 2009 at 10:37 AM, Gregory Edigarov wrote: > Hello, > > I have some problems with peaks on my mrtg, therefore I went to list > archives on mrtg,org, and saw what's available. > Then I found out that there is some script called flattengraph.pl, which > I believe could help me > with the situation. However this program is not available anymore and I > cannot find and download it anywhere. > So if some good soul will give me a link, or send me the file, I will be > really grateful. > > Thanks a lot in advance. > > > -- > With best regards, > Gregory Edigarov > > > From aidanwhyte at gmail.com Wed Jan 14 11:04:40 2009 From: aidanwhyte at gmail.com (Aidan Whyte) Date: Wed, 14 Jan 2009 17:04:40 +0000 Subject: Approach to allocating netblocks In-Reply-To: References: <496E1010.1030702@otd.com> <9c319d610901140835u834e861j4d5f8a9f1d32c1b5@mail.gmail.com> Message-ID: <9c319d610901140904t500c0cc0mb762a4cc5f4748ee@mail.gmail.com> I guess it might depend on the general profile of your customers' requirements, but I'd imagine that non-contiguous blocks will be far more efficient in the long run, with the added benefit of no need for customers to pursue a renumbering plan every N years which should nearly always be avoided in any case imho. Obviously, the smaller the average block size the less efficient it becomes. If the customers are honest in their expected future ip address requirements it shouldn't be that often that they'll need more address space in any case. Aidan 2009/1/14 Frank Bulk : > Secondary IPs, additional documentation and confusion, and less efficient > use of address space, are just a few negatives of assigning more netblocks. > > Frank > > -----Original Message----- > From: Aidan Whyte [mailto:aidanwhyte at gmail.com] > Sent: Wednesday, January 14, 2009 10:35 AM > To: frnkblk at iname.com > Subject: Re: Approach to allocating netblocks > > Perhaps I'm missing something, but I've never seen much of a problem > with non-contiguous blocks for customer address space expansion.. From greg at bestnet.kharkov.ua Wed Jan 14 11:12:29 2009 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Wed, 14 Jan 2009 19:12:29 +0200 Subject: flattengraph.pl In-Reply-To: <2c52b84e0901140904v798e0d77m5e901e20c34c74d7@mail.gmail.com> References: <496E14C0.4090803@bestnet.kharkov.ua> <2c52b84e0901140904v798e0d77m5e901e20c34c74d7@mail.gmail.com> Message-ID: <496E1CFD.3000306@bestnet.kharkov.ua> Tim, Forgive me if I'm mistaken, but AFAIR killspike works with rrdtool, while i need to do magic on an old mrtg log format. -- With best regards, Gregory Edigarov Tim Eberhard wrote: > I would suggest looking at Killspike. Works wonders in Cacti (A mtrg > based app) > > Good luck, > > -Tim Eberhard > > On Wed, Jan 14, 2009 at 10:37 AM, Gregory Edigarov > > wrote: > > Hello, > > I have some problems with peaks on my mrtg, therefore I went to > list archives on mrtg,org, and saw what's available. > Then I found out that there is some script called > flattengraph.pl, which I believe could help me > with the situation. However this program is not available anymore > and I cannot find and download it anywhere. > So if some good soul will give me a link, or send me the file, I > will be really grateful. > > Thanks a lot in advance. > > > -- > With best regards, > Gregory Edigarov > > > From xmin0s at gmail.com Wed Jan 14 11:20:32 2009 From: xmin0s at gmail.com (Tim Eberhard) Date: Wed, 14 Jan 2009 11:20:32 -0600 Subject: flattengraph.pl In-Reply-To: <496E1CFD.3000306@bestnet.kharkov.ua> References: <496E14C0.4090803@bestnet.kharkov.ua> <2c52b84e0901140904v798e0d77m5e901e20c34c74d7@mail.gmail.com> <496E1CFD.3000306@bestnet.kharkov.ua> Message-ID: <2c52b84e0901140920j7101b74pa12b77db91b7df4@mail.gmail.com> My apologies you are correct. AFAIK killspike only works on rrdtool based set ups. If you have to use the old mrtg log system then it wouldn't help you in this case. If you were using MRTG with rrdtool you wouldn't have any issues however. Not sure if it's possible in your deployment but this might help you. http://oss.oetiker.ch/mrtg/doc/mrtg-rrd.en.html Good luck, sorry to lead you astray. -Tim Eberhard On Wed, Jan 14, 2009 at 11:12 AM, Gregory Edigarov wrote: > Tim, > > Forgive me if I'm mistaken, but AFAIR killspike works with rrdtool, while i > need to do magic on an old mrtg log format. > > -- > With best regards, > Gregory Edigarov > > > Tim Eberhard wrote: > >> I would suggest looking at Killspike. Works wonders in Cacti (A mtrg based >> app) >> >> Good luck, >> >> -Tim Eberhard >> >> On Wed, Jan 14, 2009 at 10:37 AM, Gregory Edigarov < >> greg at bestnet.kharkov.ua > wrote: >> >> Hello, >> >> I have some problems with peaks on my mrtg, therefore I went to >> list archives on mrtg,org, and saw what's available. >> Then I found out that there is some script called >> flattengraph.pl, which I believe could help me >> with the situation. However this program is not available anymore >> and I cannot find and download it anywhere. >> So if some good soul will give me a link, or send me the file, I >> will be really grateful. >> >> Thanks a lot in advance. >> >> >> -- With best regards, >> Gregory Edigarov >> >> >> >> > From jbates at brightok.net Wed Jan 14 11:23:35 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 14 Jan 2009 11:23:35 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> Message-ID: <496E1F97.4050707@brightok.net> Michienne Dixon wrote: > Interesting - So as a cyber criminal - I could setup a router, start > announcing AS 16733, 18872, and maybe 6966 for good measure and their > routers would ignore my announcements and IP ranges that I siphoned from > searching IANA? Hm... Would that also prevent them from accessing my > rogue network from their network? > It may or may not prevent them from accessing your rogue network. FYI, given that this is a reachability test, it sounds like this is exactly the question Randy should be able to answer in the results. The other keys are, how effective is it at traffic engineering for load shifting and partitioning anycast. Jack From Valdis.Kletnieks at vt.edu Wed Jan 14 12:22:55 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 14 Jan 2009 13:22:55 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: Your message of "Wed, 14 Jan 2009 10:47:23 EST." <3c3e3fca0901140747i3f36b1caj1c0a2897ee0326@mail.gmail.com> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <6316CD198EC8BC44A9D200F375869F1E4A16D4@nkc-mailsrv.nkc.org> <3c3e3fca0901140747i3f36b1caj1c0a2897ee0326@mail.gmail.com> Message-ID: <21178.1231957375@turing-police.cc.vt.edu> On Wed, 14 Jan 2009 10:47:23 EST, William Herrin said: > It's more like one owner in a condominium deciding to "test" the fire > alarm without first asking the condo association or letting the other > owners know about it ahead of time. On the other hand, pre-announcing "We will have a fire drill at 8PM Thursday" doesn't do a whole lot to measure the response effectiveness - everybody will start getting their shoes and coats on at 7:55PM. And yes, it applies in the network world as well. When we pre-announce "We will be doing network scans from IP address w.x.y.z", we have a lot of users who will just blindly firewall off that IP rather than fixing their real issue they know the scan will detect... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jkinz at kinz.org Wed Jan 14 12:39:27 2009 From: jkinz at kinz.org (jkinz at kinz.org) Date: Wed, 14 Jan 2009 13:39:27 -0500 Subject: Approach to allocating netblocks In-Reply-To: References: <496E1010.1030702@otd.com> Message-ID: <20090114183927.GB14260@redline.kinz.org> On Wed, Jan 14, 2009 at 10:34:29AM -0600, Jason Biel wrote: > Customer should have the forethought to request the right amount of space to > include for growth. hmm, as a vict^H^H^H^H former associate of a few startups I can assure you the customer will almost never know how much space they need for growth, or when. :) > If customer requested more space, rather than grow into another adjacent > block, we would just assign them an additional block elsewhere in the > overall subnet, and route both blocks to them. Seems reasonable as long as it can be done whenever the customer discovers they really do need more space. Jeff Kinz From leothelion.murtaza at gmail.com Wed Jan 14 13:46:06 2009 From: leothelion.murtaza at gmail.com (Murtaza) Date: Thu, 15 Jan 2009 00:46:06 +0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <21178.1231957375@turing-police.cc.vt.edu> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <6316CD198EC8BC44A9D200F375869F1E4A16D4@nkc-mailsrv.nkc.org> <3c3e3fca0901140747i3f36b1caj1c0a2897ee0326@mail.gmail.com> <21178.1231957375@turing-police.cc.vt.edu> Message-ID: <949b74980901141146w44a23ab4l19967930bc092f80@mail.gmail.com> Knowing the Randy's research, i am sure that Randy will be doing great work this time too. Being a network researcher I can not wait more to see results of this experiments. But, even then I dont think it was a real smart thing to do without prior permission. > And yes, it applies in the network world as well. When we pre-announce "We > will be doing network scans from IP address w.x.y.z", we have a lot of > users > who will just blindly firewall off that IP rather than fixing their real > issue > they know the scan will detect... > > I think if this could have been the case in the network security research then we would not have some this far (though it still is not that far :) ) in the field. People have contributed specifically for research in the past and I hope will remain doing so. -- Ghulam Murtaza Lahore University of Management Sciences From john at sackheads.org Wed Jan 14 15:57:13 2009 From: john at sackheads.org (John Payne) Date: Wed, 14 Jan 2009 16:57:13 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> Message-ID: <3BE183A5-B1C9-46E8-8A1D-E7ACED72EA8C@sackheads.org> On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote: > > Interesting - So as a cyber criminal - I could setup a router, start > announcing AS 16733, 18872, and maybe 6966 for good measure and their > routers would ignore my announcements and IP ranges that I siphoned > from > searching IANA? Hm... Would that also prevent them from accessing my > rogue network from their network? What do you mean "announcing AS 16733..." ? Putting 16733 in an AS PATH is not announcing it. > > > > > - > Michienne Dixon > Network Administrator > liNKCity > 312 Armour Rd. > North Kansas City, MO 64116 > www.linkcity.org > (816) 412-7990 > > -----Original Message----- > From: Simon Lockhart [mailto:simon at slimey.org] > Sent: Wednesday, January 14, 2009 2:07 AM > To: Hank Nussbacher > Cc: NANOG list > Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: >> What if, by doing some research experiment, the researcher discovers >> some unknown and latent bug in IOS or JunOS that causes much of the >> Internet to go belly up? 1 in a billion chance, but nonetheless, a >> headsup would have been in order. > > Say we had a customer who connected to us over BGP, and they used some > new experimental BGP daemon. Their announcement was "odd" in some way, > but appeared clean to us (a Cisco house). Once their announcement hit > the a Foundry router, it tickled a bug which caused the router to > propogate the announcement, but also start to blackhole traffic. Oh > dear, large chunks of the Internet have just gone belly up. > > Should we have given a heads up to the Internet at large that we were > turning up this customer? > > Simon > (Yes, I'm in the minority that thinks that Randy hasn't done anything > bad) > -- > > Simon Lockhart | * Sun Server Colocation * ADSL * Domain > Registration * > Director | * Domain & Web Hosting * Internet Consultancy * > Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * > > From herrin-nanog at dirtside.com Wed Jan 14 16:06:58 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 14 Jan 2009 17:06:58 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <21178.1231957375@turing-police.cc.vt.edu> References: <6316CD198EC8BC44A9D200F375869F1E4A16BA@nkc-mailsrv.nkc.org> <496B9BE3.8020700@psg.com> <87k590xnqy.fsf@mid.deneb.enyo.de> <7E6FC8D9-18BE-4546-A8E0-701EAD175A3B@hopcount.ca> <16C9A32D-ADE6-4F7B-BE05-63A2F5F7B51B@ianai.net> <882A5D34-A658-442F-BE5A-7606F1923D3D@hopcount.ca> <6316CD198EC8BC44A9D200F375869F1E4A16D4@nkc-mailsrv.nkc.org> <3c3e3fca0901140747i3f36b1caj1c0a2897ee0326@mail.gmail.com> <21178.1231957375@turing-police.cc.vt.edu> Message-ID: <3c3e3fca0901141406q28e84069m54adea73e77f3602@mail.gmail.com> On Wed, Jan 14, 2009 at 1:22 PM, wrote: > On Wed, 14 Jan 2009 10:47:23 EST, William Herrin said: >> It's more like one owner in a condominium deciding to "test" the fire >> alarm without first asking the condo association or letting the other >> owners know about it ahead of time. > > On the other hand, pre-announcing "We will have a fire drill at 8PM Thursday" > doesn't do a whole lot to measure the response effectiveness - everybody > will start getting their shoes and coats on at 7:55PM. Tough. One of the greatest difficulties associated with research is that the researcher is expected to follow ethical constraints which impair the effectiveness of the research. Things like soliciting permission from the participants before using them as research subjects. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Jay.Murphy at state.nm.us Wed Jan 14 14:56:11 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 14 Jan 2009 13:56:11 -0700 Subject: Which is more efficient? Message-ID: All, In your humble opinion, which transmission method is more efficient, packet or cell? Granted a cell is a fixed length packet and an IP packet is variable length....would this necessarily only relate to a specific protocol, namely, cell in ATM, and IP in Ethernet or other types of domains....feedback highly welcomed. Trying to make a decision on the transport mode for cost, delay, jitter, ROI, etcetera. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa F?, New M?xico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From mdixon at nkc.org Wed Jan 14 16:52:42 2009 From: mdixon at nkc.org (Michienne Dixon) Date: Wed, 14 Jan 2009 16:52:42 -0600 Subject: Anyone notice strange announcements for 174.128.31.0/24 References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> <3BE183A5-B1C9-46E8-8A1D-E7ACED72EA8C@sackheads.org> Message-ID: <6316CD198EC8BC44A9D200F375869F1E4A1754@nkc-mailsrv.nkc.org> Well, if you really want to pick knits you are welcome to. If I meant prepending, I would have said that. The example that I listed was setting up a router, advertising the ASNs listed and the random IP ranges gleaned from IANA. Sorry if I confused you. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: John Payne [mailto:john at sackheads.org] Sent: Wednesday, January 14, 2009 3:57 PM To: Michienne Dixon Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote: > > Interesting - So as a cyber criminal - I could setup a router, start > announcing AS 16733, 18872, and maybe 6966 for good measure and their > routers would ignore my announcements and IP ranges that I siphoned > from searching IANA? Hm... Would that also prevent them from > accessing my rogue network from their network? What do you mean "announcing AS 16733..." ? Putting 16733 in an AS PATH is not announcing it. > > > > > - > Michienne Dixon > Network Administrator > liNKCity > 312 Armour Rd. > North Kansas City, MO 64116 > www.linkcity.org > (816) 412-7990 > > -----Original Message----- > From: Simon Lockhart [mailto:simon at slimey.org] > Sent: Wednesday, January 14, 2009 2:07 AM > To: Hank Nussbacher > Cc: NANOG list > Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: >> What if, by doing some research experiment, the researcher discovers >> some unknown and latent bug in IOS or JunOS that causes much of the >> Internet to go belly up? 1 in a billion chance, but nonetheless, a >> headsup would have been in order. > > Say we had a customer who connected to us over BGP, and they used some > new experimental BGP daemon. Their announcement was "odd" in some way, > but appeared clean to us (a Cisco house). Once their announcement hit > the a Foundry router, it tickled a bug which caused the router to > propogate the announcement, but also start to blackhole traffic. Oh > dear, large chunks of the Internet have just gone belly up. > > Should we have given a heads up to the Internet at large that we were > turning up this customer? > > Simon > (Yes, I'm in the minority that thinks that Randy hasn't done anything > bad) > -- > > Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration > * > Director | * Domain & Web Hosting * Internet Consultancy * > Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * > > From scott.berkman at reignmaker.net Wed Jan 14 16:59:18 2009 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Wed, 14 Jan 2009 17:59:18 -0500 (EST) Subject: Which is more efficient? In-Reply-To: References: Message-ID: <01b501c9769c$5496e240$fdc4a6c0$@berkman@reignmaker.net> Packets can have a max size as well based on the path MTU, such as 1500 bytes in an Ethernet (10/100) link. I think there are a lot of other variables here such as are you billed per data unit, bandwidth and control factors on the links, and what type of data is being sent. If your data can always fit in a smaller N-byte cell, that can be quite efficient since you have minimal overhead or wasted space and all the benefits of the fixed length data unit from a processing standpoint. If you are constantly fragmenting and then having to reassemble data due to the small cell size, you would be better off with a variable length packet, especially when bandwidth is less in demand than processing power. -Scott -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Wednesday, January 14, 2009 3:56 PM To: nanog at nanog.org Subject: Which is more efficient? All, In your humble opinion, which transmission method is more efficient, packet or cell? Granted a cell is a fixed length packet and an IP packet is variable length....would this necessarily only relate to a specific protocol, namely, cell in ATM, and IP in Ethernet or other types of domains....feedback highly welcomed. Trying to make a decision on the transport mode for cost, delay, jitter, ROI, etcetera. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa F?, New M?xico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From joshpotter at gmail.com Wed Jan 14 17:11:51 2009 From: joshpotter at gmail.com (Josh Potter) Date: Wed, 14 Jan 2009 17:11:51 -0600 Subject: Which is more efficient? In-Reply-To: <-6875281633706503708@unknownmsgid> References: <-6875281633706503708@unknownmsgid> Message-ID: <4a64e2f70901141511v1e20dfcfne1c5f179dd8b5f99@mail.gmail.com> What type of traffic are you looking at sending? As Scott said smaller payloads that need to be sent quickly work out well in fixed cells but larger payloads would be better off in variable sized packets. Also are you looking at simple data transmission rates or are you wanting to factor in hardware load, backplane load, cpu efficiency etc? On Wed, Jan 14, 2009 at 4:59 PM, Scott Berkman wrote: > Packets can have a max size as well based on the path MTU, such as 1500 > bytes in an Ethernet (10/100) link. I think there are a lot of other > variables here such as are you billed per data unit, bandwidth and control > factors on the links, and what type of data is being sent. > > If your data can always fit in a smaller N-byte cell, that can be quite > efficient since you have minimal overhead or wasted space and all the > benefits of the fixed length data unit from a processing standpoint. > > If you are constantly fragmenting and then having to reassemble data due > to the small cell size, you would be better off with a variable length > packet, especially when bandwidth is less in demand than processing power. > > -Scott > > -----Original Message----- > From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] > Sent: Wednesday, January 14, 2009 3:56 PM > To: nanog at nanog.org > Subject: Which is more efficient? > > > All, > > In your humble opinion, which transmission method is more efficient, > packet or cell? Granted a cell is a fixed length packet and an IP packet > is variable length....would this necessarily only relate to a specific > protocol, namely, cell in ATM, and IP in Ethernet or other types of > domains....feedback highly welcomed. Trying to make a decision on the > transport mode for cost, delay, jitter, ROI, etcetera. > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa F?, New M?xico 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Confidentiality Notice: This e-mail, including all attachments is for the > sole use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited unless specifically provided under the New > Mexico Inspection of Public Records Act. If you are not the intended > recipient, please contact the sender and destroy all copies of this > message. -- This email has been scanned by the Sybari - Antigen Email > System. > > > > > -- Josh Potter From kris.foster at gmail.com Wed Jan 14 17:22:53 2009 From: kris.foster at gmail.com (kris foster) Date: Wed, 14 Jan 2009 15:22:53 -0800 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E4A1754@nkc-mailsrv.nkc.org> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> <3BE183A5-B1C9-46E8-8A1D-E7ACED72EA8C@sackheads.org> <6316CD198EC8BC44A9D200F375869F1E4A1754@nkc-mailsrv.nkc.org> Message-ID: <3CFE4CF7-ADA0-4C43-93A0-9CA62955DA92@gmail.com> On Jan 14, 2009, at 2:52 PM, Michienne Dixon wrote: > Well, if you really want to pick knits you are welcome to. If I meant > prepending, I would have said that. The example that I listed was > setting up a router, advertising the ASNs listed and the random IP > ranges gleaned from IANA. Sorry if I confused you. The point I believe John is trying to make is that *ASNs are not announced*. There are no advertisements that say "this is how to get to ASN X". BGP updates specifically announce network layer reachability. This is an important point in this discussion. There are a lot of comments being made that are just simply wrong and causing confusion because of slips in terminology regarding the path attribute. Kris > -----Original Message----- > From: John Payne [mailto:john at sackheads.org] > Sent: Wednesday, January 14, 2009 3:57 PM > To: Michienne Dixon > Cc: NANOG list > Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 > > > On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote: > >> >> Interesting - So as a cyber criminal - I could setup a router, start >> announcing AS 16733, 18872, and maybe 6966 for good measure and their >> routers would ignore my announcements and IP ranges that I siphoned >> from searching IANA? Hm... Would that also prevent them from >> accessing my rogue network from their network? > > > What do you mean "announcing AS 16733..." ? > > Putting 16733 in an AS PATH is not announcing it. > >> >> >> >> >> - >> Michienne Dixon >> Network Administrator >> liNKCity >> 312 Armour Rd. >> North Kansas City, MO 64116 >> www.linkcity.org >> (816) 412-7990 >> >> -----Original Message----- >> From: Simon Lockhart [mailto:simon at slimey.org] >> Sent: Wednesday, January 14, 2009 2:07 AM >> To: Hank Nussbacher >> Cc: NANOG list >> Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 >> >> On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: >>> What if, by doing some research experiment, the researcher discovers >>> some unknown and latent bug in IOS or JunOS that causes much of the >>> Internet to go belly up? 1 in a billion chance, but nonetheless, a >>> headsup would have been in order. >> >> Say we had a customer who connected to us over BGP, and they used >> some > >> new experimental BGP daemon. Their announcement was "odd" in some >> way, > >> but appeared clean to us (a Cisco house). Once their announcement hit >> the a Foundry router, it tickled a bug which caused the router to >> propogate the announcement, but also start to blackhole traffic. Oh >> dear, large chunks of the Internet have just gone belly up. >> >> Should we have given a heads up to the Internet at large that we were >> turning up this customer? >> >> Simon >> (Yes, I'm in the minority that thinks that Randy hasn't done anything >> bad) >> -- >> >> Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration >> * >> Director | * Domain & Web Hosting * Internet Consultancy * >> Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * >> >> > > From john at vanoppen.com Wed Jan 14 17:56:22 2009 From: john at vanoppen.com (John van Oppen) Date: Wed, 14 Jan 2009 15:56:22 -0800 Subject: Cogent Haiku v2.0 References: <9515c62d0901111859o2e7327dbua6be624ab32532b1@mail.gmail.com><82a67ea80901120954s4b4e27a8qbc74d66659c198e0@mail.gmail.com> <16720fe00901121002p7171c30bl826eaaf66358749f@mail.gmail.com> Message-ID: The main problem I see is peering wars and a lack of diversity, we have seen a couple incidents where they have dropped all or part of their connectivity to our market (seattle), during the latter they had major packet-loss which was frankly more annoying than them being down... Issues also tend to be a tad more frequent than other providers but on the whole, really not that bad. We basically use cogent as private peering to reach their customers. Operationally the incredibly annoying part is their helpdesk-style attitude towards prefix-lists, if you have a few prefixes this is no big deal but if you are like us and have 30+ downstream ASNs it can get annoying to repetadily explain to techs who don't get it why you need to have them add more routes, do le 24 matching (to limit the number of times we call) or to increase their max-prefix limit. If they were not so cheap I would cancel them just due to the lack of RADB support but at least they have no uRPF filters so I have taken to just doing batch prefix-list updates with them every few months as my sanity-saving solution. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon at blacklotus.net] Sent: Monday, January 12, 2009 10:02 AM To: Mike Bartz Cc: nanog at nanog.org Subject: Re: Cogent Haiku v2.0 Mike, Aside from the occasional peering wars i've never had or witnessed any serious issues with Cogent. If you want some redundancy you might also try some other similarly priced providers like WBS Connect, HE, or BtN. Best regards, Jeff On Mon, Jan 12, 2009 at 12:54 PM, Mike Bartz wrote: > I like the haiku! On a serious note, we are considering getting a > connection from Cogent. We currently have connections to at&t, Level > 3 and TW Telecom. The low cost and high number of peer AS number's > seems appealing to us. Every carrier has its issues, so I don't know > what to make of the apparent negativity that I am seeing in these > haiku threads. I am looking for some first hand experiences to help > me make this decision. > > Thanks for any assistance! > > Mike > > > On Sun, Jan 11, 2009 at 9:59 PM, neal rauhauser wrote: >> Cogent makes a mess >> My phone rings and rings >> Unfornicate this! >> > > > > -- > Mike Bartz > mob at bartzfamily.net > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From andy at nosignal.org Thu Jan 15 02:54:29 2009 From: andy at nosignal.org (Andy Davidson) Date: Thu, 15 Jan 2009 08:54:29 +0000 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <496E0D96.6070901@spaghetti.zurich.ibm.com> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> <496E0D96.6070901@spaghetti.zurich.ibm.com> Message-ID: <5E508F27-2CAE-4CA7-A535-7AC7530DC72E@nosignal.org> On 14 Jan 2009, at 16:06, Jeroen Massar wrote: > Simon Lockhart wrote: >> (Yes, I'm in the minority that thinks that Randy hasn't done >> anything bad) > Nah, I agree with Randy's experiment too. People should protect > their networks better and this is clearly showing that there are a > lot of vulnerable places in the core internet structure. The end sometimes justifies the means, and someone in the research community discovering flaws in bgp implementation (software, protocol, or process - at the bgp stack, in my NOC tools, in the community's understanding) before hackers/spammers/fraudsters do, then I count that as a result. Andy From mansaxel at besserwisser.org Thu Jan 15 04:16:54 2009 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Thu, 15 Jan 2009 11:16:54 +0100 Subject: Approach to allocating netblocks In-Reply-To: References: <496E1010.1030702@otd.com> Message-ID: <92DC901FB679F85F2849B0D0@rasmus.kthnoc.net> --On onsdag, onsdag 14 jan 2009 10.30.18 -0600 Frank Bulk wrote: > But perhaps the BCP is to make the customer renumber, in which case I'm > making things more complicated than they need to be. Most customers with PA space (which is what you are giving them) are quite used to renumbering. If not, they will become, given v6 PAishness. Renumbering is not to be avoided at all costs, because: Renumbering cleans cruft and finds mishaps waiting to happen. Renumbering rewards those who have done proper configuration separation. Renumbering rewards those who have automated their systems management. Renumbering thus is good for you. There are economic incentives (keeping the customer because said customer hovers in the Lagrange point between clueless and lazy) to let suboptimal numbering schemes fester. Might alter picture above, but from operational standpoint renumbering is not that bad. -- M?ns Nilsson M A C H I N A Now my EMOTIONAL RESOURCES are heavily committed to 23% of the SMELTING and REFINING industry of the state of NEVADA!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From john at sackheads.org Thu Jan 15 06:45:26 2009 From: john at sackheads.org (John Payne) Date: Thu, 15 Jan 2009 07:45:26 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <3CFE4CF7-ADA0-4C43-93A0-9CA62955DA92@gmail.com> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> <3BE183A5-B1C9-46E8-8A1D-E7ACED72EA8C@sackheads.org> <6316CD198EC8BC44A9D200F375869F1E4A1754@nkc-mailsrv.nkc.org> <3CFE4CF7-ADA0-4C43-93A0-9CA62955DA92@gmail.com> Message-ID: <2ADC6BFF-B16E-496A-B251-69ED1E55B956@sackheads.org> On Jan 14, 2009, at 6:22 PM, kris foster wrote: > > On Jan 14, 2009, at 2:52 PM, Michienne Dixon wrote: > >> Well, if you really want to pick knits you are welcome to. If I >> meant >> prepending, I would have said that. The example that I listed was >> setting up a router, advertising the ASNs listed and the random IP >> ranges gleaned from IANA. Sorry if I confused you. > > The point I believe John is trying to make is that *ASNs are not > announced*. There are no advertisements that say "this is how to get > to ASN X". BGP updates specifically announce network layer > reachability. > > This is an important point in this discussion. There are a lot of > comments being made that are just simply wrong and causing confusion > because of slips in terminology regarding the path attribute. Thanks Kris - exactly what I was getting to. > > > Kris > > >> -----Original Message----- >> From: John Payne [mailto:john at sackheads.org] >> Sent: Wednesday, January 14, 2009 3:57 PM >> To: Michienne Dixon >> Cc: NANOG list >> Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 >> >> >> On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote: >> >>> >>> Interesting - So as a cyber criminal - I could setup a router, start >>> announcing AS 16733, 18872, and maybe 6966 for good measure and >>> their >>> routers would ignore my announcements and IP ranges that I siphoned >>> from searching IANA? Hm... Would that also prevent them from >>> accessing my rogue network from their network? >> >> >> What do you mean "announcing AS 16733..." ? >> >> Putting 16733 in an AS PATH is not announcing it. >> >>> >>> >>> >>> >>> - >>> Michienne Dixon >>> Network Administrator >>> liNKCity >>> 312 Armour Rd. >>> North Kansas City, MO 64116 >>> www.linkcity.org >>> (816) 412-7990 >>> >>> -----Original Message----- >>> From: Simon Lockhart [mailto:simon at slimey.org] >>> Sent: Wednesday, January 14, 2009 2:07 AM >>> To: Hank Nussbacher >>> Cc: NANOG list >>> Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 >>> >>> On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: >>>> What if, by doing some research experiment, the researcher >>>> discovers >>>> some unknown and latent bug in IOS or JunOS that causes much of the >>>> Internet to go belly up? 1 in a billion chance, but nonetheless, a >>>> headsup would have been in order. >>> >>> Say we had a customer who connected to us over BGP, and they used >>> some >> >>> new experimental BGP daemon. Their announcement was "odd" in some >>> way, >> >>> but appeared clean to us (a Cisco house). Once their announcement >>> hit >>> the a Foundry router, it tickled a bug which caused the router to >>> propogate the announcement, but also start to blackhole traffic. Oh >>> dear, large chunks of the Internet have just gone belly up. >>> >>> Should we have given a heads up to the Internet at large that we >>> were >>> turning up this customer? >>> >>> Simon >>> (Yes, I'm in the minority that thinks that Randy hasn't done >>> anything >>> bad) >>> -- >>> >>> Simon Lockhart | * Sun Server Colocation * ADSL * Domain >>> Registration >>> * >>> Director | * Domain & Web Hosting * Internet Consultancy * >>> Bogons Ltd | * http://www.bogons.net/ * Email: >>> info at bogons.net * >>> >>> >> >> > > From jabley at hopcount.ca Thu Jan 15 08:07:03 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 15 Jan 2009 09:07:03 -0500 Subject: Which is more efficient? In-Reply-To: References: Message-ID: On 2009-01-14, at 15:56, Murphy, Jay, DOH wrote: > In your humble opinion, which transmission method is more efficient, > packet or cell? When you say "transmission method" are you just interested in packet/ cell forwarding, or are you also including the effort involved in segmentation and reassembly? And when you say "efficient" are you talking about power consumption, or cost per bit, or payload versus header, or minimising jitter for isochronous applications, or something else? If the question is a pragmatic one (e.g. "which will allow me to get the most sleep, and spend the least money") then perhaps at low speeds, with Nortel's bankruptcy imminent, you could expect to find a lot of cheap ATM gear on the used market that would be the right short- term answer. It'd have to be pretty cheap though. I have met clueful people who have come to this conclusion, astonishing though it seemed to me at the time. At higher speeds, you might find that ATM gear either doesn't exist, or is so ludicrously expensive compared to ethernet switches that it makes you laugh coffee all over your keyboard. Joe From patrick at ianai.net Thu Jan 15 08:44:21 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 15 Jan 2009 09:44:21 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <5E508F27-2CAE-4CA7-A535-7AC7530DC72E@nosignal.org> References: <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><494779.53806.qm@web31810.mail.mud.yahoo.com><45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net><496CDAE5.9060008@eeph.com><802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net><5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> <496E0D96.6070901@spaghetti.zurich.ibm.com> <5E508F27-2CAE-4CA7-A535-7AC7530DC72E@nosignal.org> Message-ID: <96B6ED99-A550-41B7-BF2E-75C60180B31E@ianai.net> On Jan 15, 2009, at 3:54 AM, Andy Davidson wrote: > On 14 Jan 2009, at 16:06, Jeroen Massar wrote: > >> Simon Lockhart wrote: >>> (Yes, I'm in the minority that thinks that Randy hasn't done >>> anything bad) >> Nah, I agree with Randy's experiment too. People should protect >> their networks better and this is clearly showing that there are a >> lot of vulnerable places in the core internet structure. > > The end sometimes justifies the means, and someone in the research > community discovering flaws in bgp implementation (software, > protocol, or process - at the bgp stack, in my NOC tools, in the > community's understanding) before hackers/spammers/fraudsters do, > then I count that as a result. We disagree. The 'researcher' does not get to decide whether the information gained by yelling fire to see how quickly people react is worth the risk of someone getting hurt, or even just missing the rest of the movie. No reputable research institution's ethics committee would allow an "experiment" to proceed which announced a prefix in such a way that every network engineer on the planet would assume the prefix traveled through $ASN even though the prefix had not, and the researcher did not even notify $ASN of the experiment. -- TTFN, patrick From neito at nerdramblingz.com Thu Jan 15 08:54:05 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Thu, 15 Jan 2009 09:54:05 -0500 Subject: Anyone notice strange announcements for 174.128.31.0/24 In-Reply-To: <96B6ED99-A550-41B7-BF2E-75C60180B31E@ianai.net> References: <494779.53806.qm@web31810.mail.mud.yahoo.com> <45AD348E-AA88-49F9-B64E-1A66C8127B26@ianai.net> <496CDAE5.9060008@eeph.com> <802D3B06-BA15-4B27-8D13-85EEABC44C8A@ianai.net> <5.1.0.14.2.20090114095733.058048d8@efes.iucc.ac.il> <20090114080649.GM11420@virtual.bogons.net> <6316CD198EC8BC44A9D200F375869F1E4A1737@nkc-mailsrv.nkc.org> <496E0D96.6070901@spaghetti.zurich.ibm.com> <5E508F27-2CAE-4CA7-A535-7AC7530DC72E@nosignal.org> <96B6ED99-A550-41B7-BF2E-75C60180B31E@ianai.net> Message-ID: Here's a question that's been bugging me the whole thread, and it's a bit of a newbie one. How is this different than someone faking SMTP headers to make it seem like an email came from my domain when it didn't? I'm talking in terms of morals, obviously; I understand the technique is different. On Thu, Jan 15, 2009 at 9:44 AM, Patrick W. Gilmore wrote: > On Jan 15, 2009, at 3:54 AM, Andy Davidson wrote: >> >> On 14 Jan 2009, at 16:06, Jeroen Massar wrote: >> >>> Simon Lockhart wrote: >>>> >>>> (Yes, I'm in the minority that thinks that Randy hasn't done anything >>>> bad) >>> >>> Nah, I agree with Randy's experiment too. People should protect their >>> networks better and this is clearly showing that there are a lot of >>> vulnerable places in the core internet structure. >> >> The end sometimes justifies the means, and someone in the research >> community discovering flaws in bgp implementation (software, protocol, or >> process - at the bgp stack, in my NOC tools, in the community's >> understanding) before hackers/spammers/fraudsters do, then I count that as a >> result. > > We disagree. > > The 'researcher' does not get to decide whether the information gained by > yelling fire to see how quickly people react is worth the risk of someone > getting hurt, or even just missing the rest of the movie. > > No reputable research institution's ethics committee would allow an > "experiment" to proceed which announced a prefix in such a way that every > network engineer on the planet would assume the prefix traveled through $ASN > even though the prefix had not, and the researcher did not even notify $ASN > of the experiment. > > -- > TTFN, > patrick > > > From johns at sstar.com Thu Jan 15 09:15:07 2009 From: johns at sstar.com (John Souvestre) Date: Thu, 15 Jan 2009 09:15:07 -0600 Subject: Radius & Tacacs+ Clients Message-ID: <204419595AAD43409812044BB34287DC@JohnS> Hi all. Does anyone have any recommendations for Radius and Tacacs+ clients (not servers) to run on Linux and Windows? Thanks, John John Souvestre - Integrated Data Systems - (504) 355-0609 From sfischer1967 at gmail.com Thu Jan 15 09:53:32 2009 From: sfischer1967 at gmail.com (Steven Fischer) Date: Thu, 15 Jan 2009 10:53:32 -0500 Subject: Radius & Tacacs+ Clients In-Reply-To: <204419595AAD43409812044BB34287DC@JohnS> References: <204419595AAD43409812044BB34287DC@JohnS> Message-ID: <500ffb690901150753l3cebecf5wa2ce74179d4fcb00@mail.gmail.com> take a look at this for your Linux requirements: http://freeradius.org/pam_radius_auth/ On Thu, Jan 15, 2009 at 10:15 AM, John Souvestre wrote: > Hi all. > > Does anyone have any recommendations for Radius and Tacacs+ clients (not > servers) to run on Linux and Windows? > > Thanks, > > John > > John Souvestre - Integrated Data Systems - (504) 355-0609 > > > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From randy at psg.com Thu Jan 15 09:56:40 2009 From: randy at psg.com (Randy Bush) Date: Fri, 16 Jan 2009 00:56:40 +0900 Subject: Radius & Tacacs+ Clients In-Reply-To: <204419595AAD43409812044BB34287DC@JohnS> References: <204419595AAD43409812044BB34287DC@JohnS> Message-ID: <496F5CB8.7060004@psg.com> > Does anyone have any recommendations for Radius and Tacacs+ clients (not > servers) to run on Linux and Windows? Steven Fischer gave you a good pointer to freeradius for tacacs, look at http://shrubbery.net/tac_plus/ randy From Valdis.Kletnieks at vt.edu Thu Jan 15 12:31:49 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Jan 2009 13:31:49 -0500 Subject: Which is more efficient? In-Reply-To: Your message of "Wed, 14 Jan 2009 13:56:11 MST." References: Message-ID: <23947.1232044309@turing-police.cc.vt.edu> On Wed, 14 Jan 2009 13:56:11 MST, "Murphy, Jay, DOH" said: > In your humble opinion, which transmission method is more efficient, packet > or cell? In my humble opinion, if you care about actual in-the-field efficiency as opposed to theoretical or in-the-lab results, I think you'll find that there is enough statistical spread between "best" and "worst" actual hardware for both packet and cell to swamp the theoretical benefits - there are good packet processors out there that will kick the butt of most cell gear, and there's good cell gear that will outperform some packet gear. And then there's cost issues - if cell is 5% more efficient, but 35% more expensive, is it really a good choice? (Unless of course you *need* that 5% to fit through a non-negotiable bandwidth notch someplace - but then you'll be screwed *anyhow* if your traffic grows 7%). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From herrin-nanog at dirtside.com Thu Jan 15 14:11:48 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 15 Jan 2009 15:11:48 -0500 Subject: Approach to allocating netblocks In-Reply-To: References: Message-ID: <3c3e3fca0901151211p6012de1dy63ba9f99d70174b0@mail.gmail.com> On Wed, Jan 14, 2009 at 11:05 AM, Frank Bulk wrote: > For the first time we have our own ARIN-assigned netblocks that we can now > split out and divide to our customers. > > What's the best approach to handing out /30's, /29's, etc. that is efficient > as possible but allows for customers to expand their allocation to a > neighboring block? Frank, Prioritize the following optimization criteria in order of importance to you: 1. Most efficient use of address space. 2. Maximum routing aggregability. 3. Highest probability of expansion by only changing the netmask Solution to #1: For each new assignment, select the smallest block of available addresses which is large enough to accommodate the new assignment, where a "block" is defined as a network plus netmask, not defined as a range of addresses. Carve the assignment from the end of the block. Downside: expansion by changing the netmask is unlikely since the assignments are all crunched together. Solution to #2: Split your ARIN netblock based on your current and anticipated routing areas. Inside each sub-block, implement your second priority. Downside: Over time this becomes futile as your routing areas move, split and merge. Solution to #3: For each new assignment, select the largest block of available addresses. Split it in half, placing the new assignment in the middle. When the assignee expands, there is a relatively high probability that the adjacent part of the next shorter netmask is still available. This is called "sparse allocation." Downside: This fragments the heck out of your address space. You will typically only be able to assign address blocks whose netmask is more than log2(n) bits longer than the netmask of your ARIN block where n is the total number of assignments you've already made. For example, after assigning 150 /29's from your /20, the largest remaining block would be a /28. Assign 150 more /30's and your largest remaining block would be a /29! With Solution #1, you'd still have an untouched /21. You can do a hybrid of #1 and #3 by doing things like "pick the smallest block that's at least 4 times the size you need, split in half, etc." Or, you might split the ARIN block in half and do #3 for /28 and longer assignments in the first half and #1 for /27 and shorter assignments in the second. Unfortunately, the efficacy of such approaches is unproven. Unless you have a particularly large system (and if this is your first ARIN block, you don't) just go with solution #1 so that you don't run into problems with what will probably be tightening criteria for subsequent IPv4 address assignment. On Thu, Jan 15, 2009 at 5:16 AM, M?ns Nilsson wrote: > from operational standpoint renumbering is not that bad. M?ns, http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt provides 24 pages and growing worth of problems with renumbering. Here's a simple one: Web browsers intentionally violate the DNS TTL with a technique called "DNS Pinning." DNS Pinning limits acceptance of server IP address changes due to a javascript issue where repeated address changes could otherwise be used to induce a browser to scan the inside of a firewalled network and report the results to an outside attacker. This can persist as long as the browser is running, perhaps months at a time. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mansaxel at besserwisser.org Thu Jan 15 14:32:34 2009 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Thu, 15 Jan 2009 21:32:34 +0100 Subject: Approach to allocating netblocks In-Reply-To: <3c3e3fca0901151211p6012de1dy63ba9f99d70174b0@mail.gmail.com> References: <3c3e3fca0901151211p6012de1dy63ba9f99d70174b0@mail.gmail.com> Message-ID: <7DF93C33B6873D00D5E00A46@rasmus.kthnoc.net> --On torsdag, torsdag 15 jan 2009 15.11.48 -0500 William Herrin wrote: > On Thu, Jan 15, 2009 at 5:16 AM, M?ns Nilsson > wrote: >> from operational standpoint renumbering is not that bad. > > M?ns, > > http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.t > xt provides 24 pages and growing worth of problems with renumbering. > > Here's a simple one: > > Web browsers intentionally violate the DNS TTL with a technique called > "DNS Pinning." Given the small netmasks, I'd guess that most of the browser population behind them is addicted to a proxy. The proxy might not subscribe to pinning. Also, the browsers that run for months typically aren't on end-user PCs, but on the workstations of the clued, if I might be so blunt. It is not that renumbering is painless, not at all. But it is very useful as "spring cleaning". I'd rather know what happens by testing it than finding out by being woken up while on call. -- M?ns Nilsson M A C H I N A Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From hugh at open.com.au Thu Jan 15 14:43:45 2009 From: hugh at open.com.au (Hugh Irvine) Date: Fri, 16 Jan 2009 07:43:45 +1100 Subject: Radius & Tacacs+ Clients In-Reply-To: <204419595AAD43409812044BB34287DC@JohnS> References: <204419595AAD43409812044BB34287DC@JohnS> Message-ID: <3F9710DF-E8DC-4B9D-B3A9-557569265AE4@open.com.au> Hello John - Radiator includes both RADIUS and TACACS+ clients (written in Perl). www.open.com.au/radiator regards Hugh On 16 Jan 2009, at 02:15, John Souvestre wrote: > Hi all. > > Does anyone have any recommendations for Radius and Tacacs+ clients > (not > servers) to run on Linux and Windows? > > Thanks, > > John > > John Souvestre - Integrated Data Systems - (504) 355-0609 > > From nonobvious at gmail.com Thu Jan 15 16:03:41 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 15 Jan 2009 14:03:41 -0800 Subject: Which is more efficient? In-Reply-To: References: Message-ID: <18a5e7cb0901151403p135c864erf0396c5a838963f2@mail.gmail.com> On Wed, Jan 14, 2009 at 12:56 PM, Murphy, Jay, DOH wrote: > In your humble opinion, which transmission method is more efficient, packet or cell? ... > Trying to make a decision on the transport mode for cost, delay, jitter, ROI, etcetera. It really depends on what your applications are. I've spent the last decade as the regional ATM specialist (among other things) for an international carrier, and since we can sell you koolaid in ATM, Frame, MPLS, VPLS, IPv4, and IPSEC flavors, I can be fairly neutral about technology recommendations for my customers. The most efficient transmission method is the one for which you know how to set up your router to match the way the carrier's network works, so you'll need to train your people. If that's ATM, you may need to do some ATM-specific things, and they're different for different carriers; if it's Ethernet, you'll need to decide how to handle access line failure detection. And the work you need to do is much different if the ATM/Frame/Ethernet is a Layer 2 end-to-end service or if it's an access line for a routed service such as MPLS. ATM can give you really good control over jitter, but only if you set it up correctly. Dedicated Ethernet access typically has lower jitter than shared switched Ethernet access, but it only comes in a couple of sizes and may cost more if that's bigger than what you need. As far as cost-effectiveness goes, ATM cells have about 10% overhead, but some carriers price their services to charge you for it and some don't, and they have different policies about bursting; what you really care about is what price they're going to charge you for the data circuits you need. Ethernet also has a lot of overhead, if you're carrying lots of small packets; it's very significant if you're carrying VOIP, and trivial on big file transfers. These days circuit costs have decreased enough that router costs can be a significant part of your total cost. ATM cards are traditionally expensive, but if you're buying a VLAN-based switched ethernet access service, ask your router vendor what size router you'll need to handle traffic shaping - even if the Ethernet is built-in, a large teal-colored box costs more than a medium box. My main concerns about ATM, other than whether it matches your applications, are whether it'll scale to the size you need, and how long you'll be able to get good router vendor support. I don't see Frame/ATM interworking going away as a method for handling lots of small endpoints like cash machines reliably, at least until there are good ways to manage thousands of IPSEC sessions, but it's not the technology you're going to want for OC48s. DSL is usually ATM underneath, but that may or may not be how you connect to your DSL carrier. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From akmal_shahbaz at yahoo.com Thu Jan 15 18:39:06 2009 From: akmal_shahbaz at yahoo.com (Akmal Shahbaz) Date: Thu, 15 Jan 2009 16:39:06 -0800 (PST) Subject: What ISP's looking for in a BGP Security Solution? Message-ID: <821794.38321.qm@web56006.mail.re3.yahoo.com> Respected AllI would like to discuss some of the questions related to BGP Security which might be quite helpful in my research.1.What are you using now for BGP Security problems like Prefix hijacking,Path Spoofing,etc?2.What you would be looking for in any BGP Security Solution?3.Are solutions like BGPMon,PHAS,PGBGP are implemented anywhere?4.Are there some new issues related to BGP Security than widely discussed in research/conference/forums?5.Any other points you want to share.Thank You.Akmal Khan From tony at lava.net Thu Jan 15 19:31:58 2009 From: tony at lava.net (Antonio Querubin) Date: Thu, 15 Jan 2009 15:31:58 -1000 (HST) Subject: multicast meltdown? Message-ID: We've detected a large drop in the IPv4 multicast prefix count over the past few days. Anybody know what's going on? Antonio Querubin whois: AQ7-ARIN From frnkblk at iname.com Thu Jan 15 22:27:02 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 15 Jan 2009 22:27:02 -0600 Subject: Approach to allocating netblocks In-Reply-To: <92DC901FB679F85F2849B0D0@rasmus.kthnoc.net> References: <496E1010.1030702@otd.com> <92DC901FB679F85F2849B0D0@rasmus.kthnoc.net> Message-ID: I hesitate to put my customers in "the Lagrange point between clueless and lazy" because they're SMBs doing what 99% of the other SMBs out there do. I have some customers who are in the hub in a multi-site VPN network and renumbering would be very painful. While Renumbering has all the positives you mentioned, it's a sure way to sour the customer relationship. Much cheaper, long-term, to set aside adjacent address space. Frank -----Original Message----- From: M?ns Nilsson [mailto:mansaxel at besserwisser.org] Sent: Thursday, January 15, 2009 4:17 AM To: NANOG list Subject: RE: Approach to allocating netblocks --On onsdag, onsdag 14 jan 2009 10.30.18 -0600 Frank Bulk wrote: > But perhaps the BCP is to make the customer renumber, in which case I'm > making things more complicated than they need to be. Most customers with PA space (which is what you are giving them) are quite used to renumbering. If not, they will become, given v6 PAishness. Renumbering is not to be avoided at all costs, because: Renumbering cleans cruft and finds mishaps waiting to happen. Renumbering rewards those who have done proper configuration separation. Renumbering rewards those who have automated their systems management. Renumbering thus is good for you. There are economic incentives (keeping the customer because said customer hovers in the Lagrange point between clueless and lazy) to let suboptimal numbering schemes fester. Might alter picture above, but from operational standpoint renumbering is not that bad. -- M?ns Nilsson M A C H I N A Now my EMOTIONAL RESOURCES are heavily committed to 23% of the SMELTING and REFINING industry of the state of NEVADA!! From jeff at emailgoeshere.com Thu Jan 15 23:09:11 2009 From: jeff at emailgoeshere.com (Jeff Mitchell) Date: Fri, 16 Jan 2009 00:09:11 -0500 Subject: smtp.comcast.net self-signed certs Message-ID: <49701677.7070207@emailgoeshere.com> I've been seeing some odd behavior today with some of the servers that respond to smtp.comcast.net on port 587. Some, but not all, of the servers are presenting self-signed certs, causing my own server to balk at making a connection. (The Organization is RTFM, Inc. -- it'd be funny if mail wasn't queueing up on my end). Sometimes I get a server with a legit cert, so I can slowly drain my queue by flushing it over and over and over... openssl s_client output below. I can send a libpcap trace on request. --Jeff ??(root at bookcase)(04:48:06) ??(~)-> openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect smtp.comcast.net:587 CONNECTED(00000003) depth=1 /C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=localhost i:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 1 s:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 i:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 --- Server certificate -----BEGIN CERTIFICATE----- MIICGDCCAYECAgEBMA0GCSqGSIb3DQEBBAUAMFcxCzAJBgNVBAYTAlVTMRMwEQYD VQQKEwpSVEZNLCBJbmMuMRkwFwYDVQQLExBXaWRnZXRzIERpdmlzaW9uMRgwFgYD VQQDEw9UZXN0IENBMjAwMTA1MTcwHhcNMDEwNTE3MTYxMDU5WhcNMDQwMzA2MTYx MDU5WjBRMQswCQYDVQQGEwJVUzETMBEGA1UEChMKUlRGTSwgSW5jLjEZMBcGA1UE CxMQV2lkZ2V0cyBEaXZpc2lvbjESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCiWhMjNOPlPLNW4DJFBiL2fFEIkHuRor0pKw25 J0ZYHW93lHQ4yxA6afQr99ayRjMY0D26pH41f0qjDgO4OXskBsaYOFzapSZtQMbT 97OCZ7aHtK8z0ZGNW/cslu+1oOLomgRxJomIFgW1RyUUkQP1n0hemtUdCLOLlO7Q CPqZLQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAIumUwl1OoWuyN2xfoBHYAs+lRLY KmFLoI5+iMcGxWIsksmA+b0FLRAN43wmhPnums8eXgYbDCrKLv2xWcvKDP3mps7m AMivwtu/eFpYz6J8Mo1fsV4Ys08A/uPXkT23jyKo2hMu8mywkqXCXYF2e+7pEeBr dsbmkWK5NgoMl8eM -----END CERTIFICATE----- subject=/C=US/O=RTFM, Inc./OU=Widgets Division/CN=localhost issuer=/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 --- No client certificate CA names sent --- SSL handshake has read 1965 bytes and written 375 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 8B976D67A76BBFEF5E46CA9D079C1C1208D037B8F5825049C45B57C05786A891 Session-ID-ctx: Master-Key: 4DC43D803056BF32082F3E35B2818539E33B7321455AD625D3AD124BAD719C12C5903C9F1889EAB7A5F313B9A54D74A6 Key-Arg : None Start Time: 1232081287 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 250 OK From rjs at eng.gxn.net Fri Jan 16 06:57:19 2009 From: rjs at eng.gxn.net (Rob Shakir) Date: Fri, 16 Jan 2009 12:57:19 +0000 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH Message-ID: <20090116125718.GB26415@bronze.eng.gxn.net> Strict RFC 4893 (4-byte ASN support) BGP4 implementations are vulnerable to a session reset by distant (not directly connected) ASes. This vulnerability is a feature of the standard, and unless immediate action is taken an increasingly significant number of networks will be open to attack. Accidental triggering of this vulnerability has already been seen in the wild, although the limited number of RFC 4893 deployments has limited its effect. Summary: It is possible to cause BGP sessions to remotely reset by injecting invalid data into the AS4_PATH attribute provided to store 4-byte ASN paths. Since AS4_PATH is an optional transitive attribute, the invalid data will be transited through many intermediate ASes which will not examine the content. To be vulnerable, an operator does not have to be actively using 4-byte AS support. This problem was first reported by Andy Davidson on NANOG in December 2008 [0], furthermore we have been able to demonstrate that a device running Cisco IOS release 12.0(32)S12 behaves as per this description. Details: When a prefix is learnt from a BGP neighbour that does not support 4-byte ASNs, the AS4_PATH attribute is retained, and appended to UPDATE messages sent to other neighbours [1, 3]. RFC4893 specifies that AS_CONFED_SEQUENCE and AS_CONFED_SET are invalid in an AS4_PATH, the intention of which is to ensure that an AS with a mix of AS4-aware BGP speakers, and AS4-unaware BGP speakers does not propagate confederation AS paths outside of the confederation [1, 3]. Upon receiving an invalid BGP UPDATE message, a BGP speaker must send a NOTIFICATION message [2, 6.3], after a NOTIFICATION message, the BGP connection is closed [2, 4.5]. Analysis of the Reported Path: On 10th December 2008, a BGP update was propagated with illegal/invalid confederation attributes in the AS4_PATH. When this update was received by AS4 aware BGP speakers, the RFCs described above were interpreted literally and the session was torn down. Because the illegal attributes were learned on a transit session, an affected network can have global reachability impaired. Please note that the analysis of this path describes what we expect to have happened in this case, it has not been confirmed by any of the ASNs involved. 91.207.218.0/23 Path Attributes - Origin: Incomplete Flags: 0x40 (Well-known, Transitive, Complete) Origin: Incomplete (2) AS_PATH: xx xx 35320 23456 (13 bytes) AS4_PATH: (65044 65057) 196629 (7 bytes) In this data, the AS_PATH indicates that a prefix is announced by an AS4 speaker (as indicated by AS23456) and propagated through by AS35320. The AS4_PATH data shows that the AS4 originator is AS196629, the rest of this path is an AS_CONFED_SEQUENCE [3, 5]. It would appear that in this case, AS196629 peers with AS35320, which is AS4-aware on this border. The prefix is then propagated through AS35320, with the AS4 aware routers appending their ASN to the AS_CONFED_SEQUENCE. This is in contravention of RFC 4893 [1, 3]. The border which announces this route to AS35320's upstream does not appear to be AS4-aware. During normal announcements, the BGP speaker on a border with an upstream ASN that is not part of the confederation will remove the left-most AS_CONFED_SETs or AS_CONFED_SEQUENCEs that exist in the AS_PATH [3, 6.1] and replace them with the confederation identifier. However, due to the fact that both AS_CONFED_SET and AS_CONFED_SEQUENCE are invalid in an AS4_PATH, then no such action is taken on the border between an AS4 aware AS, and a non-AS4 aware AS. In addition, since the AS35320 border is not AS4 aware, then it does not update the AS4_PATH. This malformed UPDATE is then sent to AS35320's upstream, if there are no AS4-aware routers in the path between the AS35320 border, and an AS receiving this update, the AS4_PATH will not have been analysed. The first AS4-aware router to receive this update will reset the session towards the neighbour from whom it receives the update. The border which announces this route to AS35320's upstream does not appear to be AS4-aware; If it were a strict AS4 implementation it would reset the BGP session due to the malformed AS4_PATH, and a broken implementation that treats AS4_PATH as an equivalent of the AS_PATH would sanitise the AS4_PATH. This allows the AS4_PATH containing an AS_CONFED_SET to be passed to neighbouring networks. This escape of an AS_CONFED_SET from a network with only partial AS4 support is exactly the situation that RFC 4893 attempts to avoid by forbidding the presence of an AS_CONFED_SET in the AS4_PATH. In the ideal world the neighbouring network receiving an UPDATE containing this obviously malformed AS4_PATH would reset the session, preventing further propagation and isolating the broken network. Unfortunately the vast majority of networks do not support AS4 so pass on this malformed AS4_PATH to their neighbours. The first AS4-aware router to receive this update will reset the session towards the neighbour from whom it received the update. Cisco IOS Behaviour: In a lab environment, a Cisco 7200 running IOS 12.0(32)S12, which is able to support 4-byte ASNs, was peered with a Cisco 2811 running 12.4(19). When the BGP session to the upstream 2811 is established by the 7200, the following log messages are observed: *Jan 16 11:29:58.531: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Up *Jan 16 11:30:02.595: %BGP-6-ASPATH: Invalid AS path (65044 65048 65062) 3.21 23456 received from 193.239.32.2: Confederation found in AS4_PATH *Jan 16 11:30:02.595: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Down BGP Notification sent *Jan 16 11:30:02.595: %BGP-3-NOTIFICATION: sent to neighbor 193.239.32.2 3/1 (update malformed) 27 bytes E0111803 030000FE 140000FE 180000FE 26 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0050 0200 0000 3540 0101 0240 020C 0205 3D25 2114 89F8 5BA0 5BA0 4003 04C1 EF20 02E0 1118 0303 0000 FE14 0000 FE18 0000 FE26 0202 0003 0015 0000 5BA0 175B CFDA The configuration on the 7200 is as follows: router bgp 65123 no synchronization bgp log-neighbor-changes neighbor 193.239.32.2 remote-as 15653 no auto-summary The BGP session will continue to be reset each time the invalid AS4_PATH is received. Possible Impact: During a BGP conversation, it is expected that a neighbour's UPDATE messages are sanitised by the immediate neighbour, during a 'normal' BGP conversation, if a BGP speaker receives an invalid UPDATE, it will teardown the session, and this invalid UPDATE will not propagate any further. In the case of optional transitive attributes such as AS4_PATH, this invalid update can be transited through many ASes, as the content of the invalid attribute in the UPDATE message is not examined. In a hypothetical scenario, an AS4 aware service provider (A) has a transit provider (T) that is not AS4 aware. BGP speaker B, a large distance from A has a bug affecting their equipment that introduces an AS_CONFED_SET in the AS4_PATH. Since B's updates are propagated through to A via T, A will tear down the session to T due to the malformed attribute. This is an out of proportion reaction as the update may affect only one prefix in a full BGP table. If this update is also propagated through A's other transit providers A may lose full-table visibility until one of their transit providers filters the route. Examining the UPDATE message to establish which route caused session teardown may be a non-trivial activity. Conclusion: Whilst this description may be applied to invalid data in any optional transitive element, it has a greater impact with AS4_PATH due to the large number of BGP speakers that currently do not examine any 4-byte ASN data in an UPDATE. There has been a discussion of this matter on the IETF IDR mailing list [4], however, due to availability of Cisco IOS containing AS4 support (12.0(32)S12), and an observation of this problem 'in the wild', we believe that it is of operational concern to those that are planning on deployment of AS4-aware platforms [5]. Any input from the operational community relating to this problem is much appreciated, either publicly, or privately. Regards, Andy Davidson, NetSumo (andy.davidson at netsumo.com), Jonathan Oddy, Hostway UK (jonathan.oddy at hostway.co.uk), Rob Shakir, GX Networks (rjs at eng.gxn.net) References: [0]: Andy Davidson - 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320, http://markmail.org/message/3ofvjyggayfxezna [1]: rfc4893: BGP Support for Four-octet AS Number Space [2]: rfc4271: A Border Gateway Protocol 4 (BGP-4) [3]: rfc3054: Autonomous System Confederations for BGP [4]: Kaliraj Vairavakkalai, Juniper Networks, [Idr] RFC-4893 handling malformed AS4_PATH attributes, http://www.ietf.org/mail-archive/web/idr/current/msg03368.html [5]: http://as4.cluepon.net/index.php/Software_Support Thanks to Will Hargrave (LONAP) for assistance with this document. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available URL: From diogo.montagner at gmail.com Fri Jan 16 07:31:08 2009 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Fri, 16 Jan 2009 11:31:08 -0200 Subject: Radius & Tacacs+ Clients In-Reply-To: <3F9710DF-E8DC-4B9D-B3A9-557569265AE4@open.com.au> References: <204419595AAD43409812044BB34287DC@JohnS> <3F9710DF-E8DC-4B9D-B3A9-557569265AE4@open.com.au> Message-ID: <84eb7a820901160531q5d0e2914o377299870e2ff22e@mail.gmail.com> Also there is the JRadius: http://coova.org/wiki/index.php/JRadius Very easy to run it and also it is developed in Java. But I never tested its scalability in large environments. regards, ./diogo -montagner On Thu, Jan 15, 2009 at 6:43 PM, Hugh Irvine wrote: > > Hello John - > > Radiator includes both RADIUS and TACACS+ clients (written in Perl). > > www.open.com.au/radiator > > regards > > Hugh > > > > On 16 Jan 2009, at 02:15, John Souvestre wrote: > > Hi all. >> >> Does anyone have any recommendations for Radius and Tacacs+ clients (not >> servers) to run on Linux and Windows? >> >> Thanks, >> >> John >> >> John Souvestre - Integrated Data Systems - (504) 355-0609 >> >> >> > > > From fw at deneb.enyo.de Fri Jan 16 09:45:08 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 16 Jan 2009 16:45:08 +0100 Subject: smtp.comcast.net self-signed certs In-Reply-To: <49701677.7070207@emailgoeshere.com> (Jeff Mitchell's message of "Fri, 16 Jan 2009 00:09:11 -0500") References: <49701677.7070207@emailgoeshere.com> Message-ID: <873afjntkr.fsf@mid.deneb.enyo.de> * Jeff Mitchell: > I've been seeing some odd behavior today with some of the servers that > respond to smtp.comcast.net on port 587. Some, but not all, of the > servers are presenting self-signed certs, causing my own server to > balk at making a connection. (The Organization is RTFM, Inc. -- it'd > be funny if mail wasn't queueing up on my end). Sometimes I get a > server with a legit cert, so I can slowly drain my queue by flushing > it over and over and over... There's no PKI for Internet Mail routing, so I don't see what you get by checking certificates at all. From adrian at creative.net.au Fri Jan 16 09:48:48 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 17 Jan 2009 00:48:48 +0900 Subject: smtp.comcast.net self-signed certs In-Reply-To: <873afjntkr.fsf@mid.deneb.enyo.de> References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> Message-ID: <20090116154848.GA20675@skywalker.creative.net.au> On Fri, Jan 16, 2009, Florian Weimer wrote: > There's no PKI for Internet Mail routing, so I don't see what you get > by checking certificates at all. Function, non-broken Outlook integration. Adrian (Who is -fed up- with outlook just randomly spewing crap at you from time to time if you use self-signed certs for various mail related activities. Or chained certs. Sigh. :) From fw at deneb.enyo.de Fri Jan 16 09:52:49 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 16 Jan 2009 16:52:49 +0100 Subject: smtp.comcast.net self-signed certs In-Reply-To: <20090116154848.GA20675@skywalker.creative.net.au> (Adrian Chadd's message of "Sat, 17 Jan 2009 00:48:48 +0900") References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> <20090116154848.GA20675@skywalker.creative.net.au> Message-ID: <87y6xbmeni.fsf@mid.deneb.enyo.de> * Adrian Chadd: > On Fri, Jan 16, 2009, Florian Weimer wrote: > >> There's no PKI for Internet Mail routing, so I don't see what you get >> by checking certificates at all. > > Function, non-broken Outlook integration. Oops, silly me. I assumed that this was about SMTP, it's about message submission (and the OP made that quite clear). Sorry for the noise. From tico-nanog at raapid.net Fri Jan 16 10:10:56 2009 From: tico-nanog at raapid.net (Tico) Date: Fri, 16 Jan 2009 10:10:56 -0600 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <20090116125718.GB26415@bronze.eng.gxn.net> References: <20090116125718.GB26415@bronze.eng.gxn.net> Message-ID: <4970B190.9020300@raapid.net> Comments below. Rob Shakir wrote: > Strict RFC 4893 (4-byte ASN support) BGP4 implementations are vulnerable to a > session reset by distant (not directly connected) ASes. This vulnerability is a > feature of the standard, and unless immediate action is taken an increasingly > significant number of networks will be open to attack. Accidental triggering of > this vulnerability has already been seen in the wild, although the limited > number of RFC 4893 deployments has limited its effect. > > Summary: > It is possible to cause BGP sessions to remotely reset by injecting invalid data > into the AS4_PATH attribute provided to store 4-byte ASN paths. Since AS4_PATH > is an optional transitive attribute, the invalid data will be transited through > many intermediate ASes which will not examine the content. To be vulnerable, an > operator does not have to be actively using 4-byte AS support. This problem was > first reported by Andy Davidson on NANOG in December 2008 [0], furthermore we > have been able to demonstrate that a device running Cisco IOS release > 12.0(32)S12 behaves as per this description. > > Details: > > When a prefix is learnt from a BGP neighbour that does not support 4-byte ASNs, > the AS4_PATH attribute is retained, and appended to UPDATE messages sent to > other neighbours [1, 3]. RFC4893 specifies that AS_CONFED_SEQUENCE and > AS_CONFED_SET are invalid in an AS4_PATH, the intention of which is to ensure > that an AS with a mix of AS4-aware BGP speakers, and AS4-unaware BGP speakers > does not propagate confederation AS paths outside of the confederation [1, 3]. > Upon receiving an invalid BGP UPDATE message, a BGP speaker must send a > NOTIFICATION message [2, 6.3], after a NOTIFICATION message, the BGP connection > is closed [2, 4.5]. > > Analysis of the Reported Path: > > On 10th December 2008, a BGP update was propagated with illegal/invalid > confederation attributes in the AS4_PATH. When this update was received by AS4 > aware BGP speakers, the RFCs described above were interpreted literally and the > session was torn down. Because the illegal attributes were learned on a transit > session, an affected network can have global reachability impaired. > > Please note that the analysis of this path describes what we expect to have > happened in this case, it has not been confirmed by any of the ASNs involved. > > 91.207.218.0/23 > Path Attributes - Origin: Incomplete > Flags: 0x40 (Well-known, Transitive, Complete) > Origin: Incomplete (2) > AS_PATH: xx xx 35320 23456 (13 bytes) > AS4_PATH: (65044 65057) 196629 (7 bytes) > > In this data, the AS_PATH indicates that a prefix is announced by an AS4 speaker > (as indicated by AS23456) and propagated through by AS35320. The AS4_PATH data > shows that the AS4 originator is AS196629, the rest of this path is an > AS_CONFED_SEQUENCE [3, 5]. It would appear that in this case, AS196629 peers > with AS35320, which is AS4-aware on this border. The prefix is then propagated > through AS35320, with the AS4 aware routers appending their ASN to the > AS_CONFED_SEQUENCE. This is in contravention of RFC 4893 [1, 3]. The border > which announces this route to AS35320's upstream does not appear to be > AS4-aware. During normal announcements, the BGP speaker on a border with an > upstream ASN that is not part of the confederation will remove the left-most > AS_CONFED_SETs or AS_CONFED_SEQUENCEs that exist in the AS_PATH [3, 6.1] and > replace them with the confederation identifier. However, due to the fact that > both AS_CONFED_SET and AS_CONFED_SEQUENCE are invalid in an AS4_PATH, then no > such action is taken on the border between an AS4 aware AS, and a non-AS4 aware > AS. In addition, since the AS35320 border is not AS4 aware, then it does not > update the AS4_PATH. > > This malformed UPDATE is then sent to AS35320's upstream, if there are no > AS4-aware routers in the path between the AS35320 border, and an AS receiving > this update, the AS4_PATH will not have been analysed. The first AS4-aware > router to receive this update will reset the session towards the neighbour from > whom it receives the update. > > The border which announces this route to AS35320's upstream does not appear to > be AS4-aware; If it were a strict AS4 implementation it would reset the BGP > session due to the malformed AS4_PATH, and a broken implementation that treats > AS4_PATH as an equivalent of the AS_PATH would sanitise the AS4_PATH. This > allows the AS4_PATH containing an AS_CONFED_SET to be passed to neighbouring > networks. > > This escape of an AS_CONFED_SET from a network with only partial AS4 support is > exactly the situation that RFC 4893 attempts to avoid by forbidding the presence > of an AS_CONFED_SET in the AS4_PATH. In the ideal world the neighbouring network > receiving an UPDATE containing this obviously malformed AS4_PATH would reset the > session, preventing further propagation and isolating the broken network. > > Unfortunately the vast majority of networks do not support AS4 so pass on this > malformed AS4_PATH to their neighbours. The first AS4-aware router to receive > this update will reset the session towards the neighbour from whom it received > the update. > > Cisco IOS Behaviour: > > In a lab environment, a Cisco 7200 running IOS 12.0(32)S12, which is able to > support 4-byte ASNs, was peered with a Cisco 2811 running 12.4(19). When the BGP > session to the upstream 2811 is established by the 7200, the following log > messages are observed: > > *Jan 16 11:29:58.531: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Up > *Jan 16 11:30:02.595: %BGP-6-ASPATH: Invalid AS path (65044 65048 65062) 3.21 23456 received from 193.239.32.2: Confederation found in AS4_PATH > *Jan 16 11:30:02.595: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Down BGP Notification sent > *Jan 16 11:30:02.595: %BGP-3-NOTIFICATION: sent to neighbor 193.239.32.2 3/1 (update malformed) 27 bytes E0111803 030000FE 140000FE 180000FE 26 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0050 0200 0000 3540 0101 0240 020C 0205 3D25 2114 89F8 5BA0 5BA0 4003 04C1 EF20 02E0 1118 0303 0000 FE14 0000 FE18 0000 FE26 0202 0003 0015 0000 5BA0 175B CFDA > > The configuration on the 7200 is as follows: > > router bgp 65123 > no synchronization > bgp log-neighbor-changes > neighbor 193.239.32.2 remote-as 15653 > no auto-summary > > The BGP session will continue to be reset each time the invalid AS4_PATH is > received. > > Possible Impact: > > During a BGP conversation, it is expected that a neighbour's UPDATE messages are > sanitised by the immediate neighbour, during a 'normal' BGP conversation, if a > BGP speaker receives an invalid UPDATE, it will teardown the session, and this > invalid UPDATE will not propagate any further. In the case of optional > transitive attributes such as AS4_PATH, this invalid update can be transited > through many ASes, as the content of the invalid attribute in the UPDATE message > is not examined. > > In a hypothetical scenario, an AS4 aware service provider (A) has a transit > provider (T) that is not AS4 aware. BGP speaker B, a large distance from A has a > bug affecting their equipment that introduces an AS_CONFED_SET in the AS4_PATH. > Since B's updates are propagated through to A via T, A will tear down the > session to T due to the malformed attribute. This is an out of proportion > reaction as the update may affect only one prefix in a full BGP table. If this > update is also propagated through A's other transit providers A may lose > full-table visibility until one of their transit providers filters the route. > Examining the UPDATE message to establish which route caused session teardown > may be a non-trivial activity. > > > Conclusion: > > Whilst this description may be applied to invalid data in any optional > transitive element, it has a greater impact with AS4_PATH due to the large > number of BGP speakers that currently do not examine any 4-byte ASN data in an > UPDATE. There has been a discussion of this matter on the IETF IDR mailing list > [4], however, due to availability of Cisco IOS containing AS4 support > (12.0(32)S12), and an observation of this problem 'in the wild', we believe that > it is of operational concern to those that are planning on deployment of > AS4-aware platforms [5]. > > Any input from the operational community relating to this problem is much > appreciated, either publicly, or privately. > > Regards, > Andy Davidson, NetSumo (andy.davidson at netsumo.com), > Jonathan Oddy, Hostway UK (jonathan.oddy at hostway.co.uk), > Rob Shakir, GX Networks (rjs at eng.gxn.net) > > References: > [0]: Andy Davidson - 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - > announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320, > http://markmail.org/message/3ofvjyggayfxezna > [1]: rfc4893: BGP Support for Four-octet AS Number Space > [2]: rfc4271: A Border Gateway Protocol 4 (BGP-4) > [3]: rfc3054: Autonomous System Confederations for BGP > [4]: Kaliraj Vairavakkalai, Juniper Networks, [Idr] RFC-4893 handling malformed > AS4_PATH attributes, > http://www.ietf.org/mail-archive/web/idr/current/msg03368.html > [5]: http://as4.cluepon.net/index.php/Software_Support > > Thanks to Will Hargrave (LONAP) for assistance with this document. > Rob, I'm sure you (and others) already aware of this, but for the archives' sake, when Andy first brought this up on nanog@ there was a corresponding discussion on the misc at openbsd.org mailing list: http://marc.info/?l=openbsd-misc&w=2&r=1&s=32bit+ASn&q=b And patched (in OpenBGPD) here: http://marc.info/?l=openbsd-misc&m=122894875212174&w=2 though I see it's now in CVS: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c Regards, Tico From dot at dotat.at Fri Jan 16 10:28:42 2009 From: dot at dotat.at (Tony Finch) Date: Fri, 16 Jan 2009 16:28:42 +0000 Subject: smtp.comcast.net self-signed certs In-Reply-To: <873afjntkr.fsf@mid.deneb.enyo.de> References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> Message-ID: On Fri, 16 Jan 2009, Florian Weimer wrote: > > There's no PKI for Internet Mail routing, so I don't see what you get > by checking certificates at all. That's not entirely true. SMTP over TLS is intended to work for inter-domain SMTP, and it is in fact quite frequently used. However it is utterly broken, with the result that what PKI there is is not in practice used. The brokenness is: * TLS certificates verify host names not mail domains, so they only provide protection for the result of an MX lookup - they don't verify the MX lookup itself was not spoofed. * Most SMTP software does not check certificates and many certificates installed on MX hosts have different common names from the MX record target hostname. Turning on certificate verification breaks too much email, and there's no incentive for postmasters to install valid certificates. These problems are extremely hard to fix. Tony. -- f.anthony.n.finch http://dotat.at/ FITZROY SOLE: WEST OR SOUTHWEST 5 TO 7, INCREASING GALE 8 AT TIMES, THEN BACKING SOUTH 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From jeff at emailgoeshere.com Fri Jan 16 10:39:51 2009 From: jeff at emailgoeshere.com (Jeff Mitchell) Date: Fri, 16 Jan 2009 11:39:51 -0500 Subject: smtp.comcast.net self-signed certs In-Reply-To: References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> Message-ID: <4970B857.2090407@emailgoeshere.com> Tony Finch wrote: > That's not entirely true. SMTP over TLS is intended to work for > inter-domain SMTP, and it is in fact quite frequently used. My understanding is that Comcast uses it simply for encryption, not for authentication. > * Most SMTP software does not check certificates and many certificates > installed on MX hosts have different common names from the MX record > target hostname. Turning on certificate verification breaks too much > email, and there's no incentive for postmasters to install valid > certificates. > You're right; certificate verification was turned on on my end simply because I'd never had a reason to turn it off (since in recent times the majority of my mail goes through their gateway, which has never presented an invalid certificate to me before). However, in this case, there is another benefit: the presence of what was clearly a default certificate on some of their servers, where before there were always valid certificates presented, could indicate that the rest of the mailserver was incorrectly configured. Better that mail is delayed than it is accepted and ends up bounced or disappearing into the ether (that was my main incentive for the OP) :-) FWIW, this seems to be fixed today. --Jeff From dot at dotat.at Fri Jan 16 10:54:52 2009 From: dot at dotat.at (Tony Finch) Date: Fri, 16 Jan 2009 16:54:52 +0000 Subject: smtp.comcast.net self-signed certs In-Reply-To: <4970B857.2090407@emailgoeshere.com> References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> <4970B857.2090407@emailgoeshere.com> Message-ID: On Fri, 16 Jan 2009, Jeff Mitchell wrote: > You're right; certificate verification was turned on on my end simply because > I'd never had a reason to turn it off (since in recent times the majority of > my mail goes through their gateway, which has never presented an invalid > certificate to me before). Message submission is very different to inter-domain SMTP. There's no MX indirection, so the TLS certificate actually verifies the correct name, and certificate verification is normal on the client, and correct certificates are normal on servers. A much better situation. Tony. -- f.anthony.n.finch http://dotat.at/ PORTLAND PLYMOUTH: SOUTHWEST 5 TO 7, INCREASING GALE 8 AT TIMES. ROUGH, OCCASIONALLY VERY ROUGH IN PLYMOUTH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From eric at tow.com Fri Jan 16 11:10:04 2009 From: eric at tow.com (Eric Tow) Date: Fri, 16 Jan 2009 12:10:04 -0500 Subject: smtp.comcast.net self-signed certs In-Reply-To: <4970B857.2090407@emailgoeshere.com> References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> <4970B857.2090407@emailgoeshere.com> Message-ID: <4970BF6C.4040509@tow.com> I submitted a ticket to Comcast yesterday around 10:00 AM EST regarding this issue (ticket #151689315), received a standard reply last night, but as of yesterday 14:45 EST, the issue seems to have resolved itself. Here's the certificate I saw: Issued To Common Name (CN) - localhost Organization (O) - RTFM, Inc. Organizational Unit (OU) - Widgets Division Serial Number - 01:01 Issued By Common Name (CN) - Test CA20010517 Organization (O) - RTFM, Inc. Organizational Unit (OU) - Widgets Division Validity Issued On - 5/17/2001 Expires On - 3/6/2004 Fingerprints SHA1 Fingerprint - 15:13:DF:CF:8B:BE:63:2D:91:BC:2E:B3:ED:29:8D:74:06:4D:7D:8A MD5 Fingerprint - 21:91:FB:FE:F3:13:AF:74:53:48:56:B4:EF:7A:13:69 Eric From jeff at emailgoeshere.com Fri Jan 16 11:21:09 2009 From: jeff at emailgoeshere.com (Jeff Mitchell) Date: Fri, 16 Jan 2009 12:21:09 -0500 Subject: smtp.comcast.net self-signed certs In-Reply-To: <4970BF6C.4040509@tow.com> References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> <4970B857.2090407@emailgoeshere.com> <4970BF6C.4040509@tow.com> Message-ID: <4970C205.8040602@emailgoeshere.com> Eric Tow wrote: > I submitted a ticket to Comcast yesterday around 10:00 AM EST regarding > this issue (ticket #151689315), received a standard reply last night, > but as of yesterday 14:45 EST, the issue seems to have resolved itself. I can verify that it was still happening as of about 12:10 AM EST this morning, when I submitted the OP (the output there was grabbed right before I posted). I'm out of the country so calling them up to submit a ticket was not possible. I did get word in a private message that the people in the department responsible say that it is fixed now. Thanks, Jeff From owen at delong.com Fri Jan 16 11:27:48 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Jan 2009 09:27:48 -0800 Subject: smtp.comcast.net self-signed certs In-Reply-To: References: <49701677.7070207@emailgoeshere.com> <873afjntkr.fsf@mid.deneb.enyo.de> <4970B857.2090407@emailgoeshere.com> Message-ID: On Jan 16, 2009, at 8:54 AM, Tony Finch wrote: > On Fri, 16 Jan 2009, Jeff Mitchell wrote: > >> You're right; certificate verification was turned on on my end >> simply because >> I'd never had a reason to turn it off (since in recent times the >> majority of >> my mail goes through their gateway, which has never presented an >> invalid >> certificate to me before). > > Message submission is very different to inter-domain SMTP. There's > no MX > indirection, so the TLS certificate actually verifies the correct > name, > and certificate verification is normal on the client, and correct > certificates are normal on servers. A much better situation. > > Tony. Sure, but, in that case, it's also perfectly valid to load the self- signed root certificate for that SMTP server's cert. chain into the trusted roots set. Owen From cscora at apnic.net Fri Jan 16 12:11:54 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Jan 2009 04:11:54 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200901161811.n0GIBs4d031224@thyme.apnic.net> 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-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 Jan, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 277721 Prefixes after maximum aggregation: 132482 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 135762 Total ASes present in the Internet Routing Table: 30352 Prefixes per ASN: 9.15 Origin-only ASes present in the Internet Routing Table: 26399 Origin ASes announcing only one prefix: 12865 Transit ASes present in the Internet Routing Table: 3953 Transit-only ASes present in the Internet Routing Table: 98 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN (46211) 20 Prefixes from unregistered ASNs in the Routing Table: 523 Unregistered ASNs in the Routing Table: 184 Number of 32-bit ASNs allocated by the RIRs: 73 Prefixes from 32-bit ASNs in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 283 Number of addresses announced to Internet: 1984280064 Equivalent to 118 /8s, 69 /16s and 182 /24s Percentage of available address space announced: 53.5 Percentage of allocated address space announced: 63.3 Percentage of available address space allocated: 84.6 Percentage of address space in use by end-sites: 75.2 Total number of prefixes smaller than registry allocations: 136430 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 64135 Total APNIC prefixes after maximum aggregation: 23147 APNIC Deaggregation factor: 2.77 Prefixes being announced from the APNIC address blocks: 60996 Unique aggregates announced from the APNIC address blocks: 27679 APNIC Region origin ASes present in the Internet Routing Table: 3506 APNIC Prefixes per ASN: 17.40 APNIC Region origin ASes announcing only one prefix: 956 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 395113632 Equivalent to 23 /8s, 140 /16s and 244 /24s Percentage of available APNIC address space announced: 78.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/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: 123561 Total ARIN prefixes after maximum aggregation: 64986 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92979 Unique aggregates announced from the ARIN address blocks: 35380 ARIN Region origin ASes present in the Internet Routing Table: 12731 ARIN Prefixes per ASN: 7.30 ARIN Region origin ASes announcing only one prefix: 4911 ARIN Region transit ASes present in the Internet Routing Table: 1224 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 406799520 Equivalent to 24 /8s, 63 /16s and 68 /24s Percentage of available ARIN address space announced: 78.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 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, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 62265 Total RIPE prefixes after maximum aggregation: 36910 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 57284 Unique aggregates announced from the RIPE address blocks: 38268 RIPE Region origin ASes present in the Internet Routing Table: 12514 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 6573 RIPE Region transit ASes present in the Internet Routing Table: 1913 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 386225504 Equivalent to 23 /8s, 5 /16s and 85 /24s Percentage of available RIPE address space announced: 88.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22923 Total LACNIC prefixes after maximum aggregation: 5659 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 21089 Unique aggregates announced from the LACNIC address blocks: 11650 LACNIC Region origin ASes present in the Internet Routing Table: 1051 LACNIC Prefixes per ASN: 20.07 LACNIC Region origin ASes announcing only one prefix: 337 LACNIC Region transit ASes present in the Internet Routing Table: 174 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 59821824 Equivalent to 3 /8s, 144 /16s and 207 /24s Percentage of available LACNIC address space announced: 59.4 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4336 Total AfriNIC prefixes after maximum aggregation: 1365 AfriNIC Deaggregation factor: 3.18 Prefixes being announced from the AfriNIC address blocks: 5161 Unique aggregates announced from the AfriNIC address blocks: 2190 AfriNIC Region origin ASes present in the Internet Routing Table: 277 AfriNIC Prefixes per ASN: 18.63 AfriNIC Region origin ASes announcing only one prefix: 88 AfriNIC Region transit ASes present in the Internet Routing Table: 59 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13030656 Equivalent to 0 /8s, 198 /16s and 213 /24s Percentage of available AfriNIC address space announced: 25.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1664 6411 376 Korea Telecom (KIX) 17488 1488 105 96 Hathway IP Over Cable Interne 4755 1184 435 166 TATA Communications formerly 9583 1111 87 524 Sify Limited 4134 901 16059 364 CHINANET-BACKBONE 18101 779 174 27 Reliance Infocom Ltd Internet 4780 719 358 65 Digital United Inc. 9498 678 297 52 BHARTI BT INTERNET LTD. 7545 669 152 81 TPG Internet Pty Ltd 24560 660 224 181 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4380 3435 344 bellsouth.net, inc. 209 2835 4031 615 Qwest 20115 2030 1464 746 Charter Communications 1785 1720 734 156 PaeTec Communications, Inc. 4323 1611 1081 380 Time Warner Telecom 2386 1584 714 897 AT&T Data Communications Serv 7018 1425 5869 984 AT&T WorldNet Services 11492 1220 192 12 Cable One 6478 1185 293 488 AT&T Worldnet Services 3356 1115 10997 441 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 864 188 7 TEDATA 3292 440 1765 386 TDC Tele Danmark 12479 390 578 6 Uni2 Autonomous System 30890 387 85 199 SC Kappa Invexim SRL 3301 336 1669 302 TeliaNet Sweden 3320 333 7065 282 Deutsche Telekom AG 8866 332 109 22 Bulgarian Telecommunication C 3215 330 2897 99 France Telecom Transpac 29049 325 26 3 AzerSat LLC. 35805 312 30 8 United Telecom of Georgia Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1480 2833 231 UniNet S.A. de C.V. 10620 697 151 74 TVCABLE BOGOTA 11830 672 299 9 Instituto Costarricense de El 22047 565 302 14 VTR PUNTO NET S.A. 7303 508 253 78 Telecom Argentina Stet-France 6471 434 94 42 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 406 118 72 Servicios Alestra S.A de C.V 28573 369 493 20 NET Servicos de Comunicao S.A 7738 360 730 27 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 593 72 40 LINKdotNET AS number 3741 269 857 227 The Internet Solution 20858 269 34 3 This AS will be used to conne 2018 240 215 141 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 128 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 555 66 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4380 3435 344 bellsouth.net, inc. 209 2835 4031 615 Qwest 20115 2030 1464 746 Charter Communications 1785 1720 734 156 PaeTec Communications, Inc. 4766 1664 6411 376 Korea Telecom (KIX) 4323 1611 1081 380 Time Warner Telecom 2386 1584 714 897 AT&T Data Communications Serv 17488 1488 105 96 Hathway IP Over Cable Interne 8151 1480 2833 231 UniNet S.A. de C.V. 7018 1425 5869 984 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2835 2220 Qwest 1785 1720 1564 PaeTec Communications, Inc. 17488 1488 1392 Hathway IP Over Cable Interne 4766 1664 1288 Korea Telecom (KIX) 20115 2030 1284 Charter Communications 8151 1480 1249 UniNet S.A. de C.V. 4323 1611 1231 Time Warner Telecom 11492 1220 1208 Cable One 18566 1060 1050 Covad Communications 4755 1184 1018 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.208.128.0/18 8346 SONATEL-AS Autonomous System 41.214.0.0/17 8346 SONATEL-AS Autonomous System 41.223.108.0/22 17175 New Skies Satellites 41.223.112.0/22 5713 Telkom SA Ltd 41.223.132.0/24 12491 IPPlanet 41.223.133.0/24 12491 IPPlanet Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:20 /11:54 /12:159 /13:311 /14:561 /15:1108 /16:10298 /17:4523 /18:7805 /19:16749 /20:19686 /21:19269 /22:24472 /23:24862 /24:145716 /25:657 /26:817 /27:512 /28:98 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2859 4380 bellsouth.net, inc. 209 1578 2835 Qwest 4766 1397 1664 Korea Telecom (KIX) 17488 1273 1488 Hathway IP Over Cable Interne 2386 1263 1584 AT&T Data Communications Serv 11492 1185 1220 Cable One 1785 1169 1720 PaeTec Communications, Inc. 20115 1104 2030 Charter Communications 18566 1041 1060 Covad Communications 9583 968 1111 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:174 12:2195 13:2 15:21 16:3 17:5 20:36 24:1136 32:52 38:535 40:96 41:1468 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:516 59:609 60:454 61:1112 62:1115 63:1984 64:3405 65:2429 66:3656 67:1439 68:669 69:2443 70:532 71:198 72:1602 73:7 74:1357 75:198 76:307 77:791 78:532 79:307 80:959 81:845 82:580 83:389 84:598 85:1053 86:397 87:642 88:356 89:1374 90:44 91:1863 92:327 93:1071 94:921 95:187 96:97 97:166 98:179 99:10 110:1 111:1 112:9 113:59 114:156 115:203 116:1120 117:467 118:251 119:605 120:130 121:708 122:924 123:492 124:834 125:1274 128:357 129:226 130:134 131:411 132:70 133:9 134:326 135:35 136:219 137:136 138:145 139:92 140:414 141:109 142:384 143:312 144:325 145:38 146:372 147:143 148:609 149:224 150:134 151:209 152:149 153:132 154:10 155:255 156:168 157:269 158:161 159:279 160:277 161:139 162:261 163:143 164:516 165:505 166:361 167:351 168:674 169:162 170:465 171:37 172:10 173:161 174:28 186:1 187:24 189:359 190:2509 192:5822 193:4189 194:3317 195:2679 196:1062 198:3682 199:3310 200:5473 201:1488 202:7824 203:8095 204:3921 205:2168 206:2331 207:2764 208:3817 209:3490 210:2746 211:1169 212:1556 213:1647 214:67 215:29 216:4535 217:1200 218:374 219:403 220:1226 221:463 222:294 End of report From streiner at cluebyfour.org Fri Jan 16 15:56:42 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 16 Jan 2009 16:56:42 -0500 (EST) Subject: multicast meltdown? In-Reply-To: References: Message-ID: On Thu, 15 Jan 2009, Antonio Querubin wrote: > We've detected a large drop in the IPv4 multicast prefix count over the past > few days. Anybody know what's going on? At this point I haven't seen any problems, nor have customers reported any to me. I did see my multicast prefix count drop from about 8k prefixes to a little over 5k, starting on 8 January. The drop was quite abrupt. jms From warren at kumari.net Fri Jan 16 16:19:43 2009 From: warren at kumari.net (Warren Kumari) Date: Fri, 16 Jan 2009 17:19:43 -0500 Subject: "Smart" hands around Dulles airport / northern VA. Message-ID: Hi all, This is a mail that I have been meaning to send ever since I moved back to the NoVA area, but have only gotten around to now... Many years ago I used to provide emergency, smart hands type assistance to those in need, but had to give this up when I moved out of the area. Anyway, I'm back and am willing to start doing this again.... This is primarily for those cases where you would normally have to fly someone out to have them replace a line-card or two, hook up a few cables, maybe swap a disk in an array, etc. This is not for those cases where you simple need someone to push the reset button, nor for rebuilding your entire cage from scratch... Anyway, if you have gear here and think that you might need to take me up on this, drop me a mail and I'll give you my direct contact info... If you like this idea, and are willing to also provide this sort of thing to the community (either in this, or in another area), please let me know -- I'll look into setting up a website / mailing list / something... Important disclaimers and limitations: 1: I do not want (nor may I accept) any compensation for this, other than good-will and a hope that you might help out someone else in need (AKA, I miss the days when this industry was more co-operative). 2: $day_job comes first. 3: If you are a competitor of $day_job you are probably out of luck. 4: If you wants me to plug in a new device, its your responsibility to make sure that you have sufficient power. 5: If you are a shady spammer, don't bother... FAQ: Q: What! Are you crazy? I'd never let a stranger into my cage! A: Huh, neither would I, but some people are less paranoid than us and / or know and trust me. Q: Why are you doing this again? What's in it for you? A: Back in the day, this industry used to be much more friendly and people would often go out of their way to help others. I fully understand why this has changed over time, but, well, it sucks.. I'd like to try and bring back some of the community feeling. Q: How did you end up so handsome!? A: First off, thank you. It was mainly luck.... Q: I am a small company looking to build a network for my 200 sales people (or something similar). Can I hire you as a consultant? A: Sorry, no. I have a day job that keeps me busy and entertained. I am not a consultant, nor do I have any wish to be one (and can think of few things worse). Oh, and I'm assuming that you meant that you own and / or work at a small company and not that you *are* a small company, because that would be weird. W -- Never criticize a man till you've walked a mile in his shoes. Then if he didn't like what you've said, he's a mile away and barefoot. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4760 bytes Desc: not available URL: From jay at west.net Fri Jan 16 17:11:31 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 16 Jan 2009 15:11:31 -0800 Subject: Circuit numbering scheme - best practice? Message-ID: <49711423.9040004@west.net> We've grown to the point that "The MCI T-1 in Ontario" or "Bob's ethernet to port 6/23 on switch 7" aren't scaling. Also in working with carriers we are frequently asked to provide our internal circuit number. I've seen a lot of the the LEC scheme NN-XXXX-NNNNNN where XXXX has some significance with regard to the speed and type of circuit. The leading NN seems to be a mystery and the trailing NNNNNN is a serial number. I've also seen DS1-NNNNNNN as a straight speed-serial number type of thing and horrendously long circuit numbers including CLLI codes such as 101/T3/SNLOCAGTH07/SNLOCA01K15 . Any suggestions from those who have been down this road as to a schema that makes sense and is scalable? Are there documented best practices? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From r.hyunseog at ieee.org Fri Jan 16 17:32:22 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 16 Jan 2009 17:32:22 -0600 Subject: Circuit numbering scheme - best practice? In-Reply-To: <49711423.9040004@west.net> References: <49711423.9040004@west.net> Message-ID: <49711906.3080203@ieee.org> I think it is really depending on what kind of provisioning system you have. Circuit ID is determined by your provisioning system for CLR/DLR reference. As long as you can find circuit info quickly, it doesn't matter that much. Alex Jay Hennigan wrote: > We've grown to the point that "The MCI T-1 in Ontario" or "Bob's > ethernet to port 6/23 on switch 7" aren't scaling. Also in working > with carriers we are frequently asked to provide our internal circuit > number. > > I've seen a lot of the the LEC scheme NN-XXXX-NNNNNN where XXXX has > some significance with regard to the speed and type of circuit. The > leading NN seems to be a mystery and the trailing NNNNNN is a serial > number. > > I've also seen DS1-NNNNNNN as a straight speed-serial number type of > thing and horrendously long circuit numbers including CLLI codes such > as 101/T3/SNLOCAGTH07/SNLOCA01K15 . > > Any suggestions from those who have been down this road as to a schema > that makes sense and is scalable? Are there documented best practices? > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > > From streiner at cluebyfour.org Fri Jan 16 18:10:28 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 16 Jan 2009 19:10:28 -0500 (EST) Subject: Circuit numbering scheme - best practice? In-Reply-To: <49711423.9040004@west.net> References: <49711423.9040004@west.net> Message-ID: On Fri, 16 Jan 2009, Jay Hennigan wrote: > Any suggestions from those who have been down this road as to a schema that > makes sense and is scalable? Are there documented best practices? Many of the RBOCs (if they can be called that anymore) use the Common Language Circuit Identifier (CLCI) nomenclature for identifying circuits. Many large carriers, especially those that have spent more time buying up competitors then integrating previous acquisitions' provisioning systems, have a mish-mash of different circuit numbering schemes, depending on whose underlying plant and provisioning systems were used to build the circuit in the first place. Like you, I have seen everything from telcos that just use a number and not much else, to telcos that try to tell someone's life story in the form of a circuit ID, to forms that are somewhere in between. I won't say one is better than another, but I do favor shorter ones, if for no other reason than they're easier to key into provisioning systems, interface desciptions and put on wire labels :) I also got into the habit a long time ago of recording every circuit ID for a particular circuit. Many of the circuit I dealt with were long-haul circuits, or were provisioned by a LEC and had to be handed off to an incumbent carrier for final delivery to the customer, and one particular LEC burned me several times by stating, "Oh, I see we hand that off to $TELCO... I don't have a circuit ID for that piece....". Since you have the luxury of starting from scratch, you have the option of creating a system that best fits your needs. If you have or can build a provisioning system that captures all of the information you need, then you can get away with a simpler ID, such as a plain number. The information you want to capture would depend on the type of circuit, but would generally include things like carrier/customer handoff points, router interface/switch ports, VLANs, MPLS labels, patch assignments, etc... It's also a good idea to come up with a standard format for identifying your facilities/rooms/racks if you haven't already. Many providers use Common Language Location Identifier (CLLI) codes for this, which is another telco hold-over, but you can ID them however you want, as long as it makes sense to you and scales as you grow your network. jms From naveen at calpop.com Fri Jan 16 18:14:17 2009 From: naveen at calpop.com (Naveen Nathan) Date: Sat, 17 Jan 2009 00:14:17 +0000 Subject: BGPSEC & soBGP Message-ID: <20090117001417.GC25181@armakuni.lastninja.net> I came across this article on /.: http://www.networkworld.com/news/2009/011509-bgp.html?page=1 I'm not too familiar with security of routing protocols, but it became immediately evident as I read this article that much of the work has been accomplished with soBGP. I'm wondering why there is a new initiative for another technology to secure BGP. -- Naveen Nathan From surfer at mauigateway.com Fri Jan 16 18:32:41 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 16 Jan 2009 16:32:41 -0800 Subject: Circuit numbering scheme - best practice? Message-ID: <20090116163241.A98576CD@resin11.mta.everyone.net> ----- jay at west.net wrote: ------ thing and horrendously long circuit numbers including CLLI codes such as 101/T3/SNLOCAGTH07/SNLOCA01K15. ------------------------------- That is what's used by the transport section (I'm in the IP section) in the company where I work. Even though the description is long, I use the entire CID from the carrier along with something that makes sense to me and the NOC folk that'll be troubleshooting before I get to it. Long in information many times means more work done by the first level folks. Here's a couple of examples: "LAG 29 LINK 1 for CKT ID: 101/GE1/HNLLHIMN37W/HNLLHIMN53W" "101/GE1/HNLLHIMN37W/HNLLHIMN44W to Cisco 3750 7th floor data center" "OC-12 POS line to AT&T: CIDs-> HT: 82.ODGS.xxxxxx.HAWT AT&T: IVEC.xxxxxx..ATI" Long? Yes. Helpful to the first level NOC folks? Yes. scott From pedro at whack.org Fri Jan 16 18:55:44 2009 From: pedro at whack.org (Peter Wohlers) Date: Fri, 16 Jan 2009 16:55:44 -0800 Subject: Circuit numbering scheme - best practice? In-Reply-To: <49711423.9040004@west.net> References: <49711423.9040004@west.net> Message-ID: <49712C90.7070409@whack.org> Jay Hennigan wrote: > We've grown to the point that "The MCI T-1 in Ontario" or "Bob's > ethernet to port 6/23 on switch 7" aren't scaling. Also in working > with carriers we are frequently asked to provide our internal circuit > number. > > I've seen a lot of the the LEC scheme NN-XXXX-NNNNNN where XXXX has > some significance with regard to the speed and type of circuit. The > leading NN seems to be a mystery and the trailing NNNNNN is a serial > number. > > I've also seen DS1-NNNNNNN as a straight speed-serial number type of > thing and horrendously long circuit numbers including CLLI codes such > as 101/T3/SNLOCAGTH07/SNLOCA01K15 . > > Any suggestions from those who have been down this road as to a schema > that makes sense and is scalable? Are there documented best practices? my fave: description "XO#SF/LUXX/500032/TQW Tel#877.792.5550 "; Adding the NOC phone number for carrier in question is immensely useful. I know, long hauls with different LECs complicates things, but guarantees that someone will thank you at some point in time :) --Peter From smb at cs.columbia.edu Fri Jan 16 20:37:55 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 16 Jan 2009 21:37:55 -0500 Subject: BGPSEC & soBGP In-Reply-To: <20090117001417.GC25181@armakuni.lastninja.net> References: <20090117001417.GC25181@armakuni.lastninja.net> Message-ID: <20090116213755.28156a76@bigboy.machshav.com> On Sat, 17 Jan 2009 00:14:17 +0000 Naveen Nathan wrote: > I came across this article on /.: > http://www.networkworld.com/news/2009/011509-bgp.html?page=1 > > I'm not too familiar with security of routing protocols, but it became > immediately evident as I read this article that much of the work has > been accomplished with soBGP. I'm wondering why there is a new > initiative for another technology to secure BGP. > There are two parts to the answer. First, neither SoBGP nor SBGP, the two primary secured BGP proposals, have a consensus behind them. Whether or not either or both do the job in some objective sense, large segments of the community do not perceive that they do, and it's not for lack of trying by the proponents of either. Second, and more serious, both proposals do have major technical issues. SoBGP is very good at protecting origin announcements (and hence at preventing mistakes), but it doesn't work nearly as well against deliberate hijacking. SBGP protects entire path announcements, but is very heavy-weight and requires many signature verifications, probably too many. We need a protocol that solves both of these issues. -- --Steve Bellovin, http://www.cs.columbia.edu/~smb From randy at psg.com Fri Jan 16 20:47:04 2009 From: randy at psg.com (Randy Bush) Date: Sat, 17 Jan 2009 11:47:04 +0900 Subject: "Smart" hands around Dulles airport / northern VA. In-Reply-To: References: Message-ID: <497146A8.2030203@psg.com> warren, way cool and deeply generous of you. i wish i was clueful enough about where colos are and how things work in otemachi to offer to help folk who have kit here. fwiw, the seattle/westin community is very helpful in this way, with the seattle internet exchange lists a good place to beg and to offer. randy From brandon.galbraith at gmail.com Fri Jan 16 23:56:46 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 16 Jan 2009 23:56:46 -0600 Subject: "Smart" hands around Dulles airport / northern VA. In-Reply-To: References: Message-ID: <366100670901162156g5a78633ag9c650513983a47b4@mail.gmail.com> On 1/16/09, Warren Kumari wrote: > > Hi all, > > This is a mail that I have been meaning to send ever since I moved back to > the NoVA area, but have only gotten around to now... > > Many years ago I used to provide emergency, smart hands type assistance to > those in need, but had to give this up when I moved out of the area. Anyway, > I'm back and am willing to start doing this again.... > > This is primarily for those cases where you would normally have to fly > someone out to have them replace a line-card or two, hook up a few cables, > maybe swap a disk in an array, etc. This is not for those cases where you > simple need someone to push the reset button, nor for rebuilding your entire > cage from scratch... > > Anyway, if you have gear here and think that you might need to take me up > on this, drop me a mail and I'll give you my direct contact info... > > If you like this idea, and are willing to also provide this sort of thing > to the community (either in this, or in another area), please let me know -- > I'll look into setting up a website / mailing list / something... > What Warren said. I'm in the Chicagoland area. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From up at 3.am Sat Jan 17 07:28:31 2009 From: up at 3.am (up at 3.am) Date: Sat, 17 Jan 2009 08:28:31 -0500 (EST) Subject: Level 3 Philly "Major outage"? Message-ID: I have a cabinet at Broadwing's (now Level 3) Norristown data center, for over 2 years now. It has always seemed something of a backwater in terms of Broadwing's network, and even more so with Level 3. An outage started yesterday morning, reportedly caused by a broadcast storm on their Philly Big Iron switch that connects to Norristown (this happened before last August). In a couple of hours, they had it fixed, only for it to go into up-and-down mode a couple of hours later, for the rest of the day. I escalated the ticket at around 6:20pm, but saw no lasting improvment. This morning, I started getting customer calls that it was down again. I called Level 3 once more, after seeing the same "Analysis in Progress" message on their portal from the previous evening. The rep described that a "major outage" was happening in Philly, even though there's nothing on their "Network Outages" list about it. I would think that if this was a "Major Outage" in Philadelphia for Level 3, there would be some NANOG chatter on it, which I don't see. It's back up for now, but does anybody have any knowledge of this? As an aside, would it be ok for me to solicit colocation services in the Philadelphia area on this list? A change has to be made at some point. Thanks, James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From jam at zoidtechnologies.com Sat Jan 17 09:04:47 2009 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Sat, 17 Jan 2009 10:04:47 -0500 Subject: Circuit numbering scheme - best practice? In-Reply-To: <49712C90.7070409@whack.org> References: <49711423.9040004@west.net> <49712C90.7070409@whack.org> Message-ID: <200901171004.47170.jam@zoidtechnologies.com> On Friday 16 January 2009 19:55:44 Peter Wohlers wrote: > my fave: description "XO#SF/LUXX/500032/TQW Tel#877.792.5550 "; > Adding the NOC phone number for carrier in question is immensely useful. > I know, long hauls with different LECs complicates things, but > guarantees that someone will thank you at some point in time :) > > --Peter What I would do is populate a database with carrier circuit ids and contact information and then make some tools that ops can use to query for things like the carrier phone number, rather than putting all of it into the circuit id. Regards, Jeff From hcb at netcases.net Sat Jan 17 09:25:30 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sat, 17 Jan 2009 10:25:30 -0500 (EST) Subject: What might have been a lightning talk on anycast had I gotten to a meeting Message-ID: <1142.76.118.12.107.1232205930.squirrel@webmail3.pair.com> Economies and underemployment being what they are, I won't be getting to the in-person meeting, but it occurred to me that a brief tutorial on some of the operational applications of anycast might be a lightning tutorial. I wrote such a short article at http://en.citizendium.org/wiki/Anycasting. Citizendium, as some of you may know, is a open-content wiki that operates on a real-names model with hopefully helpful expert review. I'm starting to take some of my past NANOG presentations and turn them into articles or sets of related articles, obviously updating them. Since NANOG doesn't have a publication mechanism for its presentations, or even summaries of long mailing list threads written for someone who had not been following them, it might be useful as a means of education. I'd welcome anyone who would like to participate; it's still an early project. Given, for example, the various trade press pieces on BGP security and vulnerability expert, I may try, unless someone already has a tutorial they might like to be adapted, they'd like to write, or co-write, to do something at a little more detailed level than Network World, but lighter than an RFC. I have assorted BGP articles there, still at an introductory level, and was starting something on routing policy. From jim.h.willis at gmail.com Sat Jan 17 09:37:30 2009 From: jim.h.willis at gmail.com (Jim Willis) Date: Sun, 18 Jan 2009 08:37:30 +1700 Subject: "Smart" hands around Dulles airport / northern VA. In-Reply-To: <366100670901162156g5a78633ag9c650513983a47b4@mail.gmail.com> References: <366100670901162156g5a78633ag9c650513983a47b4@mail.gmail.com> Message-ID: <2edfe3130901170737l773f5119gaa590ed600049efe@mail.gmail.com> "FAQ: Q: What! Are you crazy? I'd never let a stranger into my cage! A: Huh, neither would I, but some people are less paranoid than us and / or know and trust me." I wouldn't allow my wife in my cage let alone a stranger and I hope my colo would deny you both as well!!! I suppose this may be useful for some as there have been two responses to your initial posting however, we use locked cabinets and cages for a reason. I can appreciate wanting to return the trust and community to the industry even though the outlook looks bleak on your behalf. Cheers, Jim On Sat, Jan 17, 2009 at 10:56 PM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > On 1/16/09, Warren Kumari wrote: > > > > Hi all, > > > > This is a mail that I have been meaning to send ever since I moved back > to > > the NoVA area, but have only gotten around to now... > > > > Many years ago I used to provide emergency, smart hands type assistance > to > > those in need, but had to give this up when I moved out of the area. > Anyway, > > I'm back and am willing to start doing this again.... > > > > This is primarily for those cases where you would normally have to fly > > someone out to have them replace a line-card or two, hook up a few > cables, > > maybe swap a disk in an array, etc. This is not for those cases where you > > simple need someone to push the reset button, nor for rebuilding your > entire > > cage from scratch... > > > > Anyway, if you have gear here and think that you might need to take me up > > on this, drop me a mail and I'll give you my direct contact info... > > > > If you like this idea, and are willing to also provide this sort of thing > > to the community (either in this, or in another area), please let me know > -- > > I'll look into setting up a website / mailing list / something... > > > > What Warren said. I'm in the Chicagoland area. > > -brandon > > -- > Brandon Galbraith > Voice: 630.400.6992 > Email: brandon.galbraith at gmail.com > From laird at pando.com Sat Jan 17 10:01:40 2009 From: laird at pando.com (Laird Popkin) Date: Sat, 17 Jan 2009 11:01:40 -0500 (EST) Subject: "Smart" hands around Dulles airport / northern VA. In-Reply-To: <2edfe3130901170737l773f5119gaa590ed600049efe@mail.gmail.com> Message-ID: <1014318005.251771232208100701.JavaMail.root@dkny.pando.com> Given the existence of water guns, you shouldn't allow anyone else into the entire CoLo. :-) - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Jim Willis" To: "Brandon Galbraith" Cc: nanog at nanog.org Sent: Saturday, January 17, 2009 10:37:30 AM (GMT-0500) America/New_York Subject: Re: "Smart" hands around Dulles airport / northern VA. "FAQ: Q: What! Are you crazy? I'd never let a stranger into my cage! A: Huh, neither would I, but some people are less paranoid than us and / or know and trust me." I wouldn't allow my wife in my cage let alone a stranger and I hope my colo would deny you both as well!!! I suppose this may be useful for some as there have been two responses to your initial posting however, we use locked cabinets and cages for a reason. I can appreciate wanting to return the trust and community to the industry even though the outlook looks bleak on your behalf. Cheers, Jim On Sat, Jan 17, 2009 at 10:56 PM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > On 1/16/09, Warren Kumari wrote: > > > > Hi all, > > > > This is a mail that I have been meaning to send ever since I moved back > to > > the NoVA area, but have only gotten around to now... > > > > Many years ago I used to provide emergency, smart hands type assistance > to > > those in need, but had to give this up when I moved out of the area. > Anyway, > > I'm back and am willing to start doing this again.... > > > > This is primarily for those cases where you would normally have to fly > > someone out to have them replace a line-card or two, hook up a few > cables, > > maybe swap a disk in an array, etc. This is not for those cases where you > > simple need someone to push the reset button, nor for rebuilding your > entire > > cage from scratch... > > > > Anyway, if you have gear here and think that you might need to take me up > > on this, drop me a mail and I'll give you my direct contact info... > > > > If you like this idea, and are willing to also provide this sort of thing > > to the community (either in this, or in another area), please let me know > -- > > I'll look into setting up a website / mailing list / something... > > > > What Warren said. I'm in the Chicagoland area. > > -brandon > > -- > Brandon Galbraith > Voice: 630.400.6992 > Email: brandon.galbraith at gmail.com > From JShao at dtcc.com Sat Jan 17 11:45:46 2009 From: JShao at dtcc.com (Jay Shao) Date: Sat, 17 Jan 2009 12:45:46 -0500 Subject: Jay Shao is out of the office. Message-ID: I will be out of the office starting 01/17/2009 and will not return until 02/09/2009. I will respond to your message when I return. Please contact with NETTCP at DTCC.COM for any production issues ----------------------------------------- ________________________________________________________ DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From warren at kumari.net Sat Jan 17 12:41:17 2009 From: warren at kumari.net (Warren Kumari) Date: Sat, 17 Jan 2009 13:41:17 -0500 Subject: "Smart" hands around Dulles airport / northern VA. In-Reply-To: <2edfe3130901170737l773f5119gaa590ed600049efe@mail.gmail.com> References: <366100670901162156g5a78633ag9c650513983a47b4@mail.gmail.com> <2edfe3130901170737l773f5119gaa590ed600049efe@mail.gmail.com> Message-ID: <6A0840DD-E6C5-48E8-8D27-1564146A9DE8@kumari.net> On Jan 17, 2009, at 10:37 AM, Jim Willis wrote: > "FAQ: > Q: What! Are you crazy? I'd never let a stranger into my cage! > A: Huh, neither would I, but some people are less paranoid than us > and / or know and trust me." > > I wouldn't allow my wife in my cage let alone a stranger and I > hope my colo would deny you both as well!!! Yup, I would hope that your colo would deny us (and everyone else as well) -- unless you call in a ticket and say something like "Please give Bob access to my cage / cabinet on Thursday at around noonish..." As for the stranger bit -- we all have different levels of trust / paranoia. I personally rank towards the top of the paranoia scale, but if I had a widget in Wyoming that needed wiring and one of the people that I know personally from the list happened to be around there, I'd probably trust them more than the colo provided folks. This all depends upon what the widget it, what needs doing and who the person is -- there are some people that I wouldn't let near my gear with a 50ft pole and some people that I trust to some (small) extent. There are some folks that are much more trusting (or possibly more desperate) than us though. Last time I made this offer I got (amongst other requests) a call in the middle of the night some someone I'd never met (nor heard of) asking me to please go over and console into a router as they had managed to push an ACL and lock themselves out -- he cheerfully volunteered his locally configured account info and seemed surprised when I suggested that that, now that it was exposed, he immediately change it everywhere... The type of gear that I have in the cage also plays into this as well -- if the only gear in the cage is networking gear I'd be more comfortable that if there are servers and such. Yes, it is possible that someone could insert a tap or connect to my management network (or a whole host of other nefarious things), but a: this is something that they could do anyway if they were determined enough (if you trust your colo provider to provide perfect physical security than you are 1: stupid and 2: less paranoid than me) and b: I'd have an easier time auditing network gear than servers. > I suppose this may be useful for some as there have been two > responses to your initial posting however, we use locked cabinets > and cages for a reason. I can appreciate wanting to return the trust > and community to the industry even though the outlook looks bleak on > your behalf. Just for information, I have received 8 off-list responses from people thanking me and volunteering their time, ranging from NoVa to Chicago to TX to the Bay Area -- sometime I'll set up a list or website where people can list where they can help out. Once again, this is purely an offer that people can take advantage of if they want -- I am not forming some secret cabal of trained ninjas that will break into people cabinets and swap linecards while no one is watching, nor am I trying to coerce anyone into doing something that they are not comfortable with. It's your network, if you need an XFP swapped and would like me to do so, great. If you don't, great. W > > > Cheers, > Jim > > On Sat, Jan 17, 2009 at 10:56 PM, Brandon Galbraith > wrote: > On 1/16/09, Warren Kumari wrote: > > > > Hi all, > > > > This is a mail that I have been meaning to send ever since I moved > back to > > the NoVA area, but have only gotten around to now... > > > > Many years ago I used to provide emergency, smart hands type > assistance to > > those in need, but had to give this up when I moved out of the > area. Anyway, > > I'm back and am willing to start doing this again.... > > > > This is primarily for those cases where you would normally have to > fly > > someone out to have them replace a line-card or two, hook up a few > cables, > > maybe swap a disk in an array, etc. This is not for those cases > where you > > simple need someone to push the reset button, nor for rebuilding > your entire > > cage from scratch... > > > > Anyway, if you have gear here and think that you might need to > take me up > > on this, drop me a mail and I'll give you my direct contact info... > > > > If you like this idea, and are willing to also provide this sort > of thing > > to the community (either in this, or in another area), please let > me know -- > > I'll look into setting up a website / mailing list / something... > > > > What Warren said. I'm in the Chicagoland area. > > -brandon > > -- > Brandon Galbraith > Voice: 630.400.6992 > Email: brandon.galbraith at gmail.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2173 bytes Desc: not available URL: From hrlinneweh at sbcglobal.net Sat Jan 17 12:47:25 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Sat, 17 Jan 2009 10:47:25 -0800 (PST) Subject: 2 services have disappeared Message-ID: <734770.96585.qm@web82903.mail.mud.yahoo.com> http://www.networkthinktank.com/ http://www.completewhois.com are there any replacement services for these vanished services? -henry From michele at blacknight.ie Sat Jan 17 12:52:26 2009 From: michele at blacknight.ie (Mr Michele Neylon :: Blacknight) Date: Sat, 17 Jan 2009 18:52:26 +0000 Subject: 2 services have disappeared In-Reply-To: <734770.96585.qm@web82903.mail.mud.yahoo.com> References: <734770.96585.qm@web82903.mail.mud.yahoo.com> Message-ID: <38D1A163-5DCE-46CA-BC7B-1CFA2F05ED00@blacknight.ie> On 17 Jan 2009, at 18:47, Henry Linneweh wrote: > http://www.networkthinktank.com/ No idea what that was, so I can't help > > http://www.completewhois.com http://who.is - maybe? > > > are there any replacement services for these vanished services? > > -henry Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.ie/ http://blog.blacknight.ie/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From tim at yocum.org Sat Jan 17 13:18:23 2009 From: tim at yocum.org (Tim Yocum) Date: Sat, 17 Jan 2009 13:18:23 -0600 Subject: "Smart" hands around Dulles airport / northern VA. In-Reply-To: <6A0840DD-E6C5-48E8-8D27-1564146A9DE8@kumari.net> References: <366100670901162156g5a78633ag9c650513983a47b4@mail.gmail.com> <2edfe3130901170737l773f5119gaa590ed600049efe@mail.gmail.com> <6A0840DD-E6C5-48E8-8D27-1564146A9DE8@kumari.net> Message-ID: <14b99b330901171118l5320a69h753af90b58f427d6@mail.gmail.com> On Sat, Jan 17, 2009 at 12:41 PM, Warren Kumari wrote: > Just for information, I have received 8 off-list responses from people > thanking me and volunteering their time, ranging from NoVa to Chicago to TX > to the Bay Area -- sometime I'll set up a list or website where people can > list where they can help out. This would be an excellent use of the NANOG wiki: http://nanog.cluepon.net/ I've created a page linked off of the "Tools and Resources" section and added myself as the first volun^H^Hvictim, setting up a foundation on which others can expand and improve: http://nanog.cluepon.net/index.php/Hands Those who wish to make their time available to others may wish to add themselves and expand upon the details given on that page to increase the value of the resource. For what it's worth, I've leaned on NANOG and I-A participants in the past for remote hands and have returned the favor; it's refreshing to see the spirit continue. Thanks! - Tim From rjoffe at centergate.com Sat Jan 17 15:49:30 2009 From: rjoffe at centergate.com (Rodney Joffe) Date: Sat, 17 Jan 2009 14:49:30 -0700 Subject: 2 services have disappeared In-Reply-To: <734770.96585.qm@web82903.mail.mud.yahoo.com> References: <734770.96585.qm@web82903.mail.mud.yahoo.com> Message-ID: <6B4DD574-52E2-40B5-88F0-37FEF496959C@centergate.com> On Jan 17, 2009, at 11:47 AM, Henry Linneweh wrote: > http://www.completewhois.com I've had http://www.geektools.com/whois.php for about 10 years. Also available on port 43. These days it is a little hobbled because of abusers, but if you're known to us we can unhobble it. From jlewis at packetnexus.com Sat Jan 17 17:25:32 2009 From: jlewis at packetnexus.com (Jason Lewis) Date: Sat, 17 Jan 2009 18:25:32 -0500 Subject: 2 services have disappeared In-Reply-To: <734770.96585.qm@web82903.mail.mud.yahoo.com> References: <734770.96585.qm@web82903.mail.mud.yahoo.com> Message-ID: <497268EC.2090507@packetnexus.com> Networkthinktank is a hobby of mine, I swiched web hosts and haven't put the site back up. Was there something specific you were looking for on the site? jas Henry Linneweh wrote: > http://www.networkthinktank.com/ > http://www.completewhois.com > > are there any replacement services for these vanished services? > > -henry > > From frnkblk at iname.com Sat Jan 17 18:02:07 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 17 Jan 2009 18:02:07 -0600 Subject: 2 services have disappeared In-Reply-To: <734770.96585.qm@web82903.mail.mud.yahoo.com> References: <734770.96585.qm@web82903.mail.mud.yahoo.com> Message-ID: Geektools is my favorite, but other ones I use are: http://www.securityspace.com/swhois/whois.html http://www.whois365.com/en/ http://www.all-nettools.com/toolbox/smart-whois.php Frank -----Original Message----- From: Henry Linneweh [mailto:hrlinneweh at sbcglobal.net] Sent: Saturday, January 17, 2009 12:47 PM To: nanog at merit.edu Subject: 2 services have disappeared http://www.networkthinktank.com/ http://www.completewhois.com are there any replacement services for these vanished services? -henry From ilopezlists at sandboxitsolutions.com Sat Jan 17 19:05:39 2009 From: ilopezlists at sandboxitsolutions.com (Israel Lopez) Date: Sat, 17 Jan 2009 17:05:39 -0800 Subject: WISP Lists - Networking in Honduras Message-ID: <49728063.2010503@sandboxitsolutions.com> Hello NANOG & LACNOG, Can point me towards an active WISP mailing list? I have a few questions about conducting site surveys for wireless infrastructure in Honduras. I'm mostly concerned about; the use of 802.11A/B/G & 900MHz equipment, RF interference, radio placement and Local Regulations,. I can take my answers off list. Thank You Kindly, Israel Lopez (EWB-OC Olancho Aid Technical Lead ) From joshpotter at gmail.com Sun Jan 18 15:31:25 2009 From: joshpotter at gmail.com (Josh Potter) Date: Sun, 18 Jan 2009 15:31:25 -0600 Subject: Circuit numbering scheme - best practice? In-Reply-To: <49712C90.7070409@whack.org> References: <49711423.9040004@west.net> <49712C90.7070409@whack.org> Message-ID: <4a64e2f70901181331t1216e50p14dba6dbf5f26fa4@mail.gmail.com> The number idea is nifty until you have to change your number... On Fri, Jan 16, 2009 at 6:55 PM, Peter Wohlers wrote: > Jay Hennigan wrote: > >> We've grown to the point that "The MCI T-1 in Ontario" or "Bob's ethernet >> to port 6/23 on switch 7" aren't scaling. Also in working with carriers we >> are frequently asked to provide our internal circuit number. >> >> I've seen a lot of the the LEC scheme NN-XXXX-NNNNNN where XXXX has some >> significance with regard to the speed and type of circuit. The leading NN >> seems to be a mystery and the trailing NNNNNN is a serial number. >> >> I've also seen DS1-NNNNNNN as a straight speed-serial number type of thing >> and horrendously long circuit numbers including CLLI codes such as >> 101/T3/SNLOCAGTH07/SNLOCA01K15 . >> >> Any suggestions from those who have been down this road as to a schema >> that makes sense and is scalable? Are there documented best practices? >> > my fave: description "XO#SF/LUXX/500032/TQW Tel#877.792.5550 "; > Adding the NOC phone number for carrier in question is immensely useful. I > know, long hauls with different LECs complicates things, but guarantees that > someone will thank you at some point in time :) > > --Peter > > -- Josh Potter From lorell at hathcock.org Sun Jan 18 18:37:19 2009 From: lorell at hathcock.org (lorell at hathcock.org) Date: Sun, 18 Jan 2009 18:37:19 -0600 Subject: Cisco ASA / Comcast SMTP problem workaround Message-ID: <20090118183719.2f681ijb40gkckgk@216.165.194.136> I have the problem when working out of my house that Comcast will lock down outbound SMTP on the regular ports. This may be due to the kids' computer getting infected with a virus from time to time. That is its own problem and I want to deal with it on its own. The problem I want to discuss is a workaround to Comcast blocking outbound SMTP. I have noticed at my house when I have problems with regular SMTP traffic on port 25 to my own colo servers, that my Yahoo! premium email goes through fine without problem. I have a premium Yahoo! account and use SMTP on port 465 and POP3 on 995 with SSL configured on both. The thought occurred to me that I could solve my immediate problem as well as let me send/receive email at hotels and wifi hotspots that all block regular SMTP traffic on port 25. And roll out an encrypted new service to my hosted customers. I run my own small hosting company at a colo for a handful of customer domains and several that I own. I have a Cisco ASA 5505 (security plus license) and a pair of mail servers needed for in- and out-bound SMTP. The servers are on private IP addresses behind the ASA which has static statements for the servers inside. Also, I have additional IPs available if needed for this solution. Here is my question: How do I configure my ASA (and Outlook) to: 1. Encrypt traffic between Outlook and the ASA on non-traditional SMTP and POP3 ports without using a VPN? (Using SSL just as Yahoo! does it.) 2. Leave my servers' configuration alone so that they continue to send/receive email in exactly the same way they are doing now? Summarized: How do I duplicate Yahoo! premium email service using PAT on my Cisco ASA without changing any settings on my server? Qualifiers: 1. I don't want to change the email server configurations because it is run by a control panel software and if I take it out of spec, the next update could wipe out my custom config. 2. I don't want to use a VPN client on my laptop because it takes up VPN licenses on the ASA and because a successful solution would be a boon to my customers. I believe the ASA would have to do these things: 1. Accept SSL connections on the outside interface. 2. Accept the inbound SMTP request on an arbitrary, but non-dynamic port and translate it to port 25 and send it on to the server. 3. Accept the response from the server and translate it back into the arbitrary port (from #2 above) on the remote client. 4. Do the same thing as above except for POP3. This configuration would allow customers to also configure their SMTP/POP3 clients to allow them access to email without configuring a VPN client for each one. Stated simply, I want to duplicate what Yahoo! premium email is doing between their servers and their customers like me. Any thoughts? Lorell Hathcock From ops.lists at gmail.com Sun Jan 18 18:40:52 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 19 Jan 2009 06:10:52 +0530 Subject: Cisco ASA / Comcast SMTP problem workaround In-Reply-To: <20090118183719.2f681ijb40gkckgk@216.165.194.136> References: <20090118183719.2f681ijb40gkckgk@216.165.194.136> Message-ID: On Mon, Jan 19, 2009 at 6:07 AM, wrote: > I have the problem when working out of my house that Comcast will lock down > outbound SMTP on the regular ports. This may be due to the kids' computer > getting infected with a virus from time to time. That is its own problem > and I want to deal with it on its own. > > The problem I want to discuss is a workaround to Comcast blocking outbound > SMTP. That's what port 587 is for and comcast hasnt been locking that down, eh? Have your server listen on the smtp submission port (587) as well - if you want you can use 465/smtp+ssl but that's deprecated to a large extent (though yes, I had to switch it on after I figured out my phone's push email service seven.com only supports smtps currently) > 1. I don't want to change the email server configurations because it is > run by a control panel software and if I take it out of spec, the next > update could wipe out my custom config. If that's cpanel there are ways to do it in the config + save it. An update wont wipe it out if you use the cpanel management console rather than edit files using vi. In fact, chances are, your cpanel box ALREADY listens on 587. For more details - and these are best practices from MAAWG, which is sort of like a nanog for mailops and antispam - very operational and relevant content there. http://www.maawg.org/port25 Oh, and RFC2476 (about port 587) and 2554 have been around for ages now. --srs From lorell at hathcock.org Sun Jan 18 19:06:40 2009 From: lorell at hathcock.org (lorell at hathcock.org) Date: Sun, 18 Jan 2009 19:06:40 -0600 Subject: Cisco ASA / Comcast SMTP problem workaround In-Reply-To: References: <20090118183719.2f681ijb40gkckgk@216.165.194.136> Message-ID: <20090118190640.hrlb046fk8kcwgsk@216.165.194.136> The Control Panel is H-Sphere. Quoting Suresh Ramasubramanian : > On Mon, Jan 19, 2009 at 6:07 AM, wrote: >> I have the problem when working out of my house that Comcast will lock down >> outbound SMTP on the regular ports. This may be due to the kids' computer >> getting infected with a virus from time to time. That is its own problem >> and I want to deal with it on its own. >> >> The problem I want to discuss is a workaround to Comcast blocking outbound >> SMTP. > > That's what port 587 is for and comcast hasnt been locking that down, eh? > > Have your server listen on the smtp submission port (587) as well - if > you want you can use 465/smtp+ssl but that's deprecated to a large > extent (though yes, I had to switch it on after I figured out my > phone's push email service seven.com only supports smtps currently) > >> 1. I don't want to change the email server configurations because it is >> run by a control panel software and if I take it out of spec, the next >> update could wipe out my custom config. > > If that's cpanel there are ways to do it in the config + save it. An > update wont wipe it out if you use the cpanel management console > rather than edit files using vi. In fact, chances are, your cpanel > box ALREADY listens on 587. > > For more details - and these are best practices from MAAWG, which is > sort of like a nanog for mailops and antispam - very operational and > relevant content there. http://www.maawg.org/port25 > > Oh, and RFC2476 (about port 587) and 2554 have been around for ages now. > > --srs > From ops.lists at gmail.com Sun Jan 18 19:08:58 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 19 Jan 2009 06:38:58 +0530 Subject: Cisco ASA / Comcast SMTP problem workaround In-Reply-To: <20090118190640.hrlb046fk8kcwgsk@216.165.194.136> References: <20090118183719.2f681ijb40gkckgk@216.165.194.136> <20090118190640.hrlb046fk8kcwgsk@216.165.194.136> Message-ID: Yeah, and that's supposed to support port 587 by default too - like most other webhosting control panel software used on pizzabox installs by lowcost webhosts around the world. Did you try something like, say, telnet localhost 587 and see? --srs On Mon, Jan 19, 2009 at 6:36 AM, wrote: > The Control Panel is H-Sphere. > >> If that's cpanel there are ways to do it in the config + save it. An >> update wont wipe it out if you use the cpanel management console >> rather than edit files using vi. In fact, chances are, your cpanel >> box ALREADY listens on 587. From jonathan.oddy at hostway.co.uk Mon Jan 19 04:41:46 2009 From: jonathan.oddy at hostway.co.uk (Jonathan Oddy) Date: Mon, 19 Jan 2009 10:41:46 +0000 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <4970B190.9020300@raapid.net> References: <20090116125718.GB26415@bronze.eng.gxn.net> <4970B190.9020300@raapid.net> Message-ID: <497458EA.2090809@hostway.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was indeed aware of the OpenBGPD discussion and patch, and I'm glad it has been worked around in what I believe to be a sensible way, however I disagree with the comment in the code that states that the standard does not specify how to handle this situation. I believe that RFC 4271* and 4893** currently require a teardown of the session in this case and indeed the person who committed the fix to OpenBGPD seems to agree in their commit message (although still kept the code comment.) This really needs to lead to more debate on the correct way to handle this situation and an updated standard, before implementers decide to fix this in their own different ways. The discussion on the IETF IDR mailing list[1] was promising, but looks to have died off before reaching a conclusion. There was mention of stripping the AS_CONFED_SET/SEQUENCE from the AS4_PATH, however several people pointed out this approach is not without issues. Dropping the UPDATE entirely is also discussed, but can lead to loops. Personally I favour treating receipt of an UPDATE with a malformed attribute as a withdrawal, although this was only briefly mentioned and its implications were never discussed in any detail... The reason for us publishing this report was to alert people to the fact that this problem is definitely in the wild, there are broken AS4_PATHs being announced, and, critically, Cisco's IOS releases to support RFC4893 are vulnerable to having their sessions reset as a result of their standards compliant implementation. At present our advice has to be that upgrading to an IOS version with RFC4893 support is extremely dangerous, and should be avoided at all costs (where this leaves Cisco shops who have been given 32 bit AS numbers by their RIR is somewhat unpleasant to consider.) It must be emphasized that this is due to no fault on Cisco's part, but rather a feature of the standard that must be corrected as soon as possible. [1] http://www.ietf.org/mail-archive/web/idr/current/msg03368.html * From RFC4271: Section 6: ~ "When any of the conditions described here are detected, a ~ NOTIFICATION message, with the indicated Error Code, Error Subcode, ~ and Data fields, is sent, and the BGP connection is closed (unless it ~ is explicitly stated that no NOTIFICATION message is to be sent and ~ the BGP connection is not to be closed). If no Error Subcode is ~ specified, then a zero MUST be used." Section 6.3: ~ "If an optional attribute is recognized, then the value of this ~ attribute MUST be checked. If an error is detected, the attribute ~ MUST be discarded, and the Error Subcode MUST be set to Optional ~ Attribute Error. The Data field MUST contain the attribute (type, ~ length, and value)." ** From RFC4893: Section 3: ~ "To prevent the possible propagation of confederation path segments ~ outside of a confederation, the path segment types AS_CONFED_SEQUENCE ~ and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH ~ attribute." - -- Jonathan Oddy Hostway UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdFjqWGqmTqbbikoRAmNuAJoCPqNUTYOW9lFUQXFfLAFgA/bIcQCeODVz Wo1MjYgtdDw1SmWhmHdzcWM= =AGvq -----END PGP SIGNATURE----- From jbates at brightok.net Mon Jan 19 07:41:26 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 19 Jan 2009 07:41:26 -0600 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <497458EA.2090809@hostway.co.uk> References: <20090116125718.GB26415@bronze.eng.gxn.net> <4970B190.9020300@raapid.net> <497458EA.2090809@hostway.co.uk> Message-ID: <49748306.8000304@brightok.net> Jonathan Oddy wrote: > dangerous, and should be avoided at all costs (where this leaves Cisco > shops who have been given 32 bit AS numbers by their RIR is somewhat > unpleasant to consider.) It must be emphasized that this is due to no Suddenly makes one wonder if it would have been easier to take back any ASN's which weren't justified versus butchering the protocol. Jack From s.ganschow at buelow-masiak.de Mon Jan 19 07:45:12 2009 From: s.ganschow at buelow-masiak.de (Sebastian Ganschow) Date: Mon, 19 Jan 2009 14:45:12 +0100 Subject: spam decrease since friday Message-ID: Hi nanog, we're seeing that we're getting about 2/3 fewer spam since friday. Even blacklist hits are declining. Does anyone has an explanation? Regards Sebastian From ops.lists at gmail.com Mon Jan 19 07:54:40 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 19 Jan 2009 19:24:40 +0530 Subject: spam decrease since friday In-Reply-To: References: Message-ID: One of your secondary MXs went down? I dont see any lower levels. But some bots hit a backup MX first. On Mon, Jan 19, 2009 at 7:15 PM, Sebastian Ganschow wrote: > Hi nanog, > > we're seeing that we're getting about 2/3 fewer spam since friday. > > Even blacklist hits are declining. > > Does anyone has an explanation? > > Regards > Sebastian > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From rsk at gsp.org Mon Jan 19 08:27:16 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 19 Jan 2009 09:27:16 -0500 Subject: spam decrease since friday In-Reply-To: References: Message-ID: <20090119142716.GA9994@gsp.org> On Mon, Jan 19, 2009 at 02:45:12PM +0100, Sebastian Ganschow wrote: > we're seeing that we're getting about 2/3 fewer spam since friday. (a) This is probably better on the mailop list, subscribe via mailop-request at mailop.org. (b) No discernable trend at any of my listening posts over the past week. ---Rsk From jonathan.oddy at hostway.co.uk Mon Jan 19 09:58:17 2009 From: jonathan.oddy at hostway.co.uk (Jonathan Oddy) Date: Mon, 19 Jan 2009 15:58:17 +0000 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <20090116125718.GB26415@bronze.eng.gxn.net> References: <20090116125718.GB26415@bronze.eng.gxn.net> Message-ID: <4974A319.60302@hostway.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After some lab work we have established that the source of the invalid AS4_PATHs discussed in [1] is likely a non compliant implementation of RFC4893 (AS4) in some versions of Juniper JunOS. We have observed the following behaviour with both JunOS 9.3R1.7 and 9.1R2.10, and suspect it may be present in all other JunOS versions since they introduced AS4 support in 9.1R1. Unfortunately we have limited resources so have not been able to test with other versions. When a mix of pre and post 9.1R1 JunOS devices are deployed within a network utilising confederations the AS4_PATH (if present) is used by the AS4 supporting devices to hold an AS_CONFED_SET/SEQUENCE. This behaviour is explicitly forbidden by RFC4893 [3]. If the egress router from the AS utilising confederations is not AS4-aware the confederation information is never removed from the AS4_PATH, and is passed onto the neighbouring networks with the repercussions discussed in [1]. As mentioned in both [1] and [2] this is especially critical as at present Cisco IOS will tear down sessions when receiving an AS4_PATH containing an AS_CONFED_SET/SEQUENCE. Lab setup: AS1.0 - obgp1 (OpenBGPD) AS64512 { ~ AS65001 - juniper1 (JunOS 9.1 or 9.3) (32 bit ASN support) ~ AS65002 - juniper2 (JunOS 8.4) (no 32 bit ASN support) } AS64513 - obgp2 (OpenBGPD) Where AS1.0 is an AS with a 32bit AS number, AS64512 is a Juniper network using confederations and with mixed AS4 support, and AS64513 is another network (doesn't matter what it supports.) On announcing a prefix from obgp1 we observe the following in the UPDATE from juniper1 to juniper2: AS_PATH: (65001) 23456 AS4_PATH: (65001) 65536 And at obgp2: AS_PATH: 64512 23456 AS4_PATH: (65001) 65536 This shows juniper1, which is AS4-aware, adding an AS_CONFED_SET to both the AS_PATH and AS4_PATH before announcing the prefix to juniper2. As juniper2 is not AS4-aware it does not strip the AS_CONFED_SET from the AS4_PATH before announcing it to obgp2, resulting in an invalid AS4_PATH attribute in the UPDATE to obgp2. Conclusions: ~ * If you use JunOS and make use of confederations you should ensure that your entire network either supports AS4 (9.1R1 or later) or doesn't (pre 9.1.) ~ * While the Juniper implementation is clearly non-compliant with the standard, and should be corrected, the number of versions in which this bug is probably present means that these versions will never be completely eliminated from use. ~ * The flaw in the standard can still be misused maliciously. We do not see that going forward it will be possible to completely eliminate the possibility of an AS_CONFED_SET appearing in an AS4_PATH. We believe that this problem requires a consistent response from the vendors, and that to facilitate such a response the standard must be revised. Even if vendors do implement their own workarounds the standard needs to be revised to ensure that future implementers don't fall into this trap. Regards, ~ Andy Davidson, NetSumo (andy.davidson at netsumo.com), ~ Jonathan Oddy, Hostway UK (jonathan.oddy at hostway.co.uk), ~ Rob Shakir, GX Networks (rjs at eng.gxn.net) [1] http://www.merit.edu/mail.archives/nanog/msg14345.html [2] http://www.merit.edu/mail.archives/nanog/msg14388.html [3] From RFC4893 section 3: ~ "To prevent the possible propagation of confederation path segments ~ outside of a confederation, the path segment types AS_CONFED_SEQUENCE ~ and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH ~ attribute." Thanks to Dan Goscomb (Goscomb Tech) for loan of a J2320 for the lab. Thanks to Will Hargrave (LONAP) for assistance with this document. - -- Jonathan Oddy Hostway UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdKMZWGqmTqbbikoRAuDFAJ9WTlvAE/5KogtgShiBmXJo238kHQCfdSjG s3p8pIfX7JmPKC84/yxE67w= =53KL -----END PGP SIGNATURE----- From simon at darkmere.gen.nz Mon Jan 19 14:52:34 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Tue, 20 Jan 2009 09:52:34 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From rjs at eng.gxn.net Tue Jan 20 04:35:48 2009 From: rjs at eng.gxn.net (Rob Shakir) Date: Tue, 20 Jan 2009 10:35:48 +0000 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <4974A319.60302@hostway.co.uk> References: <20090116125718.GB26415@bronze.eng.gxn.net> <4974A319.60302@hostway.co.uk> Message-ID: <20090120103548.GD20730@bronze.eng.gxn.net> On Mon, Jan 19, 2009 at 03:58:17PM +0000, Jonathan Oddy wrote: > As mentioned in both [1] and [2] this is especially critical as at > present Cisco IOS will tear down sessions when receiving an AS4_PATH > containing an AS_CONFED_SET/SEQUENCE. Hi, Whilst this is behaviour is RFC compliant, as previously described, it is sub-optimal operationally. I have raised this issue with Cisco TAC, and CSCsx10140 has been opened to track this problem. I would encourage those network operators who may be planning to deploy AS4-support and use Cisco equipment to open a SR with Cisco, tracking this bug, to try to ensure that both the IOS behaviour, and RFC are changed. Many thanks, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From swmike at swm.pp.se Tue Jan 20 06:01:03 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 20 Jan 2009 13:01:03 +0100 (CET) Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <4970B190.9020300@raapid.net> References: <20090116125718.GB26415@bronze.eng.gxn.net> <4970B190.9020300@raapid.net> Message-ID: > have been able to demonstrate that a device running Cisco IOS release > 12.0(32)S12 behaves as per this description. Has anyone looked into IOS XR behaviour, if it's the same as 12.0(32)S12? -- Mikael Abrahamsson email: swmike at swm.pp.se From rjs at eng.gxn.net Tue Jan 20 08:33:14 2009 From: rjs at eng.gxn.net (Rob Shakir) Date: Tue, 20 Jan 2009 14:33:14 +0000 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: References: <20090116125718.GB26415@bronze.eng.gxn.net> <4970B190.9020300@raapid.net> Message-ID: <20090120143314.GA6679@bronze.eng.gxn.net> On Tue, Jan 20, 2009 at 01:01:03PM +0100, Mikael Abrahamsson wrote: >> have been able to demonstrate that a device running Cisco IOS release >> 12.0(32)S12 behaves as per this description. > > Has anyone looked into IOS XR behaviour, if it's the same as 12.0(32)S12? Mikael, Pierfrancesco Caci was kind enough to provide me with some output from an XR box. It appears that IOS XR behaves in the same manner as Force10, and JunOS, whereby the session is not torn down, and the path is installed, albeit with a munged AS_PATH. The output below is for the prefix from 196629 which we originally analysed: Path #1: Received by speaker 0 3356 35320 3.21 23456 Given that XR box is an AS4-speaker, one would not expect to see 23456 in the AS_PATH, the prescence of this AS seems to be a symptom of the bug (and again occurs on Juniper/Force10). Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From jay at west.net Tue Jan 20 11:20:40 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 20 Jan 2009 09:20:40 -0800 Subject: Inauguration streaming traffic Message-ID: <497607E8.9070107@west.net> We're a regional ISP, about 80% SMB 20% residential. We're seeing almost double our normal downstream traffic right now. Anyone else? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From web at typo.org Tue Jan 20 11:22:24 2009 From: web at typo.org (Wayne E. Bouchard) Date: Tue, 20 Jan 2009 10:22:24 -0700 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: <20090120172224.GA39920@typo.org> Yes, pretty well everyone else. :-) On Tue, Jan 20, 2009 at 09:20:40AM -0800, Jay Hennigan wrote: > We're a regional ISP, about 80% SMB 20% residential. We're seeing > almost double our normal downstream traffic right now. Anyone else? > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From mike at sentex.net Tue Jan 20 11:23:35 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue, 20 Jan 2009 12:23:35 -0500 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: <200901201723.n0KHNQsK003090@lava.sentex.ca> At 12:20 PM 1/20/2009, Jay Hennigan wrote: >We're a regional ISP, about 80% SMB 20% residential. We're seeing >almost double our normal downstream traffic right now. Anyone else? Yes, close to double normal traffic here in south-west Ontario, Canada. ---Mike From doon.bulk at inoc.net Tue Jan 20 11:24:33 2009 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Tue, 20 Jan 2009 12:24:33 -0500 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: On Jan 20, 2009, at 12:20 PM, Jay Hennigan wrote: > We're a regional ISP, about 80% SMB 20% residential. We're seeing > almost double our normal downstream traffic right now. Anyone else? We are seeing about 150% increase in traffic as well. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C I'm sorry a pentium won't do, you need an SGI to connect with us. From dave at mvn.net Tue Jan 20 11:33:33 2009 From: dave at mvn.net (David E. Smith) Date: Tue, 20 Jan 2009 11:33:33 -0600 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: <49760AED.7030508@mvn.net> Jay Hennigan wrote: > We're a regional ISP, about 80% SMB 20% residential. We're seeing > almost double our normal downstream traffic right now. Anyone else? Ditto. I'm suddenly glad we paid for that "burstable" option :) David Smith MVN.net From brian at meganet.net Tue Jan 20 11:26:18 2009 From: brian at meganet.net (Brian Wallingford) Date: Tue, 20 Jan 2009 12:26:18 -0500 (EST) Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: On Tue, 20 Jan 2009, Jay Hennigan wrote: :We're a regional ISP, about 80% SMB 20% residential. We're seeing :almost double our normal downstream traffic right now. Anyone else? We're seeing traffic levels nearly 2x normal. On 9/11/01, we were probably only about 50% higher than the norm. Of course, lots has changed, so that's probably not a fair comparison. From hhoffman at ip-solutions.net Tue Jan 20 11:36:59 2009 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 20 Jan 2009 12:36:59 -0500 Subject: Inauguration streaming traffic In-Reply-To: References: <497607E8.9070107@west.net> Message-ID: <1232473019.17642.2.camel@localhost.localdomain> Yep, most seems to be port 8247. Which seems to be CNN streaming service. And yay for the p2p options now in flash... nothing like that to make it look like a comp'd system/attack. --Harry On Tue, 2009-01-20 at 12:24 -0500, Patrick Muldoon wrote: > On Jan 20, 2009, at 12:20 PM, Jay Hennigan wrote: > > > We're a regional ISP, about 80% SMB 20% residential. We're seeing > > almost double our normal downstream traffic right now. Anyone else? > > > We are seeing about 150% increase in traffic as well. > > -Patrick > > -- > Patrick Muldoon > Network/Software Engineer > INOC (http://www.inoc.net) > PGPKEY (http://www.inoc.net/~doon) > Key ID: 0x370D752C > > I'm sorry a pentium won't do, you need an SGI to connect with us. > > From morrowc.lists at gmail.com Tue Jan 20 11:38:11 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Jan 2009 12:38:11 -0500 Subject: Inauguration streaming traffic In-Reply-To: References: <497607E8.9070107@west.net> Message-ID: <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> On Tue, Jan 20, 2009 at 12:26 PM, Brian Wallingford wrote: > On Tue, 20 Jan 2009, Jay Hennigan wrote: > > :We're a regional ISP, about 80% SMB 20% residential. We're seeing > :almost double our normal downstream traffic right now. Anyone else? > > We're seeing traffic levels nearly 2x normal. On 9/11/01, we were > probably only about 50% higher than the norm. Of course, lots has > changed, so that's probably not a fair comparison. As an aside... thanks to BBC for streaming this, I couldn't find another source that wasn't overloaded/jerky/ugly :( Thanks Brandon. -Chris From ren.provo at gmail.com Tue Jan 20 11:50:06 2009 From: ren.provo at gmail.com (Ren Provo) Date: Tue, 20 Jan 2009 12:50:06 -0500 Subject: Inauguration streaming traffic In-Reply-To: <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> References: <497607E8.9070107@west.net> <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> Message-ID: <787581440901200950i7747f028m7391a3e1e4b4397c@mail.gmail.com> BitGravity did a great job. On Tue, Jan 20, 2009 at 12:38 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > As an aside... thanks to BBC for streaming this, I couldn't find > another source that wasn't overloaded/jerky/ugly :( > > Thanks Brandon. > > -Chris > > From hardenrm at uiuc.edu Tue Jan 20 11:54:28 2009 From: hardenrm at uiuc.edu (Ryan Harden) Date: Tue, 20 Jan 2009 11:54:28 -0600 Subject: Inauguration streaming traffic In-Reply-To: <1232473019.17642.2.camel@localhost.localdomain> References: <497607E8.9070107@west.net> <1232473019.17642.2.camel@localhost.localdomain> Message-ID: <49760FD4.7050808@uiuc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We're seeing more TCP1935 than UDP8247. http://ct-mail.cites.uiuc.edu/~hardenrm/graphs/Peakflow-1.png /Ryan Harry Hoffman wrote: > Yep, most seems to be port 8247. Which seems to be CNN streaming > service. > > And yay for the p2p options now in flash... nothing like that to make it > look like a comp'd system/attack. > > --Harry > > > On Tue, 2009-01-20 at 12:24 -0500, Patrick Muldoon wrote: >> On Jan 20, 2009, at 12:20 PM, Jay Hennigan wrote: >> >>> We're a regional ISP, about 80% SMB 20% residential. We're seeing >>> almost double our normal downstream traffic right now. Anyone else? >> >> We are seeing about 150% increase in traffic as well. >> >> -Patrick >> >> -- >> Patrick Muldoon >> Network/Software Engineer >> INOC (http://www.inoc.net) >> PGPKEY (http://www.inoc.net/~doon) >> Key ID: 0x370D752C >> >> I'm sorry a pentium won't do, you need an SGI to connect with us. >> >> > - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkl2D9IACgkQtuPckBBbXbrcdwCgoI8sF0fNPK3J983bgRL7h9OI Cy0An3WuZB9sd5ncIrKSeqGOKy+PiOnO =apAL -----END PGP SIGNATURE----- From eric at atlantech.net Tue Jan 20 12:06:04 2009 From: eric at atlantech.net (Eric Van Tol) Date: Tue, 20 Jan 2009 13:06:04 -0500 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B863514034D0C@exchange.aoihq.local> > -----Original Message----- > From: Jay Hennigan [mailto:jay at west.net] > Sent: Tuesday, January 20, 2009 12:21 PM > To: nanog at nanog.org > Subject: Inauguration streaming traffic > > We're a regional ISP, about 80% SMB 20% residential. We're seeing > almost double our normal downstream traffic right now. Anyone else? > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV Peering sessions to Limelight tripled in downstream today. No problems, just a lot of traffic. Total aggregate into our network nearly doubled, but we service a lot of SMB and government agencies in the DC area, most of which had today off or telecommuted. -evt From aaron.millisor at bright.net Tue Jan 20 12:21:32 2009 From: aaron.millisor at bright.net (Aaron Millisor) Date: Tue, 20 Jan 2009 13:21:32 -0500 Subject: Single carrier multi-circuit asynchronous routing issue In-Reply-To: <914FFB80-2AFA-4D0C-AFE1-4F4B5A09FCFD@dnz.se> References: <49650835.8090308@bright.net> <20090107200556.GJ56621@burnout.tpb.net> <914FFB80-2AFA-4D0C-AFE1-4F4B5A09FCFD@dnz.se> Message-ID: <4976162C.30309@bright.net> Thank you both. Strict mode uRPF was indeed the problem. Took awhile for them to fix it for me, but at least it's fixed. -- am Anders Lindb?ck wrote: > On 7 jan 2009, at 21.05, Niels Bakker wrote: > >> * aaron.millisor at bright.net (Aaron Millisor) [Wed 07 Jan 2009, 20:53 >> CET]: >> [..] >>> If I were to prepend the network 1.1.1.0 to come in on 'sprint 1', >>> but have a route to 2.2.2.0 via 'sprint 2' so that traffic comes in >>> on one circuit but returns on the other, routing is broken. If I >>> change my route so that packets directed to 2.2.2.0 return on the >>> same circuit that the traffic is received on, everything works fine. >> >> You might be running into uRPF (unicast reverse path forward >> verification). >> >> >> -- Niels. >> > > Strict-mode uRPF will couse this, I am sure sprint support can help you > with it.. > > ------------------------------ > Anders Lindb?ck > anders.lindback at dnz.se > > From esavage at digitalrage.org Tue Jan 20 12:22:25 2009 From: esavage at digitalrage.org (Elijah Savage) Date: Tue, 20 Jan 2009 13:22:25 -0500 (EST) Subject: Inauguration streaming traffic In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863514034D0C@exchange.aoihq.local> Message-ID: <29753924.441232475745456.JavaMail.root@mail> > > > > We're a regional ISP, about 80% SMB 20% residential. We're seeing > > almost double our normal downstream traffic right now. Anyone > else? > > > > -- > > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > > Impulse Internet Service - http://www.impulse.net/ > > Your local telephone and internet company - 805 884-6323 - WB6RDV > > Peering sessions to Limelight tripled in downstream today. No > problems, just a lot of traffic. Total aggregate into our network > nearly doubled, but we service a lot of SMB and government agencies in > the DC area, most of which had today off or telecommuted. > > -evt Port 1935 to LimeLight is what we saw as well. All is back to normal at this point. From jeff-kell at utc.edu Tue Jan 20 12:23:33 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 20 Jan 2009 13:23:33 -0500 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: <497616A5.9020803@utc.edu> Jay Hennigan wrote: > We're a regional ISP, about 80% SMB 20% residential. We're seeing > almost double our normal downstream traffic right now. Anyone else? Yes, tres beaucoups. Mostly udp/8247 for the streaming (CNN). But oddly enough, for a given client, more outbound traffic than inbound. Streaming gone peer-to-peer? Jeff From surfer at mauigateway.com Tue Jan 20 12:27:57 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 20 Jan 2009 10:27:57 -0800 Subject: Inauguration streaming traffic Message-ID: <20090120102757.A970C4E3@resin18.mta.everyone.net> ------- jay at west.net wrote: ------- From: Jay Hennigan We're a regional ISP, about 80% SMB 20% residential. We're seeing almost double our normal downstream traffic right now. Anyone else? ------------------------------------ Not much of a traffic boost here in Hawaii as it happened at 7am local time. Most folks caught the first part on TV and rushed to work, evidently. scott From azambuja at gmail.com Tue Jan 20 12:34:48 2009 From: azambuja at gmail.com (Marcello Azambuja) Date: Tue, 20 Jan 2009 16:34:48 -0200 Subject: Inauguration streaming traffic In-Reply-To: <497616A5.9020803@utc.edu> References: <497607E8.9070107@west.net> <497616A5.9020803@utc.edu> Message-ID: <7321d3a00901201034k29eae94i41993761c595c161@mail.gmail.com> On Tue, Jan 20, 2009 at 4:23 PM, Jeff Kell wrote: > > Mostly udp/8247 for the streaming (CNN). But oddly enough, for a given > client, more outbound traffic than inbound. Streaming gone peer-to-peer? > > Jeff CNN is using Octoshape's P2P plug-in with Flash. Marcello Azambuja From ddunkin at netos.net Tue Jan 20 12:35:12 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 20 Jan 2009 10:35:12 -0800 Subject: Level3 NOC Contact Message-ID: <56F5BC5F404CF84896C447397A1AAF20BE8EA0@MAIL.nosi.netos.com> Their support has been really giving me the run-around and is cluelessly sending me from department to department. Does anyone have a good NOC contact for them? I have one of their downstream customers hijacking some of my IP space and they don't really care as I am not a direct customer of theirs. From aoxomoxoa at sunlightdata.com Tue Jan 20 13:24:49 2009 From: aoxomoxoa at sunlightdata.com (Fred Heutte) Date: Tue, 20 Jan 2009 11:24:49 -0800 Subject: inauguration streams review Message-ID: <200901201924.n0KJOsLr032637@stark.hevanet.com> Normally I wouldn't do this but given that it's of-the-moment... fh ------------------------- http://www.salon.com/tech/giga_om/online_video/2009/01/20/a_quick_review_of_obamas_inauguration_streams/ Tuesday, January 20, 2009 08:02 PST A Quick Review of Obama?s Inauguration Streams By Chris Albrecht You may have heard, but Barack Obama gets to ditch the ?-elect? part of his title today as he will be sworn in (shortly) as our new President. We?ve already provided an comprehensive list of where to watch the inauguration online, but here?s a quick review of what to expect from some of them, so far. C-Span?s coverage is not very impressive. The video window was small, and choppy. Avoid. CBS is offering 7 HD streams of the event, and they look awesome. Definitely the best of the lot ? worth watching. MSNBC, FOX (which is providing Hulu?s feed) and ABC News?s video is solid, nothing too flashy. They all work just fine (and I love that MSNBC allows embeds). Visit msnbc.com for Breaking News, World News, and News about the Economy I had problems with CNN. It was the only network that asked me to install an update to Flash as well as another plug-in. I skipped the second plug-in and it worked fine. The video?s in widescreen, which is nice, and the Facebook integration gives you a running commentary. The Presidential Inauguration Committee?s stream is pretty dull, offering just imagery and no commentary. If our internal stats are any indication, this is going to be a huge day for live-streaming, and it looks like for the most part, every network involved is holding up and the Internet won?t crash (of course, we still have an hour to go). From mike.lyon at gmail.com Tue Jan 20 13:28:43 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 20 Jan 2009 11:28:43 -0800 Subject: inauguration streams review In-Reply-To: <200901201924.n0KJOsLr032637@stark.hevanet.com> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> Message-ID: <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> Better question is how well the cell systems are holding up in DC today??? But, that is slightly OT. -Mike On Tue, Jan 20, 2009 at 11:24 AM, Fred Heutte wrote: > Normally I wouldn't do this but given that it's of-the-moment... > > fh > > ------------------------- > > > http://www.salon.com/tech/giga_om/online_video/2009/01/20/a_quick_review_of_obamas_inauguration_streams/ > > Tuesday, January 20, 2009 08:02 PST > A Quick Review of Obama's Inauguration Streams > By Chris Albrecht > > You may have heard, but Barack Obama gets to ditch the "-elect" part of his > title today as he will be sworn in (shortly) as > our new President. We've already provided an comprehensive list of where to > watch the inauguration online, but here's > a quick review of what to expect from some of them, so far. > > C-Span's coverage is not very impressive. The video window was small, and > choppy. Avoid. > > CBS is offering 7 HD streams of the event, and they look awesome. > Definitely the best of the lot ? worth watching. > > MSNBC, FOX (which is providing Hulu's feed) and ABC News's video is solid, > nothing too flashy. They all work just fine > (and I love that MSNBC allows embeds). > > Visit msnbc.com for Breaking News, World News, and News about the Economy > > I had problems with CNN. It was the only network that asked me to install > an update to Flash as well as another plug-in. > I skipped the second plug-in and it worked fine. The video's in widescreen, > which is nice, and the Facebook > integration gives you a running commentary. > > The Presidential Inauguration Committee's stream is pretty dull, offering > just imagery and no commentary. > > If our internal stats are any indication, this is going to be a huge day > for live-streaming, and it looks like for the most part, > every network involved is holding up and the Internet won't crash (of > course, we still have an hour to go). > > > From vixie at isc.org Tue Jan 20 13:48:35 2009 From: vixie at isc.org (Paul Vixie) Date: Tue, 20 Jan 2009 19:48:35 +0000 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) Message-ID: <86171.1232480915@nsa.vix.com> "Cisco VNI projections indicate that IP traffic will increase at a combined annual growth rate (CAGR) of 46 percent from 2007 to 2012, nearly doubling every two years. This will result in an annual bandwidth demand on the world's IP networks of approximately 522 exabytes2, or more than half a zettabyte." http://news.cnet.com/8301-13846_3-10145480-62.html From jack at crepinc.com Tue Jan 20 13:49:23 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 20 Jan 2009 14:49:23 -0500 Subject: inauguration streams review In-Reply-To: <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> Message-ID: <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> Cell networks held up reasonably well for voice, though SMS and MMS delivery times approached an hour during the event. Switch load in almost the entire US was higher than midnight on New Years (which is generally the highest load of the year). Our network has been preparing since June, and I assume likewise for others. -Jack Carrozzo (Engineer at $large cell company whose policy doesn't allow me to specify) On Tue, Jan 20, 2009 at 2:28 PM, Mike Lyon wrote: > Better question is how well the cell systems are holding up in DC today??? > > But, that is slightly OT. > > -Mike > > > On Tue, Jan 20, 2009 at 11:24 AM, Fred Heutte wrote: > >> Normally I wouldn't do this but given that it's of-the-moment... >> >> fh >> >> ------------------------- >> >> >> http://www.salon.com/tech/giga_om/online_video/2009/01/20/a_quick_review_of_obamas_inauguration_streams/ >> >> Tuesday, January 20, 2009 08:02 PST >> A Quick Review of Obama's Inauguration Streams >> By Chris Albrecht >> >> You may have heard, but Barack Obama gets to ditch the "-elect" part of his >> title today as he will be sworn in (shortly) as >> our new President. We've already provided an comprehensive list of where to >> watch the inauguration online, but here's >> a quick review of what to expect from some of them, so far. >> >> C-Span's coverage is not very impressive. The video window was small, and >> choppy. Avoid. >> >> CBS is offering 7 HD streams of the event, and they look awesome. >> Definitely the best of the lot ? worth watching. >> >> MSNBC, FOX (which is providing Hulu's feed) and ABC News's video is solid, >> nothing too flashy. They all work just fine >> (and I love that MSNBC allows embeds). >> >> Visit msnbc.com for Breaking News, World News, and News about the Economy >> >> I had problems with CNN. It was the only network that asked me to install >> an update to Flash as well as another plug-in. >> I skipped the second plug-in and it worked fine. The video's in widescreen, >> which is nice, and the Facebook >> integration gives you a running commentary. >> >> The Presidential Inauguration Committee's stream is pretty dull, offering >> just imagery and no commentary. >> >> If our internal stats are any indication, this is going to be a huge day >> for live-streaming, and it looks like for the most part, >> every network involved is holding up and the Internet won't crash (of >> course, we still have an hour to go). >> >> >> > From randy at psg.com Tue Jan 20 13:52:44 2009 From: randy at psg.com (Randy Bush) Date: Wed, 21 Jan 2009 04:52:44 +0900 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <86171.1232480915@nsa.vix.com> References: <86171.1232480915@nsa.vix.com> Message-ID: <49762B8C.2090209@psg.com> On 09.01.21 04:48, Paul Vixie wrote: > "Cisco VNI projections indicate that IP traffic will increase at a combined > annual growth rate (CAGR) of 46 percent from 2007 to 2012 i.e. about the same as it has been. deep shock. randy From pauldotwall at gmail.com Tue Jan 20 13:53:26 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 20 Jan 2009 14:53:26 -0500 Subject: Level3 NOC Contact In-Reply-To: <56F5BC5F404CF84896C447397A1AAF20BE8EA0@MAIL.nosi.netos.com> References: <56F5BC5F404CF84896C447397A1AAF20BE8EA0@MAIL.nosi.netos.com> Message-ID: <620fd17c0901201153t3ba8f1fen20a01902434a8f79@mail.gmail.com> On Tue, Jan 20, 2009 at 1:35 PM, Darryl Dunkin wrote: > Their support has been really giving me the run-around and is cluelessly > sending me from department to department. Does anyone have a good NOC > contact for them? I have one of their downstream customers hijacking > some of my IP space and they don't really care as I am not a direct > customer of theirs. 1-877-4-LEVEL3. The e-mail box isn't regularly monitored or responded to. Drive Slow, Paul Wall From ddunkin at netos.net Tue Jan 20 13:55:50 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 20 Jan 2009 11:55:50 -0800 Subject: Level3 NOC Contact References: <56F5BC5F404CF84896C447397A1AAF20BE8EA0@MAIL.nosi.netos.com> <620fd17c0901201153t3ba8f1fen20a01902434a8f79@mail.gmail.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF20BE8EBB@MAIL.nosi.netos.com> Thanks, I've been bounced between that number and another customer service line for a week. I believe I've received enough replies from the community that I might get somewhere this month :) Thanks all for the replies and assistance. -----Original Message----- From: Paul Wall [mailto:pauldotwall at gmail.com] Sent: Tuesday, January 20, 2009 11:53 To: Darryl Dunkin Cc: nanog at merit.edu Subject: Re: Level3 NOC Contact On Tue, Jan 20, 2009 at 1:35 PM, Darryl Dunkin wrote: > Their support has been really giving me the run-around and is cluelessly > sending me from department to department. Does anyone have a good NOC > contact for them? I have one of their downstream customers hijacking > some of my IP space and they don't really care as I am not a direct > customer of theirs. 1-877-4-LEVEL3. The e-mail box isn't regularly monitored or responded to. Drive Slow, Paul Wall From swmike at swm.pp.se Tue Jan 20 13:58:21 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 20 Jan 2009 20:58:21 +0100 (CET) Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <86171.1232480915@nsa.vix.com> References: <86171.1232480915@nsa.vix.com> Message-ID: On Tue, 20 Jan 2009, Paul Vixie wrote: > "Cisco VNI projections indicate that IP traffic will increase at a combined > annual growth rate (CAGR) of 46 percent from 2007 to 2012, nearly doubling > every two years. This will result in an annual bandwidth demand on the > world's IP networks of approximately 522 exabytes2, or more than half a > zettabyte." Two thoughts: Why do some people think that bytes/month is a relevant measure of traffic? Peak bits/second is what you need to make your network handle for it to perform well. For me CAGR of 46% is a slowdown. I'm used to 75-120% growth per year in traffic, 46% is a relief. As markets mature (we're seeing decline in # of DSL lines in the country, increase is in LAN and mobile) less new people are going online (the ones who want Internet access already have it) and the increase per year in traffic by existing users is slower than the increase seen during the rush of new users coming online. This will of course vary by where you are in the world... -- Mikael Abrahamsson email: swmike at swm.pp.se From pauldotwall at gmail.com Tue Jan 20 13:59:11 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 20 Jan 2009 14:59:11 -0500 Subject: Inauguration streaming traffic In-Reply-To: <787581440901200950i7747f028m7391a3e1e4b4397c@mail.gmail.com> References: <497607E8.9070107@west.net> <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> <787581440901200950i7747f028m7391a3e1e4b4397c@mail.gmail.com> Message-ID: <620fd17c0901201159p17939923ubf8325c5b8f6dbcf@mail.gmail.com> On Tue, Jan 20, 2009 at 12:50 PM, Ren Provo wrote: > BitGravity did a great job. Nearly every major CDN or web host was involved with the inauguration in some manner, with no reported issues to speak of. Some "facilities-based" providers even placed infrastructure with their competitors to be extra certain they could handle the traffic spike. With so many involved, and in the interests of full disclosure, do you or Comcast have any fiscal interest in BitGravity's streaming of this event? ;) Drive Slow Paul Wall From john at vanoppen.com Tue Jan 20 14:01:23 2009 From: john at vanoppen.com (John van Oppen) Date: Tue, 20 Jan 2009 12:01:23 -0800 Subject: Inauguration streaming traffic References: <20090120102757.A970C4E3@resin18.mta.everyone.net> Message-ID: We wholesale to a lot of regional and local ISPs as well as several higher education institutions here in Washington State. It was interesting to see the breakdown of traffic increases between types of customers. We saw around 2.5x the amount of traffic towards most of these customers as normal but some of the most dramatic increases were on corporate customers where obviously lots of people were watching the online streams. Our monitoring indicated that in a couple of the markets we service had one of our competitors completely saturate their backbone so I think we got a bit more than we otherwise would have for the ISPs, our own non-multi-homed users were around 1.5X their normal peak by around 9 AM PST. All-in-all, things seemed to work well, most of the bump in traffic from our perspective came from our limelight networks and akamai peering sessions as others have indicated. It was a good advertisement for having spare capacity handy. John van Oppen Spectrum Networks LLC / AS11404 -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Tuesday, January 20, 2009 10:28 AM To: nanog at nanog.org Subject: Re: Inauguration streaming traffic ------- jay at west.net wrote: ------- From: Jay Hennigan We're a regional ISP, about 80% SMB 20% residential. We're seeing almost double our normal downstream traffic right now. Anyone else? ------------------------------------ Not much of a traffic boost here in Hawaii as it happened at 7am local time. Most folks caught the first part on TV and rushed to work, evidently. scott From matthew at eeph.com Tue Jan 20 14:10:33 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Tue, 20 Jan 2009 12:10:33 -0800 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <49762B8C.2090209@psg.com> References: <86171.1232480915@nsa.vix.com> <49762B8C.2090209@psg.com> Message-ID: On Jan 20, 2009, at 11:52 AM, Randy Bush wrote: > On 09.01.21 04:48, Paul Vixie wrote: >> "Cisco VNI projections indicate that IP traffic will increase at a >> combined >> annual growth rate (CAGR) of 46 percent from 2007 to 2012 > > i.e. about the same as it has been. deep shock. > > randy > With no bump when v4 address runout happens. We'll see. Matthew Kaufman (sent from my iPhone) From patrick at ianai.net Tue Jan 20 14:18:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 20 Jan 2009 15:18:05 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: References: <86171.1232480915@nsa.vix.com> Message-ID: <08C5A96B-68C8-445E-9D9D-04D55070E5DA@ianai.net> On Jan 20, 2009, at 2:58 PM, Mikael Abrahamsson wrote: > On Tue, 20 Jan 2009, Paul Vixie wrote: > >> "Cisco VNI projections indicate that IP traffic will increase at a >> combined >> annual growth rate (CAGR) of 46 percent from 2007 to 2012, nearly >> doubling >> every two years. This will result in an annual bandwidth demand on >> the >> world's IP networks of approximately 522 exabytes2, or more than >> half a >> zettabyte." > > Two thoughts: > > Why do some people think that bytes/month is a relevant measure of > traffic? Peak bits/second is what you need to make your network > handle for it to perform well. > > For me CAGR of 46% is a slowdown. I'm used to 75-120% growth per > year in traffic, 46% is a relief. As markets mature (we're seeing > decline in # of DSL lines in the country, increase is in LAN and > mobile) less new people are going online (the ones who want Internet > access already have it) and the increase per year in traffic by > existing users is slower than the increase seen during the rush of > new users coming online. It is a slowdown, but the underlying situation is not the same. 100 Mbps came out before most were doing 100 Mbps on a typical LAN in aggregate. 1000 Mbps came out before most were doing 1000 Mbps on a typical WAN in aggregate. 10000 Mbps came out before most were aggregating 10x[GigE|OC12] on their largest individual WAN links. 100000 Mbps should come out shortly after most are aggregating 32x10GE on a typical WAN link. See a pattern forming here? -- TTFN, patrick From matthew at eeph.com Tue Jan 20 14:46:08 2009 From: matthew at eeph.com (Matthew Kaufman) Date: Tue, 20 Jan 2009 12:46:08 -0800 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <49763458.6010204@ieee.org> References: <86171.1232480915@nsa.vix.com> <49762B8C.2090209@psg.com> <49763458.6010204@ieee.org> Message-ID: <49763810.4060408@eeph.com> Alex H. Ryu wrote: > Probably IP v4 address runout may not affect for traffic amount that much. > Since people will use NATing for saving IP addresses, and IPv6 will be > slowly take some traffic for that matter. > > It's more of the cost of bandwidth, and the application people uses. > > As I said, "we'll see"... the people using NATing are still going to have to connect to something, somewhere, to get the data that makes up this traffic. The people buying boxes that move traffic around will be spending some of that money on either v6 capability or NATs or both, too. Matthew Kaufman From wschultz at bsdboy.com Tue Jan 20 14:54:32 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Tue, 20 Jan 2009 12:54:32 -0800 Subject: DNS Amplification attack? Message-ID: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> Anyone else noticing "." requests coming in to your DNS servers? http://isc.sans.org/diary.html?storyid=5713 I'm seeing them coming from the following addresses in my ns server logs. 69.50.142.110 69.50.142.11 76.9.16.171 66.230.128.15 66.230.160.1 -wil From nanog at email.fries.net Tue Jan 20 14:55:14 2009 From: nanog at email.fries.net (Todd T. Fries) Date: Tue, 20 Jan 2009 14:55:14 -0600 Subject: isprime DOS in progress In-Reply-To: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> Message-ID: <20090120205514.GA10257@fries.net> You guys might want to be aware that isprime.com (I am not affiliated or representing them, just passing on info since friends and I noticed this) is actively under a DOS where lots of people's dns servers around the world are being queried with bogus sourced dns requests not from port 53 for 'NS? .'. This then bounces back to their authoritative nameservers which are getting traffic overload. They've asked that those of us that can should block all but port 53 from the following two IP's (their dns servers as seen on whois) so as not to block legitimate dns info: 66.230.128.15 66.230.160.1 Here is the response from their abuse department: To: todd at fries.net Subject: Re: dos info? From: ISPrime Support Date: Tue, 20 Jan 2009 15:16:02 -0500 (EST) Hello, These are the result of a spoofed dns recursion attack against our servers. The actual packets in question (the ones reaching your servers) do NOT originate from our network as such there is no way for us to filter things from our end. If you are receiving queries from 76.9.31.42/76.9.16.171 neither of these machines make legitimate outbound dns requests so an inbound filter of packets to udp/53 from either of these two sources is perfect. If you are receiving queries from 66.230.128.15/66.230.160.1 these servers are authoritative nameservers. Please do not blackhole either of these IPs as they host many domains. However, these IPs do not make outbound DNS requests so filtering requests to your IPs from these ips with a destination port of 53 should block any illegitimate requests. An ACL similar to: access-list 110 deny udp host 66.230.160.1 neq 53 any eq 53 access-list 110 deny udp host 66.230.128.15 neq 53 any eq 53 Is what you want. I would also suggest taking a look at the excellent CYMRU secure bind template (assuming you are running bind), to help you configure your nameservers so that you do not participate in this attack: http://www.cymru.com/Documents/secure-bind-template.html. Thanks for your help in mitigating this attack against us. Please let me know if I can be of further assistance. ISPrime Support support at isprime.com ICQ: 136633378 On 2009-01-20, at 15:14:33, "Todd T. Fries" wrote: > I was told to write here for your writeup on what to block and such > to help you guys out given the DOS that is ongoing. Thanks, -- Todd Fries .. todd at fries.net _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt Penned by Mike Lyon on 20090109 16:41.04, we have: | If so, would you mind hitting me up offlist? I have a few questions that i | am unable to get answered through normal channels. | | Cheers, | Mike From r.bhatia at ipax.at Tue Jan 20 16:43:04 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Tue, 20 Jan 2009 23:43:04 +0100 Subject: DNS Amplification attack? In-Reply-To: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> Message-ID: <49765378.1090303@ipax.at> hi, On 20.01.2009 21:54, Wil Schultz wrote: > http://isc.sans.org/diary.html?storyid=5713 > > I'm seeing them coming from the following addresses in my ns server logs. > > 69.50.142.110 > 69.50.142.11 > 76.9.16.171 > 66.230.128.15 > 66.230.160.1 counting 319149 denied queries for './NS/IN' since 2008-01-01, i see roughly 96% "coming" from those ips: > 1071 216.240.131.173 > 1183 74.86.34.144 > 3397 216.201.83.2 > 4526 216.201.82.19 > 13568 66.230.128.15 > 15487 69.50.142.110 > 17689 66.230.160.1 > 21987 69.50.137.175 > 52392 76.9.16.171 > 72591 76.9.31.42 > 113548 69.50.142.11 so "yes" :) please also see another thread titled "isprime DOS in progress". cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From David_Hankins at isc.org Tue Jan 20 17:31:28 2009 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 20 Jan 2009 15:31:28 -0800 Subject: DNS Amplification attack? In-Reply-To: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> Message-ID: <20090120233128.GI15562@isc.org> On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote: > Anyone else noticing "." requests coming in to your DNS servers? > > http://isc.sans.org/diary.html?storyid=5713 I was surprised to see 'amplification' in the subject line here, since on my nameservers my replies are of equal length to the queries. A little bit of asking around, and I see that it is an amplification attack, preying on old software. Let me sum up; If you're running 9.4 or later, you will reply to these packets with 45 octet RCODE:Refused replies. 1:1. 9.4 has an "allow-query-cache" directive that defaults to track allow-recursion, which you should have set appropriately. If you're running 9.3 or earlier, you will reply to these queries "out of cache" (the root hints), and those replies can be 300-500 octets I think. 1:6-11. So in lieu of keeping a new up-to-date list of IP addresses to filter, as it expands and shrinks, you can greatly reduce your own footprint in these attacks with a quick upgrade. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Tue Jan 20 17:31:51 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 20 Jan 2009 23:31:51 +0000 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <86171.1232480915@nsa.vix.com> References: <86171.1232480915@nsa.vix.com> Message-ID: <20090120233151.GA3835@vacation.karoshi.com.> > "Cisco VNI projections indicate that IP traffic will increase at a combined > annual growth rate (CAGR) of 46 percent from 2007 to 2012, nearly doubling > every two years. This will result in an annual bandwidth demand on the > world's IP networks of approximately 522 exabytes2, or more than half a > zettabyte." > > http://news.cnet.com/8301-13846_3-10145480-62.html duh... from a much earlier thread... > > that lesson is, the installed base is meaningless, and how we did it > > before is meaningless, all that matters is getting growth right. > > > > Mike O'dell... Mo's Law. 1994 > > I believe the quote is What installed base? > > /vijay to play devils advocate, how much impact does caching have on the total traffic flow anyway? --bill From tme at multicasttech.com Tue Jan 20 17:37:34 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 20 Jan 2009 18:37:34 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <20090120233151.GA3835@vacation.karoshi.com.> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> Message-ID: <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> On Jan 20, 2009, at 6:31 PM, bmanning at vacation.karoshi.com wrote: >> "Cisco VNI projections indicate that IP traffic will increase at a >> combined >> annual growth rate (CAGR) of 46 percent from 2007 to 2012, nearly >> doubling >> every two years. This will result in an annual bandwidth demand on >> the >> world's IP networks of approximately 522 exabytes2, or more than >> half a >> zettabyte." >> >> http://news.cnet.com/8301-13846_3-10145480-62.html > > duh... > > from a much earlier thread... > > >>> that lesson is, the installed base is meaningless, and how we did it >>> before is meaningless, all that matters is getting growth right. >>> >>> Mike O'dell... Mo's Law. 1994 >> >> I believe the quote is What installed base? >> >> /vijay > > > to play devils advocate, how much impact does caching have > on the total traffic flow anyway? Less and less would be my estimate. How much video is cached ? How much P2P is cached ? Regards Marshall > > > --bill > From patrick at ianai.net Tue Jan 20 17:41:07 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 20 Jan 2009 18:41:07 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> Message-ID: <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> On Jan 20, 2009, at 6:37 PM, Marshall Eubanks wrote: >> to play devils advocate, how much impact does caching have >> on the total traffic flow anyway? > > Less and less would be my estimate. How much video is cached ? How > much P2P is cached ? Define "cached". For instance, most of the video today (which apparently had 12 zeros in the bits per second number) was "cached", if you ask the CDNs serving it. Sounds to me like that is significant, no matter how big your network is. -- TTFN, patrick From jabley at hopcount.ca Tue Jan 20 17:49:14 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 20 Jan 2009 18:49:14 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> Message-ID: On 2009-01-20, at 18:37, Marshall Eubanks wrote: > Less and less would be my estimate. How much video is cached ? How > much P2P is cached ? If you asked Akamai, Limelight and friends, they might tell you that 100% of important video is cached. And viewed from some angles, every peer who receives a block of data and offers to serve it to others is caching that block of data for the benefit of other peers. Joe From bmanning at vacation.karoshi.com Tue Jan 20 18:18:51 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Jan 2009 00:18:51 +0000 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> Message-ID: <20090121001851.GA4102@vacation.karoshi.com.> On Tue, Jan 20, 2009 at 06:49:14PM -0500, Joe Abley wrote: > > On 2009-01-20, at 18:37, Marshall Eubanks wrote: > > >Less and less would be my estimate. How much video is cached ? How > >much P2P is cached ? > > If you asked Akamai, Limelight and friends, they might tell you that > 100% of important video is cached. And viewed from some angles, every > peer who receives a block of data and offers to serve it to others is > caching that block of data for the benefit of other peers. > > > Joe aha... so taking a peek at my nearby BT tracker & client, it seems that there is abt 12% "duplicate" traffic. wildextrapolation -- poor caching design/flaky networks have a 10-15% extra traffic load, "just to make sure". i'd guess that 10% of a femto (or is it the other way) byte of traffic relates to real money. --bill From bmanning at vacation.karoshi.com Tue Jan 20 18:23:36 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Jan 2009 00:23:36 +0000 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> Message-ID: <20090121002336.GB4102@vacation.karoshi.com.> Hum... whats the wholesale cost of 10G/byte connection? And what would the cost of a zetabyte connection cost at todays rates? me thinks Pres Obama's USD 825B package is way too small - or the cost per G/Byte is going to drop a lot... if the traffic loads keep up. --bill From adrian at creative.net.au Tue Jan 20 18:40:11 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 21 Jan 2009 09:40:11 +0900 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> Message-ID: <20090121004010.GC15862@skywalker.creative.net.au> On Tue, Jan 20, 2009, Patrick W. Gilmore wrote: > Define "cached". > > For instance, most of the video today (which apparently had 12 zeros > in the bits per second number) was "cached", if you ask the CDNs > serving it. > > Sounds to me like that is significant, no matter how big your network > is. If, for example, Google's current generation of YouTube content serving wasn't 100% uncachable by design, Squid caches would probably be saving a stupid amount of bandwidth for those of you who are using it. People rolling Squid + 'magic adrian rules to rewrite Youtube URLs so they don't suck' report upwards of 80% byte hit rates on -just- the Youtube content, because people view the same bloody popular videos over and over again. Thats 80% of a couple hundred megabits for a couple groups in Brazil, and that translates to mega dollars to them. There's no reason to doubt this wouldn't be the case even in Europe and North America for forward caches put in exactly the right spot to see exactly the right number of people. I tried talking to Google about this. Those I spoke to went from enthusiastic one month to "sorry, been told this won't happen!" the next month. Which is sad really; the people who keep coming to me and asking about caching all those things you funny CDNs are pushing out are those who are on things like satellite links, or in eastern europe / south america, where the -infrastructure- is still lacking. They're the ones blocking facebook, youtube, etc, because of the amount of bandwidth used by just those sites. :) Adrian (And I know about the various generations of Google content boxes out there and have heard stories from people who have and are trialling them. Thats great if you're a service provider, and sucks if you're not well connected to a service provider. Like, say, schools in Australia trying to run a class with 30-40 odd computers hitting Google maps at once. tsk.) From Mark_Andrews at isc.org Tue Jan 20 19:28:49 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 21 Jan 2009 12:28:49 +1100 Subject: DNS Amplification attack? In-Reply-To: Your message of "Tue, 20 Jan 2009 15:31:28 -0800." <20090120233128.GI15562@isc.org> Message-ID: <200901210128.n0L1Sn2V036934@drugs.dv.isc.org> In message <20090120233128.GI15562 at isc.org>, "David W. Hankins" writes: > > --J+eNKFoVC4T1DV3f > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote: > > Anyone else noticing "." requests coming in to your DNS servers? > > > > http://isc.sans.org/diary.html?storyid=3D5713 > > I was surprised to see 'amplification' in the subject line here, since > on my nameservers my replies are of equal length to the queries. A > little bit of asking around, and I see that it is an amplification > attack, preying on old software. > > Let me sum up; > > If you're running 9.4 or later, you will reply to these packets with > 45 octet RCODE:Refused replies. 1:1. 9.4 has an "allow-query-cache" > directive that defaults to track allow-recursion, which you should > have set appropriately. > > If you're running 9.3 or earlier, you will reply to these queries > "out of cache" (the root hints), and those replies can be 300-500 > octets I think. 1:6-11. > > So in lieu of keeping a new up-to-date list of IP addresses to filter, > as it expands and shrinks, you can greatly reduce your own footprint > in these attacks with a quick upgrade. > > --=20 > David W. Hankins "If you don't do it right the first time, > Software Engineer you'll just have to do it again." > Internet Systems Consortium, Inc. -- Jack T. Hankins > > --J+eNKFoVC4T1DV3f > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkl2XtAACgkQcXeLeWu2vmrR+wCePhZM2IrxV1mCKpnpsL6RDPIk > KnoAnRyVJpYrlan65MYJF7LRJc8nXJuj > =F1Dc > -----END PGP SIGNATURE----- > > --J+eNKFoVC4T1DV3f-- > Or better yet trace the query traffic back to the offending source and implement BCP38 there. If the source won't implement BCP38 then de-peer them. It's time to take back the "commons". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From kgasso-lists at visp.net Tue Jan 20 20:16:45 2009 From: kgasso-lists at visp.net (Kameron Gasso) Date: Tue, 20 Jan 2009 18:16:45 -0800 Subject: DNS Amplification attack? In-Reply-To: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> Message-ID: <4976858D.3080705@visp.net> Wil Schultz wrote: > Anyone else noticing "." requests coming in to your DNS servers? > > http://isc.sans.org/diary.html?storyid=5713 > > I'm seeing them coming from the following addresses in my ns server logs. > > 69.50.142.110 > 69.50.142.11 > 76.9.16.171 > 66.230.128.15 > 66.230.160.1 We're also seeing a great number of these, but the idiots spoofing the queries are hitting several non-recursive nameservers we host - and only generating 59-byte "REFUSED" replies. Looks like they probably just grabbed a bunch of DNS hosts out of WHOIS and hoped that they were recursive resolvers. -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From morrowc.lists at gmail.com Tue Jan 20 20:21:43 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Jan 2009 21:21:43 -0500 Subject: DNS Amplification attack? In-Reply-To: <4976858D.3080705@visp.net> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> <4976858D.3080705@visp.net> Message-ID: <75cb24520901201821s3ce653bbk20efaa4d86a4a8f@mail.gmail.com> On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso wrote: > We're also seeing a great number of these, but the idiots spoofing the > queries are hitting several non-recursive nameservers we host - and only > generating 59-byte "REFUSED" replies. > > Looks like they probably just grabbed a bunch of DNS hosts out of WHOIS > and hoped that they were recursive resolvers. a point to bear in mind here is that... 'its working' is good enough for the bad folks :( no need to optimize when this works. Also, it's likely this isn't all of the problem the spoofed requestors are seeing these past few days :( -Chris From kgasso-lists at visp.net Tue Jan 20 20:35:51 2009 From: kgasso-lists at visp.net (Kameron Gasso) Date: Tue, 20 Jan 2009 18:35:51 -0800 Subject: DNS Amplification attack? In-Reply-To: <75cb24520901201821s3ce653bbk20efaa4d86a4a8f@mail.gmail.com> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> <4976858D.3080705@visp.net> <75cb24520901201821s3ce653bbk20efaa4d86a4a8f@mail.gmail.com> Message-ID: <49768A07.7060105@visp.net> Christopher Morrow wrote: > a point to bear in mind here is that... 'its working' is good enough > for the bad folks :( no need to optimize when this works. Also, it's > likely this isn't all of the problem the spoofed requestors are seeing > these past few days :( Unfortunately, I can't restrict traffic to/from my authoritative nameservers like I can with my recursive ones, since it will break DNS resolution for outside visitors to domains we host. Fortunately, the spoofed queries are 60 bytes and my REFUSED responses are only 59, so it's a terribly inefficient way to DoS someone. However, I never said that the DDoS kiddies were smart - doesn't seem to be stopping them from trying. :( Thanks, -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From morrowc.lists at gmail.com Tue Jan 20 20:47:57 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Jan 2009 21:47:57 -0500 Subject: DNS Amplification attack? In-Reply-To: <49768A07.7060105@visp.net> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> <4976858D.3080705@visp.net> <75cb24520901201821s3ce653bbk20efaa4d86a4a8f@mail.gmail.com> <49768A07.7060105@visp.net> Message-ID: <75cb24520901201847x5377880k5dfe3542e4659927@mail.gmail.com> On Tue, Jan 20, 2009 at 9:35 PM, Kameron Gasso wrote: > Fortunately, the spoofed queries are 60 bytes and my REFUSED responses > are only 59, so it's a terribly inefficient way to DoS someone. bind has a 'blackhole' capabilty... which doesn't seem to reply with anything (from my quick testing) -chris From cmadams at hiwaay.net Tue Jan 20 21:07:30 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Jan 2009 21:07:30 -0600 Subject: DNS Amplification attack? In-Reply-To: <49768A07.7060105@visp.net> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> <4976858D.3080705@visp.net> <75cb24520901201821s3ce653bbk20efaa4d86a4a8f@mail.gmail.com> <49768A07.7060105@visp.net> Message-ID: <20090121030730.GB1540104@hiwaay.net> Once upon a time, Kameron Gasso said: > Fortunately, the spoofed queries are 60 bytes and my REFUSED responses > are only 59, so it's a terribly inefficient way to DoS someone. > However, I never said that the DDoS kiddies were smart - doesn't seem to > be stopping them from trying. :( Well, it still makes a DDoS, since they can (theoretically) have a bunch of sources spoofing the IPs, and the packets to the targets have legitimate source addresses (so they can't easily be blocked by the target). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jay at miscreant.org Tue Jan 20 21:08:25 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Wed, 21 Jan 2009 14:08:25 +1100 Subject: DNS Amplification attack? Message-ID: <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> > On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso wrote: > We're also seeing a great number of these, but the idiots spoofing the > queries are hitting several non-recursive nameservers we host - and only > generating 59-byte "REFUSED" replies. > > Looks like they probably just grabbed a bunch of DNS hosts out of WHOIS > and hoped that they were recursive resolvers. First post to this list, play nice :) Are you sure about this? I'm seeing these requests on /every/ (unrelated) NS I have access to, which numbers several dozen, in various countries across the world, and from various registries (.net, .org, .com.au). The spread of servers I've checked is so random that I'm wondering just how many NS records they've laid their hands on. I've also noticed that on a server running BIND 9.3.4-P1 with recursion disabled, they're still appear to be getting the list of root NS's from cache, which is a 272-byte response to a 61-byte request, which by my definition is an amplification. Cheers, Jay From cmadams at hiwaay.net Tue Jan 20 21:17:50 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Jan 2009 21:17:50 -0600 Subject: DNS Amplification attack? In-Reply-To: <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> References: <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> Message-ID: <20090121031750.GC1540104@hiwaay.net> Once upon a time, jay at miscreant.org said: > I've also noticed that on a server running BIND 9.3.4-P1 with > recursion disabled, they're still appear to be getting the list of > root NS's from cache, which is a 272-byte response to a 61-byte > request, which by my definition is an amplification. Add "additional-from-cache no;" to the options{} section of your named.conf. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Mark_Andrews at isc.org Tue Jan 20 21:23:32 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 21 Jan 2009 14:23:32 +1100 Subject: DNS Amplification attack? In-Reply-To: Your message of "Wed, 21 Jan 2009 14:08:25 +1100." <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> Message-ID: <200901210323.n0L3NWRf002868@drugs.dv.isc.org> In message <20090121140825.xwdzd4p64kgwo4go at web1.nswh.com.au>, jay at miscreant.or g writes: > > On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso wro= > te: > > > We're also seeing a great number of these, but the idiots spoofing the > > queries are hitting several non-recursive nameservers we host - and only > > generating 59-byte "REFUSED" replies. > > > > Looks like they probably just grabbed a bunch of DNS hosts out of WHOIS > > and hoped that they were recursive resolvers. > > First post to this list, play nice :) > > Are you sure about this? I'm seeing these requests on /every/ =20 > (unrelated) NS I have access to, which numbers several dozen, in =20 > various countries across the world, and from various registries (.net, =20 > .org, .com.au). The spread of servers I've checked is so random that =20 > I'm wondering just how many NS records they've laid their hands on. > > I've also noticed that on a server running BIND 9.3.4-P1 with =20 > recursion disabled, they're still appear to be getting the list of =20 > root NS's from cache, which is a 272-byte response to a 61-byte =20 > request, which by my definition is an amplification. BIND 9.3.4-P1 is past end-of-life. You need to properly set allow-query at both the option/view level and at the zone level to prevent retrieving answers from the cache in 9.3.x. option/view level "allow-query { trusted; };" zone level "allow-query { any; };" BIND 9.4.x and later have allow-query-cache make the configuration job easier. It also defaults to directly connected networks. Mark > Cheers, > > Jay > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jay at miscreant.org Tue Jan 20 21:25:49 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Wed, 21 Jan 2009 14:25:49 +1100 Subject: DNS Amplification attack? In-Reply-To: <20090121031750.GC1540104@hiwaay.net> References: <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> <20090121031750.GC1540104@hiwaay.net> Message-ID: <20090121142549.rgxvfvza5cggwsgc@web1.nswh.com.au> Quoting Chris Adams : > Once upon a time, jay at miscreant.org said: >> I've also noticed that on a server running BIND 9.3.4-P1 with >> recursion disabled, they're still appear to be getting the list of >> root NS's from cache, which is a 272-byte response to a 61-byte >> request, which by my definition is an amplification. > > Add "additional-from-cache no;" to the options{} section of your > named.conf. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > Thanks for the response Chris. I'm running higher versions of BIND, so don't see this behaviour. But I will pass it on to the ISP in question ;) From frnkblk at iname.com Tue Jan 20 22:45:56 2009 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 20 Jan 2009 22:45:56 -0600 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: During the inauguration our traffic was higher than normal, but levels only reached our average daily peak. More specifically, we climbed to our average daily peak earlier than normal, and it stayed at a sustained rate, but it didn't break any records here. Frank -----Original Message----- From: Jay Hennigan [mailto:jay at west.net] Sent: Tuesday, January 20, 2009 11:21 AM To: nanog at nanog.org Subject: Inauguration streaming traffic We're a regional ISP, about 80% SMB 20% residential. We're seeing almost double our normal downstream traffic right now. Anyone else? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From mike-nanog at tiedyenetworks.com Tue Jan 20 23:25:31 2009 From: mike-nanog at tiedyenetworks.com (mike) Date: Tue, 20 Jan 2009 21:25:31 -0800 Subject: expectations for bgp peering? Message-ID: <4976B1CB.2030600@tiedyenetworks.com> Hello, So I am just wondering what my expecations should be in a bgp peering scenario where I am multihomed with my own ASN and arin assigned ip space. At issue is the fact that my backup isp forced me to use ebgp multihop to peer with a router internal to their network and not the border router I am directly attached to, and secondly, that they say I am not allowed to prepend at all - they will do it for me, and from the looks of things they have established a route-map that just prepends their AS 6 times to my announcement. This smells of bad engineering. I have looked up the bgp report for my provider and they have 0 downstream AS's, and the week that this project has taken (and it's still not up and working) has left me with less than absolute confidence in the provider. I want to know if anyone has an opinion on ebgp multihop for external customers, and wether I should really have an expectation to be able to assign my prepends as suits my needs? Are there any conditions that could make this fail that I should be aware of? Mike- From patrick at ianai.net Tue Jan 20 23:27:03 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 21 Jan 2009 00:27:03 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <20090121004010.GC15862@skywalker.creative.net.au> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> Message-ID: <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> On Jan 20, 2009, at 7:40 PM, Adrian Chadd wrote: > On Tue, Jan 20, 2009, Patrick W. Gilmore wrote: > >> Define "cached". >> >> For instance, most of the video today (which apparently had 12 zeros >> in the bits per second number) was "cached", if you ask the CDNs >> serving it. >> >> Sounds to me like that is significant, no matter how big your network >> is. > > If, for example, Google's current generation of YouTube content > serving > wasn't 100% uncachable by design, Squid caches would probably be > saving a stupid amount of bandwidth for those of you who are using it. > > People rolling Squid + 'magic adrian rules to rewrite Youtube URLs > so they don't suck' report upwards of 80% byte hit rates on -just- > the Youtube content, because people view the same bloody popular > videos over and over again. Thats 80% of a couple hundred megabits > for a couple groups in Brazil, and that translates to mega dollars > to them. > > There's no reason to doubt this wouldn't be the case even in Europe > and North America for forward caches put in exactly the right spot > to see exactly the right number of people. > > I tried talking to Google about this. Those I spoke to went from > enthusiastic one month to "sorry, been told this won't happen!" > the next month. Which is sad really; the people who keep coming > to me and asking about caching all those things you funny CDNs are > pushing out are those who are on things like satellite links, or > in eastern europe / south america, where the -infrastructure- > is still lacking. They're the ones blocking facebook, youtube, > etc, because of the amount of bandwidth used by just those sites. :) I do not work for GOOG or YouTube, I do not know why they do what they do. However, it is trivial to think up perfectly valid reasons for Google to intentionally break caches on YouTube content (e.g. paid advertising per download). Doesn't matter if you have small links or no infrastructure or whatever. Google has ever right, moral & legal, to serve content as they please. They are providing the content for free, but they want to do it on their own terms. Seems perfectly reasonable to me. Do you disagree? Sure the situation sux, but life is not fair. As for CDNs, most do not do anything to the content they serve. A content provider makes the content and hands it to the CDNs, which serves the content. the CDN does not own, create, or modify the content. (There might be edge cases, but we are talking generalities here.) You see "funny" stuff, talk to the content owner, not the CDN. > (And I know about the various generations of Google content boxes > out there > and have heard stories from people who have and are trialling them. > Thats great if you're a service provider, and sucks if you're not well > connected to a service provider. Like, say, schools in Australia > trying > to run a class with 30-40 odd computers hitting Google maps at once. > tsk.) Google is not the only company which will put caches into any provider - or school (which is really just a special case provider) - with enough traffic. A school with 30 machines probably would not qualify. This is not being mean, this is just being rational. No way those 30 machines save the company enough money to pay for the caches. Again, sux, but that's life. I'd love to hear your solution - besides writing "magic" into squid to intentionally break or alter (some would use much harsher language) content you do not own. Content others are providing for free. -- TTFN, patrick From patrick at ianai.net Tue Jan 20 23:35:17 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 21 Jan 2009 00:35:17 -0500 Subject: expectations for bgp peering? In-Reply-To: <4976B1CB.2030600@tiedyenetworks.com> References: <4976B1CB.2030600@tiedyenetworks.com> Message-ID: <9D2BA908-DCA4-485A-9C00-2479447ECE1C@ianai.net> On Jan 21, 2009, at 12:25 AM, mike wrote: > So I am just wondering what my expecations should be in a bgp > peering scenario where I am multihomed with my own ASN and arin > assigned ip space. At issue is the fact that my backup isp forced me > to use ebgp multihop to peer with a router internal to their network > and not the border router I am directly attached to, and secondly, > that they say I am not allowed to prepend at all - they will do it > for me, and from the looks of things they have established a route- > map that just prepends their AS 6 times to my announcement. > > This smells of bad engineering. I have looked up the bgp report > for my provider and they have 0 downstream AS's, and the week that > this project has taken (and it's still not up and working) has left > me with less than absolute confidence in the provider. I want to > know if anyone has an opinion on ebgp multihop for external > customers, and wether I should really have an expectation to be able > to assign my prepends as suits my needs? Are there any conditions > that could make this fail that I should be aware of? First, Rule Number One: Your network, your decision. (Okay, rule number one not about spam. :) Your transit provider owns your transit provider's network, he can run it as he pleases. There is nothing "wrong" with multi-hop or not allowing you to prepend. Bits are flowing, and you are connected. Now that we know he _can_ run his network like that, I would never buy transit from someone who _does_ run a network like that. I've seen multi-hop before, but it is usually when something unusual is happening. For instance, if you are in a strange location and the edge router near you does not speak BGP. It is not horrible, but certainly not something I personally would prefer. Multi-hop can present more or at least different failure modes than direct BGP, but those can be managed with clue and effort. The non-prepending thing though, that's Just Plain Silly. And hints at a general lack of clue. Which means that multi-hop is dangerous as it requires more clue, not less, to manage properly. -- TTFN, patrick From surfer at mauigateway.com Tue Jan 20 23:52:37 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 20 Jan 2009 21:52:37 -0800 Subject: expectations for bgp peering? Message-ID: <20090120215237.F6C1A157@resin14.mta.everyone.net> Apologies for top posting, but my response is a little long long... I wouldn't be too concerned about the multi-hop as there're many reasons why they might do that, but a week out and it's still not working? It's all about customer service. Are they giving you the appropriate level of service you expect for what you're paying? If not, vote with your dollars and move on... Usually, I get the circuit up and pingable to the IPs that will be doing the peering ahead of time. I then set a date for the BGP turn up. On my side, BGP is pre-configured and all I have to do is type 'no shut'. Most times everything comes up and we all go home happy. Sometimes I have to do a little troubleshooting. If they got the lower layers up ahead of time with you, set a date to turn up BGP and now it's a week later, I'd be worried about what type of customer service they'd give later on when trouble happens. And they don't allow you to prepend? In my book that'd be two strikes against them and this isn't baseball, so I wouldn't wait for the third strike. scott --- mike-nanog at tiedyenetworks.com wrote: So I am just wondering what my expecations should be in a bgp peering scenario where I am multihomed with my own ASN and arin assigned ip space. At issue is the fact that my backup isp forced me to use ebgp multihop to peer with a router internal to their network and not the border router I am directly attached to, and secondly, that they say I am not allowed to prepend at all - they will do it for me, and from the looks of things they have established a route-map that just prepends their AS 6 times to my announcement. This smells of bad engineering. I have looked up the bgp report for my provider and they have 0 downstream AS's, and the week that this project has taken (and it's still not up and working) has left me with less than absolute confidence in the provider. I want to know if anyone has an opinion on ebgp multihop for external customers, and wether I should really have an expectation to be able to assign my prepends as suits my needs? Are there any conditions that could make this fail that I should be aware of? Mike- From rjs at eng.gxn.net Wed Jan 21 04:14:24 2009 From: rjs at eng.gxn.net (Rob Shakir) Date: Wed, 21 Jan 2009 10:14:24 +0000 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <20090116125718.GB26415@bronze.eng.gxn.net> References: <20090116125718.GB26415@bronze.eng.gxn.net> Message-ID: <20090121101424.GB5577@bronze.eng.gxn.net> Hi, Further to the initial research sent to NANOG, after discussions with a number of operators, we have compiled some recommendations on the handling of invalid AS4_PATH attributes. Any feedback on these recommendations is appreciated: As discussed on the IETF IDR list last month, there are concerns relating to the treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0]. Since the last post to that thread the situation has been made more urgent with the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there is no alternative error handling defined in RFC4893. As posted last Friday [1], and discussed on the IDR list, this strict implementation introduces a new attack vector by which a BGP session can be torn down due to a an attribute populated by a distant BGP neighbour. These malformed attributes have already been seen in the wild as a result of a error in Juniper's implementation of RFC4893. Following discussions with a number of operators, we have attempted to generate some recommendations relating to the behaviour that would be operationally most useful when treating the invalid data in the AS4_PATH optional transitive attribute. There are two cases to consider when an invalid AS4_PATH is received: (1) A path to the prefix is not already known from that neighbour. (2) A path to the prefix has already been learnt from that neighbour; In case (1) we recommend that the BGP speaker should discard the UPDATE and log the fact. The log entry should include the received AS_PATH and AS4_PATH to aid in debugging. In case (2) we recommend that the BGP speaker should treat the UPDATE as a withdrawal of existing path to the prefix. As per case (1) a log entry should be raised to indicate that this has occurred. It is quite possible that in both cases this behaviour may result in the BGP speaker no longer having a valid path to the destination. We foresee that this lack of a prefix in a BGP speaker's routing table may cause some operational load initially, however, we feel that this is acceptable, considering the alternate behaviours. Should a prefix be injected into the global table with an invalid AS4_PATH, and should the newly advertised (invalid) path be selected by all upstreams available to a given ASN then this ASN will lose reachability to the prefix. Whilst this can be abused we do not see this as more serious than the existing possibility of malicious injection and blackholing of a prefix by a 3rd party. As long as the rejection of paths due to invalid AS4_PATHs is clearly reported to the administrator the source of the problem can be clearly identified. We consider that attempting to extract a valid AS4 or AS_PATH from the invalid UPDATE is a mistake since this allows the propagation of invalid BGP data. In addition, incorrect implementation of this comparatively complex mechanism by a vendor may result in loops. By explicitly not installing prefixes with invalid AS_PATH or AS4_PATH into the routing table, the possibility of loops caused by these invalid paths is avoided. The defined behaviour in RFC4893 and RFC4271 has significantly harmful effects and it seems only by virtue of the fact that the implementations of many vendors do not strictly comply with the RFCs that this problem has not had the same impact for every vendor. At the current time, however, one cannot deploy a 4-byte capable Cisco IOS device, or an OpenBGP (current stable release) router into the global table, without risking teardown of a every session via which a global table is learnt. Further discussion of this issue would be much appreciated, as a common and consistent approach to rectifying the problem will benefit network operators far more than individual vendor implementing their own solution. Should a consensus be reached an update to the RFC is required in order to ensure that future implementations do not exhibit this harmful behaviour. Kind regards, Andy Davidson (NetSumo), andy.davidson at netsumo.com Jonathan Oddy (HostWay), jonathan.oddy at hostway.co.uk Rob Shakir (GX Networks), rjs at eng.gxn.net [0]: http://www.ietf.org/mail-archive/web/idr/current/msg03368.html [1]: http://www.merit.edu/mail.archives/nanog/msg14345.html Many thanks to David Freedman (Claranet) for assistance in developing the recommendations in this document. From tjc at ecs.soton.ac.uk Wed Jan 21 05:29:49 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 21 Jan 2009 11:29:49 +0000 Subject: Inauguration streaming traffic In-Reply-To: <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> References: <497607E8.9070107@west.net> <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> Message-ID: <20090121112949.GF19720@login.ecs.soton.ac.uk> On Tue, Jan 20, 2009 at 12:38:11PM -0500, Christopher Morrow wrote: > On Tue, Jan 20, 2009 at 12:26 PM, Brian Wallingford wrote: > > On Tue, 20 Jan 2009, Jay Hennigan wrote: > > > > :We're a regional ISP, about 80% SMB 20% residential. We're seeing > > :almost double our normal downstream traffic right now. Anyone else? > > > > We're seeing traffic levels nearly 2x normal. On 9/11/01, we were > > probably only about 50% higher than the norm. Of course, lots has > > changed, so that's probably not a fair comparison. > > As an aside... thanks to BBC for streaming this, I couldn't find > another source that wasn't overloaded/jerky/ugly :( The Beeb's HD multicast feed is about 23Mbit/s to the host, and we received it at quite decent (subjective) quality here on a JANET-connected university site. The feed runs continuously (as far as any 'as-is' test stream does :) and this morning is pretty flawless. The interesting aspect of the HD stream was seeing how various systems coped with the CPU load. It was good to have some HD content available that encouraged people to install vlc, find out a little about multicast, and system issues in receiving it. Thanks again Beeb :) -- Tim From stu at spacehopper.org Wed Jan 21 05:43:05 2009 From: stu at spacehopper.org (Stuart Henderson) Date: Wed, 21 Jan 2009 11:43:05 +0000 (UTC) Subject: DNS Amplification attack? References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> <4976858D.3080705@visp.net> <75cb24520901201821s3ce653bbk20efaa4d86a4a8f@mail.gmail.com> <49768A07.7060105@visp.net> Message-ID: On 2009-01-21, Kameron Gasso wrote: > Christopher Morrow wrote: >> a point to bear in mind here is that... 'its working' is good enough >> for the bad folks :( no need to optimize when this works. Also, it's >> likely this isn't all of the problem the spoofed requestors are seeing >> these past few days :( > > Unfortunately, I can't restrict traffic to/from my authoritative > nameservers like I can with my recursive ones, since it will break DNS > resolution for outside visitors to domains we host. > > Fortunately, the spoofed queries are 60 bytes and my REFUSED responses > are only 59, so it's a terribly inefficient way to DoS someone. > However, I never said that the DDoS kiddies were smart - doesn't seem to > be stopping them from trying. :( > > Thanks, For you, yes. In many cases, there's either no amplification or a small decrease in traffic (though it makes it hard to shut off the true source). In a few cases (e.g. tinydns), there's no response, so the attackers traffic is wasted. But what about the people that happen to have misconfigured their authoritative DNS servers so that they're answering recursive queries from the world? 60 -> 520 bytes isn't bad, and I bet it's not _that_ uncommon... From jlewis at lewis.org Wed Jan 21 07:17:24 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 21 Jan 2009 08:17:24 -0500 (EST) Subject: expectations for bgp peering? In-Reply-To: <4976B1CB.2030600@tiedyenetworks.com> References: <4976B1CB.2030600@tiedyenetworks.com> Message-ID: On Tue, 20 Jan 2009, mike wrote: > So I am just wondering what my expecations should be in a bgp peering > scenario where I am multihomed with my own ASN and arin assigned ip space. At > issue is the fact that my backup isp forced me to use ebgp multihop to peer > with a router internal to their network and not the border router I am > directly attached to, and secondly, that they say I am not allowed to prepend > at all - they will do it for me, and from the looks of things they have > established a route-map that just prepends their AS 6 times to my > announcement. Assuming you're getting full routes from this provider, I wouldn't be surprised if the multihop is required because their router you're connected to doesn't have or can't handle full BGP routes. I've done this with customers in the past when they were connected to routers that didn't have the RAM for full routes. As for the "you're not allowed to prepend" thing, have you experimented to see what happens if you try? Unless they're giving you special pricing based on the idea that they're providing you with strictly backup transit, they shouldn't be doing the prepending (unless you've asked them to or used communities to tell them to). > This smells of bad engineering. I have looked up the bgp report for my > provider and they have 0 downstream AS's, and the week that this project has > taken (and it's still not up and working) has left me with less than absolute > confidence in the provider. I want to know if anyone has an opinion on ebgp Only a week? I've seen BGP turnups take much longer...not that they should. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From davec at columbia.edu Wed Jan 21 07:45:22 2009 From: davec at columbia.edu (David Coulthart) Date: Wed, 21 Jan 2009 08:45:22 -0500 Subject: DNS Amplification attack? In-Reply-To: <20090120233128.GI15562@isc.org> References: <86A39458-2A2B-45D7-8968-811AAFF422A8@bsdboy.com> <20090120233128.GI15562@isc.org> Message-ID: <8A7093C2-3C15-48D5-B269-F87B7A1C7118@columbia.edu> On Jan 20, 2009, at 6:31 PM, David W. Hankins wrote: > On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote: >> Anyone else noticing "." requests coming in to your DNS servers? >> >> http://isc.sans.org/diary.html?storyid=5713 > > I was surprised to see 'amplification' in the subject line here, since > on my nameservers my replies are of equal length to the queries. A > little bit of asking around, and I see that it is an amplification > attack, preying on old software. > > Let me sum up; > > If you're running 9.4 or later, you will reply to these packets with > 45 octet RCODE:Refused replies. 1:1. 9.4 has an "allow-query-cache" > directive that defaults to track allow-recursion, which you should > have set appropriately. After reading this thread, I decided it was prudent to test my authoritative nameservers & was surprised to discover I could retrieve cached records from my nameserver even though I have "recursion no;" in my options stanza in named.conf. Re-reading the ARM, I see that behavior is expected. But is there some reason not to set "allow- recursion { none; };" since I already have recursion disabled? Thanks, Dave Coulthart From smb at cs.columbia.edu Wed Jan 21 08:09:48 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 21 Jan 2009 09:09:48 -0500 Subject: WSJ on things to do in Santo Domingo Message-ID: <20090121090948.61fdf642@cs.columbia.edu> http://online.wsj.com/article/SB123240330058595471.html -- no idea if you have to be a subscriber or not. --Steve Bellovin, http://www.cs.columbia.edu/~smb From warren at kumari.net Wed Jan 21 08:21:27 2009 From: warren at kumari.net (Warren Kumari) Date: Wed, 21 Jan 2009 09:21:27 -0500 Subject: expectations for bgp peering? In-Reply-To: <4976B1CB.2030600@tiedyenetworks.com> References: <4976B1CB.2030600@tiedyenetworks.com> Message-ID: <4D539378-BCCC-4510-8CEF-44DC27781089@kumari.net> On Jan 21, 2009, at 12:25 AM, mike wrote: > Hello, > > So I am just wondering what my expecations should be in a bgp > peering scenario where I am multihomed with my own ASN and arin > assigned ip space. At issue is the fact that my backup isp forced me > to use ebgp multihop to peer with a router internal to their network > and not the border router I am directly attached to, and secondly, > that they say I am not allowed to prepend at all - they will do it > for me, and from the looks of things they have established a route- > map that just prepends their AS 6 times to my announcement. Hmmm, this is distinctly unusual. I'd suspect that the person that you are talking to is a: very new to BGP and is just applying the wrong canned route-map or b: the person is a little less new to BGP and has reached the "Oooh, now I know that I'm doing and can twiddle the knobs with the best of them" stage. I'd suggest trying to find someone else there to talk to.... Unless you have specifically bought the service as a "backup" service (and they are clumsily (and poorly) trying to make sure that you don't use it as your primary path) I cannot think of why your ISP would do this. This also seems a bit worrying -- either they have enough capacity to carry your traffic when you need them to (and so should be happy to let you use them and bill you for the bits) or they don't and you will be unhappy when your primary goes away. Are they really really cheap? If you need a "backup" ISP for regulatory reasons and don't really care, thats fine. If however you want good performance when your primary goes away, I'd suggest looking into this more... > > > This smells of bad engineering. I have looked up the bgp report > for my provider and they have 0 downstream AS's, Yeah, that is worrying.... > and the week that this project has taken (and it's still not up and > working) has left me with less than absolute confidence in the > provider. I want to know if anyone has an opinion on ebgp multihop > for external customers, and wether I should really have an > expectation to be able to assign my prepends as suits my needs? While multihop is not in itself an issue, it does give one pause and it is worth finding out the reason. But, yes, you should expect to be able to prepend at will... W > Are there any conditions that could make this fail that I should be > aware of? > > Mike- > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2173 bytes Desc: not available URL: From patrick at ianai.net Wed Jan 21 09:13:14 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 21 Jan 2009 10:13:14 -0500 Subject: expectations for bgp peering? In-Reply-To: References: <4976B1CB.2030600@tiedyenetworks.com> Message-ID: <5CC5E40C-4889-4E2F-834A-01862A0F62C6@ianai.net> On Jan 21, 2009, at 8:17 AM, Jon Lewis wrote: > As for the "you're not allowed to prepend" thing, have you > experimented to see what happens if you try? Unless they're giving > you special pricing based on the idea that they're providing you > with strictly backup transit, they shouldn't be doing the prepending > (unless you've asked them to or used communities to tell them to). See, this is why I like NANOG. Many eyes see things one pair does not. Hadn't even occurred to me that they were giving you special "backup transit only" pricing. In that case, makes perfect sense to force multiple prepends on their side. Thanx Jon. -- TTFN, patrick From brandon at rd.bbc.co.uk Wed Jan 21 09:24:31 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 21 Jan 2009 15:24:31 GMT Subject: Inauguration streaming traffic Message-ID: <200901211524.PAA14013@sunf10.rd.bbc.co.uk> > The Beeb's HD multicast feed is about 23Mbit/s to the host, and we received > it at quite decent (subjective) quality here on a JANET-connected university > site. This is full broadcast HD, exactly the same as we have on satellite. We don't consider it generally usable, it's part of IPTV services not general Internet distribution. I expect we'll make a 1.5Mbit/s stream, not really HD just what people flog as Internet HD, some time. > The interesting aspect of the HD stream was seeing how various systems coped > with the CPU load. It was good to have some HD content available that > encouraged people to install vlc, find out a little about multicast, and > system issues in receiving it. That's why I leave it there but unpublicised as users would try getting it down their adsl and annoy their ISP. > Thanks again Beeb :) /me doffs cap brandon From jmaimon at ttec.com Wed Jan 21 09:38:21 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 21 Jan 2009 10:38:21 -0500 Subject: expectations for bgp peering? In-Reply-To: References: <4976B1CB.2030600@tiedyenetworks.com> Message-ID: <4977416D.5020806@ttec.com> Jon Lewis wrote: > On Tue, 20 Jan 2009, mike wrote: > > Assuming you're getting full routes from this provider, I wouldn't be > surprised if the multihop is required because their router you're > connected to doesn't have or can't handle full BGP routes. There is a fairly large Tier 1 US provider who does exactly this. I imagine that this allows them to build out their network using cheap L3 (think 3550's or even 3560's) switches for their customer interfaces with a few "route servers" in core pops and a number of beefy border routers. From adrian at creative.net.au Wed Jan 21 10:07:34 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Jan 2009 01:07:34 +0900 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> Message-ID: <20090121160733.GA21304@skywalker.creative.net.au> On Wed, Jan 21, 2009, Patrick W. Gilmore wrote: > Google is not the only company which will put caches into any provider > - or school (which is really just a special case provider) - with > enough traffic. A school with 30 machines probably would not > qualify. This is not being mean, this is just being rational. No way > those 30 machines save the company enough money to pay for the caches. > > Again, sux, but that's life. I'd love to hear your solution - besides > writing "magic" into squid to intentionally break or alter (some would > use much harsher language) content you do not own. Content others are > providing for free. Finding ways to force object revalidation by an intermediary cache (so the end origin server knows something has been fetched) and thus allowing the cache to serve the content on behalf of the content origintor, under their full control, but without the bits being served. I'm happy to work with content providers if they'd like to point out which bits of HTTP design and implementation fail them (eg, issues surrounding Variant object caching and invalidation/revalidation) and get them fixed in a public manner in Squid so it -can- be deployed by people to save on bandwidth in places where it still matters. Adrian From hcb at netcases.net Wed Jan 21 10:39:19 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Wed, 21 Jan 2009 11:39:19 -0500 (EST) Subject: expectations for bgp peering? In-Reply-To: <5CC5E40C-4889-4E2F-834A-01862A0F62C6@ianai.net> References: <4976B1CB.2030600@tiedyenetworks.com> <5CC5E40C-4889-4E2F-834A-01862A0F62C6@ianai.net> Message-ID: <4111.76.118.12.107.1232555959.squirrel@webmail9.pair.com> Patrick W. Gilmore wrote: > On Jan 21, 2009, at 8:17 AM, Jon Lewis wrote: > >> As for the "you're not allowed to prepend" thing, have you >> experimented to see what happens if you try? Unless they're giving >> you special pricing based on the idea that they're providing you >> with strictly backup transit, they shouldn't be doing the prepending >> (unless you've asked them to or used communities to tell them to). > > See, this is why I like NANOG. Many eyes see things one pair does not. > > Hadn't even occurred to me that they were giving you special "backup > transit only" pricing. In that case, makes perfect sense to force > multiple prepends on their side. > Good insight, Patrick. If I might suggest a point or two, it's that there's more than one "expectation" here, or perhaps should be: 1. Expectation on protocol/policy behavior 2. Expectation on service delivery and economics If breaking #1 doesn't break the basic functionality, but does achieve something under #2, it's worth clarifying. If #1 doesn't improve #2, there's a legitimate gripe. Means and ends aren't always locked together. > From jcdill.lists at gmail.com Wed Jan 21 10:44:07 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 21 Jan 2009 08:44:07 -0800 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> Message-ID: <497750D7.3020500@gmail.com> Patrick W. Gilmore wrote: > > I do not work for GOOG or YouTube, I do not know why they do what they > do. However, it is trivial to think up perfectly valid reasons for > Google to intentionally break caches on YouTube content (e.g. paid > advertising per download). > > Doesn't matter if you have small links or no infrastructure or > whatever. Google has ever right, moral & legal, to serve content as > they please. They are providing the content for free, but they want > to do it on their own terms. Seems perfectly reasonable to me. Do > you disagree? This brings me back the peering problem - if network A's customer sends network B's server a small packet, and network B's server sends back a video, why should Network A be forced to pay the lion's share of the bandwidth costs to deliver Network B's video (and ads) to the viewer? Networks which send large amounts of content should do their best to reduce the bandwidth load on end-user networks whenever and where ever possible, by hot-potato routing, by allowing the content to be cached, etc. They can't do otherwise and also claim they "do no harm". Adrian, what did your contacts at Google say when you asked them how this policy was consistent with their Do No Harm motto? If you didn't ask, I suggest you go ask! jc From neito at nerdramblingz.com Wed Jan 21 10:46:55 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Wed, 21 Jan 2009 11:46:55 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <497750D7.3020500@gmail.com> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <497750D7.3020500@gmail.com> Message-ID: > policy was consistent with their Do No Harm motto? Google's motto is Do No Evil, not Do No Harm. From Jay.Murphy at state.nm.us Wed Jan 21 11:06:58 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 21 Jan 2009 10:06:58 -0700 Subject: Traffic metrics and cost analysis.... Message-ID: Hey all, Can anyone point to a good power-point template/presentation for metric and cost analysis for routing? I will not plagiarize unless; I am given copyright permission :-). Seriously, anyone have one handy, I am under the press to complete a presentation before Friday morning. Thanks a million, Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa F?, New M?xico 87502 "We move the information that moves your world." Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From graeme at graemef.net Wed Jan 21 11:08:12 2009 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 21 Jan 2009 17:08:12 +0000 Subject: isprime DOS in progress In-Reply-To: <20090120205514.GA10257@fries.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> Message-ID: <1232557692.9593.57.camel@squonk.lboro.ac.uk> On Tue, 2009-01-20 at 14:55 -0600, Todd T. Fries forwarded: > From: ISPrime Support > These are the result of a spoofed dns recursion attack against our servers. The actual packets in question (the ones reaching your servers) do NOT originate from our network as such there is no way for us to filter things from our end. > If you are receiving queries from 76.9.31.42/76.9.16.171 neither of these machines make legitimate outbound dns requests so an inbound filter of packets to udp/53 from either of these two sources is perfect. > If you are receiving queries from 66.230.128.15/66.230.160.1 these servers are authoritative nameservers. Please do not blackhole either of these IPs as they host many domains. However, these IPs do not make outbound DNS requests so filtering requests to your IPs from these ips with a destination port of 53 should block any illegitimate requests. I've been seeing a lot of noise from the latter two addresses after switching on query logging (and finishing an application of Team Cymru's excellent template) so I decided to DROP traffic from the addresses (with source port != 53) at the hosts in question. Well, blow me down if they didn't completely stop talking to me. Four dropped packets each, and they've gone away. Something smells "not quite right" here - if the traffic is spoofed, and my "Refused" responses have been flying right back to the *real* IP addresses, how are the spoofing hosts to know that I'm dropping the traffic? Even if I used a REJECT policy, I'd expect the ICMP messages to go back to the appropriate - as in real - hosts, rather than the spoofing sources. Something here is very odd, very odd indeed... or I'm being dumb. It's happened before. Graeme From enkechen at cisco.com Wed Jan 21 11:24:34 2009 From: enkechen at cisco.com (Enke Chen) Date: Wed, 21 Jan 2009 09:24:34 -0800 Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH In-Reply-To: <20090121101424.GB5577@bronze.eng.gxn.net> References: <20090116125718.GB26415@bronze.eng.gxn.net> <20090121101424.GB5577@bronze.eng.gxn.net> Message-ID: <49775A52.6060103@cisco.com> Hi, folks: We (IDR Chairs and co-authors) are working on updating RFC 4893 regarding the handling of the confed related segments in the AS4_PATH attribute. Expect to have the revised draft this week. Thanks. -- Enke Rob Shakir wrote: > Hi, > > Further to the initial research sent to NANOG, after discussions with a number > of operators, we have compiled some recommendations on the handling of invalid > AS4_PATH attributes. > > Any feedback on these recommendations is appreciated: > > As discussed on the IETF IDR list last month, there are concerns relating to the > treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0]. > Since the last post to that thread the situation has been made more urgent with > the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH > attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP > adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there > is no alternative error handling defined in RFC4893. As posted last Friday [1], > and discussed on the IDR list, this strict implementation introduces a new > attack vector by which a BGP session can be torn down due to a an attribute > populated by a distant BGP neighbour. These malformed attributes have already > been seen in the wild as a result of a error in Juniper's implementation of > RFC4893. > > Following discussions with a number of operators, we have attempted to generate > some recommendations relating to the behaviour that would be operationally most > useful when treating the invalid data in the AS4_PATH optional transitive > attribute. > > There are two cases to consider when an invalid AS4_PATH is received: > (1) A path to the prefix is not already known from that neighbour. > (2) A path to the prefix has already been learnt from that neighbour; > > In case (1) we recommend that the BGP speaker should discard the UPDATE and log > the fact. The log entry should include the received AS_PATH and > AS4_PATH to aid in debugging. > > In case (2) we recommend that the BGP speaker should treat the UPDATE as a > withdrawal of existing path to the prefix. As per case (1) a log entry should be > raised to indicate that this has occurred. > > It is quite possible that in both cases this behaviour may result in the BGP > speaker no longer having a valid path to the destination. We foresee that this > lack of a prefix in a BGP speaker's routing table may cause some operational > load initially, however, we feel that this is acceptable, considering the > alternate behaviours. > > Should a prefix be injected into the global table with an invalid AS4_PATH, and > should the newly advertised (invalid) path be selected by all upstreams > available to a given ASN then this ASN will lose reachability to the prefix. > Whilst this can be abused we do not see this as more serious than the existing > possibility of malicious injection and blackholing of a prefix by a 3rd party. > As long as the rejection of paths due to invalid AS4_PATHs is clearly reported > to the administrator the source of the problem can be clearly identified. > > We consider that attempting to extract a valid AS4 or AS_PATH from the invalid > UPDATE is a mistake since this allows the propagation of invalid BGP data. In > addition, incorrect implementation of this comparatively complex mechanism by a > vendor may result in loops. By explicitly not installing prefixes with invalid > AS_PATH or AS4_PATH into the routing table, the possibility of loops caused by > these invalid paths is avoided. > > The defined behaviour in RFC4893 and RFC4271 has significantly harmful effects > and it seems only by virtue of the fact that the implementations of many vendors > do not strictly comply with the RFCs that this problem has not had the same > impact for every vendor. At the current time, however, one cannot deploy a > 4-byte capable Cisco IOS device, or an OpenBGP (current stable release) router > into the global table, without risking teardown of a every session via which a > global table is learnt. > > Further discussion of this issue would be much appreciated, as a common and > consistent approach to rectifying the problem will benefit network operators far > more than individual vendor implementing their own solution. Should a consensus > be reached an update to the RFC is required in order to ensure that future > implementations do not exhibit this harmful behaviour. > > Kind regards, > Andy Davidson (NetSumo), andy.davidson at netsumo.com > Jonathan Oddy (HostWay), jonathan.oddy at hostway.co.uk > Rob Shakir (GX Networks), rjs at eng.gxn.net > > [0]: http://www.ietf.org/mail-archive/web/idr/current/msg03368.html > [1]: http://www.merit.edu/mail.archives/nanog/msg14345.html > > Many thanks to David Freedman (Claranet) for assistance in developing the > recommendations in this document. > > > > > > From pr at isprime.com Wed Jan 21 11:27:48 2009 From: pr at isprime.com (Phil Rosenthal) Date: Wed, 21 Jan 2009 12:27:48 -0500 Subject: isprime DOS in progress In-Reply-To: <1232557692.9593.57.camel@squonk.lboro.ac.uk> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> Message-ID: Hello, Representing ISPrime here. This attack has been ongoing on 66.230.128.15/66.230.160.1 for about 24 hours now, and we are receiving roughly 5Gbit of attack packets from roughly 750,000 hosts. It's somewhat absurd to suggest that we are attacking our own nameservers, I assure you, we didn't spend many hours looking for your specific nameserver to start sending 10 requests per second for the root zone, and our nameservers serve many popular domains. Given the attack is still in progress, I can't really say much more publicly, but suffice to say, we're working on the situation. -Phil AS23393 On Jan 21, 2009, at 12:08 PM, Graeme Fowler wrote: > On Tue, 2009-01-20 at 14:55 -0600, Todd T. Fries forwarded: >> From: ISPrime Support >> These are the result of a spoofed dns recursion attack against our >> servers. The actual packets in question (the ones reaching your >> servers) do NOT originate from our network as such there is no way >> for us to filter things from our end. >> If you are receiving queries from 76.9.31.42/76.9.16.171 neither of >> these machines make legitimate outbound dns requests so an inbound >> filter of packets to udp/53 from either of these two sources is >> perfect. >> If you are receiving queries from 66.230.128.15/66.230.160.1 these >> servers are authoritative nameservers. Please do not blackhole >> either of these IPs as they host many domains. However, these IPs >> do not make outbound DNS requests so filtering requests to your IPs >> from these ips with a destination port of 53 should block any >> illegitimate requests. > > I've been seeing a lot of noise from the latter two addresses after > switching on query logging (and finishing an application of Team > Cymru's > excellent template) so I decided to DROP traffic from the addresses > (with source port != 53) at the hosts in question. > > Well, blow me down if they didn't completely stop talking to me. Four > dropped packets each, and they've gone away. > > Something smells "not quite right" here - if the traffic is spoofed, > and > my "Refused" responses have been flying right back to the *real* IP > addresses, how are the spoofing hosts to know that I'm dropping the > traffic? > > Even if I used a REJECT policy, I'd expect the ICMP messages to go > back > to the appropriate - as in real - hosts, rather than the spoofing > sources. > > Something here is very odd, very odd indeed... or I'm being dumb. It's > happened before. > > Graeme > > From jkrejci at usinternet.com Wed Jan 21 11:32:37 2009 From: jkrejci at usinternet.com (Justin Krejci) Date: Wed, 21 Jan 2009 11:32:37 -0600 Subject: isprime DOS in progress In-Reply-To: <1232557692.9593.57.camel@squonk.lboro.ac.uk> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com><20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> Message-ID: <72677514A6C1417EA85D7C5F74888866@usicorp.usinternet.com> -----Original Message----- From: Graeme Fowler [mailto:graeme at graemef.net] Sent: Wednesday, January 21, 2009 11:08 AM To: Nanog Mailing list Subject: Re: isprime DOS in progress > I've been seeing a lot of noise from the latter two addresses after > switching on query logging (and finishing an application of Team Cymru's > excellent template) so I decided to DROP traffic from the addresses > (with source port != 53) at the hosts in question. > Well, blow me down if they didn't completely stop talking to me. Four > dropped packets each, and they've gone away. > Something smells "not quite right" here - if the traffic is spoofed, and > my "Refused" responses have been flying right back to the *real* IP > addresses, how are the spoofing hosts to know that I'm dropping the > traffic? > > Even if I used a REJECT policy, I'd expect the ICMP messages to go back > to the appropriate - as in real - hosts, rather than the spoofing > sources. > > Something here is very odd, very odd indeed... or I'm being dumb. It's > happened before. > > Graeme In looking at my query logs I am seeing only requests from 66.230.160.1 and 66.230.128.15 so I've done the same thing with iptables and the rules are resulting in an ever growing number of packets being dropped. # iptables -nvL | grep -F -B 1 -A 1 66.230.160.1 | awk '{ print $1,$2,$3,$8,$10,$11,$12 }' pkts bytes target source 49517 2228K DROP 66.230.160.1 udp spt:!53 dpt:53 35905 1616K DROP 66.230.128.15 udp spt:!53 dpt:53 From irish.masms at gmail.com Wed Jan 21 12:08:57 2009 From: irish.masms at gmail.com (Irish) Date: Wed, 21 Jan 2009 11:08:57 -0700 Subject: 2 services have disappeared In-Reply-To: <734770.96585.qm@web82903.mail.mud.yahoo.com> References: <734770.96585.qm@web82903.mail.mud.yahoo.com> Message-ID: <2558d5bd0901211008o306870c6h82946f337f62f1f5@mail.gmail.com> On Sat, Jan 17, 2009 at 11:47 AM, Henry Linneweh wrote: > http://www.networkthinktank.com/ > http://www.completewhois.com > > are there any replacement services for these vanished services? > > -henry > I have been using http://www.robtex.com/ with success. -- Timothy G. O'Brien, CISSP, GSEC, NSA-IAM Irish dot MASMS at gmail dot com HTTP://www.linkedin.com/in/obrientg [snipped - FAQ for email trimming: http://kimihia.org.nz/articles/email/] Discussion Groups: http://www.hoax-slayer.com/discussion-groups.html Discussion List Etiquette: http://www.acfichapter.com/subscribe.htm Properly Formatted Email Replies for the Lazy: http://email.about.com/cs/netiquettetips/qt/et052704.htm Mailing List Etiquette FAQ: http://www.gweep.ca/~edmonds/usenet/ml-etiquette.html RFC 1855: Netiquette Guidelines: http://www.faqs.org/rfcs/rfc1855.html Miss Mailers Answers Your Questions on Mailing Lists: http://www.faqs.org/faqs/mail/miss-mailers/ and of course the all knowing Google: http://www.google.com/search?hl=en&q=mailing+list+etiquette ---------------------------------------------- A: No. Q: Should I include e-mail quotations after my reply? ===================================================== An often repeated quote on news.admin.net-abuse.email: "Spam is not about content, it is about consent". From dlc at lampinc.com Wed Jan 21 12:19:41 2009 From: dlc at lampinc.com (Dale Carstensen) Date: Wed, 21 Jan 2009 11:19:41 -0700 Subject: isprime DOS in progress, and Re: DNS Amplification attack? In-Reply-To: <72677514A6C1417EA85D7C5F74888866@usicorp.usinternet.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <72677514A6C1417EA85D7C5F74888866@usicorp.usinternet.com> Message-ID: <20090121181848.35FAE38D600@lampinc.com> Can't some upstream provider find a source of the DNS NS . questions that is other than isprime? From lists at die.net Wed Jan 21 12:21:23 2009 From: lists at die.net (Aaron Hopkins) Date: Wed, 21 Jan 2009 10:21:23 -0800 (PST) Subject: isprime DOS in progress In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> Message-ID: On Wed, 21 Jan 2009, Phil Rosenthal wrote: > This attack has been ongoing on 66.230.128.15/66.230.160.1 for about 24 hours > now, and we are receiving roughly 5Gbit of attack packets from roughly > 750,000 hosts. I'm only receiving NS queries for "." from spoofed 66.230.128.15 and 66.230.160.1 via above.net (of my three transit providers) and none from peering. This usually indicates a single source, such as one rooted machine on non-BCP38 net spewing most of a gigabit. > Given the attack is still in progress, I can't really say much more publicly, > but suffice to say, we're working on the situation. Have you had any luck tracking back the source of the spoofed packets? If me talking to above.net sounds useful, let me know. -- Aaron From chk at pobox.com Wed Jan 21 12:24:22 2009 From: chk at pobox.com (Harald Koch) Date: Wed, 21 Jan 2009 13:24:22 -0500 Subject: isprime DOS in progress In-Reply-To: <1232557692.9593.57.camel@squonk.lboro.ac.uk> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> Message-ID: <49776856.7030902@pobox.com> Graeme Fowler wrote: > On Tue, 2009-01-20 at 14:55 -0600, Todd T. Fries forwarded: > I've been seeing a lot of noise from the latter two addresses after > switching on query logging (and finishing an application of Team Cymru's > excellent template) so I decided to DROP traffic from the addresses > (with source port != 53) at the hosts in question. > > Well, blow me down if they didn't completely stop talking to me. Four > dropped packets each, and they've gone away. > I've seen that behaviour in the past, but not this time? I've seen a few of these attacks bouncing off my nameservers recently, and when I add "DROP" rules to my firewall, the incoming traffic disappears soon after. But the most recent set (66.230.160.1 and 66.230.128.15) are still hammering away... -- Harald From beckman at angryox.com Wed Jan 21 12:29:35 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 21 Jan 2009 13:29:35 -0500 Subject: inauguration streams review In-Reply-To: <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> Message-ID: On Tue, 20 Jan 2009, Jack Carrozzo wrote: > Cell networks held up reasonably well for voice, though SMS and MMS > delivery times approached an hour during the event. Switch load in > almost the entire US was higher than midnight on New Years (which is > generally the highest load of the year). > > Our network has been preparing since June, and I assume likewise for others. Unfortunately for me Sprint did not seem to prepare or have enough capacity for Voice, SMS or Data access. No live Twitter blogging! While I was able to get a few (maybe 5 between 10am and 2pm) text messages out while standing near the Washington Monument, calls and data were an impossibility, and SMS only seemed to have capacity available during lulls in the Inaugural activity. It was disappointing as a customer -- I'm sure that, had the capacity been there, the revenue from that single event would have made a significant impact on any of the carrier's revenue, at least for the month. > -Jack Carrozzo > (Engineer at $large cell company whose policy doesn't allow me to specify) (Google spills the beans!) I'm curious if you can find out -- did the record traffic positively affect revenue for that period compared to last year at the same time, or even last week on the same day? And from a more technical standpoint, did your $large cell company put up temporary towers? I'm curious as to how your company added capacity to handle the event, as well as how many "Network Busy" messages customers got, if any. I know I got more of those messages than I did successful communications. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jack at crepinc.com Wed Jan 21 12:49:44 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 21 Jan 2009 13:49:44 -0500 Subject: inauguration streams review In-Reply-To: References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> Message-ID: <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> I can't comment on revenue-generation, though access as a whole was quite high. We hardly had any voice IAs (Ineffective Attempts, or 'Busy' messages). Since data can be queued, the only thing that would cause data IAs are bad RF conditions - we had a TON of 'cell on wheels' in the area for the event so we had enough carrier space to cover it. In-network data response times were hardly affected, with switch loads well below 50%. In-network SMS were still getting to their destinations in under 5 seconds for the most part.... I don't have any numbers on MMS or mobile IP data at the moment, though I would have heard if something horrible had happened. I'm told that the out-of-network SMS queue was piling pretty high at one point, to delivery times up to an hour, though they all still got there. We can't control other network's switches obviously. This isn't trying to sound like an advertisement - *I'm* not affected either way if people sign up with us as I'm not in sales, however from my point of view it looks like we had the most solid network... Our guys were planning and setting things up since June. Cheers, -Jack Carrozzo On Wed, Jan 21, 2009 at 1:29 PM, Peter Beckman wrote: > On Tue, 20 Jan 2009, Jack Carrozzo wrote: > >> Cell networks held up reasonably well for voice, though SMS and MMS >> delivery times approached an hour during the event. Switch load in >> almost the entire US was higher than midnight on New Years (which is >> generally the highest load of the year). >> >> Our network has been preparing since June, and I assume likewise for >> others. > > Unfortunately for me Sprint did not seem to prepare or have enough > capacity for Voice, SMS or Data access. No live Twitter blogging! > > While I was able to get a few (maybe 5 between 10am and 2pm) text messages > out while standing near the Washington Monument, calls and data were an > impossibility, and SMS only seemed to have capacity available during lulls > in the Inaugural activity. > > It was disappointing as a customer -- I'm sure that, had the capacity been > there, the revenue from that single event would have made a significant > impact on any of the carrier's revenue, at least for the month. > >> -Jack Carrozzo >> (Engineer at $large cell company whose policy doesn't allow me to specify) > > (Google spills the beans!) I'm curious if you can find out -- did the > record traffic positively affect revenue for that period compared to last > year at the same time, or even last week on the same day? > > And from a more technical standpoint, did your $large cell company put up > temporary towers? I'm curious as to how your company added capacity to > handle the event, as well as how many "Network Busy" messages customers > got, if any. I know I got more of those messages than I did successful > communications. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From mike.lyon at gmail.com Wed Jan 21 12:52:09 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 21 Jan 2009 10:52:09 -0800 Subject: inauguration streams review In-Reply-To: <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> Message-ID: <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> How many simultaneous connections can each COW handle? What kind of backhaul connections do they have? -Mike On Wed, Jan 21, 2009 at 10:49 AM, Jack Carrozzo wrote: > I can't comment on revenue-generation, though access as a whole was quite > high. > > We hardly had any voice IAs (Ineffective Attempts, or 'Busy' > messages). Since data can be queued, the only thing that would cause > data IAs are bad RF conditions - we had a TON of 'cell on wheels' in > the area for the event so we had enough carrier space to cover it. > > In-network data response times were hardly affected, with switch loads > well below 50%. In-network SMS were still getting to their > destinations in under 5 seconds for the most part.... I don't have any > numbers on MMS or mobile IP data at the moment, though I would have > heard if something horrible had happened. > > I'm told that the out-of-network SMS queue was piling pretty high at > one point, to delivery times up to an hour, though they all still got > there. We can't control other network's switches obviously. > > This isn't trying to sound like an advertisement - *I'm* not affected > either way if people sign up with us as I'm not in sales, however from > my point of view it looks like we had the most solid network... Our > guys were planning and setting things up since June. > > Cheers, > > -Jack Carrozzo > > On Wed, Jan 21, 2009 at 1:29 PM, Peter Beckman > wrote: > > On Tue, 20 Jan 2009, Jack Carrozzo wrote: > > > >> Cell networks held up reasonably well for voice, though SMS and MMS > >> delivery times approached an hour during the event. Switch load in > >> almost the entire US was higher than midnight on New Years (which is > >> generally the highest load of the year). > >> > >> Our network has been preparing since June, and I assume likewise for > >> others. > > > > Unfortunately for me Sprint did not seem to prepare or have enough > > capacity for Voice, SMS or Data access. No live Twitter blogging! > > > > While I was able to get a few (maybe 5 between 10am and 2pm) text > messages > > out while standing near the Washington Monument, calls and data were an > > impossibility, and SMS only seemed to have capacity available during > lulls > > in the Inaugural activity. > > > > It was disappointing as a customer -- I'm sure that, had the capacity > been > > there, the revenue from that single event would have made a significant > > impact on any of the carrier's revenue, at least for the month. > > > >> -Jack Carrozzo > >> (Engineer at $large cell company whose policy doesn't allow me to > specify) > > > > (Google spills the beans!) I'm curious if you can find out -- did the > > record traffic positively affect revenue for that period compared to > last > > year at the same time, or even last week on the same day? > > > > And from a more technical standpoint, did your $large cell company put > up > > temporary towers? I'm curious as to how your company added capacity to > > handle the event, as well as how many "Network Busy" messages customers > > got, if any. I know I got more of those messages than I did successful > > communications. > > > > Beckman > > > --------------------------------------------------------------------------- > > Peter Beckman Internet > Guy > > beckman at angryox.com > http://www.angryox.com/ > > > --------------------------------------------------------------------------- > > > From pstewart at nexicomgroup.net Wed Jan 21 12:54:17 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 21 Jan 2009 13:54:17 -0500 Subject: inauguration streams review In-Reply-To: <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> References: <200901201924.n0KJOsLr032637@stark.hevanet.com><1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com><2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com><2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> Just curious on that note with COW .. did you have much security related problems setting up stuff nearby? -----Original Message----- From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Wednesday, January 21, 2009 1:52 PM To: Jack Carrozzo Cc: nanog at nanog.org Subject: Re: inauguration streams review How many simultaneous connections can each COW handle? What kind of backhaul connections do they have? -Mike On Wed, Jan 21, 2009 at 10:49 AM, Jack Carrozzo wrote: > I can't comment on revenue-generation, though access as a whole was quite > high. > > We hardly had any voice IAs (Ineffective Attempts, or 'Busy' > messages). Since data can be queued, the only thing that would cause > data IAs are bad RF conditions - we had a TON of 'cell on wheels' in > the area for the event so we had enough carrier space to cover it. > > In-network data response times were hardly affected, with switch loads > well below 50%. In-network SMS were still getting to their > destinations in under 5 seconds for the most part.... I don't have any > numbers on MMS or mobile IP data at the moment, though I would have > heard if something horrible had happened. > > I'm told that the out-of-network SMS queue was piling pretty high at > one point, to delivery times up to an hour, though they all still got > there. We can't control other network's switches obviously. > > This isn't trying to sound like an advertisement - *I'm* not affected > either way if people sign up with us as I'm not in sales, however from > my point of view it looks like we had the most solid network... Our > guys were planning and setting things up since June. > > Cheers, > > -Jack Carrozzo > > On Wed, Jan 21, 2009 at 1:29 PM, Peter Beckman > wrote: > > On Tue, 20 Jan 2009, Jack Carrozzo wrote: > > > >> Cell networks held up reasonably well for voice, though SMS and MMS > >> delivery times approached an hour during the event. Switch load in > >> almost the entire US was higher than midnight on New Years (which is > >> generally the highest load of the year). > >> > >> Our network has been preparing since June, and I assume likewise for > >> others. > > > > Unfortunately for me Sprint did not seem to prepare or have enough > > capacity for Voice, SMS or Data access. No live Twitter blogging! > > > > While I was able to get a few (maybe 5 between 10am and 2pm) text > messages > > out while standing near the Washington Monument, calls and data were an > > impossibility, and SMS only seemed to have capacity available during > lulls > > in the Inaugural activity. > > > > It was disappointing as a customer -- I'm sure that, had the capacity > been > > there, the revenue from that single event would have made a significant > > impact on any of the carrier's revenue, at least for the month. > > > >> -Jack Carrozzo > >> (Engineer at $large cell company whose policy doesn't allow me to > specify) > > > > (Google spills the beans!) I'm curious if you can find out -- did the > > record traffic positively affect revenue for that period compared to > last > > year at the same time, or even last week on the same day? > > > > And from a more technical standpoint, did your $large cell company put > up > > temporary towers? I'm curious as to how your company added capacity to > > handle the event, as well as how many "Network Busy" messages customers > > got, if any. I know I got more of those messages than I did successful > > communications. > > > > Beckman > > > ------------------------------------------------------------------------ --- > > Peter Beckman Internet > Guy > > beckman at angryox.com > http://www.angryox.com/ > > > ------------------------------------------------------------------------ --- > > > ---------------------------------------------------------------------------- "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." From jack at crepinc.com Wed Jan 21 13:01:59 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 21 Jan 2009 14:01:59 -0500 Subject: inauguration streams review In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> Message-ID: <2ad0f9f60901211101k57d902do43d8f46a3f2ece5d@mail.gmail.com> COWs are more or less full sites - so standard N concurrent voice calls per carrier (check out the CDMA standard if you're really interested), times the number of carriers. They can do 850+PCS all carrier if configured that way. If we can grab fiber from a nearby building that's best (hence why this takes so long to plan), however a lot of time we rely on OC3 microwave backhaul. I wasn't involved with the DC guys as I'm in Boston so I don't know specifics of this event. Re: security, I don't know since I wasn't involved though since all the planning started so far back I doubt there was much issue. -Jack Carrozzo On Wed, Jan 21, 2009 at 1:54 PM, Paul Stewart wrote: > Just curious on that note with COW .. did you have much security related > problems setting up stuff nearby? > > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Wednesday, January 21, 2009 1:52 PM > To: Jack Carrozzo > Cc: nanog at nanog.org > Subject: Re: inauguration streams review > > How many simultaneous connections can each COW handle? What kind of > backhaul > connections do they have? > > -Mike > > > On Wed, Jan 21, 2009 at 10:49 AM, Jack Carrozzo > wrote: > >> I can't comment on revenue-generation, though access as a whole was > quite >> high. >> >> We hardly had any voice IAs (Ineffective Attempts, or 'Busy' >> messages). Since data can be queued, the only thing that would cause >> data IAs are bad RF conditions - we had a TON of 'cell on wheels' in >> the area for the event so we had enough carrier space to cover it. >> >> In-network data response times were hardly affected, with switch loads >> well below 50%. In-network SMS were still getting to their >> destinations in under 5 seconds for the most part.... I don't have any >> numbers on MMS or mobile IP data at the moment, though I would have >> heard if something horrible had happened. >> >> I'm told that the out-of-network SMS queue was piling pretty high at >> one point, to delivery times up to an hour, though they all still got >> there. We can't control other network's switches obviously. >> >> This isn't trying to sound like an advertisement - *I'm* not affected >> either way if people sign up with us as I'm not in sales, however from >> my point of view it looks like we had the most solid network... Our >> guys were planning and setting things up since June. >> >> Cheers, >> >> -Jack Carrozzo >> >> On Wed, Jan 21, 2009 at 1:29 PM, Peter Beckman >> wrote: >> > On Tue, 20 Jan 2009, Jack Carrozzo wrote: >> > >> >> Cell networks held up reasonably well for voice, though SMS and MMS >> >> delivery times approached an hour during the event. Switch load in >> >> almost the entire US was higher than midnight on New Years (which > is >> >> generally the highest load of the year). >> >> >> >> Our network has been preparing since June, and I assume likewise > for >> >> others. >> > >> > Unfortunately for me Sprint did not seem to prepare or have enough >> > capacity for Voice, SMS or Data access. No live Twitter blogging! >> > >> > While I was able to get a few (maybe 5 between 10am and 2pm) text >> messages >> > out while standing near the Washington Monument, calls and data > were an >> > impossibility, and SMS only seemed to have capacity available > during >> lulls >> > in the Inaugural activity. >> > >> > It was disappointing as a customer -- I'm sure that, had the > capacity >> been >> > there, the revenue from that single event would have made a > significant >> > impact on any of the carrier's revenue, at least for the month. >> > >> >> -Jack Carrozzo >> >> (Engineer at $large cell company whose policy doesn't allow me to >> specify) >> > >> > (Google spills the beans!) I'm curious if you can find out -- did > the >> > record traffic positively affect revenue for that period compared > to >> last >> > year at the same time, or even last week on the same day? >> > >> > And from a more technical standpoint, did your $large cell company > put >> up >> > temporary towers? I'm curious as to how your company added > capacity to >> > handle the event, as well as how many "Network Busy" messages > customers >> > got, if any. I know I got more of those messages than I did > successful >> > communications. >> > >> > Beckman >> > >> > ------------------------------------------------------------------------ > --- >> > Peter Beckman > Internet >> Guy >> > beckman at angryox.com >> http://www.angryox.com/ >> > >> > ------------------------------------------------------------------------ > --- >> > >> > > > > > ---------------------------------------------------------------------------- > > "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." > From Crist.Clark at globalstar.com Wed Jan 21 13:23:47 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 21 Jan 2009 11:23:47 -0800 Subject: DNS Amplification attack? In-Reply-To: <200901210323.n0L3NWRf002868@drugs.dv.isc.org> References: Your message of "Wed, 21 Jan 2009 14:08:25 +1100." <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> <200901210323.n0L3NWRf002868@drugs.dv.isc.org> Message-ID: <497705BD.33E4.0097.0@globalstar.com> >>> On 1/20/2009 at 7:23 PM, Mark Andrews wrote: > In message <20090121140825.xwdzd4p64kgwo4go at web1.nswh.com.au>, > jay at miscreant.or > g writes: >> > On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso wro= >> te: >> >> > We're also seeing a great number of these, but the idiots spoofing the >> > queries are hitting several non-recursive nameservers we host - and only >> > generating 59-byte "REFUSED" replies. >> > >> > Looks like they probably just grabbed a bunch of DNS hosts out of WHOIS >> > and hoped that they were recursive resolvers. >> >> First post to this list, play nice :) >> >> Are you sure about this? I'm seeing these requests on /every/ =20 >> (unrelated) NS I have access to, which numbers several dozen, in =20 >> various countries across the world, and from various registries (.net, =20 >> .org, .com.au). The spread of servers I've checked is so random that =20 >> I'm wondering just how many NS records they've laid their hands on. >> >> I've also noticed that on a server running BIND 9.3.4-P1 with =20 >> recursion disabled, they're still appear to be getting the list of =20 >> root NS's from cache, which is a 272-byte response to a 61-byte =20 >> request, which by my definition is an amplification. > > BIND 9.3.4-P1 is past end-of-life. > > You need to properly set allow-query at both the option/view > level and at the zone level to prevent retrieving answers > from the cache in 9.3.x. > > option/view level "allow-query { trusted; };" > zone level "allow-query { any; };" > > BIND 9.4.x and later have allow-query-cache make the > configuration job easier. It also defaults to directly > connected networks. Another BIND-specific question since we're on the topic. I see some of our authorative servers being hit with these spoofs, and yes, the 9.3.5-P1 (that's what Sun supports in Solaris these days) were sending back answers from the cache... but wait... what cache? The view the Internet gets only has our authorative zones. There is no declaration for the root zone, master, slave, or hints. How does BIND have the root cached in that view? Where did it get it from? I guess it's hard coded somewhere? Blocking this in the firewall. 1:0 amplification better than the BIND fix, 1:1. But I'll get to the BIND fix anyway. From cmadams at hiwaay.net Wed Jan 21 13:27:11 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 Jan 2009 13:27:11 -0600 Subject: DNS Amplification attack? In-Reply-To: <497705BD.33E4.0097.0@globalstar.com> References: <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au> <200901210323.n0L3NWRf002868@drugs.dv.isc.org> <497705BD.33E4.0097.0@globalstar.com> Message-ID: <20090121192711.GG1239706@hiwaay.net> Once upon a time, Crist Clark said: > Another BIND-specific question since we're on the topic. I see > some of our authorative servers being hit with these spoofs, and > yes, the 9.3.5-P1 (that's what Sun supports in Solaris these > days) were sending back answers from the cache... but wait... > what cache? > > The view the Internet gets only has our authorative zones. There > is no declaration for the root zone, master, slave, or hints. > How does BIND have the root cached in that view? Where did it > get it from? I guess it's hard coded somewhere? BIND has had the hints compiled in for some time as a fall-back, but for an auth-only server, "additional-from-cache no;" will kill such responses. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From graeme at graemef.net Wed Jan 21 13:32:14 2009 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 21 Jan 2009 19:32:14 +0000 Subject: isprime DOS in progress In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> Message-ID: <1232566334.27353.7.camel@ernie.internal.graemef.net> On Wed, 2009-01-21 at 12:27 -0500, Phil Rosenthal wrote: > Representing ISPrime here. Well... representing myself and nobody else, so if that stretches my credibility thin so be it. > It's somewhat absurd to suggest that we are attacking our own > nameservers, I assure you, we didn't spend many hours looking for your > specific nameserver to start sending 10 requests per second for the > root zone, and our nameservers serve many popular domains. I just checked to make sure I did not make that assertion. I did not. I observed something odd, and stated as much to see if anyone else did. I apologise if you read my message as insinuating what you stated, but I assure you that wasn't the intention. I did say "maybe I'm being dumb", and that is indeed the answer - I applied a temporary netfilter ruleset, then made it permanent - and it switched the DROP and LOG statements round so that... the packet got dropped first and the log statements never got hit. Schoolboy error (and interesting that someone else has observed this behaviour before!)... Normal service has been resumed. I should write a haiku here (sorry, MLC, poor joke). > Given the attack is still in progress, I can't really say much more > publicly, but suffice to say, we're working on the situation. In a previous job I've been on the receiving end of similar attacks so I have a large degree of understanding of the pressure you're under at the moment. I wish you the best of luck sorting it out. Graeme From patrick at ianai.net Wed Jan 21 15:30:36 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 21 Jan 2009 16:30:36 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <20090121160733.GA21304@skywalker.creative.net.au> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> Message-ID: On Jan 21, 2009, at 11:07 AM, Adrian Chadd wrote: > On Wed, Jan 21, 2009, Patrick W. Gilmore wrote: > >> Google is not the only company which will put caches into any >> provider >> - or school (which is really just a special case provider) - with >> enough traffic. A school with 30 machines probably would not >> qualify. This is not being mean, this is just being rational. No >> way >> those 30 machines save the company enough money to pay for the >> caches. >> >> Again, sux, but that's life. I'd love to hear your solution - >> besides >> writing "magic" into squid to intentionally break or alter (some >> would >> use much harsher language) content you do not own. Content others >> are >> providing for free. > > Finding ways to force object revalidation by an intermediary cache (so > the end origin server knows something has been fetched) and thus > allowing the cache to serve the content on behalf of the content > origintor, under their full control, but without the bits being > served. Excellent idea. It is a shame content owners do not see the utility in your idea. To bring this back to an operational topic, just because a content owner does not want to work with someone on this, does the lack of external bandwidth / infrastructure / whatever make it "OK" to install a proxy which will intentionally re-write the content? -- TTFN, patrick From adrian at creative.net.au Wed Jan 21 15:38:13 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Jan 2009 06:38:13 +0900 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> Message-ID: <20090121213813.GD21304@skywalker.creative.net.au> > Excellent idea. It is a shame content owners do not see the utility > in your idea. > > To bring this back to an operational topic, just because a content > owner does not want to work with someone on this, does the lack of > external bandwidth / infrastructure / whatever make it "OK" to install > a proxy which will intentionally re-write the content? This really boils down to "who is more important? The content or the contents' eyeballs?" (Or the people having to deliver said content to said eyeballs, and aren't being paid by the content deliverer on their behalf.) Adrian From nick at foobar.org Wed Jan 21 15:37:47 2009 From: nick at foobar.org (Nick Hilliard) Date: Wed, 21 Jan 2009 21:37:47 +0000 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> Message-ID: <497795AB.9010900@foobar.org> On 21/01/2009 21:30, Patrick W. Gilmore wrote: > On Jan 21, 2009, at 11:07 AM, Adrian Chadd wrote: >> Finding ways to force object revalidation by an intermediary cache (so >> the end origin server knows something has been fetched) and thus >> allowing the cache to serve the content on behalf of the content >> origintor, under their full control, but without the bits being served. > > Excellent idea. It is a shame content owners do not see the utility in > your idea. This doesn't provide feed-back to the content distributors on partial downloads, etc - which is useful information to content providers, if you're into data mining end-user browsing habits. In the specific case of Youtube, of course I don't know that they do this, but I'd be surprised if they didn't. Nick From patrick at ianai.net Wed Jan 21 15:43:15 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 21 Jan 2009 16:43:15 -0500 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <20090121213813.GD21304@skywalker.creative.net.au> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> <20090121213813.GD21304@skywalker.creative.net.au> Message-ID: On Jan 21, 2009, at 4:38 PM, Adrian Chadd wrote: >> Excellent idea. It is a shame content owners do not see the utility >> in your idea. >> >> To bring this back to an operational topic, just because a content >> owner does not want to work with someone on this, does the lack of >> external bandwidth / infrastructure / whatever make it "OK" to >> install >> a proxy which will intentionally re-write the content? > > This really boils down to "who is more important? The content or the > contents' eyeballs?" > > (Or the people having to deliver said content to said eyeballs, and > aren't being paid by the content deliverer on their behalf.) No, it does not. If I own something, it doesn't matter how "important" the people who want to buy it are. But I guess that's not operational. -- TTFN, patrick From adrian at creative.net.au Wed Jan 21 15:52:07 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Jan 2009 06:52:07 +0900 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: <497795AB.9010900@foobar.org> References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> <497795AB.9010900@foobar.org> Message-ID: <20090121215207.GE21304@skywalker.creative.net.au> On Wed, Jan 21, 2009, Nick Hilliard wrote: > This doesn't provide feed-back to the content distributors on partial > downloads, etc - which is useful information to content providers, if > you're into data mining end-user browsing habits. In the specific case of > Youtube, of course I don't know that they do this, but I'd be surprised if > they didn't. If they'd like that included as a side-channel for certain response types, then they could ask. Its not like caches don't store per-connection information like that already.. :) Adrian From yahoo at jimpop.com Wed Jan 21 16:23:35 2009 From: yahoo at jimpop.com (Jim Popovitch) Date: Wed, 21 Jan 2009 17:23:35 -0500 Subject: Inauguration streaming traffic In-Reply-To: <497607E8.9070107@west.net> References: <497607E8.9070107@west.net> Message-ID: <7ff145960901211423p7bd15094j74683c0374b88d50@mail.gmail.com> Interesting read on yesterday's streaming. My experiences seem to mirror a lot of what is written here: http://www.techcrunch.com/2009/01/21/the-day-live-web-video-streaming-failed-us/ -Jim P. From Mark_Andrews at isc.org Wed Jan 21 16:49:26 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 22 Jan 2009 09:49:26 +1100 Subject: DNS Amplification attack? In-Reply-To: Your message of "Wed, 21 Jan 2009 11:23:47 -0800." <497705BD.33E4.0097.0@globalstar.com> Message-ID: <200901212249.n0LMnQjm008696@drugs.dv.isc.org> In message <497705BD.33E4.0097.0 at globalstar.com>, "Crist Clark" writes: > >>> On 1/20/2009 at 7:23 PM, Mark Andrews wrote: > > > In message <20090121140825.xwdzd4p64kgwo4go at web1.nswh.com.au>,=20 > > jay at miscreant.or=20 > > g writes: > >> > On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso = > wro=3D > >> te: > >>=20 > >> > We're also seeing a great number of these, but the idiots spoofing = > the > >> > queries are hitting several non-recursive nameservers we host - and = > only > >> > generating 59-byte "REFUSED" replies. > >> > > >> > Looks like they probably just grabbed a bunch of DNS hosts out of = > WHOIS > >> > and hoped that they were recursive resolvers. > >>=20 > >> First post to this list, play nice :) > >>=20 > >> Are you sure about this? I'm seeing these requests on /every/ =3D20 > >> (unrelated) NS I have access to, which numbers several dozen, in =3D20 > >> various countries across the world, and from various registries (.net, = > =3D20 > >> .org, .com.au). The spread of servers I've checked is so random that = > =3D20 > >> I'm wondering just how many NS records they've laid their hands on. > >>=20 > >> I've also noticed that on a server running BIND 9.3.4-P1 with =3D20 > >> recursion disabled, they're still appear to be getting the list of = > =3D20 > >> root NS's from cache, which is a 272-byte response to a 61-byte =3D20 > >> request, which by my definition is an amplification. > >=20 > > BIND 9.3.4-P1 is past end-of-life. > >=20 > > You need to properly set allow-query at both the option/view > > level and at the zone level to prevent retrieving answers > > from the cache in 9.3.x. > >=20 > > option/view level "allow-query { trusted; };" > > zone level "allow-query { any; };" > >=20 > > BIND 9.4.x and later have allow-query-cache make the > > configuration job easier. It also defaults to directly > > connected networks. > > Another BIND-specific question since we're on the topic. I see > some of our authorative servers being hit with these spoofs, and > yes, the 9.3.5-P1 (that's what Sun supports in Solaris these > days) were sending back answers from the cache... but wait... > what cache? Authoritative servers need a cache. Authoritative servers need to ask queries. The DNS protocol has evolved since RFC 1034 and RFC 1035 and authoritative servers need to translate named to addresses for their own use. See RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). > The view the Internet gets only has our authorative zones. There > is no declaration for the root zone, master, slave, or hints. > How does BIND have the root cached in that view? Where did it > get it from? I guess it's hard coded somewhere? > > Blocking this in the firewall. 1:0 amplification better than the > BIND fix, 1:1. But I'll get to the BIND fix anyway. The real fix is to get BCP 38 deployed. Reflection amplification attacks can be effective if BCP 38 measures have not been deployed. Go chase down the offending sources. BCP 38 is nearly 10 years old. We all should be taking this as a opportunity to find where the leaks are in the BCP 38 deployment and correct them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From vixie at isc.org Wed Jan 21 18:20:15 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 22 Jan 2009 00:20:15 +0000 Subject: DNS Amplification attack? In-Reply-To: <200901212249.n0LMnQjm008696@drugs.dv.isc.org> (Mark Andrews's message of "Thu\, 22 Jan 2009 09\:49\:26 +1100") References: <497705BD.33E4.0097.0@globalstar.com> <200901212249.n0LMnQjm008696@drugs.dv.isc.org> Message-ID: Mark Andrews writes: > Authoritative servers need a cache. Authoritative servers > need to ask queries. The DNS protocol has evolved since > RFC 1034 and RFC 1035 and authoritative servers need to > translate named to addresses for their own use. > > See RFC 1996, A Mechanism for Prompt Notification of Zone > Changes (DNS NOTIFY). if i had RFC 1996 to do over again i would either limit outbound notifies to in-zone servernames, or recommend that primary server operators configure stealth slaves for servername-containing zones, or (most likely) i would point out that the need to look up secondary servernames requires that an authority-only nameserver be able to act as a stub resolver and that such a server much have access to an independent recursive nameserver. it's not too late to implement it that way. no authority-only server should need a cache of any kind. the above text from marka represents a BIND implementatin detail, not a protocol requirement, evolved or not. > The real fix is to get BCP 38 deployed. Reflection > amplification attacks can be effective if BCP 38 measures > have not been deployed. Go chase down the offending > sources. BCP 38 is nearly 10 years old. my agreement with this statement is tempered by the fact that BCP38 deployment cannot be continuously assured, nor tested. therefore we will need protocols, implementations, and operational practices that take account of packet source address spoofing as an unduring property of the internet. > We all should be taking this as a opportunity to find where > the leaks are in the BCP 38 deployment and correct them. > > Mark yea, verily. and maybe track down rfc1918-sourced spew while you're at it. -- Paul Vixie From ongbh at ispworkshop.com Wed Jan 21 20:14:05 2009 From: ongbh at ispworkshop.com (Ong Beng Hui) Date: Thu, 22 Jan 2009 10:14:05 +0800 Subject: Inauguration streaming traffic In-Reply-To: <7ff145960901211423p7bd15094j74683c0374b88d50@mail.gmail.com> References: <497607E8.9070107@west.net> <7ff145960901211423p7bd15094j74683c0374b88d50@mail.gmail.com> Message-ID: <4977D66D.5040409@ispworkshop.com> Is there a general study done on the overall impact of inauguration streaming traffic ? any summary on what is the overall gain of bandwidth, etc. From mmc at internode.com.au Wed Jan 21 20:04:58 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 22 Jan 2009 12:34:58 +1030 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: References: <86171.1232480915@nsa.vix.com> <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> <20090121213813.GD21304@skywalker.creative.net.au> Message-ID: Surely the whole point of this is that the end users (the eyeballs) get the best experience they can as they're the ultimate consumer. So working with everyone in the chain between the content owner and the eyeballs is important. If you're a content owner then you want the experience to be good so that either you sell more ads or that your "brand" (whatever that may mean) is well thought of. It's why content owners use CDNs - to ensure that it's delivered close to the end user. Surely that means, logically to me anyway, that working with caching providers local to the eyeballs is the next logical point. Certainly for the heavy bits that don't change (eg the video streams Adrian mentioned). It's a mutual benefit thing - if your content sucks for a school (for example) to use then they're not going to use it. That's not good for you as a content owner. I realise that CDNs probably aren't that keen on people caching as it reduces their revenue, but a level of being rational about helping the whole chain deliver means probably more traffic overall. MMC On 22/01/2009, at 8:13 AM, Patrick W. Gilmore wrote: >> >> (Or the people having to deliver said content to said eyeballs, and >> aren't being paid by the content deliverer on their behalf.) > > No, it does not. > > If I own something, it doesn't matter how "important" the people who > want to buy it are. > > But I guess that's not operational. > > -- > TTFN, > patrick > > From jpleger at gmail.com Wed Jan 21 20:39:00 2009 From: jpleger at gmail.com (James Pleger) Date: Wed, 21 Jan 2009 19:39:00 -0700 Subject: Inauguration streaming traffic In-Reply-To: <4977D66D.5040409@ispworkshop.com> References: <497607E8.9070107@west.net> <7ff145960901211423p7bd15094j74683c0374b88d50@mail.gmail.com> <4977D66D.5040409@ispworkshop.com> Message-ID: Arbor had a good writeup on the traffic that they saw. http://asert.arbornetworks.com/2009/01/the-great-obama-traffic-flood/ Regards, James Pleger On Jan 21, 2009, at 7:14 PM, Ong Beng Hui wrote: > Is there a general study done on the overall impact of inauguration > streaming traffic ? > > any summary on what is the overall gain of bandwidth, etc. > From adrian at creative.net.au Wed Jan 21 23:00:21 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 22 Jan 2009 14:00:21 +0900 Subject: "IP networks will feel traffic pain in 2009" (C|Net & Cisco) In-Reply-To: References: <20090120233151.GA3835@vacation.karoshi.com.> <5C44BDC4-18F7-41E2-B798-615AFD873D73@multicasttech.com> <12880B9A-AC96-457B-BE1A-EB0E80B3C563@ianai.net> <20090121004010.GC15862@skywalker.creative.net.au> <2FDCEFC0-1C8B-40B3-A484-871BA8C1D5CB@ianai.net> <20090121160733.GA21304@skywalker.creative.net.au> <20090121213813.GD21304@skywalker.creative.net.au> Message-ID: <20090122050021.GK21304@skywalker.creative.net.au> On Thu, Jan 22, 2009, Matthew Moyle-Croft wrote: > I realise that CDNs probably aren't that keen on people caching as it > reduces their revenue, but a level of being rational about helping the > whole chain deliver means probably more traffic overall. I mean, I could extend an olive branch to all the CDNs out there and ask exactly what kind of extensions they'd like to see in intermediary caches so they can get the statistics they require, whilst allowing the edge to serve content on their behalf, but I doubt I'd get any bites. Oh well. Back to hacking on software so it can shuffle more bits. Adrian From bjorn at mork.no Thu Jan 22 05:01:56 2009 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 22 Jan 2009 12:01:56 +0100 Subject: isprime DOS in progress In-Reply-To: <1232557692.9593.57.camel@squonk.lboro.ac.uk> (Graeme Fowler's message of "Wed, 21 Jan 2009 17:08:12 +0000") References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> Message-ID: <8763k7li3f.fsf@obelix.mork.no> Graeme Fowler writes: > I've been seeing a lot of noise from the latter two addresses after > switching on query logging (and finishing an application of Team Cymru's > excellent template) so I decided to DROP traffic from the addresses > (with source port != 53) at the hosts in question. > > Well, blow me down if they didn't completely stop talking to me. Four > dropped packets each, and they've gone away. > > Something smells "not quite right" here - if the traffic is spoofed, and > my "Refused" responses have been flying right back to the *real* IP > addresses, how are the spoofing hosts to know that I'm dropping the > traffic? Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping traffic from other sources too? Looks like some of the other source addresses are controlled by the DOSers. Possibly used to detect filters? These clients may look similar to the DOS attack, but there are subtle differences: Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: view external: query (cache) './NS/IN' denied Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: view external: query (cache) './NS/IN' denied Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: view external: query (cache) './NS/IN' denied Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: view external: query (cache) './NS/IN' denied Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: view external: query (cache) './NS/IN' denied Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: view external: query (cache) './NS/IN' denied Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: view external: query (cache) './NS/IN' denied Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: view external: query (cache) './NS/IN' denied Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: view external: query (cache) './NS/IN' denied Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: view external: query (cache) './NS/IN' denied Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: view external: query (cache) './NS/IN' denied Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: view external: query (cache) './NS/IN' denied Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: view external: query (cache) './NS/IN' denied Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: view external: query (cache) './NS/IN' denied Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: view external: query (cache) './NS/IN' denied Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: view external: query (cache) './NS/IN' denied Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: view external: query (cache) './NS/IN' denied Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: view external: query (cache) './NS/IN' denied Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: view external: query (cache) './NS/IN' denied Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: view external: query (cache) './NS/IN' denied Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: view external: query (cache) './NS/IN' denied Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: view external: query (cache) './NS/IN' denied Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: view external: query (cache) './NS/IN' denied Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: view external: query (cache) './NS/IN' denied Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: view external: query (cache) './NS/IN' denied Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: view external: query (cache) './NS/IN' denied Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: view external: query (cache) './NS/IN' denied Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: view external: query (cache) './NS/IN' denied Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: view external: query (cache) './NS/IN' denied Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: view external: query (cache) './NS/IN' denied Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: view external: query (cache) './NS/IN' denied Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: view external: query (cache) './NS/IN' denied Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: view external: query (cache) './NS/IN' denied Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: view external: query (cache) './NS/IN' denied Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: view external: query (cache) './NS/IN' denied Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: view external: query (cache) './NS/IN' denied Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: view external: query (cache) './NS/IN' denied Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: view external: query (cache) './NS/IN' denied Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: view external: query (cache) './NS/IN' denied Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: view external: query (cache) './NS/IN' denied Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: view external: query (cache) './NS/IN' denied Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: view external: query (cache) './NS/IN' denied Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: view external: query (cache) './NS/IN' denied Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: view external: query (cache) './NS/IN' denied Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: view external: query (cache) './NS/IN' denied Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: view external: query (cache) './NS/IN' denied Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: view external: query (cache) './NS/IN' denied Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: view external: query (cache) './NS/IN' denied Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: view external: query (cache) './NS/IN' denied Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: view external: query (cache) './NS/IN' denied Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: view external: query (cache) './NS/IN' denied Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: view external: query (cache) './NS/IN' denied Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: view external: query (cache) './NS/IN' denied Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: view external: query (cache) './NS/IN' denied Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: view external: query (cache) './NS/IN' denied Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: view external: query (cache) './NS/IN' denied Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: view external: query (cache) './NS/IN' denied Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: view external: query (cache) './NS/IN' denied Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: view external: query (cache) './NS/IN' denied Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: view external: query (cache) './NS/IN' denied Notice the pattern: 3 probes every 38 minutes Each probe from the same source port Source port increases slowly and steadily This looks like some application actually waiting for a response. The slow source port change is probably an indication that this client only tests a small number of DNS servers. I guess that this client is either one of the many bots used to send the spoofed requests, or maybe a bot not allowed to spoof its source and therefore used for other purposes. In any case, I assume that other DNS servers may see such control sessions coming from other addresses. These 3 clients started probing my DNS server almost simultaneously on January 8th: Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: view external: query (cache) './NS/IN' denied Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: view external: query (cache) './NS/IN' denied Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: view external: query (cache) './NS/IN' denied Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: view external: query (cache) './NS/IN' denied Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: view external: query (cache) './NS/IN' denied Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: view external: query (cache) './NS/IN' denied Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: view external: query (cache) './NS/IN' denied Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: view external: query (cache) './NS/IN' denied Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: view external: query (cache) './NS/IN' denied Maybe preparing for the attack on ISPrime? I didn't start receiving spoofed requests from 66.230.128.15/66.230.160.1 before January 20th I just tried filtering the probing addresses. This made the probing stop immediately after dropping a set of 3 probes. But the spoofed requests continuted at the same rate as before, so this does not support my theory. However, I believe it would be too much of a coincidence if there isn't some connection between the probing and the DOS attack. It would be interesting to hear if others see similar probing. Bj?rn From maillist at webjogger.net Thu Jan 22 08:08:30 2009 From: maillist at webjogger.net (Adam Greene) Date: Thu, 22 Jan 2009 09:08:30 -0500 Subject: inauguration streams review References: <200901201924.n0KJOsLr032637@stark.hevanet.com><1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com><2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com><2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com><1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com><89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> <2ad0f9f60901211101k57d902do43d8f46a3f2ece5d@mail.gmail.com> Message-ID: <60C736580784448E8881314F3E51952D@GINKGO> Hi, quick question ... Most people here said they saw most of the inauguration traffic on TCP1935 to Limelight and UDP8247 to CNN. However, we were seeing it simply as "http" traffic (i.e. port 80), which made it very difficult to manage. Our inbound bandwidth was effectively maxed out for about 6 hours. I wonder what the discrepancy is between my experience and yours ... maybe the glass through which I am peering? We're analyzing / controlling WAN traffic with Exindas. Thanks, Adam ----- Original Message ----- From: "Jack Carrozzo" To: "Paul Stewart" Cc: Sent: Wednesday, January 21, 2009 2:01 PM Subject: Re: inauguration streams review COWs are more or less full sites - so standard N concurrent voice calls per carrier (check out the CDMA standard if you're really interested), times the number of carriers. They can do 850+PCS all carrier if configured that way. If we can grab fiber from a nearby building that's best (hence why this takes so long to plan), however a lot of time we rely on OC3 microwave backhaul. I wasn't involved with the DC guys as I'm in Boston so I don't know specifics of this event. Re: security, I don't know since I wasn't involved though since all the planning started so far back I doubt there was much issue. -Jack Carrozzo On Wed, Jan 21, 2009 at 1:54 PM, Paul Stewart wrote: > Just curious on that note with COW .. did you have much security related > problems setting up stuff nearby? > > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Wednesday, January 21, 2009 1:52 PM > To: Jack Carrozzo > Cc: nanog at nanog.org > Subject: Re: inauguration streams review > > How many simultaneous connections can each COW handle? What kind of > backhaul > connections do they have? > > -Mike > > > On Wed, Jan 21, 2009 at 10:49 AM, Jack Carrozzo > wrote: > >> I can't comment on revenue-generation, though access as a whole was > quite >> high. >> >> We hardly had any voice IAs (Ineffective Attempts, or 'Busy' >> messages). Since data can be queued, the only thing that would cause >> data IAs are bad RF conditions - we had a TON of 'cell on wheels' in >> the area for the event so we had enough carrier space to cover it. >> >> In-network data response times were hardly affected, with switch loads >> well below 50%. In-network SMS were still getting to their >> destinations in under 5 seconds for the most part.... I don't have any >> numbers on MMS or mobile IP data at the moment, though I would have >> heard if something horrible had happened. >> >> I'm told that the out-of-network SMS queue was piling pretty high at >> one point, to delivery times up to an hour, though they all still got >> there. We can't control other network's switches obviously. >> >> This isn't trying to sound like an advertisement - *I'm* not affected >> either way if people sign up with us as I'm not in sales, however from >> my point of view it looks like we had the most solid network... Our >> guys were planning and setting things up since June. >> >> Cheers, >> >> -Jack Carrozzo >> >> On Wed, Jan 21, 2009 at 1:29 PM, Peter Beckman >> wrote: >> > On Tue, 20 Jan 2009, Jack Carrozzo wrote: >> > >> >> Cell networks held up reasonably well for voice, though SMS and MMS >> >> delivery times approached an hour during the event. Switch load in >> >> almost the entire US was higher than midnight on New Years (which > is >> >> generally the highest load of the year). >> >> >> >> Our network has been preparing since June, and I assume likewise > for >> >> others. >> > >> > Unfortunately for me Sprint did not seem to prepare or have enough >> > capacity for Voice, SMS or Data access. No live Twitter blogging! >> > >> > While I was able to get a few (maybe 5 between 10am and 2pm) text >> messages >> > out while standing near the Washington Monument, calls and data > were an >> > impossibility, and SMS only seemed to have capacity available > during >> lulls >> > in the Inaugural activity. >> > >> > It was disappointing as a customer -- I'm sure that, had the > capacity >> been >> > there, the revenue from that single event would have made a > significant >> > impact on any of the carrier's revenue, at least for the month. >> > >> >> -Jack Carrozzo >> >> (Engineer at $large cell company whose policy doesn't allow me to >> specify) >> > >> > (Google spills the beans!) I'm curious if you can find out -- did > the >> > record traffic positively affect revenue for that period compared > to >> last >> > year at the same time, or even last week on the same day? >> > >> > And from a more technical standpoint, did your $large cell company > put >> up >> > temporary towers? I'm curious as to how your company added > capacity to >> > handle the event, as well as how many "Network Busy" messages > customers >> > got, if any. I know I got more of those messages than I did > successful >> > communications. >> > >> > Beckman >> > >> > ------------------------------------------------------------------------ > --- >> > Peter Beckman > Internet >> Guy >> > beckman at angryox.com >> http://www.angryox.com/ >> > >> > ------------------------------------------------------------------------ > --- >> > >> > > > > > ---------------------------------------------------------------------------- > > "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." > From fweimer at bfk.de Thu Jan 22 08:46:25 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 22 Jan 2009 15:46:25 +0100 Subject: DNS Amplification attack? In-Reply-To: <200901212249.n0LMnQjm008696@drugs.dv.isc.org> (Mark Andrews's message of "Thu, 22 Jan 2009 09:49:26 +1100") References: <200901212249.n0LMnQjm008696@drugs.dv.isc.org> Message-ID: <82tz7r8kla.fsf@mid.bfk.de> * Mark Andrews: > Authoritative servers need a cache. Authoritative servers > need to ask queries. The DNS protocol has evolved since > RFC 1034 and RFC 1035 and authoritative servers need to > translate named to addresses for their own use. > > See RFC 1996, A Mechanism for Prompt Notification of Zone > Changes (DNS NOTIFY). Authoritative servers in typical configurations need a resolver (and with views, you might even need a very specific resolver). This does not mean that authoritative servers must be caches. It also does not mean that a resolver operated from the view which contains a particular authoritatively served zone picks up the correct data (in other words, there are configurations where the current BIND magic does not work). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From will at charnocks.net Thu Jan 22 09:47:00 2009 From: will at charnocks.net (William Charnock) Date: Thu, 22 Jan 2009 09:47:00 -0600 Subject: WSJ on things to do in Santo Domingo In-Reply-To: <20090121090948.61fdf642@cs.columbia.edu> References: <20090121090948.61fdf642@cs.columbia.edu> Message-ID: <497894F4.2090303@charnocks.net> Here's another good site (I think): http://dr1.com/ The travel section has some good information. Will Steven M. Bellovin wrote: > http://online.wsj.com/article/SB123240330058595471.html -- no idea if > you have to be a subscriber or not. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From bdfleming at kanren.net Thu Jan 22 10:09:34 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Thu, 22 Jan 2009 10:09:34 -0600 Subject: Inauguration streaming traffic In-Reply-To: <20090121112949.GF19720@login.ecs.soton.ac.uk> References: <497607E8.9070107@west.net> <75cb24520901200938k3be7132atf0f0a69d11d28770@mail.gmail.com> <20090121112949.GF19720@login.ecs.soton.ac.uk> Message-ID: We also enjoyed a large multicast stream -- we selected the one provided by Northwestern University's retransmission of C-SPAN's coverage. We consumed the stream via KanREN's link to The Great Plains Network (our Internet2 connector). If anyone is on the list from Northwestern University: Thanks for your work... if nothing else, it helped a bunch of dorks in Kansas watch the events without consuming precious I1 capacity. :D -- Brad Fleming Network Engineer Kansas Research and Education Network Office: 785-856-9800 x.222 Moblie: 785-865-7231 NOC: 866-984-3662 On Jan 21, 2009, at 5:29 AM, Tim Chown wrote: > On Tue, Jan 20, 2009 at 12:38:11PM -0500, Christopher Morrow wrote: >> On Tue, Jan 20, 2009 at 12:26 PM, Brian Wallingford > > wrote: >>> On Tue, 20 Jan 2009, Jay Hennigan wrote: >>> >>> :We're a regional ISP, about 80% SMB 20% residential. We're seeing >>> :almost double our normal downstream traffic right now. Anyone >>> else? >>> >>> We're seeing traffic levels nearly 2x normal. On 9/11/01, we were >>> probably only about 50% higher than the norm. Of course, lots has >>> changed, so that's probably not a fair comparison. >> >> As an aside... thanks to BBC for streaming this, I couldn't find >> another source that wasn't overloaded/jerky/ugly :( > > The Beeb's HD multicast feed is about 23Mbit/s to the host, and we > received > it at quite decent (subjective) quality here on a JANET-connected > university > site. The feed runs continuously (as far as any 'as-is' test > stream does :) > and this morning is pretty flawless. > > The interesting aspect of the HD stream was seeing how various > systems coped > with the CPU load. It was good to have some HD content available > that > encouraged people to install vlc, find out a little about multicast, > and > system issues in receiving it. > > Thanks again Beeb :) > > -- > Tim > > > > From ralphw at interworld.net Thu Jan 22 16:05:21 2009 From: ralphw at interworld.net (Ralph E. Whitmore, III) Date: Thu, 22 Jan 2009 14:05:21 -0800 Subject: Anyone know what happened with OPENRBL.org or of a comperable replacement? Message-ID: They appear to have vaporized from the face of the internet. Ralph From rsk at gsp.org Thu Jan 22 17:02:36 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 22 Jan 2009 18:02:36 -0500 Subject: Anyone know what happened with OPENRBL.org or of a comperable replacement? In-Reply-To: References: Message-ID: <20090122230236.GA15635@gsp.org> On Thu, Jan 22, 2009 at 02:05:21PM -0800, Ralph E. Whitmore, III wrote: > They appear to have vaporized from the face of the internet. (This would probably be better on the "mailop" list.) You might find either or both of these alternatives useful: http://www.blacklistalert.org/ http://www.rblstatus.com/ ---Rsk From maxsec at gmail.com Fri Jan 23 09:12:45 2009 From: maxsec at gmail.com (Martin Hepworth) Date: Fri, 23 Jan 2009 15:12:45 +0000 Subject: Anyone know what happened with OPENRBL.org or of a comperable replacement? In-Reply-To: References: Message-ID: <72cf361e0901230712l1525f5a2g45c2c9d623023771@mail.gmail.com> 2009/1/22 Ralph E. Whitmore, III : > They appear to have vaporized from the face of the internet. > > Ralph > > > Ralf when bad in June.....ya must have been having a long sleep. -- Martin Hepworth Oxford, UK From pr at isprime.com Fri Jan 23 12:11:32 2009 From: pr at isprime.com (Phil Rosenthal) Date: Fri, 23 Jan 2009 13:11:32 -0500 Subject: isprime DOS in progress In-Reply-To: <8763k7li3f.fsf@obelix.mork.no> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> Message-ID: <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> Just a friendly notice, the attack against 66.230.128.15/66.230.160.1 seems to have stopped for now. -Phil On Jan 22, 2009, at 6:01 AM, Bj?rn Mork wrote: > Graeme Fowler writes: > >> I've been seeing a lot of noise from the latter two addresses after >> switching on query logging (and finishing an application of Team >> Cymru's >> excellent template) so I decided to DROP traffic from the addresses >> (with source port != 53) at the hosts in question. >> >> Well, blow me down if they didn't completely stop talking to me. Four >> dropped packets each, and they've gone away. >> >> Something smells "not quite right" here - if the traffic is >> spoofed, and >> my "Refused" responses have been flying right back to the *real* IP >> addresses, how are the spoofing hosts to know that I'm dropping the >> traffic? > > Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping > traffic from other sources too? Looks like some of the other source > addresses are controlled by the DOSers. Possibly used to detect > filters? > > These clients may look similar to the DOS attack, but there are subtle > differences: > > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > view external: query (cache) './NS/IN' denied > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > view external: query (cache) './NS/IN' denied > Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: > view external: query (cache) './NS/IN' denied > Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: > view external: query (cache) './NS/IN' denied > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > view external: query (cache) './NS/IN' denied > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > view external: query (cache) './NS/IN' denied > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > view external: query (cache) './NS/IN' denied > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > view external: query (cache) './NS/IN' denied > Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: > view external: query (cache) './NS/IN' denied > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > view external: query (cache) './NS/IN' denied > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > view external: query (cache) './NS/IN' denied > Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: > view external: query (cache) './NS/IN' denied > Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: > view external: query (cache) './NS/IN' denied > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > view external: query (cache) './NS/IN' denied > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > view external: query (cache) './NS/IN' denied > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > view external: query (cache) './NS/IN' denied > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > view external: query (cache) './NS/IN' denied > Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: > view external: query (cache) './NS/IN' denied > Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: > view external: query (cache) './NS/IN' denied > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > view external: query (cache) './NS/IN' denied > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > view external: query (cache) './NS/IN' denied > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > view external: query (cache) './NS/IN' denied > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > view external: query (cache) './NS/IN' denied > Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: > view external: query (cache) './NS/IN' denied > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > view external: query (cache) './NS/IN' denied > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > view external: query (cache) './NS/IN' denied > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > view external: query (cache) './NS/IN' denied > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > view external: query (cache) './NS/IN' denied > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > view external: query (cache) './NS/IN' denied > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > view external: query (cache) './NS/IN' denied > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > view external: query (cache) './NS/IN' denied > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > view external: query (cache) './NS/IN' denied > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > view external: query (cache) './NS/IN' denied > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > view external: query (cache) './NS/IN' denied > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > view external: query (cache) './NS/IN' denied > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > view external: query (cache) './NS/IN' denied > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > view external: query (cache) './NS/IN' denied > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > view external: query (cache) './NS/IN' denied > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > view external: query (cache) './NS/IN' denied > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > view external: query (cache) './NS/IN' denied > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > view external: query (cache) './NS/IN' denied > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > view external: query (cache) './NS/IN' denied > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > view external: query (cache) './NS/IN' denied > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > view external: query (cache) './NS/IN' denied > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > view external: query (cache) './NS/IN' denied > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > view external: query (cache) './NS/IN' denied > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > view external: query (cache) './NS/IN' denied > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > view external: query (cache) './NS/IN' denied > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > view external: query (cache) './NS/IN' denied > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > view external: query (cache) './NS/IN' denied > Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: > view external: query (cache) './NS/IN' denied > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > view external: query (cache) './NS/IN' denied > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > view external: query (cache) './NS/IN' denied > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > view external: query (cache) './NS/IN' denied > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > view external: query (cache) './NS/IN' denied > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > view external: query (cache) './NS/IN' denied > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > view external: query (cache) './NS/IN' denied > Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: > view external: query (cache) './NS/IN' denied > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > view external: query (cache) './NS/IN' denied > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > view external: query (cache) './NS/IN' denied > > > Notice the pattern: > 3 probes every 38 minutes > Each probe from the same source port > Source port increases slowly and steadily > > This looks like some application actually waiting for a response. The > slow source port change is probably an indication that this client > only > tests a small number of DNS servers. I guess that this client is > either > one of the many bots used to send the spoofed requests, or maybe a bot > not allowed to spoof its source and therefore used for other > purposes. In any case, I assume that other DNS servers may see such > control sessions coming from other addresses. > > These 3 clients started probing my DNS server almost simultaneously > on January 8th: > > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > view external: query (cache) './NS/IN' denied > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > view external: query (cache) './NS/IN' denied > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > view external: query (cache) './NS/IN' denied > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > view external: query (cache) './NS/IN' denied > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > view external: query (cache) './NS/IN' denied > Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: > view external: query (cache) './NS/IN' denied > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > view external: query (cache) './NS/IN' denied > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > view external: query (cache) './NS/IN' denied > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > view external: query (cache) './NS/IN' denied > > Maybe preparing for the attack on ISPrime? I didn't start receiving > spoofed requests from 66.230.128.15/66.230.160.1 before January 20th > > > I just tried filtering the probing addresses. This made the probing > stop immediately after dropping a set of 3 probes. But the spoofed > requests continuted at the same rate as before, so this does not > support > my theory. > > However, I believe it would be too much of a coincidence if there > isn't > some connection between the probing and the DOS attack. It would be > interesting to hear if others see similar probing. > > > > Bj?rn > From cscora at apnic.net Fri Jan 23 12:16:04 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Jan 2009 04:16:04 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200901231816.n0NIG4H0016450@thyme.apnic.net> 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-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 Jan, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 278634 Prefixes after maximum aggregation: 132262 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 135421 Total ASes present in the Internet Routing Table: 30368 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 26408 Origin ASes announcing only one prefix: 12861 Transit ASes present in the Internet Routing Table: 3960 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 21 Max AS path prepend of ASN (12445) 18 Prefixes from unregistered ASNs in the Routing Table: 529 Unregistered ASNs in the Routing Table: 182 Number of 32-bit ASNs allocated by the RIRs: 78 Prefixes from 32-bit ASNs in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 273 Number of addresses announced to Internet: 1986107424 Equivalent to 118 /8s, 97 /16s and 152 /24s Percentage of available address space announced: 53.6 Percentage of allocated address space announced: 63.3 Percentage of available address space allocated: 84.6 Percentage of address space in use by end-sites: 75.4 Total number of prefixes smaller than registry allocations: 137044 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 64288 Total APNIC prefixes after maximum aggregation: 22759 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 61154 Unique aggregates announced from the APNIC address blocks: 26988 APNIC Region origin ASes present in the Internet Routing Table: 3502 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 957 APNIC Region transit ASes present in the Internet Routing Table: 540 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 395679136 Equivalent to 23 /8s, 149 /16s and 149 /24s Percentage of available APNIC address space announced: 78.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/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: 123881 Total ARIN prefixes after maximum aggregation: 65090 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 93335 Unique aggregates announced from the ARIN address blocks: 35568 ARIN Region origin ASes present in the Internet Routing Table: 12728 ARIN Prefixes per ASN: 7.33 ARIN Region origin ASes announcing only one prefix: 4900 ARIN Region transit ASes present in the Internet Routing Table: 1226 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 407062688 Equivalent to 24 /8s, 67 /16s and 72 /24s Percentage of available ARIN address space announced: 78.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 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, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 62615 Total RIPE prefixes after maximum aggregation: 36968 RIPE Deaggregation factor: 1.69 Prefixes being announced from the RIPE address blocks: 57543 Unique aggregates announced from the RIPE address blocks: 38357 RIPE Region origin ASes present in the Internet Routing Table: 12537 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6580 RIPE Region transit ASes present in the Internet Routing Table: 1911 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 386691168 Equivalent to 23 /8s, 12 /16s and 112 /24s Percentage of available RIPE address space announced: 88.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22988 Total LACNIC prefixes after maximum aggregation: 5665 LACNIC Deaggregation factor: 4.06 Prefixes being announced from the LACNIC address blocks: 21227 Unique aggregates announced from the LACNIC address blocks: 11724 LACNIC Region origin ASes present in the Internet Routing Table: 1050 LACNIC Prefixes per ASN: 20.22 LACNIC Region origin ASes announcing only one prefix: 334 LACNIC Region transit ASes present in the Internet Routing Table: 175 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 60435456 Equivalent to 3 /8s, 154 /16s and 44 /24s Percentage of available LACNIC address space announced: 60.0 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4365 Total AfriNIC prefixes after maximum aggregation: 1368 AfriNIC Deaggregation factor: 3.19 Prefixes being announced from the AfriNIC address blocks: 5252 Unique aggregates announced from the AfriNIC address blocks: 2180 AfriNIC Region origin ASes present in the Internet Routing Table: 280 AfriNIC Prefixes per ASN: 18.76 AfriNIC Region origin ASes announcing only one prefix: 90 AfriNIC Region transit ASes present in the Internet Routing Table: 58 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13112576 Equivalent to 0 /8s, 200 /16s and 21 /24s Percentage of available AfriNIC address space announced: 26.1 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1660 6411 376 Korea Telecom (KIX) 17488 1504 107 96 Hathway IP Over Cable Interne 4755 1193 428 175 TATA Communications formerly 9583 1156 130 110 Sify Limited 4134 902 16063 365 CHINANET-BACKBONE 18101 770 174 25 Reliance Infocom Ltd Internet 4780 720 357 64 Digital United Inc. 9498 680 297 52 BHARTI BT INTERNET LTD. 7545 675 152 81 TPG Internet Pty Ltd 24560 660 224 181 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4381 3435 344 bellsouth.net, inc. 209 2833 4032 617 Qwest 20115 2033 1465 742 Charter Communications 1785 1793 735 158 PaeTec Communications, Inc. 4323 1621 1081 373 Time Warner Telecom 2386 1575 714 895 AT&T Data Communications Serv 7018 1444 5876 1002 AT&T WorldNet Services 11492 1216 192 12 Cable One 6478 1196 289 511 AT&T Worldnet Services 3356 1131 10997 441 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 922 188 7 TEDATA 3292 441 1765 386 TDC Tele Danmark 30890 435 88 199 SC Kappa Invexim SRL 12479 393 578 6 Uni2 Autonomous System 3301 336 1669 302 TeliaNet Sweden 8866 333 109 22 Bulgarian Telecommunication C 3320 332 7065 281 Deutsche Telekom AG 3215 330 2897 99 France Telecom Transpac 29049 324 26 3 AzerSat LLC. 35805 324 27 7 United Telecom of Georgia Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1479 2834 230 UniNet S.A. de C.V. 10620 725 153 77 TVCABLE BOGOTA 11830 681 299 9 Instituto Costarricense de El 22047 563 302 14 VTR PUNTO NET S.A. 7303 509 253 78 Telecom Argentina Stet-France 6471 437 94 41 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 408 118 74 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 376 505 22 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 594 72 40 LINKdotNET AS number 3741 269 857 227 The Internet Solution 20858 262 34 3 This AS will be used to conne 2018 242 215 142 Tertiary Education Network 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 6713 144 135 11 Itissalat Al-MAGHRIB 29571 128 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 555 66 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4381 3435 344 bellsouth.net, inc. 209 2833 4032 617 Qwest 20115 2033 1465 742 Charter Communications 1785 1793 735 158 PaeTec Communications, Inc. 4766 1660 6411 376 Korea Telecom (KIX) 4323 1621 1081 373 Time Warner Telecom 2386 1575 714 895 AT&T Data Communications Serv 17488 1504 107 96 Hathway IP Over Cable Interne 8151 1479 2834 230 UniNet S.A. de C.V. 7018 1444 5876 1002 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2833 2216 Qwest 1785 1793 1635 PaeTec Communications, Inc. 17488 1504 1408 Hathway IP Over Cable Interne 20115 2033 1291 Charter Communications 4766 1660 1284 Korea Telecom (KIX) 8151 1479 1249 UniNet S.A. de C.V. 4323 1621 1248 Time Warner Telecom 11492 1216 1204 Cable One 18566 1060 1050 Covad Communications 9583 1156 1046 Sify Limited Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.208.128.0/18 8346 SONATEL-AS Autonomous System 41.214.0.0/17 8346 SONATEL-AS Autonomous System 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.132.0/24 12491 IPPlanet 41.223.133.0/24 12491 IPPlanet Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:20 /11:54 /12:159 /13:311 /14:566 /15:1107 /16:10312 /17:4540 /18:7807 /19:16861 /20:19755 /21:19324 /22:24573 /23:24942 /24:146188 /25:657 /26:812 /27:508 /28:94 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2858 4381 bellsouth.net, inc. 209 1577 2833 Qwest 4766 1394 1660 Korea Telecom (KIX) 17488 1289 1504 Hathway IP Over Cable Interne 2386 1255 1575 AT&T Data Communications Serv 1785 1207 1793 PaeTec Communications, Inc. 11492 1181 1216 Cable One 20115 1107 2033 Charter Communications 18566 1041 1060 Covad Communications 9583 1001 1156 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:175 12:2195 13:2 15:21 16:3 17:5 20:35 24:1179 32:51 38:536 40:96 41:1579 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:517 59:610 60:456 61:1109 62:1115 63:2003 64:3435 65:2439 66:3641 67:1460 68:673 69:2447 70:528 71:207 72:1604 73:7 74:1358 75:203 76:303 77:795 78:534 79:318 80:939 81:846 82:564 83:395 84:589 85:1080 86:397 87:638 88:361 89:1388 90:46 91:1879 92:324 93:1068 94:984 95:207 96:97 97:171 98:187 99:11 110:1 111:1 112:14 113:68 114:157 115:209 116:1133 117:473 118:266 119:614 120:131 121:704 122:926 123:494 124:838 125:1273 128:353 129:225 130:135 131:413 132:68 133:9 134:321 135:35 136:224 137:138 138:145 139:92 140:413 141:109 142:384 143:326 144:327 145:38 146:372 147:144 148:529 149:225 150:133 151:212 152:149 153:131 154:10 155:259 156:171 157:271 158:160 159:277 160:280 161:140 162:271 163:138 164:514 165:504 166:363 167:351 168:682 169:162 170:469 171:37 172:10 173:168 174:38 186:2 187:25 189:361 190:2544 192:5821 193:4191 194:3317 195:2675 196:1058 198:3657 199:3312 200:5495 201:1468 202:7801 203:8094 204:3932 205:2151 206:2313 207:2798 208:3819 209:3503 210:2771 211:1170 212:1546 213:1645 214:66 215:30 216:4556 217:1205 218:375 219:402 220:1221 221:472 222:296 End of report From stevel at dedicatedservers.net.au Fri Jan 23 13:46:41 2009 From: stevel at dedicatedservers.net.au (Steven Lisson) Date: Sat, 24 Jan 2009 05:46:41 +1000 Subject: isprime DOS in progress In-Reply-To: <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com><20090120205514.GA10257@fries.net><1232557692.9593.57.camel@squonk.lboro.ac.uk><8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> Message-ID: Hi, I agree with seeing no traffic to/from 66.230.128.15 but am still seeing flows 'from' 66.230.160.1 Regards, Steve -----Original Message----- From: Phil Rosenthal [mailto:pr at isprime.com] Sent: Saturday, 24 January 2009 4:12 AM To: nanog at nanog.org Subject: Re: isprime DOS in progress Just a friendly notice, the attack against 66.230.128.15/66.230.160.1 seems to have stopped for now. -Phil On Jan 22, 2009, at 6:01 AM, Bj?rn Mork wrote: > Graeme Fowler writes: > >> I've been seeing a lot of noise from the latter two addresses after >> switching on query logging (and finishing an application of Team >> Cymru's >> excellent template) so I decided to DROP traffic from the addresses >> (with source port != 53) at the hosts in question. >> >> Well, blow me down if they didn't completely stop talking to me. Four >> dropped packets each, and they've gone away. >> >> Something smells "not quite right" here - if the traffic is >> spoofed, and >> my "Refused" responses have been flying right back to the *real* IP >> addresses, how are the spoofing hosts to know that I'm dropping the >> traffic? > > Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping > traffic from other sources too? Looks like some of the other source > addresses are controlled by the DOSers. Possibly used to detect > filters? > > These clients may look similar to the DOS attack, but there are subtle > differences: > > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > view external: query (cache) './NS/IN' denied > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > view external: query (cache) './NS/IN' denied > Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: > view external: query (cache) './NS/IN' denied > Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: > view external: query (cache) './NS/IN' denied > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > view external: query (cache) './NS/IN' denied > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > view external: query (cache) './NS/IN' denied > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > view external: query (cache) './NS/IN' denied > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > view external: query (cache) './NS/IN' denied > Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: > view external: query (cache) './NS/IN' denied > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > view external: query (cache) './NS/IN' denied > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > view external: query (cache) './NS/IN' denied > Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: > view external: query (cache) './NS/IN' denied > Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: > view external: query (cache) './NS/IN' denied > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > view external: query (cache) './NS/IN' denied > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > view external: query (cache) './NS/IN' denied > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > view external: query (cache) './NS/IN' denied > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > view external: query (cache) './NS/IN' denied > Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: > view external: query (cache) './NS/IN' denied > Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: > view external: query (cache) './NS/IN' denied > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > view external: query (cache) './NS/IN' denied > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > view external: query (cache) './NS/IN' denied > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > view external: query (cache) './NS/IN' denied > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > view external: query (cache) './NS/IN' denied > Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: > view external: query (cache) './NS/IN' denied > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > view external: query (cache) './NS/IN' denied > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > view external: query (cache) './NS/IN' denied > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > view external: query (cache) './NS/IN' denied > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > view external: query (cache) './NS/IN' denied > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > view external: query (cache) './NS/IN' denied > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > view external: query (cache) './NS/IN' denied > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > view external: query (cache) './NS/IN' denied > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > view external: query (cache) './NS/IN' denied > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > view external: query (cache) './NS/IN' denied > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > view external: query (cache) './NS/IN' denied > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > view external: query (cache) './NS/IN' denied > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > view external: query (cache) './NS/IN' denied > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > view external: query (cache) './NS/IN' denied > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > view external: query (cache) './NS/IN' denied > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > view external: query (cache) './NS/IN' denied > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > view external: query (cache) './NS/IN' denied > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > view external: query (cache) './NS/IN' denied > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > view external: query (cache) './NS/IN' denied > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > view external: query (cache) './NS/IN' denied > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > view external: query (cache) './NS/IN' denied > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > view external: query (cache) './NS/IN' denied > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > view external: query (cache) './NS/IN' denied > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > view external: query (cache) './NS/IN' denied > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > view external: query (cache) './NS/IN' denied > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > view external: query (cache) './NS/IN' denied > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > view external: query (cache) './NS/IN' denied > Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: > view external: query (cache) './NS/IN' denied > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > view external: query (cache) './NS/IN' denied > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > view external: query (cache) './NS/IN' denied > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > view external: query (cache) './NS/IN' denied > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > view external: query (cache) './NS/IN' denied > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > view external: query (cache) './NS/IN' denied > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > view external: query (cache) './NS/IN' denied > Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: > view external: query (cache) './NS/IN' denied > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > view external: query (cache) './NS/IN' denied > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > view external: query (cache) './NS/IN' denied > > > Notice the pattern: > 3 probes every 38 minutes > Each probe from the same source port > Source port increases slowly and steadily > > This looks like some application actually waiting for a response. The > slow source port change is probably an indication that this client > only > tests a small number of DNS servers. I guess that this client is > either > one of the many bots used to send the spoofed requests, or maybe a bot > not allowed to spoof its source and therefore used for other > purposes. In any case, I assume that other DNS servers may see such > control sessions coming from other addresses. > > These 3 clients started probing my DNS server almost simultaneously > on January 8th: > > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > view external: query (cache) './NS/IN' denied > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > view external: query (cache) './NS/IN' denied > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > view external: query (cache) './NS/IN' denied > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > view external: query (cache) './NS/IN' denied > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > view external: query (cache) './NS/IN' denied > Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: > view external: query (cache) './NS/IN' denied > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > view external: query (cache) './NS/IN' denied > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > view external: query (cache) './NS/IN' denied > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > view external: query (cache) './NS/IN' denied > > Maybe preparing for the attack on ISPrime? I didn't start receiving > spoofed requests from 66.230.128.15/66.230.160.1 before January 20th > > > I just tried filtering the probing addresses. This made the probing > stop immediately after dropping a set of 3 probes. But the spoofed > requests continuted at the same rate as before, so this does not > support > my theory. > > However, I believe it would be too much of a coincidence if there > isn't > some connection between the probing and the DOS attack. It would be > interesting to hear if others see similar probing. > > > > Bj?rn > From jabley at hopcount.ca Fri Jan 23 14:33:06 2009 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 23 Jan 2009 15:33:06 -0500 Subject: isprime DOS in progress In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com><20090120205514.GA10257@fries.net><1232557692.9593.57.camel@squonk.lboro.ac.uk><8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> Message-ID: <9B5C562E-4F7A-4891-BE0A-98D9CF4C2ABD@hopcount.ca> On 2009-01-23, at 14:46, Steven Lisson wrote: > I agree with seeing no traffic to/from 66.230.128.15 but am still > seeing flows 'from' 66.230.160.1 Are they responses to queries? Or are they queries directed at servers in your network? The latter are to be expected, I think. Joe From luke at sheldrick.co.uk Fri Jan 23 14:20:35 2009 From: luke at sheldrick.co.uk (Luke Sheldrick) Date: Fri, 23 Jan 2009 20:20:35 +0000 Subject: isprime DOS in progress In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> Message-ID: <1232742035.3801.1.camel@localhost.localdomain> Looks to me like the target has moved, anyone else seeing similar? Jan 23 20:19:08 LND02 named[9611]: client 63.217.28.226#39489: view external: query (cache) './NS/IN' denied Jan 23 20:19:09 LND02 named[9611]: client 63.217.28.226#20558: view external: query (cache) './NS/IN' denied Jan 23 20:19:11 LND02 named[9611]: client 63.217.28.226#38525: view external: query (cache) './NS/IN' denied Jan 23 20:19:12 LND02 named[9611]: client 63.217.28.226#41535: view external: query (cache) './NS/IN' denied Jan 23 20:19:12 LND02 named[9611]: client 63.217.28.226#51220: view external: query (cache) './NS/IN' denied Jan 23 20:19:13 LND02 named[9611]: client 63.217.28.226#28869: view external: query (cache) './NS/IN' denied Jan 23 20:19:14 LND02 named[9611]: client 63.217.28.226#12337: view external: query (cache) './NS/IN' denied Jan 23 20:19:15 LND02 named[9611]: client 63.217.28.226#41346: view external: query (cache) './NS/IN' denied Jan 23 20:19:15 LND02 named[9611]: client 63.217.28.226#56831: view external: query (cache) './NS/IN' denied Jan 23 20:19:17 LND02 named[9611]: client 63.217.28.226#13352: view external: query (cache) './NS/IN' denied Jan 23 20:19:18 LND02 named[9611]: client 63.217.28.226#55466: view external: query (cache) './NS/IN' denied Jan 23 20:19:18 LND02 named[9611]: client 63.217.28.226#24586: view external: query (cache) './NS/IN' denied Jan 23 20:19:19 LND02 named[9611]: client 63.217.28.226#43105: view external: query (cache) './NS/IN' denied On Fri, 2009-01-23 at 19:46 +0000, Steven Lisson wrote: > Hi, > > I agree with seeing no traffic to/from 66.230.128.15 but am still seeing flows 'from' 66.230.160.1 > > Regards, > Steve > > -----Original Message----- > From: Phil Rosenthal [mailto:pr at isprime.com] > Sent: Saturday, 24 January 2009 4:12 AM > To: nanog at nanog.org > Subject: Re: isprime DOS in progress > > Just a friendly notice, the attack against 66.230.128.15/66.230.160.1 > seems to have stopped for now. > > -Phil > On Jan 22, 2009, at 6:01 AM, Bj?rn Mork wrote: > > > Graeme Fowler writes: > > > >> I've been seeing a lot of noise from the latter two addresses after > >> switching on query logging (and finishing an application of Team > >> Cymru's > >> excellent template) so I decided to DROP traffic from the addresses > >> (with source port != 53) at the hosts in question. > >> > >> Well, blow me down if they didn't completely stop talking to me. Four > >> dropped packets each, and they've gone away. > >> > >> Something smells "not quite right" here - if the traffic is > >> spoofed, and > >> my "Refused" responses have been flying right back to the *real* IP > >> addresses, how are the spoofing hosts to know that I'm dropping the > >> traffic? > > > > Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping > > traffic from other sources too? Looks like some of the other source > > addresses are controlled by the DOSers. Possibly used to detect > > filters? > > > > These clients may look similar to the DOS attack, but there are subtle > > differences: > > > > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > > view external: query (cache) './NS/IN' denied > > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > > view external: query (cache) './NS/IN' denied > > Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: > > view external: query (cache) './NS/IN' denied > > Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: > > view external: query (cache) './NS/IN' denied > > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > > view external: query (cache) './NS/IN' denied > > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > > view external: query (cache) './NS/IN' denied > > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > > view external: query (cache) './NS/IN' denied > > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > > view external: query (cache) './NS/IN' denied > > Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: > > view external: query (cache) './NS/IN' denied > > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > > view external: query (cache) './NS/IN' denied > > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > > view external: query (cache) './NS/IN' denied > > Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: > > view external: query (cache) './NS/IN' denied > > Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: > > view external: query (cache) './NS/IN' denied > > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > > view external: query (cache) './NS/IN' denied > > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > > view external: query (cache) './NS/IN' denied > > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > > view external: query (cache) './NS/IN' denied > > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > > view external: query (cache) './NS/IN' denied > > Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: > > view external: query (cache) './NS/IN' denied > > Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: > > view external: query (cache) './NS/IN' denied > > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > > view external: query (cache) './NS/IN' denied > > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > > view external: query (cache) './NS/IN' denied > > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > > view external: query (cache) './NS/IN' denied > > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > > view external: query (cache) './NS/IN' denied > > Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: > > view external: query (cache) './NS/IN' denied > > > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > > view external: query (cache) './NS/IN' denied > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > > view external: query (cache) './NS/IN' denied > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > > view external: query (cache) './NS/IN' denied > > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > > view external: query (cache) './NS/IN' denied > > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > > view external: query (cache) './NS/IN' denied > > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > > view external: query (cache) './NS/IN' denied > > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > > view external: query (cache) './NS/IN' denied > > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > > view external: query (cache) './NS/IN' denied > > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > > view external: query (cache) './NS/IN' denied > > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > > view external: query (cache) './NS/IN' denied > > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > > view external: query (cache) './NS/IN' denied > > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > > view external: query (cache) './NS/IN' denied > > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > > view external: query (cache) './NS/IN' denied > > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > > view external: query (cache) './NS/IN' denied > > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > > view external: query (cache) './NS/IN' denied > > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > > view external: query (cache) './NS/IN' denied > > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > > view external: query (cache) './NS/IN' denied > > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > > view external: query (cache) './NS/IN' denied > > > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > > view external: query (cache) './NS/IN' denied > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > > view external: query (cache) './NS/IN' denied > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > > view external: query (cache) './NS/IN' denied > > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > > view external: query (cache) './NS/IN' denied > > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > > view external: query (cache) './NS/IN' denied > > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > > view external: query (cache) './NS/IN' denied > > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > > view external: query (cache) './NS/IN' denied > > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > > view external: query (cache) './NS/IN' denied > > Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: > > view external: query (cache) './NS/IN' denied > > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > > view external: query (cache) './NS/IN' denied > > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > > view external: query (cache) './NS/IN' denied > > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > > view external: query (cache) './NS/IN' denied > > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > > view external: query (cache) './NS/IN' denied > > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > > view external: query (cache) './NS/IN' denied > > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > > view external: query (cache) './NS/IN' denied > > Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: > > view external: query (cache) './NS/IN' denied > > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > > view external: query (cache) './NS/IN' denied > > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > > view external: query (cache) './NS/IN' denied > > > > > > Notice the pattern: > > 3 probes every 38 minutes > > Each probe from the same source port > > Source port increases slowly and steadily > > > > This looks like some application actually waiting for a response. The > > slow source port change is probably an indication that this client > > only > > tests a small number of DNS servers. I guess that this client is > > either > > one of the many bots used to send the spoofed requests, or maybe a bot > > not allowed to spoof its source and therefore used for other > > purposes. In any case, I assume that other DNS servers may see such > > control sessions coming from other addresses. > > > > These 3 clients started probing my DNS server almost simultaneously > > on January 8th: > > > > > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > > view external: query (cache) './NS/IN' denied > > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > > view external: query (cache) './NS/IN' denied > > > > Maybe preparing for the attack on ISPrime? I didn't start receiving > > spoofed requests from 66.230.128.15/66.230.160.1 before January 20th > > > > > > I just tried filtering the probing addresses. This made the probing > > stop immediately after dropping a set of 3 probes. But the spoofed > > requests continuted at the same rate as before, so this does not > > support > > my theory. > > > > However, I believe it would be too much of a coincidence if there > > isn't > > some connection between the probing and the DOS attack. It would be > > interesting to hear if others see similar probing. > > > > > > > > Bj?rn > > > > > From davidu at everydns.net Fri Jan 23 14:55:09 2009 From: davidu at everydns.net (David Ulevitch) Date: Fri, 23 Jan 2009 12:55:09 -0800 Subject: NetSol / WorldNIC nameservers continue to be down, for a couple days. Message-ID: <497A2EAD.5050000@everydns.net> Does anyone have any contact at NetSol / WorldNIC? Their nameservers (all hundred+ of them) have been down or severely degraded in service over the last 48 hours. TTLs are starting to expire and the only evidence we've found that NETSOL is aware is this thread: http://forums.networksolutions.com/announcements-f4-dns-issues-possible-impact-to-your-ecommerce-site-t3433.html#entry14382 Is there anyone here who can provide an update to the ISPs and SPs on this list? NetSol still (amazingly) manages to do DNS for a few hundred thousand domains... -David From woody at pch.net Fri Jan 23 14:58:54 2009 From: woody at pch.net (Bill Woodcock) Date: Fri, 23 Jan 2009 12:58:54 -0800 (PST) Subject: NetSol / WorldNIC nameservers continue to be down, for a couple days. In-Reply-To: <497A2EAD.5050000@everydns.net> References: <497A2EAD.5050000@everydns.net> Message-ID: On Fri, 23 Jan 2009, David Ulevitch wrote: > Does anyone have any contact at NetSol / WorldNIC? Yes. > Their nameservers (all hundred+ of them) have been down or severely > degraded in service over the last 48 hours. Yes, they're very well aware of it. They've been under very large-scale UDP/53 DDoS for that period of time. They're continuing to work the problem. -Bill From copraphage at gmail.com Fri Jan 23 15:21:52 2009 From: copraphage at gmail.com (Chris McDonald) Date: Fri, 23 Jan 2009 16:21:52 -0500 Subject: isprime DOS in progress In-Reply-To: <1232742035.3801.1.camel@localhost.localdomain> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> Message-ID: <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do the same :/ On Fri, Jan 23, 2009 at 3:20 PM, Luke Sheldrick wrote: > > Looks to me like the target has moved, anyone else seeing similar? > > Jan 23 20:19:08 LND02 named[9611]: client 63.217.28.226#39489: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:09 LND02 named[9611]: client 63.217.28.226#20558: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:11 LND02 named[9611]: client 63.217.28.226#38525: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:12 LND02 named[9611]: client 63.217.28.226#41535: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:12 LND02 named[9611]: client 63.217.28.226#51220: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:13 LND02 named[9611]: client 63.217.28.226#28869: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:14 LND02 named[9611]: client 63.217.28.226#12337: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:15 LND02 named[9611]: client 63.217.28.226#41346: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:15 LND02 named[9611]: client 63.217.28.226#56831: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:17 LND02 named[9611]: client 63.217.28.226#13352: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:18 LND02 named[9611]: client 63.217.28.226#55466: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:18 LND02 named[9611]: client 63.217.28.226#24586: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:19 LND02 named[9611]: client 63.217.28.226#43105: view > external: query (cache) './NS/IN' denied > > > > On Fri, 2009-01-23 at 19:46 +0000, Steven Lisson wrote: > > Hi, > > > > I agree with seeing no traffic to/from 66.230.128.15 but am still seeing flows 'from' 66.230.160.1 > > > > Regards, > > Steve > > > > -----Original Message----- > > From: Phil Rosenthal [mailto:pr at isprime.com] > > Sent: Saturday, 24 January 2009 4:12 AM > > To: nanog at nanog.org > > Subject: Re: isprime DOS in progress > > > > Just a friendly notice, the attack against 66.230.128.15/66.230.160.1 > > seems to have stopped for now. > > > > -Phil > > On Jan 22, 2009, at 6:01 AM, Bj?rn Mork wrote: > > > > > Graeme Fowler writes: > > > > > >> I've been seeing a lot of noise from the latter two addresses after > > >> switching on query logging (and finishing an application of Team > > >> Cymru's > > >> excellent template) so I decided to DROP traffic from the addresses > > >> (with source port != 53) at the hosts in question. > > >> > > >> Well, blow me down if they didn't completely stop talking to me. Four > > >> dropped packets each, and they've gone away. > > >> > > >> Something smells "not quite right" here - if the traffic is > > >> spoofed, and > > >> my "Refused" responses have been flying right back to the *real* IP > > >> addresses, how are the spoofing hosts to know that I'm dropping the > > >> traffic? > > > > > > Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping > > > traffic from other sources too? Looks like some of the other source > > > addresses are controlled by the DOSers. Possibly used to detect > > > filters? > > > > > > These clients may look similar to the DOS attack, but there are subtle > > > differences: > > > > > > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: > > > view external: query (cache) './NS/IN' denied > > > Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: > > > view external: query (cache) './NS/IN' denied > > > > > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > > > view external: query (cache) './NS/IN' denied > > > Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: > > > view external: query (cache) './NS/IN' denied > > > > > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > > > view external: query (cache) './NS/IN' denied > > > Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: > > > view external: query (cache) './NS/IN' denied > > > > > > > > > Notice the pattern: > > > 3 probes every 38 minutes > > > Each probe from the same source port > > > Source port increases slowly and steadily > > > > > > This looks like some application actually waiting for a response. The > > > slow source port change is probably an indication that this client > > > only > > > tests a small number of DNS servers. I guess that this client is > > > either > > > one of the many bots used to send the spoofed requests, or maybe a bot > > > not allowed to spoof its source and therefore used for other > > > purposes. In any case, I assume that other DNS servers may see such > > > control sessions coming from other addresses. > > > > > > These 3 clients started probing my DNS server almost simultaneously > > > on January 8th: > > > > > > > > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > > > view external: query (cache) './NS/IN' denied > > > Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: > > > view external: query (cache) './NS/IN' denied > > > > > > Maybe preparing for the attack on ISPrime? I didn't start receiving > > > spoofed requests from 66.230.128.15/66.230.160.1 before January 20th > > > > > > > > > I just tried filtering the probing addresses. This made the probing > > > stop immediately after dropping a set of 3 probes. But the spoofed > > > requests continuted at the same rate as before, so this does not > > > support > > > my theory. > > > > > > However, I believe it would be too much of a coincidence if there > > > isn't > > > some connection between the probing and the DOS attack. It would be > > > interesting to hear if others see similar probing. > > > > > > > > > > > > Bj?rn > > > > > > > > > > > From chort at smtps.net Fri Jan 23 16:26:43 2009 From: chort at smtps.net (Brian Keefer) Date: Fri, 23 Jan 2009 14:26:43 -0800 Subject: isprime DOS in progress In-Reply-To: <1232742035.3801.1.camel@localhost.localdomain> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> Message-ID: On Jan 23, 2009, at 12:20 PM, Luke Sheldrick wrote: > Looks to me like the target has moved, anyone else seeing similar? > > Jan 23 20:19:08 LND02 named[9611]: client 63.217.28.226#39489: view > external: query (cache) './NS/IN' denied > Jan 23 20:19:09 LND02 named[9611]: client 63.217.28.226#20558: view > external: query (cache) './NS/IN' denied > Seeing the same here, it's 1 query per second per nameserver--time to work some magic with PF. -- bk From chrome at stupendous.net Fri Jan 23 17:42:13 2009 From: chrome at stupendous.net (Nathan Ollerenshaw) Date: Sat, 24 Jan 2009 10:42:13 +1100 Subject: isprime DOS in progress In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com><20090120205514.GA10257@fries.net><1232557692.9593.57.camel@squonk.lboro.ac.uk><8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> Message-ID: <9A251497-E94C-4693-8E89-3FD3ACF6D138@stupendous.net> On 24/01/2009, at 6:46 AM, Steven Lisson wrote: > Hi, > > I agree with seeing no traffic to/from 66.230.128.15 but am still > seeing flows 'from' 66.230.160.1 > > Regards, > Steve Hi Steve, There is at least an iptables rule you can use to drop this specific query, assuming your nameservers run linux. http://www.stupendous.net/archives/2009/01/24/dropping-spurious-nsin-recursive-queries/ The bind-users mailing list suggested having the ISPs trace back the flows and find the networks emitting the spoofed packets, and have those networks implement BCP 38. While that's the 'right' solution (everyone should be doing ingress filtering, sure, impossible to argue against it), not every network out there is operated by people who give a damn. This will work at least until the kiddies improve their scripts to query for names that actually exist. On 24/01/2009, at 8:21 AM, Chris McDonald wrote: > We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do > the same :/ Good luck with that. Right now they're targetting ISPrime, and you've just made the DoS even more effective for them. With any luck, the rest of the world will follow suit and the bad guys win! yay! :) Short of getting the rest of the world to properly implement ingress filtering (ha, ha), I think dropping the specific packets that generate the reflected traffic is good enough for now. The load on the reflectors is minimal. Nathan. From Mark_Andrews at isc.org Fri Jan 23 18:00:21 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 24 Jan 2009 11:00:21 +1100 Subject: isprime DOS in progress In-Reply-To: Your message of "Sat, 24 Jan 2009 10:42:13 +1100." <9A251497-E94C-4693-8E89-3FD3ACF6D138@stupendous.net> Message-ID: <200901240000.n0O00L72046540@drugs.dv.isc.org> In message <9A251497-E94C-4693-8E89-3FD3ACF6D138 at stupendous.net>, Nathan Ollere nshaw writes: > On 24/01/2009, at 6:46 AM, Steven Lisson wrote: > > > Hi, > > > > I agree with seeing no traffic to/from 66.230.128.15 but am still > > seeing flows 'from' 66.230.160.1 > > > > Regards, > > Steve > > Hi Steve, > > There is at least an iptables rule you can use to drop this specific > query, assuming your nameservers run linux. > > http://www.stupendous.net/archives/2009/01/24/dropping-spurious-nsin-recursiv > e-queries/ > > The bind-users mailing list suggested having the ISPs trace back the > flows and find the networks emitting the spoofed packets, and have > those networks implement BCP 38. It was also said here. > While that's the 'right' solution > (everyone should be doing ingress filtering, sure, impossible to argue > against it), not every network out there is operated by people who > give a damn. I would suggest that you don't want to peer with such networks. I would suggest that deploying BCP 38 be a requirement for peering. > This will work at least until the kiddies improve their scripts to > query for names that actually exist. > > On 24/01/2009, at 8:21 AM, Chris McDonald wrote: > > > We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do > > the same :/ > > Good luck with that. Right now they're targetting ISPrime, and you've > just made the DoS even more effective for them. With any luck, the > rest of the world will follow suit and the bad guys win! yay! :) > > Short of getting the rest of the world to properly implement ingress > filtering (ha, ha), I think dropping the specific packets that > generate the reflected traffic is good enough for now. The load on the > reflectors is minimal. > > Nathan. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jlewis at lewis.org Fri Jan 23 19:22:08 2009 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 23 Jan 2009 20:22:08 -0500 (EST) Subject: TWTelecom routing instability Message-ID: Is anyone else seeing routing instability from Time Warner Telecom? We were seeing enough route-flap to upset a lightly loaded sup720-3bxl. I've enabled dampening, which we don't normally use these days, and am considering shutting the session. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From noel.butler at ausics.net Fri Jan 23 19:50:24 2009 From: noel.butler at ausics.net (Noel Butler) Date: Sat, 24 Jan 2009 11:50:24 +1000 Subject: isprime DOS in progress In-Reply-To: <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> Message-ID: <1232761823.25013.5.camel@roswell.ausics.net> On Sat, 2009-01-24 at 07:21, Chris McDonald wrote: > We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do the same :/ > Wrong approach, they are *innocent* in this as are the new targets. insert into your favourite acl: deny udp host 66.230.160.1 neq 53 any eq 53 deny udp host 66.230.128.15 neq 53 any eq 53 But it's much less work to add a filter on the name server as others have mentioned. From sethm at rollernet.us Fri Jan 23 20:05:43 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 23 Jan 2009 18:05:43 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <1232761823.25013.5.camel@roswell.ausics.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> Message-ID: <497A7777.2060003@rollernet.us> Noel Butler wrote: > On Sat, 2009-01-24 at 07:21, Chris McDonald wrote: > >> We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do the same :/ >> > > > > Wrong approach, they are *innocent* in this as are the new targets. > > insert into your favourite acl: > deny udp host 66.230.160.1 neq 53 any eq 53 > deny udp host 66.230.128.15 neq 53 any eq 53 > > But it's much less work to add a filter on the name server as others > have mentioned. > > Having the world trying to keep up with ACL entries seems futile. Is there really nothing to be done about this? (Yes, I know, BCP38, but obviously the accomplice providers don't care.) ~Seth From jeffrey.lyon at blacklotus.net Fri Jan 23 20:13:33 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 23 Jan 2009 21:13:33 -0500 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497A7777.2060003@rollernet.us> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> Message-ID: <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> I respectfully disagree. Network engineers have to keep up with many tasks and preventing DoS/DDoS should be the responsibility of everyone. I see more folks worried about spam than they are actual security. My two cents. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. On Fri, Jan 23, 2009 at 9:05 PM, Seth Mattinen wrote: > Noel Butler wrote: >> >> On Sat, 2009-01-24 at 07:21, Chris McDonald wrote: >> >>> We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do the >>> same :/ >>> >> >> >> >> Wrong approach, they are *innocent* in this as are the new targets. >> >> insert into your favourite acl: >> deny udp host 66.230.160.1 neq 53 any eq 53 >> deny udp host 66.230.128.15 neq 53 any eq 53 >> >> But it's much less work to add a filter on the name server as others >> have mentioned. >> >> > > > Having the world trying to keep up with ACL entries seems futile. Is there > really nothing to be done about this? (Yes, I know, BCP38, but obviously the > accomplice providers don't care.) > > ~Seth > > From ge at linuxbox.org Fri Jan 23 20:17:41 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 23 Jan 2009 20:17:41 -0600 (CST) Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> Message-ID: On Fri, 23 Jan 2009, Jeffrey Lyon wrote: > I respectfully disagree. Network engineers have to keep up with many > tasks and preventing DoS/DDoS should be the responsibility of > everyone. I see more folks worried about spam than they are actual > security. Because non of us wantsto spend the next two days working on fixing mail for our organizations. That said, when speaking of DDoS, I believe they are mostly the same bots. And yes, while there is a lot we can do to mitigate DDoS, we are that helpless. All our strategies show as much. Gadi. From sethm at rollernet.us Fri Jan 23 20:33:14 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 23 Jan 2009 18:33:14 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> Message-ID: <497A7DEA.1090605@rollernet.us> Jeffrey Lyon wrote: > I respectfully disagree. Network engineers have to keep up with many > tasks and preventing DoS/DDoS should be the responsibility of > everyone. I see more folks worried about spam than they are actual > security. > Back to my original question: is there really not a better solution? ~Seth From Valdis.Kletnieks at vt.edu Fri Jan 23 21:31:59 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Jan 2009 22:31:59 -0500 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: Your message of "Fri, 23 Jan 2009 18:33:14 PST." <497A7DEA.1090605@rollernet.us> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> Message-ID: <80022.1232767919@turing-police.cc.vt.edu> On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said: > Back to my original question: is there really not a better solution? Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4 baseball-bat wielding professional explainers to go explain our position to them. Figuring out how to do so without breaking any laws is the tough part... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From brandon.galbraith at gmail.com Fri Jan 23 21:34:37 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 23 Jan 2009 21:34:37 -0600 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497A7DEA.1090605@rollernet.us> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> Message-ID: <366100670901231934l34243a0fuabd43f7cc5abc13e@mail.gmail.com> On 1/23/09, Seth Mattinen wrote: > > Jeffrey Lyon wrote: > >> I respectfully disagree. Network engineers have to keep up with many >> tasks and preventing DoS/DDoS should be the responsibility of >> everyone. I see more folks worried about spam than they are actual >> security. >> >> > Back to my original question: is there really not a better solution? > > ~Seth > > When in doubt, throw more capacity at it. I'm only half-kidding. Sometimes that's the cheaper solution depending on the problem. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From jal at jal.org Fri Jan 23 21:50:09 2009 From: jal at jal.org (Jamie A Lawrence) Date: Fri, 23 Jan 2009 22:50:09 -0500 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <80022.1232767919@turing-police.cc.vt.edu> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> Message-ID: On Jan 23, 2009, at 10:31 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said: > >> Back to my original question: is there really not a better solution? > > Well, we *could* hunt down the perpetrators, pool some $$, and hire > 3 or 4 > baseball-bat wielding professional explainers to go explain our > position to > them. Figuring out how to do so without breaking any laws is the > tough part.. The Cameros or SUVs and baseball bats are normally not in sync with local legal traditions, depending on your local legal statutes. A certain ISP in California, however, seems to have learned a more subtle lesson, perhaps with left more satisfying results. And while I don't think that is any serious fix, I also think that there might well be a deterrence effect, to whatever extent that works - it might not kill a system, but it can provide deterrence. Hell, I expect the perpetrator for this attack to be on this list. So it becomes more more step on the arms race. From frnkblk at iname.com Fri Jan 23 21:58:56 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 23 Jan 2009 21:58:56 -0600 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497A7777.2060003@rollernet.us> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> Message-ID: What's interesting in all of this is that ISPrime has been experiencing this for most of this week, yet not them or any of us has shared a network that is sourcing this traffic. I know I haven't bothered asking my upstream provider which backbone provider is sending them the "ISPrime" traffic, so I'm just as guilty as anyone. Frank -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Friday, January 23, 2009 8:06 PM To: nanog at nanog.org Subject: Are we really this helpless? (Re: isprime DOS in progress) Noel Butler wrote: > On Sat, 2009-01-24 at 07:21, Chris McDonald wrote: > >> We [AS3491] null0'd the IP earlier. Rest-of-world encouraged to do the same :/ > > Wrong approach, they are *innocent* in this as are the new targets. > > insert into your favourite acl: > deny udp host 66.230.160.1 neq 53 any eq 53 > deny udp host 66.230.128.15 neq 53 any eq 53 > > But it's much less work to add a filter on the name server as others > have mentioned. Having the world trying to keep up with ACL entries seems futile. Is there really nothing to be done about this? (Yes, I know, BCP38, but obviously the accomplice providers don't care.) ~Seth From j at arpa.com Fri Jan 23 22:07:42 2009 From: j at arpa.com (jamie rishaw) Date: Fri, 23 Jan 2009 22:07:42 -0600 Subject: NetSol / WorldNIC nameservers continue to be down, for a couple days. In-Reply-To: <497A2EAD.5050000@everydns.net> References: <497A2EAD.5050000@everydns.net> Message-ID: On Fri, Jan 23, 2009 at 2:55 PM, David Ulevitch wrote: > > Is there anyone here who can provide an update to the ISPs and SPs on this > list? NetSol still (amazingly) manages to do DNS for a few hundred thousand > domains... > > -David > I'm counting a whole lot more than that. I see 1.9 _million_ domains in .com alone. Altho, I just tested a random-ish sample of 1,000 of them and got sub-75msec response times, so, the issues may be resolved. In either case , sounds like they need to rock UltraDNS, eh? :p -j -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. From morrowc.lists at gmail.com Fri Jan 23 22:10:38 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 Jan 2009 23:10:38 -0500 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <80022.1232767919@turing-police.cc.vt.edu> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> Message-ID: <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> On Fri, Jan 23, 2009 at 10:31 PM, wrote: > On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said: > >> Back to my original question: is there really not a better solution? > > Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4 > baseball-bat wielding professional explainers to go explain our position to > them. Figuring out how to do so without breaking any laws is the tough part... Step one, find a device on your netowrk seeing the traffic step two, follow the stream(s) of traffic back to its ingress (hopefully a customer link on your network) step three, watch for associated traffic to the source of the dns queries, correlate this with other sources on your network to find/identify the control point for this effort. -chris From danny at tcb.net Fri Jan 23 22:53:32 2009 From: danny at tcb.net (Danny McPherson) Date: Fri, 23 Jan 2009 21:53:32 -0700 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> Message-ID: On Jan 23, 2009, at 9:10 PM, Christopher Morrow wrote: > On Fri, Jan 23, 2009 at 10:31 PM, wrote: >> On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said: >> >>> Back to my original question: is there really not a better solution? >> >> Well, we *could* hunt down the perpetrators, pool some $$, and hire >> 3 or 4 >> baseball-bat wielding professional explainers to go explain our >> position to >> them. Figuring out how to do so without breaking any laws is the >> tough part... > > Step one, find a device on your netowrk seeing the traffic > step two, follow the stream(s) of traffic back to its ingress > (hopefully a customer link on your network) > step three, watch for associated traffic to the source of the dns > queries, correlate this with other sources on your network to > find/identify the control point for this effort. You missed one.. Step 4: enable BCP 38 or similar ingress source address spoofing mitigation mechanism on all customer ingress interfaces (note: uRPF *loose* mode no-fixie these attacks) - as you should have had in the first place such that you didn't have to trace those spoof packets step-by-step back through your network. No more excuses, people.. -danny From drc at virtualized.org Fri Jan 23 23:06:28 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 23 Jan 2009 21:06:28 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> Message-ID: <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> On Jan 23, 2009, at 8:53 PM, Danny McPherson wrote: > You missed one.. Step 4: enable BCP 38 or similar > ingress source address spoofing mitigation mechanism > on all customer ingress interfaces > ... > No more excuses, people.. Sad fact is that there are zillions of excuses. Unfortunately I suspect the only way we're going to make any progress on this will be for laws to be passed (or lawsuits to be filed) that impose a financial penalty on ISPs through which these attacks propagate. Regards, -drc From danny at tcb.net Fri Jan 23 23:16:24 2009 From: danny at tcb.net (Danny McPherson) Date: Fri, 23 Jan 2009 22:16:24 -0700 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> Message-ID: <6756136A-D372-42AF-A68C-F81883B6BB7B@tcb.net> On Jan 23, 2009, at 10:06 PM, David Conrad wrote: > > Sad fact is that there are zillions of excuses. Unfortunately I > suspect the only way we're going to make any progress on this will > be for laws to be passed (or lawsuits to be filed) that impose a > financial penalty on ISPs through which these attacks propagate. Yep, some external force is apparently necessary, unfortunately. We've been encouraging, and asking, and measuring intensely for over a dozen years now, and the application of anti- spoofing is still dismal < ~60%). I used to be sympathetic to the arguments about infrastructure support, resources, tools, etc.. I consider those argument no longer valid and operators who don't implement ingress BCP 38 style filtering remiss. -danny From jbates at brightok.net Fri Jan 23 23:34:36 2009 From: jbates at brightok.net (Jack Bates) Date: Fri, 23 Jan 2009 23:34:36 -0600 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> Message-ID: <497AA86C.7050609@brightok.net> David Conrad wrote: > Sad fact is that there are zillions of excuses. Unfortunately I suspect > the only way we're going to make any progress on this will be for laws > to be passed (or lawsuits to be filed) that impose a financial penalty > on ISPs through which these attacks propagate. Careful what you ask for. You might get it, and I'm sure the outcome wouldn't be liked by any. Forgery is bad, but I've seen plenty of DDoS without forgery that can do serious damage. Forgery just makes analysis and back tracking harder. Getting sued because you had some stealth botnet that suddenly fires up is not a good deal; and probably why ISP's still manage to hold onto some immunities. OT, though, I'm sure. The last DoS with forgery that I asked a provider to backtrack, in the small hopes that it was a concentrated attack with forgery and not a forging botnet, was met with "flows? tracking? We can't see anything. We'll happily remove the block so you can see if it's still going on if you want." Now I have fun trying to explain towards upstream management why a good security team and policy is important in anyone we purchase transit from. I think they understand it about as much as the transit providers did. Even when tracked, it is rare that you can get enough interest, time or technical ability to backtrack to a controller. Gaining access to the infected machine and grabbing the bot code is even more rare. That being said, a lot of botnets are already monitored and watched. Unfortunately, there are legal issues when they cross international boundaries; just as there are with child exploitation sites which are hosted in places that are more accepting/tolerant of such things. Jack From rdobbins at cisco.com Sat Jan 24 00:04:17 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Sat, 24 Jan 2009 14:04:17 +0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497AA86C.7050609@brightok.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> <497AA86C.7050609@brightok.net> Message-ID: On Jan 24, 2009, at 1:34 PM, Jack Bates wrote: > Now I have fun trying to explain towards upstream management why a > good security team and policy is important in anyone we purchase > transit from. Apart from commercial DDoS mitigation services, how many folks have SLAs which specify DoS-related response-times, ETRs, specify levels of service degradation, et. al. as part of their transit contracts, peering agreements, hosting/co-location agreements, etc.? How many end-customers have these terms written into their contracts with their SPs? Has anyone ever de-peered or terminated a transit or hosting/co- location relationship specifically due to DoS issues? If so, was it based upon specific contractual clauses related to DoS, or was some other metric used to justify ending the arrangement (i.e., non- adherence to traffic ratios due to DoS traffic, or other effects)? Did you have to pay a termination fee to get out of the arrangement? ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From fw at deneb.enyo.de Sat Jan 24 08:58:43 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 24 Jan 2009 15:58:43 +0100 Subject: inauguration streams review In-Reply-To: <60C736580784448E8881314F3E51952D@GINKGO> (Adam Greene's message of "Thu, 22 Jan 2009 09:08:30 -0500") References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> <2ad0f9f60901211101k57d902do43d8f46a3f2ece5d@mail.gmail.com> <60C736580784448E8881314F3E51952D@GINKGO> Message-ID: <87bptw4uos.fsf@mid.deneb.enyo.de> * Adam Greene: > Hi, quick question ... > > Most people here said they saw most of the inauguration traffic on > TCP1935 to Limelight and UDP8247 to CNN. However, we were seeing it > simply as "http" traffic (i.e. port 80), which made it very difficult > to manage. Our inbound bandwidth was effectively maxed out for about 6 > hours. 80/TCP is often used as fallback if the other methods fail to work. Have you got any filters on your network which might cause this? From Jon.Kibler at aset.com Sat Jan 24 09:01:23 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Sat, 24 Jan 2009 10:01:23 -0500 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <80022.1232767919@turing-police.cc.vt.edu> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> Message-ID: <497B2D43.6090105@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valdis.Kletnieks at vt.edu wrote: > Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4 > baseball-bat wielding professional explainers to go explain our position to > them. Figuring out how to do so without breaking any laws is the tough part... > But if they were in eastern Europe or Russia, wouldn't that solution be considered standard business practice and thus be legal? Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl7LUMACgkQUVxQRc85QlNCjQCdF1UAaO7sCU5rTN6xoN7UrDX9 EL4AoKKTLj0U5sAWsMinCRot10BFB0Go =WHAs -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From fobdfc at gmail.com Sat Jan 24 10:29:09 2009 From: fobdfc at gmail.com (Mike) Date: Sat, 24 Jan 2009 10:29:09 -0600 Subject: inauguration streams review In-Reply-To: <87bptw4uos.fsf@mid.deneb.enyo.de> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> <2ad0f9f60901211101k57d902do43d8f46a3f2ece5d@mail.gmail.com> <60C736580784448E8881314F3E51952D@GINKGO> <87bptw4uos.fsf@mid.deneb.enyo.de> Message-ID: On Sat, Jan 24, 2009 at 8:58 AM, Florian Weimer wrote: > * Adam Greene: > >> Hi, quick question ... >> >> Most people here said they saw most of the inauguration traffic on >> TCP1935 to Limelight and UDP8247 to CNN. However, we were seeing it >> simply as "http" traffic (i.e. port 80), which made it very difficult >> to manage. Our inbound bandwidth was effectively maxed out for about 6 >> hours. > > 80/TCP is often used as fallback if the other methods fail to work. > Have you got any filters on your network which might cause this? > > This was our case. Websense blocked all the streaming protocols and p2p by default. It was difficult to isolate our legitimate business traffic from the streaming content sine it was all port 80/TCP/HTTP. Throughout the morning I was adding in streaming sites as they came in. We fared pretty well considering only one customer complaint and we were able to maintain 92% utilization or internet bandwidth(one point of saturation @ 98%). From jdfalk-lists at cybernothing.org Sat Jan 24 11:24:36 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Sat, 24 Jan 2009 10:24:36 -0700 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497A7DEA.1090605@rollernet.us> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> Message-ID: <497B4ED4.9090305@cybernothing.org> Seth Mattinen wrote: > Jeffrey Lyon wrote: >> I respectfully disagree. Network engineers have to keep up with many >> tasks and preventing DoS/DDoS should be the responsibility of >> everyone. I see more folks worried about spam than they are actual >> security. >> > > Back to my original question: is there really not a better solution? This sounds a lot like the conversations which led to the creation of the original Realtime Blackhole List of spam sources. When was that, 1996? -- J.D. Falk Return Path Inc http://www.returnpath.net/ From hank at efes.iucc.ac.il Sat Jan 24 12:15:24 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 24 Jan 2009 20:15:24 +0200 (IST) Subject: inauguration streams review In-Reply-To: <87bptw4uos.fsf@mid.deneb.enyo.de> References: <200901201924.n0KJOsLr032637@stark.hevanet.com> <1b5c1c150901201128s712e018ck23376dc28122a61a@mail.gmail.com> <2ad0f9f60901201149r440551a4l6fca04261aed908@mail.gmail.com> <2ad0f9f60901211049u99e6eb7ue8efa8d2be3acfeb@mail.gmail.com> <1b5c1c150901211052v1b51d88fg4974887ef4a91a67@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01F2592D@nexus.nexicomgroup.net> <2ad0f9f60901211101k57d902do43d8f46a3f2ece5d@mail.gmail.com> <60C736580784448E8881314F3E51952D@GINKGO> <87bptw4uos.fsf@mid.deneb.enyo.de> Message-ID: Obama inauguration sets Web traffic record, Akamai says http://www.networkworld.com/news/2009/012109-obama-inauguration-web-traffic.html -Hank From sethm at rollernet.us Sat Jan 24 12:18:51 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 24 Jan 2009 10:18:51 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497B4ED4.9090305@cybernothing.org> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <497B4ED4.9090305@cybernothing.org> Message-ID: <497B5B8B.6040705@rollernet.us> J.D. Falk wrote: > Seth Mattinen wrote: >> Jeffrey Lyon wrote: >>> I respectfully disagree. Network engineers have to keep up with many >>> tasks and preventing DoS/DDoS should be the responsibility of >>> everyone. I see more folks worried about spam than they are actual >>> security. >>> >> >> Back to my original question: is there really not a better solution? > > This sounds a lot like the conversations which led to the creation of > the original Realtime Blackhole List of spam sources. When was that, 1996? > Perhaps the time has come for a BGP blackhole list like the bogon routes one. Who wants to become a target? ;) ~Seth From chort at smtps.net Sat Jan 24 13:03:57 2009 From: chort at smtps.net (Brian Keefer) Date: Sat, 24 Jan 2009 11:03:57 -0800 Subject: isprime DOS in progress In-Reply-To: <1232742035.3801.1.camel@localhost.localdomain> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> Message-ID: <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> On Jan 23, 2009, at 12:20 PM, Luke Sheldrick wrote: > Looks to me like the target has moved, anyone else seeing similar? It's switched again. The new target is 206.71.158.30 . Over night it cycled through several different IPs (testing the waters?), and finally started on this one around 10:26 Pacific time this morning. Timeline below. -- bk Jan 23 23:24:47 imhotep named[32762]: client 63.217.28.226#53: view ext: query (cache) './NS/IN' denied Jan 24 00:51:11 imhotep named[32762]: client 208.78.169.236#33027: view ext: query (cache) './NS/IN' denied Jan 24 00:51:11 imhotep last message repeated 2 times Jan 24 00:51:11 imhotep named[32762]: client 204.11.51.60#32831: view ext: query (cache) './NS/IN' denied Jan 24 00:51:11 imhotep last message repeated 2 times Jan 24 00:51:30 imhotep named[32762]: client 208.37.177.61#42517: view ext: query (cache) './NS/IN' denied Jan 24 00:51:30 imhotep last message repeated 2 times Jan 24 01:54:44 imhotep named[32762]: client 208.37.177.61#42517: view ext: query (cache) './NS/IN' denied Jan 24 01:54:44 imhotep last message repeated 2 times Jan 24 01:55:44 imhotep named[32762]: client 204.11.51.60#32831: view ext: query (cache) './NS/IN' denied Jan 24 01:55:44 imhotep last message repeated 2 times Jan 24 01:57:46 imhotep named[32762]: client 208.78.169.235#46265: view ext: query (cache) './NS/IN' denied Jan 24 01:57:46 imhotep last message repeated 2 times Jan 24 02:58:29 imhotep named[32762]: client 208.37.177.62#46265: view ext: query (cache) './NS/IN' denied Jan 24 02:58:30 imhotep last message repeated 2 times Jan 24 03:00:34 imhotep named[32762]: client 204.11.51.60#32831: view ext: query (cache) './NS/IN' denied Jan 24 03:00:35 imhotep last message repeated 2 times Jan 24 03:05:05 imhotep named[32762]: client 208.78.169.236#33027: view ext: query (cache) './NS/IN' denied Jan 24 03:05:05 imhotep last message repeated 2 times Jan 24 03:07:49 imhotep named[32762]: client 63.217.28.226#53: view ext: query (cache) './NS/IN' denied Jan 24 04:02:38 imhotep named[32762]: client 208.37.177.61#42517: view ext: query (cache) './NS/IN' denied Jan 24 04:02:38 imhotep last message repeated 2 times Jan 24 04:05:43 imhotep named[32762]: client 204.11.51.59#32802: view ext: query (cache) './NS/IN' denied Jan 24 04:05:43 imhotep last message repeated 2 times Jan 24 04:12:52 imhotep named[32762]: client 208.78.169.234#42517: view ext: query (cache) './NS/IN' denied Jan 24 04:12:52 imhotep last message repeated 2 times Jan 24 05:07:37 imhotep named[32762]: client 208.37.177.61#42517: view ext: query (cache) './NS/IN' denied Jan 24 05:07:37 imhotep last message repeated 2 times Jan 24 05:11:35 imhotep named[32762]: client 204.11.51.59#32802: view ext: query (cache) './NS/IN' denied Jan 24 05:11:35 imhotep last message repeated 2 times Jan 24 05:21:36 imhotep named[32762]: client 208.78.169.234#42517: view ext: query (cache) './NS/IN' denied Jan 24 05:21:37 imhotep last message repeated 2 times Jan 24 06:16:06 imhotep named[32762]: client 208.37.177.62#46265: view ext: query (cache) './NS/IN' denied Jan 24 06:16:06 imhotep last message repeated 2 times Jan 24 06:20:19 imhotep named[32762]: client 204.11.51.61#43329: view ext: query (cache) './NS/IN' denied Jan 24 06:20:19 imhotep last message repeated 2 times Jan 24 06:29:37 imhotep named[32762]: client 208.78.169.235#46265: view ext: query (cache) './NS/IN' denied Jan 24 06:29:37 imhotep last message repeated 2 times Jan 24 06:35:11 imhotep named[32762]: client 149.20.52.161#61452: view ext: notify question section contains no SOA Jan 24 07:23:06 imhotep named[32762]: client 208.37.177.61#42517: view ext: query (cache) './NS/IN' denied Jan 24 07:23:06 imhotep last message repeated 2 times Jan 24 07:28:27 imhotep named[32762]: client 204.11.51.60#32831: view ext: query (cache) './NS/IN' denied Jan 24 07:28:27 imhotep last message repeated 2 times Jan 24 07:40:25 imhotep named[32762]: client 208.78.169.234#42517: view ext: query (cache) './NS/IN' denied Jan 24 07:40:25 imhotep last message repeated 2 times Jan 24 08:29:57 imhotep named[32762]: client 208.37.177.61#42517: view ext: query (cache) './NS/IN' denied Jan 24 08:29:57 imhotep last message repeated 2 times Jan 24 08:36:10 imhotep named[32762]: client 204.11.51.61#43330: view ext: query (cache) './NS/IN' denied Jan 24 08:36:11 imhotep last message repeated 2 times Jan 24 08:52:45 imhotep named[32762]: client 208.78.169.235#46265: view ext: query (cache) './NS/IN' denied Jan 24 08:52:45 imhotep last message repeated 2 times Jan 24 08:55:54 imhotep named[32762]: client 149.20.58.131#59151: view ext: query (cache) 'localhost/A/IN' denied Jan 24 09:36:38 imhotep named[32762]: client 208.37.177.62#46265: view ext: query (cache) './NS/IN' denied Jan 24 09:36:38 imhotep last message repeated 2 times Jan 24 09:43:53 imhotep named[32762]: client 204.11.51.61#43330: view ext: query (cache) './NS/IN' denied Jan 24 09:43:54 imhotep last message repeated 2 times Jan 24 09:53:56 imhotep named[32762]: client 63.217.28.226#53: view ext: query (cache) './NS/IN' denied Jan 24 10:05:28 imhotep named[32762]: client 208.78.169.234#42517: view ext: query (cache) './NS/IN' denied Jan 24 10:05:28 imhotep last message repeated 2 times Jan 24 10:26:09 imhotep named[32762]: client 206.71.158.30#18971: view ext: query (cache) './NS/IN' denied Jan 24 10:26:11 imhotep named[32762]: client 206.71.158.30#47622: view ext: query (cache) './NS/IN' denied Jan 24 10:26:13 imhotep named[32762]: client 206.71.158.30#16077: view ext: query (cache) './NS/IN' denied From wavetossed at googlemail.com Sat Jan 24 13:57:18 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Sat, 24 Jan 2009 19:57:18 +0000 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497B2D43.6090105@aset.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <497B2D43.6090105@aset.com> Message-ID: <877585b00901241157tff7879dub9ff412cc0de950d@mail.gmail.com> > > > But if they were in eastern Europe or Russia, wouldn't that solution be > considered standard business practice and thus be legal? > Assuming that you really believe such an outrageous statement, I went to to search for stories about people being arrested for the behavior that you think is "legal". Interestingly, the first story on the front page is about such an arrest, and you can type "arrest" into the search box to find several other stories. Note that the Moscow Times is an English language newspaper in Russia that tends to be critical of the government. But at least it is written by people who live there and who have a much better idea of what is going on than the folklore that is reported on in the West. Yes, this is network operational, because the Internet is a global network, and you really do need to understand that the majority of network operators in Eastern Europe or Russia, are not out to get you. If you have operational issues with them you should contact them directly and sort it out. The criminal elements in cyberspace are also criminals in their own country and very few network operators are actually in league with them. Treat other network operators as innocent unless they are proven guilty. For instance go to , click on the Union Jack flag for English language version and then on the Conference link for the 7th Nov 2008 to see presentations from Finland, Estonia, Bulgaria, and Russia. Some of the slides are even in English, or English and Russian. And if you attend one of the RIPE meetings in Europe you can actually meet network operators from these countries and learn that they are pretty much like you, running a business and sorting out problems. -- Michael Dillon From cidr-report at potaroo.net Fri Jan 23 05:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Jan 2009 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200901231100.n0NB022R041773@wattle.apnic.net> This report has been generated at Fri Jan 23 21:13:36 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 Prefixes CIDR Agg 16-01-09 285123 176930 17-01-09 285171 176972 18-01-09 285278 177127 19-01-09 285289 177273 20-01-09 285498 177701 21-01-09 285484 177557 22-01-09 285700 177790 23-01-09 286053 177844 AS Summary 30445 Number of ASes in routing system 12948 Number of ASes announcing only one prefix 4378 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89878272 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'). --- 23Jan09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 285882 177862 108020 37.8% All ASes AS6389 4378 356 4022 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4204 1739 2465 58.6% TWTC - tw telecom holdings, inc. AS209 2833 1270 1563 55.2% ASN-QWEST - Qwest Communications Corporation AS4766 1770 498 1272 71.9% KIXS-AS-KR Korea Telecom AS17488 1493 344 1149 77.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1190 218 972 81.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 999 59 940 94.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1479 611 868 58.7% Uninet S.A. de C.V. AS1785 1793 1006 787 43.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS11492 1219 456 763 62.6% CABLEONE - CABLE ONE, INC. AS19262 944 246 698 73.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 922 242 680 73.8% TEDATA TEDATA AS2386 1575 900 675 42.9% INS-AS - AT&T Data Communications Services AS3356 1131 482 649 57.4% LEVEL3 Level 3 Communications AS18101 770 135 635 82.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS18566 1060 465 595 56.1% COVAD - Covad Communications Co. AS6478 1196 656 540 45.2% ATT-INTERNET3 - AT&T WorldNet Services AS2706 545 25 520 95.4% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS7545 700 181 519 74.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS20115 2033 1547 486 23.9% CHARTER-NET-HKY-NC - Charter Communications AS17908 599 118 481 80.3% TCISL Tata Communications AS855 595 137 458 77.0% CANET-ASN-4 - Bell Aliant AS4808 612 158 454 74.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1435 995 440 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS22047 563 127 436 77.4% VTR BANDA ANCHA S.A. AS4134 902 475 427 47.3% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 660 239 421 63.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 698 283 415 59.5% LGNET-AS-KR LG CNS AS9443 504 92 412 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 527 115 412 78.2% GIGAINFRA BB TECHNOLOGY Corp. Total 39329 14175 25154 64.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.208.128.0/18 AS8346 SONATEL-AS Autonomous System 41.214.0.0/17 AS8346 SONATEL-AS Autonomous System 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.132.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.133.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.134.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.135.0/24 AS12491 IPPLANET-AS IPPlanet 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.12.96.0/19 AS15834 MENANET-AS MenaNet network Autonomous System 62.12.107.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.68.32.0/19 AS21003 GPTC-AS GPTC Autonomous System, Tripoli Libya 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 81.4.0.0/18 AS15834 MENANET-AS MenaNet network Autonomous System 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.40.192.0/19 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 155.254.0.0/16 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.43.64.0/19 AS33765 TTCLDATA AS FOR TTCL 196.43.80.0/20 AS33765 TTCLDATA AS FOR TTCL 196.46.96.0/20 AS33765 TTCLDATA AS FOR TTCL 196.46.104.0/21 AS33765 TTCLDATA AS FOR TTCL 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.192.0/18 AS8346 SONATEL-AS Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.67.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.69.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.71.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.74.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.75.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.77.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.78.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.233.204.0/22 AS22446 MEDLINE - Medline Industries 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.100.64.0/21 AS1273 CW Cable and Wireless plc 212.100.64.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.65.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.66.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.68.0/22 AS1273 CW Cable and Wireless plc 212.100.68.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.69.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.71.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.72.0/24 AS29835 NSS-CA - New Skies Satellites, Inc. 212.100.73.0/24 AS29835 NSS-CA - New Skies Satellites, Inc. 213.154.64.0/19 AS8346 SONATEL-AS Autonomous System 213.154.90.0/24 AS30985 IKATELNET 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.128.0/20 AS15834 MENANET-AS MenaNet network Autonomous System 217.29.134.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 23 05:00:06 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Jan 2009 22:00:06 +1100 (EST) Subject: BGP Update Report Message-ID: <200901231100.n0NB06xs041803@wattle.apnic.net> BGP Update Report Interval: 22-Dec-08 -to- 22-Jan-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 90009 1.1% 20.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS4323 89143 1.1% 20.8 -- TWTC - tw telecom holdings, inc. 3 - AS9583 83162 1.0% 58.2 -- SIFY-AS-IN Sify Limited 4 - AS209 64388 0.8% 22.4 -- ASN-QWEST - Qwest Communications Corporation 5 - AS35805 52833 0.6% 165.1 -- UTG-AS United Telecom AS 6 - AS6629 51646 0.6% 782.5 -- NOAA-AS - NOAA 7 - AS20115 47444 0.6% 22.5 -- CHARTER-NET-HKY-NC - Charter Communications 8 - AS17974 44557 0.5% 89.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS1785 44154 0.5% 24.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - AS17488 42803 0.5% 27.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 11 - AS7643 39218 0.5% 58.6 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 12 - AS8151 38880 0.5% 26.0 -- Uninet S.A. de C.V. 13 - AS9829 38164 0.5% 44.9 -- BSNL-NIB National Internet Backbone 14 - AS2386 35929 0.4% 22.2 -- INS-AS - AT&T Data Communications Services 15 - AS4766 35861 0.4% 20.1 -- KIXS-AS-KR Korea Telecom 16 - AS24863 35250 0.4% 58.2 -- LINKdotNET-AS 17 - AS7018 35053 0.4% 23.8 -- ATT-INTERNET4 - AT&T WorldNet Services 18 - AS6478 34949 0.4% 16.3 -- ATT-INTERNET3 - AT&T WorldNet Services 19 - AS29571 32426 0.4% 245.7 -- CITelecom-AS 20 - AS6458 29771 0.3% 65.1 -- Telgua TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 5447 0.1% 5447.0 -- ALON-USA - ALON USA, LP 2 - AS48129 4827 0.1% 4827.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 3 - AS32753 3262 0.0% 3262.0 -- GLOBEOP-FINANCIAL-SERVICES-NYC1 - GlobeOp Financial Services 4 - AS30969 23982 0.3% 2997.8 -- TAN-NET TransAfrica Networks 5 - AS30306 13872 0.2% 2774.4 -- AfOL-Sz-AS 6 - AS23917 2732 0.0% 2732.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 7 - AS28194 6990 0.1% 2330.0 -- 8 - AS41007 6124 0.1% 2041.3 -- CTCASTANA CTC ASTANA, KZ 9 - AS32398 14090 0.2% 1761.2 -- REALNET-ASN-1 10 - AS24228 12311 0.1% 1758.7 -- BARNETWORK-AP BarNetwork Pty Limited 11 - AS19017 1732 0.0% 1732.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 12 - AS45122 1579 0.0% 1579.0 -- JASPACE-AS-ID-AP PT. JASPACE NET 13 - AS29224 2512 0.0% 1256.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG 14 - AS44265 13277 0.2% 1207.0 -- SMOLTELECOM-NET Smoltelecom Ltd AS peering 15 - AS5050 13352 0.2% 1112.7 -- PSC-EXT - Pittsburgh Supercomputing Center 16 - AS29427 2214 0.0% 1107.0 -- AZM-AS Mercury Telecom 17 - AS8599 2115 0.0% 1057.5 -- Ulyanovsk State University Network 18 - AS40430 8048 0.1% 1006.0 -- COLO4JAX-AS - colo4jax, LLC 19 - AS41685 1003 0.0% 1003.0 -- DTEK DTEK 20 - AS30095 1887 0.0% 943.5 -- AS-30095 - Group M Worldwide, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 124.7.201.0/24 20933 0.2% AS9583 -- SIFY-AS-IN Sify Limited 2 - 210.214.151.0/24 20344 0.2% AS9583 -- SIFY-AS-IN Sify Limited 3 - 192.35.129.0/24 16938 0.2% AS6629 -- NOAA-AS - NOAA 4 - 198.77.177.0/24 16738 0.2% AS6629 -- NOAA-AS - NOAA 5 - 192.102.88.0/24 16717 0.2% AS6629 -- NOAA-AS - NOAA 6 - 144.36.245.0/24 16104 0.2% AS21433 -- ACCENTUREFSSC Accenture London Delivery Centre 7 - 41.204.2.0/24 13902 0.2% AS32398 -- REALNET-ASN-1 8 - 72.23.246.0/24 13062 0.1% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - 202.83.176.0/21 12167 0.1% AS24228 -- BARNETWORK-AP BarNetwork Pty Limited 10 - 196.27.104.0/21 11715 0.1% AS30969 -- TAN-NET TransAfrica Networks 11 - 196.27.108.0/22 11641 0.1% AS30969 -- TAN-NET TransAfrica Networks 12 - 199.2.119.0/24 11350 0.1% AS11816 -- SetarNet 13 - 192.12.120.0/24 10544 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 64.162.116.0/24 9163 0.1% AS5033 -- ISW - Internet Specialties West Inc. 16 - 221.135.80.0/24 7675 0.1% AS9583 -- SIFY-AS-IN Sify Limited 17 - 212.85.220.0/24 6748 0.1% AS30306 -- AfOL-Sz-AS 18 - 212.85.223.0/24 6729 0.1% AS30306 -- AfOL-Sz-AS 19 - 89.4.131.0/24 6556 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 118.95.130.0/23 6391 0.1% AS9583 -- SIFY-AS-IN Sify Limited Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From drc at virtualized.org Sat Jan 24 16:38:53 2009 From: drc at virtualized.org (David Conrad) Date: Sat, 24 Jan 2009 14:38:53 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497AA86C.7050609@brightok.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> <497AA86C.7050609@brightok.net> Message-ID: <8C5F1FEC-FF51-4BA2-A762-C13BC275E806@virtualized.org> Jack, On Jan 23, 2009, at 9:34 PM, Jack Bates wrote: > David Conrad wrote: >> Sad fact is that there are zillions of excuses. Unfortunately I >> suspect the only way we're going to make any progress on this will >> be for laws to be passed (or lawsuits to be filed) that impose a >> financial penalty on ISPs through which these attacks propagate. > Careful what you ask for. You might get it, and I'm sure the outcome > wouldn't be liked by any. You misunderstand. I am certainly not asking for it, in fact I consider it something of a tragedy that it appears the only way action can be taken is to take it away from technologists and give it to lawyers and politicians. And no, the outcome most likely won't be liked, just like CAN-SPAM was a sad joke. > Getting sued because you had some stealth botnet that suddenly fires > up is not a good deal; and probably why ISP's still manage to hold > onto some immunities. OT, though, I'm sure. It would seem that as ISPs implement DPI and protocol-specific traffic shaping, they damage the arguments that they can make claiming they have "common carrier" status with the inherent immunities that status provides. I can hear the argument now: if an ISP can throttle BitTorrent (or whatever) for specific nodes, why can't they also limit the source addresses of packets coming from those nodes? Regards, -drc From chort at smtps.net Sat Jan 24 18:50:24 2009 From: chort at smtps.net (Brian Keefer) Date: Sat, 24 Jan 2009 16:50:24 -0800 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: Caveat: my PERL is _terrible_. http://www.smtps.net/pub/dns-amp-watch.pl This assumes you're using BIND. My logs roll on the hour, so I run it from cron at 1 minute before the hour. Depending on how long it takes to process your logs, you might need to tweak. -- bk CA cert: http://www.smtps.net/pub/smtps-dot-net-ca-2.pem -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1613 bytes Desc: not available URL: From Mark_Andrews at isc.org Sat Jan 24 19:01:46 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sun, 25 Jan 2009 12:01:46 +1100 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: Your message of "Sat, 24 Jan 2009 14:38:53 -0800." <8C5F1FEC-FF51-4BA2-A762-C13BC275E806@virtualized.org> Message-ID: <200901250101.n0P11kjE060357@drugs.dv.isc.org> In message <8C5F1FEC-FF51-4BA2-A762-C13BC275E806 at virtualized.org>, David Conrad writes: > It would seem that as ISPs implement DPI and protocol-specific traffic > shaping, they damage the arguments that they can make claiming they > have "common carrier" status with the inherent immunities that status > provides. I can hear the argument now: if an ISP can throttle > BitTorrent (or whatever) for specific nodes, why can't they also limit > the source addresses of packets coming from those nodes? They can and should. I suspect many of them do as they usually apply these filters to home networks. BCP 38 is ~10 years old now. It should have been factored into the purchasing decision of all the current equipement. If it wasn't then the operator was negligent. Mark > Regards, > -drc > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From martin at theicelandguy.com Sat Jan 24 19:34:59 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 24 Jan 2009 20:34:59 -0500 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <200901250101.n0P11kjE060357@drugs.dv.isc.org> References: <8C5F1FEC-FF51-4BA2-A762-C13BC275E806@virtualized.org> <200901250101.n0P11kjE060357@drugs.dv.isc.org> Message-ID: On Sat, Jan 24, 2009 at 8:01 PM, Mark Andrews wrote: > > In message <8C5F1FEC-FF51-4BA2-A762-C13BC275E806 at virtualized.org>, David > Conrad writes: > > It would seem that as ISPs implement DPI and protocol-specific traffic > > shaping, they damage the arguments that they can make claiming they > > have "common carrier" status with the inherent immunities that status > > provides. I can hear the argument now: if an ISP can throttle > > BitTorrent (or whatever) for specific nodes, why can't they also limit > > the source addresses of packets coming from those nodes? > > They can and should. I suspect many of them do as they > usually apply these filters to home networks. > > BCP 38 is ~10 years old now. It should have been factored > into the purchasing decision of all the current equipement. > If it wasn't then the operator was negligent. > > Mark > > BCP 38 isn't a license, it's a technique. -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From Mark_Andrews at isc.org Sat Jan 24 20:05:06 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sun, 25 Jan 2009 13:05:06 +1100 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: Your message of "Sat, 24 Jan 2009 20:34:59 CDT." Message-ID: <200901250205.n0P256rZ061168@drugs.dv.isc.org> In message , Marti n Hannigan writes: > On Sat, Jan 24, 2009 at 8:01 PM, Mark Andrews wrote: > > > > > In message <8C5F1FEC-FF51-4BA2-A762-C13BC275E806 at virtualized.org>, David > > Conrad writes: > > > It would seem that as ISPs implement DPI and protocol-specific traffic > > > shaping, they damage the arguments that they can make claiming they > > > have "common carrier" status with the inherent immunities that status > > > provides. I can hear the argument now: if an ISP can throttle > > > BitTorrent (or whatever) for specific nodes, why can't they also limit > > > the source addresses of packets coming from those nodes? > > > > They can and should. I suspect many of them do as they > > usually apply these filters to home networks. > > > > BCP 38 is ~10 years old now. It should have been factored > > into the purchasing decision of all the current equipement. > > If it wasn't then the operator was negligent. > > > Mark > > > > > BCP 38 isn't a license, it's a technique. There are plenty of cases in common law where as a owner of something and you havn't taken reasonable steps to protect or prevent injury that, were well known, you will be proved to be negligent. BCP 38 is falling into that sort of category. Every operator here should be worried about what will happen when someone decides to sue them to recover damaged caused by spoofed traffic. It's just a matter of time before this happens. Remember every router inspects packets to the level required to implement BCP 38. This is not deep packet inspection. This is address inspection which every router performs. Did you know about "BCP 38"? What steps did you take to implement "BCP 38"? I suspect that a lawyer will be able to demonstrate to a judge that even as a common carrier that a operator should have been deploying BCP 38. Mark > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From fergdawgster at gmail.com Sat Jan 24 20:13:14 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 24 Jan 2009 18:13:14 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <200901250205.n0P256rZ061168@drugs.dv.isc.org> References: <200901250205.n0P256rZ061168@drugs.dv.isc.org> Message-ID: <6cd462c00901241813w265ccdc5tc7b2ca359c09c4f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Jan 24, 2009 at 6:05 PM, Mark Andrews wrote: >> BCP 38 isn't a license, it's a technique. > > There are plenty of cases in common law where as a owner > of something and you havn't taken reasonable steps to protect > or prevent injury that, were well known, you will be proved > to be negligent. > > BCP 38 is falling into that sort of category. > > Every operator here should be worried about what will happen > when someone decides to sue them to recover damaged caused > by spoofed traffic. It's just a matter of time before this > happens. Remember every router inspects packets to the > level required to implement BCP 38. This is not deep packet > inspection. This is address inspection which every router > performs. > > Did you know about "BCP 38"? > What steps did you take to implement "BCP 38"? > > I suspect that a lawyer will be able to demonstrate to a > judge that even as a common carrier that a operator should > have been deploying BCP 38. > I think each point above is true -- BCP38 is indeed a technique, but failure to universally implement it defaults to (almost) a tragedy of the commons. After ~10 years, it is surreal to me that we, as a community, are still grappling with issues where it could be beneficial for the Internet community at-large. I mean, it _is_ a BCP. - - ferg p.s. Even when Dan Senie and I drafted RFC2827/BCP38, we were doing nothing more than documenting what everyone (well, maybe not everyone) already knew anyway -- that we all need to bite the bullet and just do it. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJe8qeq1pz9mNUZTMRAmXvAJ4h2V/p6Ak+woMbT9BTCOYrEKMlXACdFaFe icfmMA4432St/zl5j3yfQiA= =iWAr -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From frnkblk at iname.com Sat Jan 24 21:00:53 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Jan 2009 21:00:53 -0600 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: I would not recommend sucking in your dns log into array, rather, read line by line and iterate over the file, line by line. Frank -----Original Message----- From: Brian Keefer [mailto:chort at smtps.net] Sent: Saturday, January 24, 2009 6:50 PM To: nanog at nanog.org Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) Caveat: my PERL is _terrible_. http://www.smtps.net/pub/dns-amp-watch.pl This assumes you're using BIND. My logs roll on the hour, so I run it from cron at 1 minute before the hour. Depending on how long it takes to process your logs, you might need to tweak. -- bk CA cert: http://www.smtps.net/pub/smtps-dot-net-ca-2.pem From andrius at andrius.org Sat Jan 24 22:47:48 2009 From: andrius at andrius.org (AKK) Date: Sun, 25 Jan 2009 04:47:48 +0000 Subject: massive routes hijack at AS48400, up to 6000 AS affected? Message-ID: <497BEEF4.50506@andrius.org> Hi all, Jan 24 23:20 - Jan 25 01:45 UK time, from LINX peers I have seen major performance degradation on unusually strange route to some eastern Europe countries - see MTR at the bottom of this email. If this is true, it is exactly what few people told us(and we knew) last year. Probably AS48400, which is defined as two ISP multihomed non-transit at RIPEDB, announced various prefixes it had from their ISP.. actually from one ISP to another becoming a transit ISP. I am sure this was not the only faulty point in this failure, but it took quite a while for ISPs to fix it.. It would be interesting to know whether that was unintentional... I know that at least two countries in that way were almost taken internationally offline. I wonder if some sort of action should/will be taken.. Unfortunately ripe's asinuse doesn't tell the story about 48400, but you would find that in raw update logs and bgpplay where I counted around 6k AS were affected. AS PATH 8468 8732 12389 48400 48400 48400 48400 20485 1299 20965 2847 4. te5-1.telehouse-east.core.enta.net 0.1% 2991 1.0 12.1 0.9 282.4 37.5 5. te5-1.telecity-hex.core.enta.net 0.1% 2991 1.2 3.5 0.9 218.9 17.7 6. te5-3.frankfurt.core.enta.net 0.0% 2991 18.0 22.7 17.8 224.9 25.0 7. decix.comcor.ru 0.0% 2991 64.5 64.1 63.6 92.6 0.9 8. 213.171.44.10 90.5% 2991 113.6 115.9 111.9 193.5 8.6 9. 87.226.137.162 99.4% 2991 107.0 106.0 104.4 107.8 0.9 10. 92.50.194.254 98.9% 2991 121.0 123.2 120.4 135.1 2.7 11. vgd15.transtelecom.net 90.4% 2991 114.8 113.4 111.2 117.6 1.1 12. adm-b1-link.telia.net 88.9% 2991 103.7 104.4 102.1 108.0 1.1 13. adm-bb2-link.telia.net 89.9% 2991 105.8 104.5 102.3 119.3 1.5 14. hbg-bb2-pos7-0-0.telia.net 89.8% 2991 116.4 115.7 112.9 122.0 1.2 15. kbn-bb2-pos1-2-0.telia.net 90.7% 2986 120.6 120.7 117.9 137.1 1.7 kbn-bb2-link.telia.net kbn-bb2-link.telia.net 16. kbn-b2-pos5-0.telia.net 89.7% 2986 121.0 124.7 118.4 257.9 16.1 kbn-b2-link.telia.net 17. dante-ic-125712-kbn-b2.c.telia.net 89.2% 2985 127.1 123.2 119.3 207.3 8.9 18. so-0-0-0.rt1.tal.ee.geant2.net 89.4% 2984 135.2 136.8 133.9 162.7 2.8 19. so-1-0-0.rt1.rig.lv.geant2.net 89.2% 2984 145.4 144.7 142.2 170.9 2.1 20. 62.40.112.169 90.0% 2981 151.1 152.1 149.8 171.6 1.8 21. litnet-gw.rt1.kau.lt.geant2.net 90.8% 2981 152.4 152.3 149.6 158.7 1.2 22 .. Regards, Andrius KK From marquis at roble.com Sat Jan 24 23:33:21 2009 From: marquis at roble.com (Roger Marquis) Date: Sat, 24 Jan 2009 21:33:21 -0800 (PST) Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: References: Message-ID: <20090125053321.C92A62B21C3@mx5.roble.com> Frank Bulk wrote: > I would not recommend sucking in your dns log into array, rather, read line > by line and iterate over the file, line by line. Agreed. Python and Pytailer are particularly good tools for this application, running as a daemon and implementing IP filters as needed. This is all, however, treating symptoms. The root cause would be far better fixed with a named patch implementing Chris Paul's recommendation to NANOG back in August: >Chris Paul wrote >> Sorry if this is real stupid for some reason because I don't think about >> DNS all day (I'm the ldap dude) but since we have faster networks and >> faster cpus today, what would be the harm in switching to use TCP for >> DNS clients? The latency on the web isn't dns anymore ever it seems to >> me..... > > That's the best idea I've read so far. You wouldn't want to toggle > protocols on the first mismatch, but maybe the 10th or 50th. Would also be > worthwhile to factor in some rate limiting and an algorithm for timing the > toggle-back. Stir in some simple statefulness via btree and voila. Roger Marquis From danny at tcb.net Sat Jan 24 23:47:21 2009 From: danny at tcb.net (Danny McPherson) Date: Sat, 24 Jan 2009 22:47:21 -0700 Subject: massive routes hijack at AS48400, up to 6000 AS affected? In-Reply-To: <497BEEF4.50506@andrius.org> References: <497BEEF4.50506@andrius.org> Message-ID: On Jan 24, 2009, at 9:47 PM, AKK wrote: > Hi all, > > Jan 24 23:20 - Jan 25 01:45 UK time, from LINX peers I have seen > major performance degradation on unusually strange route to some > eastern Europe countries - see MTR at the bottom of this email. > > If this is true, it is exactly what few people told us(and we knew) > last year. Probably AS48400, which is defined as two ISP multihomed > non-transit at RIPEDB, announced various prefixes it had from their > ISP.. actually from one ISP to another becoming a transit ISP. I am > sure this was not the only faulty point in this failure, but it took > quite a while for ISPs to fix it.. It would be interesting to know > whether that was unintentional... I know that at least two countries > in that way were almost taken internationally offline. I wonder if > some sort of action should/will be taken.. Unfortunately ripe's > asinuse doesn't tell the story about 48400, but you would find that > in raw update logs and bgpplay where I counted around 6k AS were > affected. A cursory looks suggests this was nothing more than an ordinary route leak (inspection of the leaking AS, as well as location of that AS in the relevant paths, and the preservation of the prefix lengths; versus some deaggregation or re-origination, and the proximity of those leaked routes to the leaking ASes transit providers). Of course, an ordinary route leak could be the result of accidental configuration, but it could have been malicious as well. When you've got: 1) an AS multi-homed to two different ISPs, AND 2) that AS fails to scope what they announce to those ISPs (i.e., advertise only locally originated and downstream prefixes explicitly), AND 3) one or both of the ISPs employ neither per-prefix, or explicit AS path filtering on ingress, OR 4) they do, but they enable a BGP session _before they apply that ingress policy on the session This is exactly what you get.... To complicate things further, common RFC 1998-style routing policy models result in most clueful ISPs preferring customer routes over peer routes (e.g., via local preference), so those leaked routes are now the preferred path to ALL those prefixes (because local preference trumps AS path), so the customer, with a T1, E1, 100M Ethernet, or whatever, is now the sole primary transit data path between the two networks in question, and all their non-customer egress traffic takes that route, the congestion and collateral damage makes fixing the mistake .. challenging. We always had fallback AS path filters we'd apply to peers in the past that were automatically applied to all new sessions *before* they were turned up in order to avert this type of problem. Basically, the AS path filters listed all the ASNs that we bi-laterally interconnected with, so that if a customer leaked any of their other transit ISPs routes to us, they'd be dropped. Ohh, and regarding 4) above, I experienced that first hand in 1995, when a BGP session between iMCI and Sprint was turned up before ANY ingress BGP policy was applied. The T1 customer immediately became the sole transit path for all iMCI -> Sprint traffic, and all iMCI -> non-iMCI-customer traffic, as they were taking full routes from Sprint, and we preferred those paths (because of default local preference) over all other paths. Took a while to get the router rebooted to fixed the problem. I suspect you can find some evidence of this event in some dusty NANOG archives out there somewhere. Glad to see things have evolved so little... I'll dig a little deeper and qualify the terse look I've already had when I get some time. I suspect others will be looking as well. -danny From andrew.fried at gmail.com Sat Jan 24 23:54:07 2009 From: andrew.fried at gmail.com (Andrew Fried) Date: Sun, 25 Jan 2009 00:54:07 -0500 Subject: isprime DOS in progress In-Reply-To: <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: <497BFE7F.70909@gmail.com> I extracted all logs from one of my dns servers that reflected an "'./NS/IN' denied" message, pumped them into a database and ran a few queries. The first query shows the number of "denied" messages on my dns server, sorted by date. The amount of traffic definitely picked up on January 21st: +-------------+-------------+ | date | count(date) | +-------------+-------------+ | 03-Jan-2009 | 20 | | 04-Jan-2009 | 173 | | 05-Jan-2009 | 407 | | 06-Jan-2009 | 6429 | | 07-Jan-2009 | 6391 | | 08-Jan-2009 | 1421 | | 09-Jan-2009 | 398 | | 10-Jan-2009 | 402 | | 11-Jan-2009 | 257 | | 12-Jan-2009 | 174 | | 13-Jan-2009 | 168 | | 14-Jan-2009 | 451 | | 15-Jan-2009 | 959 | | 16-Jan-2009 | 31410 | | 17-Jan-2009 | 79418 | | 18-Jan-2009 | 64788 | | 19-Jan-2009 | 90391 | | 20-Jan-2009 | 71683 | | 21-Jan-2009 | 104413 | | 22-Jan-2009 | 104344 | | 23-Jan-2009 | 105686 | | 24-Jan-2009 | 105853 | | 25-Jan-2009 | 1757 | +-------------+-------------+ This report shows the number of queries grouped by host IP: +-----------------+-------------+ | host | count(host) | +-----------------+-------------+ | 10.168.69.6 | 1059 | | 123.127.121.245 | 528 | | 202.106.83.125 | 530 | | 203.121.29.11 | 426 | | 203.121.29.12 | 402 | | 206.71.158.30 | 45047 | | 209.123.8.64 | 361 | | 209.123.8.99 | 617 | | 211.72.249.201 | 786 | | 211.95.81.245 | 530 | | 213.61.92.192 | 863 | | 216.201.82.19 | 4548 | | 216.201.83.2 | 3411 | | 216.240.131.173 | 1081 | | 219.142.91.125 | 530 | | 220.181.168.251 | 451 | | 58.26.5.43 | 426 | | 58.26.5.44 | 367 | | 60.247.99.245 | 530 | | 61.129.61.245 | 5 | | 63.217.28.226 | 130907 | | 66.230.128.15 | 123551 | | 66.230.160.1 | 176558 | | 66.238.93.161 | 789 | | 69.31.52.214 | 15 | | 69.50.137.175 | 22068 | | 69.50.142.11 | 114048 | | 69.50.142.110 | 15483 | | 74.86.34.144 | 1188 | | 76.9.16.171 | 57275 | | 76.9.31.42 | 72669 | | 91.199.112.18 | 344 | +-----------------+-------------+ And finally, I looked at all log entries reflecting the host ip '206.71.158.30'. The first time my dns server logged that IP address was on January 24th: +-------------+-------------+ | date | count(date) | +-------------+-------------+ | 24-Jan-2009 | 43441 | | 25-Jan-2009 | 1606 | +-------------+-------------+ Finally, when I focused strictly on logs from January 24th, 5 hosts came up: +---------------+-------------+ | host | count(host) | +---------------+-------------+ | 10.168.69.6 | 51 | | 206.71.158.30 | 43441 | | 63.217.28.226 | 57955 | | 66.230.160.1 | 4014 | | 76.9.16.171 | 392 | +---------------+-------------+ A tail end of the logs related to 206.71.158.30 indicate queries originating, on average, about one second apart: | 25-Jan-2009 | 00:22:58.644 | 206.71.158.30 | | 25-Jan-2009 | 00:22:59.056 | 206.71.158.30 | | 25-Jan-2009 | 00:23:00.565 | 206.71.158.30 | | 25-Jan-2009 | 00:23:00.643 | 206.71.158.30 | | 25-Jan-2009 | 00:23:00.949 | 206.71.158.30 | | 25-Jan-2009 | 00:23:02.640 | 206.71.158.30 | | 25-Jan-2009 | 00:23:04.330 | 206.71.158.30 | | 25-Jan-2009 | 00:23:04.639 | 206.71.158.30 | | 25-Jan-2009 | 00:23:05.283 | 206.71.158.30 | | 25-Jan-2009 | 00:23:06.646 | 206.71.158.30 | | 25-Jan-2009 | 00:23:06.792 | 206.71.158.30 | | 25-Jan-2009 | 00:23:07.176 | 206.71.158.30 | | 25-Jan-2009 | 00:23:08.653 | 206.71.158.30 | | 25-Jan-2009 | 00:23:10.556 | 206.71.158.30 | | 25-Jan-2009 | 00:23:10.653 | 206.71.158.30 | | 25-Jan-2009 | 00:23:11.509 | 206.71.158.30 | | 25-Jan-2009 | 00:23:12.652 | 206.71.158.30 | | 25-Jan-2009 | 00:23:13.018 | 206.71.158.30 | | 25-Jan-2009 | 00:23:13.402 | 206.71.158.30 | | 25-Jan-2009 | 00:23:14.656 | 206.71.158.30 | | 25-Jan-2009 | 00:23:16.665 | 206.71.158.30 | | 25-Jan-2009 | 00:23:16.783 | 206.71.158.30 | | 25-Jan-2009 | 00:23:17.736 | 206.71.158.30 | | 25-Jan-2009 | 00:23:18.666 | 206.71.158.30 | | 25-Jan-2009 | 00:23:19.245 | 206.71.158.30 | | 25-Jan-2009 | 00:23:19.629 | 206.71.158.30 | | 25-Jan-2009 | 00:23:20.662 | 206.71.158.30 | | 25-Jan-2009 | 00:23:22.658 | 206.71.158.30 | | 25-Jan-2009 | 00:23:23.010 | 206.71.158.30 | | 25-Jan-2009 | 00:23:23.963 | 206.71.158.30 | | 25-Jan-2009 | 00:23:24.665 | 206.71.158.30 | | 25-Jan-2009 | 00:23:25.472 | 206.71.158.30 | | 25-Jan-2009 | 00:23:25.856 | 206.71.158.30 | +-------------+--------------+---------------+ Andrew Brian Keefer wrote: > > > On Jan 23, 2009, at 12:20 PM, Luke Sheldrick wrote: > >> Looks to me like the target has moved, anyone else seeing similar? > > It's switched again. The new target is 206.71.158.30 . > > Over night it cycled through several different IPs (testing the > waters?), and finally started on this one around 10:26 Pacific time > this morning. > > Timeline below. > > -- > bk > > Jan 23 23:24:47 imhotep named[32762]: client 63.217.28.226#53: view > ext: query (cache) './NS/IN' denied > Jan 24 00:51:11 imhotep named[32762]: client 208.78.169.236#33027: > view ext: query (cache) './NS/IN' denied > Jan 24 00:51:11 imhotep last message repeated 2 times > Jan 24 00:51:11 imhotep named[32762]: client 204.11.51.60#32831: view > ext: query (cache) './NS/IN' denied > Jan 24 00:51:11 imhotep last message repeated 2 times > Jan 24 00:51:30 imhotep named[32762]: client 208.37.177.61#42517: view > ext: query (cache) './NS/IN' denied > Jan 24 00:51:30 imhotep last message repeated 2 times > Jan 24 01:54:44 imhotep named[32762]: client 208.37.177.61#42517: view > ext: query (cache) './NS/IN' denied > Jan 24 01:54:44 imhotep last message repeated 2 times > Jan 24 01:55:44 imhotep named[32762]: client 204.11.51.60#32831: view > ext: query (cache) './NS/IN' denied > Jan 24 01:55:44 imhotep last message repeated 2 times > Jan 24 01:57:46 imhotep named[32762]: client 208.78.169.235#46265: > view ext: query (cache) './NS/IN' denied > Jan 24 01:57:46 imhotep last message repeated 2 times > Jan 24 02:58:29 imhotep named[32762]: client 208.37.177.62#46265: view > ext: query (cache) './NS/IN' denied > Jan 24 02:58:30 imhotep last message repeated 2 times > Jan 24 03:00:34 imhotep named[32762]: client 204.11.51.60#32831: view > ext: query (cache) './NS/IN' denied > Jan 24 03:00:35 imhotep last message repeated 2 times > Jan 24 03:05:05 imhotep named[32762]: client 208.78.169.236#33027: > view ext: query (cache) './NS/IN' denied > Jan 24 03:05:05 imhotep last message repeated 2 times > Jan 24 03:07:49 imhotep named[32762]: client 63.217.28.226#53: view > ext: query (cache) './NS/IN' denied > Jan 24 04:02:38 imhotep named[32762]: client 208.37.177.61#42517: view > ext: query (cache) './NS/IN' denied > Jan 24 04:02:38 imhotep last message repeated 2 times > Jan 24 04:05:43 imhotep named[32762]: client 204.11.51.59#32802: view > ext: query (cache) './NS/IN' denied > Jan 24 04:05:43 imhotep last message repeated 2 times > Jan 24 04:12:52 imhotep named[32762]: client 208.78.169.234#42517: > view ext: query (cache) './NS/IN' denied > Jan 24 04:12:52 imhotep last message repeated 2 times > Jan 24 05:07:37 imhotep named[32762]: client 208.37.177.61#42517: view > ext: query (cache) './NS/IN' denied > Jan 24 05:07:37 imhotep last message repeated 2 times > Jan 24 05:11:35 imhotep named[32762]: client 204.11.51.59#32802: view > ext: query (cache) './NS/IN' denied > Jan 24 05:11:35 imhotep last message repeated 2 times > Jan 24 05:21:36 imhotep named[32762]: client 208.78.169.234#42517: > view ext: query (cache) './NS/IN' denied > Jan 24 05:21:37 imhotep last message repeated 2 times > Jan 24 06:16:06 imhotep named[32762]: client 208.37.177.62#46265: view > ext: query (cache) './NS/IN' denied > Jan 24 06:16:06 imhotep last message repeated 2 times > Jan 24 06:20:19 imhotep named[32762]: client 204.11.51.61#43329: view > ext: query (cache) './NS/IN' denied > Jan 24 06:20:19 imhotep last message repeated 2 times > Jan 24 06:29:37 imhotep named[32762]: client 208.78.169.235#46265: > view ext: query (cache) './NS/IN' denied > Jan 24 06:29:37 imhotep last message repeated 2 times > Jan 24 06:35:11 imhotep named[32762]: client 149.20.52.161#61452: view > ext: notify question section contains no SOA > Jan 24 07:23:06 imhotep named[32762]: client 208.37.177.61#42517: view > ext: query (cache) './NS/IN' denied > Jan 24 07:23:06 imhotep last message repeated 2 times > Jan 24 07:28:27 imhotep named[32762]: client 204.11.51.60#32831: view > ext: query (cache) './NS/IN' denied > Jan 24 07:28:27 imhotep last message repeated 2 times > Jan 24 07:40:25 imhotep named[32762]: client 208.78.169.234#42517: > view ext: query (cache) './NS/IN' denied > Jan 24 07:40:25 imhotep last message repeated 2 times > Jan 24 08:29:57 imhotep named[32762]: client 208.37.177.61#42517: view > ext: query (cache) './NS/IN' denied > Jan 24 08:29:57 imhotep last message repeated 2 times > Jan 24 08:36:10 imhotep named[32762]: client 204.11.51.61#43330: view > ext: query (cache) './NS/IN' denied > Jan 24 08:36:11 imhotep last message repeated 2 times > Jan 24 08:52:45 imhotep named[32762]: client 208.78.169.235#46265: > view ext: query (cache) './NS/IN' denied > Jan 24 08:52:45 imhotep last message repeated 2 times > Jan 24 08:55:54 imhotep named[32762]: client 149.20.58.131#59151: view > ext: query (cache) 'localhost/A/IN' denied > Jan 24 09:36:38 imhotep named[32762]: client 208.37.177.62#46265: view > ext: query (cache) './NS/IN' denied > Jan 24 09:36:38 imhotep last message repeated 2 times > Jan 24 09:43:53 imhotep named[32762]: client 204.11.51.61#43330: view > ext: query (cache) './NS/IN' denied > Jan 24 09:43:54 imhotep last message repeated 2 times > Jan 24 09:53:56 imhotep named[32762]: client 63.217.28.226#53: view > ext: query (cache) './NS/IN' denied > Jan 24 10:05:28 imhotep named[32762]: client 208.78.169.234#42517: > view ext: query (cache) './NS/IN' denied > Jan 24 10:05:28 imhotep last message repeated 2 times > Jan 24 10:26:09 imhotep named[32762]: client 206.71.158.30#18971: view > ext: query (cache) './NS/IN' denied > Jan 24 10:26:11 imhotep named[32762]: client 206.71.158.30#47622: view > ext: query (cache) './NS/IN' denied > Jan 24 10:26:13 imhotep named[32762]: client 206.71.158.30#16077: view > ext: query (cache) './NS/IN' denied > > > -- Andrew Fried andrew.fried at gmail.com From eugen at imacandi.net Sun Jan 25 03:07:46 2009 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 25 Jan 2009 11:07:46 +0200 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <80022.1232767919@turing-police.cc.vt.edu> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> Message-ID: <497C2BE2.2020901@imacandi.net> Valdis.Kletnieks at vt.edu wrote: > On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said: > > >> Back to my original question: is there really not a better solution? >> > > Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4 > baseball-bat wielding professional explainers to go explain our position to > them. Figuring out how to do so without breaking any laws is the tough part... > Or better yet, how Marsellus Wallace said it in Pulp Fiction: " I'ma call a coupla hard, pipe-hittin' niggers, who'll go to work on the homes here with a pair of pliers and a blow torch." Now that would be fun and actually send a strong message across the board :)) From chort at smtps.net Sun Jan 25 03:22:51 2009 From: chort at smtps.net (Brian Keefer) Date: Sun, 25 Jan 2009 01:22:51 -0800 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: On Jan 24, 2009, at 7:00 PM, Frank Bulk wrote: > > -----Original Message----- > From: Brian Keefer [mailto:chort at smtps.net] > > Caveat: my PERL is _terrible_. > > http://www.smtps.net/pub/dns-amp-watch.pl > > I would not recommend sucking in your dns log into array, rather, > read line > by line and iterate over the file, line by line. > > Frank Yep, you're absolutely right. I copied that bit from another script without thinking. It's fixed now, along with the logic error on an empty array. Thanks for the feedback. -- bk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1613 bytes Desc: not available URL: From mysidia at gmail.com Sun Jan 25 03:23:05 2009 From: mysidia at gmail.com (James Hess) Date: Sun, 25 Jan 2009 03:23:05 -0600 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: <6eb799ab0901250123h685fc40dl5a64a3febb1dd21e@mail.gmail.com> On Sat, Jan 24, 2009 at 9:00 PM, Frank Bulk wrote: > I would not recommend sucking in your dns log into array, rather, read line > by line and iterate over the file, line by line. > > Frank True.. reading into an array can get a bit nasty, if your server logs are a few gigabytes in size. Could use C, also... http://pastebin.com/f4c2ff010 Scanning your logs after the fact is definitely not as good as separating DNS servers that are authoritative for zones and picking nameserver software such as TinyDNS or similar options for authoritative DNS usage that won't respond to queries for the root or other zones the DNS server is not directed to be used for, and using acls/firewalls to prevent outside queries against other DNS servers that aren't delegated zones. It's a bit difficult to apply a BIND patch that doesn't exist yet in vendor-supplied implementations of BIND, at least.. -- -J From eugen at imacandi.net Sun Jan 25 03:57:08 2009 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 25 Jan 2009 11:57:08 +0200 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <497B2D43.6090105@aset.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <497B2D43.6090105@aset.com> Message-ID: <497C3774.2000005@imacandi.net> Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Valdis.Kletnieks at vt.edu wrote: > > >> Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4 >> baseball-bat wielding professional explainers to go explain our position to >> them. Figuring out how to do so without breaking any laws is the tough part... >> >> > > But if they were in eastern Europe or Russia, wouldn't that solution be > considered standard business practice and thus be legal? > As an eastern european, I can tell you that you're watching way too much TV :) We also have law enforcement that can take down rogue cracker networks. The only problem police has in this matters is somewhat lack of experience and lack of resources. Otherwise they don't have a problem knocking down doors to catch bad guys. From dga at cs.cmu.edu Sun Jan 25 11:23:27 2009 From: dga at cs.cmu.edu (David Andersen) Date: Sun, 25 Jan 2009 12:23:27 -0500 Subject: isprime DOS in progress In-Reply-To: <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> Message-ID: <86C1310E-420C-4E19-83B4-BA3A95A72E36@cs.cmu.edu> I'm not sure you're entirely out of the water yet: 17:13:45.680944 76.9.16.171.53868 > XXXXXXXX.53: 58451+ NS? . (17) 17:13:45.681251 XXXXXXXX.53 > 76.9.16.171.53868: 58451 Refused- 0/0/0 (17) CIDR: 76.9.0.0/19 NetName: ISPRIME-ARIN-3 In addition to the one that Brian Keefer mentioned a few days ago (206.71.158.30). But on that subject, I figured I'd toss in a (sad) anecdote about security and upgrades. I'd upgraded this nameserver to bind-9 some time ago, during a bit of a security panic. And in the process, I screwed it up - I'd updated the machine itself, but had failed to propagate the changes to the master that sends updates to all of the servers. The obvious thing happened: after a while, this nameserver pulled its updates from the master, and downgraded to bind-8 again, which we didn't notice until I saw it spitting full cached NS responses to isprime hosts. Human error strikes again. Apologies for letting my host be an amplifier. -Dave On Jan 23, 2009, at 1:11 PM, Phil Rosenthal wrote: > Just a friendly notice, the attack against > 66.230.128.15/66.230.160.1 seems to have stopped for now. > > -Phil > On Jan 22, 2009, at 6:01 AM, Bj?rn Mork wrote: > >> Graeme Fowler writes: >> >>> I've been seeing a lot of noise from the latter two addresses after >>> switching on query logging (and finishing an application of Team >>> Cymru's >>> excellent template) so I decided to DROP traffic from the addresses >>> (with source port != 53) at the hosts in question. >>> >>> Well, blow me down if they didn't completely stop talking to me. >>> Four >>> dropped packets each, and they've gone away. >>> >>> Something smells "not quite right" here - if the traffic is >>> spoofed, and >>> my "Refused" responses have been flying right back to the *real* IP >>> addresses, how are the spoofing hosts to know that I'm dropping the >>> traffic? >> >> Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping >> traffic from other sources too? Looks like some of the other source >> addresses are controlled by the DOSers. Possibly used to detect >> filters? >> >> These clients may look similar to the DOS attack, but there are >> subtle >> differences: >> >> Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: >> view external: query (cache) './NS/IN' denied >> Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: >> view external: query (cache) './NS/IN' denied >> Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: >> view external: query (cache) './NS/IN' denied >> Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: >> view external: query (cache) './NS/IN' denied >> Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: >> view external: query (cache) './NS/IN' denied >> Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: >> view external: query (cache) './NS/IN' denied >> Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: >> view external: query (cache) './NS/IN' denied >> Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: >> view external: query (cache) './NS/IN' denied >> Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: >> view external: query (cache) './NS/IN' denied >> Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: >> view external: query (cache) './NS/IN' denied >> Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: >> view external: query (cache) './NS/IN' denied >> Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: >> view external: query (cache) './NS/IN' denied >> Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: >> view external: query (cache) './NS/IN' denied >> Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: >> view external: query (cache) './NS/IN' denied >> Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: >> view external: query (cache) './NS/IN' denied >> Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: >> view external: query (cache) './NS/IN' denied >> Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: >> view external: query (cache) './NS/IN' denied >> Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: >> view external: query (cache) './NS/IN' denied >> Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: >> view external: query (cache) './NS/IN' denied >> Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: >> view external: query (cache) './NS/IN' denied >> Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: >> view external: query (cache) './NS/IN' denied >> Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: >> view external: query (cache) './NS/IN' denied >> Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: >> view external: query (cache) './NS/IN' denied >> Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: >> view external: query (cache) './NS/IN' denied >> >> Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: >> view external: query (cache) './NS/IN' denied >> Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: >> view external: query (cache) './NS/IN' denied >> Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: >> view external: query (cache) './NS/IN' denied >> Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: >> view external: query (cache) './NS/IN' denied >> Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: >> view external: query (cache) './NS/IN' denied >> Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: >> view external: query (cache) './NS/IN' denied >> Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: >> view external: query (cache) './NS/IN' denied >> Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: >> view external: query (cache) './NS/IN' denied >> Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: >> view external: query (cache) './NS/IN' denied >> Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: >> view external: query (cache) './NS/IN' denied >> Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: >> view external: query (cache) './NS/IN' denied >> Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: >> view external: query (cache) './NS/IN' denied >> Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: >> view external: query (cache) './NS/IN' denied >> Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: >> view external: query (cache) './NS/IN' denied >> Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: >> view external: query (cache) './NS/IN' denied >> Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: >> view external: query (cache) './NS/IN' denied >> Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: >> view external: query (cache) './NS/IN' denied >> Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: >> view external: query (cache) './NS/IN' denied >> >> Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: >> view external: query (cache) './NS/IN' denied >> Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: >> view external: query (cache) './NS/IN' denied >> Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: >> view external: query (cache) './NS/IN' denied >> Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: >> view external: query (cache) './NS/IN' denied >> Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: >> view external: query (cache) './NS/IN' denied >> Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: >> view external: query (cache) './NS/IN' denied >> Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: >> view external: query (cache) './NS/IN' denied >> Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: >> view external: query (cache) './NS/IN' denied >> Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: >> view external: query (cache) './NS/IN' denied >> Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: >> view external: query (cache) './NS/IN' denied >> Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: >> view external: query (cache) './NS/IN' denied >> Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: >> view external: query (cache) './NS/IN' denied >> Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: >> view external: query (cache) './NS/IN' denied >> Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: >> view external: query (cache) './NS/IN' denied >> Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: >> view external: query (cache) './NS/IN' denied >> Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: >> view external: query (cache) './NS/IN' denied >> Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: >> view external: query (cache) './NS/IN' denied >> Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: >> view external: query (cache) './NS/IN' denied >> >> >> Notice the pattern: >> 3 probes every 38 minutes >> Each probe from the same source port >> Source port increases slowly and steadily >> >> This looks like some application actually waiting for a response. >> The >> slow source port change is probably an indication that this client >> only >> tests a small number of DNS servers. I guess that this client is >> either >> one of the many bots used to send the spoofed requests, or maybe a >> bot >> not allowed to spoof its source and therefore used for other >> purposes. In any case, I assume that other DNS servers may see such >> control sessions coming from other addresses. >> >> These 3 clients started probing my DNS server almost simultaneously >> on January 8th: >> >> >> Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: >> view external: query (cache) './NS/IN' denied >> Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: >> view external: query (cache) './NS/IN' denied >> >> Maybe preparing for the attack on ISPrime? I didn't start receiving >> spoofed requests from 66.230.128.15/66.230.160.1 before January 20th >> >> >> I just tried filtering the probing addresses. This made the probing >> stop immediately after dropping a set of 3 probes. But the spoofed >> requests continuted at the same rate as before, so this does not >> support >> my theory. >> >> However, I believe it would be too much of a coincidence if there >> isn't >> some connection between the probing and the DOS attack. It would be >> interesting to hear if others see similar probing. >> >> >> >> Bj?rn >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jhorn at terremark.com Sun Jan 25 12:46:10 2009 From: jhorn at terremark.com (Joshua Snowhorn) Date: Sun, 25 Jan 2009 12:46:10 -0600 Subject: NANOG45 Attendees - Tonight's Dominican Fiesta Party! Message-ID: All NANOG45 Attendees! Don't miss tonight's Dominican Fiesta Party sponsored by the Dominican Government for NANOG attendees in Santo Domingo. Buses will be outside the lobby starting 7 p.m. and leaving the hotel promptly at 7:30 p.m. If you miss the bus you can take a taxi (~US$10) to: Restaurant Pate Palo Alcazar de Colon Plaza Espana See you there! Josh Snowhorn ? as Host and for the NANOG Program Committee From andrew.fried at gmail.com Sun Jan 25 13:46:27 2009 From: andrew.fried at gmail.com (Andrew Fried) Date: Sun, 25 Jan 2009 14:46:27 -0500 Subject: isprime DOS in progress In-Reply-To: <86C1310E-420C-4E19-83B4-BA3A95A72E36@cs.cmu.edu> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <86C1310E-420C-4E19-83B4-BA3A95A72E36@cs.cmu.edu> Message-ID: <497CC193.8020008@gmail.com> I just took a snapshot of my bind logs from the past two hours (on 01/25/209 at 14:40 EST). Based on what I'm seeing, four DNS servers are still under attack at varying levels. 206.71.158.30 is bearing the brunt of the attacks. And as you indicated, 76.9.16.171 is still being targeted, although to a lesser degree than before. +---------------+-------------+ | host | count(host) | +---------------+-------------+ | 10.168.69.6 | 3 | | 206.71.158.30 | 6513 | | 63.217.28.226 | 182 | | 66.230.160.1 | 266 | | 76.9.16.171 | 92 | +---------------+-------------+ -- Andrew Fried andrew.fried at gmail.com David Andersen wrote: > I'm not sure you're entirely out of the water yet: > > 17:13:45.680944 76.9.16.171.53868 > XXXXXXXX.53: 58451+ NS? . (17) > 17:13:45.681251 XXXXXXXX.53 > 76.9.16.171.53868: 58451 Refused- 0/0/0 > (17) > > CIDR: 76.9.0.0/19 > NetName: ISPRIME-ARIN-3 > > In addition to the one that Brian Keefer mentioned a few days ago > (206.71.158.30). > > But on that subject, I figured I'd toss in a (sad) anecdote about > security and upgrades. I'd upgraded this nameserver to bind-9 some > time ago, during a bit of a security panic. And in the process, I > screwed it up - I'd updated the machine itself, but had failed to > propagate the changes to the master that sends updates to all of the > servers. The obvious thing happened: after a while, this nameserver > pulled its updates from the master, and downgraded to bind-8 again, > which we didn't notice until I saw it spitting full cached NS > responses to isprime hosts. Human error strikes again. Apologies for > letting my host be an amplifier. > > -Dave > > > On Jan 23, 2009, at 1:11 PM, Phil Rosenthal wrote: > >> Just a friendly notice, the attack against 66.230.128.15/66.230.160.1 >> seems to have stopped for now. >> >> -Phil >> On Jan 22, 2009, at 6:01 AM, Bj?rn Mork wrote: >> >>> Graeme Fowler writes: >>> >>>> I've been seeing a lot of noise from the latter two addresses after >>>> switching on query logging (and finishing an application of Team >>>> Cymru's >>>> excellent template) so I decided to DROP traffic from the addresses >>>> (with source port != 53) at the hosts in question. >>>> >>>> Well, blow me down if they didn't completely stop talking to me. Four >>>> dropped packets each, and they've gone away. >>>> >>>> Something smells "not quite right" here - if the traffic is >>>> spoofed, and >>>> my "Refused" responses have been flying right back to the *real* IP >>>> addresses, how are the spoofing hosts to know that I'm dropping the >>>> traffic? >>> >>> Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping >>> traffic from other sources too? Looks like some of the other source >>> addresses are controlled by the DOSers. Possibly used to detect >>> filters? >>> >>> These clients may look similar to the DOS attack, but there are subtle >>> differences: >>> >>> Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:03:42 canardo named[32046]: client 211.72.249.201#29667: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:42:08 canardo named[32046]: client 211.72.249.201#29670: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:42:09 canardo named[32046]: client 211.72.249.201#29670: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 08:20:29 canardo named[32046]: client 211.72.249.201#29673: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 08:20:30 canardo named[32046]: client 211.72.249.201#29673: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 08:58:50 canardo named[32046]: client 211.72.249.201#29678: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 08:58:51 canardo named[32046]: client 211.72.249.201#29678: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 09:37:12 canardo named[32046]: client 211.72.249.201#29679: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 09:37:13 canardo named[32046]: client 211.72.249.201#29679: >>> view external: query (cache) './NS/IN' denied >>> >>> Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 07:02:51 canardo named[32046]: client 213.61.92.192#46716: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 07:41:21 canardo named[32046]: client 213.61.92.192#46752: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 08:19:46 canardo named[32046]: client 213.61.92.192#46785: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 08:58:12 canardo named[32046]: client 213.61.92.192#46808: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 09:36:34 canardo named[32046]: client 213.61.92.192#46833: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: >>> view external: query (cache) './NS/IN' denied >>> Jan 20 10:14:58 canardo named[32046]: client 213.61.92.192#46858: >>> view external: query (cache) './NS/IN' denied >>> >>> Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 06:27:28 canardo named[32046]: client 66.238.93.161#34373: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 07:05:55 canardo named[32046]: client 66.238.93.161#34420: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 07:44:20 canardo named[32046]: client 66.238.93.161#34473: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 07:44:21 canardo named[32046]: client 66.238.93.161#34473: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 08:22:38 canardo named[32046]: client 66.238.93.161#34503: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 09:00:56 canardo named[32046]: client 66.238.93.161#34540: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 09:39:20 canardo named[32046]: client 66.238.93.161#34574: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: >>> view external: query (cache) './NS/IN' denied >>> Jan 22 09:39:21 canardo named[32046]: client 66.238.93.161#34574: >>> view external: query (cache) './NS/IN' denied >>> >>> >>> Notice the pattern: >>> 3 probes every 38 minutes >>> Each probe from the same source port >>> Source port increases slowly and steadily >>> >>> This looks like some application actually waiting for a response. The >>> slow source port change is probably an indication that this client only >>> tests a small number of DNS servers. I guess that this client is >>> either >>> one of the many bots used to send the spoofed requests, or maybe a bot >>> not allowed to spoof its source and therefore used for other >>> purposes. In any case, I assume that other DNS servers may see such >>> control sessions coming from other addresses. >>> >>> These 3 clients started probing my DNS server almost simultaneously >>> on January 8th: >>> >>> >>> Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:33:52 canardo named[26496]: client 213.61.92.192#31195: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:36:29 canardo named[26496]: client 66.238.93.161#11299: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:36:30 canardo named[26496]: client 66.238.93.161#11299: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: >>> view external: query (cache) './NS/IN' denied >>> Jan 8 19:37:47 canardo named[26496]: client 211.72.249.201#29112: >>> view external: query (cache) './NS/IN' denied >>> >>> Maybe preparing for the attack on ISPrime? I didn't start receiving >>> spoofed requests from 66.230.128.15/66.230.160.1 before January 20th >>> >>> >>> I just tried filtering the probing addresses. This made the probing >>> stop immediately after dropping a set of 3 probes. But the spoofed >>> requests continuted at the same rate as before, so this does not >>> support >>> my theory. >>> >>> However, I believe it would be too much of a coincidence if there isn't >>> some connection between the probing and the DOS attack. It would be >>> interesting to hear if others see similar probing. >>> >>> >>> >>> Bj?rn >>> >> >> >> > From wavetossed at googlemail.com Sun Jan 25 16:15:20 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 25 Jan 2009 22:15:20 +0000 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <6cd462c00901241813w265ccdc5tc7b2ca359c09c4f@mail.gmail.com> References: <200901250205.n0P256rZ061168@drugs.dv.isc.org> <6cd462c00901241813w265ccdc5tc7b2ca359c09c4f@mail.gmail.com> Message-ID: <877585b00901251415n7a771698kb9eb9c7115f462c7@mail.gmail.com> > > I think each point above is true -- BCP38 is indeed a technique, but > failure to universally implement it defaults to (almost) a tragedy of the > commons. > > After ~10 years, it is surreal to me that we, as a community, are still > grappling with issues where it could be beneficial for the Internet > community at-large. I mean, it _is_ a BCP. > The community isn't grappling with the issue. For the most part the NANOG community has implemented BCP 38. The problem is that there are lots of ISPs that are not part of the community and I get the sense that the this number continues to grow. In a sense NANOG has a problem with dwindling market-share. A shrinking percentage of ISPs are part of the NANOG community, and NANOG participants have less and less influence on decisions in the ISPs that they work for, probably because most of them do not work for ISPs but work for telephone companies which have expanded into the ISP business. And yes, I too work for a telco that is now also a major ISP in its telco market area. p.s. Even when Dan Senie and I drafted RFC2827/BCP38, we were doing nothing more than documenting what everyone (well, maybe not everyone) already knew > anyway -- that we all need to bite the bullet and just do it. > Personally, I think that the network operations community represented in NANOG needs to do more outreach to forums where the telecoms community gather rather than ghettoizing Internet ops and engineering. It's all well and good to have NANOG lists and meetings, but once things like BCP-38 reach consensus, how many NANOG members would consider going to something like FutureNet Expo and presenting on the topic? --Michael Dillon From a.harrowell at gmail.com Sun Jan 25 16:49:49 2009 From: a.harrowell at gmail.com (a.harrowell at gmail.com) Date: Sun, 25 Jan 2009 22:49:49 +0000 Subject: Are we really this helpless? (Re: isprime DOS in progress) Message-ID: -original message- Subject: Re: Are we really this helpless? (Re: isprime DOS in progress) From: Michael Dillon Date: 25/01/2009 10:16 pm > > I think each point above is true -- BCP38 is indeed a technique, but > failure to universally implement it defaults to (almost) a tragedy of the > commons. > > After ~10 years, it is surreal to me that we, as a community, are still > grappling with issues where it could be beneficial for the Internet > community at-large. I mean, it _is_ a BCP. > The community isn't grappling with the issue. For the most part the NANOG community has implemented BCP 38. The problem is that there are lots of ISPs that are not part of the community and I get the sense that the this number continues to grow. In a sense NANOG has a problem with dwindling market-share. A shrinking percentage of ISPs are part of the NANOG community, and NANOG participants have less and less influence on decisions in the ISPs that they work for, probably because most of them do not work for ISPs but work for telephone companies which have expanded into the ISP business. And yes, I too work for a telco that is now also a major ISP in its telco market area. p.s. Even when Dan Senie and I drafted RFC2827/BCP38, we were doing nothing more than documenting what everyone (well, maybe not everyone) already knew > anyway -- that we all need to bite the bullet and just do it. > Personally, I think that the network operations community represented in NANOG needs to do more outreach to forums where the telecoms community gather rather than ghettoizing Internet ops and engineering. It's all well and good to have NANOG lists and meetings, but once things like BCP-38 reach consensus, how many NANOG members would consider going to something like FutureNet Expo and presenting on the topic? --Michael Dillon Both to telcos and to non-NA operators. Remember that everything is going to IP. All the interesting voice applications seem to be based on Asterisk in the end, China Mobile is apparently building a flat-IP net with media servers. And there are plenty of clever innovative people outside NA. From lorell at hathcock.org Sun Jan 25 19:27:12 2009 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 25 Jan 2009 19:27:12 -0600 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> Message-ID: <002701c97f55$63300950$29901bf0$@org> Every time I see a post like the one below on this list, I can't help but feel like big brother has infiltrated the list. There's no mess like the ones government will create for you. Lorell -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Friday, January 23, 2009 11:06 PM To: Danny McPherson Cc: NANOG list Subject: Re: Are we really this helpless? (Re: isprime DOS in progress) On Jan 23, 2009, at 8:53 PM, Danny McPherson wrote: > You missed one.. Step 4: enable BCP 38 or similar > ingress source address spoofing mitigation mechanism > on all customer ingress interfaces > ... > No more excuses, people.. Sad fact is that there are zillions of excuses. Unfortunately I suspect the only way we're going to make any progress on this will be for laws to be passed (or lawsuits to be filed) that impose a financial penalty on ISPs through which these attacks propagate. Regards, -drc No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.12/1911 - Release Date: 1/23/2009 7:28 AM From cayle.spandon at gmail.com Sun Jan 25 20:31:59 2009 From: cayle.spandon at gmail.com (cayle.spandon at gmail.com) Date: Mon, 26 Jan 2009 02:31:59 +0000 Subject: BGP on Mac OS X? Message-ID: <00163630ee1d0f1ba60461598bed@google.com> Does anyone known which open source BGP implementation I can get running on Mac OS X Leopard with a minimum of fuss? This is for experimentation only (not for a production environment) so I am not too concerned about scaling and performance. If any tweaking is needed to get it to compile / run on OS X, a pointer to a website with instructions would be highly appreciated. -- Cayle. From jack at crepinc.com Sun Jan 25 21:46:22 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Sun, 25 Jan 2009 22:46:22 -0500 Subject: BGP on Mac OS X? In-Reply-To: <00163630ee1d0f1ba60461598bed@google.com> References: <00163630ee1d0f1ba60461598bed@google.com> Message-ID: <2ad0f9f60901251946y57d85bb0q6cddc1b17a5ba1aa@mail.gmail.com> 'long as you have your compiler working, Quagga reportedly builds and runs out of the box: http://www.quagga.net/ No clue about OSX, but OpenBGPd works well on generic FreeBSD, you could give it a try: http://www.openbgpd.org/ -Jack Carrozzo On Sun, Jan 25, 2009 at 9:31 PM, wrote: > Does anyone known which open source BGP implementation I can get running on > Mac OS X Leopard with a minimum of fuss? > > This is for experimentation only (not for a production environment) so I am > not too concerned about scaling and performance. > > If any tweaking is needed to get it to compile / run on OS X, a pointer to a > website with instructions would be highly appreciated. > > -- Cayle. > From drc at virtualized.org Sun Jan 25 21:47:35 2009 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jan 2009 19:47:35 -0800 Subject: Are we really this helpless? (Re: isprime DOS in progress) In-Reply-To: <002701c97f55$63300950$29901bf0$@org> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <25dbbe250901231321s7cf17d20jeb526c0e75aea6a1@mail.gmail.com> <1232761823.25013.5.camel@roswell.ausics.net> <497A7777.2060003@rollernet.us> <16720fe00901231813k2223491anf02f81abaeb9a389@mail.gmail.com> <497A7DEA.1090605@rollernet.us> <80022.1232767919@turing-police.cc.vt.edu> <75cb24520901232010q2aed7e49x36579a05e97108f@mail.gmail.com> <844C67FA-9F15-48A3-BD0D-61C0BD6521D8@virtualized.org> <002701c97f55$63300950$29901bf0$@org> Message-ID: <0E9CB904-68FB-4081-B4CC-4F2BD47F144C@virtualized.org> Lorell, On Jan 25, 2009, at 5:27 PM, Lorell Hathcock wrote: > Every time I see a post like the one below on this list, I can't > help but > feel like big brother has infiltrated the list. Someone stating the obvious implications of the lack of the Internet operations community to address a known problem that threatens pretty much anyone on the Internet feels like Big Brother has infiltrated the list to you? Odd. > There's no mess like the ones government will create for you. Agreed. Too bad the technologists haven't been able to solve the problem. To be clear, I'm not suggesting laws or lawsuits are a good thing. Rather, it's generally what happens when an industry isn't able to figure out how to wipe its own butt. Regards, -drc From isabeldias1 at yahoo.com Mon Jan 26 04:29:29 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Mon, 26 Jan 2009 02:29:29 -0800 (PST) Subject: inauguration streams review In-Reply-To: Message-ID: <175090.15286.qm@web52607.mail.re2.yahoo.com> we wonder why they have not come up w/ a better word on that IT website, a "standard" ...maybe launching day ...or opening day .....:-) --- On Sat, 1/24/09, Hank Nussbacher wrote: > From: Hank Nussbacher > Subject: Re: inauguration streams review > To: "Florian Weimer" > Cc: nanog at nanog.org > Date: Saturday, January 24, 2009, 7:15 PM > Obama inauguration sets Web traffic record, Akamai says > http://www.networkworld.com/news/2009/012109-obama-inauguration-web-traffic.html > > -Hank From alex.cf+nanog at netsumo.com Mon Jan 26 04:38:02 2009 From: alex.cf+nanog at netsumo.com (Alex Cruz Farmer) Date: Mon, 26 Jan 2009 10:38:02 +0000 Subject: BGP on Mac OS X? In-Reply-To: <00163630ee1d0f1ba60461598bed@google.com> References: <00163630ee1d0f1ba60461598bed@google.com> Message-ID: <497D928A.2040409@netsumo.com> cayle.spandon at gmail.com wrote: > Does anyone known which open source BGP implementation I can get running > on Mac OS X Leopard with a minimum of fuss? > > This is for experimentation only (not for a production environment) so I > am not too concerned about scaling and performance. > > If any tweaking is needed to get it to compile / run on OS X, a pointer > to a website with instructions would be highly appreciated. Hi, More than definitely possible for Quagga on Mac OSX, a company here in the UK run their network on Mac Minis. http://www.fubra.com/blog/2007/04/first-mac-mini-bgp-routers-on-worlds.html Kind regards, Alex Cruz Farmer From alex.cf+nanog at netsumo.com Mon Jan 26 04:47:22 2009 From: alex.cf+nanog at netsumo.com (Alex Cruz Farmer) Date: Mon, 26 Jan 2009 10:47:22 +0000 Subject: BGP on Mac OS X? In-Reply-To: <497D928A.2040409@netsumo.com> References: <00163630ee1d0f1ba60461598bed@google.com> <497D928A.2040409@netsumo.com> Message-ID: <497D94BA.5070608@netsumo.com> Alex Cruz Farmer wrote: > cayle.spandon at gmail.com wrote: >> Does anyone known which open source BGP implementation I can get running >> on Mac OS X Leopard with a minimum of fuss? >> >> This is for experimentation only (not for a production environment) so I >> am not too concerned about scaling and performance. >> >> If any tweaking is needed to get it to compile / run on OS X, a pointer >> to a website with instructions would be highly appreciated. > > Hi, > > More than definitely possible for Quagga on Mac OSX, a company here in the UK run their network on Mac Minis. > > http://www.fubra.com/blog/2007/04/first-mac-mini-bgp-routers-on-worlds.html Actually, I could be wrong here, I believe that they may run their Minis using Ubuntu, rather than OSX. Apologies! From iljitsch at muada.com Mon Jan 26 05:20:22 2009 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 26 Jan 2009 12:20:22 +0100 Subject: BGP on Mac OS X? In-Reply-To: <2ad0f9f60901251946y57d85bb0q6cddc1b17a5ba1aa@mail.gmail.com> References: <00163630ee1d0f1ba60461598bed@google.com> <2ad0f9f60901251946y57d85bb0q6cddc1b17a5ba1aa@mail.gmail.com> Message-ID: <7F6297B3-CCB4-4BEB-86E6-EEA3672024AB@muada.com> On 26 jan 2009, at 4:46, Jack Carrozzo wrote: > 'long as you have your compiler working, Quagga reportedly builds and > runs out of the box: http://www.quagga.net/ Zebra works fine, too. I use it all the time in my training courses. I suggest running the configure script with an alternative path, though, this way Zebra/Quagga and the OS don't get in each other's way. From joelja at bogus.com Mon Jan 26 06:41:23 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 26 Jan 2009 04:41:23 -0800 Subject: NANOG 45 PGP signing party. (update) Message-ID: <497DAF73.9070108@bogus.com> Just a quick note, The thrice annual NANOG pgp key signing party will be making an appearance at NANOG 45. The keysigning sessions are going to be during the morning breaks during the general session, and will be located in the Higuey room on the pool side of the hotel. Monday January 26th 11:00-11:30 Tuesday January 27th 11:00-11:30 It is not to late to add your key to the keyring at: https://biglumber.com/x/web?keyring=9210 Then come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email. Feel free to add your key to the keyring right up to the time of the last keysigning event. Thanks Joel From tkapela at gmail.com Mon Jan 26 07:09:44 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 26 Jan 2009 09:09:44 -0400 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 Message-ID: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> List, The DR meeting is now available in HD video format at the following addresses: mcast feed: 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 unicast feeds: ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 ~3mbit HDV h.264, in mpeg TS: HTTP://208.66.134.110:9000 Enjoy, -tk From tony at lava.net Mon Jan 26 07:47:20 2009 From: tony at lava.net (Antonio Querubin) Date: Mon, 26 Jan 2009 03:47:20 -1000 (HST) Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> Message-ID: On Mon, 26 Jan 2009, Anton Kapela wrote: > mcast feed: > > 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 Not seeing the mcast feed at all. What's the source address so we can try to mtrace to it? Antonio Querubin whois: AQ7-ARIN From tkapela at gmail.com Mon Jan 26 07:57:26 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 26 Jan 2009 09:57:26 -0400 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> Message-ID: <2e9d8ae50901260557r29dc60d4i63b5f966cd9004e4@mail.gmail.com> The source for 233.0.59.45 is kona.doit.wisc.edu and has address 128.104.23.100, hope that helps! -Tk On Mon, Jan 26, 2009 at 9:47 AM, Antonio Querubin wrote: > On Mon, 26 Jan 2009, Anton Kapela wrote: > >> mcast feed: >> >> 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 > > Not seeing the mcast feed at all. What's the source address so we can try > to mtrace to it? > > Antonio Querubin > whois: AQ7-ARIN > From internetplumber at gmail.com Mon Jan 26 07:56:55 2009 From: internetplumber at gmail.com (Rob Evans) Date: Mon, 26 Jan 2009 13:56:55 +0000 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> Message-ID: <9a8fa98b0901260556l654dbd0esaaf421199fa0c8fb@mail.gmail.com> >> 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 > > Not seeing the mcast feed at all. What's the source address so we can try > to mtrace to it? I see it from: 128.104.23.100 (kona.doit.wisc.edu). Cheers, Rob From tony at lava.net Mon Jan 26 08:05:15 2009 From: tony at lava.net (Antonio Querubin) Date: Mon, 26 Jan 2009 04:05:15 -1000 (HST) Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <2e9d8ae50901260557r29dc60d4i63b5f966cd9004e4@mail.gmail.com> References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> <2e9d8ae50901260557r29dc60d4i63b5f966cd9004e4@mail.gmail.com> Message-ID: On Mon, 26 Jan 2009, Anton Kapela wrote: > The source for 233.0.59.45 is kona.doit.wisc.edu and has address > 128.104.23.100, hope that helps! Doesn't show up in our MSDP table. Hmmm... Antonio Querubin whois: AQ7-ARIN From tjc at ecs.soton.ac.uk Mon Jan 26 08:14:47 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 26 Jan 2009 14:14:47 +0000 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <2e9d8ae50901260557r29dc60d4i63b5f966cd9004e4@mail.gmail.com> References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> <2e9d8ae50901260557r29dc60d4i63b5f966cd9004e4@mail.gmail.com> Message-ID: <20090126141447.GH19986@login.ecs.soton.ac.uk> Nice quality feed, thanks, receiving fine here on UK academic network campus. Tim On Mon, Jan 26, 2009 at 09:57:26AM -0400, Anton Kapela wrote: > The source for 233.0.59.45 is kona.doit.wisc.edu and has address > 128.104.23.100, hope that helps! > > -Tk > > On Mon, Jan 26, 2009 at 9:47 AM, Antonio Querubin wrote: > > On Mon, 26 Jan 2009, Anton Kapela wrote: > > > >> mcast feed: > >> > >> 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 > > > > Not seeing the mcast feed at all. What's the source address so we can try > > to mtrace to it? > > > > Antonio Querubin > > whois: AQ7-ARIN > > > -- Tim From leigh.porter at ukbroadband.com Mon Jan 26 08:25:21 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 26 Jan 2009 14:25:21 +0000 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <20090126141447.GH19986@login.ecs.soton.ac.uk> Message-ID: Same here on DSL in UK. On my big telly. It's like being there but without the beer and BO ;-) Nice work. -- Leigh On 26/1/09 14:14, "Tim Chown" wrote: > Nice quality feed, thanks, receiving fine here on UK academic network campus. > > Tim > > On Mon, Jan 26, 2009 at 09:57:26AM -0400, Anton Kapela wrote: >> The source for 233.0.59.45 is kona.doit.wisc.edu and has address >> 128.104.23.100, hope that helps! >> >> -Tk >> >> On Mon, Jan 26, 2009 at 9:47 AM, Antonio Querubin wrote: >>> On Mon, 26 Jan 2009, Anton Kapela wrote: >>> >>>> mcast feed: >>>> >>>> 25 mbit HDV, mpeg Transport Stream, UDP: 233.0.59.45 port 1234 >>> >>> Not seeing the mcast feed at all. What's the source address so we can try >>> to mtrace to it? >>> >>> Antonio Querubin >>> whois: AQ7-ARIN >>> >> From marc at let.de Mon Jan 26 08:31:15 2009 From: marc at let.de (marc) Date: Mon, 26 Jan 2009 15:31:15 +0100 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> Message-ID: <2454F271-A6AD-477B-A545-9F3689EE6747@let.de> Am 26.01.2009 um 14:09 schrieb Anton Kapela: > > unicast feeds: > > ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 my VCL say " ffmpeg: more than 5 seconds of late video -> dropping frame (computer too slow ?) " so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( Quicktime does not want the url. marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From zbynek at dialtelecom.cz Mon Jan 26 08:34:35 2009 From: zbynek at dialtelecom.cz (Zbynek Pospichal) Date: Mon, 26 Jan 2009 15:34:35 +0100 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <2454F271-A6AD-477B-A545-9F3689EE6747@let.de> References: <2e9d8ae50901260509o12d9c508q88889cd853177712@mail.gmail.com> <2454F271-A6AD-477B-A545-9F3689EE6747@let.de> Message-ID: <497DC9FB.8080906@dialtelecom.cz> The same here with VLC. BR, Zbynek Pospichal Dial Telecom Czech Republic marc napsal(a): > > Am 26.01.2009 um 14:09 schrieb Anton Kapela: >> >> unicast feeds: >> >> ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 > > > my VCL say > > " ffmpeg: more than 5 seconds of late video -> dropping frame > (computer too slow ?) " > > so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( > > Quicktime does not want the url. > > marc > > -- > Les Enfants Terribles - WWW.LET.DE > Marc Manthey 50672 K?ln - Germany > Hildeboldplatz 1a > Tel.:0049-221-3558032 > Mobil:0049-1577-3329231 > mail: marc at let.de > jabber :marc at kgraff.net > IRC: #opencu freenode.net > PGP/GnuPG: 0x1ac02f3296b12b4d > twitter: http://twitter.com/macbroadcast > web: http://www.let.de > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > Please note that according to the German law on data retention, > information on every electronic information exchange with me is > retained for a period of six months. > > From leigh.porter at ukbroadband.com Mon Jan 26 08:37:23 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 26 Jan 2009 14:37:23 +0000 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <2454F271-A6AD-477B-A545-9F3689EE6747@let.de> Message-ID: Does it work in quicktime? On 26/1/09 14:31, "marc" wrote: > > Am 26.01.2009 um 14:09 schrieb Anton Kapela: >> >> unicast feeds: >> >> ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 > > > my VCL say > > " ffmpeg: more than 5 seconds of late video -> dropping frame > (computer too slow ?) " > > so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( > > Quicktime does not want the url. > > marc > > -- > Les Enfants Terribles - WWW.LET.DE > Marc Manthey 50672 K?ln - Germany > Hildeboldplatz 1a > Tel.:0049-221-3558032 > Mobil:0049-1577-3329231 > mail: marc at let.de > jabber :marc at kgraff.net > IRC: #opencu freenode.net > PGP/GnuPG: 0x1ac02f3296b12b4d > twitter: http://twitter.com/macbroadcast > web: http://www.let.de > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > Please note that according to the German law on data retention, > information on every electronic information exchange with me is > retained for a period of six months. From marc at let.de Mon Jan 26 08:42:48 2009 From: marc at let.de (marc) Date: Mon, 26 Jan 2009 15:42:48 +0100 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: References: Message-ID: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> Am 26.01.2009 um 15:37 schrieb Leigh Porter: > Does it work in quicktime? quicketime sayed "Invalid Url" regards Marc > > > > On 26/1/09 14:31, "marc" wrote: > >> >> Am 26.01.2009 um 14:09 schrieb Anton Kapela: >>> >>> unicast feeds: >>> >>> ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 >> >> >> my VCL say >> >> " ffmpeg: more than 5 seconds of late video -> dropping frame >> (computer too slow ?) " >> >> so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( >> >> Quicktime does not want the url. >> >> marc >> >> -- >> Les Enfants Terribles - WWW.LET.DE >> Marc Manthey 50672 K?ln - Germany >> Hildeboldplatz 1a >> Tel.:0049-221-3558032 >> Mobil:0049-1577-3329231 >> mail: marc at let.de >> jabber :marc at kgraff.net >> IRC: #opencu freenode.net >> PGP/GnuPG: 0x1ac02f3296b12b4d >> twitter: http://twitter.com/macbroadcast >> web: http://www.let.de >> >> Opinions expressed may not even be mine by the time you read them, >> and >> certainly don't reflect those of any other entity (legal or >> otherwise). >> >> Please note that according to the German law on data retention, >> information on every electronic information exchange with me is >> retained for a period of six months. -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From tme at multicasttech.com Mon Jan 26 08:51:44 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 26 Jan 2009 09:51:44 -0500 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> References: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> Message-ID: <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> On Jan 26, 2009, at 9:42 AM, marc wrote: > > Am 26.01.2009 um 15:37 schrieb Leigh Porter: > >> Does it work in quicktime? > > > quicketime sayed "Invalid Url" > I think that you will need either a rtsp server or an SDP file for quicktime. Regards Marshall > regards > > > Marc >> >> >> >> On 26/1/09 14:31, "marc" wrote: >> >>> >>> Am 26.01.2009 um 14:09 schrieb Anton Kapela: >>>> >>>> unicast feeds: >>>> >>>> ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 >>> >>> >>> my VCL say >>> >>> " ffmpeg: more than 5 seconds of late video -> dropping frame >>> (computer too slow ?) " >>> >>> so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( >>> >>> Quicktime does not want the url. >>> >>> marc >>> >>> -- >>> Les Enfants Terribles - WWW.LET.DE >>> Marc Manthey 50672 K?ln - Germany >>> Hildeboldplatz 1a >>> Tel.:0049-221-3558032 >>> Mobil:0049-1577-3329231 >>> mail: marc at let.de >>> jabber :marc at kgraff.net >>> IRC: #opencu freenode.net >>> PGP/GnuPG: 0x1ac02f3296b12b4d >>> twitter: http://twitter.com/macbroadcast >>> web: http://www.let.de >>> >>> Opinions expressed may not even be mine by the time you read them, >>> and >>> certainly don't reflect those of any other entity (legal or >>> otherwise). >>> >>> Please note that according to the German law on data retention, >>> information on every electronic information exchange with me is >>> retained for a period of six months. > > -- > Les Enfants Terribles - WWW.LET.DE > Marc Manthey 50672 K?ln - Germany > Hildeboldplatz 1a > Tel.:0049-221-3558032 > Mobil:0049-1577-3329231 > mail: marc at let.de > jabber :marc at kgraff.net > IRC: #opencu freenode.net > PGP/GnuPG: 0x1ac02f3296b12b4d > twitter: http://twitter.com/macbroadcast > web: http://www.let.de > > Opinions expressed may not even be mine by the time you read them, > and certainly don't reflect those of any other entity (legal or > otherwise). > > Please note that according to the German law on data retention, > information on every electronic information exchange with me is > retained for a period of six months. > From morrowc.lists at gmail.com Mon Jan 26 08:54:07 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 26 Jan 2009 09:54:07 -0500 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> References: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> Message-ID: <75cb24520901260654u56062d54i1661eefefac426a4@mail.gmail.com> is there just an audio stream maybe?? (cause the video one isn't so much happy for me today) -Chris On Mon, Jan 26, 2009 at 9:51 AM, Marshall Eubanks wrote: > > On Jan 26, 2009, at 9:42 AM, marc wrote: > >> >> Am 26.01.2009 um 15:37 schrieb Leigh Porter: >> >>> Does it work in quicktime? >> >> >> quicketime sayed "Invalid Url" >> > > I think that you will need either a rtsp server or an SDP file for > quicktime. > > Regards > Marshall > >> regards >> >> >> Marc >>> >>> >>> >>> On 26/1/09 14:31, "marc" wrote: >>> >>>> >>>> Am 26.01.2009 um 14:09 schrieb Anton Kapela: >>>>> >>>>> unicast feeds: >>>>> >>>>> ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 >>>> >>>> >>>> my VCL say >>>> >>>> " ffmpeg: more than 5 seconds of late video -> dropping frame >>>> (computer too slow ?) " >>>> >>>> so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( >>>> >>>> Quicktime does not want the url. >>>> >>>> marc >>>> >>>> -- >>>> Les Enfants Terribles - WWW.LET.DE >>>> Marc Manthey 50672 K?ln - Germany >>>> Hildeboldplatz 1a >>>> Tel.:0049-221-3558032 >>>> Mobil:0049-1577-3329231 >>>> mail: marc at let.de >>>> jabber :marc at kgraff.net >>>> IRC: #opencu freenode.net >>>> PGP/GnuPG: 0x1ac02f3296b12b4d >>>> twitter: http://twitter.com/macbroadcast >>>> web: http://www.let.de >>>> >>>> Opinions expressed may not even be mine by the time you read them, and >>>> certainly don't reflect those of any other entity (legal or otherwise). >>>> >>>> Please note that according to the German law on data retention, >>>> information on every electronic information exchange with me is >>>> retained for a period of six months. >> >> -- >> Les Enfants Terribles - WWW.LET.DE >> Marc Manthey 50672 K?ln - Germany >> Hildeboldplatz 1a >> Tel.:0049-221-3558032 >> Mobil:0049-1577-3329231 >> mail: marc at let.de >> jabber :marc at kgraff.net >> IRC: #opencu freenode.net >> PGP/GnuPG: 0x1ac02f3296b12b4d >> twitter: http://twitter.com/macbroadcast >> web: http://www.let.de >> >> Opinions expressed may not even be mine by the time you read them, and >> certainly don't reflect those of any other entity (legal or otherwise). >> >> Please note that according to the German law on data retention, >> information on every electronic information exchange with me is retained for >> a period of six months. >> > > > From marc at let.de Mon Jan 26 09:01:36 2009 From: marc at let.de (marc) Date: Mon, 26 Jan 2009 16:01:36 +0100 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> References: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> Message-ID: Am 26.01.2009 um 15:51 schrieb Marshall Eubanks: > On Jan 26, 2009, at 9:42 AM, marc wrote: > >> >> Am 26.01.2009 um 15:37 schrieb Leigh Porter: >> >>> Does it work in quicktime? >> >> >> quicketime sayed "Invalid Url" >> > > I think that you will need either a rtsp server or an SDP file for > quicktime. hello Marshall well the server is not the problem ;) but where can i get the .sdp file ;) cheers Marc > > > Regards > Marshall > >> regards >> >> >> Marc >>> >>> >>> >>> On 26/1/09 14:31, "marc" wrote: >>> >>>> >>>> Am 26.01.2009 um 14:09 schrieb Anton Kapela: >>>>> >>>>> unicast feeds: >>>>> >>>>> ~1mbit HD-Lite h.264, in mpeg TS: HTTP://208.66.134.110:8000 >>>> >>>> >>>> my VCL say >>>> >>>> " ffmpeg: more than 5 seconds of late video -> dropping frame >>>> (computer too slow ?) " >>>> >>>> so 1.25 GHZ OSX Tiger with 16MB DSL isnt enough ? :-( >>>> >>>> Quicktime does not want the url. >>>> >>>> marc >>>> >>>> -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From graeme at graemef.net Mon Jan 26 09:04:26 2009 From: graeme at graemef.net (Graeme Fowler) Date: Mon, 26 Jan 2009 15:04:26 +0000 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: References: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> Message-ID: <1232982266.9672.0.camel@squonk.lboro.ac.uk> On Mon, 2009-01-26 at 16:01 +0100, marc wrote: > well the server is not the problem ;) > > but where can i get the .sdp file ;) http://nanog.org/streaming.php From steve at ibctech.ca Sun Jan 25 19:52:36 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 25 Jan 2009 20:52:36 -0500 Subject: New ISP to market, BCP 38, and new tactics Message-ID: <497D1764.4050709@ibctech.ca> Although I've posted to this list before, I don't want to waste your time. This is an ops question, so I'm looking for direction, off-list if necessary. We are a *very* small I-SP, and am just now being put in the position to be a backup transit for a client. Currently, our 'upstream' advertises our route for us, 208.70.104.0/21 from my AS 14270 (SBE96-ARIN). As I've wanted to do this myself for some time, the upstream has had issues allowing me to do so. I've also been advertising 2607:f118::/32 via BGP peering to kind people who have been sensitive to the lack of my 'upstream's' inability to provide me with native access. Now, I am about to force my 'upstream' to allow me to bring my advertisement (v4) back to me, I would like off-list feedback of any/all documentation that I should be aware of regarding filtering. I've proven that my 'upstream' doesn't do pull-up routes, doesn't filter BOGON, and given that they have no clients other than myself that have their own IP space, most likely is not capable of doing anything beyond a simple peering session. I've done much research on RPSL, BCP 38, and other basic filter methods (and from a systems standpoint, I always follow an allow,allow,default-deny approach) , and I am willing to follow all standards and recommended practises to ensure compliance with current Internet standards. Although we are small with minimal resources, I feel that touching this list is my best approach to ensure that when I do begin advertising routes, I conform to the most practical, realistic and best current common standards regarding IPv4 route advertisement and filtering. I hate being a 'rat', so I won't state who does what for AS14270 (on the v4 side of things). I have a 100Mbps fibre link from Cobourg Ontario, to _provider_ in 151 Front Toronto. My 'new' connection (which I control), is a direct link to Hydro One. I am open to bandwidth/connection options regarding this feed to Toronto, if you are commercially inclined, Thanks, Steve From tkapela at gmail.com Mon Jan 26 09:24:49 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 26 Jan 2009 11:24:49 -0400 Subject: Updated: New meeting hd stream servers Message-ID: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> So, I underestimated the popularity of the NANOG 45 meeting. We've moved the streams to a SJC and NYC reflector pair. I'm too cheap to implement GSLB or bothering coordinating anycast, so you'll need to self-direct your choice of which POP you'll watch from. HD-lite streams: http://nanog-east.owhost.net:8000 http://nanog-west.owhost.net:8000 Full-HD streams: http://nanog-east.owhost.net:9000 http://nanog-west.owhost.net:9000 Of course, you'll need a player that supports mpeg TS's and h.264. Videolan VLC or Mplayer work, others, not so much. Best, -Tk From ljb at merit.edu Mon Jan 26 09:31:44 2009 From: ljb at merit.edu (Larry J. Blunk) Date: Mon, 26 Jan 2009 10:31:44 -0500 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <1232982266.9672.0.camel@squonk.lboro.ac.uk> References: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> <1232982266.9672.0.camel@squonk.lboro.ac.uk> Message-ID: <497DD760.6000708@merit.edu> Graeme Fowler wrote: > On Mon, 2009-01-26 at 16:01 +0100, marc wrote: > >> well the server is not the problem ;) >> >> but where can i get the .sdp file ;) >> > > http://nanog.org/streaming.php > > > The link on the streaming page has been updated to http://www.nanog.org/qtstream.mov. This should work better. From me at sharloncarty.net Mon Jan 26 09:39:00 2009 From: me at sharloncarty.net (Sharlon R. Carty) Date: Mon, 26 Jan 2009 11:39:00 -0400 Subject: Updated: New meeting hd stream servers In-Reply-To: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> References: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> Message-ID: The HD-lite streams have no sound. On Mon, Jan 26, 2009 at 11:24 AM, Anton Kapela wrote: > So, I underestimated the popularity of the NANOG 45 meeting. > > We've moved the streams to a SJC and NYC reflector pair. > > I'm too cheap to implement GSLB or bothering coordinating anycast, so > you'll need to self-direct your choice of which POP you'll watch from. > > HD-lite streams: > > http://nanog-east.owhost.net:8000 > > http://nanog-west.owhost.net:8000 > > Full-HD streams: > > http://nanog-east.owhost.net:9000 > > http://nanog-west.owhost.net:9000 > > Of course, you'll need a player that supports mpeg TS's and h.264. > Videolan VLC or Mplayer work, others, not so much. > > Best, > > -Tk > > From marc at let.de Mon Jan 26 09:39:30 2009 From: marc at let.de (marc) Date: Mon, 26 Jan 2009 16:39:30 +0100 Subject: Mcast mpeg2 and unicast h.264 for NANOG-45 In-Reply-To: <497DD760.6000708@merit.edu> References: <6F1BD9E8-0F2A-4CF6-A066-B14B6D7AE01B@let.de> <982975D5-1FDC-4882-B070-F1F87DB4A9FD@multicasttech.com> <1232982266.9672.0.camel@squonk.lboro.ac.uk> <497DD760.6000708@merit.edu> Message-ID: <760924B3-72B7-466A-A0AA-B896A7D07A22@let.de> Am 26.01.2009 um 16:31 schrieb Larry J. Blunk: > Graeme Fowler wrote: >> On Mon, 2009-01-26 at 16:01 +0100, marc wrote: >> >>> well the server is not the problem ;) >>> >>> but where can i get the .sdp file ;) >>> >> >> http://nanog.org/streaming.php >> >> >> > > The link on the streaming page has been updated to > http://www.nanog.org/qtstream.mov. This should work > better. thanks both works seamlessly ;) greetings from germany marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From andrey.gordon at gmail.com Mon Jan 26 09:42:48 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Mon, 26 Jan 2009 10:42:48 -0500 Subject: Updated: New meeting hd stream servers In-Reply-To: References: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> Message-ID: <90ccfc90901260742q382ef99aw17da14e31e26cb1c@mail.gmail.com> I was just typing that up. I'm glad I'm not the only one. ----- Andrey Gordon [andrey.gordon at gmail.com] On Mon, Jan 26, 2009 at 10:39 AM, Sharlon R. Carty wrote: > The HD-lite streams have no sound. > > > > On Mon, Jan 26, 2009 at 11:24 AM, Anton Kapela wrote: > > > So, I underestimated the popularity of the NANOG 45 meeting. > > > > We've moved the streams to a SJC and NYC reflector pair. > > > > I'm too cheap to implement GSLB or bothering coordinating anycast, so > > you'll need to self-direct your choice of which POP you'll watch from. > > > > HD-lite streams: > > > > http://nanog-east.owhost.net:8000 > > > > http://nanog-west.owhost.net:8000 > > > > Full-HD streams: > > > > http://nanog-east.owhost.net:9000 > > > > http://nanog-west.owhost.net:9000 > > > > Of course, you'll need a player that supports mpeg TS's and h.264. > > Videolan VLC or Mplayer work, others, not so much. > > > > Best, > > > > -Tk > > > > > From jabley at hopcount.ca Mon Jan 26 09:49:08 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 26 Jan 2009 10:49:08 -0500 Subject: Updated: New meeting hd stream servers In-Reply-To: <90ccfc90901260742q382ef99aw17da14e31e26cb1c@mail.gmail.com> References: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> <90ccfc90901260742q382ef99aw17da14e31e26cb1c@mail.gmail.com> Message-ID: On 26 Jan 2009, at 10:42, Andrey Gordon wrote: > I was just typing that up. I'm glad I'm not the only one. the nanog-east stream video and audio are fine for me, in AS 9327. Joe From morrowc.lists at gmail.com Mon Jan 26 09:52:26 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 26 Jan 2009 10:52:26 -0500 Subject: Updated: New meeting hd stream servers In-Reply-To: References: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> <90ccfc90901260742q382ef99aw17da14e31e26cb1c@mail.gmail.com> Message-ID: <75cb24520901260752l1e498770q3657b02cbe96dbef@mail.gmail.com> On Mon, Jan 26, 2009 at 10:49 AM, Joe Abley wrote: > > On 26 Jan 2009, at 10:42, Andrey Gordon wrote: > >> I was just typing that up. I'm glad I'm not the only one. > > the nanog-east stream video and audio are fine for me, in AS 9327. me too! - from a 701 customer connection in IAD/TCO/DCA. From tkapela at gmail.com Mon Jan 26 09:52:52 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 26 Jan 2009 11:52:52 -0400 Subject: Updated: New meeting hd stream servers In-Reply-To: References: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> <90ccfc90901260742q382ef99aw17da14e31e26cb1c@mail.gmail.com> Message-ID: <2e9d8ae50901260752n724f2b2fre4e6ac1bbbfca80f@mail.gmail.com> Of course, I'd recommend everyone use the most recent vlc, 0.9.8a, before debugging more. Send me a direct email with output from "debug messages" and let me know what details show in the "stream information" gui dialog. -Tk From jtrooney at nexdlevel.com Mon Jan 26 10:59:03 2009 From: jtrooney at nexdlevel.com (Jeff Rooney) Date: Mon, 26 Jan 2009 10:59:03 -0600 Subject: ATT Contact Message-ID: Does anyone have an ATT contact that might be able to help with a Business Class DSL issue? We are seeing pretty major packet loss across their network, but since their tests are not registering any problems they will not escalate the the issue: Host Loss% Snt Last Avg Best Wrst StDev 1. 216.x.x.x 0.0% 15 0.9 1.8 0.9 11.6 2.8 2. 64.14.x.x 0.0% 15 1.3 1.6 1.3 4.5 0.8 3. hr2-ge-11-46.Elkgrovech3.savvis.net 0.0% 14 0.7 0.7 0.6 1.5 0.2 4. cr2-tengig-0-7-5-0.chicago.savvis.net 0.0% 14 1.9 2.1 1.8 3.2 0.4 5. 204.70.200.90 0.0% 14 18.6 18.8 18.5 19.3 0.2 6. 204.70.197.241 0.0% 14 19.3 19.5 19.3 19.9 0.2 7. ex1-g4-0-1.eqabva.sbcglobal.net 15.4% 14 22.3 22.1 21.8 23.2 0.4 8. dist1-g1-3.chcgil.ameritech.net 21.4% 14 24.5 24.6 24.0 24.8 0.2 9. Se20-g5-2.chcgil.sbcglobal.net 0.0% 14 23.9 24.0 23.7 24.1 0.1 10. adsl-76-193-193-214.dsl.chcgil.sbcglobal.net 7.1% 14 32.0 35.3 32.0 54.0 6.1 11. adsl-76-193-193-210.dsl.chcgil.sbcglobal.net 7.1% 14 32.9 34.1 32.9 39.8 1.8 Jeff Rooney jtrooney at nexdlevel.com From andrew.fried at gmail.com Mon Jan 26 11:48:50 2009 From: andrew.fried at gmail.com (Andrew Fried) Date: Mon, 26 Jan 2009 12:48:50 -0500 Subject: DNS DDoS Host list Message-ID: <497DF782.3010202@gmail.com> Based on the logs from the past 48 hours, here are the hosts that appear to be under attack. The count field reflects the individual number of "'./NS/IN' denied" log entries that appeared in my logs. Note that the stats for 206.71.158.30 are under-reported due to the fact that I blackholed that address last night, however packet captures reveal that I'm no longer seeing spoofed packets targeting that address. +----------------+-------------+ | host | count(host) | +----------------+-------------+ | 10.168.69.6 | 18 | | 202.104.106.49 | 84 | | 206.71.158.30 | 34327 | | 210.21.218.138 | 84 | | 63.217.28.226 | 2696 | | 66.230.160.1 | 3541 | | 76.9.16.171 | 1355 | +----------------+-------------+ -- Andrew Fried andrew.fried at gmail.com From jmartinez at zero11.com Mon Jan 26 11:56:39 2009 From: jmartinez at zero11.com (John Martinez) Date: Mon, 26 Jan 2009 09:56:39 -0800 Subject: ATT Contact In-Reply-To: References: Message-ID: <497DF957.4060801@zero11.com> Jeff Rooney wrote: > Does anyone have an ATT contact that might be able to help with a Business > Class DSL issue? We are seeing pretty major packet loss across their > network, but since their tests are not registering any problems they will > not escalate the the issue: > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. 216.x.x.x > 0.0% 15 0.9 1.8 0.9 11.6 2.8 > 2. 64.14.x.x > 0.0% 15 1.3 1.6 1.3 4.5 0.8 > 3. hr2-ge-11-46.Elkgrovech3.savvis.net > 0.0% 14 0.7 0.7 0.6 1.5 0.2 > 4. cr2-tengig-0-7-5-0.chicago.savvis.net > 0.0% 14 1.9 2.1 1.8 3.2 0.4 > 5. 204.70.200.90 > 0.0% 14 18.6 18.8 18.5 19.3 0.2 > 6. 204.70.197.241 > 0.0% 14 19.3 19.5 19.3 19.9 0.2 > 7. ex1-g4-0-1.eqabva.sbcglobal.net > 15.4% 14 22.3 22.1 21.8 23.2 0.4 > 8. dist1-g1-3.chcgil.ameritech.net > 21.4% 14 24.5 24.6 24.0 24.8 0.2 > 9. Se20-g5-2.chcgil.sbcglobal.net > 0.0% 14 23.9 24.0 23.7 24.1 0.1 > 10. adsl-76-193-193-214.dsl.chcgil.sbcglobal.net > 7.1% 14 32.0 35.3 32.0 54.0 6.1 > 11. adsl-76-193-193-210.dsl.chcgil.sbcglobal.net > 7.1% 14 32.9 34.1 32.9 39.8 1.8 > > > > Jeff Rooney > jtrooney at nexdlevel.com there is packet loss between sbc (att) and Savvis. http://www.internetpulse.net/Main.aspx?xAxis=Destination&yAxis=Origin&zAxis=Metric&nAxis=Period From tkapela at gmail.com Mon Jan 26 12:30:17 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 26 Jan 2009 14:30:17 -0400 Subject: Updated: New meeting hd stream servers In-Reply-To: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> References: <2e9d8ae50901260724v347fcd9bn114cc013bc447d84@mail.gmail.com> Message-ID: <2e9d8ae50901261030u29e38f8co445b2a5160505027@mail.gmail.com> One short update. The "full Hd" transcoded streams will be (i.e. :9000) offline for the remainder of the NANOG meeting. The encoder system we were using to provide both the full and hf-lite streams is offline (system trouble). We've switched to a backup system, but it can only provide enough resources for the hd-lite stream. HD-lite streams: http://nanog-east.owhost.net:8000 http://nanog-west.owhost.net:8000 We've also determined there is a VLC bug that prevents mpeg4 audio re-packetization from correctly determining the number of audio channels, thus causing several users with several playback clients from hearing the audio program. The audio codec has been switched to mpeg2 audio, as this avoids the packetizer bug. Hopefully this is fixed. Enjoy, -Tk From tkapela at gmail.com Mon Jan 26 12:50:15 2009 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 26 Jan 2009 14:50:15 -0400 Subject: NANOG meeting video RTSP source for mobile devices Message-ID: <2e9d8ae50901261050x3287884bv7d975d306b6354f0@mail.gmail.com> List, Tim Jackson at Iris Transport was whipped up a stream playable on 3gpp-multimedia compatible mobile devices. It's about 150 kbits/sec, so evdo or 3g will likely been the minimum data services needed to view it. Find it here: rtsp://nanog.iristransport.net/nanog.sdp Enjoy, -Tk From bkuzma at electronerdz.com Mon Jan 26 15:48:44 2009 From: bkuzma at electronerdz.com (Bobby Kuzma) Date: Mon, 26 Jan 2009 16:48:44 -0500 Subject: Comcast NOC contact wanted Message-ID: <7474F92C63F5714BA8DF412B79E0733E5EE3B14D98@mb1.he.electronerdz.net> Hello all, We've been having issues with latency on one of our customers in Tallahassee, FL on Comcast, due to some very odd routing. Could anyone with Comcast please get in touch with me off-list. Thanks, Bobby Kuzma, CISSP VP, Professional Services ElectroNerdz, Inc. From tjc at ecs.soton.ac.uk Tue Jan 27 08:10:52 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 27 Jan 2009 14:10:52 +0000 Subject: NANOG stream - projector screens Message-ID: <20090127141051.GI29354@login.ecs.soton.ac.uk> Hi, Just a minor comment - yesterday the projector screen appeared larger in the streamed picture (I think we only saw one screen?) and was readable. Today the view seems to have been made wider, and both screens appear brighter and smaller and no longer readable on the HD stream. Would be nice if they were :) -- Tim From bburke at merit.edu Tue Jan 27 08:13:32 2009 From: bburke at merit.edu (Betty Burke) Date: Tue, 27 Jan 2009 09:13:32 -0500 (EST) Subject: NANOG stream - projector screens In-Reply-To: <20090127141051.GI29354@login.ecs.soton.ac.uk> Message-ID: <1183023611.6327801233065612605.JavaMail.root@crono> Thanks for the note... we are making the adjustment. Betty Merit Network Inc. Merit/NANOG Project Manager ----- Original Message ----- From: "Tim Chown" To: nanog at nanog.org Sent: Tuesday, January 27, 2009 9:10:52 AM GMT -05:00 US/Canada Eastern Subject: NANOG stream - projector screens Hi, Just a minor comment - yesterday the projector screen appeared larger in the streamed picture (I think we only saw one screen?) and was readable. Today the view seems to have been made wider, and both screens appear brighter and smaller and no longer readable on the HD stream. Would be nice if they were :) -- Tim From tjc at ecs.soton.ac.uk Tue Jan 27 08:16:28 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 27 Jan 2009 14:16:28 +0000 Subject: NANOG stream - projector screens In-Reply-To: <1183023611.6327801233065612605.JavaMail.root@crono> References: <20090127141051.GI29354@login.ecs.soton.ac.uk> <1183023611.6327801233065612605.JavaMail.root@crono> Message-ID: <20090127141627.GJ29354@login.ecs.soton.ac.uk> Wow that was fast - much better now and the HE presentation graph legends are even readable :) Thanks! Tim On Tue, Jan 27, 2009 at 09:13:32AM -0500, Betty Burke wrote: > Thanks for the note... we are making the adjustment. > > Betty > > > Merit Network Inc. > Merit/NANOG Project Manager > > > ----- Original Message ----- > From: "Tim Chown" > To: nanog at nanog.org > Sent: Tuesday, January 27, 2009 9:10:52 AM GMT -05:00 US/Canada Eastern > Subject: NANOG stream - projector screens > > Hi, > > Just a minor comment - yesterday the projector screen appeared larger in > the streamed picture (I think we only saw one screen?) and was readable. > Today the view seems to have been made wider, and both screens appear > brighter and smaller and no longer readable on the HD stream. > > Would be nice if they were :) > > -- > Tim > -- Tim From swmike at swm.pp.se Tue Jan 27 08:24:18 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 27 Jan 2009 15:24:18 +0100 (CET) Subject: NANOG stream - projector screens In-Reply-To: <20090127141627.GJ29354@login.ecs.soton.ac.uk> References: <20090127141051.GI29354@login.ecs.soton.ac.uk> <1183023611.6327801233065612605.JavaMail.root@crono> <20090127141627.GJ29354@login.ecs.soton.ac.uk> Message-ID: On Tue, 27 Jan 2009, Tim Chown wrote: > Wow that was fast - much better now and the HE presentation graph legends > are even readable :) The presentations PDFs come up on the agenda page ahead of the presentation start (has been so today anyway), so that might help as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From chort at smtps.net Tue Jan 27 08:34:16 2009 From: chort at smtps.net (Brian Keefer) Date: Tue, 27 Jan 2009 06:34:16 -0800 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: <8762DC96-CF43-4D4C-9931-A567D406D5CB@smtps.net> There's another new IP: 67.192.144.0 . Initially (around 2AM Pacific) the query rate was 1 per second, but is now down significantly. -- bk From chort at smtps.net Tue Jan 27 08:42:03 2009 From: chort at smtps.net (Brian Keefer) Date: Tue, 27 Jan 2009 06:42:03 -0800 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: <8762DC96-CF43-4D4C-9931-A567D406D5CB@smtps.net> References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> <8762DC96-CF43-4D4C-9931-A567D406D5CB@smtps.net> Message-ID: <1E9CB170-598D-4A55-B31F-7014B3731752@smtps.net> and just now it changed to 64.57.246.146. Interestingly, the IP changed within minutes of me posting to NANOG. -- bk On Jan 27, 2009, at 6:34 AM, Brian Keefer wrote: > There's another new IP: 67.192.144.0 . > > Initially (around 2AM Pacific) the query rate was 1 per second, but > is now down significantly. > > > -- > bk > > > > From andrew.fried at gmail.com Tue Jan 27 09:13:46 2009 From: andrew.fried at gmail.com (Andrew Fried) Date: Tue, 27 Jan 2009 10:13:46 -0500 Subject: DNS DDoS - New Hosts Message-ID: <497F24AA.5050504@gmail.com> As of 10:10am (EST) new hosts are now being targeted in the DDoS. Interestingly enough two of the ip addresses are in China. Attached is a file containing the geoip/whois and peering information for the targeted systems. +----------------+-------------+ | host | count(host) | +----------------+-------------+ | 202.104.106.49 | 45 | | 210.21.218.138 | 48 | | 63.217.28.226 | 1153 | | 64.57.246.146 | 1559 | | 67.192.144.0 | 11765 | | 76.9.16.171 | 582 | +----------------+-------------+ -- Andrew Fried andrew.fried at gmail.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ddos-20090127-1010.txt URL: From xaerni at pop.ch Tue Jan 27 09:37:35 2009 From: xaerni at pop.ch (Xaver Aerni) Date: Tue, 27 Jan 2009 16:37:35 +0100 Subject: Tracking the DNS amplification attacks (was: isprime DOS inprogress) References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com><20090120205514.GA10257@fries.net><1232557692.9593.57.camel@squonk.lboro.ac.uk><8763k7li3f.fsf@obelix.mork.no><90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com><1232742035.3801.1.camel@localhost.localdomain><2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net><8762DC96-CF43-4D4C-9931-A567D406D5CB@smtps.net> <1E9CB170-598D-4A55-B31F-7014B3731752@smtps.net> Message-ID: Today we have from 208.69.36.12, DNS 67.192.144.x divers of this networkes attakes ----- Original Message ----- From: "Brian Keefer" To: Sent: Tuesday, January 27, 2009 3:42 PM Subject: Re: Tracking the DNS amplification attacks (was: isprime DOS inprogress) > and just now it changed to 64.57.246.146. Interestingly, the IP changed > within minutes of me posting to NANOG. > > -- > bk > > > > On Jan 27, 2009, at 6:34 AM, Brian Keefer wrote: > >> There's another new IP: 67.192.144.0 . >> >> Initially (around 2AM Pacific) the query rate was 1 per second, but is >> now down significantly. >> >> >> -- >> bk >> >> >> >> > > > From bburke at merit.edu Tue Jan 27 09:50:54 2009 From: bburke at merit.edu (Betty Burke) Date: Tue, 27 Jan 2009 10:50:54 -0500 (EST) Subject: [NANOG-announce] NANOG45 Survey Message-ID: <635894549.6350601233071454869.JavaMail.root@crono> Please excuse the posting to NANOG, however given the large number of remote viewers we wanted all to be aware; the NANOG45 Survey is online. Please take a moment and complete http://www.surveymonkey.com/s.aspx?sm=xAI_2bhyaMaWjl2diOG8lBKQ_3d_3d For those on site, there are also some paper copies in LaFiesta. We look forward to your comments!! All best. Betty Merit Network Inc. Merit/NANOG Project Manager _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From tkapela at gmail.com Tue Jan 27 10:19:42 2009 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 27 Jan 2009 12:19:42 -0400 Subject: NANOG meeting video RTSP source for mobile devices In-Reply-To: <2e9d8ae50901261050x3287884bv7d975d306b6354f0@mail.gmail.com> References: <2e9d8ae50901261050x3287884bv7d975d306b6354f0@mail.gmail.com> Message-ID: <2e9d8ae50901270819j30356d41ucc912c757beee79a@mail.gmail.com> RTSP is back up, for those mobile or on a restrictive corporate network. rtsp://nanog.iristransport.net/nanog.sdp -Tk From wingying at umich.edu Tue Jan 27 12:54:10 2009 From: wingying at umich.edu (wingying) Date: Tue, 27 Jan 2009 13:54:10 -0500 Subject: out-of-band access bandwidth Message-ID: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Hi all, A quick question, what is the common bandwidth for out-of-band access? Thanks. From brian at meganet.net Tue Jan 27 12:52:56 2009 From: brian at meganet.net (Brian Wallingford) Date: Tue, 27 Jan 2009 13:52:56 -0500 (EST) Subject: out-of-band access bandwidth In-Reply-To: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Message-ID: On Tue, 27 Jan 2009, wingying wrote: : :Hi all, :A quick question, what is the common bandwidth for out-of-band access? :Thanks. That would depend on what your OOB uses for an interface (cli/gui), or what bandwidth you have to spare. Not necessarily in any given order. Overprovisioning alleviates most concerns, and bw, whether clear-channel in-house, or otherwise is cheap these days :) From mksmith at adhost.com Tue Jan 27 13:04:36 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 27 Jan 2009 11:04:36 -0800 Subject: out-of-band access bandwidth In-Reply-To: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Message-ID: <17838240D9A5544AAA5FF95F8D520316056589EE@ad-exh01.adhost.lan> > Hi all, > A quick question, what is the common bandwidth for out-of-band access? > Thanks. > In the optical world it's often 192 Kb/sec. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From surfer at mauigateway.com Tue Jan 27 13:09:28 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 27 Jan 2009 11:09:28 -0800 Subject: out-of-band access bandwidth Message-ID: <20090127110928.F6C522EC@resin13.mta.everyone.net> --- wingying at umich.edu wrote: A quick question, what is the common bandwidth for out-of-band access? -------------------------------------- I would say that varies. Size them based on needs and expected traffic levels. There is no common BW, but it would be small as compared to production links. scott From cchurc05 at harris.com Tue Jan 27 13:22:06 2009 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 27 Jan 2009 13:22:06 -0600 Subject: out-of-band access bandwidth In-Reply-To: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Message-ID: -----Original Message----- From: wingying [mailto:wingying at umich.edu] Sent: Tuesday, January 27, 2009 1:54 PM To: nanog at nanog.org Cc: Xu (Simon) Chen Subject: out-of-band access bandwidth >Hi all, >A quick question, what is the common bandwidth for out-of-band access? >Thanks. Probably depends if you use in-band management primarily. If your code pushes etc normally happen only inband, and out of band is reserved for console/CLI access only in emergencies, then small (9.6 to 64kb) is probably fine. From chucklist at forest.net Tue Jan 27 13:37:28 2009 From: chucklist at forest.net (chuck goolsbee) Date: Tue, 27 Jan 2009 11:37:28 -0800 Subject: out-of-band access bandwidth In-Reply-To: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Message-ID: <20090127113728095245.c27b3e7b@forest.net> On Tue, 27 Jan 2009 13:54:10 -0500, wingying wrote: > A quick question, what is the common bandwidth for out-of-band access? > Thanks. Clearwire + POTS as a backup. --chuck From broldan at gmail.com Tue Jan 27 13:38:18 2009 From: broldan at gmail.com (Brad Roldan) Date: Tue, 27 Jan 2009 11:38:18 -0800 Subject: MPLS Backbone ASN Use - Best Practice? Message-ID: <5ca99b350901271138x36f1ea94t53d700c3dcec0414@mail.gmail.com> Hi, I'm working with a team of engineers to build an IP MPLS backbone, with the intention of eventually offering MPLS VPN services (RFC 2547/4364). We have an existing IP transit backbone with an ASN already in use. Our plan is to leverage our existing infrastructure for both MPLS and IP transit services, as we are not in a position to purchase new hardware and tranport for a dedicated MPLS backbone. Questions: - Is there an industry best practice or recommendation on using the same ASN for both our IP transit service AND our MPLS service, or do we use a dedicated ASN for each service? - I've noticed that large providers (like Level 3) use different ASNs for MPLS (ASN 1) and IP Transit (ASN 3356), what are small and mid-sized providers doing? - Is this a non-issue because customers don't really care what ASN their provider is using to deliver IP MPLS services? Thanks, Brad Roldan From smeuse at mara.org Tue Jan 27 13:50:14 2009 From: smeuse at mara.org (Steve Meuse) Date: Tue, 27 Jan 2009 14:50:14 -0500 Subject: out-of-band access bandwidth In-Reply-To: <17838240D9A5544AAA5FF95F8D520316056589EE@ad-exh01.adhost.lan> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> <17838240D9A5544AAA5FF95F8D520316056589EE@ad-exh01.adhost.lan> Message-ID: <20090127195014.GE31423@mara.org> Michael K. Smith - Adhost expunged (mksmith at adhost.com): > > Hi all, > > A quick question, what is the common bandwidth for out-of-band access? > > Thanks. > > > In the optical world it's often 192 Kb/sec. I think that was common circa late 90's, I've seen at least two optical providers that use 10Mb/s optical overhead channels on recent technology. -Steve From mhuff at ox.com Tue Jan 27 14:04:19 2009 From: mhuff at ox.com (Matthew Huff) Date: Tue, 27 Jan 2009 15:04:19 -0500 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <20090127195014.GE31423@mara.org> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> <17838240D9A5544AAA5FF95F8D520316056589EE@ad-exh01.adhost.lan> <20090127195014.GE31423@mara.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> Given the recent DNS amplification attacks, I've audit and updated our authoritative servers. We are using 9.6.0-P1 now. I've been using the cyrmu templates, but one thing I see is that the dns queries to the . hint file are still occuring and are not being denied by our servers. For example: 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view external-in: query: . IN NS + 27-Jan-2009 15:00:23.118 queries: client 64.57.246.146#33146: view external-in: query: . IN NS + the named.conf has: ... ... ... view "external-in" in { match-clients { any; }; recursion no; additional-from-auth no; additional-from-cache no; zone "." in { type hint; file "db.cache"; }; ... ... since you can't put a "allow-query { none; };" in a hint zone, what can I do to deny the query to the . zone file? ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: application/octet-stream Size: 1595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4229 bytes Desc: not available URL: From braaen at zcorum.com Tue Jan 27 14:13:08 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 27 Jan 2009 15:13:08 -0500 Subject: out-of-band access bandwidth In-Reply-To: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Message-ID: <200901271513.08529.braaen@zcorum.com> Many times I've used 9600 or 2400 baud over dail-up for OOB of routers. On the other hand some enterprises use a seperate 1Gbps Vlan for management. Again it depends on the type of traffic (i.e. snmp(traps), telnet, ssh, graphical, web, syslog, netflow etc..). For ssh/telnet without the need for filetransfer a dial-ip modem should work fine. ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Tuesday 27 January 2009, wingying wrote: > > Hi all, > A quick question, what is the common bandwidth for out-of-band access? > Thanks. > > > From leigh.porter at ukbroadband.com Tue Jan 27 14:23:09 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 27 Jan 2009 20:23:09 +0000 Subject: out-of-band access bandwidth In-Reply-To: <20090127113728095245.c27b3e7b@forest.net> Message-ID: We used a 3rd party Frame Relay network for out of band access. On 27/1/09 19:37, "chuck goolsbee" wrote: > On Tue, 27 Jan 2009 13:54:10 -0500, wingying wrote: >> A quick question, what is the common bandwidth for out-of-band access? >> Thanks. > > Clearwire + POTS as a backup. > > --chuck > > > From nanog at konadogs.net Tue Jan 27 15:16:44 2009 From: nanog at konadogs.net (Nate Itkin) Date: Tue, 27 Jan 2009 11:16:44 -1000 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> Message-ID: <200901272116.n0RLGiJA002250@ns1.konadogs.net> On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote: > < ... snip ... > > dns queries to the . hint file > are still occuring and are not being denied by our servers. For example: > 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view > external-in: query: . IN NS + > < ... snip ... > > since you can't put a "allow-query { none; };" in a hint zone, what can I do > to deny the query to the . zone file? AFAIK, that's about the best you can do with the DNS configuration. You've mitigated the amplification value, so hopefully the perpetrator(s) will drop you. If you're willing to keep up with the moving targets, the next level is an inbound packet filter. Add to your inbound ACL: deny udp host 64.57.246.146 neq 53 any eq 53 Also on this topic: Coincident with this DNS DOS, I started seeing inbound PTR queries from various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers). They receive no response, yet they persist. Anyone have thoughts on their part in the scheme? Best wishes, Nate Itkin From randy at psg.com Tue Jan 27 15:37:33 2009 From: randy at psg.com (Randy Bush) Date: Wed, 28 Jan 2009 06:37:33 +0900 Subject: AfNOG 2009 - Call for Presentations Message-ID: <497F7E9D.2010005@psg.com> ---------------------- Call for Presentations ---------------------- The African Network Operators' Group (AfNOG) invites applications from people who wish to teach a tutorial, make a presentation, or chair a panel discussion at the 10th AfNOG meeting in Cairo, Egypt, in May 2009. We also invite programme suggestions from other people. Background ---------- AfNOG and AfriNIC are jointly organising a two-week event that includes the AfNOG Workshop on Network Technology (offering advanced training in a week-long hands-on workshop), several full-day Tutorials, a one-day AfNOG meeting, and a two-day AfriNIC meeting. Further information about the event may be found at and . Venue ----- Venue for the event will be announced shortly About AfNOG ----------- AfNOG (see ) is a forum for cooperation and the exchange of technical information between operators of Internet-connected networks in Africa. AfNOG has organised an event like this one every year since 2000. About the Tutorials & Conference ------------------- The AfNOG Conference takes the form of a series of short presentations followed by open discussions, during which network operators from around the continent share experiences, discuss problems and their solutions as well as interact on various issues affecting African networking. The conference has in the past attracted over 200 participants, mainly consisting of engineering staff from national service providers, managers from IT Enterprises and members of the research and education community. Several tutorials will be offered before the AfNOG conference from 17 - 18 May 2009. Tutorials are technical workshops which focus on a particular subject in-depth and should be non-commercial in nature. Tutorials take place in a classroom-style environment, and may include a hands-on practical component. They are intended to offer advanced training relating to technology already deployed or soon to be deployed on networking and related services provisioning for ISP operations. Potential Areas of Interest --------------------------- Conference: * Routing Operations: Rural Connectivity Solution, IPv4 and IPv6 Routing, MPLS, Backbone operations, Traffic Engineering * Services Operations: DNS, Email, VOIP, Content Development, Open Source Tools and Analysis * Security Operations: NSP-Sec, DDoS, Security Operations, Anti-SPAM, Anti-Malware. * Internet Provider Relationships: IXP Operations, Peering * Technologies: Wireless, WiMax, DSL, Broadband access aggregation * Internet Governance Tutorials: * Network Monitoring and Management * Wireless Networking * Advanced Routing * DNSSEC * IPV6 * VOIP How to Submit ------------- People interested in making a presentation, or chairing a panel discussion at the AfNOG meeting are invited to submit a proposal not later than 28 February 2008 We ask that the following information be sent in an email message to . * speaker/presenter name and affiliation * email address and phone number * nature of the proposal (conference presentation, panel discussion, or tutorial) * proposed title * requested time allocation (for conference presentations or panel discussions: 30 minutes to 2 hours). * an abstract of no more than 200 words * permission to reproduce your presentation after the event, including permission to post it on the AfNOG website. The Programme Committee also welcomes suggestions and expressions of interest, even if you don't have all the above information. Funding and Support AfNOG is a not-for-profit event and because limited funds are available, conference presenters and tutorial instructors are expected to cover their travel expenses. However, tutorial instructor or conference presenters are exempted from paying registration fees. Deadlines ---------- Submission deadline: 28 Feb 2009 Notification by: 15 March 2009 Final Program Published: 31 March 2009 Send Requests to: afnog-presentations09 at afnog.org From jay at miscreant.org Tue Jan 27 15:42:39 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Wed, 28 Jan 2009 08:42:39 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> <17838240D9A5544AAA5FF95F8D520316056589EE@ad-exh01.adhost.lan> <20090127195014.GE31423@mara.org> <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> Message-ID: <20090128084239.sgq1qjkko4scgcwo@web1.nswh.com.au> Quoting Matthew Huff : > Given the recent DNS amplification attacks, I've audit and updated our > authoritative servers. We are using 9.6.0-P1 now. I've been using the cyrmu > templates, but one thing I see is that the dns queries to the . hint file > are still occuring and are not being denied by our servers. For example: > > 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view > external-in: query: . IN NS + > 27-Jan-2009 15:00:23.118 queries: client 64.57.246.146#33146: view > external-in: query: . IN NS + > > the named.conf has: > > ... > ... > ... > > view "external-in" in { > match-clients { any; }; > recursion no; > additional-from-auth no; > additional-from-cache no; > > zone "." in { > type hint; > file "db.cache"; > }; > ... > ... > > since you can't put a "allow-query { none; };" in a hint zone, what can I do > to deny the query to the . zone file? > > > > ---- > Matthew Huff?????? | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > http://www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff? | Fax:?? 914-460-4139 > Hi Matthew, I'm using the following with 9.5.1: view "external" { recursion no; allow-query-cache { none; }; zone "." IN { type hint; file "/var/named/named.ca"; And my logs indicate that the requests for . IN NS are being denied: Jan 28 08:40:38 web1 named[12337]: client 64.57.246.146#33453: view external: query (cache) './NS/IN' denied Jan 28 08:40:39 web1 named[12337]: client 67.192.144.0#41794: view external: query (cache) './NS/IN' denied Cheers, Jay From sethm at rollernet.us Tue Jan 27 15:43:35 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 27 Jan 2009 13:43:35 -0800 Subject: out-of-band access bandwidth In-Reply-To: <20090127113728095245.c27b3e7b@forest.net> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> <20090127113728095245.c27b3e7b@forest.net> Message-ID: <497F8007.90809@rollernet.us> chuck goolsbee wrote: > On Tue, 27 Jan 2009 13:54:10 -0500, wingying wrote: >> A quick question, what is the common bandwidth for out-of-band access? >> Thanks. > > Clearwire + POTS as a backup. > POTS + CDMA cellular for me. There's a lot of ways to do it. It really depends on what you want to do, what's available, what's reliable, and what you can afford. Like your primary circuits, if you need reliable OOB access pick more than one method just in case. ~Seth From leigh.porter at ukbroadband.com Tue Jan 27 15:51:35 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 27 Jan 2009 21:51:35 +0000 Subject: out-of-band access bandwidth In-Reply-To: <497F8007.90809@rollernet.us> Message-ID: And be careful.. It's easy to have simple local passwords, a dial-in modem and then get pwned.. Were I used to be, we had encrypted modems for POP dialin. -- Leigh Porter On 27/1/09 21:43, "Seth Mattinen" wrote: > chuck goolsbee wrote: >> On Tue, 27 Jan 2009 13:54:10 -0500, wingying wrote: >>> A quick question, what is the common bandwidth for out-of-band access? >>> Thanks. >> >> Clearwire + POTS as a backup. >> > > POTS + CDMA cellular for me. There's a lot of ways to do it. It really > depends on what you want to do, what's available, what's reliable, and > what you can afford. Like your primary circuits, if you need reliable > OOB access pick more than one method just in case. > > ~Seth From mhernand1 at comcast.net Tue Jan 27 15:55:09 2009 From: mhernand1 at comcast.net (manolo) Date: Tue, 27 Jan 2009 16:55:09 -0500 Subject: APNIC offline Message-ID: <497F82BD.7090107@comcast.net> All, Is anyone else seeing www.apnic.net offline? I have tried from two locations and the website does not respond. whois is working as expected though. Manolo From chaim.rieger at gmail.com Tue Jan 27 15:57:55 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Tue, 27 Jan 2009 13:57:55 -0800 Subject: APNIC offline In-Reply-To: <497F82BD.7090107@comcast.net> References: <497F82BD.7090107@comcast.net> Message-ID: <497F8363.5060004@gmail.com> manolo wrote: > All, > > Is anyone else seeing www.apnic.net offline? I have tried from two > locations and the website does not respond. whois is working as expected > though. > > > > Manolo > tis not online but i did sleep at a holiday inn last night From jay at miscreant.org Tue Jan 27 16:01:54 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Wed, 28 Jan 2009 09:01:54 +1100 Subject: APNIC offline In-Reply-To: <497F82BD.7090107@comcast.net> References: <497F82BD.7090107@comcast.net> Message-ID: <20090128090154.n0id9f5fl0kkgscg@web1.nswh.com.au> Tried from the US and AU, I can get to the box's IP, the webserver appears to be down though. Quoting manolo : > All, > > Is anyone else seeing www.apnic.net offline? I have tried from two > locations and the website does not respond. whois is working as > expected though. > > > > Manolo From r.hyunseog at ieee.org Tue Jan 27 16:07:10 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Tue, 27 Jan 2009 16:07:10 -0600 Subject: APNIC offline In-Reply-To: <497F82BD.7090107@comcast.net> References: <497F82BD.7090107@comcast.net> Message-ID: <497F858E.5000807@ieee.org> Website www.apnic.net is not accessable from my desktop, either. But it is responded with ping, so it may be the issue with specific application such as web server daemon? Alex manolo wrote: > All, > > Is anyone else seeing www.apnic.net offline? I have tried from two > locations and the website does not respond. whois is working as > expected though. > > > > Manolo > > > From skeeve at skeeve.org Tue Jan 27 16:23:27 2009 From: skeeve at skeeve.org (Skeeve Stevens) Date: Wed, 28 Jan 2009 09:23:27 +1100 Subject: APNIC offline In-Reply-To: <497F858E.5000807@ieee.org> References: <497F82BD.7090107@comcast.net> <497F858E.5000807@ieee.org> Message-ID: <04b601c980cd$e0b99700$a22cc500$@org> Back now, crisis avderted ...Skeeve -----Original Message----- From: Alex H. Ryu [mailto:r.hyunseog at ieee.org] Sent: Wednesday, 28 January 2009 9:07 AM To: manolo Cc: nanog at merit.edu Subject: Re: APNIC offline Website www.apnic.net is not accessable from my desktop, either. But it is responded with ping, so it may be the issue with specific application such as web server daemon? Alex manolo wrote: > All, > > Is anyone else seeing www.apnic.net offline? I have tried from two > locations and the website does not respond. whois is working as > expected though. > > > > Manolo > > > From morrowc.lists at gmail.com Tue Jan 27 16:24:43 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 27 Jan 2009 17:24:43 -0500 Subject: APNIC offline In-Reply-To: <497F858E.5000807@ieee.org> References: <497F82BD.7090107@comcast.net> <497F858E.5000807@ieee.org> Message-ID: <75cb24520901271424p1bf09e7fo2810da2474250972@mail.gmail.com> http://downforeveryoneorjustme.com/www.apnic.net oy - 'just you, it's up for everone else' -Chris (it's a nice service, we should all use it) On Tue, Jan 27, 2009 at 5:07 PM, Alex H. Ryu wrote: > Website www.apnic.net is not accessable from my desktop, either. > > But it is responded with ping, so it may be the issue with specific > application such as web server daemon? > > Alex > > > manolo wrote: >> All, >> >> Is anyone else seeing www.apnic.net offline? I have tried from two >> locations and the website does not respond. whois is working as >> expected though. >> >> >> >> Manolo >> >> >> > > > From twright at internode.com.au Tue Jan 27 16:24:49 2009 From: twright at internode.com.au (Tom Wright) Date: Wed, 28 Jan 2009 08:54:49 +1030 Subject: APNIC offline In-Reply-To: <497F858E.5000807@ieee.org> References: <497F82BD.7090107@comcast.net> <497F858E.5000807@ieee.org> Message-ID: <6415E241-9509-48D6-ADD6-A63CEF2DF9C8@internode.com.au> Working now from here... (AU) On 28/01/2009, at 8:37 AM, Alex H. Ryu wrote: > Website www.apnic.net is not accessable from my desktop, either. > > But it is responded with ping, so it may be the issue with specific > application such as web server daemon? > > Alex > > > manolo wrote: >> All, >> >> Is anyone else seeing www.apnic.net offline? I have tried from two >> locations and the website does not respond. whois is working as >> expected though. >> >> >> >> Manolo >> >> >> > > Tom From sethm at rollernet.us Tue Jan 27 16:30:54 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 27 Jan 2009 14:30:54 -0800 Subject: out-of-band access bandwidth In-Reply-To: References: Message-ID: <497F8B1E.80901@rollernet.us> Leigh Porter wrote: > And be careful.. It's easy to have simple local passwords, a dial-in modem > and then get pwned.. Were I used to be, we had encrypted modems for POP > dialin. > I have my POTS modem set up to accept PPP too so there's the option of being a little more secure than a plain text terminal, assuming the world didn't completely blow up. ~Seth From deepak at ai.net Tue Jan 27 17:34:59 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 27 Jan 2009 18:34:59 -0500 Subject: -48VDC equipment recommendations Message-ID: <497F9A23.70008@ai.net> Who does everyone like for -48VDC power systems nowadays (say in the 60A @48VDC and 600A at 48VDC sizes). Something like you'd deploy in a POP or a 10-rack MMR with A&B. Management/no-management, not a big deal. Off-list is fine, and I'll be glad to summarize for the list. Thanks in advance, Deepak From Mark_Andrews at isc.org Tue Jan 27 17:36:29 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 28 Jan 2009 10:36:29 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: Your message of "Tue, 27 Jan 2009 11:16:44 -1000." <200901272116.n0RLGiJA002250@ns1.konadogs.net> Message-ID: <200901272336.n0RNaUQ6020960@drugs.dv.isc.org> In message <200901272116.n0RLGiJA002250 at ns1.konadogs.net>, Nate Itkin writes: > On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote: > > < ... snip ... > > > dns queries to the . hint file > > are still occuring and are not being denied by our servers. For example: > > 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view > > external-in: query: . IN NS + > > < ... snip ... > > > since you can't put a "allow-query { none; };" in a hint zone, what can I d > o > > to deny the query to the . zone file? > > > AFAIK, that's about the best you can do with the DNS configuration. You've > mitigated the amplification value, so hopefully the perpetrator(s) will drop > you. If you're willing to keep up with the moving targets, the next level > is an inbound packet filter. Add to your inbound ACL: > > deny udp host 64.57.246.146 neq 53 any eq 53 Which pre-supposes that 64.57.246.146 os not emitting queries of its own. BCP 140 looked at this problem and concluded that sending REFUSED was the best general guidance that can be given. While BCP 140 applies to recursive servers, returning REFUSED to queries which are not within the namespace served by authoritative servers is entirely consistant with BCP 140. > Also on this topic: > Coincident with this DNS DOS, I started seeing inbound PTR queries from > various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers). > They receive no response, yet they persist. Anyone have thoughts on their > part in the scheme? If you don't implement BCP 38 you don't block bogus traffic. Unless you are using 10.0.0.0/8 then you aren't implementing BCP 38 either. If you were you wouldn't be seeing queries from 10.0.0.0/8. Mark > Best wishes, > Nate Itkin > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From sethm at rollernet.us Tue Jan 27 17:38:19 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 27 Jan 2009 15:38:19 -0800 Subject: Contact at Eschelon/Integra to remove old swip Message-ID: <497F9AEB.5070704@rollernet.us> I've been trying unsuccessfully for years to get Eschelon/Integra to remove the swip for an old IP block. Last time I called some months ago I finally talked to someone who said they'd take care of it, but I looked today and it still says it's mine. The range in question is 66.224.163.0/24 and the T1 it was used with was disconnected years ago. If anyone can remove the swip or put me in touch with someone who can I'd appreciate it. ~Seth From rooknee at gmail.com Tue Jan 27 18:02:05 2009 From: rooknee at gmail.com (Randy Rooney) Date: Tue, 27 Jan 2009 16:02:05 -0800 Subject: Contact at Eschelon/Integra to remove old swip In-Reply-To: <497F9AEB.5070704@rollernet.us> References: <497F9AEB.5070704@rollernet.us> Message-ID: <148ea5c60901271602n527549e1hf7aedeb79560594@mail.gmail.com> Replied in private to Seth. Randy Rooney On Tue, Jan 27, 2009 at 3:38 PM, Seth Mattinen wrote: > I've been trying unsuccessfully for years to get Eschelon/Integra to remove > the swip for an old IP block. Last time I called some months ago I finally > talked to someone who said they'd take care of it, but I looked today and it > still says it's mine. The range in question is 66.224.163.0/24 and the T1 it > was used with was disconnected years ago. If anyone can remove the swip or > put me in touch with someone who can I'd appreciate it. > > ~Seth > > From stephens at ameslab.gov Tue Jan 27 18:25:35 2009 From: stephens at ameslab.gov (Douglas C. Stephens) Date: Tue, 27 Jan 2009 18:25:35 -0600 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <200901272116.n0RLGiJA002250@ns1.konadogs.net> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> Message-ID: <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> At 03:16 PM 1/27/2009, Nate Itkin wrote: >On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote: > > < ... snip ... > > > dns queries to the . hint file > > are still occuring and are not being denied by our servers. For example: > > 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view > > external-in: query: . IN NS + > > < ... snip ... > > > since you can't put a "allow-query { none; };" in a hint zone, > what can I do > > to deny the query to the . zone file? > > >AFAIK, that's about the best you can do with the DNS configuration. You've >mitigated the amplification value, so hopefully the perpetrator(s) will drop >you. If you're willing to keep up with the moving targets, the next level >is an inbound packet filter. Add to your inbound ACL: > >deny udp host 64.57.246.146 neq 53 any eq 53 > >Also on this topic: >Coincident with this DNS DOS, I started seeing inbound PTR queries from >various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers). >They receive no response, yet they persist. Anyone have thoughts on their >part in the scheme? > >Best wishes, >Nate Itkin I'm not seeing those PTR queries for 10.0.0.0/8, but then my perimeter ingress/egress filters (BCP 38) toss most of that kind of junk before my DNS servers ever see it. I agree that is as far as one can go with BIND, right now. However, that isn't making the perpetrators cease and desist. I am seeing ongoing query attempts coming in and refusal packets going back out, and the targets don't seem to change until I do something to block them. So mitigating the amplification factor does not seem of interest to these perpetrators. On the contrary, even REFUSED responses can aggregate with some amplified responses to enhance the apparent DoS goal. Thus BCP 140 seems to be less than completely effective because it is less than universally applied (i.e., older versions of BIND or misconfigured BIND.) I think the same situation is true with BCP 38: less than universally applied. So do I wait for universal application of these BCPs, or do I take responsibility for doing what I can to make my network resources less appealing for abuse? I choose the latter, and that is why went to the effort of blocking this abusive traffic before it reaches my authoritative-only DNS servers. Nevertheless, I also agree with a point made last week that trying to keep up with the changing targets is a game of whack-a-mole that is and will continue to be a drain on network management resources -- if the detection and response continues to be deployed manually. This is why I wrote some Perl for my authoritative-only servers to automate detection and response at the server level. Granted it isn't a permanent solution, but at least it is a place to start. I appended that code below for those who are interested in it. Notes ----- * Does not blindly block all queries from an IP address, as would be the case with an ACL. * Assumes BIND 9.4+ configured for authoritative-only role and configured to respond with REFUSE for queries to zones for which it is not authoritative. * Uses BIND 9.4+ syslog messages and a state table as inputs. * Alters IPtables rules and a state table as outputs. * Runs as a periodic cron job (currently every 10 minutes). * Performs a logtail on BIND 9.4+ syslog messages to detect abusive queries matching a pattern. * Implements a minimum detection threshold to reduce the false positive rate (currently 1/minute a.k.a. 10/cycle) * Implements a state table with last-seen timestamps to maintain state between job runs. * Implements an expiry mechanism (currently 24 hours) which is extended each time a source is re-detected. Dependencies ------------ * Linux 2.4+ kernel * BIND 9.4+ * An account sufficiently privileged to read local syslog and modify IPtables rules. * Logtail * Cron */10 * * * * /usr/local/sbin/dns-reflecter-finder * IPtables key rules: iptables -N dns-reflecter iptables -A {INPUT} -p udp --sport ! 53 --dport 53 -j dns-reflecter (place this above your general ALLOW rules for DNS) #!/usr/bin/perl # use strict; use Data::Dumper; my $BASENAME = "/bin/basename"; my $LN = "/bin/ln"; my $LOGTAIL = "/usr/sbin/logtail"; my $IPTABLES = "/sbin/iptables"; my $LOGDIR = "/var/log"; my $RUNDIR = "/var/run"; my $Progname = $0; $Progname = `$BASENAME $Progname`; chomp ($Progname); my $IPtablesChain = "dns-reflecter"; my $RealLogFile = "$LOGDIR/messages"; my $LogFile = "$LOGDIR/$Progname.log"; my $DBfile = "$RUNDIR/$Progname.dat"; my $DetectPeriod = 600; # This should match the cron period my $DetectThold = $DetectPeriod / 60; my $ExpiryPeriod = 60 * 60 * 24; my $Now = time(); my $Debug = 0; if ($#ARGV >= 0 && $ARGV[0] eq "-debug") { $Debug++; } # # Set up the symlink to the real log file. # unless (-l $LogFile) { if ($Debug) { print "$LN -s $RealLogFile $LogFile\n"; } else { system ($LN, "-s", $RealLogFile, $LogFile); } } # # Find all unread log entries that are refused ". IN NS" queries with # source port number != 53; # my %IPaddrsMatched = (); my $ipaddr = ""; my $portnum = ""; if (open (LOGS, "$LOGTAIL $LogFile|")) { while () { chomp; if (/named\[\d+\]: client ([\d\.]+)\#(\d+): .* \'\.\/NS\/IN\' denied$/o) { $ipaddr = $1; $portnum = $2; if ($portnum != 53) { $IPaddrsMatched{$ipaddr}++; } } } close (LOGS); } else { die "Cannot logtail $LogFile: $!\n"; } if ($Debug) { print Dumper (\%IPaddrsMatched), "\n"; } # # Delete IP addresses from the running if they hit with # frequency less than the threshold. In this case 1 every # 60 seconds. # foreach $ipaddr (keys %IPaddrsMatched) { if ($IPaddrsMatched{$ipaddr} < $DetectThold) { delete ($IPaddrsMatched{$ipaddr}); } } # # If our db file exists, read it into a hash. # my %IPaddrsCached = (); my $when = 0; if (-f $DBfile) { if (open (DB, $DBfile)) { while () { chomp; # # Decode the IP address and the Unix epoch timestamp # when it was last found in logs. # ($ipaddr, $when) = split (/\s+/o); # # If the entry has been quiescent for less than the # expire time, retain it. If not, skip it. # if ($Now - $when <= $ExpiryPeriod) { $IPaddrsCached{$ipaddr} = $when; } } close (DB); } else { die "Cannot read from $DBfile: $!\n"; } } if ($Debug) { print Dumper (\%IPaddrsCached), "\n"; } # # Refresh last-seen timestamps for IP addresses detected # during this run, and add new entries for IP addresses # not previously seen (i.e., never before seen, or # previously seen and expired). # foreach $ipaddr (keys %IPaddrsMatched) { $IPaddrsCached{$ipaddr} = $Now; } # # Write out the updated db file. Overwrite if # previously existed. # if (open (DB, ">$DBfile")) { foreach $ipaddr (sort keys %IPaddrsCached) { print DB "$ipaddr\t$IPaddrsCached{$ipaddr}\n"; } close (DB); } else { die "Cannot write to $DBfile: $!\n"; } # # Flush the dedicated IPtables rule chain. # if ($Debug) { print "$IPTABLES -F $IPtablesChain\n"; } else { system ($IPTABLES, "-F", $IPtablesChain); } # # Add to the dedicated IPtables rule chain all the entries # just written to the db as DROP rules. # foreach $ipaddr (sort keys %IPaddrsCached) { if ($Debug) { print "$IPTABLES -A $IPtablesChain -s $ipaddr -j DROP\n"; } else { system ($IPTABLES, "-A", $IPtablesChain, "-s", $ipaddr, "-j", "DROP"); } } exit 0; -- Douglas C. Stephens | UNIX/Windows/Email Admin System Support Specialist | Network/DNS Admin Information Systems | Phone: (515) 294-6102 Ames Laboratory, US DOE | Email: stephens at ameslab.gov From Mark_Andrews at isc.org Tue Jan 27 18:50:55 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 28 Jan 2009 11:50:55 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: Your message of "Tue, 27 Jan 2009 18:25:35 MDT." <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> Message-ID: <200901280050.n0S0otsk022453@drugs.dv.isc.org> In message <6.2.3.4.2.20090127162808.02d4ae50 at imap.ameslab.gov>, "Douglas C. St ephens" writes: > At 03:16 PM 1/27/2009, Nate Itkin wrote: > >On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote: > > > < ... snip ... > > > > dns queries to the . hint file > > > are still occuring and are not being denied by our servers. For example: > > > 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view > > > external-in: query: . IN NS + > > > < ... snip ... > > > > since you can't put a "allow-query { none; };" in a hint zone, > > what can I do > > > to deny the query to the . zone file? > > > > > >AFAIK, that's about the best you can do with the DNS configuration. You've > >mitigated the amplification value, so hopefully the perpetrator(s) will drop > >you. If you're willing to keep up with the moving targets, the next level > >is an inbound packet filter. Add to your inbound ACL: > > > >deny udp host 64.57.246.146 neq 53 any eq 53 > > > >Also on this topic: > >Coincident with this DNS DOS, I started seeing inbound PTR queries from > >various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers). > >They receive no response, yet they persist. Anyone have thoughts on their > >part in the scheme? > > > >Best wishes, > >Nate Itkin > > I'm not seeing those PTR queries for 10.0.0.0/8, but then my perimeter > ingress/egress filters (BCP 38) toss most of that kind of junk before my > DNS servers ever see it. > > I agree that is as far as one can go with BIND, right now. However, that > isn't making the perpetrators cease and desist. I am seeing ongoing query > attempts coming in and refusal packets going back out, and the targets > don't seem to change until I do something to block them. So mitigating > the amplification factor does not seem of interest to these perpetrators. > On the contrary, even REFUSED responses can aggregate with some amplified > responses to enhance the apparent DoS goal. Thus BCP 140 seems to be > less than completely effective because it is less than universally applied > (i.e., older versions of BIND or misconfigured BIND.) I think the same > situation is true with BCP 38: less than universally applied. So do I wait > for universal application of these BCPs, or do I take responsibility for > doing what I can to make my network resources less appealing for abuse? > > I choose the latter, and that is why went to the effort of blocking this > abusive traffic before it reaches my authoritative-only DNS servers. > Nevertheless, I also agree with a point made last week that trying to keep up > with the changing targets is a game of whack-a-mole that is and will continue > to be a drain on network management resources -- if the detection and respons > e > continues to be deployed manually. This is why I wrote some Perl for my > authoritative-only servers to automate detection and response at the server > level. Granted it isn't a permanent solution, but at least it is a place > to start. I appended that code below for those who are interested in it. Which will just make the attacks evolve. It's pretty easy to design a amplifing DNS attack which is almost indetectable unless you know which addresses are being targeted. This one is highly visible in the logs. A much more productive task would be to trace back the offending traffic and to put into place policies which require BCP 38 deployment by those you connect to. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Curtis at GreenKey.net Tue Jan 27 18:52:16 2009 From: Curtis at GreenKey.net (Curtis Doty) Date: Tue, 27 Jan 2009 16:52:16 -0800 (PST) Subject: out-of-band access bandwidth In-Reply-To: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> References: <974e1dfdd9ad4e7a0434a026cf743ee0@umich.edu> Message-ID: <20090128005217.16AC86F064@alopias.GreenKey.net> 1:54pm wingying said: > A quick question, what is the common bandwidth for out-of-band access? > If you administer the metro MPLS for a large city, apparently about "1,100...modems hidden away in locked filing cabinets in public buildings around the city." http://weblog.infoworld.com/venezia/archives/017935.html :-p Couldn't resist. ../C From jmartinez at zero11.com Tue Jan 27 18:58:34 2009 From: jmartinez at zero11.com (John Martinez) Date: Tue, 27 Jan 2009 16:58:34 -0800 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <200901280050.n0S0otsk022453@drugs.dv.isc.org> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> Message-ID: <497FADBA.2050009@zero11.com> Mark Andrews wrote: > In message <6.2.3.4.2.20090127162808.02d4ae50 at imap.ameslab.gov>, "Douglas C. St > ephens" writes: >> At 03:16 PM 1/27/2009, Nate Itkin wrote: >>> On Tue, Jan 27, 2009 at 03:04:19PM -0500, Matthew Huff wrote: >>>> < ... snip ... > >>>> dns queries to the . hint file >>>> are still occuring and are not being denied by our servers. For example: >>>> 27-Jan-2009 15:00:22.963 queries: client 64.57.246.146#64176: view >>>> external-in: query: . IN NS + >>>> < ... snip ... > >>>> since you can't put a "allow-query { none; };" in a hint zone, >>> what can I do >>>> to deny the query to the . zone file? >>> >>> AFAIK, that's about the best you can do with the DNS configuration. You've >>> mitigated the amplification value, so hopefully the perpetrator(s) will drop >>> you. If you're willing to keep up with the moving targets, the next level >>> is an inbound packet filter. Add to your inbound ACL: >>> >>> deny udp host 64.57.246.146 neq 53 any eq 53 >>> >>> Also on this topic: >>> Coincident with this DNS DOS, I started seeing inbound PTR queries from >>> various hosts on 10.0.0.0/8 (which are blackholed by my DNS servers). >>> They receive no response, yet they persist. Anyone have thoughts on their >>> part in the scheme? >>> >>> Best wishes, >>> Nate Itkin >> I'm not seeing those PTR queries for 10.0.0.0/8, but then my perimeter >> ingress/egress filters (BCP 38) toss most of that kind of junk before my >> DNS servers ever see it. >> >> I agree that is as far as one can go with BIND, right now. However, that >> isn't making the perpetrators cease and desist. I am seeing ongoing query >> attempts coming in and refusal packets going back out, and the targets >> don't seem to change until I do something to block them. So mitigating >> the amplification factor does not seem of interest to these perpetrators. >> On the contrary, even REFUSED responses can aggregate with some amplified >> responses to enhance the apparent DoS goal. Thus BCP 140 seems to be >> less than completely effective because it is less than universally applied >> (i.e., older versions of BIND or misconfigured BIND.) I think the same >> situation is true with BCP 38: less than universally applied. So do I wait >> for universal application of these BCPs, or do I take responsibility for >> doing what I can to make my network resources less appealing for abuse? >> >> I choose the latter, and that is why went to the effort of blocking this >> abusive traffic before it reaches my authoritative-only DNS servers. >> Nevertheless, I also agree with a point made last week that trying to keep up >> with the changing targets is a game of whack-a-mole that is and will continue >> to be a drain on network management resources -- if the detection and respons >> e >> continues to be deployed manually. This is why I wrote some Perl for my >> authoritative-only servers to automate detection and response at the server >> level. Granted it isn't a permanent solution, but at least it is a place >> to start. I appended that code below for those who are interested in it. > > Which will just make the attacks evolve. It's pretty easy > to design a amplifing DNS attack which is almost indetectable > unless you know which addresses are being targeted. This > one is highly visible in the logs. > > A much more productive task would be to trace back the > offending traffic and to put into place policies which > require BCP 38 deployment by those you connect to. > > Mark Are we still seeing DNS DDoS attack? From nanog at konadogs.net Tue Jan 27 18:59:40 2009 From: nanog at konadogs.net (Nate Itkin) Date: Tue, 27 Jan 2009 14:59:40 -1000 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <200901272336.n0RNaUQ6020960@drugs.dv.isc.org> Message-ID: <200901280059.n0S0xeeT002804@ns1.konadogs.net> On Wed, Jan 28, 2009 at 10:36:29AM +1100, Mark Andrews wrote: > < ... snip ... > > > deny udp host 64.57.246.146 neq 53 any eq 53 > > Which pre-supposes that 64.57.246.146 os not emitting queries of > its own. > BCP 140 looked at this problem and concluded that sending > REFUSED was the best general guidance that can be given. > While BCP 140 applies to recursive servers, returning REFUSED > to queries which are not within the namespace served by > authoritative servers is entirely consistant with BCP 140. Agree. Thank you for catching that. I should have elaborated that one must be very judicious about adding ACLs for the reasons you mentioned. One of the DOS victims had explicitly said not to expect queries from two of the recent targets, but yeah, not necessarily a good plan in the general case. Best wishes, Nate Itkin From sethm at rollernet.us Tue Jan 27 18:59:57 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 27 Jan 2009 16:59:57 -0800 Subject: Contact at Eschelon/Integra to remove old swip In-Reply-To: <497F9AEB.5070704@rollernet.us> References: <497F9AEB.5070704@rollernet.us> Message-ID: <497FAE0D.4000303@rollernet.us> Problem resolved. Thanks for the help! ~Seth From jay at miscreant.org Tue Jan 27 19:22:46 2009 From: jay at miscreant.org (jay at miscreant.org) Date: Wed, 28 Jan 2009 12:22:46 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <497FADBA.2050009@zero11.com> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> Message-ID: <20090128122246.sziowznu8sswog48@web1.nswh.com.au> Quoting John Martinez : > Are we still seeing DNS DDoS attack? Yep. I'm seeing ~2 queries/sec targetting 64.57.246.146. Also seeing requests from 76.9.16.171 every 1 minute 2 seconds. From orion at pirk.com Tue Jan 27 19:49:05 2009 From: orion at pirk.com (Steve Pirk) Date: Tue, 27 Jan 2009 17:49:05 -0800 (PST) Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <20090128122246.sziowznu8sswog48@web1.nswh.com.au> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> <20090128122246.sziowznu8sswog48@web1.nswh.com.au> Message-ID: On Wed, 28 Jan 2009, jay at miscreant.org wrote: > Quoting John Martinez : > >> Are we still seeing DNS DDoS attack? > > Yep. I'm seeing ~2 queries/sec targetting 64.57.246.146. > > Also seeing requests from 76.9.16.171 every 1 minute 2 seconds. > I run a small personal nameserver and even I am seeing requests for that address 64.57.246.146 at ~1/sec. How many people have upgraded to the latest version of Bind 9? Reason I ask is that when I do my nightly port scan of my server, I no longer see named listening to udp on a random high order port (for replies I believe?). Almost the next day, I started hearing about/seeing these DNS attacks. Previous nmap scan showed: 53/tcp open domain 53/udp open|filtered domain 33591/udp open|filtered unknown Now nmap shows: 53/tcp open domain 53/udp open|filtered domain The listen port (> 32767 I believe) is no longer there with BIND 9.4.3-P1. The port was bound at startup time and did not change as long as named was still running. -- Steve Equal bytes for women. From Mark_Andrews at isc.org Tue Jan 27 21:06:07 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 28 Jan 2009 14:06:07 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: Your message of "Tue, 27 Jan 2009 17:49:05 -0800." Message-ID: <200901280306.n0S367IP030775@drugs.dv.isc.org> In message , Steve Pirk writes : > On Wed, 28 Jan 2009, jay at miscreant.org wrote: > > > Quoting John Martinez : > > > >> Are we still seeing DNS DDoS attack? > > > > Yep. I'm seeing ~2 queries/sec targetting 64.57.246.146. > > > > Also seeing requests from 76.9.16.171 every 1 minute 2 seconds. > > > > I run a small personal nameserver and even I am seeing requests for that > address 64.57.246.146 at ~1/sec. > > How many people have upgraded to the latest version of Bind 9? Reason > I ask is that when I do my nightly port scan of my server, I no longer see > named listening to udp on a random high order port (for replies I believe?). > Almost the next day, I started hearing about/seeing these DNS attacks. Totally unrelated. Named now creates multiple listening ports on demand. Mark > Previous nmap scan showed: > 53/tcp open domain > 53/udp open|filtered domain > 33591/udp open|filtered unknown > > Now nmap shows: > 53/tcp open domain > 53/udp open|filtered domain > > The listen port (> 32767 I believe) is no longer there with BIND 9.4.3-P1. > The port was bound at startup time and did not change as long as named was > still running. > -- > Steve > Equal bytes for women. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From vixie at isc.org Tue Jan 27 21:21:14 2009 From: vixie at isc.org (Paul Vixie) Date: Wed, 28 Jan 2009 03:21:14 +0000 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> (Douglas C. Stephens's message of "Tue\, 27 Jan 2009 18\:25\:35 -0600") References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> Message-ID: "Douglas C. Stephens" writes: > ... > I choose the latter, and that is why went to the effort of blocking this > abusive traffic before it reaches my authoritative-only DNS servers. this is an odd implementation choice. the 1PPS query stream is still using your line even with this defense in place. the 1PPS response stream and the CPU cycles it takes to generate that stream isn't a burden on you (compared to the 1PPS query stream that you can't stop anyway). so the only reason to block these appears to be so that you don't participate in the attack, or in other words to cut down the burden on the victim. with me so far? the burden on the victim isn't going to drop materially by what you did since hundreds of thousands of other servers are not going to block it. but if the victim is a recursive nameserver, then your blocking them will mean that they cannot access the zones you're authoritative for. so, no positive, but some negative, for the only person in the whole equation who can be affected by the blocking you're doing. i don't get it. with a cost:benefit matrix like that one, why is anybody blocking this traffic? (i note with some alarm that ten years after i shot it down, i still get queries to rbl.maps.vix.com, so the possibility that the blocks some folks might put in place to ...manage?... this attack will have a long term bad effect on our heirs and assigns. i know your perl script will expire things 60 seconds after they stop spewing, but i fear that others are blocking these in hardcode. (looking for ". IN NS" as the q-tuple pattern is not a solution, since the bad guys can pretty trivially change the question they ask into one you're willing to answer.) (REFUSED is nice because it's small, but the bad guys aren't lacking for bots to transmit spoofed packets from, they Do Not Need amplification, and all forms of error rate limiting are also new attack vectors.) (is there a name-and-shame registry for networks that do/don't implement BCP38? if not i guess i'll start one and hope that various auditors will use google and notice me.) -- Paul Vixie From David.Zielezna at acma.gov.au Tue Jan 27 21:32:30 2009 From: David.Zielezna at acma.gov.au (David Zielezna) Date: Wed, 28 Jan 2009 14:32:30 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED] In-Reply-To: <497FADBA.2050009@zero11.com> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> Message-ID: <2ADA77D9DC5188469280D991E524971201568856@VIC01EXC01.internal.govt> I still see a few new ones each day, here is my current bind acl for blocking them: acl blacknet { 69.50.142.11/32; 66.230.160.1/32; 66.230.128.15/32; 76.9.16.171/32; 63.217.28.226/32; 206.71.158.30/32; 64.57.246.146/32; 67.192.144.0/32; }; These have all been seen in the last few days, verified by hand. DZ -----Original Message----- From: John Martinez [mailto:jmartinez at zero11.com] Sent: Wednesday, 28 January 2009 11:59 AM Cc: nanog at nanog.org Subject: Re: Tightened DNS security question re: DNS amplification attacks. Are we still seeing DNS DDoS attack? If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. From dga at cs.cmu.edu Tue Jan 27 21:46:35 2009 From: dga at cs.cmu.edu (David Andersen) Date: Tue, 27 Jan 2009 22:46:35 -0500 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> Message-ID: <7EA9625D-2678-496E-BD7E-76F02E40C6E4@cs.cmu.edu> On Jan 27, 2009, at 10:21 PM, Paul Vixie wrote: >> > (looking for ". IN NS" as the q-tuple pattern is not a solution, > since the > bad guys can pretty trivially change the question they ask into one > you're > willing to answer.) Actually, ". IN NS" is a particularly useful thing for them to do, because it's an almost globally guaranteed response that will get a large response and be in cache. One can get similar effects with ". IN NS", of course, but the set of things that work well for such an attack are relatively limited. One thing that's fairly straightforward with the current attack is to block 00600 deny udp from 66.230.160.1 to me 53 iplen 45 (foreach victim host) (If you tcpdump the traffic, because of the . IN NS, the packets are all the same length - 45 IP bytes.) Very easy to filter at the current time with almost no collateral damage. I realize this is just a cat-and-mouse game, but forcing the attacker to use larger query packets that have smaller cached replies isn't a bad thing. ". NS" -> 45 byte query, 245 byte response "COM. NS" -> 48 byte query, 245 byte response "NET. NS" -> 242 byte response, "ORG. NS" -> 159 byte response, This masking is mostly effective for people whose nameservers are set to deny recursive but are still serving from cache. YMMV. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From David.Zielezna at acma.gov.au Tue Jan 27 21:59:29 2009 From: David.Zielezna at acma.gov.au (David Zielezna) Date: Wed, 28 Jan 2009 14:59:29 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED] In-Reply-To: <497FD54B.9010601@ibctech.ca> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> <2ADA77D9DC5188469280D991E524971201568856@VIC01EXC01.internal.govt> <497FD54B.9010601@ibctech.ca> Message-ID: <2ADA77D9DC5188469280D991E524971201568857@VIC01EXC01.internal.govt> I'm checking just with a mix of tcpdump/pcap, bind logs and p0f. A bit overboard, but logging is fun. I haven't checked any dark hosts to see whether the attack repeatedly sends queries to IPs which have never given an answer or indication of any kind of life. Your monitoring will probably determine this so let us know what behavior you find. DZ -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Wednesday, 28 January 2009 2:47 PM To: David Zielezna Cc: John Martinez; nanog at nanog.org Subject: Re: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED] Good work! How are you checking for this by hand? Would it be safe to assume that running tcpdump on a box in the following manner on a monitor port for a sizable portion of the network be ok (as opposed to the DNS servers themselves, as I don't have control over them all)? sniffer# tcpdump -n -i em5 dst port 53 | grep "NS? . (17)" 22:38:31.150114 IP 64.57.246.146.43581 > 208.70.106.58.53: 23685+ NS? . (17) We have a mix of DNS servers, some BIND and some DJBDNS, a BIND ACL won't work here. We also have single-homed clients that run accessible DNS servers that appear to be Windows based. ACL's outside of the BIND scope would be fantastic. For now, I'm following the above list, and blocking everything ingress that is not source port 53 from the IP to my network 53. Steve If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. From cmadams at hiwaay.net Tue Jan 27 22:19:40 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 27 Jan 2009 22:19:40 -0600 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <7EA9625D-2678-496E-BD7E-76F02E40C6E4@cs.cmu.edu> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <7EA9625D-2678-496E-BD7E-76F02E40C6E4@cs.cmu.edu> Message-ID: <20090128041940.GA1363625@hiwaay.net> Once upon a time, David Andersen said: > Actually, ". IN NS" is a particularly useful thing for them to do, > because it's an almost globally guaranteed response that will get a > large response and be in cache. That's only true on servers that aren't well-configured. > ". IN NS", of course, but the set of things that work well for > such an attack are relatively limited. Try "aol.com. MX", "hotmail.com. MX", any domain with a big SPF TXT record, etc. There's nothing really special about ". NS". If somebody is serving cached data to the world (even if they aren't recursing for the world), there are any number of things that are likely in the cache. And, since most people have SMTP servers, it is often easy to "prime" somebody's cache, since the SMTP servers often use the same DNS servers. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fredan-nanog at fredan.se Wed Jan 28 06:16:01 2009 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Wed, 28 Jan 2009 13:16:01 +0100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <2ADA77D9DC5188469280D991E524971201568856@VIC01EXC01.internal.govt> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> <2ADA77D9DC5188469280D991E524971201568856@VIC01EXC01.internal.govt> Message-ID: <200901281316.01925.fredan-nanog@fredan.se> At 12:07:16 local time here in sweden, I saw a new address 70.86.80.98. At 12:09:36 another new address 64.57.246.123 At 12:20:10 the address 70.86.80.98 started to ask for funny domain name like: "pjphcdaaaafwu0000dgaaabaaacboinf". This ended at 12:55:01 when it was back to just ask for the .NS records again. -- //Fredrik Danerklint //Fredan From cmorris at cs.odu.edu Wed Jan 28 08:31:56 2009 From: cmorris at cs.odu.edu (Charles Morris) Date: Wed, 28 Jan 2009 09:31:56 -0500 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <200901281316.01925.fredan-nanog@fredan.se> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> <2ADA77D9DC5188469280D991E524971201568856@VIC01EXC01.internal.govt> <200901281316.01925.fredan-nanog@fredan.se> Message-ID: <6171c6010901280631g571e7ca8xff7bf21a9255f72e@mail.gmail.com> You all may wish to check your logs for 202.108.12.112, it could be a new target; although I only saw two requests from it. -- Charles Morris cmorris at cs.odu.edu, cmorris at occs.odu.edu Network Security Administrator, Software Developer Office of Computing and Communications Services, CS Systems Group Old Dominion University http://www.cs.odu.edu/~cmorris From graeme at graemef.net Wed Jan 28 08:32:11 2009 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 28 Jan 2009 14:32:11 +0000 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <200901281316.01925.fredan-nanog@fredan.se> References: <200901280050.n0S0otsk022453@drugs.dv.isc.org> <497FADBA.2050009@zero11.com> <2ADA77D9DC5188469280D991E524971201568856@VIC01EXC01.internal.govt> <200901281316.01925.fredan-nanog@fredan.se> Message-ID: <1233153132.10688.13.camel@squonk.lboro.ac.uk> Hi On Wed, 2009-01-28 at 13:16 +0100, fredrik danerklint wrote: > At 12:07:16 local time here in sweden, I saw a new address 70.86.80.98. > At 12:09:36 another new address 64.57.246.123 > At 12:20:10 the address 70.86.80.98 started to ask for funny domain name like: > "pjphcdaaaafwu0000dgaaabaaacboinf". This ended at 12:55:01 when it was back to > just ask for the .NS records again. Same here - times different, though, in that it appeared at 1120 UTC and disappeared at 1159 UTC. There were 194 entries. Every query was the same format - a 32-byte lower case alphanumeric string, differing at the following positions marked with a period: ......aaaafw.0000d.aaabaaa...... I expect that others will have seen similar patterns with differing fixed strings. I'm also starting to wonder if this is something to with the downadup/conficker worm, or another botnet. Graeme From frnkblk at iname.com Wed Jan 28 09:02:55 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 28 Jan 2009 09:02:55 -0600 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> Message-ID: Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) -----Original Message----- From: Paul Vixie [mailto:vixie at isc.org] Sent: Tuesday, January 27, 2009 9:21 PM To: nanog at merit.edu Subject: Re: Tightened DNS security question re: DNS amplification attacks. "Douglas C. Stephens" writes: > ... > I choose the latter, and that is why went to the effort of blocking this > abusive traffic before it reaches my authoritative-only DNS servers. this is an odd implementation choice. the 1PPS query stream is still using your line even with this defense in place. the 1PPS response stream and the CPU cycles it takes to generate that stream isn't a burden on you (compared to the 1PPS query stream that you can't stop anyway). so the only reason to block these appears to be so that you don't participate in the attack, or in other words to cut down the burden on the victim. with me so far? the burden on the victim isn't going to drop materially by what you did since hundreds of thousands of other servers are not going to block it. but if the victim is a recursive nameserver, then your blocking them will mean that they cannot access the zones you're authoritative for. so, no positive, but some negative, for the only person in the whole equation who can be affected by the blocking you're doing. i don't get it. with a cost:benefit matrix like that one, why is anybody blocking this traffic? (i note with some alarm that ten years after i shot it down, i still get queries to rbl.maps.vix.com, so the possibility that the blocks some folks might put in place to ...manage?... this attack will have a long term bad effect on our heirs and assigns. i know your perl script will expire things 60 seconds after they stop spewing, but i fear that others are blocking these in hardcode. (looking for ". IN NS" as the q-tuple pattern is not a solution, since the bad guys can pretty trivially change the question they ask into one you're willing to answer.) (REFUSED is nice because it's small, but the bad guys aren't lacking for bots to transmit spoofed packets from, they Do Not Need amplification, and all forms of error rate limiting are also new attack vectors.) (is there a name-and-shame registry for networks that do/don't implement BCP38? if not i guess i'll start one and hope that various auditors will use google and notice me.) -- Paul Vixie From info at linuxmount.com Wed Jan 28 09:18:29 2009 From: info at linuxmount.com (aljuhani) Date: Wed, 28 Jan 2009 18:18:29 +0300 Subject: Tightened DNS security question re: DNS amplification attacks. Message-ID: <20090128151826.38145A5B28C@riy-m18.saudi.net.sa> Well the RBLs, in using dns queries, is another form of legal DDoS attacks, mainly when the suddenly cease to respond or re-configure to black-list the entire wold. One should just imagine the bandwidth consumption during a given time-frame, RBLs consume as oppose to volume of spam messages. ----- Original Message ----- From: "Frank Bulk" To: "'Paul Vixie'" ; Sent: Wednesday, January 28, 2009 18:02 Subject: RE: Tightened DNS security question re: DNS amplification attacks. | Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) | | -----Original Message----- | From: Paul Vixie [mailto:vixie at isc.org] | Sent: Tuesday, January 27, 2009 9:21 PM | To: nanog at merit.edu | Subject: Re: Tightened DNS security question re: DNS amplification attacks. | | "Douglas C. Stephens" writes: | | > ... | > I choose the latter, and that is why went to the effort of blocking this | > abusive traffic before it reaches my authoritative-only DNS servers. | | this is an odd implementation choice. the 1PPS query stream is still using | your line even with this defense in place. the 1PPS response stream and the | CPU cycles it takes to generate that stream isn't a burden on you (compared | to the 1PPS query stream that you can't stop anyway). so the only reason to | block these appears to be so that you don't participate in the attack, or in | other words to cut down the burden on the victim. with me so far? | | the burden on the victim isn't going to drop materially by what you did | since | hundreds of thousands of other servers are not going to block it. but if | the | victim is a recursive nameserver, then your blocking them will mean that | they | cannot access the zones you're authoritative for. so, no positive, but some | negative, for the only person in the whole equation who can be affected by | the blocking you're doing. | | i don't get it. with a cost:benefit matrix like that one, why is anybody | blocking this traffic? (i note with some alarm that ten years after i shot | it down, i still get queries to rbl.maps.vix.com, so the possibility that | the | blocks some folks might put in place to ...manage?... this attack will have | a | long term bad effect on our heirs and assigns. i know your perl script will | expire things 60 seconds after they stop spewing, but i fear that others are | blocking these in hardcode. | | (looking for ". IN NS" as the q-tuple pattern is not a solution, since the | bad guys can pretty trivially change the question they ask into one you're | willing to answer.) | | (REFUSED is nice because it's small, but the bad guys aren't lacking for | bots | to transmit spoofed packets from, they Do Not Need amplification, and all | forms of error rate limiting are also new attack vectors.) | | (is there a name-and-shame registry for networks that do/don't implement | BCP38? if not i guess i'll start one and hope that various auditors will use | google and notice me.) | -- | Paul Vixie | | | | From ops.lists at gmail.com Wed Jan 28 09:29:44 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Jan 2009 20:59:44 +0530 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <20090128151826.38145A5B28C@riy-m18.saudi.net.sa> References: <20090128151826.38145A5B28C@riy-m18.saudi.net.sa> Message-ID: This, in a thread where paul vixie is posting .. and on a list where there are several people who do run professional blocklists. Well, I dare say there'll be some difference of opinion. Cant help that. On Wed, Jan 28, 2009 at 8:48 PM, aljuhani wrote: > > Well the RBLs, in using dns queries, is another form of legal DDoS attacks, mainly when the suddenly cease to respond or re-configure to black-list the entire wold. One should just imagine the bandwidth consumption during a given time-frame, RBLs consume as oppose to volume of spam messages. > From andrew.fried at gmail.com Wed Jan 28 10:07:20 2009 From: andrew.fried at gmail.com (Andrew Fried) Date: Wed, 28 Jan 2009 11:07:20 -0500 Subject: DNS DDoS Message-ID: <498082B8.6020103@gmail.com> Targeted victims, beginning 28-Jan-2009, as seen from my DNS server. GeoIP data for top two sites also below: +----------------+-------------+------------+ | host | count(host) | Percentage | +----------------+-------------+------------+ | 202.104.106.49 | 51 | 0.1109 | | 210.21.218.138 | 51 | 0.1109 | | 64.57.246.123 | 3561 | 7.7421 | | 64.57.246.146 | 29530 | 64.2026 | | 67.192.144.0 | 991 | 2.1546 | | 70.86.80.98 | 11276 | 24.5157 | | 76.9.16.171 | 535 | 1.1632 | +----------------+-------------+------------+ GeoIP Location Information for IP: 64.57.246.146 Located in: Suwanee, GA (US) Latitude: 34.0535 Longitude: -84.0659 Area Code: 770 Postal Code: 30024 ARIN information for: 64.57.246.146 DNS PTR Record: Registrar: arin ASN Number: AS20141 Country: US Ip Starting Block: 64.57.240.0 IP Ending Block: 64.57.255.255 IP Block Size: 4096 Date Registered: 20051012 Block Status: allocated BGP Peering Information for ASN20141: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 6983 | 64.57.246.146 | 64.57.240.0/20 | US | arin | 2005-10-12 | ITCDELTA - ITC^Deltacom 14745 | 64.57.246.146 | 64.57.240.0/20 | US | arin | 2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation GeoIP Location Information for IP: 70.86.80.98 Located in: Houston, TX (US) Latitude: 29.7523 Longitude: -95.3670 Area Code: 713 Postal Code: 77002 ARIN information for: 70.86.80.98 DNS PTR Record: 62.50.5646.static.theplanet.com. Registrar: arin ASN Number: AS21844 Country: US Ip Starting Block: 70.84.0.0 IP Ending Block: 70.87.255.255 IP Block Size: 262144 Date Registered: 20040729 Block Status: allocated BGP Peering Information for ASN21844: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 2914 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc. 3356 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | LEVEL3 Level 3 Communications 3549 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | GBLX Global Crossing Ltd. 4565 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc. 6461 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | MFNX MFN - Metromedia Fiber Network -- Andrew Fried andrew.fried at gmail.com From tony at lava.net Wed Jan 28 10:45:34 2009 From: tony at lava.net (Antonio Querubin) Date: Wed, 28 Jan 2009 06:45:34 -1000 (HST) Subject: google logo Message-ID: Anyone else noticing Google's logo has been scrambled? Antonio Querubin whois: AQ7-ARIN From mjkits at rit.edu Wed Jan 28 10:47:23 2009 From: mjkits at rit.edu (Mark Kimble) Date: Wed, 28 Jan 2009 11:47:23 -0500 Subject: google logo In-Reply-To: References: Message-ID: <6F61718F1AB1BC4486D7CA3429B3EDA334D8DF@svits26.main.ad.rit.edu> Jackson Pollock's Birthday - http://en.wikipedia.org/wiki/Jackson_Pollock -----Original Message----- From: Antonio Querubin [mailto:tony at lava.net] Sent: Wednesday, January 28, 2009 11:46 AM To: nanog at merit.edu Subject: google logo Anyone else noticing Google's logo has been scrambled? Antonio Querubin whois: AQ7-ARIN From tan7f at virginia.edu Wed Jan 28 10:47:45 2009 From: tan7f at virginia.edu (Tim Nowaczyk) Date: Wed, 28 Jan 2009 11:47:45 -0500 Subject: google logo In-Reply-To: Message-ID: On 1/28/09 11:45 AM, "Antonio Querubin" wrote: > Anyone else noticing Google's logo has been scrambled? > It was done in honor of Jackson Pollock's birthday. Cheers, Tim Nowaczyk -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f at virginia.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4531 bytes Desc: not available URL: From sbryant at thepit.org Wed Jan 28 10:47:57 2009 From: sbryant at thepit.org (Shaun Bryant) Date: Wed, 28 Jan 2009 08:47:57 -0800 Subject: google logo In-Reply-To: References: Message-ID: It is Jackson Pollock's birthday http://en.wikipedia.org/wiki/Jackson_Pollock Shaun On Wed, Jan 28, 2009 at 8:45 AM, Antonio Querubin wrote: > Anyone else noticing Google's logo has been scrambled? > > Antonio Querubin > whois: AQ7-ARIN > > From Jay.Murphy at state.nm.us Wed Jan 28 10:48:12 2009 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Wed, 28 Jan 2009 09:48:12 -0700 Subject: google logo In-Reply-To: References: Message-ID: Yea, it is Jackson Pollack's B-day art... Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Antonio Querubin [mailto:tony at lava.net] Sent: Wednesday, January 28, 2009 9:46 AM To: nanog at merit.edu Subject: google logo Anyone else noticing Google's logo has been scrambled? Antonio Querubin whois: AQ7-ARIN ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From tme at multicasttech.com Wed Jan 28 10:48:19 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 28 Jan 2009 11:48:19 -0500 Subject: google logo In-Reply-To: References: Message-ID: That's a Jackson Pollock. Marshall On Jan 28, 2009, at 11:45 AM, Antonio Querubin wrote: > Anyone else noticing Google's logo has been scrambled? > > Antonio Querubin > whois: AQ7-ARIN > From cgrundemann at gmail.com Wed Jan 28 10:49:06 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 28 Jan 2009 09:49:06 -0700 Subject: google logo In-Reply-To: References: Message-ID: <443de7ad0901280849h207dca6j45d1dae355fb00f7@mail.gmail.com> On Wed, Jan 28, 2009 at 09:45, Antonio Querubin wrote: > Anyone else noticing Google's logo has been scrambled? If you click on it you will see that it is a Jackson Pollack inspired image, most likely a tribute to his birthday today. ~Chris > > Antonio Querubin > whois: AQ7-ARIN > > -- Chris Grundemann www.chrisgrundemann.com From admin at racksecurity.net Wed Jan 28 10:52:39 2009 From: admin at racksecurity.net (Zach) Date: Wed, 28 Jan 2009 10:52:39 -0600 Subject: google logo In-Reply-To: References: Message-ID: <3918cf170901280852g6ee30032xa7248627d32dbba3@mail.gmail.com> That's one hell of a captcha.. On Wed, Jan 28, 2009 at 10:47 AM, Tim Nowaczyk wrote: > > > On 1/28/09 11:45 AM, "Antonio Querubin" wrote: > > > Anyone else noticing Google's logo has been scrambled? > > > It was done in honor of Jackson Pollock's birthday. > > Cheers, > Tim Nowaczyk > > -- > Timothy Nowaczyk > Network Systems Engineer > University of Virginia - ITC > tan7f at virginia.edu > > From pafriend at octavian.org Wed Jan 28 10:53:03 2009 From: pafriend at octavian.org (Peter A. Friend) Date: Wed, 28 Jan 2009 08:53:03 -0800 Subject: google logo In-Reply-To: References: Message-ID: <60CE58FC-702B-4F3B-A1E1-7CDBBA0F7381@octavian.org> On Jan 28, 2009, at 8:45 AM, Antonio Querubin wrote: > Anyone else noticing Google's logo has been scrambled? > > Antonio Querubin > whois: AQ7-ARIN > Look closely. It's Jackson Pollock's birthday. From Stephen.Bailey at uk.fujitsu.com Wed Jan 28 10:58:07 2009 From: Stephen.Bailey at uk.fujitsu.com (Bailey Stephen) Date: Wed, 28 Jan 2009 16:58:07 -0000 Subject: google logo In-Reply-To: References: Message-ID: That will be because of Jackon Pollock's Birthday http://www.jacksonpollock.org/ Stephen Bailey - Senior Lead Systems Engineer Network Operations - ISP & DSL FUJITSU + Infinity House, Mallard Way, Crewe Business Park, Crewe, Cheshire, CW1 6ZQ ( Tel: +44 (0) 870 325 3457 or Internally: 7225 3457 ( Fax: +44 (0) 870 325 3622 or Internally: 7225 3622 : E-mail: stephen.bailey at uk.fujitsu.com " Web: http://services.fujitsu.com/ Fujitsu Services Limited, Registered in England no 96056, Registered Office 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. _____________________________________________ From: Tim Nowaczyk [mailto:tan7f at virginia.edu] Sent: 28 January 2009 16:48 To: Antonio Querubin; nanog at merit.edu Subject: Re: google logo * PGP Bad Signature, Signed by an unverified key: 01/28/09 at 16:47:45 On 1/28/09 11:45 AM, "Antonio Querubin" wrote: > Anyone else noticing Google's logo has been scrambled? > It was done in honor of Jackson Pollock's birthday. Cheers, Tim Nowaczyk -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f at virginia.edu * Timothy Allen Nowaczyk 70 * Issuer: University of Virginia - Unverified From sil at infiltrated.net Wed Jan 28 11:08:57 2009 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 28 Jan 2009 11:08:57 -0600 Subject: google logo In-Reply-To: References: Message-ID: <20090128170857.GB76143@infiltrated.net> On Wed, 28 Jan 2009, Dozens of Overpaid Engineers wrote: > That's a Jackson Pollock. > Question should be - How does this affect route patterns, traffic, policies, etc.? =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From tony at lava.net Wed Jan 28 11:38:54 2009 From: tony at lava.net (Antonio Querubin) Date: Wed, 28 Jan 2009 07:38:54 -1000 (HST) Subject: google logo In-Reply-To: <60CE58FC-702B-4F3B-A1E1-7CDBBA0F7381@octavian.org> References: <60CE58FC-702B-4F3B-A1E1-7CDBBA0F7381@octavian.org> Message-ID: On Wed, 28 Jan 2009, Peter A. Friend wrote: > Look closely. It's Jackson Pollock's birthday. Heh. My first thought was the site might have been hacked. The logo looks cool though. Thanks for the reply :) Antonio Querubin whois: AQ7-ARIN From leigh.porter at ukbroadband.com Wed Jan 28 11:48:35 2009 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 28 Jan 2009 17:48:35 +0000 Subject: google logo In-Reply-To: References: <60CE58FC-702B-4F3B-A1E1-7CDBBA0F7381@octavian.org> Message-ID: <49809A73.8000007@ukbroadband.com> "the site" is an interesting phrase to use with Google. What is the google site anyway? Does it exist in any one place in space-time? -- Leigh Antonio Querubin wrote: > On Wed, 28 Jan 2009, Peter A. Friend wrote: > >> Look closely. It's Jackson Pollock's birthday. > > Heh. My first thought was the site might have been hacked. The logo > looks cool though. Thanks for the reply :) > > Antonio Querubin > whois: AQ7-ARIN From ops.lists at gmail.com Wed Jan 28 12:05:26 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 28 Jan 2009 23:35:26 +0530 Subject: google logo In-Reply-To: <20090128170857.GB76143@infiltrated.net> References: <20090128170857.GB76143@infiltrated.net> Message-ID: On Wed, Jan 28, 2009 at 10:38 PM, J. Oquendo wrote: > On Wed, 28 Jan 2009, Dozens of Overpaid Engineers wrote: > >> That's a Jackson Pollock. >> > > Question should be - How does this affect route patterns, > traffic, policies, etc.? Suspected global case of bitrot leading to the logo being scrambled, maybe? :) From michael.holstein at csuohio.edu Wed Jan 28 13:12:16 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 28 Jan 2009 14:12:16 -0500 Subject: google logo In-Reply-To: References: Message-ID: <4980AE10.5010302@csuohio.edu> > Anyone else noticing Google's logo has been scrambled? Did you notice what happens when you mouse-over it (same thing that happens anytime they do a "doodle", btw). http://www.google.com/search?q=Jackson+Pollock&hl=en&ct=pollock09&oi=ddle http://en.wikipedia.org/wiki/Google_logo From vixie at isc.org Wed Jan 28 13:30:05 2009 From: vixie at isc.org (Paul Vixie) Date: Wed, 28 Jan 2009 19:30:05 +0000 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: Your message of "Wed, 28 Jan 2009 09:02:55 CST." References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> Message-ID: <41649.1233171005@nsa.vix.com> > Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) in the classic sense, you're wrong. in a neoclassic sense: "maybe". let me explain. the original RBL was designed to reject TCP/25 (SMTP) transactions based on source address reputation. we had a false start where we blackholed these addresses as destinations, figuring that if they couldn't hear our ACK then we would never get into TCP with them. then we decided to reject inside the SMTP server and that's what the world has settled on. but throughout, we have been able to bind a reputation to an IP address and act in some way based on that reputation because TCP more or less requires that a real IP address be used. we're seeing cracks at the edges of this model now, because so many core routers have login: cisco; password: cisco, and it's now trivial for any spammer to inject BGP that either lights up unallocated space or cuts out a piece of somebody else's allocated block. this makes it possible to very temporarily and untraceably speak TCP from addresses that have no reputation (if they're unallocated) or that have a good reputation (if they're cutouts). DNS-oriented attacks are of a completely different kind. today's attacks were precisely described in (which wasn't news in october 2002 but somebody had to write it down so i did). the important statement out of that 4-page document is: "Source addresses that appear at Border or Interior connections are nonrepudiable by nature..." and that statement bears on the question of RBL for DNS-oriented DDoS attacks since the address we'd have to assign a reputation to is the victim, so all we can do is make an attack worse (by denying service to the victim's real traffic.) i've pondered whether a network reputation service based on morality rather than behaviour could possibly work. in other words an RBL-like entity that did not prevent attacks, but rather, which denied service to collaborators. if someone claims they can't deploy BCP38 and if their network or nameserver is then used as a launch point for spoofed packets toward reflectors and amplifiers, then would anyone be willing to deny service to them -- to paint them as having a negative reputation even though their "sin" is laziness or cluelessness rather than malevolent intent? and if someone claims they can't turn off open recursion and they get used as an amplifier, would anyone here be willing to deny that recursive server access to their authority server, not on the basis that it might attack them, but strictly to pressure an upgrade? note, i'm speaking as a concerned internet citizen here, not as an ARIN trustee or as ISC's president. i really want to know if folks would be willing to shun eachother not on the basis of evil but rather complacency. From wschultz at bsdboy.com Wed Jan 28 13:49:51 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 28 Jan 2009 11:49:51 -0800 Subject: DNS DDoS In-Reply-To: <498082B8.6020103@gmail.com> References: <498082B8.6020103@gmail.com> Message-ID: <5D820294-0273-4651-B319-85C25E570E70@bsdboy.com> If anyone is interested, here's what things look like from here for the past 3 days. dns2:~ wschultz$ gzcat /var/log/named.log.01262009.gz |awk '/\.\/NS\/ IN.*denied/{print $6}' |sed -e 's/#.*//g' |sort |uniq -c |sort -n 6 150.69.136.10 1387 76.9.16.171 2759 63.217.28.226 98680 206.71.158.30 dns2:~ wschultz$ gzcat /var/log/named.log.01272009.gz |awk '/\.\/NS\/ IN.*denied/{print $6}' |sed -e 's/#.*//g' |sort |uniq -c |sort -n 6 150.69.136.10 1387 76.9.16.171 2753 63.217.28.226 5521 206.71.158.30 dns2:~ wschultz$ cat /var/log/named.log |awk '/\.\/NS\/IN.*denied/ {print $6}' |sed -e 's/#.*//g' |sort |uniq -c |sort -n 2 150.69.136.10 279 67.192.144.0 296 76.9.16.171 6519 64.57.246.123 17207 64.57.246.146 20646 70.86.80.98 -wil On Jan 28, 2009, at 8:07 AM, Andrew Fried wrote: > Targeted victims, beginning 28-Jan-2009, as seen from my DNS server. > GeoIP data for top two sites also below: > > +----------------+-------------+------------+ > | host | count(host) | Percentage | > +----------------+-------------+------------+ > | 202.104.106.49 | 51 | 0.1109 | > | 210.21.218.138 | 51 | 0.1109 | > | 64.57.246.123 | 3561 | 7.7421 | > | 64.57.246.146 | 29530 | 64.2026 | > | 67.192.144.0 | 991 | 2.1546 | > | 70.86.80.98 | 11276 | 24.5157 | > | 76.9.16.171 | 535 | 1.1632 | > +----------------+-------------+------------+ > > GeoIP Location Information for IP: 64.57.246.146 > Located in: Suwanee, GA (US) > Latitude: 34.0535 > Longitude: -84.0659 > Area Code: 770 > Postal Code: 30024 > > ARIN information for: 64.57.246.146 > DNS PTR Record: > Registrar: arin > ASN Number: AS20141 > Country: US > Ip Starting Block: 64.57.240.0 > IP Ending Block: 64.57.255.255 > IP Block Size: 4096 > Date Registered: 20051012 > Block Status: allocated > > BGP Peering Information for ASN20141: > > PEER_AS | IP | BGP Prefix | CC | Registry | > Allocated | AS Name > 6983 | 64.57.246.146 | 64.57.240.0/20 | US | arin | > 2005-10-12 | ITCDELTA - ITC^Deltacom > 14745 | 64.57.246.146 | 64.57.240.0/20 | US | arin | > 2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation > > > > > GeoIP Location Information for IP: 70.86.80.98 > Located in: Houston, TX (US) > Latitude: 29.7523 > Longitude: -95.3670 > Area Code: 713 > Postal Code: 77002 > > ARIN information for: 70.86.80.98 > DNS PTR Record: 62.50.5646.static.theplanet.com. > Registrar: arin > ASN Number: AS21844 > Country: US > Ip Starting Block: 70.84.0.0 > IP Ending Block: 70.87.255.255 > IP Block Size: 262144 > Date Registered: 20040729 > Block Status: allocated > > BGP Peering Information for ASN21844: > > PEER_AS | IP | BGP Prefix | CC | Registry | > Allocated | AS Name > 2914 | 70.86.80.98 | 70.84.0.0/14 | US | arin | > 2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc. > 3356 | 70.86.80.98 | 70.84.0.0/14 | US | arin | > 2004-07-29 | LEVEL3 Level 3 Communications > 3549 | 70.86.80.98 | 70.84.0.0/14 | US | arin | > 2004-07-29 | GBLX Global Crossing Ltd. > 4565 | 70.86.80.98 | 70.84.0.0/14 | US | arin | > 2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc. > 6461 | 70.86.80.98 | 70.84.0.0/14 | US | arin | > 2004-07-29 | MFNX MFN - Metromedia Fiber Network > > -- > Andrew Fried > andrew.fried at gmail.com > > From jbates at brightok.net Wed Jan 28 13:52:12 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 28 Jan 2009 13:52:12 -0600 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <41649.1233171005@nsa.vix.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> Message-ID: <4980B76C.6020401@brightok.net> Paul Vixie wrote: > > note, i'm speaking as a concerned internet citizen here, not as an ARIN > trustee or as ISC's president. i really want to know if folks would be > willing to shun eachother not on the basis of evil but rather complacency. > The real question is, would the endpoints be willing to shun each other not based on the other endpoint, but complacency of the endpoint's provider. I believe such traffic changes would quickly find themselves to "net-neutrality" lawsuits. From things I've seen in the past, it is appropriate to say "my server, my rules" but not appropriate to say "my network, my rules". ie, if I wanted to shape/block/alter p2p, block vontage, etc. Jack From jmartinez at zero11.com Wed Jan 28 14:27:15 2009 From: jmartinez at zero11.com (John Martinez) Date: Wed, 28 Jan 2009 12:27:15 -0800 Subject: cogent issues? In-Reply-To: <4980B76C.6020401@brightok.net> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net> Message-ID: <4980BFA3.5010703@zero11.com> http://www.internetpulse.net/ From brandon.galbraith at gmail.com Wed Jan 28 14:29:18 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 28 Jan 2009 14:29:18 -0600 Subject: cogent issues? In-Reply-To: <4980BFA3.5010703@zero11.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net> <4980BFA3.5010703@zero11.com> Message-ID: <366100670901281229x78615e3ep7e1784ee5fe46cb0@mail.gmail.com> On 1/28/09, John Martinez wrote: > > http://www.internetpulse.net/ > > Sent to "outages" a bit ago: Cogent is currently experiencing problems on their backbone in Chicago, manifesting as packet loss and latency. The master ticket # is 853582. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From Ray.Sanders at VillageVoiceMedia.com Wed Jan 28 14:30:03 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Wed, 28 Jan 2009 13:30:03 -0700 Subject: cogent issues? In-Reply-To: <4980BFA3.5010703@zero11.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net> <4980BFA3.5010703@zero11.com> Message-ID: <1233174603.3607.25.camel@artoo.vvmedia.com> >From the outages list: Cogent is currently experiencing problems on their backbone in Chicago, manifesting as packet loss and latency. The master ticket # is 853582. On Wed, 2009-01-28 at 12:27 -0800, John Martinez wrote: > http://www.internetpulse.net/ > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From wschultz at bsdboy.com Wed Jan 28 14:31:07 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 28 Jan 2009 12:31:07 -0800 Subject: cogent issues? In-Reply-To: <4980BFA3.5010703@zero11.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net> <4980BFA3.5010703@zero11.com> Message-ID: <90240ECB-77C2-45AE-8D57-E29F6570C1CD@bsdboy.com> https://puck.nether.net/pipermail/outages/2009-January/001101.html -wil On Jan 28, 2009, at 12:27 PM, John Martinez wrote: > http://www.internetpulse.net/ > From jmartinez at zero11.com Wed Jan 28 14:37:50 2009 From: jmartinez at zero11.com (John Martinez) Date: Wed, 28 Jan 2009 12:37:50 -0800 Subject: cogent issues? In-Reply-To: <90240ECB-77C2-45AE-8D57-E29F6570C1CD@bsdboy.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net> <4980BFA3.5010703@zero11.com> <90240ECB-77C2-45AE-8D57-E29F6570C1CD@bsdboy.com> Message-ID: <4980C21E.5070109@zero11.com> Wil Schultz wrote: > https://puck.nether.net/pipermail/outages/2009-January/001101.html > > -wil > > On Jan 28, 2009, at 12:27 PM, John Martinez wrote: > >> http://www.internetpulse.net/ >> > Thank you all. From leen at wirehub.nl Wed Jan 28 14:53:15 2009 From: leen at wirehub.nl (Leen Besselink) Date: Wed, 28 Jan 2009 21:53:15 +0100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <20090128151826.38145A5B28C@riy-m18.saudi.net.sa> References: Message-ID: <20090128205314.GA5791@debian64.besselink> > ----- Original Message ----- > From: "aljuhani" > Subject: Re: Tightened DNS security question re: DNS amplification > attacks. > To: "nanog" > > Well the RBLs, in using dns queries, is another form of legal DDoS attacks, mainly when the > suddenly cease to respond or re-configure to black-list the entire wold. One should just > imagine the bandwidth consumption during a > +given time-frame, RBLs consume as oppose to volume of spam messages. > If you folks are really serious about this, can I suggest using BGP for this ? Maybe a multi-hop BGP-session like Team Cymru already has for bogons [0]. With different communities for different types of traffic that should be dropped. That way you, the network operator, could choose what you what to drop and how. They are already a pretty trusted party if people actually use these bogon-sessions. Might it actually be a structural solution ? Atleast if I didn't forget something important. [0] http://www.team-cymru.org/Services/Bogons/routeserver.html > ----- Original Message ----- > From: "Frank Bulk" > To: "'Paul Vixie'" ; > Sent: Wednesday, January 28, 2009 18:02 > Subject: RE: Tightened DNS security question re: DNS amplification attacks. > > > | Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) > | From RWerber at epiknetworks.com Wed Jan 28 14:56:16 2009 From: RWerber at epiknetworks.com (Ryan Werber) Date: Wed, 28 Jan 2009 15:56:16 -0500 Subject: cogent issues? References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com><200901272116.n0RLGiJA002250@ns1.konadogs.net><6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov><41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net><4980BFA3.5010703@zero11.com> <90240ECB-77C2-45AE-8D57-E29F6570C1CD@bsdboy.com> Message-ID: <4D58C7B4943F874BA4CB5D68A79240606D63DE@Epikserver2.Epik.local> That ticket was opened yesterday, and we have been hit very hard with it. This problem started on Monday night - I don't know what they did, but we lost all of our Toronto sites in the middle of the night for a good bit - so I assume maintenance - Then all h*ll broke loose over the last couple days. >https://puck.nether.net/pipermail/outages/2009-January/001101.html -wil On Jan 28, 2009, at 12:27 PM, John Martinez wrote: > http://www.internetpulse.net/ > Ryan Werber Sr. Network Engineer Epik Networks From jmartinez at zero11.com Wed Jan 28 15:04:30 2009 From: jmartinez at zero11.com (John Martinez) Date: Wed, 28 Jan 2009 13:04:30 -0800 Subject: cogent issues? In-Reply-To: <4D58C7B4943F874BA4CB5D68A79240606D63DE@Epikserver2.Epik.local> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com><200901272116.n0RLGiJA002250@ns1.konadogs.net><6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov><41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net><4980BFA3.5010703@zero11.com> <90240ECB-77C2-45AE-8D57-E29F6570C1CD@bsdboy.com> <4D58C7B4943F874BA4CB5D68A79240606D63DE@Epikserver2.Epik.local> Message-ID: <4980C85E.3060609@zero11.com> Ryan Werber wrote: > That ticket was opened yesterday, and we have been hit very hard with > it. This problem started on Monday night - I don't know what they did, > but we lost all of our Toronto sites in the middle of the night for a > good bit - so I assume maintenance - Then all h*ll broke loose over the > last couple days. > >> https://puck.nether.net/pipermail/outages/2009-January/001101.html > > -wil > > On Jan 28, 2009, at 12:27 PM, John Martinez wrote: > >> http://www.internetpulse.net/ >> > > Ryan Werber > Sr. Network Engineer > Epik Networks > We saw the issue starting to show up in our monitors at 8:55 EST. From jmartinez at zero11.com Wed Jan 28 15:06:18 2009 From: jmartinez at zero11.com (John Martinez) Date: Wed, 28 Jan 2009 13:06:18 -0800 Subject: cogent issues? In-Reply-To: <4D58C7B4943F874BA4CB5D68A79240606D63DE@Epikserver2.Epik.local> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com><200901272116.n0RLGiJA002250@ns1.konadogs.net><6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov><41649.1233171005@nsa.vix.com> <4980B76C.6020401@brightok.net><4980BFA3.5010703@zero11.com> <90240ECB-77C2-45AE-8D57-E29F6570C1CD@bsdboy.com> <4D58C7B4943F874BA4CB5D68A79240606D63DE@Epikserver2.Epik.local> Message-ID: <4980C8CA.6060907@zero11.com> Ryan Werber wrote: > That ticket was opened yesterday, and we have been hit very hard with > it. This problem started on Monday night - I don't know what they did, > but we lost all of our Toronto sites in the middle of the night for a > good bit - so I assume maintenance - Then all h*ll broke loose over the > last couple days. > >> https://puck.nether.net/pipermail/outages/2009-January/001101.html > > -wil > > On Jan 28, 2009, at 12:27 PM, John Martinez wrote: > >> http://www.internetpulse.net/ >> > > Ryan Werber > Sr. Network Engineer > Epik Networks > > Seems like that packet loss is decreasing. From frnkblk at iname.com Wed Jan 28 16:27:05 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 28 Jan 2009 16:27:05 -0600 Subject: -48VDC equipment recommendations In-Reply-To: <497F9A23.70008@ai.net> References: <497F9A23.70008@ai.net> Message-ID: We're using this a product by C&D and happy with it: http://www.cdstandbypower.com/product/power_sys/system/sageon.html Runs very quietly, very efficient (compared to what we used to have) For our smaller sites, we use Valere: http://www.eltekvalere.com/wip4/telecom/c/detail.epl?cat=11071 It's amazing how compact they've made these units. Frank -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Tuesday, January 27, 2009 5:35 PM To: nanog list Subject: -48VDC equipment recommendations Who does everyone like for -48VDC power systems nowadays (say in the 60A @48VDC and 600A at 48VDC sizes). Something like you'd deploy in a POP or a 10-rack MMR with A&B. Management/no-management, not a big deal. Off-list is fine, and I'll be glad to summarize for the list. Thanks in advance, Deepak From phil.pennock at spodhuis.org Wed Jan 28 17:11:30 2009 From: phil.pennock at spodhuis.org (Phil Pennock) Date: Wed, 28 Jan 2009 15:11:30 -0800 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <41649.1233171005@nsa.vix.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> Message-ID: <20090128231130.GA66814@redoubt.spodhuis.org> On 2009-01-28 at 19:30 +0000, Paul Vixie wrote: > DNS-oriented attacks are of a completely different kind. today's attacks were > precisely described in > (which wasn't news in october 2002 but somebody had to write it down so i did). > the important statement out of that 4-page document is: "Source addresses that > appear at Border or Interior connections are nonrepudiable by nature..." and > that statement bears on the question of RBL for DNS-oriented DDoS attacks since > the address we'd have to assign a reputation to is the victim, so all we can > do is make an attack worse (by denying service to the victim's real traffic.) I'd be willing to drop DNS queries, without even sending back a REFUSED response, if they come in with RD set from an IP in a list X, where X might be an RBL. I'd be perfectly happy to have X list every root server, gTLD server and ccTLD server, as a starting point, on the basis that none of those should ever be sending out RD queries, so refusing to reply to those addresses should have no impact. Perhaps if operators start to do this, anyone still running critical infrastructure authoritative DNS servers which perform recursive queries would finally split roles. Smaller outfits might get away with an auth server which does recursion too, for a finite set of IPs (eg, "localhost"), if they have issues obtaining IP addresses. Anyone providing nameservers for gTLD or ccTLD zones should not have this problem. (My personal nameserver is in the smaller outfit category here). Now, implementing the RBL against only recursive queries is a separate issue; without nameserver support, you're obviously down to packet filtering. bind supports complete blackholes, but not RD blackholes, AFAIK, but you'd be in a better position than me to say what's coming in bind. iptables can apparently perform payload inspection, but pf definitely can't (at this time). By this, I mean filtering on udp[10] & 0xf9 = 1 [1] Regards, -Phil [1] That's from the tcpdump rule I'm using to glance at this traffic; intf=ifname0 # wire ethernet device ipv4=192.0.2.1 # local IP tcpdump -vvvnpi $intf -Xs 1500 "( (dst host $ipv4 and dst port 53 and (udp[10] & 0xf9 = 1)) or (src host $ipv4 and src port 53 and (udp[10:2] & 0xfc80 = 0x8000)) )" Queries: QR=0, Opcode=0, RD=1 Responses: QR=1, Opcode=0, AA=0 And all assuming that we're only worried about UDP queries, since a TCP query implies the three-way handshake and if that's susceptible to spoofing then there are routing issues too. From phil.pennock at spodhuis.org Wed Jan 28 17:21:23 2009 From: phil.pennock at spodhuis.org (Phil Pennock) Date: Wed, 28 Jan 2009 15:21:23 -0800 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <20090128231130.GA66814@redoubt.spodhuis.org> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> <20090128231130.GA66814@redoubt.spodhuis.org> Message-ID: <20090128232123.GA66921@redoubt.spodhuis.org> Sorry to follow up to myself; a few more moments reviewing before sending were warranted. On 2009-01-28 at 15:11 -0800, Phil Pennock wrote: > I'd be perfectly happy to have X list every root server, gTLD server and > ccTLD server, as a starting point, on the basis that none of those > should ever be sending out RD queries, Before I get grilled on this point: it's not strictly true, since obviously things like looking up the IPs of secondary servers to send NOTIFY requests to may use recursive DNS. Okay, unless you're running a nameserver which secondaries from the gTLD/ccTLD/root servers, you have no reason to see RD packets from those servers. Hopefully that's accurate enough to appease people who'll otherwise concentrate on that point and lose sight of what I was trying to show -- that *most* people could easily make use of such an RBL, if the nameservers supported using an external file for ignoring RD queries without dropping all traffic. As people upgrade Bind naturally, the number of reflectors that could participate in an attack would go down. Get the OS vendors to use default configs which set a Bind option to maintain the file automatically and you're getting most of the way there, by sheer number of DNS servers. -Phil From william.allen.simpson at gmail.com Wed Jan 28 17:50:15 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 28 Jan 2009 18:50:15 -0500 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <41649.1233171005@nsa.vix.com> References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> <41649.1233171005@nsa.vix.com> Message-ID: <4980EF37.4010406@gmail.com> Paul Vixie wrote: > have been able to bind a reputation to an IP address and act in some way based > on that reputation because TCP more or less requires that a real IP address > be used. we're seeing cracks at the edges of this model now, because so many > core routers have login: cisco; password: cisco, and it's now trivial for any > spammer to inject BGP that either lights up unallocated space or cuts out a > piece of somebody else's allocated block. this makes it possible to very > temporarily and untraceably speak TCP from addresses that have no reputation > (if they're unallocated) or that have a good reputation (if they're cutouts). > ... > i've pondered whether a network reputation service based on morality rather > than behaviour could possibly work. > ... would anyone be willing to deny service to them -- to paint > them as having a negative reputation even though their "sin" is laziness or > cluelessness rather than malevolent intent? > ... Yes, I've long been an advocate. Heck, the entire community had to take this approach temporarily to slow/stop 2 worms (so far), because the damage was so great that we couldn't operate otherwise. However, I'd argue semantically that this is "behaviour" as well -- under a negligence or attractive nuisance doctrine. My previous solution involved extensive AUPs, but over time I've found AUPs to be almost entirely unenforcible. Action turns out to be very expensive, courts don't understand them, and are reluctant to support the "outsider" ISP over their small business that belongs to the local chamber. I was pleased by community action for de-peering this last year, although it took several years of mounting evidence and national media exposure. Do we need a law? From stephens at ameslab.gov Wed Jan 28 18:32:04 2009 From: stephens at ameslab.gov (Douglas C. Stephens) Date: Wed, 28 Jan 2009 18:32:04 -0600 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9830CC657D3@PUR-EXCH07.ox.com> <200901272116.n0RLGiJA002250@ns1.konadogs.net> <6.2.3.4.2.20090127162808.02d4ae50@imap.ameslab.gov> Message-ID: <6.2.3.4.2.20090128182341.042ffd18@imap.ameslab.gov> At 09:21 PM 1/27/2009, Paul Vixie wrote: >"Douglas C. Stephens" writes: > > > ... > > I choose the latter, and that is why went to the effort of blocking this > > abusive traffic before it reaches my authoritative-only DNS servers. > >this is an odd implementation choice. the 1PPS query stream is still using >your line even with this defense in place. the 1PPS response stream and the >CPU cycles it takes to generate that stream isn't a burden on you (compared >to the 1PPS query stream that you can't stop anyway). so the only reason to >block these appears to be so that you don't participate in the attack, or in >other words to cut down the burden on the victim. with me so far? > >the burden on the victim isn't going to drop materially by what you did since >hundreds of thousands of other servers are not going to block it. but if the >victim is a recursive nameserver, then your blocking them will mean that they >cannot access the zones you're authoritative for. so, no positive, but some >negative, for the only person in the whole equation who can be affected by >the blocking you're doing. > >i don't get it. with a cost:benefit matrix like that one, why is anybody >blocking this traffic? (i note with some alarm that ten years after i shot >it down, i still get queries to rbl.maps.vix.com, so the possibility that the >blocks some folks might put in place to ...manage?... this attack will have a >long term bad effect on our heirs and assigns. i know your perl script will >expire things 60 seconds after they stop spewing, but i fear that others are >blocking these in hardcode. > >(looking for ". IN NS" as the q-tuple pattern is not a solution, since the >bad guys can pretty trivially change the question they ask into one you're >willing to answer.) > >(REFUSED is nice because it's small, but the bad guys aren't lacking for bots >to transmit spoofed packets from, they Do Not Need amplification, and all >forms of error rate limiting are also new attack vectors.) > >(is there a name-and-shame registry for networks that do/don't implement >BCP38? if not i guess i'll start one and hope that various auditors will use >google and notice me.) >-- >Paul Vixie Paul, Arrrg. I checked and you're right about the ACL blocking potentially legitimate queries from the victim's IP address of authoritative zones served from my authoritative-only DNS servers. This is an issue if the victim is running a recursive DNS server at that IP address. However, is this really an issue if the victim is running a non- recursive DNS server or another kind of server at that IP address? In the latter case, I think not. In the former case, maybe, if it is an authoritative-only DNS server that doesn't call its own system stub resolver, or if it is a forwarding DNS server configured to query my authoritative-only servers (though goodness knows why someone would want to do that). Obviously my code did not vet the detected IP address for these cases, and I don't see any way to do so. The 1 pps query stream is not a burden to my line, nor to my servers. My goal was to make it more difficult for these perpetrators to relay this garbage off my authoritative-only servers, and thus reduce the abusive traffic being reflected towards their target(s). As you said, the "bad guys" aren't lacking for bots, and they don't need, nor seem interested in, amplification. I hadn't noticed BIND having any handles to turn for this. Maybe I'll work on that, or just rebuild my kernels to include the u32 IPtables module. As for why to block near the reflector? Given the cost/benefit you pointed out, and using my tool or other simpler ACLs, you're right, it doesn't make sense. However, using proper DPI tools (which obviously my tool was not), why shouldn't those who are able to block near the reflector? A variation on the IPtables u32 rule I saw posted elsewhere, or a handle to turn in BIND, based on signatures of known abusive query patterns would accomplish for DNS attack vector what anti-virus has been doing for decades for workstation and server systems, would it not? (Yes, yes, I know, signature-based tech is bloated and dying, and behavioral tech is the wave of the future, but right now signatures are all there is for this attack vector.) To address another critique of the posting of my tool, evolution of this form of attack is inevitable. For example, several people have suggested that the next variation will be to change the query data from asking for a root referral to asking for some other zone for which my authoritative-only servers are not authoritative. I'm not so sure, though, about the "bad guys" changing their query into something my authoritative-only servers should answer and not REFUSE. I think changing to querying for a zone my servers are authoritative for would come after simple permutations of their initial static query signature. Though it may be a recent innovation to use a botnet to carry out these attacks, the vector itself is not new, and they started with a simple static query signature. Their botnet CinC channels seem sophisticated enough to divide labor to send out spam, but are they sophisticated enough to determine which zones I host authoritative-only and then hammer out spoofed-source-address queries for only those zones? If not, then a signature-based DPI blocking tool would likely have an appreciable dampening effect. If so, then at least it would raise the bar, as has most other anti-virus and anti-spyware tech. Anyway, I think the "bad guys", if they cared at all, will already be aware of the fact that the community has identified their attack signature. This is because either they are monitoring the down-ness of their targets, or because folks on this list and others have been posting details about identified targets since last week. In some way they must be aware when targets are identified by the community, since the targets keep changing as they are found and dealt with. Finally, I agree with Mark Andrews that BCP 38 is the ultimate best response, right now, and that a cooperative community of network operators working together is the best way to track down from where this garbage is coming. At least that is when said community is small enough and clueful enough. I should wonder, though, (as have others on this list) if the operators of the network(s) where these spoofed query packets originate are complying with BCP 38? Or if the operators of the networks upstream are complying with it? Also, that is assuming that the packets are originating from sufficiently stubby networks where BCP 38 can be applied. Yep, I'm full of cheery thoughts like these. -- Douglas C. Stephens | UNIX/Windows/Email Admin System Support Specialist | Network/DNS Admin Information Systems | Phone: (515) 294-6102 Ames Laboratory, US DOE | Email: stephens at ameslab.gov From Mark_Andrews at isc.org Wed Jan 28 19:58:08 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 29 Jan 2009 12:58:08 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: Your message of "Wed, 28 Jan 2009 18:32:04 MDT." <6.2.3.4.2.20090128182341.042ffd18@imap.ameslab.gov> Message-ID: <200901290158.n0T1w8vc053282@drugs.dv.isc.org> The bad guys want amplification but will take obscuring if that's all they can get. RD=1 is only the signature of the current attack. RD=0 is equally viable. Can you cope with "RD=0 NS ." directed to the root servers from forged addresses? This is exactly the query name servers use to prime their caches with. Stop trying to figure out how to stop the attack of the day as it really is a waste of time and start trying to figure out how to get near universal BCP 38 deployment. Let the world know you are a good you if are deploying BCP 38. Put up on your front web page what percentage of address space / links are convered by BCP 38 compliance, where compliance is defined as "traffic sourced from a arbitary address will not be passed". This should be auditable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Mark_Andrews at isc.org Wed Jan 28 23:18:12 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 29 Jan 2009 16:18:12 +1100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: Your message of "Wed, 28 Jan 2009 15:21:23 -0800." <20090128232123.GA66921@redoubt.spodhuis.org> Message-ID: <200901290518.n0T5ICb6063416@drugs.dv.isc.org> In message <20090128232123.GA66921 at redoubt.spodhuis.org>, Phil Pennock writes: > Sorry to follow up to myself; a few more moments reviewing before > sending were warranted. > > On 2009-01-28 at 15:11 -0800, Phil Pennock wrote: > > I'd be perfectly happy to have X list every root server, gTLD server and > > ccTLD server, as a starting point, on the basis that none of those > > should ever be sending out RD queries, > > Before I get grilled on this point: it's not strictly true, since > obviously things like looking up the IPs of secondary servers to send > NOTIFY requests to may use recursive DNS. Only if you have configured a forwarder. Nameserver make non- recursive queries by default. > Okay, unless you're running > a nameserver which secondaries from the gTLD/ccTLD/root servers, you > have no reason to see RD packets from those servers. Hopefully that's > accurate enough to appease people who'll otherwise concentrate on that > point and lose sight of what I was trying to show -- that *most* people > could easily make use of such an RBL, if the nameservers supported using > an external file for ignoring RD queries without dropping all traffic. > > As people upgrade Bind naturally, the number of reflectors that could > participate in an attack would go down. Get the OS vendors to use > default configs which set a Bind option to maintain the file > automatically and you're getting most of the way there, by sheer number > of DNS servers. > > -Phil The most common reason for recursive queries to a authoritative server is someone using dig, nslookup or similar and forgeting to disable recursion on the request. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From fweimer at bfk.de Thu Jan 29 07:01:15 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 29 Jan 2009 14:01:15 +0100 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <200901290518.n0T5ICb6063416@drugs.dv.isc.org> (Mark Andrews's message of "Thu, 29 Jan 2009 16:18:12 +1100") References: <200901290518.n0T5ICb6063416@drugs.dv.isc.org> Message-ID: <82y6wucllw.fsf@mid.bfk.de> * Mark Andrews: > The most common reason for recursive queries to a authoritative > server is someone using dig, nslookup or similar and forgeting > to disable recursion on the request. dnscache in "forward only" mode also sets the RD bit, and apparently does not restrict itself to the configured forwarders list. (This is based on a public report, not on first-hand knowledge.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From itmailinglist at connection2.com Thu Jan 29 07:00:26 2009 From: itmailinglist at connection2.com (itmailinglist) Date: Thu, 29 Jan 2009 13:00:26 -0000 Subject: ISP Unbundling circuits Message-ID: <4DEAEFAABAA743D5B7B06A9EFAC01417@response2.com> Hi everyone, Is it common for an ISP to install a lased line (circuit) and when the service ends, the service is not unbundled again but all the cabling is left where it is? I have even seen that a circuit is still active on there exchanges after years and no one at the ISP seems to care that they are wasting there own resources. Thanks and best regards, Alexander From jjn at nuge.com Thu Jan 29 07:13:47 2009 From: jjn at nuge.com (Jay Nugent) Date: Thu, 29 Jan 2009 08:13:47 -0500 (EST) Subject: ISP Unbundling circuits In-Reply-To: <4DEAEFAABAA743D5B7B06A9EFAC01417@response2.com> Message-ID: Greetings, On Thu, 29 Jan 2009, itmailinglist wrote: > Hi everyone, > Is it common for an ISP to install a lased line (circuit) and when the > service ends, the service is not unbundled again but all the cabling is left > where it is? I have even seen that a circuit is still active on there > exchanges after years and no one at the ISP seems to care that they are > wasting there own resources. *EVERY* ISP I have consulted for has failed to perform the simplest of Order Entry processes, including an item-by-item checklist of what to do when a customer disconnects. At each ISP we have found numerous circuits still in place and being paid for month after month. Only when we have gone through all of their circuit billings and customer accounts do we find all the loose ends and get their record keeping cleaned up. And then set them up with internal processes and databases that prevent such costly errors. --- Jay Nugent ISPmonitor.org "You can't manage what you can't measure" Providing monitoring and consulting services for ISP's Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 8:01am up 60 days, 16:28, 4 users, load average: 0.72, 0.16, 0.05 From karnaugh at karnaugh.za.net Thu Jan 29 07:31:40 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 29 Jan 2009 15:31:40 +0200 Subject: ISP Unbundling circuits In-Reply-To: References: Message-ID: <4981AFBC.7060405@karnaugh.za.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jay Nugent wrote: > *EVERY* ISP I have consulted for has failed to perform the simplest of > Order Entry processes, including an item-by-item checklist of what to do > when a customer disconnects. At each ISP we have found numerous circuits > still in place and being paid for month after month. Circuits seems worse, but they also don't seem to track their CPE at all. We have boxes full of various teleco CPE, including some Cisco 800 and 1600 routers. I guess it costs more than it's worth to recover it, but the irritating thing is we have to hold it "incase" they ever ask for it. I even have a cabinet full of patch/cross-connect gear at one site. The teleco took some of the NTU kit from it when it was cancelled, said they would be back for the rest and 2 years later there it stands :) Murpheys' law says the instant I tie it to the roof of my car, they will ask when they can come collect it... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJga+80FZZWLfHKjURAgkmAJ9C88Y7e04JD2NrY2y2WM7FQdk5oQCfRXE3 9nzfCipzoCfCNmw6n3XBME0= =tWQV -----END PGP SIGNATURE----- From shrdlu at deaddrop.org Thu Jan 29 09:20:16 2009 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Thu, 29 Jan 2009 07:20:16 -0800 Subject: ISP Unbundling circuits In-Reply-To: <4981AFBC.7060405@karnaugh.za.net> References: <4981AFBC.7060405@karnaugh.za.net> Message-ID: <4981C930.1070705@deaddrop.org> Colin Alston wrote: > I even have a cabinet full of patch/cross-connect gear at one site. The > teleco took some of the NTU kit from it when it was cancelled, said they > would be back for the rest and 2 years later there it stands :) > > Murpheys' law says the instant I tie it to the roof of my car, they will > ask when they can come collect it... For equipment that can be moved, and is still vaguely useful, send them a certified letter, explaining that you will be donating all this equipment to X (my personal suggestion is Cymru) upon a certain date not too far in the future, if arrangements are not made to retrieve it. Once you've received the signature back, and the date arrives, donate it. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan From michael.holstein at csuohio.edu Thu Jan 29 09:30:14 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 29 Jan 2009 10:30:14 -0500 Subject: ISP Unbundling circuits In-Reply-To: <4DEAEFAABAA743D5B7B06A9EFAC01417@response2.com> References: <4DEAEFAABAA743D5B7B06A9EFAC01417@response2.com> Message-ID: <4981CB86.4070804@csuohio.edu> > Is it common for an ISP to install a lased line (circuit) and when the > service ends, the service is not unbundled again but all the cabling is left > where it is? I have even seen that a circuit is still active on there > exchanges after years and no one at the ISP seems to care that they are > wasting there own resources. > At various jobs, I too have seen boxes of CPE gear waiting for the phone call out of the blue demanding it back, and circuits that are still live despite being disconnected ages ago (and not being paid for). On the home front, I canceled my digital cable years ago, but they never asked for the converter boxes back, nor did they physically disconnect the cable (I have satellite nowdays). I have never seen them remove cables, etc. it's just too expensive to bother with. The exception to this is Verizon when they do a FiOS install .. except they actually remove the *competitor's* cables, if the customer asks them to (which is preceded by the question "hey .. while I'm up there, I can take down that ugly wire if you ask me to.."). Cheers, ~Mike. From web at typo.org Thu Jan 29 10:51:19 2009 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 29 Jan 2009 09:51:19 -0700 Subject: ISP Unbundling circuits In-Reply-To: <4981AFBC.7060405@karnaugh.za.net> References: <4981AFBC.7060405@karnaugh.za.net> Message-ID: <20090129165119.GA28735@typo.org> On Thu, Jan 29, 2009 at 03:31:40PM +0200, Colin Alston wrote: > Circuits seems worse, but they also don't seem to track their CPE at > all. We have boxes full of various teleco CPE, including some Cisco 800 > and 1600 routers. I guess it costs more than it's worth to recover it, > but the irritating thing is we have to hold it "incase" they ever ask > for it. Well, SOME of that is a deliberate decision. I mean, equipment is expected to have a useful life and then either fail or be obsolete. Some custsomers can carry a contract 4 or 5 years. At that point, the equipment they had may well not be in use anywhere else on the network. There's not much point in reclaiming equipment you can't use and can't get a decent value for through the various disposal channels. But yeah, ISPs and telcos as well are generally horrible about reclaiming property. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From pmeaux at msn.com Thu Jan 29 11:12:33 2009 From: pmeaux at msn.com (pmeaux MEAUX) Date: Thu, 29 Jan 2009 12:12:33 -0500 Subject: NetFlow Research Message-ID: I am doing some research at the University of Colorado on NetFlow and its potential to influence BGP routing policies. Are there any examples where review of NetFlow data has caused a change in a BGP routing policy? How often are these changes made and what would be the most common reasons for using NetFlow? Thanks Paul Meaux _________________________________________________________________ Windows Live?: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_012009 From bruce at greatbasin.net Thu Jan 29 11:45:25 2009 From: bruce at greatbasin.net (Bruce Robertson) Date: Thu, 29 Jan 2009 09:45:25 -0800 Subject: ISP Unbundling circuits In-Reply-To: <4DEAEFAABAA743D5B7B06A9EFAC01417@response2.com> References: <4DEAEFAABAA743D5B7B06A9EFAC01417@response2.com> Message-ID: <4981EB35.8010804@greatbasin.net> Sometimes it's the telco. We've issued disconnects for copper-based T1s, and seen the HDSL card still powered years later. itmailinglist wrote: > Hi everyone, > > > > Is it common for an ISP to install a lased line (circuit) and when the > service ends, the service is not unbundled again but all the cabling is left > where it is? I have even seen that a circuit is still active on there > exchanges after years and no one at the ISP seems to care that they are > wasting there own resources. > > > > Thanks and best regards, > > > > Alexander > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: bruce.vcf Type: text/x-vcard Size: 352 bytes Desc: not available URL: From dholmes at mwdh2o.com Thu Jan 29 11:45:39 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 29 Jan 2009 09:45:39 -0800 Subject: -48VDC equipment recommendations In-Reply-To: References: <497F9A23.70008@ai.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E084EADE7@usmsxt104.mwd.h2o> For large plants, the Sageon brand is excellent and for small scale, 48 VDC @ 30 amps the Argus brand is excellent. The Sageon units are stand-alone. The Argus units are rm @ 19" and 23". We use both. David -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Wednesday, January 28, 2009 2:27 PM To: deepak at ai.net; nanog list Subject: RE: -48VDC equipment recommendations We're using this a product by C&D and happy with it: http://www.cdstandbypower.com/product/power_sys/system/sageon.html Runs very quietly, very efficient (compared to what we used to have) For our smaller sites, we use Valere: http://www.eltekvalere.com/wip4/telecom/c/detail.epl?cat=11071 It's amazing how compact they've made these units. Frank -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Tuesday, January 27, 2009 5:35 PM To: nanog list Subject: -48VDC equipment recommendations Who does everyone like for -48VDC power systems nowadays (say in the 60A @48VDC and 600A at 48VDC sizes). Something like you'd deploy in a POP or a 10-rack MMR with A&B. Management/no-management, not a big deal. Off-list is fine, and I'll be glad to summarize for the list. Thanks in advance, Deepak From sethm at rollernet.us Thu Jan 29 11:56:56 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 29 Jan 2009 09:56:56 -0800 Subject: ISP Unbundling circuits In-Reply-To: <4981AFBC.7060405@karnaugh.za.net> References: <4981AFBC.7060405@karnaugh.za.net> Message-ID: <4981EDE8.5070102@rollernet.us> Colin Alston wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jay Nugent wrote: >> *EVERY* ISP I have consulted for has failed to perform the simplest of >> Order Entry processes, including an item-by-item checklist of what to do >> when a customer disconnects. At each ISP we have found numerous circuits >> still in place and being paid for month after month. > > > Circuits seems worse, but they also don't seem to track their CPE at > all. We have boxes full of various teleco CPE, including some Cisco 800 > and 1600 routers. I guess it costs more than it's worth to recover it, > but the irritating thing is we have to hold it "incase" they ever ask > for it. > > I even have a cabinet full of patch/cross-connect gear at one site. The > teleco took some of the NTU kit from it when it was cancelled, said they > would be back for the rest and 2 years later there it stands :) > > Murpheys' law says the instant I tie it to the roof of my car, they will > ask when they can come collect it... Same here; cabinet full of telco stuff. I've showed it to several techs and they've all told me they wouldn't reuse it anyway so there's no point in taking it back. ~Seth From phil.pennock at spodhuis.org Thu Jan 29 13:54:14 2009 From: phil.pennock at spodhuis.org (Phil Pennock) Date: Thu, 29 Jan 2009 11:54:14 -0800 Subject: Tightened DNS security question re: DNS amplification attacks. In-Reply-To: <82y6wucllw.fsf@mid.bfk.de> References: <200901290518.n0T5ICb6063416@drugs.dv.isc.org> <82y6wucllw.fsf@mid.bfk.de> Message-ID: <20090129195414.GA67911@redoubt.spodhuis.org> On 2009-01-29 at 14:01 +0100, Florian Weimer wrote: > * Mark Andrews: > > The most common reason for recursive queries to a authoritative > > server is someone using dig, nslookup or similar and forgeting > > to disable recursion on the request. Useful to know, thanks. So someone performing diagnostics on one of the root/gTLD/ccTLD servers would need to remember to dig +norec when checking visibility? Are manual diagnostics going out from the source IP of such auth nameservers considered common? In any case, it's a small enough, and hopefully clued enough, sample of admins that it shouldn't be a problem. Any organisation seeking to add their auth nameservers to a public RBL of such IPs will have to accept the same constraint on needing clued staff. No tears shed at that. > dnscache in "forward only" mode also sets the RD bit, and apparently > does not restrict itself to the configured forwarders list. (This is > based on a public report, not on first-hand knowledge.) Unless any of the root/gTLD/ccTLD nameservers are also running dnscache, it should be safe to drop UDP RD packets from those source IP addresses, as previously described. -Phil From mark at noc.mainstreet.net Thu Jan 29 14:14:33 2009 From: mark at noc.mainstreet.net (Mark Kent) Date: Thu, 29 Jan 2009 12:14:33 -0800 (PST) Subject: ISP Unbundling circuits Message-ID: <200901292014.n0TKEXtq037747@mainstreet.net> On a slightly related topic, a US-based colo outfit used by a company I work with wants a fee to disconnect power to the cage. The tenant had been there for years and, at contract renewal time, was lobbied hard ($$) by the colo company to reduce power consumption. The tenant worked for a few months and freed up 20 power circuits. The colo then said that they had a disconnect fee for each power circuit. Now, I think a reasonable fee is $0. The colo wants considerably more. I won't bias you with the figure yet... please let me know what you think is reasonable, either by experience or just as a thought exercise. Thanks, -mark From web at typo.org Thu Jan 29 14:22:46 2009 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 29 Jan 2009 13:22:46 -0700 Subject: ISP Unbundling circuits In-Reply-To: <200901292014.n0TKEXtq037747@mainstreet.net> References: <200901292014.n0TKEXtq037747@mainstreet.net> Message-ID: <20090129202246.GA30226@typo.org> I've never been happy with 'deinstall' fees of any sort. To me, this is just a cost of doing business. The time necessary to remove such is just accepted. It is assumed that the terms of the contract are long enough that such costs become insignificant and should not be something that gets passed along. Besides, if you turn right around and reuse this for someone else, you haven't done a deinstall and are therefore charging the customer for work that you did not actually perform. There are several different ways to argue both for and against such fees but they always rub me the wrong way whenever I see them. On Thu, Jan 29, 2009 at 12:14:33PM -0800, Mark Kent wrote: > On a slightly related topic, a US-based colo outfit used by a company > I work with wants a fee to disconnect power to the cage. The tenant > had been there for years and, at contract renewal time, was lobbied > hard ($$) by the colo company to reduce power consumption. > > The tenant worked for a few months and freed up 20 power circuits. > The colo then said that they had a disconnect fee for each power > circuit. > > Now, I think a reasonable fee is $0. The colo wants considerably more. > I won't bias you with the figure yet... please let me know what you > think is reasonable, either by experience or just as a thought exercise. > > Thanks, > -mark > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jcdill.lists at gmail.com Thu Jan 29 14:35:37 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 29 Jan 2009 12:35:37 -0800 Subject: ISP Unbundling circuits In-Reply-To: <200901292014.n0TKEXtq037747@mainstreet.net> References: <200901292014.n0TKEXtq037747@mainstreet.net> Message-ID: <49821319.5060503@gmail.com> Mark Kent wrote: > On a slightly related topic, a US-based colo outfit used by a company > I work with wants a fee to disconnect power to the cage. The tenant > had been there for years and, at contract renewal time, was lobbied > hard ($$) by the colo company to reduce power consumption. > Did they mention a deinstall fee at this time? > The tenant worked for a few months and freed up 20 power circuits. > The colo then said that they had a disconnect fee for each power > circuit. > > Now, I think a reasonable fee is $0. The colo wants considerably more. > I won't bias you with the figure yet... please let me know what you > think is reasonable, either by experience or just as a thought exercise. > I think a reasonable fee is whatever is set in their contract - which I suspect is $0. You can't just tack on fees like this afterwards. jc From jeffrey.lyon at blacklotus.net Thu Jan 29 14:41:49 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 29 Jan 2009 15:41:49 -0500 Subject: ISP Unbundling circuits In-Reply-To: <49821319.5060503@gmail.com> References: <200901292014.n0TKEXtq037747@mainstreet.net> <49821319.5060503@gmail.com> Message-ID: <16720fe00901291241j3cb9af77xe54ef998d16e0596@mail.gmail.com> I think they should pay *you* a deinstall fee just for suggesting something like that. Jeff On Thu, Jan 29, 2009 at 3:35 PM, JC Dill wrote: > Mark Kent wrote: >> >> On a slightly related topic, a US-based colo outfit used by a company >> I work with wants a fee to disconnect power to the cage. The tenant >> had been there for years and, at contract renewal time, was lobbied >> hard ($$) by the colo company to reduce power consumption. >> > > Did they mention a deinstall fee at this time? >> >> The tenant worked for a few months and freed up 20 power circuits. >> The colo then said that they had a disconnect fee for each power >> circuit. >> >> Now, I think a reasonable fee is $0. The colo wants considerably more. >> I won't bias you with the figure yet... please let me know what you >> think is reasonable, either by experience or just as a thought exercise. >> > > I think a reasonable fee is whatever is set in their contract - which I > suspect is $0. You can't just tack on fees like this afterwards. > > jc > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From brettlists at gmail.com Thu Jan 29 15:38:13 2009 From: brettlists at gmail.com (B C) Date: Thu, 29 Jan 2009 21:38:13 +0000 Subject: Paypal DNS Problems? Message-ID: <5c494b510901291338s5b89692cjaf9c915c22b49f44@mail.gmail.com> As the subject says really, paypal's DNS servers don't appear to be responding for me... [root at oracle1 oracle]# dig @a.gtld-servers.net paypal.com ; <<>> DiG 9.2.4 <<>> @a.gtld-servers.net paypal.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38254 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;paypal.com. IN A ;; AUTHORITY SECTION: paypal.com. 172800 IN NS ppns1.den.paypal.com. paypal.com. 172800 IN NS ppns1.phx.paypal.com. paypal.com. 172800 IN NS ppns2.den.paypal.com. paypal.com. 172800 IN NS ppns2.phx.paypal.com. ;; ADDITIONAL SECTION: ppns1.den.paypal.com. 172800 IN A 216.113.188.121 ppns1.phx.paypal.com. 172800 IN A 66.211.168.226 ppns2.den.paypal.com. 172800 IN A 216.113.188.122 ppns2.phx.paypal.com. 172800 IN A 66.211.168.227 ;; Query time: 32 msec ;; SERVER: 192.5.6.30#53(a.gtld-servers.net) ;; WHEN: Thu Jan 29 21:34:58 2009 ;; MSG SIZE rcvd: 180 [root at oracle1 oracle]# dig @216.113.188.121 paypal.com ns ; <<>> DiG 9.2.4 <<>> @216.113.188.121 paypal.com ns ;; global options: printcmd ;; connection timed out; no servers could be reached [root at oracle1 oracle]# [root at oracle1 oracle]# dig @66.211.168.226 paypal.com ns ; <<>> DiG 9.2.4 <<>> @66.211.168.226 paypal.com ns ;; global options: printcmd ;; connection timed out; no servers could be reached From jmartinez at zero11.com Thu Jan 29 15:56:25 2009 From: jmartinez at zero11.com (John Martinez) Date: Thu, 29 Jan 2009 13:56:25 -0800 Subject: Paypal DNS Problems? In-Reply-To: <5c494b510901291338s5b89692cjaf9c915c22b49f44@mail.gmail.com> References: <5c494b510901291338s5b89692cjaf9c915c22b49f44@mail.gmail.com> Message-ID: <49822609.1000701@zero11.com> B C wrote: > As the subject says really, paypal's DNS servers don't appear to be > responding for me... > > > [root at oracle1 oracle]# dig @a.gtld-servers.net paypal.com > > ; <<>> DiG 9.2.4 <<>> @a.gtld-servers.net paypal.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38254 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > > ;; QUESTION SECTION: > ;paypal.com. IN A > > ;; AUTHORITY SECTION: > paypal.com. 172800 IN NS ppns1.den.paypal.com. > paypal.com. 172800 IN NS ppns1.phx.paypal.com. > paypal.com. 172800 IN NS ppns2.den.paypal.com. > paypal.com. 172800 IN NS ppns2.phx.paypal.com. > > ;; ADDITIONAL SECTION: > ppns1.den.paypal.com. 172800 IN A 216.113.188.121 > ppns1.phx.paypal.com. 172800 IN A 66.211.168.226 > ppns2.den.paypal.com. 172800 IN A 216.113.188.122 > ppns2.phx.paypal.com. 172800 IN A 66.211.168.227 > > ;; Query time: 32 msec > ;; SERVER: 192.5.6.30#53(a.gtld-servers.net) > ;; WHEN: Thu Jan 29 21:34:58 2009 > ;; MSG SIZE rcvd: 180 > > [root at oracle1 oracle]# dig @216.113.188.121 paypal.com ns > > ; <<>> DiG 9.2.4 <<>> @216.113.188.121 paypal.com ns > ;; global options: printcmd > ;; connection timed out; no servers could be reached > [root at oracle1 oracle]# > [root at oracle1 oracle]# dig @66.211.168.226 paypal.com ns > > ; <<>> DiG 9.2.4 <<>> @66.211.168.226 paypal.com ns > ;; global options: printcmd > ;; connection timed out; no servers could be reached > I'm not seeing any issues. Is anyone else? From BBlackford at nwresd.k12.or.us Thu Jan 29 15:57:11 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Thu, 29 Jan 2009 13:57:11 -0800 Subject: Paypal DNS Problems? In-Reply-To: <49822609.1000701@zero11.com> References: <5c494b510901291338s5b89692cjaf9c915c22b49f44@mail.gmail.com> <49822609.1000701@zero11.com> Message-ID: <6069A203FD01884885C037F81DD75080C43FE51C@wsc-mail-01.intra.nwresd.k12.or.us> Looks ok here. -b -----Original Message----- From: John Martinez [mailto:jmartinez at zero11.com] Sent: Thursday, January 29, 2009 1:56 PM Cc: nanog at nanog.org Subject: Re: Paypal DNS Problems? B C wrote: > As the subject says really, paypal's DNS servers don't appear to be > responding for me... > > > [root at oracle1 oracle]# dig @a.gtld-servers.net paypal.com > > ; <<>> DiG 9.2.4 <<>> @a.gtld-servers.net paypal.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38254 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > > ;; QUESTION SECTION: > ;paypal.com. IN A > > ;; AUTHORITY SECTION: > paypal.com. 172800 IN NS ppns1.den.paypal.com. > paypal.com. 172800 IN NS ppns1.phx.paypal.com. > paypal.com. 172800 IN NS ppns2.den.paypal.com. > paypal.com. 172800 IN NS ppns2.phx.paypal.com. > > ;; ADDITIONAL SECTION: > ppns1.den.paypal.com. 172800 IN A 216.113.188.121 > ppns1.phx.paypal.com. 172800 IN A 66.211.168.226 > ppns2.den.paypal.com. 172800 IN A 216.113.188.122 > ppns2.phx.paypal.com. 172800 IN A 66.211.168.227 > > ;; Query time: 32 msec > ;; SERVER: 192.5.6.30#53(a.gtld-servers.net) > ;; WHEN: Thu Jan 29 21:34:58 2009 > ;; MSG SIZE rcvd: 180 > > [root at oracle1 oracle]# dig @216.113.188.121 paypal.com ns > > ; <<>> DiG 9.2.4 <<>> @216.113.188.121 paypal.com ns > ;; global options: printcmd > ;; connection timed out; no servers could be reached > [root at oracle1 oracle]# > [root at oracle1 oracle]# dig @66.211.168.226 paypal.com ns > > ; <<>> DiG 9.2.4 <<>> @66.211.168.226 paypal.com ns > ;; global options: printcmd > ;; connection timed out; no servers could be reached > I'm not seeing any issues. Is anyone else? From gem at rellim.com Thu Jan 29 16:03:59 2009 From: gem at rellim.com (Gary E. Miller) Date: Thu, 29 Jan 2009 14:03:59 -0800 (PST) Subject: Paypal DNS Problems? In-Reply-To: <49822609.1000701@zero11.com> References: <5c494b510901291338s5b89692cjaf9c915c22b49f44@mail.gmail.com> <49822609.1000701@zero11.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo John! On Thu, 29 Jan 2009, John Martinez wrote: > > As the subject says really, paypal's DNS servers don't appear to be > > responding for me... > I'm not seeing any issues. > Is anyone else? That, and payflow.verisign.com, were down for me two. From East and West coasts. Back now. Fingers crossed. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFJgifUBmnRqz71OvMRApyWAJ4xQSetg3WFQfLND7IezW16bw9tZQCgnixp tdkVhEhozM6L0Q9nyH4A+yQ= =Lp8C -----END PGP SIGNATURE----- From brettlists at gmail.com Thu Jan 29 16:17:13 2009 From: brettlists at gmail.com (B C) Date: Thu, 29 Jan 2009 22:17:13 +0000 Subject: Paypal DNS Problems? In-Reply-To: References: <5c494b510901291338s5b89692cjaf9c915c22b49f44@mail.gmail.com> <49822609.1000701@zero11.com> Message-ID: <5c494b510901291417r7196e909ha1eae985b59979cc@mail.gmail.com> On Thu, Jan 29, 2009 at 10:03 PM, Gary E. Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yo John! > > On Thu, 29 Jan 2009, John Martinez wrote: > >> > As the subject says really, paypal's DNS servers don't appear to be >> > responding for me... > >> I'm not seeing any issues. >> Is anyone else? > > That, and payflow.verisign.com, were down for me two. From East and > West coasts. Back now. Fingers crossed. > Yes came back up about 10 mins after I posted. Guess we'll never know unless there is a paypal network person on the list. Brett From steve at ibctech.ca Thu Jan 29 22:09:39 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 29 Jan 2009 23:09:39 -0500 Subject: New ISP to market, BCP 38, and new tactics In-Reply-To: <498166AC.5030608@ipax.at> References: <497D1764.4050709@ibctech.ca> <498166AC.5030608@ipax.at> Message-ID: <49827D83.7040304@ibctech.ca> Raoul Bhatia [IPAX] wrote: > hello steve, > > Steve Bertrand wrote: >> I've done much research on RPSL, BCP 38, and other basic filter methods >> (and from a systems standpoint, I always follow an >> allow,allow,default-deny approach) , and I am willing to follow all >> standards and recommended practises to ensure compliance with current >> Internet standards. > > did you receive off-list replies? do you mind replying with a summary > of your findings to the list? i would also be interested in this subject > thou i will not be able to work on this during the next couple of > months. Yes, I did receive a few very kind off-list replies. The feedback was based mainly on the fact that I have a small number of address blocks, and few connections to the Internet. In summary: - implement BCP 38 by using ACLs on outward facing interfaces by permitting anything within my (or my client's) address space as source, and log/deny the rest (which is my personal standard per my OP) - on all client-connected interfaces, ensure that the prefix(es) you supply them with is found in the source address for packets inbound, and deny the rest - for smaller *SPs, ACLs is the way to go, as with only a few prefixes and a limited number of connections to the Internet, manual management of filters is easily maintained. Inbound ACLs can be put in place when a new client is provisioned, and for a small shop without the need or the resources, strategies such as uRPF are not advised - pay attention to uRPF ("and the like"), as manual ACL management is not scalable. It pays to keep up with what the "big boys" are doing. Having knowledge of scalable methods, while utilizing a basic approach will allow for an easier transition in the event of quick growth/acquisition/new job. - ensure you only advertise your own block(s) via BGP. allow-allow-deny approach - regarding BGP, scrutinize, but deny-by-default anything longer than /24. (With IPv6, I don't know of any standard, so I filter above /48 and I have 1579 and 1422 routes with two peers) The above is a summary of feedback from others. I have a few that I already do personally, but remember that I don't even advertise my v4 space myself yet: - peer with Cymru, and null route BOGONs - implement a pull-up route - on all interfaces, 'get rid of' inbound traffic with a source within BOGON - inform clients of their broken VPN connections, when you see private IP space being sent via their assigned default gateway (which of course is just an alert, because it has already been null0'd) - always develop the closest-match allow filters you can, and implement with an explicit deny. If anything, for visual purposes - never be afraid to ask for help - be confident, but always assume someone knows more than you do - and most important (IMHO), always acknowledge and be able to admit when you have made a mistake. Hopefully this summary is ok. Thanks to all those who did reply off-list. Steve From bruce at yoafrica.com Thu Jan 29 23:33:44 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Fri, 30 Jan 2009 07:33:44 +0200 Subject: Shaping on a large scale Message-ID: <49829138.6010304@yoafrica.com> Hi, Does anyone know of any Shaping appliances to shape customers based on IP, allow for a quota per IP and qos mechanisms like LLQ?, This is should be something that can sit in between two border router's and support a small ISP (20000 customers), also an opensource solution would be great! Regards, Bruce From nuno.vieira at nfsi.pt Fri Jan 30 03:04:05 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 30 Jan 2009 09:04:05 +0000 (WET) Subject: Shaping on a large scale In-Reply-To: <49829138.6010304@yoafrica.com> Message-ID: <2130427677.8181233306245368.JavaMail.root@zimbra.nfsi.pt> Check Ipoque solutions. http://www.ipoque.com/ regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Bruce Grobler" wrote: > Hi, > > Does anyone know of any Shaping appliances to shape customers based > on > IP, allow for a quota per IP and qos mechanisms like LLQ?, This is > should be something that can sit in between two border router's and > support a small ISP (20000 customers), also an opensource solution > would > be great! > > Regards, > > Bruce From cidr-report at potaroo.net Fri Jan 30 05:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Jan 2009 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200901301100.n0UB05oc051043@wattle.apnic.net> BGP Update Report Interval: 29-Dec-08 -to- 29-Jan-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7643 88011 1.2% 146.2 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 2 - AS9583 84992 1.2% 57.3 -- SIFY-AS-IN Sify Limited 3 - AS4323 69146 0.9% 16.1 -- TWTC - tw telecom holdings, inc. 4 - AS6389 68757 0.9% 15.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS6629 52216 0.7% 791.2 -- NOAA-AS - NOAA 6 - AS209 51988 0.7% 18.0 -- ASN-QWEST - Qwest Communications Corporation 7 - AS35805 50222 0.7% 141.1 -- UTG-AS United Telecom AS 8 - AS20115 43116 0.6% 20.4 -- CHARTER-NET-HKY-NC - Charter Communications 9 - AS8151 39308 0.5% 26.3 -- Uninet S.A. de C.V. 10 - AS1785 36937 0.5% 20.0 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - AS17974 35121 0.5% 70.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS17488 34805 0.5% 23.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 13 - AS9829 33611 0.5% 39.6 -- BSNL-NIB National Internet Backbone 14 - AS7018 28934 0.4% 19.5 -- ATT-INTERNET4 - AT&T WorldNet Services 15 - AS2386 27997 0.4% 17.3 -- INS-AS - AT&T Data Communications Services 16 - AS14420 27808 0.4% 112.6 -- ANDINATEL S.A. 17 - AS4766 27066 0.4% 15.1 -- KIXS-AS-KR Korea Telecom 18 - AS6458 27005 0.4% 55.6 -- Telgua 19 - AS21433 25762 0.4% 196.7 -- ACCENTUREFSSC Accenture London Delivery Centre 20 - AS24863 25397 0.3% 40.9 -- LINKdotNET-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30287 6015 0.1% 6015.0 -- ALON-USA - ALON USA, LP 2 - AS48129 4829 0.1% 4829.0 -- IRBIS-TELECOMMUNICATIONS-AS IRBIS Telecommunications Ltd. 3 - AS30306 18237 0.2% 3647.4 -- AfOL-Sz-AS 4 - AS32753 3180 0.0% 3180.0 -- GLOBEOP-FINANCIAL-SERVICES-NYC1 - GlobeOp Financial Services 5 - AS12500 12180 0.2% 3045.0 -- RCS-AS RCS Autonomus System 6 - AS30969 24339 0.3% 3042.4 -- TAN-NET TransAfrica Networks 7 - AS23917 2792 0.0% 2792.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 8 - AS28194 7093 0.1% 2364.3 -- 9 - AS19017 1990 0.0% 1990.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 10 - AS32398 13362 0.2% 1670.2 -- REALNET-ASN-1 11 - AS45122 1572 0.0% 1572.0 -- JASPACE-AS-ID-AP PT. JASPACE NET 12 - AS41007 4615 0.1% 1538.3 -- CTCASTANA CTC ASTANA, KZ 13 - AS10806 6138 0.1% 1534.5 -- AFP-NET - AGENCE FRANCE PRESSE 14 - AS24228 10091 0.1% 1441.6 -- BARNETWORK-AP BarNetwork Pty Limited 15 - AS5033 13137 0.2% 1313.7 -- ISW - Internet Specialties West Inc. 16 - AS30095 2523 0.0% 1261.5 -- AS-30095 - Group M Worldwide, Inc. 17 - AS25970 7511 0.1% 1251.8 -- IAC - IAC Services LLC 18 - AS29427 2456 0.0% 1228.0 -- AZM-AS Mercury Telecom 19 - AS44265 13244 0.2% 1204.0 -- SMOLTELECOM-NET Smoltelecom Ltd AS peering 20 - AS29224 2052 0.0% 1026.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 210.214.151.0/24 22738 0.3% AS9583 -- SIFY-AS-IN Sify Limited 2 - 124.7.201.0/24 21287 0.3% AS9583 -- SIFY-AS-IN Sify Limited 3 - 144.36.245.0/24 21258 0.3% AS21433 -- ACCENTUREFSSC Accenture London Delivery Centre 4 - 72.23.246.0/24 18307 0.2% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 5 - 192.35.129.0/24 17259 0.2% AS6629 -- NOAA-AS - NOAA 6 - 192.102.88.0/24 17030 0.2% AS6629 -- NOAA-AS - NOAA 7 - 198.77.177.0/24 16984 0.2% AS6629 -- NOAA-AS - NOAA 8 - 41.204.2.0/24 13199 0.2% AS32398 -- REALNET-ASN-1 9 - 64.162.116.0/24 13016 0.2% AS5033 -- ISW - Internet Specialties West Inc. 10 - 196.27.104.0/21 11897 0.2% AS30969 -- TAN-NET TransAfrica Networks 11 - 196.27.108.0/22 11819 0.2% AS30969 -- TAN-NET TransAfrica Networks 12 - 222.255.51.64/26 10834 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 13 - 192.12.120.0/24 10506 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 14 - 202.83.176.0/21 9977 0.1% AS24228 -- BARNETWORK-AP BarNetwork Pty Limited 15 - 221.135.80.0/24 9100 0.1% AS9583 -- SIFY-AS-IN Sify Limited 16 - 212.85.220.0/24 8932 0.1% AS30306 -- AfOL-Sz-AS 17 - 212.85.223.0/24 8920 0.1% AS30306 -- AfOL-Sz-AS 18 - 199.2.119.0/24 7055 0.1% AS11816 -- SetarNet 19 - 89.4.131.0/24 6255 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 158.50.64.0/20 6099 0.1% AS10806 -- AFP-NET - AGENCE FRANCE PRESSE Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jan 30 05:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Jan 2009 22:00:03 +1100 (EST) Subject: The Cidr Report Message-ID: <200901301100.n0UB03n1051037@wattle.apnic.net> This report has been generated at Fri Jan 30 21:13:57 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 Prefixes CIDR Agg 23-01-09 286053 177941 24-01-09 286089 178446 25-01-09 286547 178462 26-01-09 286835 178564 27-01-09 287083 178066 28-01-09 286198 178147 29-01-09 286289 177870 30-01-09 286408 178004 AS Summary 30507 Number of ASes in routing system 12982 Number of ASes announcing only one prefix 4379 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89881344 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'). --- 30Jan09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 286397 178149 108248 37.8% All ASes AS6389 4379 356 4023 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4216 1741 2475 58.7% TWTC - tw telecom holdings, inc. AS209 2828 1264 1564 55.3% ASN-QWEST - Qwest Communications Corporation AS4766 1771 499 1272 71.8% KIXS-AS-KR Korea Telecom AS17488 1507 345 1162 77.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1200 231 969 80.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1007 62 945 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1476 615 861 58.3% Uninet S.A. de C.V. AS1785 1803 1036 767 42.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS11492 1218 458 760 62.4% CABLEONE - CABLE ONE, INC. AS8452 1021 283 738 72.3% TEDATA TEDATA AS19262 944 243 701 74.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1566 899 667 42.6% INS-AS - AT&T Data Communications Services AS3356 1143 489 654 57.2% LEVEL3 Level 3 Communications AS18101 766 143 623 81.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS18566 1061 466 595 56.1% COVAD - Covad Communications Co. AS6478 1204 660 544 45.2% ATT-INTERNET3 - AT&T WorldNet Services AS7545 690 158 532 77.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS2706 545 25 520 95.4% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 623 114 509 81.7% VTR BANDA ANCHA S.A. AS17908 602 111 491 81.6% TCISL Tata Communications AS855 602 146 456 75.7% CANET-ASN-4 - Bell Aliant AS4808 612 158 454 74.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1438 1003 435 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 902 475 427 47.3% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 661 239 422 63.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 699 283 416 59.5% LGNET-AS-KR LG CNS AS9443 504 92 412 81.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 527 115 412 78.2% GIGAINFRA BB TECHNOLOGY Corp. AS7011 958 550 408 42.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 38473 13259 25214 65.5% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.12.96.0/19 AS15834 MENANET-AS MenaNet network Autonomous System 62.12.107.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 67.20.0.0/20 AS27334 MEGAGATE - Megagate Broadband, Inc. 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 81.4.0.0/18 AS15834 MENANET-AS MenaNet network Autonomous System 95.208.0.0/16 AS29562 KABELBW-ASN Kabel Baden-Wuerttemberg GmbH & Co. KG 95.209.0.0/16 AS44034 HI3G Hi3G Access AB 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 155.254.0.0/16 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.67.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.69.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.71.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.74.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.75.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.77.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.78.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.106.8.0/21 AS36052 JTI0 - Juch-Tech Inc 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.233.204.0/22 AS22446 MEDLINE - Medline Industries 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.100.64.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.65.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.66.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.68.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.69.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.71.0/24 AS20598 CYBERSPACE-AS Autonomous System number for Cyber Space, 212.100.72.0/24 AS29835 NSS-CA - New Skies Satellites, Inc. 212.100.73.0/24 AS29835 NSS-CA - New Skies Satellites, Inc. 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.128.0/20 AS15834 MENANET-AS MenaNet network Autonomous System 217.29.134.0/24 AS15834 MENANET-AS MenaNet network Autonomous System 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From arievayner at gmail.com Fri Jan 30 05:09:44 2009 From: arievayner at gmail.com (Arie Vayner) Date: Fri, 30 Jan 2009 13:09:44 +0200 Subject: Shaping on a large scale In-Reply-To: <49829138.6010304@yoafrica.com> References: <49829138.6010304@yoafrica.com> Message-ID: <20b13c6b0901300309m43e2d5bkf9e369a4b40db8f3@mail.gmail.com> Take a look here: http://www.cisco.com/en/US/products/ps6151/index.html Arie On Fri, Jan 30, 2009 at 7:33 AM, Bruce Grobler wrote: > Hi, > > Does anyone know of any Shaping appliances to shape customers based on IP, > allow for a quota per IP and qos mechanisms like LLQ?, This is should be > something that can sit in between two border router's and support a small > ISP (20000 customers), also an opensource solution would be great! > > Regards, > > Bruce > > From scott.berkman at reignmaker.net Fri Jan 30 09:25:49 2009 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Fri, 30 Jan 2009 10:25:49 -0500 (EST) Subject: Shaping on a large scale In-Reply-To: <49829138.6010304@yoafrica.com> References: <49829138.6010304@yoafrica.com> Message-ID: <005401c982ef$c18a49f0$449eddd0$@berkman@reignmaker.net> Check out Packeteer. I used to work somewhere about that size and this was the product we used: http://www.bluecoat.com/products/packetshaper/ Open source you can do a custom setup with IPTables and iproute2, but it will take some work to get the same kind of features and management interface. LARTC is a good reference for this kind of topic: http://lartc.org/. Also I'm not sure if someone has built this into any of the firewall specific linux distros yet, so you may want to explore those a little. Good luck, -Scott -----Original Message----- From: Bruce Grobler [mailto:bruce at yoafrica.com] Sent: Friday, January 30, 2009 12:34 AM To: nanog at nanog.org Subject: Shaping on a large scale Hi, Does anyone know of any Shaping appliances to shape customers based on IP, allow for a quota per IP and qos mechanisms like LLQ?, This is should be something that can sit in between two border router's and support a small ISP (20000 customers), also an opensource solution would be great! Regards, Bruce From jlarsen at richweb.com Fri Jan 30 09:40:23 2009 From: jlarsen at richweb.com (C. Jon Larsen) Date: Fri, 30 Jan 2009 10:40:23 -0500 (EST) Subject: Shaping on a large scale In-Reply-To: <005401c982ef$c18a49f0$449eddd0$@berkman@reignmaker.net> References: <49829138.6010304@yoafrica.com> <005401c982ef$c18a49f0$449eddd0$@berkman@reignmaker.net> Message-ID: > Open source you can do a custom setup with IPTables and iproute2, but it > will take some work to get the same kind of features and management > interface. LARTC is a good reference for this kind of topic: > http://lartc.org/. Also I'm not sure if someone has built this into any > of the firewall specific linux distros yet, so you may want to explore > those a little. The scripts below will set max bandwidth on an interface to 60mbit, and setup a queue to shape a.b.c.d to 3Mbit. Seems to work ok for me. Its used on a physical server to limit bandwidth to a virtual server(s) on the physical server. Should work just as well on a dual-armed router/firewall shaping devices behind it. You would just create more classes (1:11, 1:12, etc) for more clients/ips to shape and you might want to knock the ceiling on the default (1:30) class down to guarantee the bandwidth to the 1:10, 1:11...classes. tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 60mbit burst 150k tc class add dev eth0 parent 1:1 classid 1:10 htb rate 3mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 60mbit burst 150k tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 ## limit a.b.c.d to 3mbit/sec: U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" $U32 match ip src a.b.c.d/32 flowid 1:10 $U32 match ip dst a.b.c.d/32 flowid 1:10 tc -s -d qdisc show dev eth0 > -----Original Message----- > From: Bruce Grobler [mailto:bruce at yoafrica.com] > Sent: Friday, January 30, 2009 12:34 AM > To: nanog at nanog.org > Subject: Shaping on a large scale > > Hi, > > Does anyone know of any Shaping appliances to shape customers based on > IP, allow for a quota per IP and qos mechanisms like LLQ?, This is > should be something that can sit in between two border router's and > support a small ISP (20000 customers), also an opensource solution would > be great! From bert.hubert at netherlabs.nl Fri Jan 30 11:56:39 2009 From: bert.hubert at netherlabs.nl (bert hubert) Date: Fri, 30 Jan 2009 18:56:39 +0100 Subject: Shaping on a large scale Message-ID: <20090130175639.GA22516@outpost.ds9a.nl> On Fri, Jan 30, 2009 at 10:25:49AM -0500, Scott Berkman wrote: > http://lartc.org/. Also I'm not sure if someone has built this into any > of the firewall specific linux distros yet, so you may want to explore > those a little. They have. Many Linux appliances come with a 'Linux Wonder Shaper' http://lartc.org/wondershaper/ or an equivalent. In general, the Linux packet shaping infrastructure is overly powerful, if very weakly documented - despite the LARTC efforts. I do have to add that shaping is rarely an exact science, and that achieving very high accuracies may prove impossible on general (timer interrupt based) hardware & operating systems. Stochastic results will be good however. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From adriankok2000 at yahoo.com.hk Fri Jan 30 11:57:25 2009 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Sat, 31 Jan 2009 01:57:25 +0800 (CST) Subject: can I ask mtu question Message-ID: <761682.59176.qm@web33301.mail.mud.yahoo.com> Hi What is max mtu in jumbo frame? ls it 9000? Do I need to reboot the switch to take effect after setting up it? if it doesn't need to reboot, How can I know the switch is running fine in this mtu 9000? eg: cisco any tools to check? Thank you for your help Send instant messages to your online friends http://uk.messenger.yahoo.com From pstewart at nexicomgroup.net Fri Jan 30 12:00:20 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 30 Jan 2009 13:00:20 -0500 Subject: can I ask mtu question In-Reply-To: <761682.59176.qm@web33301.mail.mud.yahoo.com> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01F7FDB9@nexus.nexicomgroup.net> Depends on the hardware - GSR's have different MTU's than 7600's for example (and dependant on linecard too). We use 9216 between 7206VXR and 7606 for example. No, the change is immediate - "show interface" will tell you among other commands... Paul -----Original Message----- From: adrian kok [mailto:adriankok2000 at yahoo.com.hk] Sent: January 30, 2009 12:57 PM To: nanog at nanog.org Subject: can I ask mtu question Hi What is max mtu in jumbo frame? ls it 9000? Do I need to reboot the switch to take effect after setting up it? if it doesn't need to reboot, How can I know the switch is running fine in this mtu 9000? eg: cisco any tools to check? Thank you for your help Send instant messages to your online friends http://uk.messenger.yahoo.com ---------------------------------------------------------------------------- "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." From msmith at internap.com Fri Jan 30 12:02:51 2009 From: msmith at internap.com (Michael Smith) Date: Fri, 30 Jan 2009 13:02:51 -0500 Subject: can I ask mtu question In-Reply-To: <761682.59176.qm@web33301.mail.mud.yahoo.com> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB020A1DB6@cx49.800onemail.com> http://www.google.com/search?source=ig&hl=en&rlz=&=&q=What+is+max+mtu+in +jumbo+frame%3F+&btnG=Google+Search&aq=f >-----Original Message----- >From: adrian kok [mailto:adriankok2000 at yahoo.com.hk] >Sent: Friday, January 30, 2009 12:57 PM >To: nanog at nanog.org >Subject: can I ask mtu question > >Hi > >What is max mtu in jumbo frame? >ls it 9000? > >Do I need to reboot the switch to take effect after >setting up it? > >if it doesn't need to reboot, How can I know the >switch is running fine in this mtu 9000? eg: cisco >any tools to check? > >Thank you for your help > > > >Send instant messages to your online friends >http://uk.messenger.yahoo.com From cscora at apnic.net Fri Jan 30 12:04:23 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Jan 2009 04:04:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200901301804.n0UI4Nun032709@thyme.apnic.net> 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-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Jan, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Complete listing at http://thyme.apnic.net/current/data-ASnet Complete listing at http://thyme.apnic.net/current/data-CIDRnet Complete listing at http://thyme.apnic.net/current/data-badAS Complete listing at http://thyme.apnic.net/current/data-dsua Complete listing at http://thyme.apnic.net/current/data-add-IANA Complete listing at http://thyme.apnic.net/current/data/sXXas-nos End of report From goemon at anime.net Fri Jan 30 12:07:25 2009 From: goemon at anime.net (goemon at anime.net) Date: Fri, 30 Jan 2009 10:07:25 -0800 (PST) Subject: clueful yahoo admin? Message-ID: Can a yahoo mail admin with clue pleae contact me? I'm going around in circles with your support staff who are unable to read headers. -Dan From deepak at ai.net Fri Jan 30 12:10:05 2009 From: deepak at ai.net (Deepak Jain) Date: Fri, 30 Jan 2009 13:10:05 -0500 Subject: -48VDC summary of responses Message-ID: Lots of folks provided very good suggestions and information. Here is a brief attempt at a summary. I only got a few sales folks hitting me up, so you are probably on your own to get in touch with most of these guys. Top recommendation: * Eltek/Valere seemed to be the top recommendation (3:1 or 4:1), though customer svc is rumored to have gone downhill since the acquisition). Large Plants: (1000A and more) ** C&C & Sageon (sageon: stand alone, not rack mount, C&C scales in 100A increments) Small plants: Argus (re: Cordex unit- management UI only works in IE, emails just fine, good chassis based expandability) [2:1 recommendation here] Tyco in the lower range Telect for unmanaged supplies/PDUs Lorain/Realtec makes nice equipment. Thanks to everyone for their input, I don't have much more detail from most of the responses so if you want a contact who is using this gear, I can try to make the introduction. Deepak Jain AiNET From bdfleming at kanren.net Fri Jan 30 13:06:03 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Fri, 30 Jan 2009 13:06:03 -0600 Subject: can I ask mtu question In-Reply-To: <761682.59176.qm@web33301.mail.mud.yahoo.com> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: <82447760-7AEE-4427-A8CA-6F5255B9F905@kanren.net> KanREN runs Foundry (Brocade) NetIron XMR 4000's as our primary core infrastructure with an MTU of 9216. To make the change (this is Foundry-specific), we have to change some system-max settings which only take effect once the device has been rebooted (or at least it DID require a reboot in the IronWare 3.3.x days). It does NOT reboot immediately so you're free to make the change then perform a reboot at a convenient time. -- Brad Fleming Network Engineer Kansas Research and Education Network Office: 785-856-9800 x.222 Moblie: 785-865-7231 NOC: 866-984-3662 On Jan 30, 2009, at 11:57 AM, adrian kok wrote: > Hi > > What is max mtu in jumbo frame? > ls it 9000? > > Do I need to reboot the switch to take effect after > setting up it? > > if it doesn't need to reboot, How can I know the > switch is running fine in this mtu 9000? eg: cisco > any tools to check? > > Thank you for your help > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > > From ccaputo at alt.net Fri Jan 30 13:54:00 2009 From: ccaputo at alt.net (Chris Caputo) Date: Fri, 30 Jan 2009 19:54:00 +0000 (UTC) Subject: Shaping on a large scale In-Reply-To: References: <49829138.6010304@yoafrica.com> <005401c982ef$c18a49f0$449eddd0$@berkman@reignmaker.net> Message-ID: On Fri, 30 Jan 2009, C. Jon Larsen wrote: > > Open source you can do a custom setup with IPTables and iproute2, but it > > will take some work to get the same kind of features and management > > interface. LARTC is a good reference for this kind of topic: > > http://lartc.org/. Also I'm not sure if someone has built this into any > > of the firewall specific linux distros yet, so you may want to explore > > those a little. > > The scripts below will set max bandwidth on an interface to 60mbit, and setup > a queue to shape a.b.c.d to 3Mbit. Seems to work ok for me. Its used on a > physical server to limit bandwidth to a virtual server(s) on the physical > server. Should work just as well on a dual-armed router/firewall shaping > devices behind it. You would just create more classes (1:11, 1:12, etc) for > more clients/ips to shape and you might want to knock the ceiling on the > default (1:30) class down to guarantee the bandwidth to the 1:10, > 1:11...classes. > > tc qdisc add dev eth0 root handle 1: htb default 30 > > tc class add dev eth0 parent 1: classid 1:1 htb rate 60mbit burst 150k > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 3mbit burst 15k > tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 60mbit burst > 150k > > tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 > > ## limit a.b.c.d to 3mbit/sec: > U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" > $U32 match ip src a.b.c.d/32 flowid 1:10 > $U32 match ip dst a.b.c.d/32 flowid 1:10 > > tc -s -d qdisc show dev eth0 tcng - Traffic Control Next Generation (http://tcng.sourceforge.net/) provides a configuration language that abstracts the gnarliness above. Chris From jfbeam at gmail.com Fri Jan 30 15:33:43 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 30 Jan 2009 16:33:43 -0500 Subject: can I ask mtu question In-Reply-To: <761682.59176.qm@web33301.mail.mud.yahoo.com> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: On Fri, 30 Jan 2009 12:57:25 -0500, adrian kok wrote: > What is max mtu in jumbo frame? That depends on the hardware. I've seen gear running as low as ~8k. I'd have to consult standard, but I think the max is 10k (10240). Keep in mind the switch is not the only device on the network with jumbo frame limits. The NICs in your servers will also have limits. > Do I need to reboot the switch to take effect after > setting up it? Again, this depends on the system. Many accept the change immediately, while others have to rebooted or interfaces reset to effect the change. > if it doesn't need to reboot, How can I know the > switch is running fine in this mtu 9000? eg: cisco > any tools to check? "ping" will do. Set the packet size larger than the normal MTU (1500) and see if it crosses the network intact. If it's not working, A) the packets will be dropped, and B) the "oversized frame" counter (among others) should be clocking errors. --Ricky From streiner at cluebyfour.org Fri Jan 30 15:51:00 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 30 Jan 2009 16:51:00 -0500 (EST) Subject: can I ask mtu question In-Reply-To: References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: On Fri, 30 Jan 2009, Ricky Beam wrote: > On Fri, 30 Jan 2009 12:57:25 -0500, adrian kok > wrote: >> What is max mtu in jumbo frame? > > That depends on the hardware. I've seen gear running as low as ~8k. I'd > have to consult standard, but I think the max is 10k (10240). > > Keep in mind the switch is not the only device on the network with jumbo > frame limits. The NICs in your servers will also have limits. > >> Do I need to reboot the switch to take effect after >> setting up it? > > Again, this depends on the system. Many accept the change immediately, while > others have to rebooted or interfaces reset to effect the change. > >> if it doesn't need to reboot, How can I know the >> switch is running fine in this mtu 9000? eg: cisco >> any tools to check? > > "ping" will do. Set the packet size larger than the normal MTU (1500) and > see if it crosses the network intact. If it's not working, A) the packets > will be dropped, and B) the "oversized frame" counter (among others) should > be clocking errors. If you're sourcing the pings from a device that supports it, you can also send the large pings with the Do Not Fragment bit set. jms From sthaug at nethelp.no Fri Jan 30 15:59:12 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 30 Jan 2009 22:59:12 +0100 (CET) Subject: can I ask mtu question In-Reply-To: References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: <20090130.225912.74704493.sthaug@nethelp.no> > That depends on the hardware. I've seen gear running as low as ~8k. I'd > have to consult standard, but I think the max is 10k (10240). There *is* no standard for jumbo MTU. IEEE has steadfastly refused to standardize anything bigger than 1500 bytes. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From saku+nanog at ytti.fi Fri Jan 30 16:00:00 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Sat, 31 Jan 2009 00:00:00 +0200 Subject: can I ask mtu question In-Reply-To: References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: <20090130220000.GA10014@mx.ytti.net> On (2009-01-30 16:33 -0500), Ricky Beam wrote: > That depends on the hardware. I've seen gear running as low as ~8k. I'd > have to consult standard, but I think the max is 10k (10240). Which standard are you referring to? AFAIK, nothing above 1500 is standardised -- ++ytti From bruce at yoafrica.com Fri Jan 30 16:21:38 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Sat, 31 Jan 2009 00:21:38 +0200 Subject: Shaping on a large scale In-Reply-To: References: <49829138.6010304@yoafrica.com> <005401c982ef$c18a49f0$449eddd0$@berkman@reignmaker.net> Message-ID: <000001c98329$1f06ffe0$5d14ffa0$@com> Hi, Thanks for all the comments!, do you know of any web frontends for these apps? (don't want to go reinventing the wheel) Something that preferably uses a mysql backend. Regards, Bruce Grobler Yo! Africa - Network Engineer Cell : 0912364532 Skype: bruce.grobler -----Original Message----- From: Chris Caputo [mailto:ccaputo at alt.net] Sent: Friday, January 30, 2009 9:54 PM To: C. Jon Larsen Cc: Scott Berkman; nanog at nanog.org Subject: RE: Shaping on a large scale On Fri, 30 Jan 2009, C. Jon Larsen wrote: > > Open source you can do a custom setup with IPTables and iproute2, but it > > will take some work to get the same kind of features and management > > interface. LARTC is a good reference for this kind of topic: > > http://lartc.org/. Also I'm not sure if someone has built this into any > > of the firewall specific linux distros yet, so you may want to explore > > those a little. > > The scripts below will set max bandwidth on an interface to 60mbit, and setup > a queue to shape a.b.c.d to 3Mbit. Seems to work ok for me. Its used on a > physical server to limit bandwidth to a virtual server(s) on the physical > server. Should work just as well on a dual-armed router/firewall shaping > devices behind it. You would just create more classes (1:11, 1:12, etc) for > more clients/ips to shape and you might want to knock the ceiling on the > default (1:30) class down to guarantee the bandwidth to the 1:10, > 1:11...classes. > > tc qdisc add dev eth0 root handle 1: htb default 30 > > tc class add dev eth0 parent 1: classid 1:1 htb rate 60mbit burst 150k > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 3mbit burst 15k > tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 60mbit burst > 150k > > tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 > tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 > > ## limit a.b.c.d to 3mbit/sec: > U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" > $U32 match ip src a.b.c.d/32 flowid 1:10 > $U32 match ip dst a.b.c.d/32 flowid 1:10 > > tc -s -d qdisc show dev eth0 tcng - Traffic Control Next Generation (http://tcng.sourceforge.net/) provides a configuration language that abstracts the gnarliness above. Chris From askthelist at gmail.com Fri Jan 30 17:00:04 2009 From: askthelist at gmail.com (askthelist at gmail.com) Date: Fri, 30 Jan 2009 15:00:04 -0800 Subject: Towerstream outage/intermittency? Message-ID: anyone using towerstream in the la area and experiencing an outage? From Crist.Clark at globalstar.com Fri Jan 30 17:04:20 2009 From: Crist.Clark at globalstar.com (Crist Clark) Date: Fri, 30 Jan 2009 15:04:20 -0800 Subject: Tracking the DNS amplification attacks (was: isprime DOS in progress) In-Reply-To: References: <1b5c1c150901091641l5b89a625l185228e9aa7e72fc@mail.gmail.com> <20090120205514.GA10257@fries.net> <1232557692.9593.57.camel@squonk.lboro.ac.uk> <8763k7li3f.fsf@obelix.mork.no> <90932AF0-4D17-4D1D-B8BD-ABC2DEF8A27E@isprime.com> <1232742035.3801.1.camel@localhost.localdomain> <2AB3D2DC-4076-4B31-B14C-41A27D268377@smtps.net> Message-ID: <498316F0.33E4.0097.0@globalstar.com> >>> On 1/24/2009 at 4:50 PM, Brian Keefer wrote: > Caveat: my PERL is _terrible_. > > http://www.smtps.net/pub/dns-amp-watch.pl > > This assumes you're using BIND. My logs roll on the hour, so I run it > from cron at 1 minute before the hour. Depending on how long it takes > to process your logs, you might need to tweak. FWIW, I find it easier to track this using tcpdump. I don't like running BIND with query logging. Here's a filter that catches these, port 53 && (udp[10:4] == 0x01000001) && (udp[20:2] == 0x0000) How it works is left as an exercise for the reader. When I sniff the link to a server authorative for several domains, 17:29:55.792127 IP 72.249.127.168.3966 > 206.220.220.100.53: 18501+ NS? . (17) 17:29:57.116367 IP 69.64.87.156.58419 > 206.220.220.100.53: 62419+ NS? . (17) 17:29:57.804987 IP 72.249.127.168.33108 > 206.220.220.100.53: 4637+ NS? . (17) 17:29:58.959680 IP 72.20.3.82.23084 > 206.220.220.100.53: 14310+ NS? . (17) 17:29:59.818994 IP 72.249.127.168.60876 > 206.220.220.100.53: 22791+ NS? . (17) 17:30:01.622728 IP 69.64.87.156.30151 > 206.220.220.100.53: 13557+ NS? . (17) 17:30:01.628899 IP 72.20.3.82.49015 > 206.220.220.100.53: 14250+ NS? . (17) 17:30:01.821214 IP 72.249.127.168.13831 > 206.220.220.100.53: 51065+ NS? . (17) 17:30:03.342856 IP 69.64.87.156.1926 > 206.220.220.100.53: 38768+ NS? . (17) 17:30:03.818706 IP 72.249.127.168.33663 > 206.220.220.100.53: 12720+ NS? . (17) 17:30:05.186647 IP 72.20.3.82.7649 > 206.220.220.100.53: 52079+ NS? . (17) 17:30:05.815718 IP 72.249.127.168.37241 > 206.220.220.100.53: 345+ NS? . (17) 17:30:07.816144 IP 72.249.127.168.23784 > 206.220.220.100.53: 56874+ NS? . (17) 17:30:07.849503 IP 69.64.87.156.33190 > 206.220.220.100.53: 20113+ NS? . (17) From mmc at internode.com.au Fri Jan 30 17:13:53 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 31 Jan 2009 09:43:53 +1030 Subject: Shaping on a large scale In-Reply-To: <49829138.6010304@yoafrica.com> References: <49829138.6010304@yoafrica.com> Message-ID: <248ACA00-097A-44FE-BA3A-66A0D999BB80@internode.com.au> Bruce, Are these broadband customer using PPPoE or L2TP? If so, I suggest looking at the capabilities of your BRAS to do the work. Per user bandwidth quotas are the nature of the game here in Australia and doing it at the BRAS is the way we do it. RADIUS gives you byte counts and gives you the ability to pass back rate limits etc. MMC On 30/01/2009, at 4:03 PM, Bruce Grobler wrote: > Hi, > > Does anyone know of any Shaping appliances to shape customers based > on IP, allow for a quota per IP and qos mechanisms like LLQ?, This > is should be something that can sit in between two border router's > and support a small ISP (20000 customers), also an opensource > solution would be great! > > Regards, > > Bruce > -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From jfbeam at gmail.com Fri Jan 30 17:33:37 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 30 Jan 2009 18:33:37 -0500 Subject: can I ask mtu question In-Reply-To: References: <761682.59176.qm@web33301.mail.mud.yahoo.com> Message-ID: On Fri, 30 Jan 2009 16:51:00 -0500, Justin M. Streiner wrote: > If you're sourcing the pings from a device that supports it, you can > also send the large pings with the Do Not Fragment bit set. Most modern systems do that already (part of path MTU discovery.) And if there are no routers in the path (only the switch in question), then there's nothing to fragment it anyway. --Ricky From jfbeam at gmail.com Fri Jan 30 17:43:37 2009 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 30 Jan 2009 18:43:37 -0500 Subject: can I ask mtu question In-Reply-To: <20090130220000.GA10014@mx.ytti.net> References: <761682.59176.qm@web33301.mail.mud.yahoo.com> <20090130220000.GA10014@mx.ytti.net> Message-ID: On Fri, 30 Jan 2009 17:00:00 -0500, Saku Ytti wrote: > Which standard are you referring to? AFAIK, nothing above 1500 is > standardised None that have ever been accepted. From a quick google for manufacturer support, 9216 looks like the most popular number. But, as I said, it boils down to the largest frame *every* device on the LAN will accept. If there is a single device that only supports "9000", then that's your limit. And if there's a single non-JF device in the LAN, it throws a wrench into the whole thing. (This appears to be one of the sticking points as to why IEEE won't accept the addition of JF to any specs.) --Ricky PS: The topic pops up again with super-jumbo frames in 10G networks. From adrian at creative.net.au Fri Jan 30 21:44:56 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 31 Jan 2009 12:44:56 +0900 Subject: Shaping on a large scale In-Reply-To: <248ACA00-097A-44FE-BA3A-66A0D999BB80@internode.com.au> References: <49829138.6010304@yoafrica.com> <248ACA00-097A-44FE-BA3A-66A0D999BB80@internode.com.au> Message-ID: <20090131034456.GA30564@skywalker.creative.net.au> On Sat, Jan 31, 2009, Matthew Moyle-Croft wrote: > Bruce, > Are these broadband customer using PPPoE or L2TP? If so, I suggest > looking at the capabilities of your BRAS to do the work. > > Per user bandwidth quotas are the nature of the game here in Australia > and doing it at the BRAS is the way we do it. RADIUS gives you byte > counts and gives you the ability to pass back rate limits etc. What you didn't tell him is that the kind of shaping you can do on the BRAS heavily depends on features used and platform. :) 64k policing mostly works everywhere, for example, but isn't all that crash hot for your clients. :) Doing more complicated hierarchical QoS on software platforms is doable but complicated. Others take a multi-tiered approach - they'll buy some kit to do P2P identification/shaping, and per-user hard shaping in case they go over quota. Lots of cute stuff. :) Adrian > > MMC > > On 30/01/2009, at 4:03 PM, Bruce Grobler wrote: > > >Hi, > > > >Does anyone know of any Shaping appliances to shape customers based > >on IP, allow for a quota per IP and qos mechanisms like LLQ?, This > >is should be something that can sit in between two border router's > >and support a small ISP (20000 customers), also an opensource > >solution would be great! > > > >Regards, > > > >Bruce > > > > -- > Matthew Moyle-Croft Internode/Agile Peering and Core Networks > Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA - From chaz at chaz6.com Sat Jan 31 00:24:42 2009 From: chaz at chaz6.com (Chris Hills) Date: Sat, 31 Jan 2009 07:24:42 +0100 Subject: ISP Unbundling circuits In-Reply-To: <20090129202246.GA30226@typo.org> References: <200901292014.n0TKEXtq037747@mainstreet.net> <20090129202246.GA30226@typo.org> Message-ID: Wayne E. Bouchard wrote: > I've never been happy with 'deinstall' fees of any sort. To me, this > is just a cost of doing business. The time necessary to remove such is > just accepted. It is assumed that the terms of the contract are long > enough that such costs become insignificant and should not be > something that gets passed along. Besides, if you turn right around > and reuse this for someone else, you haven't done a deinstall and are > therefore charging the customer for work that you did not actually > perform. > > There are several different ways to argue both for and against such > fees but they always rub me the wrong way whenever I see them. Perversely these fees have gotten as far as residential broadband subscribers in the UK. BT Wholesale now charge a line disconnection fee, which is being applied retrospectively to all contracts. On the flip side, the new WEEE (Waste Electrical and Electronic Equipment) regulations make disposal of electronic equipment the responsibility of the manufacturer. From marc at let.de Sat Jan 31 01:48:43 2009 From: marc at let.de (marc) Date: Sat, 31 Jan 2009 08:48:43 +0100 Subject: OT: After dozents of spam reportings , still spam from Message-ID: i still get spam from ualadys.com hosted at ServerBeach PEER1-SERVERBEACH-08A (NET-76-74-166-0-1) I mentioned that some isps in .cz npt even allow me to send Abuse mail to them, because the block the complette ip range , rediculous , huh ? what else can i do ? thanks marc Anfang der weitergeleiteten E-Mail: > Von: ualadys mailing > Datum: 31. Januar 2009 08:30:04 MEZ > An: marc > Betreff: Weekly Special > Return-Path: > Received: from mx1.mail.vrmd.de ([10.0.1.20]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Sat, 31 Jan > 2009 08:30:06 +0100 > Received: from mx3.iispp.com ([76.74.167.190]) by mx1.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from ) id > 1LTAIo-0005l7-DA for marc at let.de; Sat, 31 Jan 2009 08:30:06 +0100 > Received: by mail.iispp.com (Postfix, from userid 1003) id > A9CC5B7BF05; Sat, 31 Jan 2009 02:30:04 -0500 (EST) > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Sat, 31 Jan 2009 08:30:06 +0100 > Message-Id: <2d1440035a3dcbfc66693621daf32f78 at localhost.localdomain> > X-Priority: 3 > X-Mailer: PHPMailer (phpmailer.codeworxtech.com) [version 2.2] > Mime-Version: 1.0 > Content-Type: multipart/alternative; > boundary="b1_2d1440035a3dcbfc66693621daf32f78" > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: 150741::090131083006-569C86C0- > ACFC0CF4/2502755973-0/0-1 X-purgate-Ad: For more information about > eXpurgate please visit http://www.expurgate.net/ > > > > > Weekly Special! > > Thank you for using our services! We would like to make a special > price offer for our services: > > Please choose one of our weekly special offers and get 1 video > credit for free > > This Special Offer will be available for 1 week ONLY! Don?t miss > your chance to urchase our service for better price! > > Ladies' New Videos > > -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de jabber :marc at kgraff.net IRC: #opencu freenode.net PGP/GnuPG: 0x1ac02f3296b12b4d twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From karnaugh at karnaugh.za.net Sat Jan 31 02:53:59 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Sat, 31 Jan 2009 10:53:59 +0200 Subject: Shaping on a large scale In-Reply-To: <20090130175639.GA22516@outpost.ds9a.nl> References: <20090130175639.GA22516@outpost.ds9a.nl> Message-ID: <498411A7.6070302@karnaugh.za.net> On 2009/01/30 07:56 PM bert hubert wrote: > In general, the Linux packet shaping infrastructure is overly powerful, if > very weakly documented - despite the LARTC efforts. > "Overly powerful" is a strong word. Sure it has countless poorly documented features, but then it fails at even the the most trivial task at shaping ingress without having to shape your other egress interface. Essentially, you have to throw hardware at it. FreeBSD notably has less of these problems, but neither are all that viable on large scale throughputs. From rubensk at gmail.com Sat Jan 31 04:42:23 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 31 Jan 2009 08:42:23 -0200 Subject: Shaping on a large scale In-Reply-To: <49829138.6010304@yoafrica.com> References: <49829138.6010304@yoafrica.com> Message-ID: <6bb5f5b10901310242v389d2f03gd56966ebe45ccbb5@mail.gmail.com> Besides the other solutions listed, you can also take a look at Arbor (formerly Ellacoya) and Sandvine. Rubens On Fri, Jan 30, 2009 at 3:33 AM, Bruce Grobler wrote: > Hi, > > Does anyone know of any Shaping appliances to shape customers based on IP, > allow for a quota per IP and qos mechanisms like LLQ?, This is should be > something that can sit in between two border router's and support a small > ISP (20000 customers), also an opensource solution would be great! > > Regards, > > Bruce > > From marc at let.de Sat Jan 31 04:46:23 2009 From: marc at let.de (marc) Date: Sat, 31 Jan 2009 11:46:23 +0100 Subject: OT: After dozents of spam reportings , still spam from References: Message-ID: <07FEB939-D790-4B62-BB9D-F9AD56E19965@let.de> sorry again just for the records and web NANOG archives second worth enemy : > Von: Discount Shopper > Datum: 31. Januar 2009 11:36:15 MEZ > An: marc at let.de > Betreff: Wal-Mart Notice: You've been selected to receive a $1000 > Wal-Mart GiftCard > Antwort an: > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Sat, 31 Jan > 2009 11:35:58 +0100 > Received: from tboraxweed.com ([69.64.30.86]) by mx2.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from ) id > 1LTDCg-0002lY-Gw for marc at let.de; Sat, 31 Jan 2009 11:35:59 +0100 > Received: by tboraxweed.com (Postfix) with SMTP id 1AE25173BCE for >; Sat, 31 Jan 2009 05:36:15 -0500 (EST) > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Sat, 31 Jan 2009 11:35:59 +0100 > X-Priority: 5 > X-Mailer: Alife12 > Content-Type: text/html; charset=us-ascii; > Content-Disposition: inline > Message-Id: <20090131103615.1AE25173BCE at tboraxweed.com> > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: > 150741::090131113558-29D086C0-2F47B123/2502851796-0/0-0 X-purgate- > Ad: For more information about eXpurgate please visit http://www.expurgate.net/ 3rd worth enemy > Von: Your participation in our Gift Card Survey is greatly valued. > > Datum: 31. Januar 2009 11:19:57 MEZ > An: > Betreff: $500 Sears? Gift Card?come see what's new. > Antwort an: > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Sat, 31 Jan > 2009 11:20:22 +0100 > Received: from gwcx.nflblack.com ([72.13.18.216]) by > mx2.mail.vrmd.de with esmtp (Exim 4.69) (envelope-from >) id 1LTCxZ-0005i0-U2 for marc at let.de; Sat, 31 Jan 2009 11:20:22 > +0100 > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Sat, 31 Jan 2009 11:20:22 +0100 > Message-Id: <71218.291541664.1233392633 at nflblack.com> > List-Unsubscribe: > > Mime-Version: 1.0 > Content-Type: multipart/alternative; boundary="291541664.1233392633" > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: 150741::090131112022-55FB86C0- > EA9CDA41/0-0/0-0 X-purgate-Ad: For more information about eXpurgate > please visit http://www.expurgate.net/ > 4 th worth enemy > Von: Chinese secrect to weight loss. > Datum: 31. Januar 2009 11:39:36 MEZ > An: > Betreff: How Your Favorite Celebrities Are Losing Those Pounds Fast! > Antwort an: > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Sat, 31 Jan > 2009 11:40:03 +0100 > Received: from 44v7.despiteto.com ([67.227.72.76]) by > mx2.mail.vrmd.de with esmtp (Exim 4.69) (envelope-from >) id 1LTDGd-0004Kz-AP for marc at let.de; Sat, 31 Jan 2009 11:40:03 > +0100 > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Sat, 31 Jan 2009 11:40:03 +0100 > Message-Id: <71224.291541664.1233392803 at despiteto.com> > List-Unsubscribe: > > Mime-Version: 1.0 > Content-Type: multipart/alternative; boundary="291541664.1233392803" > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: 150741::090131114003-418E86C0- > F541CBCD/0-0/0-0 X-purgate-Ad: For more information about eXpurgate > please visit http://www.expurgate.net/ if i had the knowlede i would build something like stormworm., or russian inkaso ping to dead attack service... i am not FOR http://en.wikipedia.org/wiki/Capital_punishment but spammer get 25 years jail in the u.s. ? AND they slow the web down and get RICH from this shit!!! oh mama help just my euro offline contacts welcome greetings from old germany Marc > thanks > > > marc > > > Anfang der weitergeleiteten E-Mail: >> Von: ualadys mailing >> Datum: 31. Januar 2009 08:30:04 MEZ >> An: marc >> Betreff: Weekly Special >> Return-Path: >> Received: from mx1.mail.vrmd.de ([10.0.1.20]) by vm42.mail.vrmd.de >> (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Sat, 31 Jan >> 2009 08:30:06 +0100 >> Received: from mx3.iispp.com ([76.74.167.190]) by mx1.mail.vrmd.de >> with esmtp (Exim 4.69) (envelope-from ) id >> 1LTAIo-0005l7-DA for marc at let.de; Sat, 31 Jan 2009 08:30:06 +0100 >> Received: by mail.iispp.com (Postfix, from userid 1003) id >> A9CC5B7BF05; Sat, 31 Jan 2009 02:30:04 -0500 (EST) >> X-Sieve: CMU Sieve 2.2 >> Envelope-To: marc at let.de >> Delivery-Date: Sat, 31 Jan 2009 08:30:06 +0100 >> Message-Id: <2d1440035a3dcbfc66693621daf32f78 at localhost.localdomain> >> X-Priority: 3 >> X-Mailer: PHPMailer (phpmailer.codeworxtech.com) [version 2.2] >> Mime-Version: 1.0 >> Content-Type: multipart/alternative; >> boundary="b1_2d1440035a3dcbfc66693621daf32f78" >> X-Spam-Suspicion: No >> X-Purgate: Clean X-purgate-ID: 150741::090131083006-569C86C0- >> ACFC0CF4/2502755973-0/0-1 X-purgate-Ad: For more information about >> eXpurgate please visit http://www.expurgate.net/ >> >> >> >> >> Weekly Special! >> >> Thank you for using our services! We would like to make a special >> price offer for our services: >> >> Please choose one of our weekly special offers and get 1 video >> credit for free >> >> This Special Offer will be available for 1 week ONLY! Don?t miss >> your chance to urchase our service for better price! >> >> Ladies' New Videos >> >> From ops.lists at gmail.com Sat Jan 31 07:32:17 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 31 Jan 2009 19:02:17 +0530 Subject: OT: After dozents of spam reportings , still spam from In-Reply-To: <07FEB939-D790-4B62-BB9D-F9AD56E19965@let.de> References: <07FEB939-D790-4B62-BB9D-F9AD56E19965@let.de> Message-ID: On Sat, Jan 31, 2009 at 4:16 PM, marc wrote: > sorry again just for the records and web NANOG archives > You want to archive spam then news.admin.net-abuse.sightings is down the hall, three doors to your left. -srs From beckman at angryox.com Sat Jan 31 08:50:24 2009 From: beckman at angryox.com (Peter Beckman) Date: Sat, 31 Jan 2009 09:50:24 -0500 Subject: All Google Search Results: "This site may harm your computer." Message-ID: This morning whilest Googling, I got a bunch of "Permission Denied" to "/interstitial?..." URLs on Google. Then all my search results got listed as "This site may harm your computer." Is Google broken, or is the functionality of listing sites as broken, broken? http://dl.getdropbox.com/u/423476/google-broken.gif Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From wschultz at bsdboy.com Sat Jan 31 08:56:00 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Sat, 31 Jan 2009 06:56:00 -0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <641A7761-8B96-45C7-A4BF-D1624DA29202@bsdboy.com> Yup, google's gone craaazy. http://farm4.static.flickr.com/3089/3241488702_9a9a994f07.jpg -wil On Jan 31, 2009, at 6:50 AM, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From damin at nacs.net Sat Jan 31 08:56:22 2009 From: damin at nacs.net (Gregory Boehnlein) Date: Sat, 31 Jan 2009 09:56:22 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <000a01c983b4$14f5e120$3ee1a360$@net> > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? I thought I was going nuts, but yes.. same thing here. From any computer I get the same results. From ward at pong.be Sat Jan 31 08:57:10 2009 From: ward at pong.be (Ward Vandewege) Date: Sat, 31 Jan 2009 09:57:10 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <20090131145710.GA9634@localdomain> On Sat, Jan 31, 2009 at 09:50:24AM -0500, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? Yeah, something is very wrong - I see the same thing. Thanks, Ward. -- Pong.be -( Writing software is more fun than working. )- Virtual hosting -( )- http://pong.be -( )- GnuPG public key: http://pgp.mit.edu From adam.young at mountaincable.on.ca Sat Jan 31 08:57:34 2009 From: adam.young at mountaincable.on.ca (Adam Young) Date: Sat, 31 Jan 2009 09:57:34 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <498466DE.6080508@mountaincable.on.ca> Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? Confirmed in Southern Ontario, Canada. -- Adam Young From tme at multicasttech.com Sat Jan 31 09:01:25 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 31 Jan 2009 10:01:25 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> On Jan 31, 2009, at 9:50 AM, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > Yes, I got it for a search link to wikipedia and to my own sites. I am cynical; I would guess that there is some for-pay "web site blessed by Google" certificate coming. Regards Marshall > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From rcorbin at traffiq.com Sat Jan 31 09:02:35 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Sat, 31 Jan 2009 09:02:35 -0600 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <641A7761-8B96-45C7-A4BF-D1624DA29202@bsdboy.com> References: , <641A7761-8B96-45C7-A4BF-D1624DA29202@bsdboy.com> Message-ID: Classic :D http://i39.tinypic.com/ac9qp.jpg -r ________________________________________ From: Wil Schultz [wschultz at bsdboy.com] Sent: Saturday, January 31, 2009 9:56 AM To: NANOG list Subject: Re: All Google Search Results: "This site may harm your computer." Yup, google's gone craaazy. http://farm4.static.flickr.com/3089/3241488702_9a9a994f07.jpg -wil On Jan 31, 2009, at 6:50 AM, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From tme at multicasttech.com Sat Jan 31 09:03:33 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 31 Jan 2009 10:03:33 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <641A7761-8B96-45C7-A4BF-D1624DA29202@bsdboy.com> References: <641A7761-8B96-45C7-A4BF-D1624DA29202@bsdboy.com> Message-ID: <5AB9AE2D-706C-46DF-B515-CE0103E58F3E@multicasttech.com> Also for NANOG : Warning - visiting this web site may harm your computer! Suggestions: ? Return to the previous page and pick another result. ? Try another search to find what you're looking for. Or you can continue to http://www.nanog.org/meetings/nanog44/ at your own risk. For detailed information about the problems we found, visit Google'sSafe Browsing diagnostic page for this site. ----- If you follow the link for diagnostics you get Server ErrorThe server encountered a temporary error and could not complete your request. Please try again in 30 seconds. Regards Marshall On Jan 31, 2009, at 9:56 AM, Wil Schultz wrote: > Yup, google's gone craaazy. > > http://farm4.static.flickr.com/3089/3241488702_9a9a994f07.jpg > > -wil > > On Jan 31, 2009, at 6:50 AM, Peter Beckman wrote: > >> This morning whilest Googling, I got a bunch of "Permission Denied" >> to >> "/interstitial?..." URLs on Google. >> >> Then all my search results got listed as "This site may harm your >> computer." >> >> Is Google broken, or is the functionality of listing sites as broken, >> broken? >> >> http://dl.getdropbox.com/u/423476/google-broken.gif >> >> Beckman >> --------------------------------------------------------------------------- >> Peter Beckman >> Internet Guy >> beckman at angryox.com http://www.angryox.com/ >> --------------------------------------------------------------------------- >> > > From info at linuxmount.com Sat Jan 31 09:04:19 2009 From: info at linuxmount.com (aljuhani) Date: Sat, 31 Jan 2009 18:04:19 +0300 Subject: Google search results leading to google "This site may harm your computer" Message-ID: <20090131150419.F0E8EA5B2DA@riy-m18.saudi.net.sa> Hi. Just trying to search for website then presented with all search each have under the text "This site may harm your computer", when any of search result clicked that lead to a google page headed with "This site may harm your computer" and no further option to proceed. I even tried entering google.com in search and first result of the search was the google search engine with again "This site may harm your computer". any ideas. From fsmendoza at gmail.com Sat Jan 31 09:06:26 2009 From: fsmendoza at gmail.com (Frank) Date: Sat, 31 Jan 2009 23:06:26 +0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <498466DE.6080508@mountaincable.on.ca> References: <498466DE.6080508@mountaincable.on.ca> Message-ID: confirmed. same here manila, philippines. On Sat, Jan 31, 2009 at 10:57 PM, Adam Young wrote: > Peter Beckman wrote: > > This morning whilest Googling, I got a bunch of "Permission Denied" to > > "/interstitial?..." URLs on Google. > > > > Then all my search results got listed as "This site may harm your > > computer." > > > > Is Google broken, or is the functionality of listing sites as broken, > > broken? > > Confirmed in Southern Ontario, Canada. > > -- > Adam Young > > > From jj at diamondtech.ca Sat Jan 31 09:10:08 2009 From: jj at diamondtech.ca (Jeff Johnstone) Date: Sat, 31 Jan 2009 07:10:08 -0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <5AB9AE2D-706C-46DF-B515-CE0103E58F3E@multicasttech.com> References: <641A7761-8B96-45C7-A4BF-D1624DA29202@bsdboy.com> <5AB9AE2D-706C-46DF-B515-CE0103E58F3E@multicasttech.com> Message-ID: <31911cd20901310710v72085a2bnef5b278a4761e2d7@mail.gmail.com> Its spilling over into email processing at gmail now and marking as spam messages that have links that show bad on google search. Interesting Saturday morning..... cheers Jeff On Sat, Jan 31, 2009 at 7:03 AM, Marshall Eubanks wrote: > Also for NANOG : > > Warning - visiting this web site may harm your computer! > Suggestions: > ? Return to the previous page and pick another result. > ? Try another search to find what you're looking for. > Or you can continue to http://www.nanog.org/meetings/nanog44/ at your own > risk. For detailed information about the problems we found, visit > Google'sSafe Browsing diagnostic page for this site. > > ----- > If you follow the link for diagnostics you get > > Server ErrorThe server encountered a temporary error and could not complete > your request. > Please try again in 30 seconds. > > > > Regards > > Marshall > > > > On Jan 31, 2009, at 9:56 AM, Wil Schultz wrote: > > Yup, google's gone craaazy. >> >> http://farm4.static.flickr.com/3089/3241488702_9a9a994f07.jpg >> >> -wil >> >> On Jan 31, 2009, at 6:50 AM, Peter Beckman wrote: >> >> This morning whilest Googling, I got a bunch of "Permission Denied" to >>> "/interstitial?..." URLs on Google. >>> >>> Then all my search results got listed as "This site may harm your >>> computer." >>> >>> Is Google broken, or is the functionality of listing sites as broken, >>> broken? >>> >>> http://dl.getdropbox.com/u/423476/google-broken.gif >>> >>> Beckman >>> >>> --------------------------------------------------------------------------- >>> Peter Beckman Internet >>> Guy >>> beckman at angryox.com >>> http://www.angryox.com/ >>> >>> --------------------------------------------------------------------------- >>> >>> >> >> > > From nenolod at systeminplace.net Sat Jan 31 09:10:48 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 31 Jan 2009 09:10:48 -0600 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <1233414648.10490.134.camel@petrie> On Sat, 2009-01-31 at 09:50 -0500, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? It's broken here. http://petrie.dereferenced.org/~nenolod/googlefailsit.png -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-800-688-5018 From jason at biel-tech.com Sat Jan 31 09:12:00 2009 From: jason at biel-tech.com (Jason Biel) Date: Sat, 31 Jan 2009 09:12:00 -0600 Subject: Google search results leading to google "This site may harm your computer" In-Reply-To: <20090131150419.F0E8EA5B2DA@riy-m18.saudi.net.sa> References: <20090131150419.F0E8EA5B2DA@riy-m18.saudi.net.sa> Message-ID: Looks like they are experiencing some "internal" issue. On Sat, Jan 31, 2009 at 9:04 AM, aljuhani wrote: > Hi. > > Just trying to search for website then presented with all search each have > under the text "This site may harm your computer", when any of search result > clicked that lead to a google page headed with "This site may harm your > computer" and no further option to proceed. > > I even tried entering google.com in search and first result of the search > was the google search engine with again "This site may harm your computer". > > any ideas. > > > -- Jason Biel From brian at meganet.net Sat Jan 31 09:04:30 2009 From: brian at meganet.net (Brian Wallingford) Date: Sat, 31 Jan 2009 10:04:30 -0500 (EST) Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> References: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> Message-ID: Considering the lingering Comcast gig w/the SEC, I can't see that flying well. (Unless they manage to pull a PUC/DTE thing like VZ has done in the past, and manage to get exec(s) placed as commisioner(s)). Because of Google's insanely disproportionate market domination, I don't see them staying under the radar for long if this is the case. But, it could simply be a misconfig on a Friday night... On Sat, 31 Jan 2009, Marshall Eubanks wrote: : :On Jan 31, 2009, at 9:50 AM, Peter Beckman wrote: : :> This morning whilest Googling, I got a bunch of "Permission Denied" to :> "/interstitial?..." URLs on Google. :> :> Then all my search results got listed as "This site may harm your :> computer." :> : :Yes, I got it for a search link to wikipedia and to my own sites. : :I am cynical; I would guess that there is some for-pay "web site :blessed by Google" :certificate coming. : :Regards :Marshall : : :> Is Google broken, or is the functionality of listing sites as broken, :> broken? :> :> http://dl.getdropbox.com/u/423476/google-broken.gif :> :> Beckman :> --------------------------------------------------------------------------- :> Peter Beckman :> Internet Guy :> beckman at angryox.com http://www.angryox.com/ :> --------------------------------------------------------------------------- :> : : : -- ___________________________________ Brian Wallingford Director, Network Operations MegaNet Communications, TCIX, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From somasundaram.s at alcatel-lucent.com Sat Jan 31 09:15:12 2009 From: somasundaram.s at alcatel-lucent.com (S, Somasundaram (Somasundaram)) Date: Sat, 31 Jan 2009 20:45:12 +0530 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <498466DE.6080508@mountaincable.on.ca> Message-ID: <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E7@INBANSXCHMBSA1.in.alcatel-lucent.com> confirmed..here in India too... -----Original Message----- From: Frank [mailto:fsmendoza at gmail.com] Sent: Saturday, January 31, 2009 8:36 PM To: Adam Young Cc: nanog at nanog.org Subject: Re: All Google Search Results: "This site may harm your computer." confirmed. same here manila, philippines. On Sat, Jan 31, 2009 at 10:57 PM, Adam Young wrote: > Peter Beckman wrote: > > This morning whilest Googling, I got a bunch of "Permission Denied" > > to "/interstitial?..." URLs on Google. > > > > Then all my search results got listed as "This site may harm your > > computer." > > > > Is Google broken, or is the functionality of listing sites as > > broken, broken? > > Confirmed in Southern Ontario, Canada. > > -- > Adam Young > > > From bambenek at gmail.com Sat Jan 31 09:15:33 2009 From: bambenek at gmail.com (John C. A. Bambenek) Date: Sat, 31 Jan 2009 09:15:33 -0600 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> References: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> Message-ID: Yeah, google search is broken everywhere in the world right now. http://isc.sans.org On 1/31/09, Marshall Eubanks wrote: > > On Jan 31, 2009, at 9:50 AM, Peter Beckman wrote: > >> This morning whilest Googling, I got a bunch of "Permission Denied" to >> "/interstitial?..." URLs on Google. >> >> Then all my search results got listed as "This site may harm your >> computer." >> > > Yes, I got it for a search link to wikipedia and to my own sites. > > I am cynical; I would guess that there is some for-pay "web site > blessed by Google" > certificate coming. > > Regards > Marshall > > >> Is Google broken, or is the functionality of listing sites as broken, >> broken? >> >> http://dl.getdropbox.com/u/423476/google-broken.gif >> >> Beckman >> --------------------------------------------------------------------------- >> Peter Beckman >> Internet Guy >> beckman at angryox.com >> http://www.angryox.com/ >> --------------------------------------------------------------------------- >> > > > -- Sent from my mobile device From Steven.Glogger at swisscom.com Sat Jan 31 09:16:02 2009 From: Steven.Glogger at swisscom.com (Steven.Glogger at swisscom.com) Date: Sat, 31 Jan 2009 16:16:02 +0100 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <621703B5-9D3B-48EF-825F-F674E3D227B1@swisscom.com> References: <498466DE.6080508@mountaincable.on.ca> <621703B5-9D3B-48EF-825F-F674E3D227B1@swisscom.com> Message-ID: <96336C36-A256-4099-812E-2263D1CC2683@swisscom.com> seems to be a global problem. even here in switzerland... i barely hear already "the internet is broken":) -steven > > Am 31.01.2009 um 16:02 schrieb "Adam Young" > : > >> Peter Beckman wrote: >>> This morning whilest Googling, I got a bunch of "Permission Denied" >>> to >>> "/interstitial?..." URLs on Google. >>> >>> Then all my search results got listed as "This site may harm your >>> computer." >>> >>> Is Google broken, or is the functionality of listing sites as >>> broken, >>> broken? >> >> Confirmed in Southern Ontario, Canada. >> >> -- >> Adam Young >> >> From Bourbon.Odenthal at sce.com Sat Jan 31 09:16:34 2009 From: Bourbon.Odenthal at sce.com (Bourbon.Odenthal at sce.com) Date: Sat, 31 Jan 2009 07:16:34 -0800 Subject: All Google Search Results: "This site may harm your computer." Message-ID: Interesting...its happening in Los Angeles using my Verizon Blackberry but not on the ATT iPhone. -bb ----- Original Message ----- From: Frank [fsmendoza at gmail.com] Sent: 01/31/2009 11:06 PM ZE8 To: Adam Young Cc: nanog at nanog.org Subject: Re: All Google Search Results: "This site may harm your computer." confirmed. same here manila, philippines. On Sat, Jan 31, 2009 at 10:57 PM, Adam Young wrote: > Peter Beckman wrote: > > This morning whilest Googling, I got a bunch of "Permission Denied" to > > "/interstitial?..." URLs on Google. > > > > Then all my search results got listed as "This site may harm your > > computer." > > > > Is Google broken, or is the functionality of listing sites as broken, > > broken? > > Confirmed in Southern Ontario, Canada. > > -- > Adam Young > > > From neito at nerdramblingz.com Sat Jan 31 09:18:50 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Sat, 31 Jan 2009 10:18:50 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <498466DE.6080508@mountaincable.on.ca> Message-ID: Not only that, but the gMail logo is missing from my gMail for Domains page. On Sat, Jan 31, 2009 at 10:06 AM, Frank wrote: > confirmed. same here manila, philippines. > > On Sat, Jan 31, 2009 at 10:57 PM, Adam Young > wrote: > >> Peter Beckman wrote: >> > This morning whilest Googling, I got a bunch of "Permission Denied" to >> > "/interstitial?..." URLs on Google. >> > >> > Then all my search results got listed as "This site may harm your >> > computer." >> > >> > Is Google broken, or is the functionality of listing sites as broken, >> > broken? >> >> Confirmed in Southern Ontario, Canada. >> >> -- >> Adam Young >> >> >> > From casfre at gmail.com Sat Jan 31 09:19:24 2009 From: casfre at gmail.com (casfre at gmail.com) Date: Sat, 31 Jan 2009 13:19:24 -0200 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <1233414648.10490.134.camel@petrie> References: <1233414648.10490.134.camel@petrie> Message-ID: > >> Is Google broken, or is the functionality of listing sites as broken, >> broken? > > It's broken here. > http://petrie.dereferenced.org/~nenolod/googlefailsit.png Same here, in Brazil. Weird. Regards, C?ssio From leothelion.murtaza at gmail.com Sat Jan 31 09:25:29 2009 From: leothelion.murtaza at gmail.com (Murtaza) Date: Sat, 31 Jan 2009 20:25:29 +0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <498466DE.6080508@mountaincable.on.ca> <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E7@INBANSXCHMBSA1.in.alcatel-lucent.com> Message-ID: <949b74980901310725h2a0160bandb243aee3134a372@mail.gmail.com> fine in Pakistan..... On Sat, Jan 31, 2009 at 8:15 PM, S, Somasundaram (Somasundaram) < somasundaram.s at alcatel-lucent.com> wrote: > confirmed..here in India too... > > -----Original Message----- > From: Frank [mailto:fsmendoza at gmail.com] > Sent: Saturday, January 31, 2009 8:36 PM > To: Adam Young > Cc: nanog at nanog.org > Subject: Re: All Google Search Results: "This site may harm your computer." > > confirmed. same here manila, philippines. > > On Sat, Jan 31, 2009 at 10:57 PM, Adam Young < > adam.young at mountaincable.on.ca > > wrote: > > > Peter Beckman wrote: > > > This morning whilest Googling, I got a bunch of "Permission Denied" > > > to "/interstitial?..." URLs on Google. > > > > > > Then all my search results got listed as "This site may harm your > > > computer." > > > > > > Is Google broken, or is the functionality of listing sites as > > > broken, broken? > > > > Confirmed in Southern Ontario, Canada. > > > > -- > > Adam Young > > > > > > > > -- Ghulam Murtaza Lahore University of Management Sciences From wschultz at bsdboy.com Sat Jan 31 09:29:20 2009 From: wschultz at bsdboy.com (Wil Schultz) Date: Sat, 31 Jan 2009 07:29:20 -0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <96336C36-A256-4099-812E-2263D1CC2683@swisscom.com> References: <498466DE.6080508@mountaincable.on.ca> <621703B5-9D3B-48EF-825F-F674E3D227B1@swisscom.com> <96336C36-A256-4099-812E-2263D1CC2683@swisscom.com> Message-ID: Just cleared up here in the Bay Area, California. -wil On Jan 31, 2009, at 7:16 AM, Steven.Glogger at swisscom.com wrote: > seems to be a global problem. even here in switzerland... i barely > hear already "the internet is broken":) > > > -steven > > >> >> Am 31.01.2009 um 16:02 schrieb "Adam Young" >> : >> >>> Peter Beckman wrote: >>>> This morning whilest Googling, I got a bunch of "Permission Denied" >>>> to >>>> "/interstitial?..." URLs on Google. >>>> >>>> Then all my search results got listed as "This site may harm your >>>> computer." >>>> >>>> Is Google broken, or is the functionality of listing sites as >>>> broken, >>>> broken? >>> >>> Confirmed in Southern Ontario, Canada. >>> >>> -- >>> Adam Young >>> >>> > From bambenek at gmail.com Sat Jan 31 09:32:33 2009 From: bambenek at gmail.com (John C. A. Bambenek) Date: Sat, 31 Jan 2009 09:32:33 -0600 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <498466DE.6080508@mountaincable.on.ca> Message-ID: Error is fixed and seems to be propogating to resolution On 1/31/09, Nathan Malynn wrote: > Not only that, but the gMail logo is missing from my gMail for Domains page. > > On Sat, Jan 31, 2009 at 10:06 AM, Frank wrote: >> confirmed. same here manila, philippines. >> >> On Sat, Jan 31, 2009 at 10:57 PM, Adam Young >> >> wrote: >> >>> Peter Beckman wrote: >>> > This morning whilest Googling, I got a bunch of "Permission Denied" to >>> > "/interstitial?..." URLs on Google. >>> > >>> > Then all my search results got listed as "This site may harm your >>> > computer." >>> > >>> > Is Google broken, or is the functionality of listing sites as broken, >>> > broken? >>> >>> Confirmed in Southern Ontario, Canada. >>> >>> -- >>> Adam Young >>> >>> >>> >> > > -- Sent from my mobile device From pstewart at nexicomgroup.net Sat Jan 31 09:31:51 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sat, 31 Jan 2009 10:31:51 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <96336C36-A256-4099-812E-2263D1CC2683@swisscom.com> References: <498466DE.6080508@mountaincable.on.ca><621703B5-9D3B-48EF-825F-F674E3D227B1@swisscom.com> <96336C36-A256-4099-812E-2263D1CC2683@swisscom.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01F7FEA6@nexus.nexicomgroup.net> Yeah, weird here.... if I'm logged in everything works - if I logout stuff breaks.. at least to google.ca (southern Ontario as well). -----Original Message----- From: Steven.Glogger at swisscom.com [mailto:Steven.Glogger at swisscom.com] Sent: January 31, 2009 10:16 AM To: nanog at nanog.org Subject: Re: All Google Search Results: "This site may harm your computer." seems to be a global problem. even here in switzerland... i barely hear already "the internet is broken":) -steven > > Am 31.01.2009 um 16:02 schrieb "Adam Young" > : > >> Peter Beckman wrote: >>> This morning whilest Googling, I got a bunch of "Permission Denied" >>> to >>> "/interstitial?..." URLs on Google. >>> >>> Then all my search results got listed as "This site may harm your >>> computer." >>> >>> Is Google broken, or is the functionality of listing sites as >>> broken, >>> broken? >> >> Confirmed in Southern Ontario, Canada. >> >> -- >> Adam Young >> >> ---------------------------------------------------------------------------- "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." From info at linuxmount.com Sat Jan 31 09:34:33 2009 From: info at linuxmount.com (aljuhani) Date: Sat, 31 Jan 2009 18:34:33 +0300 Subject: Google search results leading to google "This site may harm your computer" Message-ID: <20090131153434.1365EA5B293@riy-m18.saudi.net.sa> Now clicking search results forward to "service unavailable" page within google. The error message about the site may harm your computer is also displayed in Arabic on google Saudi Arabia, www.google.com.sa image here: http://ns.mx04.com/google-sa.jpg looks like the whole database is gone! ..... Yahoo! search engine seem to be working fine as looks have no affiliation with google ----- Original Message ----- From: Jason Biel To: info at linuxmount.com Cc: nanog Sent: Saturday, January 31, 2009 18:12 Subject: Re: Google search results leading to google "This site may harm your computer" Looks like they are experiencing some "internal" issue. From tme at multicasttech.com Sat Jan 31 09:35:20 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 31 Jan 2009 10:35:20 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <1233414648.10490.134.camel@petrie> Message-ID: <9AE71D48-7238-49F9-8346-1C3829825115@multicasttech.com> The reports I am getting (and my direct observation) is that it is now fixed. Marshall On Jan 31, 2009, at 10:19 AM, casfre at gmail.com wrote: >> >>> Is Google broken, or is the functionality of listing sites as >>> broken, >>> broken? >> >> It's broken here. >> http://petrie.dereferenced.org/~nenolod/googlefailsit.png > > Same here, in Brazil. Weird. > > Regards, > > C?ssio > From neito at nerdramblingz.com Sat Jan 31 09:37:28 2009 From: neito at nerdramblingz.com (Nathan Malynn) Date: Sat, 31 Jan 2009 10:37:28 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <949b74980901310725h2a0160bandb243aee3134a372@mail.gmail.com> References: <498466DE.6080508@mountaincable.on.ca> <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E7@INBANSXCHMBSA1.in.alcatel-lucent.com> <949b74980901310725h2a0160bandb243aee3134a372@mail.gmail.com> Message-ID: Google's back on my connection on Verizon in the Northeast US. On Sat, Jan 31, 2009 at 10:25 AM, Murtaza wrote: > fine in Pakistan..... > > On Sat, Jan 31, 2009 at 8:15 PM, S, Somasundaram (Somasundaram) < > somasundaram.s at alcatel-lucent.com> wrote: > >> confirmed..here in India too... >> >> -----Original Message----- >> From: Frank [mailto:fsmendoza at gmail.com] >> Sent: Saturday, January 31, 2009 8:36 PM >> To: Adam Young >> Cc: nanog at nanog.org >> Subject: Re: All Google Search Results: "This site may harm your computer." >> >> confirmed. same here manila, philippines. >> >> On Sat, Jan 31, 2009 at 10:57 PM, Adam Young < >> adam.young at mountaincable.on.ca >> > wrote: >> >> > Peter Beckman wrote: >> > > This morning whilest Googling, I got a bunch of "Permission Denied" >> > > to "/interstitial?..." URLs on Google. >> > > >> > > Then all my search results got listed as "This site may harm your >> > > computer." >> > > >> > > Is Google broken, or is the functionality of listing sites as >> > > broken, broken? >> > >> > Confirmed in Southern Ontario, Canada. >> > >> > -- >> > Adam Young >> > >> > >> > >> >> > > > -- > Ghulam Murtaza > Lahore University of Management Sciences > From somasundaram.s at alcatel-lucent.com Sat Jan 31 09:39:40 2009 From: somasundaram.s at alcatel-lucent.com (S, Somasundaram (Somasundaram)) Date: Sat, 31 Jan 2009 21:09:40 +0530 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <498466DE.6080508@mountaincable.on.ca> <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E7@INBANSXCHMBSA1.in.alcatel-lucent.com> <949b74980901310725h2a0160bandb243aee3134a372@mail.gmail.com> Message-ID: <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E8@INBANSXCHMBSA1.in.alcatel-lucent.com> google;s back on India too!!! -----Original Message----- From: Nathan Malynn [mailto:neito at nerdramblingz.com] Sent: Saturday, January 31, 2009 9:07 PM To: Murtaza Cc: S, Somasundaram (Somasundaram); nanog at nanog.org Subject: Re: All Google Search Results: "This site may harm your computer." Google's back on my connection on Verizon in the Northeast US. On Sat, Jan 31, 2009 at 10:25 AM, Murtaza wrote: > fine in Pakistan..... > > On Sat, Jan 31, 2009 at 8:15 PM, S, Somasundaram (Somasundaram) < > somasundaram.s at alcatel-lucent.com> wrote: > >> confirmed..here in India too... >> >> -----Original Message----- >> From: Frank [mailto:fsmendoza at gmail.com] >> Sent: Saturday, January 31, 2009 8:36 PM >> To: Adam Young >> Cc: nanog at nanog.org >> Subject: Re: All Google Search Results: "This site may harm your computer." >> >> confirmed. same here manila, philippines. >> >> On Sat, Jan 31, 2009 at 10:57 PM, Adam Young < >> adam.young at mountaincable.on.ca >> > wrote: >> >> > Peter Beckman wrote: >> > > This morning whilest Googling, I got a bunch of "Permission Denied" >> > > to "/interstitial?..." URLs on Google. >> > > >> > > Then all my search results got listed as "This site may harm your >> > > computer." >> > > >> > > Is Google broken, or is the functionality of listing sites as >> > > broken, broken? >> > >> > Confirmed in Southern Ontario, Canada. >> > >> > -- >> > Adam Young >> > >> > >> > >> >> > > > -- > Ghulam Murtaza > Lahore University of Management Sciences > From info at linuxmount.com Sat Jan 31 09:52:15 2009 From: info at linuxmount.com (aljuhani) Date: Sat, 31 Jan 2009 18:52:15 +0300 Subject: All Google Search Results: "This site may harm your computer." Message-ID: <20090131155217.E2882A5B2BC@riy-m18.saudi.net.sa> Google back to norms here, Saudi Arabia. Just wondering, how could something of this nature goes un-monitored by google.... ! -aljuhani ----- Original Message ----- From: "Nathan Malynn" To: "Murtaza" Cc: Sent: Saturday, January 31, 2009 18:37 Subject: Re: All Google Search Results: "This site may harm your computer." | Google's back on my connection on Verizon in the Northeast US. | | On Sat, Jan 31, 2009 at 10:25 AM, Murtaza wrote: | > fine in Pakistan..... | > | > On Sat, Jan 31, 2009 at 8:15 PM, S, Somasundaram (Somasundaram) < | > somasundaram.s at alcatel-lucent.com> wrote: | > | >> confirmed..here in India too... | >> | >> -----Original Message----- | >> From: Frank [mailto:fsmendoza at gmail.com] | >> Sent: Saturday, January 31, 2009 8:36 PM | >> To: Adam Young | >> Cc: nanog at nanog.org | >> Subject: Re: All Google Search Results: "This site may harm your computer." | >> | >> confirmed. same here manila, philippines. | >> | >> On Sat, Jan 31, 2009 at 10:57 PM, Adam Young < | >> adam.young at mountaincable.on.ca | >> > wrote: | >> | >> > Peter Beckman wrote: | >> > > This morning whilest Googling, I got a bunch of "Permission Denied" | >> > > to "/interstitial?..." URLs on Google. | >> > > | >> > > Then all my search results got listed as "This site may harm your | >> > > computer." | >> > > | >> > > Is Google broken, or is the functionality of listing sites as | >> > > broken, broken? | >> > | >> > Confirmed in Southern Ontario, Canada. | >> > | >> > -- | >> > Adam Young | >> > | >> > | >> > | >> | >> | > | > | > -- | > Ghulam Murtaza | > Lahore University of Management Sciences | > | | From ops.lists at gmail.com Sat Jan 31 09:56:47 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 31 Jan 2009 21:26:47 +0530 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <20090131155217.E2882A5B2BC@riy-m18.saudi.net.sa> References: <20090131155217.E2882A5B2BC@riy-m18.saudi.net.sa> Message-ID: On Sat, Jan 31, 2009 at 9:22 PM, aljuhani wrote: > Google back to norms here, Saudi Arabia. > > Just wondering, how could something of this nature goes un-monitored by google.... ! If it was unmonitored .. what do you think, would it have got fixed within minutes? --srs From anderson at cbn.net.id Sat Jan 31 09:58:41 2009 From: anderson at cbn.net.id (Anderson Lumbantobing) Date: Sat, 31 Jan 2009 22:58:41 +0700 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E8@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <498466DE.6080508@mountaincable.on.ca> <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E7@INBANSXCHMBSA1.in.alcatel-lucent.com> <949b74980901310725h2a0160bandb243aee3134a372@mail.gmail.com> <7E79416ABDDDFC4E8C85571D0B5CAB3F010F8800E8@INBANSXCHMBSA1.in.alcatel-lucent.com> Message-ID: <49847531.8070106@cbn.net.id> Done on Indonesia... S, Somasundaram (Somasundaram) wrote: > google;s back on India too!!! > > -----Original Message----- > From: Nathan Malynn [mailto:neito at nerdramblingz.com] > Sent: Saturday, January 31, 2009 9:07 PM > To: Murtaza > Cc: S, Somasundaram (Somasundaram); nanog at nanog.org > Subject: Re: All Google Search Results: "This site may harm your computer." > > Google's back on my connection on Verizon in the Northeast US. > > On Sat, Jan 31, 2009 at 10:25 AM, Murtaza wrote: > >> fine in Pakistan..... >> >> On Sat, Jan 31, 2009 at 8:15 PM, S, Somasundaram (Somasundaram) < >> somasundaram.s at alcatel-lucent.com> wrote: >> >> >>> confirmed..here in India too... >>> >>> -----Original Message----- >>> From: Frank [mailto:fsmendoza at gmail.com] >>> Sent: Saturday, January 31, 2009 8:36 PM >>> To: Adam Young >>> Cc: nanog at nanog.org >>> Subject: Re: All Google Search Results: "This site may harm your computer." >>> >>> confirmed. same here manila, philippines. >>> >>> On Sat, Jan 31, 2009 at 10:57 PM, Adam Young < >>> adam.young at mountaincable.on.ca >>> >>>> wrote: >>>> >>>> Peter Beckman wrote: >>>> >>>>> This morning whilest Googling, I got a bunch of "Permission Denied" >>>>> to "/interstitial?..." URLs on Google. >>>>> >>>>> Then all my search results got listed as "This site may harm your >>>>> computer." >>>>> >>>>> Is Google broken, or is the functionality of listing sites as >>>>> broken, broken? >>>>> >>>> Confirmed in Southern Ontario, Canada. >>>> >>>> -- >>>> Adam Young >>>> >>>> >>>> >>>> >>> >> -- >> Ghulam Murtaza >> Lahore University of Management Sciences >> >> > > > -- regards Anderson Lumbantobing eMail: anderson at cbn.net.id From tme at multicasttech.com Sat Jan 31 10:01:59 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 31 Jan 2009 11:01:59 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <20090131155217.E2882A5B2BC@riy-m18.saudi.net.sa> Message-ID: <29A61767-8919-4C51-B1A3-D2FDC6409161@multicasttech.com> On Jan 31, 2009, at 10:56 AM, Suresh Ramasubramanian wrote: > On Sat, Jan 31, 2009 at 9:22 PM, aljuhani wrote: >> Google back to norms here, Saudi Arabia. >> >> Just wondering, how could something of this nature goes un- >> monitored by google.... ! > > If it was unmonitored .. what do you think, would it have got fixed > within minutes? > Who needs monitoring when you can just scan NANOG ? Regards Marshall > --srs > From info at linuxmount.com Sat Jan 31 10:02:58 2009 From: info at linuxmount.com (aljuhani) Date: Sat, 31 Jan 2009 19:02:58 +0300 Subject: All Google Search Results: "This site may harm your computer." Message-ID: <20090131160257.D34B0A5B281@riy-m18.saudi.net.sa> ----- Original Message ----- From: "Suresh Ramasubramanian" To: Cc: "nanog" Sent: Saturday, January 31, 2009 18:56 Subject: Re: All Google Search Results: "This site may harm your computer." | On Sat, Jan 31, 2009 at 9:22 PM, aljuhani wrote: | > Google back to norms here, Saudi Arabia. | > | > Just wondering, how could something of this nature goes un-monitored by google.... ! | | If it was unmonitored .. what do you think, would it have got fixed | within minutes? | | --srs | The meaning was that the root cause "which went un-monitored" that led to this condition. I was surprised by such given the company size, experience and resources available but will wait and see if press release comes up explaining this issue. cheers -aljuhani From ops.lists at gmail.com Sat Jan 31 10:06:26 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 31 Jan 2009 21:36:26 +0530 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <29A61767-8919-4C51-B1A3-D2FDC6409161@multicasttech.com> References: <20090131155217.E2882A5B2BC@riy-m18.saudi.net.sa> <29A61767-8919-4C51-B1A3-D2FDC6409161@multicasttech.com> Message-ID: On Sat, Jan 31, 2009 at 9:31 PM, Marshall Eubanks wrote: > > Who needs monitoring when you can just scan NANOG ? > Oh, we're the NA*NOC* now? From a.harrowell at gmail.com Sat Jan 31 10:12:13 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Sat, 31 Jan 2009 16:12:13 +0000 Subject: Google search results leading to google "This site may harm your computer" In-Reply-To: <20090131153434.1365EA5B293@riy-m18.saudi.net.sa> References: <20090131153434.1365EA5B293@riy-m18.saudi.net.sa> Message-ID: GMail classified this as phishing. On Sat, Jan 31, 2009 at 3:34 PM, aljuhani wrote: > > Now clicking search results forward to "service unavailable" page within > google. > > The error message about the site may harm your computer is also displayed > in Arabic on google Saudi Arabia, www.google.com.sa > > image here: http://ns.mx04.com/google-sa.jpg > > looks like the whole database is gone! ..... Yahoo! search engine seem to > be working fine as looks have no affiliation with google > > ----- Original Message ----- > From: Jason Biel > To: info at linuxmount.com > Cc: nanog > Sent: Saturday, January 31, 2009 18:12 > Subject: Re: Google search results leading to google "This site may harm > your computer" > > > Looks like they are experiencing some "internal" issue. > > > > > From info at linuxmount.com Sat Jan 31 10:24:31 2009 From: info at linuxmount.com (aljuhani) Date: Sat, 31 Jan 2009 19:24:31 +0300 Subject: Google search results leading to google "This site may harm your computer" Message-ID: <20090131162432.2BF87A5B29D@riy-m18.saudi.net.sa> Thanks for the notice. Possibly because of the URL contained in the message and/or as appear to be in html format as composed initially under OE and the copied to another mail client. Gmail support notice: http://mail.google.com/support/bin/answer.py?hl=en&answer=8253 If our system flags a message as phishing, but you've validated the source from which the message originated, click the down arrow next to Reply at the top-right of the message pane, and select Report Not Phishing to let us know the message is legitimate. And if you receive a message that our phishing detection system doesn't pick up on, click Report Phishing to send a copy of the message to the Gmail Team. -aljuhani ----- Original Message ----- From: Alexander Harrowell To: info at linuxmount.com Cc: nanog Sent: Saturday, January 31, 2009 19:12 Subject: Re: Google search results leading to google "This site may harm your computer" GMail classified this as phishing. On Sat, Jan 31, 2009 at 3:34 PM, aljuhani wrote: Now clicking search results forward to "service unavailable" page within google. The error message about the site may harm your computer is also displayed in Arabic on google Saudi Arabia, www.google.com.sa image here: http://ns.mx04.com/google-sa.jpg looks like the whole database is gone! ..... Yahoo! search engine seem to be working fine as looks have no affiliation with google From info at linuxmount.com Sat Jan 31 11:04:49 2009 From: info at linuxmount.com (aljuhani) Date: Sat, 31 Jan 2009 20:04:49 +0300 Subject: News on Google fault Message-ID: <20090131170449.28040A5B266@riy-m18.saudi.net.sa> Washington Post: Google: This Internet May Harm Your Computer: A glitch in a computer security program embedded deeply into Google's search engine briefly prevented users of the popular search engine from visiting any Web sites turned up in search results this morning. Instead, Google users were redirected to page that warned: "This site may harm your computer." ---also--- Update, 11:46 a.m.: Stopbadware.org, the consortium of industry and academia leaders that handles the database of sites Google lists as harmful, issued the following statement: "This morning, an apparent glitch at Google caused nearly every [update 11:44 am] search listing to carry the "Warning! This site may harm your computer" message. Users who attempted to click through the results saw the "interstitial" warning page that mentions the possibility of badware and refers people to StopBadware.org for more information. This led to a denial of service of our website, as millions of Google users attempted to visit our site for more information. We are working now to bring the site back up. We are also awaiting word from Google about what happened to cause the false warnings." ---full news link: http://voices.washingtonpost.com/securityfix/2009/01/google_this_internet_will_harm.html?wprss=securityfix -aljuhani From vgill at vijaygill.com Sat Jan 31 11:19:04 2009 From: vgill at vijaygill.com (vijay gill) Date: Sat, 31 Jan 2009 09:19:04 -0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> References: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> Message-ID: <21ef2c1c0901310919o47adfbe6n895ae543d120a564@mail.gmail.com> On Sat, Jan 31, 2009 at 7:01 AM, Marshall Eubanks wrote: > > On Jan 31, 2009, at 9:50 AM, Peter Beckman wrote: > > This morning whilest Googling, I got a bunch of "Permission Denied" to >> "/interstitial?..." URLs on Google. >> >> Then all my search results got listed as "This site may harm your >> computer." >> >> > Yes, I got it for a search link to wikipedia and to my own sites. > > I am cynical; I would guess that there is some for-pay "web site blessed by > Google" > certificate coming. http://zapatopi.net/afdb/build.html works for me, I believe it may also work for you. /vijay > > > Regards > Marshall > > > > Is Google broken, or is the functionality of listing sites as broken, >> broken? >> >> http://dl.getdropbox.com/u/423476/google-broken.gif >> >> Beckman >> >> --------------------------------------------------------------------------- >> Peter Beckman Internet >> Guy >> beckman at angryox.com >> http://www.angryox.com/ >> >> --------------------------------------------------------------------------- >> >> > > From tme at multicasttech.com Sat Jan 31 11:27:33 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 31 Jan 2009 12:27:33 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <21ef2c1c0901310919o47adfbe6n895ae543d120a564@mail.gmail.com> References: <2E4139DF-8BA9-4866-85ED-F8DCA681E7D5@multicasttech.com> <21ef2c1c0901310919o47adfbe6n895ae543d120a564@mail.gmail.com> Message-ID: <84A6B404-16F0-43BE-84C8-4D8BEE267D44@multicasttech.com> On Jan 31, 2009, at 12:19 PM, vijay gill wrote: > > > On Sat, Jan 31, 2009 at 7:01 AM, Marshall Eubanks > wrote: > > On Jan 31, 2009, at 9:50 AM, Peter Beckman wrote: > > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > > Yes, I got it for a search link to wikipedia and to my own sites. > > I am cynical; I would guess that there is some for-pay "web site > blessed by Google" > certificate coming. > > > http://zapatopi.net/afdb/build.html works for me, I believe it may > also work for you. Aluminium foil will certainly block RFID's, so they may become a fashion statement soon enough. Marshall > > > /vijay > > > > Regards > Marshall > > > > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman > Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > > > > From damian at google.com Sat Jan 31 11:31:55 2009 From: damian at google.com (Damian Menscher) Date: Sat, 31 Jan 2009 09:31:55 -0800 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <6c98f4060901310931l450aaef4s630af8a40afaee93@mail.gmail.com> FYI, the official explanation has been posted: http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html Damian On Sat, Jan 31, 2009 at 6:50 AM, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > > -- Damian Menscher :: Security Reliability Engineer :: Google :: +1.650.253.2757 From frnkblk at iname.com Sat Jan 31 12:23:25 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 31 Jan 2009 12:23:25 -0600 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <6c98f4060901310931l450aaef4s630af8a40afaee93@mail.gmail.com> References: <6c98f4060901310931l450aaef4s630af8a40afaee93@mail.gmail.com> Message-ID: Sounds like a whitelist of URLs to check against the blacklist would be appropriate here. I know that content-filtering company 8e6 had a problem over 2 years ago with some good well-known sites. Somewhere around that time they hardcoded categories for the top 500 sites, so that if something slipped through the cracks again, the impact would be smaller. Frank -----Original Message----- From: Damian Menscher [mailto:damian at google.com] Sent: Saturday, January 31, 2009 11:32 AM To: Peter Beckman Cc: nanog at nanog.org Subject: Re: All Google Search Results: "This site may harm your computer." FYI, the official explanation has been posted: http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.h tml Damian On Sat, Jan 31, 2009 at 6:50 AM, Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > > -- Damian Menscher :: Security Reliability Engineer :: Google :: +1.650.253.2757 From karnaugh at karnaugh.za.net Sat Jan 31 15:18:14 2009 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Sat, 31 Jan 2009 23:18:14 +0200 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: Message-ID: <4984C016.6010508@karnaugh.za.net> On 2009/01/31 04:50 PM Peter Beckman wrote: > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? You know, I recently started turning off safe-site checks to stopbadware. Never mind this incident, I've noticed *a lot* of sites getting blocked arbitrarily. Checking the site for reasons gives only the most tenuous reasoning, and on a number of occasions misspellings of the site I was actually visiting (as in, it was blocking the site I wanted based on a similarly or misspelt version being bad). I do think Firefox for one misappropriates the accuracy of the system. Essentially it is allowing one site to dictate what their users can view. Anyway, my 2c rant on web blacklists.. From hrlinneweh at sbcglobal.net Sat Jan 31 15:40:20 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Sat, 31 Jan 2009 13:40:20 -0800 (PST) Subject: All Google Search Results: "This site may harm your computer." References: Message-ID: <501016.78297.qm@web82903.mail.mud.yahoo.com> I think they clarify what happened here and are pretty straight up about it. http://www.nytimes.com/2009/02/01/technology/internet/01google.html?hp -henry ________________________________ From: Peter Beckman To: nanog at nanog.org Sent: Saturday, January 31, 2009 6:50:24 AM Subject: All Google Search Results: "This site may harm your computer." This morning whilest Googling, I got a bunch of "Permission Denied" to "/interstitial?..." URLs on Google. Then all my search results got listed as "This site may harm your computer." Is Google broken, or is the functionality of listing sites as broken, broken? http://dl.getdropbox.com/u/423476/google-broken.gif Beckman --------------------------------------------------------------------------- Peter Beckman? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Internet Guy beckman at angryox.com? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.angryox.com/ --------------------------------------------------------------------------- From mpetach at netflight.com Sat Jan 31 17:11:30 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 31 Jan 2009 15:11:30 -0800 Subject: Google search results leading to google "This site may harm your computer" In-Reply-To: <20090131153434.1365EA5B293@riy-m18.saudi.net.sa> References: <20090131153434.1365EA5B293@riy-m18.saudi.net.sa> Message-ID: <63ac96a50901311511o694cd404h86dde90b4dff2524@mail.gmail.com> On 1/31/09, aljuhani wrote: > > Now clicking search results forward to "service unavailable" page within google. ... > Yahoo! search engine seem to be working fine as looks have no affiliation with google That would be correct; the Yahoo Search engine is not affiliated with Google, and was a perfectly acceptable alternative for people needing to perform searches while Google was down. Thankfully, there's more than one company providing essential services such as search for the Internet, so that we don't have to worry about Google being a single point of failure in instances like this. Matt just another happy yahoo user ;-P From gds at gds.best.vwh.net Sat Jan 31 17:53:19 2009 From: gds at gds.best.vwh.net (Greg Skinner) Date: Sat, 31 Jan 2009 23:53:19 +0000 Subject: Google search results leading to google "This site may harm your computer" In-Reply-To: <63ac96a50901311511o694cd404h86dde90b4dff2524@mail.gmail.com>; from mpetach@netflight.com on Sat, Jan 31, 2009 at 03:11:30PM -0800 References: <20090131153434.1365EA5B293@riy-m18.saudi.net.sa> <63ac96a50901311511o694cd404h86dde90b4dff2524@mail.gmail.com> Message-ID: <20090131235319.A26489@gds.best.vwh.net> On Sat, Jan 31, 2009 at 03:11:30PM -0800, Matthew Petach wrote: > On 1/31/09, aljuhani wrote: > > > > Now clicking search results forward to "service unavailable" page within google. > ... > > Yahoo! search engine seem to be working fine as looks have no affiliation with google > > That would be correct; the Yahoo Search engine is not affiliated with Google, > and was a perfectly acceptable alternative for people needing to perform > searches while Google was down. Thankfully, there's more than one company > providing essential services such as search for the Internet, so that we don't > have to worry about Google being a single point of failure in > instances like this. > > Matt > just another happy yahoo user ;-P Competition is good. It keeps us all on our toes. --gregbo From securinate at gmail.com Sat Jan 31 23:23:06 2009 From: securinate at gmail.com (Chris Mills) Date: Sun, 1 Feb 2009 00:23:06 -0500 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: <501016.78297.qm@web82903.mail.mud.yahoo.com> References: <501016.78297.qm@web82903.mail.mud.yahoo.com> Message-ID: Anyone seeing phishing alerts for senders in this thread? http://farm4.static.flickr.com/3080/3243440012_d1f6f1e5e7_o.png -Chris On Sat, Jan 31, 2009 at 4:40 PM, Henry Linneweh wrote: > I think they clarify what happened here and are pretty straight up about > it. > http://www.nytimes.com/2009/02/01/technology/internet/01google.html?hp > > -henry > > > > > ________________________________ > From: Peter Beckman > To: nanog at nanog.org > Sent: Saturday, January 31, 2009 6:50:24 AM > Subject: All Google Search Results: "This site may harm your computer." > > This morning whilest Googling, I got a bunch of "Permission Denied" to > "/interstitial?..." URLs on Google. > > Then all my search results got listed as "This site may harm your > computer." > > Is Google broken, or is the functionality of listing sites as broken, > broken? > > http://dl.getdropbox.com/u/423476/google-broken.gif > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From andrew.wallace at rocketmail.com Sat Jan 31 23:32:00 2009 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sun, 1 Feb 2009 05:32:00 +0000 Subject: All Google Search Results: "This site may harm your computer." In-Reply-To: References: <501016.78297.qm@web82903.mail.mud.yahoo.com> Message-ID: <4b6ee9310901312132x46e1b377i2f1b6022e6a2ccd3@mail.gmail.com> On Sun, Feb 1, 2009 at 5:23 AM, Chris Mills wrote: > Anyone seeing phishing alerts for senders in this thread? > > http://farm4.static.flickr.com/3080/3243440012_d1f6f1e5e7_o.png > > -Chris Yes.