From rbf+nanog at panix.com Sat Jun 1 00:30:28 2013 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Fri, 31 May 2013 19:30:28 -0500 Subject: Headscratcher of the week In-Reply-To: <51A92352.3000906@tiedyenetworks.com> References: <51A92352.3000906@tiedyenetworks.com> Message-ID: <20130601003027.GA10433@panix.com> On Fri, May 31, 2013 at 03:25:22PM -0700, Mike wrote: > Gang, > > In the interest of sharing 'the weird stuff' which makes the job of > being an operator ... uh, fun? is that the right word?..., I would > like to present the following two smokeping latency/packetloss > plots, which are by far the weirdest I have ever seen. > > These plots are from our smokeping host out to a customer location. > The customer is connected via DSL and they run PPPoE over it to > connect with our access concentrator. There is about 5 physical > insfastructure hops between the host and customer; The switch, the > BRAS, the Switch again, and then directly to the DSLAM and then > customer on the end. > > > The 10 day plot: > http://picpaste.com/10_Day_graph-YV3IdvRV.png > > The 30 hour plot: > http://picpaste.com/30_hour_graph-DrwzfhYJ.png > > How can you possibly have consistent increase in latency like that? > I'd love to hear theories (or offers of beer, your choice!). Theory: There's a stateful device (firewall, NAT, something else) in the path that is creating state for every ICMP Echo Request it forwards and (possibly) searching that state when forwarding the ICMP Echo Reply responses, and never destroying that state, and either the create operation or the search operation (or both) takes an amount of time that is a linear function of the number of state entries. -- Brett From khuon at NEEBU.Net Sat Jun 1 00:40:44 2013 From: khuon at NEEBU.Net (Jake Khuon) Date: Fri, 31 May 2013 17:40:44 -0700 Subject: Headscratcher of the week In-Reply-To: <20130601003027.GA10433@panix.com> References: <51A92352.3000906@tiedyenetworks.com> <20130601003027.GA10433@panix.com> Message-ID: <51A9430C.9010502@NEEBU.Net> On 31/05/13 17:30, Brett Frankenberger wrote: >> How can you possibly have consistent increase in latency like that? >> I'd love to hear theories (or offers of beer, your choice!). Variation of the buffer filling theory is that there's some QoS/traffic-shaping going on which is causing your ping packets to get classed and policed into an ever depleting buffer pool. I wonder what would happen to the pattern if you reset the interface. |8^) -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From ikiris at gmail.com Sat Jun 1 04:18:51 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 31 May 2013 23:18:51 -0500 Subject: Headscratcher of the week In-Reply-To: <51A9430C.9010502@NEEBU.Net> References: <51A92352.3000906@tiedyenetworks.com> <20130601003027.GA10433@panix.com> <51A9430C.9010502@NEEBU.Net> Message-ID: I agree with previous poster, table size progression and corresponding increase in search delay, probably related directly to the monitoring itself, or at least a connection state of some kind. On Fri, May 31, 2013 at 7:40 PM, Jake Khuon wrote: > On 31/05/13 17:30, Brett Frankenberger wrote: > > How can you possibly have consistent increase in latency like >>> that? >>> I'd love to hear theories (or offers of beer, your choice!). >>> >> > Variation of the buffer filling theory is that there's some > QoS/traffic-shaping going on which is causing your ping packets to get > classed and policed into an ever depleting buffer pool. > > I wonder what would happen to the pattern if you reset the interface. |8^) > > > -- > /*=================[ Jake Khuon ]=================+ > | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | > | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | > +=============================**==============================**=======*/ > > From tuc at admarketplace.com Sat Jun 1 02:36:30 2013 From: tuc at admarketplace.com (Tuc) Date: Fri, 31 May 2013 22:36:30 -0400 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: <20130531222645.GC27305@puck.nether.net> Message-ID: Hi, Thanks to everyone. I didn't pay enough attention the last time this was discussed, sorry about that. I have my cables, though I need to start working on my sob story when I put in my expense report for 30 cables that should have been 1.44 each, not 6.95. Thanks again, Tuc On Fri, May 31, 2013 at 6:37 PM, Carlos Alcantar wrote: > I don't think they will care how you pay. It's just the question if you > do or don't need an account. > > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > > > > -----Original Message----- > From: "Majdi S. Abbas" > Date: Friday, May 31, 2013 3:26 PM > To: Tim M Edwards > Cc: "nanog at nanog.org" > Subject: Re: Cat-5 cables near 200 Paul, SF > > On Fri, May 31, 2013 at 12:06:50PM -0700, Tim M Edwards wrote: > > Needs to be a Corporate CC though. > > Nahh, they take my personal card in Phoenix and SF all the time. > > --msa > > > > > -- Tuc Senior Director of Infrastructure p: (646) 532 4510 e: tuc at admarketplace.com contact: 3 Park Avenue | 27th Floor | NY 10016 | 212-925-2022 connect: Twitter | Facebook | Google+ | Linkedin | Blog | Careers *adMarketplace is #8 on Crain?s New York Fast 50 List !* From robertg at garlic.com Sat Jun 1 14:43:24 2013 From: robertg at garlic.com (Robert Glover) Date: Sat, 01 Jun 2013 07:43:24 -0700 Subject: Anyone from O1? Message-ID: <51AA088C.4090102@garlic.com> Anyone from O1 around? Your support line (888-444-1111) is failing to "All Circuits are Busy". Managed Modem service numbers in Area Codes 530 & 916 are failing to "All Circuits are Busy". Any ETA for service to be restored? I have some grumpy dial-up users this morning. -Robert From branto at argentiumsolutions.com Sat Jun 1 17:53:11 2013 From: branto at argentiumsolutions.com (Stevens, Brant I.) Date: Sat, 1 Jun 2013 13:53:11 -0400 Subject: GMail IPv6 IMAP Issue, or is it Just Me? Message-ID: Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it just me? Here's some of what I'm seeing: It responds to ping... imac01:~ branto$ ping6 imap.gmail.com PING6(56=40+8+8 bytes) 2001:470:8d30:b00c::bb0e --> 2607:f8b0:400d:c00::6c 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=0 hlim=55 time=31.299 ms 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=1 hlim=55 time=41.528 ms 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=2 hlim=55 time=30.092 ms 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=3 hlim=55 time=35.450 ms ^C --- gmail-imap.l.google.com ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 30.092/34.592/41.528/4.470 ms TCP Sessions on v6 seem to time-out: imac01:~ branto$ telnet -6 imap.gmail.com 993 Trying 2607:f8b0:400d:c01::6c... telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out telnet: Unable to connect to remote host IPv4 Connects: imac01:~ branto$ telnet -4 imap.gmail.com 993 Trying 173.194.76.108... Connected to gmail-imap.l.google.com. Escape character is '^]'. ^] telnet> close Connection closed. and other connectivity via IPv6 works: imac01:~ branto$ telnet -6 www.google.com 80 Trying 2607:f8b0:400c:c04::68... Connected to www.google.com. Escape character is '^]'. GET / HTTP/1.0 200 OK Date: Sat, 01 Jun 2013 17:08:58 GMT Connection closed by foreign host. I've tried flushing my dnscache to make sure I'm not holding on to something that's not valid, but no dice. -Brant From jhellenthal at dataix.net Sat Jun 1 20:00:09 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sat, 1 Jun 2013 16:00:09 -0400 Subject: GMail IPv6 IMAP Issue, or is it Just Me? In-Reply-To: References: Message-ID: <799172B1-9875-4670-B48B-3D088323BC19@dataix.net> IDK, But I get NXDOMAIN upon lookup of imap. But have all my clients using mail.google.com for imaps. I get ipv6 on 2607:f8b0:4009:802::1015 -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 1, 2013, at 13:53, "Stevens, Brant I." wrote: > Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it just > me? > > Here's some of what I'm seeing: > > It responds to ping... > > imac01:~ branto$ ping6 imap.gmail.com > PING6(56=40+8+8 bytes) 2001:470:8d30:b00c::bb0e --> 2607:f8b0:400d:c00::6c > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=0 hlim=55 time=31.299 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=1 hlim=55 time=41.528 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=2 hlim=55 time=30.092 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=3 hlim=55 time=35.450 ms > ^C > --- gmail-imap.l.google.com ping6 statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 30.092/34.592/41.528/4.470 ms > > > TCP Sessions on v6 seem to time-out: > > imac01:~ branto$ telnet -6 imap.gmail.com 993 > Trying 2607:f8b0:400d:c01::6c... > telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out > telnet: Unable to connect to remote host > > IPv4 Connects: > > imac01:~ branto$ telnet -4 imap.gmail.com 993 > Trying 173.194.76.108... > Connected to gmail-imap.l.google.com. > Escape character is '^]'. > > ^] > telnet> close > Connection closed. > > and other connectivity via IPv6 works: > > imac01:~ branto$ telnet -6 www.google.com 80 > Trying 2607:f8b0:400c:c04::68... > Connected to www.google.com. > Escape character is '^]'. > > GET / > HTTP/1.0 200 OK > Date: Sat, 01 Jun 2013 17:08:58 GMT > > > > Connection closed by foreign host. > > I've tried flushing my dnscache to make sure I'm not holding on to > something that's not valid, but no dice. > > -Brant -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2529 bytes Desc: not available URL: From arturo.servin at gmail.com Sat Jun 1 20:44:13 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Sat, 01 Jun 2013 17:44:13 -0300 Subject: GMail IPv6 IMAP Issue, or is it Just Me? In-Reply-To: References: Message-ID: <51AA5D1D.5040301@gmail.com> It works to me, a different one by the way: telnet -6 imap.gmail.com 993 Trying 2607:f8b0:400c:c01::6c... Connected to gmail-imap.l.google.com. Escape character is '^]'. ] ^] telnet> q Connection closed. The same one, works too: telnet 2607:f8b0:400d:c00::6c 993 Trying 2607:f8b0:400d:c00::6c... Connected to qa-in-x6c.1e100.net. Escape character is '^]'. ^] telnet> q Connection closed. Regards, as On 6/1/13 2:53 PM, Stevens, Brant I. wrote: > Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it just > me? > > Here's some of what I'm seeing: > > It responds to ping... > > imac01:~ branto$ ping6 imap.gmail.com > PING6(56=40+8+8 bytes) 2001:470:8d30:b00c::bb0e --> 2607:f8b0:400d:c00::6c > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=0 hlim=55 time=31.299 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=1 hlim=55 time=41.528 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=2 hlim=55 time=30.092 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=3 hlim=55 time=35.450 ms > ^C > --- gmail-imap.l.google.com ping6 statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 30.092/34.592/41.528/4.470 ms > > > TCP Sessions on v6 seem to time-out: > > imac01:~ branto$ telnet -6 imap.gmail.com 993 > Trying 2607:f8b0:400d:c01::6c... > telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out > telnet: Unable to connect to remote host > > IPv4 Connects: > > imac01:~ branto$ telnet -4 imap.gmail.com 993 > Trying 173.194.76.108... > Connected to gmail-imap.l.google.com. > Escape character is '^]'. > > ^] > telnet> close > Connection closed. > > and other connectivity via IPv6 works: > > imac01:~ branto$ telnet -6 www.google.com 80 > Trying 2607:f8b0:400c:c04::68... > Connected to www.google.com. > Escape character is '^]'. > > GET / > HTTP/1.0 200 OK > Date: Sat, 01 Jun 2013 17:08:58 GMT > > > > Connection closed by foreign host. > > I've tried flushing my dnscache to make sure I'm not holding on to > something that's not valid, but no dice. > > -Brant > From mike at sentex.net Sun Jun 2 01:43:58 2013 From: mike at sentex.net (Mike Tancsa) Date: Sat, 01 Jun 2013 21:43:58 -0400 Subject: GMail IPv6 IMAP Issue, or is it Just Me? In-Reply-To: References: Message-ID: <51AAA35E.6000800@sentex.net> On 6/1/2013 1:53 PM, Stevens, Brant I. wrote: > Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it just > me? > > imac01:~ branto$ telnet -6 imap.gmail.com 993 > Trying 2607:f8b0:400d:c01::6c... > telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out > telnet: Unable to connect to remote host Looks ok for me via Toronto, Ont, Canada 0(marble)% host imap.gmail.com imap.gmail.com is an alias for gmail-imap.l.google.com. gmail-imap.l.google.com has address 74.125.142.108 gmail-imap.l.google.com has address 74.125.142.109 gmail-imap.l.google.com has IPv6 address 2607:f8b0:4003:c01::6c 0(marble)% % traceroute6 -q1 2607:f8b0:4003:c01::6c traceroute6 to 2607:f8b0:4003:c01::6c (2607:f8b0:4003:c01::6c) from 2607:f3e0::2, 64 hops max, 12 byte packets 1 iolite4-6 0.560 ms 2 toronto-torix-6 4.678 ms 3 he.ip6.torontointernetxchange.net 3.793 ms 4 2001:478:245:1::6 5.810 ms 5 2001:4860::1:0:e38 3.471 ms 6 2001:4860::8:0:2fe9 16.342 ms 7 2001:4860::8:0:29ee 31.341 ms 8 2001:4860::2:0:95e 31.340 ms 9 * 10 ob-in-x6c.1e100.net 30.584 ms 1(marble)% openssl s_client -host imap.gmail.com -port 993 CONNECTED(00000003) depth=1 /C=US/O=Google Inc/CN=Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com i:/C=US/O=Google Inc/CN=Google Internet Authority 1 s:/C=US/O=Google Inc/CN=Google Internet Authority i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIDgDCCAumgAwIBAgIKVEsbtQABAACELjANBgkqhkiG9w0BAQUFADBGMQswCQYD VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu dGVybmV0IEF1dGhvcml0eTAeFw0xMzA0MTUwODQ0MDBaFw0xMzEyMzExNTU4NTBa MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3a/wUjZBSOgZ EeyRqaSaKEwS8+1y/8AK9HdplSR72PU+iBc7HyA4aXgD6XYEJVoyGsO97nMj+oeN 2iNvKfkPvTrn2YnQfJLuxpEw9gwIHvwVqy3TNpHwt4DHnxOg5CxV8e7PaCAhAXD+ uj0H09aVFJmfYDnU0VSSukNJX2MZSJUCAwEAAaOCAVEwggFNMB0GA1UdJQQWMBQG CCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUY9A6EExy3NNFBc2R0vrY8lpf OB8wHwYDVR0jBBgwFoAUv8Aw6/VDET5nup6R+/xq2uNrEiQwWwYDVR0fBFQwUjBQ oE6gTIZKaHR0cDovL3d3dy5nc3RhdGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhv cml0eS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS5jcmwwZgYIKwYBBQUHAQEEWjBY MFYGCCsGAQUFBzAChkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dvb2dsZUludGVy bmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNydDAMBgNVHRMB Af8EAjAAMBkGA1UdEQQSMBCCDmltYXAuZ21haWwuY29tMA0GCSqGSIb3DQEBBQUA A4GBAAcrDCcXCKZ2VNcJv31SSXTKs1AH0sU1lvAB0kzy3mIB/H8UHvMz1+T3Lfmy 68bqBSM97W6MO6UiqmVvbMhwPBrktUVT/Q4cWskVf2MONrW3g0UtX47L1ocs/WZe XdUTkjQ3EFCzxpw4joHefndfZHsEn0VrjZR49kzR9+1Me7Rz -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority --- No client certificate CA names sent --- SSL handshake has read 1752 bytes and written 325 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: 881124D0017ADA0B7D8CEB26ECBCBCF86AF8A593600858D165164A17B2C0C652 Session-ID-ctx: Master-Key: 667BDFF99C7FE7733C8CB36FE2F73C76380DE2AC9453A0D3D621E39CE64EC1259BC8AB8FE65C425E15BCA467B80FD274 Key-Arg : None Start Time: 1370137039 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- * OK Gimap ready for requests from 199.212.134.2 bj1if1491559oac.162 ^C 1(marble)% -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From branto at argentiumsolutions.com Sun Jun 2 12:34:43 2013 From: branto at argentiumsolutions.com (Brant Ian Stevens) Date: Sun, 02 Jun 2013 08:34:43 -0400 Subject: GMail IPv6 IMAP Issue, or is it Just Me? In-Reply-To: <51AAA35E.6000800@sentex.net> References: <51AAA35E.6000800@sentex.net> Message-ID: <51AB3BE3.4060301@argentiumsolutions.com> It started flowing shortly after I sent the initial message... Thanks to all who answered. > Mike Tancsa > June 1, 2013 9:43 PM > > > Looks ok for me via Toronto, Ont, Canada > > 0(marble)% host imap.gmail.com > imap.gmail.com is an alias for gmail-imap.l.google.com. > gmail-imap.l.google.com has address 74.125.142.108 > gmail-imap.l.google.com has address 74.125.142.109 > gmail-imap.l.google.com has IPv6 address 2607:f8b0:4003:c01::6c > 0(marble)% > > % traceroute6 -q1 2607:f8b0:4003:c01::6c > traceroute6 to 2607:f8b0:4003:c01::6c (2607:f8b0:4003:c01::6c) from > 2607:f3e0::2, 64 hops max, 12 byte packets > 1 iolite4-6 0.560 ms > 2 toronto-torix-6 4.678 ms > 3 he.ip6.torontointernetxchange.net 3.793 ms > 4 2001:478:245:1::6 5.810 ms > 5 2001:4860::1:0:e38 3.471 ms > 6 2001:4860::8:0:2fe9 16.342 ms > 7 2001:4860::8:0:29ee 31.341 ms > 8 2001:4860::2:0:95e 31.340 ms > 9 * > 10 ob-in-x6c.1e100.net 30.584 ms > > > 1(marble)% openssl s_client -host imap.gmail.com -port 993 > CONNECTED(00000003) > depth=1 /C=US/O=Google Inc/CN=Google Internet Authority > verify error:num=20:unable to get local issuer certificate > verify return:0 > --- > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com > i:/C=US/O=Google Inc/CN=Google Internet Authority > 1 s:/C=US/O=Google Inc/CN=Google Internet Authority > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > --- > Server certificate > -----BEGIN CERTIFICATE----- > MIIDgDCCAumgAwIBAgIKVEsbtQABAACELjANBgkqhkiG9w0BAQUFADBGMQswCQYD > VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu > dGVybmV0IEF1dGhvcml0eTAeFw0xMzA0MTUwODQ0MDBaFw0xMzEyMzExNTU4NTBa > MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N > b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw > LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3a/wUjZBSOgZ > EeyRqaSaKEwS8+1y/8AK9HdplSR72PU+iBc7HyA4aXgD6XYEJVoyGsO97nMj+oeN > 2iNvKfkPvTrn2YnQfJLuxpEw9gwIHvwVqy3TNpHwt4DHnxOg5CxV8e7PaCAhAXD+ > uj0H09aVFJmfYDnU0VSSukNJX2MZSJUCAwEAAaOCAVEwggFNMB0GA1UdJQQWMBQG > CCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUY9A6EExy3NNFBc2R0vrY8lpf > OB8wHwYDVR0jBBgwFoAUv8Aw6/VDET5nup6R+/xq2uNrEiQwWwYDVR0fBFQwUjBQ > oE6gTIZKaHR0cDovL3d3dy5nc3RhdGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhv > cml0eS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS5jcmwwZgYIKwYBBQUHAQEEWjBY > MFYGCCsGAQUFBzAChkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dvb2dsZUludGVy > bmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNydDAMBgNVHRMB > Af8EAjAAMBkGA1UdEQQSMBCCDmltYXAuZ21haWwuY29tMA0GCSqGSIb3DQEBBQUA > A4GBAAcrDCcXCKZ2VNcJv31SSXTKs1AH0sU1lvAB0kzy3mIB/H8UHvMz1+T3Lfmy > 68bqBSM97W6MO6UiqmVvbMhwPBrktUVT/Q4cWskVf2MONrW3g0UtX47L1ocs/WZe > XdUTkjQ3EFCzxpw4joHefndfZHsEn0VrjZR49kzR9+1Me7Rz > -----END CERTIFICATE----- > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com > issuer=/C=US/O=Google Inc/CN=Google Internet Authority > --- > No client certificate CA names sent > --- > SSL handshake has read 1752 bytes and written 325 bytes > --- > New, TLSv1/SSLv3, Cipher is RC4-SHA > Server public key is 1024 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1 > Cipher : RC4-SHA > Session-ID: > 881124D0017ADA0B7D8CEB26ECBCBCF86AF8A593600858D165164A17B2C0C652 > Session-ID-ctx: > Master-Key: > 667BDFF99C7FE7733C8CB36FE2F73C76380DE2AC9453A0D3D621E39CE64EC1259BC8AB8FE65C425E15BCA467B80FD274 > Key-Arg : None > Start Time: 1370137039 > Timeout : 300 (sec) > Verify return code: 20 (unable to get local issuer certificate) > --- > * OK Gimap ready for requests from 199.212.134.2 bj1if1491559oac.162 > ^C > 1(marble)% > Stevens, Brant I. > June 1, 2013 1:53 PM > Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it > just > me? > > Here's some of what I'm seeing: > > It responds to ping... > > imac01:~ branto$ ping6 imap.gmail.com > PING6(56=40+8+8 bytes) 2001:470:8d30:b00c::bb0e --> 2607:f8b0:400d:c00::6c > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=0 hlim=55 time=31.299 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=1 hlim=55 time=41.528 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=2 hlim=55 time=30.092 ms > 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=3 hlim=55 time=35.450 ms > ^C > --- gmail-imap.l.google.com ping6 statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 30.092/34.592/41.528/4.470 ms > > > TCP Sessions on v6 seem to time-out: > > imac01:~ branto$ telnet -6 imap.gmail.com 993 > Trying 2607:f8b0:400d:c01::6c... > telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out > telnet: Unable to connect to remote host > > IPv4 Connects: > > imac01:~ branto$ telnet -4 imap.gmail.com 993 > Trying 173.194.76.108... > Connected to gmail-imap.l.google.com. > Escape character is '^]'. > > ^] > telnet> close > Connection closed. > > and other connectivity via IPv6 works: > > imac01:~ branto$ telnet -6 www.google.com 80 > Trying 2607:f8b0:400c:c04::68... > Connected to www.google.com. > Escape character is '^]'. > > GET / > HTTP/1.0 200 OK > Date: Sat, 01 Jun 2013 17:08:58 GMT > > > > Connection closed by foreign host. > > I've tried flushing my dnscache to make sure I'm not holding on to > something that's not valid, but no dice. > > -Brant From jvanoppen at spectrumnet.us Mon Jun 3 02:43:07 2013 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 3 Jun 2013 02:43:07 +0000 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: <20130531222645.GC27305@puck.nether.net>, Message-ID: an account is not required at least at the locations in Seattle, but an account gets you access to the best prices if you buy in quantity. John - AS11404 ________________________________________ From: Carlos Alcantar [carlos at race.com] Sent: Friday, May 31, 2013 3:37 PM To: nanog at nanog.org Subject: Re: Cat-5 cables near 200 Paul, SF I don't think they will care how you pay. It's just the question if you do or don't need an account. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: "Majdi S. Abbas" Date: Friday, May 31, 2013 3:26 PM To: Tim M Edwards Cc: "nanog at nanog.org" Subject: Re: Cat-5 cables near 200 Paul, SF On Fri, May 31, 2013 at 12:06:50PM -0700, Tim M Edwards wrote: > Needs to be a Corporate CC though. Nahh, they take my personal card in Phoenix and SF all the time. --msa From bosch at adacore.com Mon Jun 3 03:10:53 2013 From: bosch at adacore.com (Geert Bosch) Date: Sun, 2 Jun 2013 23:10:53 -0400 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: <20130531222645.GC27305@puck.nether.net> Message-ID: On May 31, 2013, at 22:36, Tuc wrote: > Thanks to everyone. I didn't pay enough attention the last time this was > discussed, sorry about that. I have my cables, though I need to start > working on my sob story when I put in my expense report for 30 cables that > should have been 1.44 each, not 6.95. So the difference is $165, probably not even 3 or 4 hours of your time. Probably the time spent writing the expense report and sob story is the biggest waste of money. -Geert From intensifysecurity at gmail.com Mon Jun 3 14:30:54 2013 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Mon, 3 Jun 2013 10:30:54 -0400 Subject: NANOG58 - link to OpenFlow session slides Message-ID: Re-posting for those having difficulties: tinyurl.com/nanog58-slides From philfagan at gmail.com Mon Jun 3 15:14:23 2013 From: philfagan at gmail.com (Phil Fagan) Date: Mon, 3 Jun 2013 09:14:23 -0600 Subject: NANOG58 - link to OpenFlow session slides In-Reply-To: References: Message-ID: Stupid question....there's not a live stream for 58 is there? On Mon, Jun 3, 2013 at 8:30 AM, Jeff Hartley wrote: > Re-posting for those having difficulties: > > tinyurl.com/nanog58-slides > -- Phil Fagan Denver, CO 970-480-7618 From lhynes at dyn.com Mon Jun 3 15:19:06 2013 From: lhynes at dyn.com (Liam Hynes) Date: Mon, 03 Jun 2013 11:19:06 -0400 Subject: NANOG58 - link to OpenFlow session slides In-Reply-To: References: Message-ID: <51ACB3EA.9060306@dyn.com> http://www.kikaua.com/clients/nanog/ It looks to be only for the main room though On 6/3/13 11:14 AM, Phil Fagan wrote: > Stupid question....there's not a live stream for 58 is there? > > > On Mon, Jun 3, 2013 at 8:30 AM, Jeff Hartley wrote: > >> Re-posting for those having difficulties: >> >> tinyurl.com/nanog58-slides >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From jabley at hopcount.ca Mon Jun 3 15:22:09 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 3 Jun 2013 11:22:09 -0400 Subject: NANOG58 - link to OpenFlow session slides In-Reply-To: References: Message-ID: <5836E944-29A6-47EA-89F4-CFAD4C43B9BA@hopcount.ca> On 2013-06-03, at 11:14, Phil Fagan wrote: > Stupid question....there's not a live stream for 58 is there? There's a grey icon in the agenda for sessions that are being streamed, looks like. Click grey icon, video appears. Joe From philfagan at gmail.com Mon Jun 3 15:29:13 2013 From: philfagan at gmail.com (Phil Fagan) Date: Mon, 3 Jun 2013 09:29:13 -0600 Subject: NANOG58 - link to OpenFlow session slides In-Reply-To: <5836E944-29A6-47EA-89F4-CFAD4C43B9BA@hopcount.ca> References: <5836E944-29A6-47EA-89F4-CFAD4C43B9BA@hopcount.ca> Message-ID: awesome, thanks! On Mon, Jun 3, 2013 at 9:22 AM, Joe Abley wrote: > > On 2013-06-03, at 11:14, Phil Fagan wrote: > > > Stupid question....there's not a live stream for 58 is there? > > There's a grey icon in the agenda for sessions that are being streamed, > looks like. Click grey icon, video appears. > > > Joe -- Phil Fagan Denver, CO 970-480-7618 From jra at baylink.com Mon Jun 3 17:00:34 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 03 Jun 2013 13:00:34 -0400 Subject: Mirror image fiber infrastructure could bring faster, more reliable Internet | Streaming content from Broadcast Engineering Message-ID: <792452cf-6cd8-4c0b-8be4-67eb15c250f1@email.android.com> Bell Labs researchers working on a phase-conjugate laser tracking system. Hope they like popcorn. Cheers, -jra http://broadcastengineering.com/streaming/mirror-image-fiber-infrastructure-could-bring-faster-more-reliable-internet -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From outsider at scarynet.org Mon Jun 3 19:17:46 2013 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 03 Jun 2013 21:17:46 +0200 Subject: nokiamail spam Message-ID: <1370287066.8502.7.camel@outsider.laptop> Could someone from yahoo please contact me off list please? Because I really want something to be done against the recent spam mail floods from nokiamail.com without needing to harm yahoo itself by adding them to dnsbl as it would harm more users then just the intended target in order to protect users from these spams. The abuse has been going on for weeks, and I hardly see any improvements in solving those. I encourage yahoo to make it clear to nokia that this abuse has to end. I myself receive these mails multiple times a day on several mailboxes. Googling around tells me there are millions others suffering from the same spams as well. To put it in a simple quote: When... does.... the... hurting... end? Kind regards, Alexander Maassen Maintainer DroneBL -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From rsk at gsp.org Mon Jun 3 19:25:48 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 3 Jun 2013 15:25:48 -0400 Subject: nokiamail spam In-Reply-To: <1370287066.8502.7.camel@outsider.laptop> References: <1370287066.8502.7.camel@outsider.laptop> Message-ID: <20130603192548.GA10267@gsp.org> On Mon, Jun 03, 2013 at 09:17:46PM +0200, Alexander Maassen wrote: > Could someone from yahoo please contact me off list please? [snip] 1. This would be better directed to the mailop list, please see: http://chilli.nosignal.org/mailman/listinfo/mailop 2. I have yet to see any evidence this century that Yahoo cares in the slightest about the unceasing flood of spam/phish/abuse flowing outbound from its operation. After all, if they did, we would not be having this conversation. ---rsk From akennykant at gmail.com Mon Jun 3 19:52:26 2013 From: akennykant at gmail.com (Kenny Kant) Date: Mon, 3 Jun 2013 14:52:26 -0500 Subject: Centurylink Outage Iowa Message-ID: <1AF2B5C1-772E-47CE-9B40-AEF8B39B2B93@gmail.com> Can anyone from Centurylink confirm any large outage in Dubuque, Iowa area? Support lines seem jammed. Thanks Kenny Sent from my iPhone From Valdis.Kletnieks at vt.edu Mon Jun 3 20:10:06 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Jun 2013 16:10:06 -0400 Subject: Centurylink Outage Iowa In-Reply-To: Your message of "Mon, 03 Jun 2013 14:52:26 -0500." <1AF2B5C1-772E-47CE-9B40-AEF8B39B2B93@gmail.com> References: <1AF2B5C1-772E-47CE-9B40-AEF8B39B2B93@gmail.com> Message-ID: <34049.1370290206@turing-police.cc.vt.edu> On Mon, 03 Jun 2013 14:52:26 -0500, Kenny Kant said: > Can anyone from Centurylink confirm any large outage in Dubuque, Iowa area? It's Dubuque, Iowa. How large can an outage there *be*? :) (Sorry, couldn't resist. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From goemon at anime.net Mon Jun 3 20:18:33 2013 From: goemon at anime.net (goemon at anime.net) Date: Mon, 3 Jun 2013 13:18:33 -0700 (PDT) Subject: nokiamail spam In-Reply-To: <20130603192548.GA10267@gsp.org> References: <1370287066.8502.7.camel@outsider.laptop> <20130603192548.GA10267@gsp.org> Message-ID: On Mon, 3 Jun 2013, Rich Kulawiec wrote: > 2. I have yet to see any evidence this century that Yahoo cares in > the slightest about the unceasing flood of spam/phish/abuse flowing > outbound from its operation. After all, if they did, we would not > be having this conversation. wasn't yahoo's abuse team disbanded years ago? -Dan From akennykant at gmail.com Mon Jun 3 20:24:02 2013 From: akennykant at gmail.com (Kenny Kant) Date: Mon, 3 Jun 2013 15:24:02 -0500 Subject: Centurylink Outage Iowa In-Reply-To: <34049.1370290206@turing-police.cc.vt.edu> References: <1AF2B5C1-772E-47CE-9B40-AEF8B39B2B93@gmail.com> <34049.1370290206@turing-police.cc.vt.edu> Message-ID: <62CF2266-4117-4C36-A5AC-A6D1C86F6ADB@gmail.com> Rofl lots of corn and cows :) Sent from my iPhone On Jun 3, 2013, at 3:10 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 03 Jun 2013 14:52:26 -0500, Kenny Kant said: >> Can anyone from Centurylink confirm any large outage in Dubuque, Iowa area? > > It's Dubuque, Iowa. How large can an outage there *be*? :) > > (Sorry, couldn't resist. :) From lyle at lcrcomputer.net Tue Jun 4 01:09:50 2013 From: lyle at lcrcomputer.net (Lyle Giese) Date: Mon, 03 Jun 2013 20:09:50 -0500 Subject: Centurylink Outage Iowa In-Reply-To: <34049.1370290206@turing-police.cc.vt.edu> References: <1AF2B5C1-772E-47CE-9B40-AEF8B39B2B93@gmail.com> <34049.1370290206@turing-police.cc.vt.edu> Message-ID: <51AD3E5E.2050109@lcrcomputer.net> On 06/03/13 15:10, Valdis.Kletnieks at vt.edu wrote: > On Mon, 03 Jun 2013 14:52:26 -0500, Kenny Kant said: >> Can anyone from Centurylink confirm any large outage in Dubuque, Iowa area? > It's Dubuque, Iowa. How large can an outage there *be*? :) > > (Sorry, couldn't resist. :) Hey, people in Galena, IL may well be interested! All phone and Internet goes back to Dubuque and then down to the Quad Cities. Besides the riverboat managers may be interested also. Lyle Giese LCR Computer Services, Inc. From ryan at finnesey.com Tue Jun 4 02:27:07 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Tue, 4 Jun 2013 02:27:07 +0000 Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: <59db294d56aa461899b3ec87a40d6350@BY2PR05MB079.namprd05.prod.outlook.com> Great list to know about I just joined thank you -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Monday, May 20, 2013 2:47 PM To: Brandon Galbraith Cc: NANOG mailing list Subject: Re: Remote Hands Nation-Wide? there's also a mailing-list Warren Kumari setup ... there are folk in the DC area (myself and warren) who have on occasion helped out with these sorts of things. http://www.ne-where.com/cgi-bin/mailman/listinfo/ne-where I think is the thing in question... On Mon, May 20, 2013 at 2:37 PM, Brandon Galbraith wrote: > http://nanog.cluepon.net/index.php/Hands > > From morrowc.lists at gmail.com Tue Jun 4 03:22:38 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 3 Jun 2013 23:22:38 -0400 Subject: Remote Hands Nation-Wide? In-Reply-To: <59db294d56aa461899b3ec87a40d6350@BY2PR05MB079.namprd05.prod.outlook.com> References: <59db294d56aa461899b3ec87a40d6350@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: On Mon, Jun 3, 2013 at 10:27 PM, Ryan Finnesey wrote: > Great list to know about I just joined thank you > thanks to warren, really. From mpetach at netflight.com Tue Jun 4 07:22:24 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 4 Jun 2013 00:22:24 -0700 Subject: 2013.06.03 NANOG58 notes posted Message-ID: Sorry about the delay in sending these out; didn't realize my nanog subscription had lapsed. Notes are being posted to the NANOG wiki at cluepon: http://nanog.cluepon.net/index.php/NANOG58 rather than spam the list with each new set of notes, you can check the wiki about 30 minutes after the end of the session, and I should have the notes up. Thanks! Matt From johnl at iecc.com Tue Jun 4 13:11:08 2013 From: johnl at iecc.com (John Levine) Date: 4 Jun 2013 13:11:08 -0000 Subject: nokiamail spam In-Reply-To: Message-ID: <20130604131108.3052.qmail@joyce.lan> >> 2. I have yet to see any evidence this century that Yahoo cares in >> the slightest about the unceasing flood of spam/phish/abuse flowing >> outbound from its operation. After all, if they did, we would not >> be having this conversation. > >wasn't yahoo's abuse team disbanded years ago? It was cut way back, but they still have a few very very overworked people. I'm sitting next to one of them at a meeting. From cjc+nanog at pumpky.net Tue Jun 4 17:45:16 2013 From: cjc+nanog at pumpky.net (Crist Clark) Date: Tue, 4 Jun 2013 10:45:16 -0700 Subject: Microsoft Exchange Public Cloud Contact Message-ID: Looking for some help from anyone associated with Microsoft's cloud email service. As of last Thursday, customers of Microsoft Exchange Online and other Microsoft email services could no longer send us email. We are not a Microsoft customer, so I'm not sure of how to get help on this. I think I have some guesses about what might be happening, but it's something we cannot fix from the outside. MS needs to fix it Any help would be appreciated. I can supply more details. Did not want to share too much in a public forum. Thanks. From mpetach at netflight.com Tue Jun 4 18:57:37 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 4 Jun 2013 11:57:37 -0700 Subject: nokiamail spam In-Reply-To: <20130604131108.3052.qmail@joyce.lan> References: <20130604131108.3052.qmail@joyce.lan> Message-ID: On Tue, Jun 4, 2013 at 6:11 AM, John Levine wrote: > >> 2. I have yet to see any evidence this century that Yahoo cares in > >> the slightest about the unceasing flood of spam/phish/abuse flowing > >> outbound from its operation. After all, if they did, we would not > >> be having this conversation. > > > >wasn't yahoo's abuse team disbanded years ago? > > It was cut way back, but they still have a few very very overworked > people. I'm sitting next to one of them at a meeting. > > > Sorry. Full disk, plus being out on medical leave for a month meant my NANOG mail stopped flowing; hadn't seen anything since April. Got the disk taken care of. Won't be able to catch back up on what I missed, but will be keeping my eyes open for new threads. Not one of the people who can say anything publicly about the situation; but people *do* care, they really do. Matt From jcurran at arin.net Tue Jun 4 20:10:29 2013 From: jcurran at arin.net (John Curran) Date: Tue, 4 Jun 2013 20:10:29 +0000 Subject: Less than 1 hour remaining to register for remote participation in the PPC@NANOG 58!! References: <51ADF4E6.5020600@arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B374E70DB7F4@CHAXCH01.corp.arin.net> NANOG Community - At 4:45 PM CDT today, there will be a Public Policy Consultation (PPC) being held in conjunction with NANOG 58 in New Orleans. As noted in the attached announcement, there is a remote participation available and is free, but you must register in advance (and there is less than an hour remaining to do so!) Thank you! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN Public Policy Consultation At NANOG 58 Today at 4:45 CDT Date: June 4, 2013 9:08:38 AM CDT To: > If you aren't at NANOG, you can still register as a remote participant for ARIN's Public Policy Consultation (PPC), which will be webcast this afternoon beginning at 4:45 PM CDT. The PPC is an open public discussion of Internet number resource policy, and part of ARIN's Policy Development Process (PDP). ARIN will be offering a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants may submit comments and questions to the discussions during the meeting. Register to attend in person or remotely today at https://www.arin.net/app/meeting/registration/?action=show_form&meeting_id=53. Your Jabber ID must be registered by 4:00PM CDT if you wish to participate. We do encourage you to register early so you have ample time to test the chat before the session opens. Current policy proposals up for discussion at this meeting are: * Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers of ASNs * Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy * Draft Policy ARIN-2013-4: RIR Principles * Draft Policy ARIN-2013-5: LIR/ISP and End-user Definitions Learn more at https://www.arin.net/ppc_nanog58/. Registered NANOG 58 attendees do not need to register to participate in this session. ARIN welcomes members of the NANOG community who will not be in Orlando to register as remote participants. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From ak47 at gawul.net Tue Jun 4 20:11:50 2013 From: ak47 at gawul.net (Andrew Koch) Date: Tue, 4 Jun 2013 15:11:50 -0500 Subject: NANOG meeting live stream - hope to be back soon Message-ID: <20130604201150.GA28719@bucket.gawul.net> We are aware of the live streaming troubles. The engineering team is working on switching out to the backup the system at this time. Hopefully, the stream will be back soon. Best Regards, Andrew Koch on behalf of the NANOG Communications Committee From pozar at lns.com Tue Jun 4 20:34:01 2013 From: pozar at lns.com (Tim Pozar) Date: Tue, 4 Jun 2013 15:34:01 -0500 Subject: NANOG meeting live stream - hope to be back soon In-Reply-To: <20130604201150.GA28719@bucket.gawul.net> References: <20130604201150.GA28719@bucket.gawul.net> Message-ID: <89ACDF81-7CE8-41AF-95FF-513A2AA90FF6@lns.com> Do you need Wowza servers? I can prevision some within minutes. Tim On Jun 4, 2013, at 3:11 PM, Andrew Koch wrote: > We are aware of the live streaming troubles. The engineering team is > working on switching out to the backup the system at this time. > Hopefully, the stream will be back soon. > > Best Regards, > Andrew Koch > on behalf of the NANOG Communications Committee > From pozar at lns.com Tue Jun 4 21:49:12 2013 From: pozar at lns.com (Tim Pozar) Date: Tue, 4 Jun 2013 16:49:12 -0500 Subject: NANOG meeting live stream - hope to be back soon In-Reply-To: <20130604201150.GA28719@bucket.gawul.net> References: <20130604201150.GA28719@bucket.gawul.net> Message-ID: There is a back up audio stream at: http://stream2.streamq.net:8080/listen.pls Tim On Jun 4, 2013, at 3:11 PM, Andrew Koch wrote: > We are aware of the live streaming troubles. The engineering team is > working on switching out to the backup the system at this time. > Hopefully, the stream will be back soon. > > Best Regards, > Andrew Koch > on behalf of the NANOG Communications Committee > From ajarvela at gmail.com Tue Jun 4 21:51:03 2013 From: ajarvela at gmail.com (Adam) Date: Tue, 4 Jun 2013 17:51:03 -0400 Subject: Verizon to AT&T Outage from East Coast? Message-ID: I've seen sporadic connectivity from Wash DC to SanFran CA today. At 1700 ET the connection dropped entirely. Anybody aware of network issues between VZ and AT&T? -- Failed Path -- 1 <1 ms <1 ms <1 ms 192.168.1.1 2 7 ms 6 ms 7 ms L100.WASHDC-VFTTP-125.verizon-gni.net[173.66.17 0.1] 3 12 ms 13 ms 9 ms G0-8-0-3.WASHDC-LCR-22.verizon-gni.net[130.81.2 16.72] 4 7 ms 7 ms 7 ms ae5-0.RES-BB-RTR1.verizon-gni.net[130.81.209.22 2] 5 40 ms 11 ms 11 ms 0.xe-5-1-0.BR1.IAD8.ALTER.NET [152.63.37.69] 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. -- Working Path -- 1 1 ms <1 ms 1 ms 192.168.1.1 2 8 ms 6 ms 6 ms L100.WASHDC-VFTTP-125.verizon-gni.net[173.66.17 0.1] 3 22 ms 9 ms 10 ms G0-8-0-3.WASHDC-LCR-22.verizon-gni.net[130.81.2 16.72] 4 8 ms 6 ms 7 ms ae5-0.RES-BB-RTR1.verizon-gni.net[130.81.209.22 2] 5 12 ms 11 ms 11 ms 0.xe-5-1-0.BR1.IAD8.ALTER.NET [152.63.37.69] 6 10 ms 9 ms 9 ms 192.205.36.141 7 87 ms 88 ms 86 ms cr2.wswdc.ip.att.net [12.122.81.250] 8 85 ms 87 ms 86 ms cr1.cgcil.ip.att.net [12.122.18.21] 9 89 ms 92 ms 89 ms cr1.sffca.ip.att.net [12.122.4.121] 10 87 ms 89 ms 83 ms cr83.sffca.ip.att.net [12.123.15.110] 11 84 ms 84 ms 84 ms 12.122.137.161 12 90 ms 88 ms 90 ms 12.127.32.62 Thanks, Adam From swmike at swm.pp.se Tue Jun 4 22:34:01 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 5 Jun 2013 00:34:01 +0200 (CEST) Subject: IP4 address conservation method Message-ID: I read: http://www.nanog.org/sites/default/files/tues.general.Papandreou.conservation.24.pdf I would like to point out RFC 3069. On most cisco equipment this is done using static routes and "ip unnumbered". So my question is basically: What am I missing? Why can't data center guys not build their network the same way regular ETTH is done? Either one vlan per customer and sharing the IPv4 subnet between several vlans, or having several customers in the same vlan but use antispoofing etc (IETF SAVI-wg functionality) to handle the security stuff? One vlan per customer also works very well with IPv6. -- Mikael Abrahamsson email: swmike at swm.pp.se From landonstewart at gmail.com Tue Jun 4 23:44:02 2013 From: landonstewart at gmail.com (Landon) Date: Tue, 4 Jun 2013 16:44:02 -0700 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints Message-ID: Hello, I'm wondering how other Canadian Hosting Providers handle copyright and trademark complaints about customers on their network. I'm thinking of just handling them the same as a DMCA notification should be handled but since there's no forced takedown provisions in the Canadian copyright act (that I know of?) it's difficult to say what is better. I'd kind of like if our customers could enjoy some freedom from the sledgehammer of the DMCA *but* still being subject to copyright and trademark infringement laws of course. I have to admit - this is my ignorance. I'm quite familiar with the DMCA and the litigation that usually ensues during american trademark infringement already but not Canadian copyright laws or trademark laws. I do intend to consult with a real lawyer about this eventually but I want to have intelligent questions or suggestions before that happens. Also how are trademark infringement issues handled differently than copyright issues in Canada? -- Landon Stewart From nanog at namor.ca Wed Jun 5 05:12:05 2013 From: nanog at namor.ca (J) Date: Wed, 05 Jun 2013 00:12:05 -0500 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: References: Message-ID: <51AEC8A5.4030606@namor.ca> Voluntary notice-and-notice. Mostly automated based on ACNS reports that the majority do. Haven't really dealt any takedowns. On 13-06-04 06:44 PM, Landon wrote: > Hello, > > I'm wondering how other Canadian Hosting Providers handle copyright and > trademark complaints about customers on their network. I'm thinking of > just handling them the same as a DMCA notification should be handled but > since there's no forced takedown provisions in the Canadian copyright act > (that I know of?) it's difficult to say what is better. I'd kind of like > if our customers could enjoy some freedom from the sledgehammer of the DMCA > *but* still being subject to copyright and trademark infringement laws of > course. I have to admit - this is my ignorance. I'm quite familiar with > the DMCA and the litigation that usually ensues during american trademark > infringement already but not Canadian copyright laws or trademark laws. > > I do intend to consult with a real lawyer about this eventually but I want > to have intelligent questions or suggestions before that happens. > > Also how are trademark infringement issues handled differently than > copyright issues in Canada? > From dwhite at olp.net Wed Jun 5 14:44:14 2013 From: dwhite at olp.net (Dan White) Date: Wed, 5 Jun 2013 09:44:14 -0500 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: <20130605144414.GC7129@dan.olp.net> On 06/05/13?00:34?+0200, Mikael Abrahamsson wrote: > >I read: > >http://www.nanog.org/sites/default/files/tues.general.Papandreou.conservation.24.pdf > >I would like to point out RFC 3069. On most cisco equipment this is >done using static routes and "ip unnumbered". > >So my question is basically: What am I missing? Why can't data center >guys not build their network the same way regular ETTH is done? >Either one vlan per customer and sharing the IPv4 subnet between >several vlans, or having several customers in the same vlan but use >antispoofing etc (IETF SAVI-wg functionality) to handle the security >stuff? VLAN-per-subscriber (1 customer per VLAN), can require more costly routing equipment, particularly if you're performing double tagging (outer tag for switch, inner tag for customer). Sharing an IPv4 subnet among customers is appropriate for residential and small business services, which is how we typically deliver service. But may be less appropriate for larger business customers (and I presume hosting customers) where the number of IPs is large enough that you're throwing away less addresses ratio-wise. Generally the simpler deployment model wins out in that type of scenario. Also, the 'ip unnumbered' approach may require some layer-3 security features. VLAN-per-service (>1 customer sharing a VLAN) is problematic, and typically pushes a lot of IPv4 specific layer-3 security features (MACFF, DHCPv4 snooping, proxy arp, broadcast forwarding/split horizon) down into the access equipment, and that's rarely a perfect feature set. In my experience, IPv6 services lag behind on such equipment because those v4 security features break v6. >One vlan per customer also works very well with IPv6. +1 -- Dan White From bill at herrin.us Wed Jun 5 16:06:49 2013 From: bill at herrin.us (William Herrin) Date: Wed, 5 Jun 2013 12:06:49 -0400 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: On Tue, Jun 4, 2013 at 6:34 PM, Mikael Abrahamsson wrote: > http://www.nanog.org/sites/default/files/tues.general.Papandreou.conservation.24.pdf > > So my question is basically: What am I missing? Both the router and host have to support sending and accepting invalid ARP requests. Since the Linux kernel already mishandles arp by default, you're probably begging for unexpected behavior. Double down on that if the customer controls the server image. I don't have any experience with softlayer but I have had to abandon a handful of VPS providers due to bizarre routing failures they couldn't fix. I was particularly thrilled with the one where if I didn't ping the second-hop router from each of the VPS's IPs at least once every 15 seconds it would eventually forget how to reach the address. I could log in via one of the other addresses and confirm with tcpdump that no arps or anything else would appear on the interface. Their advice? Disable iptables. Thanks guys, real helpful. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From swmike at swm.pp.se Wed Jun 5 16:11:20 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 5 Jun 2013 18:11:20 +0200 (CEST) Subject: IP4 address conservation method In-Reply-To: References: Message-ID: On Wed, 5 Jun 2013, William Herrin wrote: > Both the router and host have to support sending and accepting invalid > ARP requests. Since the Linux kernel already mishandles arp by default, > you're probably begging for unexpected behavior. Double down on that if > the customer controls the server image. Exactly what is wrong with the ARP answers and requests sent using local-proxy-arp? -- Mikael Abrahamsson email: swmike at swm.pp.se From bill at herrin.us Wed Jun 5 16:30:33 2013 From: bill at herrin.us (William Herrin) Date: Wed, 5 Jun 2013 12:30:33 -0400 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: On Wed, Jun 5, 2013 at 12:11 PM, Mikael Abrahamsson wrote: > On Wed, 5 Jun 2013, William Herrin wrote: >> Both the router and host have to support sending and accepting invalid ARP >> requests. Since the Linux kernel already mishandles arp by default, you're >> probably begging for unexpected behavior. Double down on that if the >> customer controls the server image. > > Exactly what is wrong with the ARP answers and requests sent using > local-proxy-arp? Nothing. The problem is that the arp source IP doesn't fall within the interface netmask at the receiver. Some receivers ignore that... after all, why do they care what the source IP is? They only care about the source MAC. Other receivers see a spoofed packet and drop it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From swmike at swm.pp.se Wed Jun 5 16:57:51 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 5 Jun 2013 18:57:51 +0200 (CEST) Subject: IP4 address conservation method In-Reply-To: References: Message-ID: On Wed, 5 Jun 2013, William Herrin wrote: > Nothing. The problem is that the arp source IP doesn't fall within the > interface netmask at the receiver. Some receivers ignore that... after > all, why do they care what the source IP is? They only care about the > source MAC. Other receivers see a spoofed packet and drop it. Why wouldn't it be within the source IP mask? I would imagine local-proxy-arp would work exactly the same way as if a directly connected host with the IP the ARP request was for would have answered. -- Mikael Abrahamsson email: swmike at swm.pp.se From mdixon at nkc.org Wed Jun 5 17:58:47 2013 From: mdixon at nkc.org (Michienne Dixon) Date: Wed, 5 Jun 2013 17:58:47 +0000 Subject: SBC / Yahoo Mail Admin Message-ID: <95AE0F4CE21FAF45A39A5F665EC0BCB7C2BE21@nkc-mailhub.nkc.org> Hello - I am looking for someone with the SBC/Yahoo email group that might be able to assist me in tracking down a couple of issues. I have pretty much exhausted most of the known publicly listed resources. Feel free to contact me off list. Thanks in advance. - Max Dixon From dwhite at olp.net Wed Jun 5 18:42:53 2013 From: dwhite at olp.net (Dan White) Date: Wed, 5 Jun 2013 13:42:53 -0500 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: <20130605184253.GG7129@dan.olp.net> On 06/05/13?18:57?+0200, Mikael Abrahamsson wrote: >On Wed, 5 Jun 2013, William Herrin wrote: > >>Nothing. The problem is that the arp source IP doesn't fall within the >>interface netmask at the receiver. Some receivers ignore that... after >>all, why do they care what the source IP is? They only care about the >>source MAC. Other receivers see a spoofed packet and drop it. > >Why wouldn't it be within the source IP mask? I would imagine >local-proxy-arp would work exactly the same way as if a directly >connected host with the IP the ARP request was for would have >answered. I've seen two vendors get it wrong: 1) when originating an ARP request, the router uses a source IP that does not match the subnet of the ip being requested (happened when the interface on the router had secondary IPs); 2) when a customer had more than IP address assigned on an interface/VLAN, and one device ARPd the other, the router responded with its own MAC, creating a race condition where sometimes traffic between those two devices was forced up through the router. -- Dan White From mehmet at akcin.net Wed Jun 5 19:22:39 2013 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 5 Jun 2013 14:22:39 -0500 Subject: DNS Track at NANOG 58 In-Reply-To: <9CA9035F-75D0-463B-93EF-F51AB4ED239D@akcin.net> References: <645BD201-33BB-46D8-80B6-9EDB16A658A1@akcin.net> <9CA9035F-75D0-463B-93EF-F51AB4ED239D@akcin.net> Message-ID: <03034D60-1312-4CC8-B1B3-8EE90BFECE6C@akcin.net> Friendly reminder to those who are in the NANOG Meeting. DNS Track is today from 4:45 to 6:15. See you all there. mehmet On May 22, 2013, at 1:07 AM, Mehmet Akcin wrote: > Hello everyone, > > DNS Track will be on June 5, 2013 Wednesday 4:45pm-6:15pm in Crescent City Ball Room. > > I still have some slots available if you would like to talk about an interesting DNS related subject. , We've got a very good coverage with rate-limiting, reflection attacks, d > > look forward to see you all there. > > mehmet > > > On Apr 18, 2013, at 12:15 PM, Mehmet Akcin wrote: > >> Greetings folks >> >> Once again we will have DNS Track in NANOG. >> >> There has been lots of recent DNS related discussions going on in many e-mail lists and I am quite sure there will be many great DNS talks in NANOG 58 just like in previous NANOGs. >> >> DNS Track's goal is to bring together the audience who doesn't necessarily want to know all the details of a topic but would like to spend 90 mins listening quick updates from various DNS related subjects and get some crucial information and updates. >> >> If you are interested in talking/presenting in the DNS Track and/or want to help me organize this Track in any way, please contact me off-list. Hopefully we can inform those who do NOT spend much time dealing with DNS about some topics they were not aware. >> >> Once I know the details of the agenda such as time and date of the track, topics that will be covered, i will share this with you. >> >> Mehmet >> >> > From mikeal.clark at gmail.com Wed Jun 5 19:42:27 2013 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Wed, 5 Jun 2013 14:42:27 -0500 Subject: Regional Internet problems for AT&T in Wisconsin? Message-ID: We are having issues on our MIS Fiber dropping for 10-15 seconds at a time and getting reports for end users working remotely that residential u-verse internet stops working at the same time they are disconnected from work. From wbailey at satelliteintelligencegroup.com Wed Jun 5 21:06:19 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 5 Jun 2013 21:06:19 +0000 Subject: Regional Internet problems for AT&T in Wisconsin? In-Reply-To: References: Message-ID: Uverse residential service in South Orange County CA has been bad all day. Can't even get emails with attachments out. Sent from my Mobile Device. -------- Original message -------- From: Mikeal Clark Date: 06/05/2013 12:44 PM (GMT-08:00) To: "NANOG [nanog at nanog.org]" Subject: Regional Internet problems for AT&T in Wisconsin? We are having issues on our MIS Fiber dropping for 10-15 seconds at a time and getting reports for end users working remotely that residential u-verse internet stops working at the same time they are disconnected from work. From chrisp at softlayer.com Wed Jun 5 21:20:44 2013 From: chrisp at softlayer.com (Christopher Papandreou) Date: Wed, 5 Jun 2013 21:20:44 +0000 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: Hi Mikael, (Sorry if you are getting a duplicate copy of this.) In our network we had a couple of problems with RFC3069. Not all the hardware we currently use supports the RFC so we tried to come up with a solution that worked and didn't have us opening a lot of ERs (I know I reference 1 ER in the presentation but that's just 1 rather than a lot). We have more than just routers to consider (i.e. load balancers, firewalls, etc..) and don't want to lock ourselves in to any particular vendor. We also wanted a solution that we could easily migrate our customers into rather than completely taking them off line while we "retrofit" them into a new config (as probably would've been the case if we tried implementing RFC3069). Additionally, for a number of our customers we needed a solution that worked with a FHRP. I don't currently see a way to do that with RFC3069 but if I've missed something please let me know. Thanks, ChrisP. SoftLayer Technologies chrisp at softlayer.com -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Tuesday, June 04, 2013 5:34 PM To: nanog at nanog.org Subject: IP4 address conservation method I read: http://www.nanog.org/sites/default/files/tues.general.Papandreou.conservation.24.pdf I would like to point out RFC 3069. On most cisco equipment this is done using static routes and "ip unnumbered". So my question is basically: What am I missing? Why can't data center guys not build their network the same way regular ETTH is done? Either one vlan per customer and sharing the IPv4 subnet between several vlans, or having several customers in the same vlan but use antispoofing etc (IETF SAVI-wg functionality) to handle the security stuff? One vlan per customer also works very well with IPv6. -- Mikael Abrahamsson email: swmike at swm.pp.se From jfbeam at gmail.com Wed Jun 5 22:25:52 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 05 Jun 2013 18:25:52 -0400 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: On Wed, 05 Jun 2013 12:06:49 -0400, William Herrin wrote: > ... Since the Linux kernel already mishandles arp by > default, you're probably begging for unexpected behavior. Double down > on that if the customer controls the server image. I won't argue against calling Linux "wrong". However, the linux way of dealing with ARP is well tuned for "host" and not "router" duty. It's just not designed for the kernel to maintain huge arp tables for extended periods. Generally, a host speaks to very few L2 neighbors. Even a "server" tends to speak to few of it's L2 neighbors -- esp. for an internet service (www, ftp, irc, etc.). However, a ROUTER speaks to everything on most of it's links. As such, out-of-the-box, linux makes for a very BAD router... it's neighbor cache goes "stale" in 30s (avg), and entries are dropped on a scale of minutes. Real Routers(tm) hold on to arp's for *hours* -- because broadcast traffic requires CPU attention. That said, I do use a stripped debian box as an inter-vlan router. You don't want to see the pages of tweaks it's taken to stop it being a broadcast storm generator. (and no, "arpd" is stupid hack.) It's a beautiful thing to run "tcpdump ... broadcast" and see no packets! (And I'm not too happy with the BS 32 interface limit for multicast routing.) --Ricky From skhosla at neutraldata.com Wed Jun 5 22:27:59 2013 From: skhosla at neutraldata.com (Sameer Khosla) Date: Wed, 5 Jun 2013 22:27:59 +0000 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: <51AEC8A5.4030606@namor.ca> References: <51AEC8A5.4030606@namor.ca> Message-ID: <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> My personal favorite is the number of notices that we receive as DMCA takedown notices, citing the specific laws. Most of the notices come from people who are unable to comprehend that US Laws don't apply outside of the US. Sk. -----Original Message----- From: J [mailto:nanog at namor.ca] Subject: Re: Canadian Hosting Providers - how do you handle copyright and trademark complaints Voluntary notice-and-notice. Mostly automated based on ACNS reports that the majority do. Haven't really dealt any takedowns. On 13-06-04 06:44 PM, Landon wrote: > Hello, > > I'm wondering how other Canadian Hosting Providers handle copyright > and trademark complaints about customers on their network. I'm > thinking of just handling them the same as a DMCA notification should > be handled but since there's no forced takedown provisions in the > Canadian copyright act (that I know of?) it's difficult to say what is > better. I'd kind of like if our customers could enjoy some freedom > from the sledgehammer of the DMCA > *but* still being subject to copyright and trademark infringement laws > of course. I have to admit - this is my ignorance. I'm quite > familiar with the DMCA and the litigation that usually ensues during > american trademark infringement already but not Canadian copyright laws or trademark laws. > > I do intend to consult with a real lawyer about this eventually but I > want to have intelligent questions or suggestions before that happens. > > Also how are trademark infringement issues handled differently than > copyright issues in Canada? > From bill at herrin.us Wed Jun 5 23:15:38 2013 From: bill at herrin.us (William Herrin) Date: Wed, 5 Jun 2013 19:15:38 -0400 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: On Wed, Jun 5, 2013 at 6:25 PM, Ricky Beam wrote: > I won't argue against calling Linux "wrong". However, the linux way of > dealing with ARP is well tuned for "host" and not "router" duty. I love Linux and use it throughout my work but I can't tell you the number of times its ARP behavior has bitten me. If you send a packet to a VIP on a Linux box and it doesn't have an arp entry for the default gateway, the Linux box will send an arp request... with the vip as the source. That is just wrong. Wrong, wrong, wrong. Use the damn interface IP when you arp for something on that interface. If the router doesn't happen to like the bad arp (since the VIP isn't on the router's LAN) the router will ignore it. And your service will merrily pop up and down depending on whether the Linux box has any traffic to originate. Okay, I'm done venting now. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jabley at hopcount.ca Wed Jun 5 23:22:22 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 5 Jun 2013 19:22:22 -0400 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: References: Message-ID: Hi Landon, On 2013-06-04, at 19:44, Landon wrote: > I'm wondering how other Canadian Hosting Providers handle copyright and > trademark complaints about customers on their network. This is perhaps not directly related to your question (it concerns the application of copyright law in Canada on customers of an access provider) but it might give you some background. http://blogs.teksavvy.com/2012/11/30/copyrightlaw/ http://blogs.teksavvy.com/2012/12/10/firm-seeks-customer-information-in-copyright-infringement-lawsuit/ http://www.teksavvy.com/en/why-teksavvy/in-the-news/teksavvy-customer-notices/copyright-law-in-canada/copyright-faqs Joe From symack at gmail.com Wed Jun 5 23:40:30 2013 From: symack at gmail.com (Nick Khamis) Date: Wed, 5 Jun 2013 19:40:30 -0400 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> Message-ID: On 6/5/13, Sameer Khosla wrote: > My personal favorite is the number of notices that we receive as DMCA > takedown notices, citing the specific laws. > I'm not sure US copyright laws even apply to us here in Canada? What countries have no internet laws? N. From freimer at freimer.org Wed Jun 5 23:56:35 2013 From: freimer at freimer.org (Fred Reimer) Date: Wed, 5 Jun 2013 23:56:35 +0000 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: Message-ID: Canada signed the WIPO Copyright Treaty in 1997: http://www.wipo.int/treaties/en/ShowResults.jsp?lang=en&treaty_id=16 I don't know enough about Canadian law to say whether you need to ratify it or "accession" it before it becomes Canadian law? HTH, On 6/5/13 7:40 PM, "Nick Khamis" wrote: >On 6/5/13, Sameer Khosla wrote: >> My personal favorite is the number of notices that we receive as DMCA >> takedown notices, citing the specific laws. >> > >I'm not sure US copyright laws even apply to us here in Canada? >What countries have no internet laws? > >N. > From mysidia at gmail.com Thu Jun 6 02:28:22 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Jun 2013 21:28:22 -0500 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> Message-ID: On 6/5/13, Sameer Khosla wrote: > My personal favorite is the number of notices that we receive as DMCA > takedown notices, citing the specific laws. Heh... In an ideal world; you'd provide them an "agent" for copyright takedown requests, that they must send canadian postal mail to, with the request, and a notarized signed statement taken under penalty of perjury; no e-mail, because you can't e-mail a check, AND you can't authenticate the signature on an e-mail --- the sender can always repudiate it claiming the penalty doesn't apply to them, because that message was sent by accident (therefore false messages would not be under a penalty, therefore.... invalid notices). In addition, to the signed letter, require a check to cover processing and takedown ~ $100 processing per URL/domain/customer, required to process the legal request, plus 24 hours of time after check clears in order to give advance notification to the customer, and hosting fee for that customer for 14 days -- to cover the refund to the customer: after the customer has provided the provider with a copy of their counternotice. I suspect 'erroneous' and 'faulty' notices, or 'maliciously false' notices intended to suppress (strategic copyright letters against public participation), would greatly diminish: were all providers to require such a thing as a manually written signature from a human, for each letter: in a tangible paper form, not electronically transmitted. > Most of the notices come from people who are unable to comprehend that US > Laws don't apply outside of the US. > Sk. -- -JH From rdrake at direcpath.com Thu Jun 6 03:11:22 2013 From: rdrake at direcpath.com (rdrake) Date: Wed, 05 Jun 2013 23:11:22 -0400 Subject: IP4 address conservation method In-Reply-To: References: Message-ID: <33109133a6c3c4d592afc7c38150e976@mail.ipsek.net> On 2013-06-05 18:25, Ricky Beam wrote: > That said, I do use a stripped debian box as an inter-vlan router. > You > don't want to see the pages of tweaks it's taken to stop it being a > broadcast storm generator. (and no, "arpd" is stupid hack.) It's a > beautiful thing to run "tcpdump ... broadcast" and see no packets! > > (And I'm not too happy with the BS 32 interface limit for multicast > routing.) Actually, I'd love to see the pages of tweaks. Seems like it would be useful if I need to do this in the future :) Maybe drop it on the Debian wiki somewhere if you get the chance. Or at the least it would be nice to know what issues you're hitting now. You can tune the neighbor cache size and timeout via sysctl, so I would think it would be more of a memory limit than anything (unless the kernel uses a really poor hash lookup for arp entries) > > --Ricky --Robert From mysidia at gmail.com Thu Jun 6 03:30:01 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Jun 2013 22:30:01 -0500 Subject: IP4 address conservation method In-Reply-To: <33109133a6c3c4d592afc7c38150e976@mail.ipsek.net> References: <33109133a6c3c4d592afc7c38150e976@mail.ipsek.net> Message-ID: On 6/5/13, rdrake wrote: > On 2013-06-05 18:25, Ricky Beam wrote: [snip] >> (And I'm not too happy with the BS 32 interface limit for multicast >> routing.) > > Actually, I'd love to see the pages of tweaks. Seems like it would be > useful if I need to do this in the future :) The great thing about open sourced operating system kernels is if an arbitrary limit or system misbehavior causes you problems, or a tweak is needed to fix incorrect behavior, you can work out a patch to correct the situation -- or add an optional configuration setting to fix the problem, and submit the improvement to the maintainer in the form of a patch. :) -- -JH From r.engehausen at gmail.com Thu Jun 6 05:30:14 2013 From: r.engehausen at gmail.com (Roy) Date: Wed, 05 Jun 2013 22:30:14 -0700 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> Message-ID: <51B01E66.80707@gmail.com> On 6/5/2013 4:40 PM, Nick Khamis wrote: > On 6/5/13, Sameer Khosla wrote: >> My personal favorite is the number of notices that we receive as DMCA >> takedown notices, citing the specific laws. >> > I'm not sure US copyright laws even apply to us here in Canada? > What countries have no internet laws? > > N. > > US laws apply where ever the US says they apply. The question is how enforceable the US law is your country. There is probably a Hollywood lobbyist who is insisting on drone strikes on servers that offend the DMCA :-) From mysidia at gmail.com Thu Jun 6 06:41:46 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 6 Jun 2013 01:41:46 -0500 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: <51B01E66.80707@gmail.com> References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> <51B01E66.80707@gmail.com> Message-ID: On 6/6/13, Roy wrote: > US laws apply where ever the US says they apply. > The question is how enforceable the US law is your country. There is Copyrights owned by people in the US are recognized in Canada, due to Canada having signed the berne convention; by virtue of owning a US copyright, a person automatically owns the exclusive rights in Canada as well. If a rights holder's copyright is infringed by a subscriber/provider in canada, the rights holder might either go to court in Canada, and get judgement from Canadian court, or go to court in the US, get their judgement in the US, and then go visit a court in Canada, to get their US judgement recognized in Canada. The DMCA doesn't require takedowns. The DMCA provides a "safe harbour" for internet service providers and another safe harbour for information services to be protected from liability. For information services, the safe harbour is lost, if they do not follow the rules about takedown notices. It is not clear that an information service provider in Canada will enjoy the same protections and assurances, even if they follow the US safe harbor rules. Furthermore, it is not clear that a service provider in the US will enjoy the DMCA safe harbor protections, if the rights holder is in Canada, and the case against them is tried in a Canadian jurisdiction.... If you are in Country X, and you might have rightsholders in Country X or Country Y, Z, that might go after you on the way to one of your subscribers... You should probably retain some legal counsel for appropriate recommendations. -- -JH From Valdis.Kletnieks at vt.edu Thu Jun 6 07:03:06 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Jun 2013 03:03:06 -0400 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: Your message of "Thu, 06 Jun 2013 01:41:46 -0500." References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> <51B01E66.80707@gmail.com> Message-ID: <80197.1370502186@turing-police.cc.vt.edu> On Thu, 06 Jun 2013 01:41:46 -0500, Jimmy Hess said: > On 6/6/13, Roy wrote: > > US laws apply where ever the US says they apply. > > The question is how enforceable the US law is your country. There is > > Copyrights owned by people in the US are recognized in Canada, due to > Canada having signed the berne convention; by virtue of owning a US > copyright, a person automatically owns the exclusive rights in Canada > as well. I beleive Great Britain is also a Berne signatory, which makes this legislative gem from London rather... problematic: http://copyrightblog.co.uk/2013/04/29/d-err-cretins-1-creators-0/ (tl:dr vastly oversimplified - if you can't easily identify the copyright owner, it's free for the taking, rather than not usable without permission. So if you posted an awesome sunset picture from your vacation on Flickr, and somebody reshared it on another site, an advertising agency can find it, not be able to find you easily, and run with it as the artwork for an ad campaign) Some lawyers are about to get rich. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From blake at ispn.net Thu Jun 6 14:29:56 2013 From: blake at ispn.net (Blake Hudson) Date: Thu, 06 Jun 2013 09:29:56 -0500 Subject: IP4 address conservation method In-Reply-To: <20130605144414.GC7129@dan.olp.net> References: <20130605144414.GC7129@dan.olp.net> Message-ID: <51B09CE4.90408@ispn.net> Dan White wrote the following on 6/5/2013 9:44 AM: > On 06/05/13 00:34 +0200, Mikael Abrahamsson wrote: >> >> I read: >> >> http://www.nanog.org/sites/default/files/tues.general.Papandreou.conservation.24.pdf >> >> >> I would like to point out RFC 3069. On most cisco equipment this is >> done using static routes and "ip unnumbered". >> >> So my question is basically: What am I missing? Why can't data center >> guys not build their network the same way regular ETTH is done? >> Either one vlan per customer and sharing the IPv4 subnet between >> several vlans, or having several customers in the same vlan but use >> antispoofing etc (IETF SAVI-wg functionality) to handle the security >> stuff? > > VLAN-per-subscriber (1 customer per VLAN), can require more costly > routing > equipment, particularly if you're performing double tagging (outer tag > for > switch, inner tag for customer). Sharing an IPv4 subnet among > customers is > appropriate for residential and small business services, which is how we > typically deliver service. But may be less appropriate for larger > business > customers (and I presume hosting customers) where the number of IPs is > large enough that you're throwing away less addresses ratio-wise. > Generally > the simpler deployment model wins out in that type of scenario. Also, the > 'ip unnumbered' approach may require some layer-3 security features. > One thing not mentioned so far in this discussion is using PPPoE or some other tunnel/VPN technology for efficient IP utilization. The result could be zero wasted IP addresses without the need to resort to non-routable IP addresses in a customer's path (as the pdf suggested) and without some of the quirkyness or vendor lock-in of using ip unnumbered. PPPoE (and other VPNs) have many of the same downsides as mentioned above though, they require routing cost and increase the complexity of the network. The question becomes which deployment has more cost: the simple, yet wasteful, design or the efficient, but complex, design. --Blake From owen at delong.com Thu Jun 6 18:07:21 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jun 2013 11:07:21 -0700 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: <51B01E66.80707@gmail.com> References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> <51B01E66.80707@gmail.com> Message-ID: On Jun 5, 2013, at 22:30 , Roy wrote: > On 6/5/2013 4:40 PM, Nick Khamis wrote: >> On 6/5/13, Sameer Khosla wrote: >>> My personal favorite is the number of notices that we receive as DMCA >>> takedown notices, citing the specific laws. >>> >> I'm not sure US copyright laws even apply to us here in Canada? >> What countries have no internet laws? >> >> N. >> >> > > US laws apply where ever the US says they apply. > How do you figure that? The US power to enforce US law is limited to: 1. US Citizens (pretty much wherever they are, unfortunately) 2. Things that happen within the borders of the united states 3. Transactions involving entities within the borders of the united states or citizens of the US. Beyond that, their power is supposed to be pretty limited. > The question is how enforceable the US law is your country. There is probably a Hollywood lobbyist who is insisting on drone strikes on servers that offend the DMCA :-) One would hope that we would not be so stupid as to carry out a drone strike against Canada for DMCA. I'm pretty sure that the current administration would not authorize that. As to the previous administration, your guess is as good as mine. Owen From bjorn at mork.no Thu Jun 6 19:00:12 2013 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 06 Jun 2013 21:00:12 +0200 Subject: IP4 address conservation method In-Reply-To: (William Herrin's message of "Wed, 5 Jun 2013 19:15:38 -0400") References: Message-ID: <87d2rzyshv.fsf@nemi.mork.no> William Herrin writes: > On Wed, Jun 5, 2013 at 6:25 PM, Ricky Beam wrote: >> I won't argue against calling Linux "wrong". However, the linux way of >> dealing with ARP is well tuned for "host" and not "router" duty. > > I love Linux and use it throughout my work but I can't tell you the > number of times its ARP behavior has bitten me. If you send a packet > to a VIP on a Linux box and it doesn't have an arp entry for the > default gateway, the Linux box will send an arp request... with the > vip as the source. That is just wrong. Wrong, wrong, wrong. Use the > damn interface IP when you arp for something on that interface. If the > router doesn't happen to like the bad arp (since the VIP isn't on the > router's LAN) the router will ignore it. And your service will merrily > pop up and down depending on whether the Linux box has any traffic to > originate. Did you try setting sys.net.ipv4.conf.all.arp_announce=2 ? Yes, the system default may be tuned for host/desktop usage, but it's not like you *have* to use the system default. Tweak it as you like. And if there isn't enough knobs, then you can always add another one. You have the source code. Bj?rn From r.engehausen at gmail.com Thu Jun 6 19:01:15 2013 From: r.engehausen at gmail.com (Roy) Date: Thu, 06 Jun 2013 12:01:15 -0700 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> <51B01E66.80707@gmail.com> Message-ID: <51B0DC7B.3090805@gmail.com> On 6/6/2013 11:07 AM, Owen DeLong wrote: > On Jun 5, 2013, at 22:30 , Roy wrote: > >> On 6/5/2013 4:40 PM, Nick Khamis wrote: >>> On 6/5/13, Sameer Khosla wrote: >>>> My personal favorite is the number of notices that we receive as DMCA >>>> takedown notices, citing the specific laws. >>>> >>> I'm not sure US copyright laws even apply to us here in Canada? >>> What countries have no internet laws? >>> >>> N. >>> >>> >> US laws apply where ever the US says they apply. >> > How do you figure that? A government can say anything it wants to > > The US power to enforce US law is limited to: > > 1. US Citizens (pretty much wherever they are, unfortunately) > 2. Things that happen within the borders of the united states > 3. Transactions involving entities within the borders of the united states or > citizens of the US. > > Beyond that, their power is supposed to be pretty limited. Limited by who? A government can pass any law that it wants to and apply it to anyone. It then becomes a question of how it enforces that law and that is limited by its ability to project power. See http://en.wikipedia.org/wiki/The_Mouse_That_Roared > ... > From owen at delong.com Thu Jun 6 19:21:11 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Jun 2013 12:21:11 -0700 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: <51B0DC7B.3090805@gmail.com> References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> <51B01E66.80707@gmail.com> <51B0DC7B.3090805@gmail.com> Message-ID: <477EAD7E-9113-4FCD-A662-09D384991174@delong.com> On Jun 6, 2013, at 12:01 , Roy wrote: > On 6/6/2013 11:07 AM, Owen DeLong wrote: >> On Jun 5, 2013, at 22:30 , Roy wrote: >> >>> On 6/5/2013 4:40 PM, Nick Khamis wrote: >>>> On 6/5/13, Sameer Khosla wrote: >>>>> My personal favorite is the number of notices that we receive as DMCA >>>>> takedown notices, citing the specific laws. >>>>> >>>> I'm not sure US copyright laws even apply to us here in Canada? >>>> What countries have no internet laws? >>>> >>>> N. >>>> >>>> >>> US laws apply where ever the US says they apply. >>> >> How do you figure that? > > A government can say anything it wants to That's not what you said. You said "US laws apply wherever the US says they apply." I agree that the US government can claim its laws apply wherever they wish to clam they apply. That is a far cry from having them ACTUALLY apply there. > >> >> The US power to enforce US law is limited to: >> >> 1. US Citizens (pretty much wherever they are, unfortunately) >> 2. Things that happen within the borders of the united states >> 3. Transactions involving entities within the borders of the united states or >> citizens of the US. >> >> Beyond that, their power is supposed to be pretty limited. > > Limited by who? > Unfortunately, that is the real crux of the matter, now, isn't. However, at least on a theoretical level, the government should be limited by the powers granted to it by the constitution and by the voters. > A government can pass any law that it wants to and apply it to anyone. It then becomes a question of how it enforces that law and that is limited by its ability to project power. See Yes and no. Depends somewhat on the structure of the government. In the case of the united States, Congress can pass any bill that they want, however, absent a 2/3rd majority, it then needs signature of the president. Beyond that, you still have the issue that the judiciary may strike that law down as unconstitutional. As an example, I'm quite certain that if the US Congress passed a law stating that we would tax all Spanish citizens residing on Spanish soil $100 per year in perpetuity, that law would have the following problems: 1. The president would probably never sign it. 2. If the president signed it, the supreme court would likely demonstrate that it can, in fact, act with great haste in repealing it. 3. I doubt that any Spanish citizen on Spanish soil would have any belief whatsoever that the law actually applied to them. 4. For any meaningful value of the word "apply", the law would not actually apply to said citizens. Finally when it came to enforcing the law, I doubt that the US tax collectors and law enforcement officers would be welcomed into Spain with open arms to carry out this application of law. While the US may well be capable of taking on the EU militarily, I suspect it would be very costly to do so and it certainly wouldn't be well supported by the citizenry which I believe would make it difficult for the government to sustain said revenue collection campaign. Owen From Valdis.Kletnieks at vt.edu Thu Jun 6 19:36:12 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Jun 2013 15:36:12 -0400 Subject: Canadian Hosting Providers - how do you handle copyright and trademark complaints In-Reply-To: Your message of "Thu, 06 Jun 2013 12:21:11 -0700." <477EAD7E-9113-4FCD-A662-09D384991174@delong.com> References: <51AEC8A5.4030606@namor.ca> <49A81EB09F493442B6D259E36251192C01241F076D@ndcc-exch1.neutraldata.com> <51B01E66.80707@gmail.com> <51B0DC7B.3090805@gmail.com> <477EAD7E-9113-4FCD-A662-09D384991174@delong.com> Message-ID: <122843.1370547372@turing-police.cc.vt.edu> On Thu, 06 Jun 2013 12:21:11 -0700, Owen DeLong said: > As an example, I'm quite certain that if the US Congress passed a law stating > that we would tax all Spanish citizens residing on Spanish soil $100 per year > in perpetuity, that law would have the following problems: Skip the hypotheticals. Go read Lincoln's Emancipation Proclamation, and pay *very* careful attention to the exact wording, and where it applied, and where it didn't apply. tl;dr: What they taught you in history and what it actually says are probably different, unless you had a *really* cool history teacher. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Thu Jun 6 21:19:26 2013 From: bill at herrin.us (William Herrin) Date: Thu, 6 Jun 2013 17:19:26 -0400 Subject: IP4 address conservation method In-Reply-To: <87d2rzyshv.fsf@nemi.mork.no> References: <87d2rzyshv.fsf@nemi.mork.no> Message-ID: On Thu, Jun 6, 2013 at 3:00 PM, Bj?rn Mork wrote: > William Herrin writes: >> On Wed, Jun 5, 2013 at 6:25 PM, Ricky Beam wrote: >>> I won't argue against calling Linux "wrong". However, the linux way of >>> dealing with ARP is well tuned for "host" and not "router" duty. >> >> I love Linux and use it throughout my work but I can't tell you the >> number of times its ARP behavior has bitten me. If you send a packet >> to a VIP on a Linux box and it doesn't have an arp entry for the >> default gateway, the Linux box will send an arp request... with the >> vip as the source. That is just wrong. Wrong, wrong, wrong. Use the >> damn interface IP when you arp for something on that interface. If the >> router doesn't happen to like the bad arp (since the VIP isn't on the >> router's LAN) the router will ignore it. And your service will merrily >> pop up and down depending on whether the Linux box has any traffic to >> originate. > > Did you try setting sys.net.ipv4.conf.all.arp_announce=2 ? Yes, of course I changed the sysctl. Yes of course that worked. Every time I've run in to the problem. On server after server after server. > Yes, the system default may be tuned for host/desktop usage No, it doesn't default to reasonable desktop settings for ARP... it defaults to a version of wrong that on a desktop with one NIC and one IP doesn't happen to break anything. It'd be nice if it defaulted to RFC compliant instead and let the few folks with wacky needs move it off the standard behavior. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Thu Jun 6 23:35:42 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 6 Jun 2013 19:35:42 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project Message-ID: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Has fingers directly in servers of top Internet content companies, dates to 2007. Happily, none of the companies listed are transport networks: http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Fri Jun 7 00:04:43 2013 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 6 Jun 2013 17:04:43 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: > Has fingers directly in servers of top Internet content companies, > dates to 2007. Happily, none of the companies listed are transport > networks: > > > http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > I've always just assumed that if it's in electronic form, someone else is either reading it now, has already read it, or will read it as soon as I walk away from the screen. Much less stress in life that way. ^_^ Matt From alex at corp.nac.net Fri Jun 7 00:07:57 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 6 Jun 2013 20:07:57 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> > > Has fingers directly in servers of top Internet content companies, > > dates to 2007. Happily, none of the companies listed are transport > > networks: > > I've always just assumed that if it's in electronic form, someone else is either > reading it now, has already read it, or will read it as soon as I walk away from > the screen. So, you are comfortable just giving up your right to privacy? It's just the way it is? I'm sorry, I am not as accepting of that fact as you are. I am disappointed and disgusted that this is, and has been, going on. Our government is failing us. From goemon at anime.net Fri Jun 7 00:16:17 2013 From: goemon at anime.net (goemon at anime.net) Date: Thu, 6 Jun 2013 17:16:17 -0700 (PDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, 6 Jun 2013, Matthew Petach wrote: > Much less stress in life that way. ^_^ complacency is always the easiest path. many abuse@ mailboxes follow the same policy. -Dan From Valdis.Kletnieks at vt.edu Fri Jun 7 00:18:46 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Jun 2013 20:18:46 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Your message of "Thu, 06 Jun 2013 17:04:43 -0700." References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <136449.1370564326@turing-police.cc.vt.edu> On Thu, 06 Jun 2013 17:04:43 -0700, Matthew Petach said: > I've always just assumed that if it's in electronic form, > someone else is either reading it now, has already read > it, or will read it as soon as I walk away from the screen. Things like PGP, TrueCrypt, and Tor help a lot in leveling the playing field at least somewhat. But I'm sure you all knew that already. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jof at thejof.com Fri Jun 7 00:22:36 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 6 Jun 2013 17:22:36 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> Message-ID: Agreed. I can already pretty much just assume this widespread surveillance is going on. The Bluffdale, Utah facility isn't being built to store nothing. It's happening whether we like it or not. When I care about my privacy, I know that I have to take matters into my own hands. GnuPG and TLS are mine and your friends. Use them together. Use them in peace. Cheers, jof (0x8F8CAD3D) On Thu, Jun 6, 2013 at 5:07 PM, Alex Rubenstein wrote: >> > Has fingers directly in servers of top Internet content companies, >> > dates to 2007. Happily, none of the companies listed are transport >> > networks: >> >> I've always just assumed that if it's in electronic form, someone else is either >> reading it now, has already read it, or will read it as soon as I walk away from >> the screen. > > > So, you are comfortable just giving up your right to privacy? It's just the way it is? > > I'm sorry, I am not as accepting of that fact as you are. I am disappointed and disgusted that this is, and has been, going on. Our government is failing us. > > > > > From deleskie at gmail.com Fri Jun 7 01:06:44 2013 From: deleskie at gmail.com (jim deleskie) Date: Thu, 6 Jun 2013 22:06:44 -0300 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: Knowing its going on, knowing nothing online is secret != OK with it, it mealy understand the way things are. -jim On Thu, Jun 6, 2013 at 9:16 PM, wrote: > On Thu, 6 Jun 2013, Matthew Petach wrote: > >> Much less stress in life that way. ^_^ >> > > complacency is always the easiest path. > > many abuse@ mailboxes follow the same policy. > > -Dan > > From mathews at hawaii.edu Fri Jun 7 01:12:35 2013 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 06 Jun 2013 21:12:35 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <51B13383.2050500@hawaii.edu> On 6/6/2013 7:35 PM, Jay Ashworth wrote: > [ ..... ] Happily, none of the companies listed are transport > networks: > > [ .... ] > > Cheers, > -- jra Could you be certain that TWC, Comcast, Qwest/CenturyLink could not be involved? From Valdis.Kletnieks at vt.edu Fri Jun 7 01:22:56 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Jun 2013 21:22:56 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Your message of "Thu, 06 Jun 2013 21:12:35 -0400." <51B13383.2050500@hawaii.edu> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B13383.2050500@hawaii.edu> Message-ID: <139392.1370568176@turing-police.cc.vt.edu> On Thu, 06 Jun 2013 21:12:35 -0400, "Robert Mathews (OSIA)" said: > On 6/6/2013 7:35 PM, Jay Ashworth wrote: > > [ ..... ] Happily, none of the companies listed are transport networks: > Could you be certain that TWC, Comcast, Qwest/CenturyLink could not be > involved? Pay attention. None of the ones *listed* are transport networks. Doesn't mean they're not involved but unlisted (as of yet). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jeff-kell at utc.edu Fri Jun 7 01:27:48 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 6 Jun 2013 21:27:48 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <139392.1370568176@turing-police.cc.vt.edu> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B13383.2050500@hawaii.edu> <139392.1370568176@turing-police.cc.vt.edu> Message-ID: <51B13714.3090800@utc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/6/2013 9:22 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 06 Jun 2013 21:12:35 -0400, "Robert Mathews (OSIA)" said: >> On 6/6/2013 7:35 PM, Jay Ashworth wrote: >>> [ ..... ] Happily, none of the companies listed are transport networks: > >> Could you be certain that TWC, Comcast, Qwest/CenturyLink could not be >> involved? > > Pay attention. None of the ones *listed* are transport networks. > Doesn't mean they're not involved but unlisted (as of yet). > Umm... CALEA. They've *already* had access for quite some time. Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlGxNxQACgkQiwXJq373XhZ3eACgyBgsW1iG2o2Vzqt0+XKHqRcc YOgAoIAObRb9KxUcTXlTa3eAi+exIhRG =FMTZ -----END PGP SIGNATURE----- From bicknell at ufp.org Fri Jun 7 01:28:18 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 6 Jun 2013 20:28:18 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 6, 2013, at 8:06 PM, jim deleskie wrote: > Knowing its going on, knowing nothing online is secret != OK with it, it > mealy understand the way things are. While there's a whole political aspect of electing people who pass better laws, NANOG is not a political action forum. However many of the people on NANOG are in positions to affect positive change at their respective employers. - Implement HTTPS for all services. - Implement PGP for e-mail. - Implement S/MIME for e-mail. - Build cloud services that encrypt on the client machine, using a key that is only kept on the client machine. - Create better UI frameworks for managing keys and identities. - Align data retention policies with the law. - Scrutinize and reject defective government legal requests. - When allowed by law, charge law enforcement for access to data. - Lobby for more sane laws applied to your area of business. The high tech industry has often made the government's job easy, not by intention but by laziness. Keeping your customer's data secure should be a proud marketing point. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mathews at hawaii.edu Fri Jun 7 01:46:17 2013 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 06 Jun 2013 21:46:17 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <139392.1370568176@turing-police.cc.vt.edu> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B13383.2050500@hawaii.edu> <139392.1370568176@turing-police.cc.vt.edu> Message-ID: <51B13B69.3020408@hawaii.edu> On 6/6/2013 9:22 PM, Valdis.Kletnieks at vt.edu wrote: > Pay attention. None of the ones *listed* are transport networks. > Doesn't mean they're not involved but unlisted (as of yet). *Vladis: * I thank you for waking me up in class! I am impressed - your finely tuned language hair "has picked-up" the distinctions. Further, I am quite certain that the "listing" will be more inclusive/explicative in the next round. /************************************************ * Dr. Robert Mathews, D.Phil. * Distinguished Senior Research Scholar * National Security Affairs & U.S Industrial Preparedness * Office of Scientific Inquiry and Applications * University of Hawai'i * Secure Messaging/Voice/Video available/ From thepacketmaster at hotmail.com Fri Jun 7 02:13:46 2013 From: thepacketmaster at hotmail.com (James Smith) Date: Thu, 6 Jun 2013 22:13:46 -0400 Subject: Verizon/Alter.net issues Message-ID: Anyone know if Verizon/Alter.net is experiencing some issues? We're seeing some big latency issues to one of our sites in the Pacific. 10 0.xe-11-2-0.GW2.SEA1.ALTER.NET (152.63.105.202) 50 msec 416-345-2609-gw.customer.alter.net (157.130.180.90) 430 msec 0.xe-11-2-0.GW2.SEA1.ALTER.NET (152.63.105.202) 50 msec 11 * 416-345-2609-gw.customer.alter.net (157.130.180.90) 420 msec * 12 ge3-4.hcap8-tor.bb.allstream.net (199.212.168.86) 450 msec 450 msec * James From streiner at cluebyfour.org Fri Jun 7 02:23:19 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 6 Jun 2013 22:23:19 -0400 (EDT) Subject: Verizon/Alter.net issues In-Reply-To: References: Message-ID: On Thu, 6 Jun 2013, James Smith wrote: > Anyone know if Verizon/Alter.net is experiencing some issues? We're > seeing some big latency issues to one of our sites in the Pacific. > > 416-345-2609-gw.customer.alter.net (157.130.180.90) 420 > msec * > 12 ge3-4.hcap8-tor.bb.allstream.net (199.212.168.86) 450 msec 450 msec * My first thought would be congestion in one direction or the other on that link between VZB and Allstream. Those would be the best places to start your investigation, if you're a customer of either provider. jms From mathews at hawaii.edu Fri Jun 7 02:46:12 2013 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 06 Jun 2013 22:46:12 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <51B14974.2000900@hawaii.edu> On 6/6/2013 9:28 PM, Leo Bicknell wrote: > However many of the people on NANOG are in positions to affect positive change at their respective employers. > > - Implement HTTPS for all services. > - Implement PGP for e-mail. > - Implement S/MIME for e-mail. > - Build cloud services that encrypt on the client machine, using a key that is only kept on the client machine. > - Create better UI frameworks for managing keys and identities. > - Align data retention policies with the law. > - Scrutinize and reject defective government legal requests. > - When allowed by law, charge law enforcement for access to data. > - Lobby for more sane laws applied to your area of business. Being an AGENT or AGENCY of Change is not an activity most are CAPABLE of effectively thinking about, let alone acting upon. The act of effectively initiating change will take far more than passing a few emails, memos, or having a few lengthy conversation at the water cooler. Implementation of some, most, or all of the offered suggestions - while good (even essential), involves wholistic thinking, planning, proper budgeting, coordinating expertise and tasking - well beyond present day operational limits for a lot of shops. > The high tech industry has often made the government's job easy, not by intention but by laziness. Keeping your customer's data secure should be a proud marketing point. Laziness aside, permit me to humbly note that emphasis on COMPLIANCE (with sane or insane laws) alone, neither ENSURES, nor ASSURES security for oneself or one's customers. All the best /-- ************************************************ * Dr. Robert Mathews, D.Phil. * Distinguished Senior Research Scholar * National Security Affairs & U.S Industrial Preparedness * Office of Scientific Inquiry and Applications * University of Hawai'i * Secure Messaging/Voice/Video available/ From ag4ve.us at gmail.com Fri Jun 7 03:19:48 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 6 Jun 2013 23:19:48 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B13714.3090800@utc.edu> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B13383.2050500@hawaii.edu> <139392.1370568176@turing-police.cc.vt.edu> <51B13714.3090800@utc.edu> Message-ID: On Jun 6, 2013 9:30 PM, "Jeff Kell" wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 6/6/2013 9:22 PM, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 06 Jun 2013 21:12:35 -0400, "Robert Mathews (OSIA)" said: > >> On 6/6/2013 7:35 PM, Jay Ashworth wrote: > >>> [ ..... ] Happily, none of the companies listed are transport > networks: > > > >> Could you be certain that TWC, Comcast, Qwest/CenturyLink could not be > >> involved? > > > > Pay attention. None of the ones *listed* are transport networks. > > Doesn't mean they're not involved but unlisted (as of yet). > > > > Umm... CALEA. They've *already* had access for quite some time. > AFAIK, CALEA doesn't by default collect data for everyone on their network. You use the word 'access' which doesn't convey anything to me - a network switch might have access to all the data on the network but you might only see some of it. Should law enforcement have easy access to some data? Absolutely. If my phone is ever stolen, I want the next cop car driving by the thief's location to retrieve my phone and pick up the thief. But I'd prefer some fat dude in an office not see pictures my grandmother emails to me. Is there a way to do both? Sure. The way I'd like it done is to make all requests for data open and respond to FOIA requests within a month. Or, easier option - any data LE requests goes online. This way, if you have a reason to request data for a whole state and your family happens to live there, you know that the conversation between your family will also be publicly available so will be more likely to limit the scope. From mis at seiden.com Fri Jun 7 03:38:04 2013 From: mis at seiden.com (Mark Seiden) Date: Thu, 6 Jun 2013 20:38:04 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 6, 2013, at 6:28 PM, Leo Bicknell wrote: > > On Jun 6, 2013, at 8:06 PM, jim deleskie wrote: > >> Knowing its going on, knowing nothing online is secret != OK with it, it >> mealy understand the way things are. > > While there's a whole political aspect of electing people who pass better laws, NANOG is not a political action forum. > > However many of the people on NANOG are in positions to affect positive change at their respective employers. > > - Implement HTTPS for all services. not just externally exposed services -- or use some form of strong crypto on your inter-data center traffic. > - Implement PGP for e-mail. > - Implement S/MIME for e-mail. > - Build cloud services that encrypt on the client machine, using a key that is only kept on the client machine. > - Create better UI frameworks for managing keys and identities. > - Align data retention policies with the law. > - Scrutinize and reject defective government legal requests. > - When allowed by law, charge law enforcement for access to data. > - Lobby for more sane laws applied to your area of business. > > The high tech industry has often made the government's job easy, not by intention but by laziness. Keeping your customer's data secure should be a proud marketing point. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > From mysidia at gmail.com Fri Jun 7 04:06:12 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 6 Jun 2013 23:06:12 -0500 Subject: IP4 address conservation method In-Reply-To: References: <87d2rzyshv.fsf@nemi.mork.no> Message-ID: On 6/6/13, William Herrin wrote: >> Yes, the system default may be tuned for host/desktop usage > No, it doesn't default to reasonable desktop settings for ARP... it > defaults to a version of wrong that on a desktop with one NIC and one > IP doesn't happen to break anything. It'd be nice if it defaulted to > RFC compliant instead and let the few folks with wacky needs move it > off the standard behavior. I find Linux's arp defaults annoying also, but they're not "wrong" or "non-RFC compliant". An interpretation that applies in the design of Linux networking, is that IP addresses belong to the host, and IP addresses do not belong to IP interfaces (excepting 'scope local' IPs, such as IPv6 link-local). An interface has a source IP address assigned to it for outgoing traffic from the host. All destination IPs for incoming traffic to the host belong to no specific interface on the host. Any IP address added to any interface, belongs to the host as a valid destination IP, and can be ARP'ed on any of the host's IP interfaces. Excepting a firewall rule to the contrary, traffic for any of the host's destination IPs can come in any interface. This is a totally valid and correct way of a host managing that host's IP addresses. However, it is a tad inconvenient for the administrator, in some real-world circumstances; mainly unusual configs such as servers with multiple NICs plugged into different subnets, or servers behind a load balancer. And the ARP behavior is counterintuitive, because regardless of that fact, in Linux you _still_ configure IP addresses on interfaces; every interface has a preferred IP, and maybe some alias IPs. In most case's Linux's choice not to restrict ARP to a specific interface bound to the IP is not useful. However, it is useful if you have a host that has multiple NICs plugged into the same network. The kernel has its defaults, but distribution vendors such as Redhat/Ubuntu/Debian, are free to supply their own defaults through sysctl.conf or their NetworkManager packages or network configuration scripts... It's interesting to note they have so far chosen to go (mostly) with the defaults. I'm sure most people do not have a problem, or else, someone would have updated the defaults by now > -Bill -- -JH From j at arpa.com Fri Jun 7 05:25:35 2013 From: j at arpa.com (jamie rishaw) Date: Fri, 7 Jun 2013 00:25:35 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: Just wait until we find out dark and lit private fiber is getting vampired. -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. arpa / arpa labs From bill at herrin.us Fri Jun 7 05:36:45 2013 From: bill at herrin.us (William Herrin) Date: Fri, 7 Jun 2013 01:36:45 -0400 Subject: IP4 address conservation method In-Reply-To: References: <87d2rzyshv.fsf@nemi.mork.no> Message-ID: On Fri, Jun 7, 2013 at 12:06 AM, Jimmy Hess wrote: > On 6/6/13, William Herrin wrote: >>> Yes, the system default may be tuned for host/desktop usage >> No, it doesn't default to reasonable desktop settings for ARP... it >> defaults to a version of wrong that on a desktop with one NIC and one >> IP doesn't happen to break anything. It'd be nice if it defaulted to >> RFC compliant instead and let the few folks with wacky needs move it >> off the standard behavior. > > An interpretation that applies in the design of Linux networking, is > that IP addresses belong to the host, and IP addresses do not belong > to IP interfaces (excepting 'scope local' IPs, such as IPv6 > link-local). > > I find Linux's arp defaults annoying also, but they're not "wrong" > or "non-RFC compliant". Hi Jimmy, I reread RFC 826 and much to my annoyance it doesn't directly speak to this question. But it does speak to it in a backhanded way, setting a requirement that makes sense only if the ARP source address is part of the subnet on which the arp request is made. 826 says, "The Address Resolution module then sets the [...] ar$spa with the protocol address of itself." "Itself" is never explicitly defined. But 826 also says, "The sender hardware address and sender protocol address are absolutely necessary. It is these fields that get put in a translation table." It says that in a context that appears to apply to both request and response ARPs. RFC 5227 confirms this interpretation, insisting that gratuitous arps and defensive arps are arp-request packets, not arp-reply packets. That would yield a nonsensical activity from the ARP request message *unless* the source layer 3 address is part of the subnet defined on that layer 2 network. Not just any source address will do; it must be one of the machine's addresses that would form a valid entry in the target's arp cache. Linux's default behavior copies the source IP address of the outgoing IP packet to the ARP request, regardless of whether that IP is valid for that particular LAN subnet. So, I reiterate that Linux's default for selecting the ARP source address does not match what the RFC says. Postel's law cuts Linux some slack with respect to accepting ARPs on the wrong interface. Even though that's almost always the wrong thing to do. On the other hand, it reinforces the errant nature of Linux's behavior with respect to source address selection when originating ARP requests. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tvhawaii at shaka.com Fri Jun 7 05:56:49 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 6 Jun 2013 19:56:49 -1000 Subject: Wackie 'ol Friday. Message-ID: <55B908F4EEBF47F7813EEFE2E2483EC1@owner59e1f1502> Anyone besides jra remember the last Super Bowl? Better this year? Worse? I'm sure whomever is listening in would like to know as well. http://www.multichannel.com/blogs/translation-please/multicast-unicast-and-super-bowl-problem From mis at seiden.com Fri Jun 7 05:57:07 2013 From: mis at seiden.com (Mark Seiden) Date: Thu, 6 Jun 2013 22:57:07 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> On Jun 6, 2013, at 10:25 PM, jamie rishaw wrote: > > Just wait until we find out dark and lit private fiber is getting vampired. > > well, that's exactly and the only thing what would not surprise me, given the eff suit and mark klein's testimony about room 421a full of narus taps. mark klein is an utterly convincing and credible guy on this subject of tapping transit traffic. but the ability to assemble intelligence out of taps on providers' internal connections would require reverse engineering the ever changing protocols of all of those providers. and at least at one of the providers named, where i worked on security and abuse, it was hard for us, ourselves, to quickly mash up data from various internal services and lines of business that were almost completely siloed -- data typically wasn't exposed widely and stayed within a particular server or data center absent a logged in session by the user. were these guys scraping the screens of non-ssl sessions of interest in real time? with asymmetric routing, it's hard to reassemble both sides of a conversation, say in IM. one side might come in via a vip and the other side go out through the default route, shortest path. only *on* a specific internal server might you see the entire conversation. typically only the engineers who worked on that application would log on or even know what to look for. and also, only $20m/year? in my experience, the govt cannot do anything like this addressing even a single provider for that little money. and pretty much denials all around. so at the moment, i don't believe it. (and i hope it's not true, or i might have to leave this industry in utter disgust because i didn't notice this going on in about 8 years at that provider and it was utterly contrary to the expressed culture. take up beekeeping, or alcohol, or something.). > > > -- > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > arpa / arpa labs From rob at invaluement.com Fri Jun 7 06:34:00 2013 From: rob at invaluement.com (Rob McEwen) Date: Fri, 07 Jun 2013 02:34:00 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <51B17ED8.2030604@invaluement.com> The "oh well, it happens, who cares, guess you need PGP" comments on this thread are idiotic. Some of you would benefit from reading the text of the 4th Amendment: "The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized" The Washington Post mentioned some "safeguards"... but those were pathetic. Why? They seemed to be similar to the following analogy: "we'll keep that video camera in your home, recording your every move, and we promise we'll close our eyes when reviewing the tape whenever it shows you naked". THAT is essentially what they're saying. The access described by both the Washington Post and The Guardian is essentially unfettered/unmetered/unmonitored. Just as a doctors take the "hippocratic oath" to maintain decent standards which are to the benefit of modern civilization... shouldn't IT/Networking/Internet professionals (NANOG readers!!!) have standards that, hopefully, distinguishes us from... say... the State-run ISP of North Korea. And if these allegations are true... then... I have a difficult time believing that there was no "quid pro quo" involved. Especially since such companies risk a backlash and huge loss of customers if/when this gets out. So I don't think they'd do this without some kind of return in favor. Did they get special tax treatment? Tarp money of any kind (maybe to a parent company)? Easing of regulation enforcement? If there was "quid pro quo", then what a bunch of F'ing whores, selling their own customers down the river... to make a buck... and potentially contributing to a future tyranny. Sure, the US government probably only use this to catch the bad guys today... but what would a *corrupt* adminstration do with such data in the future... stick the IRS on their political enemies? (oh, wait, that just happened... hmmmm) -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-932 From tore at fud.no Fri Jun 7 06:35:57 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 07 Jun 2013 08:35:57 +0200 Subject: IP4 address conservation method In-Reply-To: <51B09CE4.90408@ispn.net> References: <20130605144414.GC7129@dan.olp.net> <51B09CE4.90408@ispn.net> Message-ID: <51B17F4D.2060500@fud.no> * Blake Hudson > One thing not mentioned so far in this discussion is using PPPoE or some > other tunnel/VPN technology for efficient IP utilization. The result > could be zero wasted IP addresses without the need to resort to > non-routable IP addresses in a customer's path (as the pdf suggested) > and without some of the quirkyness or vendor lock-in of using ip > unnumbered. > > PPPoE (and other VPNs) have many of the same downsides as mentioned > above though, they require routing cost and increase the complexity of > the network. The question becomes which deployment has more cost: the > simple, yet wasteful, design or the efficient, but complex, design. Or, simply just use IPv6, and use a stateless translation service located in the core network to provide IPv4 connectivity to the public Internet services. This allows for 100% efficient utilisation of whatever IPv4 addresses you have left - nothing needs to go to waste due to router interfaces, subnet power of 2 overhead, internal servers/services that have no Internet-available services, etc...all without requiring you to do anything special on the server/application stacks to support it (like set up tunnel endpoints), add dual-stack complexity into your network, or introduce any form of stateful translation or VPN service into your network. Here's some more resources: http://fud.no/talks/20130321-V6_World_Congress-The_Case_for_IPv6_Only_Data_Centres.pdf http://tools.ietf.org/html/draft-anderson-siit-dc-00 In case you're interested in more, Ivan Pepelnjak and I will host a (free) webinar about the approach next week. Feel free to join! http://www.ipspace.net/IPv6-Only_Data_Centers BTW: I hear Cisco has implemented support for this approach in their latest AS1K code, although I haven't confirmed this myself yet. Tore From mansaxel at besserwisser.org Fri Jun 7 06:51:31 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 7 Jun 2013 08:51:31 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <20130607065131.GB21448@besserwisser.org> Subject: Re: PRISM: NSA/FBI Internet data mining project Date: Fri, Jun 07, 2013 at 12:25:35AM -0500 Quoting jamie rishaw (j at arpa.com): > > Just wait until we find out dark and lit private fiber is getting vampired. > I'm not even assuming it, I'm convinced. In Sweden, we have a law, that makes what NSA/FBI did illegal while at the same time legalising, after some scrutiny, the practice of tapping traffic that passes Sweden and is not both originated by and destined to Swedes. . We're pretty good at selling transit abroad. Eastward. Go figure. Combine that with our NSA buddy, the FRA (http://www.fra.se) actively attempting to hire WDM experience and there is enough circumstantial data that I'm convinced it's being done. Also, what agencies like NSA, GCHQ and FRA have done for ages is listening to a broad spectrum of RF data with their aerials. Moving it into fiber is just keeping pace with the technology. Another historical fact is that the FRA has its roots in a extremely successful wiretapping operation in WW2, where the German teleprinter traffic between Norway (occupied) and Germany was passed on leased lines through western Sweden. Cross-border wiretap. In conclusion; I'm convinced. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm having an emotional outburst!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From bjorn at mork.no Fri Jun 7 08:01:38 2013 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 07 Jun 2013 10:01:38 +0200 Subject: IP4 address conservation method In-Reply-To: (Jimmy Hess's message of "Thu, 6 Jun 2013 23:06:12 -0500") References: <87d2rzyshv.fsf@nemi.mork.no> Message-ID: <87zjv2xsbh.fsf@nemi.mork.no> Jimmy Hess writes: > The kernel has its defaults, but distribution vendors such as > Redhat/Ubuntu/Debian, are free to supply their own defaults through > sysctl.conf or their NetworkManager packages or network configuration > scripts... > > It's interesting to note they have so far chosen to go (mostly) with > the defaults. > > I'm sure most people do not have a problem, or else, someone would > have updated the defaults by now Changing defaults will break stuff for people relying on those defaults. This is usually not acceptable. At least not in the kernel. The behaviour is well documented and easy to change. Whining about the defaults not matching personal preferences is useless noise. Bj?rn From eugen at leitl.org Fri Jun 7 11:36:07 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 7 Jun 2013 13:36:07 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> Message-ID: <20130607113607.GE2380@leitl.org> On Thu, Jun 06, 2013 at 08:07:57PM -0400, Alex Rubenstein wrote: > > > Has fingers directly in servers of top Internet content companies, > > > dates to 2007. Happily, none of the companies listed are transport > > > networks: > > > > I've always just assumed that if it's in electronic form, someone else is either > > reading it now, has already read it, or will read it as soon as I walk away from > > the screen. > > > So, you are comfortable just giving up your right to privacy? It's just the way it is? If you want to exercise your right to privacy, use end to end encryption and onion remixing networks to hamper traffic analysis. Everything else is for the hopelessly gullible. > I'm sorry, I am not as accepting of that fact as you are. I am disappointed and disgusted that this is, and has been, going on. Our government is failing us. What government is this, kemo sabe? Nanog has a global audience. From eugen at leitl.org Fri Jun 7 13:28:49 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 7 Jun 2013 15:28:49 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <20130607132849.GR2380@leitl.org> On Fri, Jun 07, 2013 at 12:25:35AM -0500, jamie rishaw wrote: > > Just wait until we find out dark and lit private fiber is getting vampired. > Approaches like http://www.wired.com/science/discoveries/news/2006/04/70619 obviously don't scale to small time operators. But if you can vaccuum up close to the core at full wire speed (and there is no reason to think you can't, since there are switches which deal with that) you don't have to deal with periphery that much. How would you tap a few TBit/s so that you can filter it down to where you can look it at layer 7 in ASICs, and filter out something to a more manageable data rate? Would you use a dedicated fibre to forward that to a central facility, or do it with storage that is periodically picked up via sneakernet? From alex at corp.nac.net Fri Jun 7 13:47:31 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 7 Jun 2013 09:47:31 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607132849.GR2380@leitl.org> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607132849.GR2380@leitl.org> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC546185@EXCHMBX.hq.nac.net> > Approaches like > http://www.wired.com/science/discoveries/news/2006/04/70619 > obviously don't scale to small time operators. But if you can vaccuum up close > to the core at full wire speed (and there is no reason to think you can't, since > there are switches which deal with that) you don't have to deal with > periphery that much. Remember, there is no core. I say that half-jokingly. Sniffing at the core will only net you a small set of potentially asymmetrical traffic flow. From dwhite at olp.net Fri Jun 7 13:50:30 2013 From: dwhite at olp.net (Dan White) Date: Fri, 7 Jun 2013 08:50:30 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B17ED8.2030604@invaluement.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> Message-ID: <20130607135030.GB8319@dan.olp.net> On 06/07/13?02:34?-0400, Rob McEwen wrote: >The "oh well, it happens, who cares, guess you need PGP" comments on >this thread are idiotic. Some of you would benefit from reading the text >of the 4th Amendment: > >"The right of the people to be secure in their persons, houses, papers, >and effects, against unreasonable searches and seizures, shall not be >violated, and no Warrants shall issue, but upon probable cause, >supported by Oath or affirmation, and particularly describing the place >to be searched, and the persons or things to be seized" OpenPGP and other end-to-end protocols protect against all nefarious actors, including state entities. I'll admit my first reaction yesterday after hearing this news was - so what? Network security by its nature presumes that an insecure channel is going to be attacked and compromised. The 4th Amendment is a layer-8 solution to a problem that is better solved lower in the stack. >The Washington Post mentioned some "safeguards"... but those were >pathetic. Why? They seemed to be similar to the following analogy: >"we'll keep that video camera in your home, recording your every move, >and we promise we'll close our eyes when reviewing the tape whenever it >shows you naked". THAT is essentially what they're saying. The access >described by both the Washington Post and The Guardian is essentially >unfettered/unmetered/unmonitored. > >Just as a doctors take the "hippocratic oath" to maintain decent >standards which are to the benefit of modern civilization... shouldn't >IT/Networking/Internet professionals (NANOG readers!!!) have standards >that, hopefully, distinguishes us from... say... the State-run ISP of >North Korea. > >And if these allegations are true... then... > >I have a difficult time believing that there was no "quid pro quo" >involved. Especially since such companies risk a backlash and huge loss >of customers if/when this gets out. So I don't think they'd do this >without some kind of return in favor. Did they get special tax >treatment? Tarp money of any kind (maybe to a parent company)? Easing of >regulation enforcement? I assume these taps were put in place under the auspices of (by order of) homeland security or some such. If there were some financial incentive involved, I'd be surprise. -- Dan White From alex at corp.nac.net Fri Jun 7 13:53:37 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 7 Jun 2013 09:53:37 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607113607.GE2380@leitl.org> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> <20130607113607.GE2380@leitl.org> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC54618D@EXCHMBX.hq.nac.net> > > So, you are comfortable just giving up your right to privacy? It's just the way > it is? > > If you want to exercise your right to privacy, use end to end encryption and > onion remixing networks to hamper traffic analysis. Whoa. These are two completely separate issues. I concur with you whole-heartedly; if you have something to keep private or something that is sensitive, protect it. That is your right, it is legal, and you should do it. I do. But that DOES NOT, UNDER ANY CIRCUMSTANCES, in any way make it OK for the USG to ignore the fourth amendment. I should not have to "hamper traffic analysis" that is analyzing my traffic illegally. That is the bigger point here. > Everything else is for the hopelessly gullible. You mean, "Everything else is for the people who are OK with being snooped on by the government." > > I'm sorry, I am not as accepting of that fact as you are. I am disappointed > > and disgusted that this is, and has been, going on. Our government is failing > > us. > > What government is this, kemo sabe? Nanog has a global audience. Fair enough, but I think we all know what I am talking about. From philfagan at gmail.com Fri Jun 7 14:21:17 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 7 Jun 2013 08:21:17 -0600 Subject: [NANOG 58] Final agenda posted and late registration - See you in New Orleans! In-Reply-To: References: Message-ID: I just wanted to take a moment and say thank you to all you that put together NANOG. I'm pretty new to the list and 58 was the first NANOG that I followed, watched a few archive speakers in the past, but this was the first time I actually "stay tuned" and followed most speakers. Simply put, thank you for the knowledge, perspective, and keep up the effort. On Tue, May 21, 2013 at 7:33 AM, David Temkin wrote: > All- > > The final agenda for NANOG 58 has been posted at: > > http://www.nanog.org/meetings/nanog58/agenda > > Also of note, Standard Registration ends on May 30 - the price will then go > up $75. We encourage you to register now and lock in the few remaining > hotel rooms at > > http://www.nanog.org/meetings/nanog58/registration > > This meeting will follow the new Monday-Wednesday format of tutorials > beginning Monday morning, a Newcomers Lunch, and then General Sessions > beginning in the early afternoon. The program will conclude with the > Peering Track and then a social on Wednesday night. > > Looking forward to seeing everyone in The Big Easy! > > Regards, > -Dave Temkin > Chair, NANOG Program Committee > -- Phil Fagan Denver, CO 970-480-7618 From morrowc.lists at gmail.com Fri Jun 7 15:02:03 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 7 Jun 2013 11:02:03 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: On Fri, Jun 7, 2013 at 1:57 AM, Mark Seiden wrote: > and also, only $20m/year? in my experience, the govt cannot do anything like this > addressing even a single provider for that little money. agreed, that 20m seems extraordinarily low for such an effort... hell, for 6 yrs time transport costs along would have exceeded that number. From dbrisson at uvm.edu Fri Jun 7 15:07:55 2013 From: dbrisson at uvm.edu (Dan Brisson) Date: Fri, 07 Jun 2013 11:07:55 -0400 Subject: [NANOG 58] Final agenda posted and late registration - See you in New Orleans! In-Reply-To: References: Message-ID: <51B1F74B.4000600@uvm.edu> I echo the same sentiment and this meeting being my first in-person, I can say that if you can swing physically making it to a meeting, jump at the chance. The content was excellent, the "networking" in the hallways was priceless, and the evening activities that the sponsors put on were first-class. Again, hats off to the folks at NANOG for a great meeting. -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbrisson at uvm.edu On 6/7/13 10:21 AM, Phil Fagan wrote: > I just wanted to take a moment and say thank you to all you that put > together NANOG. I'm pretty new to the list and 58 was the first NANOG that > I followed, watched a few archive speakers in the past, but this was the > first time I actually "stay tuned" and followed most speakers. Simply put, > thank you for the knowledge, perspective, and keep up the effort. > > > On Tue, May 21, 2013 at 7:33 AM, David Temkin wrote: > >> All- >> >> The final agenda for NANOG 58 has been posted at: >> >> http://www.nanog.org/meetings/nanog58/agenda >> >> Also of note, Standard Registration ends on May 30 - the price will then go >> up $75. We encourage you to register now and lock in the few remaining >> hotel rooms at >> >> http://www.nanog.org/meetings/nanog58/registration >> >> This meeting will follow the new Monday-Wednesday format of tutorials >> beginning Monday morning, a Newcomers Lunch, and then General Sessions >> beginning in the early afternoon. The program will conclude with the >> Peering Track and then a social on Wednesday night. >> >> Looking forward to seeing everyone in The Big Easy! >> >> Regards, >> -Dave Temkin >> Chair, NANOG Program Committee >> > > From rob at invaluement.com Fri Jun 7 15:11:12 2013 From: rob at invaluement.com (Rob McEwen) Date: Fri, 07 Jun 2013 11:11:12 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607135030.GB8319@dan.olp.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> Message-ID: <51B1F810.7050706@invaluement.com> On 6/7/2013 9:50 AM, Dan White wrote: > OpenPGP and other end-to-end protocols protect against all nefarious > actors, including state entities. I'll admit my first reaction yesterday > after hearing this news was - so what? Network security by its nature > presumes that an insecure channel is going to be attacked and > compromised. > The 4th Amendment is a layer-8 solution to a problem that is better > solved > lower in the stack. That is JUST like saying... || now that the police can freely bust your door down and raid your house in a "fishing expedition", without a search warrant, without court order, and without "probable cause"... the solution is for you to get a stronger metal door and hide all your stuff better.|| You're basically saying that it is OK for governments to defy their constitutions and trample over EVERYONE's rights, and that is OK since a TINY PERCENTAGE of experts will have exotic means to evade such trampling. But to hell with everyone else. They'll just have to become good little subjects to the State. If grandma can't do PGP, then she deserves it, right? Yet... many people DIED to initiate/preserve/codify such human rights... but I guess others just give them away freely. What a shame. Ironically, many who think this is no big deal have themselves benefited immensely from centuries of freedom and prosperity that resulted from "rule of law" and the U.S. Constitution/Bill of Rights. > I assume these taps were put in place under the auspices of (by order of) > homeland security or some such. If there were some financial incentive > involved, I'd be surprise. Some of the authors of the laws that were used to justify these are already starting to come forward saying, "it wasn't suppose to go that far". And to the extent that some laws were followed correctly, any such laws that do not conform to the 4th Amendment are suppose to be invalid, and eventually, officially invalidated. I think what has happened here is that stuff like this was nudging the 4th amendment aside... and little-by-little, kept getting worse... just like the Frog in the slowly heating water who doesn't know that he is now boiling to death. Does ANY REASONABLE person on this list REALLY think that the government snooping through your e-mail without warrant or court order is DIFFERENT in nature than the government sneaking into your home and snooping through your desk? Yes, it is easier. Yes, we ought to know that mail is less secure (from the BAD guys!!!). Otherwise, there really isn't any difference. This is a flagrant violation of the 4th amendment. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From jeroen at massar.ch Fri Jun 7 15:14:20 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 07 Jun 2013 08:14:20 -0700 Subject: PGP/SSL/TLS really as secure as one thinks? In-Reply-To: <20130607135030.GB8319@dan.olp.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> Message-ID: <51B1F8CC.9070402@massar.ch> On 2013-06-07 06:50, Dan White wrote: [..] A nice 'it is Friday' kind of thought.... > OpenPGP and other end-to-end protocols protect against all nefarious > actors, including state entities. If you can't trust the entities where your data is flowing through because you are unsure if and where they are tapping you, why do you trust any of the crypto out there that is allowed to exist? :) Think about it, the same organization(s) that you are suspecting of having those taps, are the ones who have the top crypto people in the world and who have been influencing those standards for decades... Oh, yes, the fun thing is that likely one is not able to do 'better' crypto either, unless it is not to talk. With PGP/SSL/TLS I of course mean primarily the underlying crypto, not the mechanism that they exist as, the mechanisms are quite well understood, the crypto though is a whole bunch of hocus spocus for most folks. And remember that when you are good enough with the crypto you are likely quickly enough to join on of those orgs ;) /me doles out tin foil hats for one to safely think this over on the weekend. Greets, Jeroen From oscar.vives at gmail.com Fri Jun 7 15:28:06 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Fri, 7 Jun 2013 17:28:06 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: This is one of these "Save the forest by burning it" situations that don't have any logic. To save a forest firefighters often cut a few tree. Don't cut all the trees in a forest to save it from a fire. Exceptions must be made for police forces to violate rights (like privacy). Exceptions can't be the norm. A exception can't be "we have accesss to all emails all the time". Thats cutting all the forest. If you give police forces the ability to violate personal rights all the time (not as exceptions) what this cause is people running away from the police forces. And turn the police forces in some type of criminal, the only difference is better organized and backed by the law. -- -- ?in del ?ensaje. From bicknell at ufp.org Fri Jun 7 15:34:05 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 7 Jun 2013 10:34:05 -0500 Subject: PGP/SSL/TLS really as secure as one thinks? In-Reply-To: <51B1F8CC.9070402@massar.ch> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F8CC.9070402@massar.ch> Message-ID: <760A8572-519D-43DB-AD04-2FE26E257519@ufp.org> On Jun 7, 2013, at 10:14 AM, Jeroen Massar wrote: > If you can't trust the entities where your data is flowing through > because you are unsure if and where they are tapping you, why do you > trust any of the crypto out there that is allowed to exist? :) > > Think about it, the same organization(s) that you are suspecting of > having those taps, are the ones who have the top crypto people in the > world and who have been influencing those standards for decades... I believe there are two answers to your question, although neither is entirely satisfactory. The same organization(s) you describe use cryptography themselves, and do influence the standards. They have a strong interest in keeping their own communication secure. It would be a huge risk to build in some weakness they could exploit and hope that other state funded entities would not be able to find the hidden flaw that allows decryption. Having "unbreakable" cryptography is not necessary to affect positive change. Reading unencrypted communications is O(1). If cryptography can make reading the communications (by breaking the crypto) harder, ideally at least O(n^2), it would likely prevent it from being economically feasible to do wide scale surveillance. Basically if they want your individual communications it's still no problem to break the crypto and get it, but simply reading everything going by from everyone becomes economically impossible. There's an important point to the second item; when scanning a large data set one of the most important details algorithmically is knowing which data _not_ to scan. When the data is in plain text throwing away uninteresting data is often trivial. If all data is encrypted, cycles must be spent to decrypt it all just to discover it is uninteresting. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From james at talkunafraid.co.uk Fri Jun 7 15:09:49 2013 From: james at talkunafraid.co.uk (James Harrison) Date: Fri, 07 Jun 2013 16:09:49 +0100 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: <51B1F7BD.9000008@talkunafraid.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/06/2013 16:02, Christopher Morrow wrote: > On Fri, Jun 7, 2013 at 1:57 AM, Mark Seiden > wrote: > >> and also, only $20m/year? in my experience, the govt cannot do >> anything like this addressing even a single provider for that >> little money. > > agreed, that 20m seems extraordinarily low for such an effort... > hell, for 6 yrs time transport costs along would have exceeded that > number. > Does seem cheap. Still, here's an update from the horse's mouth: http://www.dni.gov/index.php/newsroom/press-releases/191-press-releases-2013/868-dni-statement-on-recent-unauthorized-disclosures-of-classified-information Cheers, James Harrison -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlGx970ACgkQ22kkGnnJQAz8swCgjwv821xxn+B4wBVOCE069x6q hJ0An3wMSQ4K3DPzakhKEfPRuTnTgpAv =w9js -----END PGP SIGNATURE----- From dwhite at olp.net Fri Jun 7 15:42:07 2013 From: dwhite at olp.net (Dan White) Date: Fri, 7 Jun 2013 10:42:07 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B1F810.7050706@invaluement.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> Message-ID: <20130607154207.GF8319@dan.olp.net> On 06/07/13?11:11?-0400, Rob McEwen wrote: >On 6/7/2013 9:50 AM, Dan White wrote: >> OpenPGP and other end-to-end protocols protect against all nefarious >> actors, including state entities. I'll admit my first reaction yesterday >> after hearing this news was - so what? Network security by its nature >> presumes that an insecure channel is going to be attacked and >> compromised. The 4th Amendment is a layer-8 solution to a problem that >> is better solved lower in the stack. > >That is JUST like saying... > >|| now that the police can freely bust your door down and raid your >house in a "fishing expedition", without a search warrant, without court >order, and without "probable cause"... the solution is for you to get a >stronger metal door and hide all your stuff better.|| Hiding stuff better is generally good security practice, particularly in the absence of a search warrant. How effective those practices are is really what's important. From a data standpoint, those security procedures can be highly effective, even against law enforcement. But it's not law enforcement that I worry about the most (understandably, you may have a differing opinion); It's the random anonymous cracker who isn't beholden to any international laws or courts. I design my personal security procedures for him. That's why I don't, say, send passwords in emails. I don't trust state entities to protect the transmission of that data. I don't wish to place that burden on them. >You're basically saying that it is OK for governments to defy their >constitutions and trample over EVERYONE's rights, and that is OK since a >TINY PERCENTAGE of experts will have exotic means to evade such >trampling. But to hell with everyone else. They'll just have to become >good little subjects to the State. If grandma can't do PGP, then she >deserves it, right? I believe it's your responsibility to protect your own data, not the government's, and certainly not Facebook's. >Yet... many people DIED to initiate/preserve/codify such human rights... >but I guess others just give them away freely. What a shame. Ironically, >many who think this is no big deal have themselves benefited immensely >from centuries of freedom and prosperity that resulted from "rule of >law" and the U.S. Constitution/Bill of Rights. Freedom is very important to me, as well as the laws that are in place to protect them. -- Dan White From rob at invaluement.com Fri Jun 7 15:49:54 2013 From: rob at invaluement.com (Rob McEwen) Date: Fri, 07 Jun 2013 11:49:54 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607154207.GF8319@dan.olp.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> Message-ID: <51B20122.20800@invaluement.com> On 6/7/2013 11:42 AM, Dan White wrote: > I believe it's your responsibility to protect your own data, not the > government's, and certainly not Facebook's. Dan, I agree with everything you said in your last post. Except this part misses the point. Yes, it may not be their job to protect the data, but they do have certain responsibilities to not enable the snooping/sharing of my data beyond what is either obviously expected and/or what is clearly found in licensing/terms. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From jra at baylink.com Fri Jun 7 15:53:50 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 11:53:50 -0400 (EDT) Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: <55B908F4EEBF47F7813EEFE2E2483EC1@owner59e1f1502> Message-ID: <20371516.7332.1370620430594.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Painter" > Anyone besides jra remember the last Super Bowl? > Better this year? Worse? > I'm sure whomever is listening in would like to know as well. > > http://www.multichannel.com/blogs/translation-please/multicast-unicast-and-super-bowl-problem Well, in fact, the most recent Massive Failure was the webcast of the Concert For Boston, on 5/31. They were using a vendor called LiveAlliance.tv, who did not appear to be farming it out to Limelight or Akamai or Youtube, as far as I could tell, and they apparently only figured for a scale 5 audience, and then got more than 500k attempts. They got rescued by a vendor named Fast Hockey who are an amateur hockey webcast aggregator, I gather, and *are* an Akamai client. My estimation is that the reason that webcasting will never completely replace broadcasting is that -- because it is mostly unicast -- its inherent complexity factor is a) orders of magnitude higher than bcast, and b) *proportional to the number of viewers*. Like Linux, that doesn't scale. And broadcasters are not prone to think of the world in a view where you have to provide technical support to people just to watch your show. "He's at the 40... the 30... the 20... this is gonna be the Super Bowl, folks... the 10... [buffering]" Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Jun 7 15:55:42 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 11:55:42 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B13383.2050500@hawaii.edu> Message-ID: <1247029.7334.1370620542420.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Mathews (OSIA)" > On 6/6/2013 7:35 PM, Jay Ashworth wrote: > > > [ ..... ] Happily, none of the companies listed are transport > > networks: > > > > [ .... ] > > > > Cheers, > > -- jra > > > Could you be certain that TWC, Comcast, Qwest/CenturyLink could not be > involved? No, nor L3, GBLX, or the others. But you'd assume their names would get mentioned... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Jun 7 15:58:42 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 11:58:42 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B13B69.3020408@hawaii.edu> Message-ID: <5333159.7336.1370620722010.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Mathews (OSIA)" > On 6/6/2013 9:22 PM, Valdis.Kletnieks at vt.edu wrote: > > > Pay attention. None of the ones *listed* are transport networks. > > Doesn't mean they're not involved but unlisted (as of yet). > > *Vladis: * I thank you for waking me up in class! I am > impressed - your finely tuned language hair "has picked-up" the > distinctions. Further, I am quite certain that the "listing" will be > more inclusive/explicative in the next round. With all due respect, Dr Mathews, I *know* Valdis[1]' reputation; he's a regular participant here. Who are you again? Cheers, -- jra [1] Note proper spelling of his name[2]. [2] Note that I spelled your name correctly as well. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Jun 7 16:05:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 12:05:41 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B14974.2000900@hawaii.edu> Message-ID: <13727576.7340.1370621141483.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Mathews (OSIA)" > Being an AGENT or AGENCY of Change is not an activity most are CAPABLE > of effectively thinking about, let alone acting upon. [ ... ] > Laziness aside, permit me to humbly note that emphasis on COMPLIANCE > (with sane or insane laws) alone, neither ENSURES, nor ASSURES > security for oneself or one's customers. UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Jun 7 16:10:57 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 12:10:57 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: <25481232.7342.1370621457652.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Seiden" > but the ability to assemble intelligence out of taps on providers' > internal connections > would require reverse engineering the ever changing protocols of all > of those providers. > and at least at one of the providers named, where i worked on security > and abuse, > it was hard for us, ourselves, to quickly mash up data from various > internal services > and lines of business that were almost completely siloed -- > data typically wasn't exposed widely and stayed within a particular > server or data center absent a logged in session by the user. Jamie makes an excellent point here: Least Privilege should apply within carrier's cores and data centers, just as much as within corporate and organizational ones. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From brunner at nic-naa.net Fri Jun 7 16:15:01 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 07 Jun 2013 09:15:01 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: <51B20705.7010506@nic-naa.net> On 6/7/13 8:28 AM, <<"tei''>>> wrote: > This is one of these "Save the forest by burning it" situations that > don't have any logic. > > To save a forest firefighters often cut a few tree. Don't cut all the > trees in a forest to save it from a fire. Seasonal work, many solar obits past. Well, actually, standard practice is to scratch a line and burn out from the line to reduce fuel proximal to the line. "Scrach" can take the form of a crew with hand tools scratching a width-of-tool reduction in fine fuel to tandem tractors scratching width-of-blade, followed by walked drip torches. Trees don't really "burn" and cutting trees to make line is only useful when attempting to limit crown fires more effectively dealt with by retreat to a discontiguous canopy and firing out to reduce propagation over fine fuels. Modernly, fire is recognized as a natural phenomena and past fire suppression doctrine has elevated fuel load and fire intensity, with deleterious effect, and suppression goals modified to structure defense, and identified resource defense, as well as the ongoing timber sales value defense. -e From mpetach at netflight.com Fri Jun 7 16:32:53 2013 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 7 Jun 2013 09:32:53 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach wrote: > > > On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: > >> Has fingers directly in servers of top Internet content companies, >> dates to 2007. Happily, none of the companies listed are transport >> networks: >> >> >> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 >> 647 1274 >> >> > > I've always just assumed that if it's in electronic form, > someone else is either reading it now, has already read > it, or will read it as soon as I walk away from the screen. > > Much less stress in life that way. ^_^ > > Matt > > When I posted this yesterday, I was speaking somewhat tongue-in-cheek, because we hadn't yet made a formal statement to the press. Now that we've made our official reply, I can echo it, and note that whatever fluffed up powerpoint was passed around to the washington post, it does not reflect reality. There are no optical taps in our datacenters funneling information out, there are no sooper-seekret backdoors in the software that funnel information to the government. As our formal reply stated: "Yahoo does not provide the government with direct access to its servers, systems, or network." I believe the other major players supposedly listed in the document have released similar statements, all indicating a similar lack of super-cheap government listening capabilities. Speaking just for myself, and if you quote me on this as speaking on anyone else's behalf, you're a complete fool, if the government was able to build infrastructure that could listen to all the traffic from a major provider for a fraction of what it costs them to handle that traffic in the first place, I'd be truly amazed--and I'd probably wonder why the company didn't outsource their infrastruture to the government, if they can build and run it so much more cheaply than the commercial providers. ;P 7 companies were listed; if we assume the burden was split roughly evenly between them, that's 20M/7, about $2.85M per company per year to tap in, or about $238,000/month per company listed, to supposedly snoop on hundreds of gigs per second of data. Two ways to handle it: tap in, and funnel copies of all traffic back to distant monitoring posts, or have local servers digesting and filtering, just extracting the few nuggets they want, and sending just those back. Let's take the first case; doing optical taps, or other form of direct traffic mirroring, carrying it untouched offsite to process; that's going to mean the ability to siphon off hundreds of Gbps per datacenter and carry it offsite for $238k/month; let's figure a major player has data split across at least 3 datacenters, so about $75K/month per datacenter to carry say 300Gbps of traffic. It's pretty clearly going to have to be DWDM on dark fiber at that traffic volume; most recent quotes I've seen for dark fiber put it at $325/mile for already-laid-in-ground (new builds are considerably more, of course). If we figure the three datacenters are split around just the US, on average you're going to need to run about 1500 miles to reach their central listening post; that's $49K/month just to carry the bitstream, which leaves you just about $25K/month to run the servers to digest that data; at 5c/kwhr, a typical server pulling 300 watts is gonna cost you $11/month to run; let's assume each server can process 2Gbps of traffic, constantly; 150 servers for the stream of 300Gbps means we're down to $22K for the rest of our support costs; figure two sysadmins getting paid $10k/month to run the servers (120k annual salary), and you've got just $2k for G&A overhead. That's a heck of an efficient operation they'd have to be running to listen in on all the traffic for the supposed budget number claimed. I'm late for work; I'll follow up with a runthrough of the other model, doing on-site digestion and processing later, but I think you can see the point--it's not realistic to think they can handle the volumes of data being claimed at the price numbers listed. If they could, the major providers would already be doing it for much cheaper than they are today. I mean, the Utah datacenter they're building is costing them $2B to build; does anyone really think if they're overpaying that much for datacenter space, they could really snoop on provider traffic for only $238K/month? More later--and remember, this is purely my own rampant speculation, I'm not speaking for anyone, on behalf of anyone, or even remotely authorized or acknowledged by any entity on this rambling, so please don't go quoting this anywhere else, it'll make you look foolish, and probably get me in trouble anyhow. :( Matt From mathews at hawaii.edu Fri Jun 7 16:38:31 2013 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Fri, 07 Jun 2013 12:38:31 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <5333159.7336.1370620722010.JavaMail.root@benjamin.baylink.com> References: <5333159.7336.1370620722010.JavaMail.root@benjamin.baylink.com> Message-ID: <51B20C87.8030009@hawaii.edu> On 6/7/2013 11:58 AM, Jay Ashworth wrote: > With all due respect, Dr Mathews, I *know* Valdis[1]' reputation; he's a > regular participant here. > > Who are you again? > > Cheers, > -- jra > [1] Note proper spelling of his name[2]. > [2] Note that I spelled your name correctly as well. I am "no one" particularly important, or of great reputation! ...... and, I shall make it a point to avail myself to a nearby English class... meanwhile, please carry on with the "cultivated" and wonderful discussions on what "a" government can, cannot, or indeed may do.... Cheers to you as well. From wbailey at satelliteintelligencegroup.com Fri Jun 7 17:10:38 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 7 Jun 2013 17:10:38 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> , Message-ID: <337d509g596l6qg7obc158mr.1370624005739@email.android.com> Five days ago anyone who would have talked about the government having this capability would have been issued another tin foil hat. We think we know the truth now, but why hasn't echelon been brought up? I'm not calling anyone a liar, but isn't not speaking the truth the same thing? Sent from my Mobile Device. -------- Original message -------- From: Matthew Petach Date: 06/07/2013 9:34 AM (GMT-08:00) To: Cc: NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach wrote: > > > On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: > >> Has fingers directly in servers of top Internet content companies, >> dates to 2007. Happily, none of the companies listed are transport >> networks: >> >> >> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 >> 647 1274 >> >> > > I've always just assumed that if it's in electronic form, > someone else is either reading it now, has already read > it, or will read it as soon as I walk away from the screen. > > Much less stress in life that way. ^_^ > > Matt > > When I posted this yesterday, I was speaking somewhat tongue-in-cheek, because we hadn't yet made a formal statement to the press. Now that we've made our official reply, I can echo it, and note that whatever fluffed up powerpoint was passed around to the washington post, it does not reflect reality. There are no optical taps in our datacenters funneling information out, there are no sooper-seekret backdoors in the software that funnel information to the government. As our formal reply stated: "Yahoo does not provide the government with direct access to its servers, systems, or network." I believe the other major players supposedly listed in the document have released similar statements, all indicating a similar lack of super-cheap government listening capabilities. Speaking just for myself, and if you quote me on this as speaking on anyone else's behalf, you're a complete fool, if the government was able to build infrastructure that could listen to all the traffic from a major provider for a fraction of what it costs them to handle that traffic in the first place, I'd be truly amazed--and I'd probably wonder why the company didn't outsource their infrastruture to the government, if they can build and run it so much more cheaply than the commercial providers. ;P 7 companies were listed; if we assume the burden was split roughly evenly between them, that's 20M/7, about $2.85M per company per year to tap in, or about $238,000/month per company listed, to supposedly snoop on hundreds of gigs per second of data. Two ways to handle it: tap in, and funnel copies of all traffic back to distant monitoring posts, or have local servers digesting and filtering, just extracting the few nuggets they want, and sending just those back. Let's take the first case; doing optical taps, or other form of direct traffic mirroring, carrying it untouched offsite to process; that's going to mean the ability to siphon off hundreds of Gbps per datacenter and carry it offsite for $238k/month; let's figure a major player has data split across at least 3 datacenters, so about $75K/month per datacenter to carry say 300Gbps of traffic. It's pretty clearly going to have to be DWDM on dark fiber at that traffic volume; most recent quotes I've seen for dark fiber put it at $325/mile for already-laid-in-ground (new builds are considerably more, of course). If we figure the three datacenters are split around just the US, on average you're going to need to run about 1500 miles to reach their central listening post; that's $49K/month just to carry the bitstream, which leaves you just about $25K/month to run the servers to digest that data; at 5c/kwhr, a typical server pulling 300 watts is gonna cost you $11/month to run; let's assume each server can process 2Gbps of traffic, constantly; 150 servers for the stream of 300Gbps means we're down to $22K for the rest of our support costs; figure two sysadmins getting paid $10k/month to run the servers (120k annual salary), and you've got just $2k for G&A overhead. That's a heck of an efficient operation they'd have to be running to listen in on all the traffic for the supposed budget number claimed. I'm late for work; I'll follow up with a runthrough of the other model, doing on-site digestion and processing later, but I think you can see the point--it's not realistic to think they can handle the volumes of data being claimed at the price numbers listed. If they could, the major providers would already be doing it for much cheaper than they are today. I mean, the Utah datacenter they're building is costing them $2B to build; does anyone really think if they're overpaying that much for datacenter space, they could really snoop on provider traffic for only $238K/month? More later--and remember, this is purely my own rampant speculation, I'm not speaking for anyone, on behalf of anyone, or even remotely authorized or acknowledged by any entity on this rambling, so please don't go quoting this anywhere else, it'll make you look foolish, and probably get me in trouble anyhow. :( Matt From Valdis.Kletnieks at vt.edu Fri Jun 7 18:05:23 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 07 Jun 2013 14:05:23 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Your message of "Thu, 06 Jun 2013 22:57:07 -0700." <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: <13976.1370628323@turing-police.cc.vt.edu> On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: > and also, only $20m/year? in my experience, the govt cannot do anything like this > addressing even a single provider for that little money. Convince me the *real* number doesn't have another zero. Remember - the $20M number came from a source that has *very* good reason to lie as much as it can right now about the true extent of this. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From cscora at apnic.net Fri Jun 7 18:39:36 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Jun 2013 04:39:36 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201306071839.r57IdaoO002049@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Jun, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 455106 Prefixes after maximum aggregation: 185702 Deaggregation factor: 2.45 Unique aggregates announced to Internet: 225482 Total ASes present in the Internet Routing Table: 44265 Prefixes per ASN: 10.28 Origin-only ASes present in the Internet Routing Table: 34687 Origin ASes announcing only one prefix: 16161 Transit ASes present in the Internet Routing Table: 5879 Transit-only ASes present in the Internet Routing Table: 147 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 55644) 23 Prefixes from unregistered ASNs in the Routing Table: 331 Unregistered ASNs in the Routing Table: 139 Number of 32-bit ASNs allocated by the RIRs: 4787 Number of 32-bit ASNs visible in the Routing Table: 3699 Prefixes from 32-bit ASNs in the Routing Table: 10729 Special use prefixes present in the Routing Table: 26 Prefixes being announced from unallocated address space: 226 Number of addresses announced to Internet: 2623669644 Equivalent to 156 /8s, 98 /16s and 5 /24s Percentage of available address space announced: 70.9 Percentage of allocated address space announced: 70.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.6 Total number of prefixes smaller than registry allocations: 159823 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109375 Total APNIC prefixes after maximum aggregation: 33513 APNIC Deaggregation factor: 3.26 Prefixes being announced from the APNIC address blocks: 110866 Unique aggregates announced from the APNIC address blocks: 45108 APNIC Region origin ASes present in the Internet Routing Table: 4855 APNIC Prefixes per ASN: 22.84 APNIC Region origin ASes announcing only one prefix: 1227 APNIC Region transit ASes present in the Internet Routing Table: 825 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 563 Number of APNIC addresses announced to Internet: 724781792 Equivalent to 43 /8s, 51 /16s and 74 /24s Percentage of available APNIC address space announced: 84.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 158557 Total ARIN prefixes after maximum aggregation: 80320 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 159120 Unique aggregates announced from the ARIN address blocks: 73458 ARIN Region origin ASes present in the Internet Routing Table: 15729 ARIN Prefixes per ASN: 10.12 ARIN Region origin ASes announcing only one prefix: 5984 ARIN Region transit ASes present in the Internet Routing Table: 1653 Average ARIN Region AS path length visible: 4.2 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1064524096 Equivalent to 63 /8s, 115 /16s and 89 /24s Percentage of available ARIN address space announced: 56.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 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 117096 Total RIPE prefixes after maximum aggregation: 60007 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 120642 Unique aggregates announced from the RIPE address blocks: 78094 RIPE Region origin ASes present in the Internet Routing Table: 17224 RIPE Prefixes per ASN: 7.00 RIPE Region origin ASes announcing only one prefix: 8185 RIPE Region transit ASes present in the Internet Routing Table: 2823 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2349 Number of RIPE addresses announced to Internet: 656568420 Equivalent to 39 /8s, 34 /16s and 112 /24s Percentage of available RIPE address space announced: 95.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-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 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, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 48355 Total LACNIC prefixes after maximum aggregation: 9319 LACNIC Deaggregation factor: 5.19 Prefixes being announced from the LACNIC address blocks: 52748 Unique aggregates announced from the LACNIC address blocks: 24740 LACNIC Region origin ASes present in the Internet Routing Table: 1953 LACNIC Prefixes per ASN: 27.01 LACNIC Region origin ASes announcing only one prefix: 583 LACNIC Region transit ASes present in the Internet Routing Table: 361 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 762 Number of LACNIC addresses announced to Internet: 130842376 Equivalent to 7 /8s, 204 /16s and 127 /24s Percentage of available LACNIC address space announced: 78.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10894 Total AfriNIC prefixes after maximum aggregation: 2500 AfriNIC Deaggregation factor: 4.36 Prefixes being announced from the AfriNIC address blocks: 11504 Unique aggregates announced from the AfriNIC address blocks: 3873 AfriNIC Region origin ASes present in the Internet Routing Table: 628 AfriNIC Prefixes per ASN: 18.32 AfriNIC Region origin ASes announcing only one prefix: 182 AfriNIC Region transit ASes present in the Internet Routing Table: 130 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46672128 Equivalent to 2 /8s, 200 /16s and 41 /24s Percentage of available AfriNIC address space announced: 46.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2958 11559 926 Korea Telecom (KIX) 17974 2524 855 91 PT TELEKOMUNIKASI INDONESIA 7545 1992 320 108 TPG Internet Pty Ltd 4755 1738 391 191 TATA Communications formerly 9829 1500 1205 40 BSNL National Internet Backbo 9583 1221 91 503 Sify Limited 7552 1164 1080 13 Vietel Corporation 4808 1141 2123 333 CNCGROUP IP network: China169 9498 1127 309 70 BHARTI Airtel Ltd. 24560 1077 394 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3015 3691 75 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 1785 1991 677 123 PaeTec Communications, Inc. 22773 1989 2929 125 Cox Communications, Inc. 20115 1664 1616 617 Charter Communications 4323 1618 1138 403 Time Warner Telecom 701 1533 11075 840 UUNET Technologies, Inc. 30036 1333 298 644 Mediacom Communications Corp 7018 1293 11038 833 AT&T WorldNet Services 11492 1218 216 359 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1684 544 16 Corbina telecom 34984 1271 244 223 BILISIM TELEKOM 2118 1069 97 13 EUnet/RELCOM Autonomous Syste 20940 896 315 702 Akamai Technologies European 13188 830 98 74 Educational Network 31148 812 41 25 FreeNet ISP 8551 773 370 43 Bezeq International 6830 768 2376 441 UPC Distribution Services 34744 676 173 59 SC GVM SISTEM 2003 SRL 58113 666 74 386 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2827 1558 111 NET Servicos de Comunicao S.A 10620 2650 417 218 TVCABLE BOGOTA 7303 1732 1155 221 Telecom Argentina Stet-France 8151 1271 2710 407 UniNet S.A. de C.V. 18881 972 780 19 Global Village Telecom 6503 873 434 65 AVANTEL, S.A. 27947 836 89 104 Telconet S.A 3816 711 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 6147 665 374 25 Telefonica Del Peru Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1237 80 4 MOBITEL 24863 887 274 32 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 446 956 9 TEDATA 24835 345 80 8 RAYA Telecom - Egypt 3741 259 906 218 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 29571 205 17 9 Ci Telecom Autonomous system 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3015 3691 75 bellsouth.net, inc. 4766 2958 11559 926 Korea Telecom (KIX) 28573 2827 1558 111 NET Servicos de Comunicao S.A 10620 2650 417 218 TVCABLE BOGOTA 17974 2524 855 91 PT TELEKOMUNIKASI INDONESIA 18566 2065 382 184 Covad Communications 7545 1992 320 108 TPG Internet Pty Ltd 1785 1991 677 123 PaeTec Communications, Inc. 22773 1989 2929 125 Cox Communications, Inc. 4755 1738 391 191 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2827 2716 NET Servicos de Comunicao S.A 17974 2524 2433 PT TELEKOMUNIKASI INDONESIA 10620 2650 2432 TVCABLE BOGOTA 4766 2958 2032 Korea Telecom (KIX) 7545 1992 1884 TPG Internet Pty Ltd 18566 2065 1881 Covad Communications 1785 1991 1868 PaeTec Communications, Inc. 22773 1989 1864 Cox Communications, Inc. 8402 1684 1668 Corbina telecom 4755 1738 1547 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.57.0/24 60993 Totalsoft SA 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:16 /9:11 /10:30 /11:91 /12:250 /13:484 /14:901 /15:1599 /16:12696 /17:6638 /18:11162 /19:22169 /20:32006 /21:34349 /22:47488 /23:42257 /24:238977 /25:1318 /26:1660 /27:855 /28:46 /29:65 /30:18 /31:0 /32:20 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 6389 1732 3015 bellsouth.net, inc. 8402 1370 1684 Corbina telecom 22773 1296 1989 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1202 1333 Mediacom Communications Corp 11492 1180 1218 Cable One 1785 1062 1991 PaeTec Communications, Inc. 6983 1011 1138 ITC^Deltacom 10620 990 2650 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:821 2:778 3:3 4:15 5:771 6:11 8:558 12:1927 13:3 14:831 15:11 16:3 17:10 20:17 23:369 24:1769 27:1478 31:1322 32:57 33:2 34:5 36:32 37:1851 38:871 39:2 40:171 41:2810 42:194 44:6 46:1933 47:2 49:641 50:716 52:12 54:33 55:5 57:27 58:1164 59:572 60:314 61:1407 62:1123 63:2034 64:4324 65:2164 66:4177 67:2049 68:1074 69:3263 70:787 71:487 72:1914 74:2476 75:323 76:301 77:1131 78:1025 79:619 80:1269 81:1004 82:624 83:574 84:534 85:1164 86:453 87:992 88:537 89:1763 90:147 91:5531 92:590 93:1673 94:1856 95:1459 96:512 97:344 98:1002 99:42 100:31 101:323 103:2735 105:519 106:149 107:208 108:510 109:1820 110:896 111:1046 112:539 113:813 114:695 115:958 116:933 117:800 118:1083 119:1301 120:408 121:729 122:1794 123:1217 124:1362 125:1356 128:648 129:224 130:325 131:654 132:342 133:148 134:267 135:66 136:224 137:239 138:345 139:194 140:211 141:327 142:536 143:392 144:497 145:93 146:510 147:382 148:684 149:368 150:162 151:500 152:417 153:193 154:41 155:402 156:267 157:397 158:278 159:729 160:339 161:432 162:409 163:221 164:599 165:495 166:271 167:594 168:1021 169:129 170:1052 171:181 172:21 173:1594 174:544 175:470 176:1144 177:2087 178:1863 179:27 180:1458 181:450 182:1215 183:387 184:693 185:512 186:2281 187:1298 188:2135 189:1259 190:6822 192:6651 193:5668 194:4591 195:3423 196:1349 197:904 198:4483 199:5329 200:5979 201:2250 202:8825 203:8896 204:4499 205:2572 206:2802 207:2849 208:4060 209:3620 210:2964 211:1507 212:2185 213:1979 214:924 215:98 216:5233 217:1616 218:618 219:349 220:1264 221:558 222:321 223:456 End of report From jra at baylink.com Fri Jun 7 19:03:16 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 15:03:16 -0400 (EDT) Subject: Pen testing and white hats for mass consumption Message-ID: <29267816.7430.1370631796527.JavaMail.root@benjamin.baylink.com> Since one Whacky Weekend thread isn't enough on a post-NANOG weekend: Here's some coverage of pentesting and 'ethical' hacking packaged for a general audience. I only caught the first half of this the other day, but it seemed worth listening to. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From me at staticsafe.ca Fri Jun 7 19:05:44 2013 From: me at staticsafe.ca (staticsafe) Date: Fri, 7 Jun 2013 15:05:44 -0400 Subject: Pen testing and white hats for mass consumption In-Reply-To: <29267816.7430.1370631796527.JavaMail.root@benjamin.baylink.com> References: <29267816.7430.1370631796527.JavaMail.root@benjamin.baylink.com> Message-ID: <20130607190544.GA9097@uriel.asininetech.com> On Fri, Jun 07, 2013 at 03:03:16PM -0400, Jay Ashworth wrote: > Since one Whacky Weekend thread isn't enough on a post-NANOG weekend: > > Here's some coverage of pentesting and 'ethical' hacking packaged for a > general audience. I only caught the first half of this the other day, but > it seemed worth listening to. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > You seem to have forgotten the link. :) -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on. From mis at seiden.com Fri Jun 7 19:05:43 2013 From: mis at seiden.com (Mark Seiden) Date: Fri, 7 Jun 2013 12:05:43 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <13976.1370628323@turing-police.cc.vt.edu> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> <13976.1370628323@turing-police.cc.vt.edu> Message-ID: i have talked with a dozen people about this who ought to know if there were something more creepy than usual going on. and nobody in engineering knows of anything. but hm, people in compliance said "no comment". that, and the $20M annual number, suggests that what they actually did was set up a portal for intel agency people to use to request "business records" of the members (service providers). (maybe PRISM stands for something like Portal to Request Intelligence Service Materials, or somesuch.) of course, under patriot, the legal concept of "business records" was greatly expanded, and the kinds of approvals needed to get them reduced. i really wonder if the FISC has a pki. i.e. as a technical matter can a FISC judge electronically approve a NSL or FISA warrant? if i'm right, now they're following the letter of the new law electronically, rather than using paper and fax. which would increase timeliness, accuracy and efficiency for all parties concerned. this would only affect compliance activities at the providers, who would continue receiving and handling individual requests just as previously and supplying the same data as before. (and i suppose now the providers could actually supply the returned records electronically also?) (i am actually in favor of this kind of thing for both law enforcement requests and for intel agency requests. the amount of time and money wasted and delays in handling perfectly legal and necessary investigative requests was kind of shocking to me. i repeatedly heard complaints about cases where compliance would not respond to LE in long enough that the data provided was stale for judicial purposes, and the same search warrant would have to be reissued. (or where they would take a very long time to reject a request for a technical or legal reason.) (there's an interesting gray area in this request handling: there were several times as an internal investigator at a provider when i wanted to be able to convey to LE that they *should go through the trouble* of doing all the paperwork of going to a judge, or even worse, through the MLAT which means a foot of paper and a man-month of work. there were even more times when i wanted to say "don't bother to even ask, you'd just be wasting your time"). but my lawyers would not allow that sort of communication. On Jun 7, 2013, at 11:05 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: >> and also, only $20m/year? in my experience, the govt cannot do anything like this >> addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. > > Remember - the $20M number came from a source that has *very* good reason > to lie as much as it can right now about the true extent of this. > > From jra at baylink.com Fri Jun 7 19:08:13 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 15:08:13 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <13976.1370628323@turing-police.cc.vt.edu> Message-ID: <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: > > and also, only $20m/year? in my experience, the govt cannot do > > anything like this addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. > > Remember - the $20M number came from a source that has *very* good > reason to lie as much as it can right now about the true extent of this. Indeed. Luckily, the press is all over this like a bad smell. I mentioned The Story in a new posting just now; they have, surprisingly, already managed to dig at this spot, a pretty quick response for them: http://www.thestory.org/stories/2013-06/americans-spying-americans Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Jun 7 19:09:26 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 15:09:26 -0400 (EDT) Subject: Pen testing and white hats for mass consumption In-Reply-To: <29267816.7430.1370631796527.JavaMail.root@benjamin.baylink.com> Message-ID: <17175986.7436.1370632166350.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > To: "NANOG" > Sent: Friday, June 7, 2013 3:03:16 PM > Subject: Pen testing and white hats for mass consumption > Since one Whacky Weekend thread isn't enough on a post-NANOG weekend: > > Here's some coverage of pentesting and 'ethical' hacking packaged for > a general audience. I only caught the first half of this the other day, > but it seemed worth listening to. http://www.thestory.org/stories/2013-06/employment-security-hacker Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Jun 7 19:11:45 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 15:11:45 -0400 (EDT) Subject: FIXED: Pen testing and white hats for mass consumption In-Reply-To: <29267816.7430.1370631796527.JavaMail.root@benjamin.baylink.com> Message-ID: <20072412.7444.1370632305519.JavaMail.root@benjamin.baylink.com> Since one Whacky Weekend thread isn't enough on a post-NANOG weekend: Here's some coverage of pentesting and 'ethical' hacking packaged for a general audience. I only caught the first half of this the other day, but it seemed worth listening to. and that link is... http://www.thestory.org/stories/2013-06/employment-security-hacker Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Fri Jun 7 20:14:49 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 7 Jun 2013 20:14:49 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> <13976.1370628323@turing-police.cc.vt.edu>, Message-ID: I'm cool with technology to catch bad guys, I just don't know that catching everything for some kind of dragnet is the right approach. There will be a time where Americans realize they are actually not in control of their governence, perhaps that time is now? On the upside, Holder now has another leak (reason) to subpoena a journalist.. ;) As a side note.. I don't know how many of you have been on major government projects, but 20MM was spent in the first 20 minutes.. Much of the gear can be developed by another organization on another (massive) budget. Look at Groom Lake*.. What's their budget?Government contracting is murky territory, especially when things are critically needed and a General says "go". *Groom Lake (area 51) was confirmed to be the facility that developed the stealth helicopter used in the Bin Laden raids. Sent from my Mobile Device. -------- Original message -------- From: Mark Seiden Date: 06/07/2013 12:11 PM (GMT-08:00) To: Valdis.Kletnieks at vt.edu Cc: goemon at anime.net,NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project i have talked with a dozen people about this who ought to know if there were something more creepy than usual going on. and nobody in engineering knows of anything. but hm, people in compliance said "no comment". that, and the $20M annual number, suggests that what they actually did was set up a portal for intel agency people to use to request "business records" of the members (service providers). (maybe PRISM stands for something like Portal to Request Intelligence Service Materials, or somesuch.) of course, under patriot, the legal concept of "business records" was greatly expanded, and the kinds of approvals needed to get them reduced. i really wonder if the FISC has a pki. i.e. as a technical matter can a FISC judge electronically approve a NSL or FISA warrant? if i'm right, now they're following the letter of the new law electronically, rather than using paper and fax. which would increase timeliness, accuracy and efficiency for all parties concerned. this would only affect compliance activities at the providers, who would continue receiving and handling individual requests just as previously and supplying the same data as before. (and i suppose now the providers could actually supply the returned records electronically also?) (i am actually in favor of this kind of thing for both law enforcement requests and for intel agency requests. the amount of time and money wasted and delays in handling perfectly legal and necessary investigative requests was kind of shocking to me. i repeatedly heard complaints about cases where compliance would not respond to LE in long enough that the data provided was stale for judicial purposes, and the same search warrant would have to be reissued. (or where they would take a very long time to reject a request for a technical or legal reason.) (there's an interesting gray area in this request handling: there were several times as an internal investigator at a provider when i wanted to be able to convey to LE that they *should go through the trouble* of doing all the paperwork of going to a judge, or even worse, through the MLAT which means a foot of paper and a man-month of work. there were even more times when i wanted to say "don't bother to even ask, you'd just be wasting your time"). but my lawyers would not allow that sort of communication. On Jun 7, 2013, at 11:05 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: >> and also, only $20m/year? in my experience, the govt cannot do anything like this >> addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. > > Remember - the $20M number came from a source that has *very* good reason > to lie as much as it can right now about the true extent of this. > > From wbailey at satelliteintelligencegroup.com Fri Jun 7 20:14:49 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 7 Jun 2013 20:14:49 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> <13976.1370628323@turing-police.cc.vt.edu>, Message-ID: I'm cool with technology to catch bad guys, I just don't know that catching everything for some kind of dragnet is the right approach. There will be a time where Americans realize they are actually not in control of their governence, perhaps that time is now? On the upside, Holder now has another leak (reason) to subpoena a journalist.. ;) As a side note.. I don't know how many of you have been on major government projects, but 20MM was spent in the first 20 minutes.. Much of the gear can be developed by another organization on another (massive) budget. Look at Groom Lake*.. What's their budget?Government contracting is murky territory, especially when things are critically needed and a General says "go". *Groom Lake (area 51) was confirmed to be the facility that developed the stealth helicopter used in the Bin Laden raids. Sent from my Mobile Device. -------- Original message -------- From: Mark Seiden Date: 06/07/2013 12:11 PM (GMT-08:00) To: Valdis.Kletnieks at vt.edu Cc: goemon at anime.net,NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project i have talked with a dozen people about this who ought to know if there were something more creepy than usual going on. and nobody in engineering knows of anything. but hm, people in compliance said "no comment". that, and the $20M annual number, suggests that what they actually did was set up a portal for intel agency people to use to request "business records" of the members (service providers). (maybe PRISM stands for something like Portal to Request Intelligence Service Materials, or somesuch.) of course, under patriot, the legal concept of "business records" was greatly expanded, and the kinds of approvals needed to get them reduced. i really wonder if the FISC has a pki. i.e. as a technical matter can a FISC judge electronically approve a NSL or FISA warrant? if i'm right, now they're following the letter of the new law electronically, rather than using paper and fax. which would increase timeliness, accuracy and efficiency for all parties concerned. this would only affect compliance activities at the providers, who would continue receiving and handling individual requests just as previously and supplying the same data as before. (and i suppose now the providers could actually supply the returned records electronically also?) (i am actually in favor of this kind of thing for both law enforcement requests and for intel agency requests. the amount of time and money wasted and delays in handling perfectly legal and necessary investigative requests was kind of shocking to me. i repeatedly heard complaints about cases where compliance would not respond to LE in long enough that the data provided was stale for judicial purposes, and the same search warrant would have to be reissued. (or where they would take a very long time to reject a request for a technical or legal reason.) (there's an interesting gray area in this request handling: there were several times as an internal investigator at a provider when i wanted to be able to convey to LE that they *should go through the trouble* of doing all the paperwork of going to a judge, or even worse, through the MLAT which means a foot of paper and a man-month of work. there were even more times when i wanted to say "don't bother to even ask, you'd just be wasting your time"). but my lawyers would not allow that sort of communication. On Jun 7, 2013, at 11:05 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: >> and also, only $20m/year? in my experience, the govt cannot do anything like this >> addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. > > Remember - the $20M number came from a source that has *very* good reason > to lie as much as it can right now about the true extent of this. > > From wbailey at satelliteintelligencegroup.com Fri Jun 7 20:28:23 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 7 Jun 2013 20:28:23 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> References: <13976.1370628323@turing-police.cc.vt.edu>, <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> Message-ID: Has anyone found out if this system is actually based on Narus? I associated this program as a super version of the AT&T thing, and if I recall it was understood that was Narus and Co via NSA/FBI? Sent from my Mobile Device. -------- Original message -------- From: Jay Ashworth Date: 06/07/2013 12:16 PM (GMT-08:00) To: NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: > > and also, only $20m/year? in my experience, the govt cannot do > > anything like this addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. > > Remember - the $20M number came from a source that has *very* good > reason to lie as much as it can right now about the true extent of this. Indeed. Luckily, the press is all over this like a bad smell. I mentioned The Story in a new posting just now; they have, surprisingly, already managed to dig at this spot, a pretty quick response for them: http://www.thestory.org/stories/2013-06/americans-spying-americans Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jlsparks at gmail.com Fri Jun 7 20:31:55 2013 From: jlsparks at gmail.com (Jason L. Sparks) Date: Fri, 7 Jun 2013 16:31:55 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <13976.1370628323@turing-police.cc.vt.edu> <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> Message-ID: I assume the unclassified word "Prism" (which is found everywhere on IC resumes and open job descriptions) refers to Palantir's Prism suite. Could be wrong, but seems logical. On Fri, Jun 7, 2013 at 4:28 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Has anyone found out if this system is actually based on Narus? I > associated this program as a super version of the AT&T thing, and if I > recall it was understood that was Narus and Co via NSA/FBI? > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Jay Ashworth > Date: 06/07/2013 12:16 PM (GMT-08:00) > To: NANOG > Subject: Re: PRISM: NSA/FBI Internet data mining project > > > ----- Original Message ----- > > From: "Valdis Kletnieks" > > > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: > > > and also, only $20m/year? in my experience, the govt cannot do > > > anything like this addressing even a single provider for that little > money. > > > > Convince me the *real* number doesn't have another zero. > > > > Remember - the $20M number came from a source that has *very* good > > reason to lie as much as it can right now about the true extent of this. > > Indeed. Luckily, the press is all over this like a bad smell. > > I mentioned The Story in a new posting just now; they have, surprisingly, > already managed to dig at this spot, a pretty quick response for them: > > http://www.thestory.org/stories/2013-06/americans-spying-americans > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From andy at newslink.com Fri Jun 7 20:36:33 2013 From: andy at newslink.com (Andy Ringsmuth) Date: Fri, 7 Jun 2013 15:36:33 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> Message-ID: On Jun 7, 2013, at 10:02 AM, Christopher Morrow wrote: > On Fri, Jun 7, 2013 at 1:57 AM, Mark Seiden wrote: > >> and also, only $20m/year? in my experience, the govt cannot do anything like this >> addressing even a single provider for that little money. > > agreed, that 20m seems extraordinarily low for such an effort... hell, > for 6 yrs time transport costs along would have exceeded that number. > Obligatory Independence Day quote: President Thomas Whitmore: I don't understand, where does all this come from? How do you get funding for something like this? Julius Levinson: You don't actually think they spend $20,000 on a hammer, $30,000 on a toilet seat, do you? ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From davidianwalker at gmail.com Fri Jun 7 21:09:44 2013 From: davidianwalker at gmail.com (David Walker) Date: Sat, 8 Jun 2013 06:39:44 +0930 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B20C87.8030009@hawaii.edu> References: <5333159.7336.1370620722010.JavaMail.root@benjamin.baylink.com> <51B20C87.8030009@hawaii.edu> Message-ID: I've been trying to find details to the contrary but as far as I see, there's no indication that the constitutional (or otherwise) rights of any US citizens (or anyone, anywhere, for that matter) are being overtly (or otherwise) trampled which would seem to be the pertinent objection. The somewhat obvious ... - the NSA are authorized by congress (i.e. the American people) under the National Security Act of 1947 to deal with "foreign" signals intelligence and they've been doing this for some time. http://www.nsa.gov/about/mission/index.shtml - specifically the NSA has powers under the Foreign Intelligence Surveillance Act and amendments. http://www.intelligence.senate.gov/laws/pl110261.pdf - co-operating parties are under direction to follow NSA guidelines about disclosure. http://www.intelligence.senate.gov/laws/pl95-511.pdf The NSA are collecting SIGINT from commercial enterprise without disclosing specifics. This is "lawful" and to be expected. Your government is doing it too and has been for probably most of your nation's existence by whatever means available. Pertinent things we know here ... - there's a program called PRISM under NSA auspices. - the slides specifically reference extra-territorial communications. - there's discussion of "providers" and what type of information can be retrieved. - the infrastructure or procedures are established and have been for some time. Taking the few slides and relevant quotes (i.e. factual points) provided by the Washington Post and the Guardian and others and drawing a straight line on those, i.e. ignoring supposition and whatever, I don't see any news here other than somebody from NSA has leaked a powerpoint presentation that seemingly is an internal, hyperbolic, morale-boosting show. "The Guardian has verified the authenticity of the document ... which was apparently used to train intelligence operatives on the capabilities of the program." http://www.guardian.co.uk/world/2013/jun/06/us-tech-giants-nsa-data Here's the result of an ACLU FOI request dated 10/2/2009 ... http://www.aclu.org/files/pdfs/natsec/faafoia20101129/FAAFBI0536.pdf I don't see anything surprising or new. Is .gov is overstepping it's mandate and abusing any of this? History tells us there should be concerns. Is there any evidence to support such an assertion here? No. Later, I noticed this: http://www.dni.gov/index.php/newsroom/press-releases/191-press-releases-2013/869-dni-statement-on-activities-authorized-under-section-702-of-fisa "They contain numerous inaccuracies." James R. Clapper, Director of National Intelligence I've skimmed this: http://www.dni.gov/index.php/newsroom/press-releases/191-press-releases-2013/868-dni-statement-on-recent-unauthorized-disclosures-of-classified-information I might read it carefully later but it looks to describe sensible paradigms for understanding this leak. If there's an abuse of process going on can somebody point it out to me? If there is something un-constitutional going on, it's not PRISM per se, but the Act (FISA) which authorizes it. Right? If that's the case it doesn't require evidence of a program to point to the problem. From wbailey at satelliteintelligencegroup.com Fri Jun 7 21:10:58 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 7 Jun 2013 21:10:58 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> , Message-ID: <65uoseqkj6sltnnocffswdge.1370638810450@email.android.com> Lol.. I think the 20k hammer is probably a result of the contract vehicle. Firm fixed tend to have trouble with change orders so they bury costs within the project. The real cheap stuff comes from the indefinite quantity type of contracts, where they are buying consumables regularly at a discounted rate (and change orders are non issues). I used to wonder why the air force would run close to full burner on a training departure towards to the end of the month. I was told by someone who had an understanding of these things if you didn't use your fuel in a given month it impacted the next months delivery. It was necessary waste to ensure regular fuel quantities. The government entity was buying fuel on an indefinite basis, and the contract made the fuel cheaper as they were burning more. It's a total shit show in government contracting, which is I'm surprised they consider this system to be so wildly successful. If it was some anti jihad box, why did it not detect the Boston guys (who were not US citizens and likely would have been subject to monitoring by the anti jihad box)? Sent from my Mobile Device. -------- Original message -------- From: Andy Ringsmuth Date: 06/07/2013 1:38 PM (GMT-08:00) To: NANOG list Subject: Re: PRISM: NSA/FBI Internet data mining project On Jun 7, 2013, at 10:02 AM, Christopher Morrow wrote: > On Fri, Jun 7, 2013 at 1:57 AM, Mark Seiden wrote: > >> and also, only $20m/year? in my experience, the govt cannot do anything like this >> addressing even a single provider for that little money. > > agreed, that 20m seems extraordinarily low for such an effort... hell, > for 6 yrs time transport costs along would have exceeded that number. > Obligatory Independence Day quote: President Thomas Whitmore: I don't understand, where does all this come from? How do you get funding for something like this? Julius Levinson: You don't actually think they spend $20,000 on a hammer, $30,000 on a toilet seat, do you? ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From wbailey at satelliteintelligencegroup.com Fri Jun 7 21:21:01 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 7 Jun 2013 21:21:01 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <13976.1370628323@turing-police.cc.vt.edu> <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> , Message-ID: Wink wink http://www.forbes.com/sites/andygreenberg/2013/06/07/startup-palantir-denies-its-prism-software-is-the-nsas-prism-surveillance-system/ Sent from my Mobile Device. -------- Original message -------- From: "Jason L. Sparks" Date: 06/07/2013 1:31 PM (GMT-08:00) To: Warren Bailey Cc: Jay Ashworth ,NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project I assume the unclassified word "Prism" (which is found everywhere on IC resumes and open job descriptions) refers to Palantir's Prism suite. Could be wrong, but seems logical. On Fri, Jun 7, 2013 at 4:28 PM, Warren Bailey > wrote: Has anyone found out if this system is actually based on Narus? I associated this program as a super version of the AT&T thing, and if I recall it was understood that was Narus and Co via NSA/FBI? Sent from my Mobile Device. -------- Original message -------- From: Jay Ashworth > Date: 06/07/2013 12:16 PM (GMT-08:00) To: NANOG > Subject: Re: PRISM: NSA/FBI Internet data mining project ----- Original Message ----- > From: "Valdis Kletnieks" > > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: > > and also, only $20m/year? in my experience, the govt cannot do > > anything like this addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. > > Remember - the $20M number came from a source that has *very* good > reason to lie as much as it can right now about the true extent of this. Indeed. Luckily, the press is all over this like a bad smell. I mentioned The Story in a new posting just now; they have, surprisingly, already managed to dig at this spot, a pretty quick response for them: http://www.thestory.org/stories/2013-06/americans-spying-americans Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at impulse.net Fri Jun 7 21:32:21 2013 From: owen at impulse.net (Owen Roth) Date: Fri, 7 Jun 2013 14:32:21 -0700 (PDT) Subject: BGP filter issue -- need contact from Level3 Message-ID: <592744303.4934303.1370640741482.JavaMail.root@impulse.net> NANOG folks, I have had a bug with Level3 bgp filters for over a week, and have not been able to get a call back from their NOC despite multiple phone calls, for what should be a trivial change, but is buggy (yes I've used their normal process to no avail.) Can someone from their NOC or having a useful contact for same, please contact me off list so I can get this resolved. Much appreciated, ------------ Owen Roth Snr Network Engineer Impulse Advanced Communications owen at impulse.net 805-884-6332 From davidianwalker at gmail.com Fri Jun 7 21:43:46 2013 From: davidianwalker at gmail.com (David Walker) Date: Sat, 8 Jun 2013 07:13:46 +0930 Subject: PGP/SSL/TLS really as secure as one thinks? In-Reply-To: <51B1F8CC.9070402@massar.ch> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F8CC.9070402@massar.ch> Message-ID: On 08/06/2013, Jeroen Massar wrote: > On 2013-06-07 06:50, Dan White wrote: > [..] > > A nice 'it is Friday' kind of thought.... Caring about secrecy (or obscurity) of algorithms is a fools errand. http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle Taking Shannon's maxim "the enemy knows the system" to it's ultimate conclusion, the NSA put a premium on any and all looking at their algorithms. They'd prefer us to have a crack or they're not doing their job. As you say, they "have the top crypto people in the world" and this is a cherished paradigm of doing business in crypto land. Any useful system will survive that process. From cidr-report at potaroo.net Fri Jun 7 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Jun 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201306072200.r57M00eb058038@wattle.apnic.net> This report has been generated at Fri Jun 7 21:13:20 2013 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 31-05-13 456466 261325 01-06-13 457291 261189 02-06-13 457058 261549 03-06-13 457448 261806 04-06-13 457768 260371 05-06-13 456341 260320 06-06-13 456735 260392 07-06-13 457163 260501 AS Summary 44384 Number of ASes in routing system 18385 Number of ASes announcing only one prefix 3015 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116910048 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 07Jun13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 457311 260494 196817 43.0% All ASes AS6389 3015 79 2936 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2820 110 2710 96.1% NET Servi?os de Comunica??o S.A. AS4766 2958 942 2016 68.2% KIXS-AS-KR Korea Telecom AS17974 2523 546 1977 78.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1989 154 1835 92.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2650 830 1820 68.7% Telmex Colombia S.A. AS18566 2065 507 1558 75.4% COVAD - Covad Communications Co. AS7303 1732 454 1278 73.8% Telecom Argentina S.A. AS4323 1621 410 1211 74.7% TWTC - tw telecom holdings, inc. AS4755 1737 584 1153 66.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1069 85 984 92.0% RELCOM-AS OOO "NPO Relcom" AS7552 1164 187 977 83.9% VIETEL-AS-AP Vietel Corporation AS18881 974 29 945 97.0% Global Village Telecom AS36998 1237 301 936 75.7% SDN-MOBITEL AS1785 1991 1148 843 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 998 179 819 82.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1141 391 750 65.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 844 140 704 83.4% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS701 1533 843 690 45.0% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS22561 1192 511 681 57.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS855 731 54 677 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7545 2000 1326 674 33.7% TPG-INTERNET-AP TPG Telecom Limited AS24560 1077 409 668 62.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1277 612 665 52.1% Uninet S.A. de C.V. AS6983 1138 477 661 58.1% ITCDELTA - ITC^Deltacom AS8402 1660 1024 636 38.3% CORBINA-AS OJSC "Vimpelcom" AS17676 730 107 623 85.3% GIGAINFRA Softbank BB Corp. AS6147 665 48 617 92.8% Telefonica del Peru S.A.A. AS3549 1046 437 609 58.2% GBLX Global Crossing Ltd. AS34744 676 72 604 89.3% GVM S.C. GVM SISTEM 2003 S.R.L. Total 46253 12996 33257 71.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 100.100.100.0/24 AS9950 PUBNETPLUS2-AS-KR DACOM 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.50.176.0/24 AS38267 120.50.177.0/24 AS38267 120.50.178.0/24 AS38267 120.50.179.0/24 AS38267 120.50.180.0/24 AS38267 120.50.181.0/24 AS38267 120.50.182.0/24 AS38267 120.50.183.0/24 AS38267 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.128.0/20 AS32738 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.124.252.0/22 AS7303 Telecom Argentina S.A. 195.248.240.0/23 AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.70.56.0/21 AS32738 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.127.223.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jun 7 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Jun 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201306072200.r57M01pB058051@wattle.apnic.net> BGP Update Report Interval: 30-May-13 -to- 06-Jun-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 180296 6.9% 269.1 -- SDN-MOBITEL 2 - AS4837 130901 5.0% 246.1 -- CHINA169-BACKBONE CNCGROUP China169 Backbone 3 - AS17974 83748 3.2% 34.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS8402 53306 2.0% 35.4 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS4538 37215 1.4% 71.7 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS9829 31658 1.2% 50.7 -- BSNL-NIB National Internet Backbone 7 - AS18403 31281 1.2% 74.3 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 8 - AS35548 26358 1.0% 4393.0 -- SMARTTERRA-AS smartTERRA GmbH NL-AMS / DE-DUS1 / DE-DUS2 9 - AS5800 25716 1.0% 111.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 10 - AS33776 24043 0.9% 143.1 -- STARCOMMS-ASN 11 - AS50710 21353 0.8% 89.3 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 12 - AS7552 16537 0.6% 15.0 -- VIETEL-AS-AP Vietel Corporation 13 - AS2118 16177 0.6% 12.8 -- RELCOM-AS OOO "NPO Relcom" 14 - AS9416 16049 0.6% 8024.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 15 - AS3909 15563 0.6% 864.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 16 - AS28573 14239 0.6% 6.3 -- NET Servi?os de Comunica??o S.A. 17 - AS45899 13982 0.5% 37.5 -- VNPT-AS-VN VNPT Corp 18 - AS14420 13457 0.5% 40.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 19 - AS9854 13017 0.5% 13017.0 -- KTO-AS-KR KTO 20 - AS7029 12933 0.5% 7.2 -- WINDSTREAM - Windstream Communications Inc TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9854 13017 0.5% 13017.0 -- KTO-AS-KR KTO 2 - AS33920 8322 0.3% 8322.0 -- AQL (aq) Networks Limited 3 - AS9416 16049 0.6% 8024.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - AS19406 5177 0.2% 5177.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS8137 4724 0.2% 4724.0 -- DISNEYONLINE-AS - Disney Online 6 - AS29018 4397 0.2% 4397.0 -- WEBCONTROL-AS SmartTERRA GmbH 7 - AS35548 26358 1.0% 4393.0 -- SMARTTERRA-AS smartTERRA GmbH NL-AMS / DE-DUS1 / DE-DUS2 8 - AS6629 7293 0.3% 3646.5 -- NOAA-AS - NOAA 9 - AS6174 6300 0.2% 3150.0 -- SPRINTLINK8 - Sprint 10 - AS14733 2491 0.1% 2491.0 -- AS14733 - Barclays Capital Inc. 11 - AS14680 6977 0.3% 2325.7 -- REALE-6 - Auction.com 12 - AS36225 2156 0.1% 2156.0 -- INFINITEIT-ASN-01 - Infinite IT Solutions Inc. 13 - AS37367 3387 0.1% 1693.5 -- CALLKEY 14 - AS14453 4366 0.2% 1455.3 -- AS-AKN - ADVANCED KNOWLEDGE NETWORKS 15 - AS42334 4330 0.2% 1443.3 -- BBP-AS Broadband Plus s.a.l. 16 - AS37164 1396 0.1% 1396.0 -- ZAIN-SL 17 - AS36948 2483 0.1% 1241.5 -- KENIC 18 - AS57201 1236 0.1% 1236.0 -- EDF-AS Estonian Defence Forces 19 - AS10445 2204 0.1% 1102.0 -- HTG - Huntleigh Telcom 20 - AS44971 1860 0.1% 930.0 -- GOETEC-AS GOETEC Limited TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 211.214.206.0/24 13017 0.5% AS9854 -- KTO-AS-KR KTO 2 - 92.246.207.0/24 9613 0.3% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 202.41.70.0/24 9043 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 4 - 78.40.240.0/24 8322 0.3% AS33920 -- AQL (aq) Networks Limited 5 - 203.118.224.0/21 8051 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 203.118.232.0/21 7998 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - 192.58.232.0/24 7289 0.3% AS6629 -- NOAA-AS - NOAA 8 - 12.139.133.0/24 5863 0.2% AS14680 -- REALE-6 - Auction.com 9 - 173.232.234.0/24 5837 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 10 - 173.232.235.0/24 5837 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 11 - 69.38.178.0/24 5177 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 12 - 151.118.255.0/24 5168 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 13 - 151.118.254.0/24 5168 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 14 - 151.118.18.0/24 5151 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 15 - 198.187.189.0/24 4724 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 16 - 64.187.64.0/23 4494 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 17 - 213.218.160.0/19 4397 0.2% AS29018 -- WEBCONTROL-AS SmartTERRA GmbH 18 - 194.9.87.0/24 4396 0.2% AS35548 -- SMARTTERRA-AS smartTERRA GmbH NL-AMS / DE-DUS1 / DE-DUS2 19 - 195.225.132.0/22 4396 0.2% AS35548 -- SMARTTERRA-AS smartTERRA GmbH NL-AMS / DE-DUS1 / DE-DUS2 20 - 194.9.86.0/24 4396 0.2% AS35548 -- SMARTTERRA-AS smartTERRA GmbH NL-AMS / DE-DUS1 / DE-DUS2 Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From m.hallgren at free.fr Fri Jun 7 22:49:02 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Sat, 08 Jun 2013 00:49:02 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <337d509g596l6qg7obc158mr.1370624005739@email.android.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> , <337d509g596l6qg7obc158mr.1370624005739@email.android.com> Message-ID: <51B2635E.6080002@free.fr> Le 07/06/2013 19:10, Warren Bailey a ?crit : > Five days ago anyone who would have talked about the government having this capability would have been issued another tin foil hat. We think we know the truth now, but why hasn't echelon been brought up? I'm not calling anyone a liar, but isn't not speaking the truth the same thing? ;-) mh > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Matthew Petach > Date: 06/07/2013 9:34 AM (GMT-08:00) > To: > Cc: NANOG > Subject: Re: PRISM: NSA/FBI Internet data mining project > > > On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach wrote: > >> >> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: >> >>> Has fingers directly in servers of top Internet content companies, >>> dates to 2007. Happily, none of the companies listed are transport >>> networks: >>> >>> >>> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html >>> >>> Cheers, >>> -- jra >>> -- >>> Jay R. Ashworth Baylink >>> jra at baylink.com >>> Designer The Things I Think RFC >>> 2100 >>> Ashworth & Associates http://baylink.pitas.com 2000 Land >>> Rover DII >>> St Petersburg FL USA #natog +1 727 >>> 647 1274 >>> >>> >> I've always just assumed that if it's in electronic form, >> someone else is either reading it now, has already read >> it, or will read it as soon as I walk away from the screen. >> >> Much less stress in life that way. ^_^ >> >> Matt >> >> > When I posted this yesterday, I was speaking somewhat > tongue-in-cheek, because we hadn't yet made a formal > statement to the press. Now that we've made our official > reply, I can echo it, and note that whatever fluffed up > powerpoint was passed around to the washington post, > it does not reflect reality. There are no optical taps in > our datacenters funneling information out, there are no > sooper-seekret backdoors in the software that funnel > information to the government. As our formal reply > stated: "Yahoo does not provide the government with > direct access to its servers, systems, or network." > I believe the other major players supposedly listed > in the document have released similar statements, > all indicating a similar lack of super-cheap government > listening capabilities. > > Speaking just for myself, and if you quote me on this > as speaking on anyone else's behalf, you're a complete > fool, if the government was able to build infrastructure > that could listen to all the traffic from a major provider > for a fraction of what it costs them to handle that traffic > in the first place, I'd be truly amazed--and I'd probably > wonder why the company didn't outsource their infrastruture > to the government, if they can build and run it so much > more cheaply than the commercial providers. ;P > 7 companies were listed; if we assume the > burden was split roughly evenly between them, that's > 20M/7, about $2.85M per company per year to tap in, > or about $238,000/month per company listed, to > supposedly snoop on hundreds of gigs per second > of data. Two ways to handle it: tap in, and funnel > copies of all traffic back to distant monitoring posts, > or have local servers digesting and filtering, just > extracting the few nuggets they want, and sending > just those back. > > Let's take the first case; doing optical taps, or other > form of direct traffic mirroring, carrying it untouched > offsite to process; that's going to mean the ability to > siphon off hundreds of Gbps per datacenter and carry > it offsite for $238k/month; let's figure a major player > has data split across at least 3 datacenters, so about > $75K/month per datacenter to carry say 300Gbps of > traffic. It's pretty clearly going to have to be DWDM > on dark fiber at that traffic volume; most recent > quotes I've seen for dark fiber put it at $325/mile > for already-laid-in-ground (new builds are considerably > more, of course). If we figure the three datacenters > are split around just the US, on average you're going > to need to run about 1500 miles to reach their central > listening post; that's $49K/month just to carry the > bitstream, which leaves you just about $25K/month > to run the servers to digest that data; at 5c/kwhr, a > typical server pulling 300 watts is gonna cost you $11/month > to run; let's assume each server can process 2Gbps of > traffic, constantly; 150 servers for the stream of 300Gbps > means we're down to $22K for the rest of our support > costs; figure two sysadmins getting paid $10k/month > to run the servers (120k annual salary), and you've got > just $2k for G&A overhead. > > That's a heck of an efficient operation they'd have to be > running to listen in on all the traffic for the supposed > budget number claimed. > > I'm late for work; I'll follow up with a runthrough of the > other model, doing on-site digestion and processing > later, but I think you can see the point--it's not realistic > to think they can handle the volumes of data being > claimed at the price numbers listed. If they could, > the major providers would already be doing it for > much cheaper than they are today. I mean, the > Utah datacenter they're building is costing them > $2B to build; does anyone really think if they're > overpaying that much for datacenter space, they > could really snoop on provider traffic for only > $238K/month? > > More later--and remember, this is purely my own > rampant speculation, I'm not speaking for anyone, > on behalf of anyone, or even remotely authorized > or acknowledged by any entity on this rambling, > so please don't go quoting this anywhere else, > it'll make you look foolish, and probably get me > in trouble anyhow. :( > > Matt From fergdawgster at gmail.com Fri Jun 7 22:54:34 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 7 Jun 2013 15:54:34 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B2635E.6080002@free.fr> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: Also of interest: http://www.guardian.co.uk/world/2013/jun/07/nsa-prism-records-surveillance-questions - ferg On Fri, Jun 7, 2013 at 3:49 PM, Michael Hallgren wrote: > Le 07/06/2013 19:10, Warren Bailey a ?crit : >> Five days ago anyone who would have talked about the government having this capability would have been issued another tin foil hat. We think we know the truth now, but why hasn't echelon been brought up? I'm not calling anyone a liar, but isn't not speaking the truth the same thing? > > > ;-) > > mh > >> >> >> Sent from my Mobile Device. >> >> >> -------- Original message -------- >> From: Matthew Petach >> Date: 06/07/2013 9:34 AM (GMT-08:00) >> To: >> Cc: NANOG >> Subject: Re: PRISM: NSA/FBI Internet data mining project >> >> >> On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach wrote: >> >>> >>> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: >>> >>>> Has fingers directly in servers of top Internet content companies, >>>> dates to 2007. Happily, none of the companies listed are transport >>>> networks: >>>> >>>> >>>> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html >>>> >>>> Cheers, >>>> -- jra >>>> -- >>>> Jay R. Ashworth Baylink >>>> jra at baylink.com >>>> Designer The Things I Think RFC >>>> 2100 >>>> Ashworth & Associates http://baylink.pitas.com 2000 Land >>>> Rover DII >>>> St Petersburg FL USA #natog +1 727 >>>> 647 1274 >>>> >>>> >>> I've always just assumed that if it's in electronic form, >>> someone else is either reading it now, has already read >>> it, or will read it as soon as I walk away from the screen. >>> >>> Much less stress in life that way. ^_^ >>> >>> Matt >>> >>> >> When I posted this yesterday, I was speaking somewhat >> tongue-in-cheek, because we hadn't yet made a formal >> statement to the press. Now that we've made our official >> reply, I can echo it, and note that whatever fluffed up >> powerpoint was passed around to the washington post, >> it does not reflect reality. There are no optical taps in >> our datacenters funneling information out, there are no >> sooper-seekret backdoors in the software that funnel >> information to the government. As our formal reply >> stated: "Yahoo does not provide the government with >> direct access to its servers, systems, or network." >> I believe the other major players supposedly listed >> in the document have released similar statements, >> all indicating a similar lack of super-cheap government >> listening capabilities. >> >> Speaking just for myself, and if you quote me on this >> as speaking on anyone else's behalf, you're a complete >> fool, if the government was able to build infrastructure >> that could listen to all the traffic from a major provider >> for a fraction of what it costs them to handle that traffic >> in the first place, I'd be truly amazed--and I'd probably >> wonder why the company didn't outsource their infrastruture >> to the government, if they can build and run it so much >> more cheaply than the commercial providers. ;P >> 7 companies were listed; if we assume the >> burden was split roughly evenly between them, that's >> 20M/7, about $2.85M per company per year to tap in, >> or about $238,000/month per company listed, to >> supposedly snoop on hundreds of gigs per second >> of data. Two ways to handle it: tap in, and funnel >> copies of all traffic back to distant monitoring posts, >> or have local servers digesting and filtering, just >> extracting the few nuggets they want, and sending >> just those back. >> >> Let's take the first case; doing optical taps, or other >> form of direct traffic mirroring, carrying it untouched >> offsite to process; that's going to mean the ability to >> siphon off hundreds of Gbps per datacenter and carry >> it offsite for $238k/month; let's figure a major player >> has data split across at least 3 datacenters, so about >> $75K/month per datacenter to carry say 300Gbps of >> traffic. It's pretty clearly going to have to be DWDM >> on dark fiber at that traffic volume; most recent >> quotes I've seen for dark fiber put it at $325/mile >> for already-laid-in-ground (new builds are considerably >> more, of course). If we figure the three datacenters >> are split around just the US, on average you're going >> to need to run about 1500 miles to reach their central >> listening post; that's $49K/month just to carry the >> bitstream, which leaves you just about $25K/month >> to run the servers to digest that data; at 5c/kwhr, a >> typical server pulling 300 watts is gonna cost you $11/month >> to run; let's assume each server can process 2Gbps of >> traffic, constantly; 150 servers for the stream of 300Gbps >> means we're down to $22K for the rest of our support >> costs; figure two sysadmins getting paid $10k/month >> to run the servers (120k annual salary), and you've got >> just $2k for G&A overhead. >> >> That's a heck of an efficient operation they'd have to be >> running to listen in on all the traffic for the supposed >> budget number claimed. >> >> I'm late for work; I'll follow up with a runthrough of the >> other model, doing on-site digestion and processing >> later, but I think you can see the point--it's not realistic >> to think they can handle the volumes of data being >> claimed at the price numbers listed. If they could, >> the major providers would already be doing it for >> much cheaper than they are today. I mean, the >> Utah datacenter they're building is costing them >> $2B to build; does anyone really think if they're >> overpaying that much for datacenter space, they >> could really snoop on provider traffic for only >> $238K/month? >> >> More later--and remember, this is purely my own >> rampant speculation, I'm not speaking for anyone, >> on behalf of anyone, or even remotely authorized >> or acknowledged by any entity on this rambling, >> so please don't go quoting this anywhere else, >> it'll make you look foolish, and probably get me >> in trouble anyhow. :( >> >> Matt > > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From mis at seiden.com Fri Jun 7 23:04:45 2013 From: mis at seiden.com (Mark Seiden) Date: Fri, 7 Jun 2013 16:04:45 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <13976.1370628323@turing-police.cc.vt.edu> <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> , Message-ID: the palantir financial product named prism is useless for intelligence analysis. it's for timeseries financial data. my understanding is it's a completely different product, code base and market from the connect-the-dots product they sell as a competitor to i2's Analyst's Notebook product. "these are not the droids you're looking for" On Jun 7, 2013, at 2:21 PM, Warren Bailey wrote: > Wink wink > http://www.forbes.com/sites/andygreenberg/2013/06/07/startup-palantir-denies-its-prism-software-is-the-nsas-prism-surveillance-system/ > > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: "Jason L. Sparks" > Date: 06/07/2013 1:31 PM (GMT-08:00) > To: Warren Bailey > Cc: Jay Ashworth ,NANOG > Subject: Re: PRISM: NSA/FBI Internet data mining project > > > I assume the unclassified word "Prism" (which is found everywhere on IC resumes and open job descriptions) refers to Palantir's Prism suite. Could be wrong, but seems logical. > > > On Fri, Jun 7, 2013 at 4:28 PM, Warren Bailey > wrote: > Has anyone found out if this system is actually based on Narus? I associated this program as a super version of the AT&T thing, and if I recall it was understood that was Narus and Co via NSA/FBI? > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Jay Ashworth > > Date: 06/07/2013 12:16 PM (GMT-08:00) > To: NANOG > > Subject: Re: PRISM: NSA/FBI Internet data mining project > > > ----- Original Message ----- >> From: "Valdis Kletnieks" > > >> On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: >>> and also, only $20m/year? in my experience, the govt cannot do >>> anything like this addressing even a single provider for that little money. >> >> Convince me the *real* number doesn't have another zero. >> >> Remember - the $20M number came from a source that has *very* good >> reason to lie as much as it can right now about the true extent of this. > > Indeed. Luckily, the press is all over this like a bad smell. > > I mentioned The Story in a new posting just now; they have, surprisingly, > already managed to dig at this spot, a pretty quick response for them: > > http://www.thestory.org/stories/2013-06/americans-spying-americans > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > > From brunner at nic-naa.net Fri Jun 7 23:17:14 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 07 Jun 2013 16:17:14 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <13976.1370628323@turing-police.cc.vt.edu> <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> , Message-ID: <51B269FA.9070106@nic-naa.net> http://www.guardian.co.uk/world/2013/jun/07/obama-china-targets-cyber-overseas the headline may be misleading. Presidential Policy Directive 20 defines OCEO as "operations and related programs or activities ? conducted by or on behalf of the United States Government, in or through cyberspace, that are intended to enable or produce cyber effects outside United States government networks." effects outside United States government networks. now there's an interesting phrase. OCEO == "Offensive Cyber Effects Operations". -e From mis at seiden.com Fri Jun 7 23:43:59 2013 From: mis at seiden.com (Mark Seiden) Date: Fri, 7 Jun 2013 16:43:59 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: what a piece of crap this article is. the guy doesn't understand what sniffing can and can't do. obviously he doesn't understand peering or routing, and he doesn't understand what cdns are for. he doesn't understand the EU safe harbor, saying it applies to govt entitites, when it's purely about companies hosting data of EU citizens. he quotes a source who suggests that the intel community might have privileged search access to facebook, which i don't believe. he even says "company-owned equipment" might refer to the NSA, which i thought everybody calls the "agency" so to not confuse with the CIA. and he suggests that these companies might have given up their "master decryption keys" (as he terms them) so that USG could decrypt SSL. and the $20M cost per year, which would only pay for something the size of a portal or a web site, well, that's mysterious. sheesh. this is not journalism. On Jun 7, 2013, at 3:54 PM, Paul Ferguson wrote: > Also of interest: > > http://www.guardian.co.uk/world/2013/jun/07/nsa-prism-records-surveillance-questions > > - ferg > > > On Fri, Jun 7, 2013 at 3:49 PM, Michael Hallgren wrote: > >> Le 07/06/2013 19:10, Warren Bailey a ?crit : >>> Five days ago anyone who would have talked about the government having this capability would have been issued another tin foil hat. We think we know the truth now, but why hasn't echelon been brought up? I'm not calling anyone a liar, but isn't not speaking the truth the same thing? >> >> >> ;-) >> >> mh >> >>> >>> >>> Sent from my Mobile Device. >>> >>> >>> -------- Original message -------- >>> From: Matthew Petach >>> Date: 06/07/2013 9:34 AM (GMT-08:00) >>> To: >>> Cc: NANOG >>> Subject: Re: PRISM: NSA/FBI Internet data mining project >>> >>> >>> On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach wrote: >>> >>>> >>>> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: >>>> >>>>> Has fingers directly in servers of top Internet content companies, >>>>> dates to 2007. Happily, none of the companies listed are transport >>>>> networks: >>>>> >>>>> >>>>> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html >>>>> >>>>> Cheers, >>>>> -- jra >>>>> -- >>>>> Jay R. Ashworth Baylink >>>>> jra at baylink.com >>>>> Designer The Things I Think RFC >>>>> 2100 >>>>> Ashworth & Associates http://baylink.pitas.com 2000 Land >>>>> Rover DII >>>>> St Petersburg FL USA #natog +1 727 >>>>> 647 1274 >>>>> >>>>> >>>> I've always just assumed that if it's in electronic form, >>>> someone else is either reading it now, has already read >>>> it, or will read it as soon as I walk away from the screen. >>>> >>>> Much less stress in life that way. ^_^ >>>> >>>> Matt >>>> >>>> >>> When I posted this yesterday, I was speaking somewhat >>> tongue-in-cheek, because we hadn't yet made a formal >>> statement to the press. Now that we've made our official >>> reply, I can echo it, and note that whatever fluffed up >>> powerpoint was passed around to the washington post, >>> it does not reflect reality. There are no optical taps in >>> our datacenters funneling information out, there are no >>> sooper-seekret backdoors in the software that funnel >>> information to the government. As our formal reply >>> stated: "Yahoo does not provide the government with >>> direct access to its servers, systems, or network." >>> I believe the other major players supposedly listed >>> in the document have released similar statements, >>> all indicating a similar lack of super-cheap government >>> listening capabilities. >>> >>> Speaking just for myself, and if you quote me on this >>> as speaking on anyone else's behalf, you're a complete >>> fool, if the government was able to build infrastructure >>> that could listen to all the traffic from a major provider >>> for a fraction of what it costs them to handle that traffic >>> in the first place, I'd be truly amazed--and I'd probably >>> wonder why the company didn't outsource their infrastruture >>> to the government, if they can build and run it so much >>> more cheaply than the commercial providers. ;P >>> 7 companies were listed; if we assume the >>> burden was split roughly evenly between them, that's >>> 20M/7, about $2.85M per company per year to tap in, >>> or about $238,000/month per company listed, to >>> supposedly snoop on hundreds of gigs per second >>> of data. Two ways to handle it: tap in, and funnel >>> copies of all traffic back to distant monitoring posts, >>> or have local servers digesting and filtering, just >>> extracting the few nuggets they want, and sending >>> just those back. >>> >>> Let's take the first case; doing optical taps, or other >>> form of direct traffic mirroring, carrying it untouched >>> offsite to process; that's going to mean the ability to >>> siphon off hundreds of Gbps per datacenter and carry >>> it offsite for $238k/month; let's figure a major player >>> has data split across at least 3 datacenters, so about >>> $75K/month per datacenter to carry say 300Gbps of >>> traffic. It's pretty clearly going to have to be DWDM >>> on dark fiber at that traffic volume; most recent >>> quotes I've seen for dark fiber put it at $325/mile >>> for already-laid-in-ground (new builds are considerably >>> more, of course). If we figure the three datacenters >>> are split around just the US, on average you're going >>> to need to run about 1500 miles to reach their central >>> listening post; that's $49K/month just to carry the >>> bitstream, which leaves you just about $25K/month >>> to run the servers to digest that data; at 5c/kwhr, a >>> typical server pulling 300 watts is gonna cost you $11/month >>> to run; let's assume each server can process 2Gbps of >>> traffic, constantly; 150 servers for the stream of 300Gbps >>> means we're down to $22K for the rest of our support >>> costs; figure two sysadmins getting paid $10k/month >>> to run the servers (120k annual salary), and you've got >>> just $2k for G&A overhead. >>> >>> That's a heck of an efficient operation they'd have to be >>> running to listen in on all the traffic for the supposed >>> budget number claimed. >>> >>> I'm late for work; I'll follow up with a runthrough of the >>> other model, doing on-site digestion and processing >>> later, but I think you can see the point--it's not realistic >>> to think they can handle the volumes of data being >>> claimed at the price numbers listed. If they could, >>> the major providers would already be doing it for >>> much cheaper than they are today. I mean, the >>> Utah datacenter they're building is costing them >>> $2B to build; does anyone really think if they're >>> overpaying that much for datacenter space, they >>> could really snoop on provider traffic for only >>> $238K/month? >>> >>> More later--and remember, this is purely my own >>> rampant speculation, I'm not speaking for anyone, >>> on behalf of anyone, or even remotely authorized >>> or acknowledged by any entity on this rambling, >>> so please don't go quoting this anywhere else, >>> it'll make you look foolish, and probably get me >>> in trouble anyhow. :( >>> >>> Matt >> >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > From symack at gmail.com Sat Jun 8 00:14:12 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 7 Jun 2013 20:14:12 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: Tax payer money...... :) On 6/7/13, Mark Seiden wrote: > what a piece of crap this article is. > > the guy doesn't understand what sniffing can and can't do. obviously he > doesn't understand peering or routing, and he doesn't understand what cdns > are for. > > he doesn't understand the EU safe harbor, saying it applies to govt > entitites, when it's purely about companies hosting data of EU citizens. > > he quotes a source who suggests that the intel community might have > privileged search access to facebook, which i don't believe. > > he even says "company-owned equipment" might refer to the NSA, which i > thought everybody calls the "agency" so to not confuse with the CIA. > > and he suggests that these companies might have given up their "master > decryption keys" (as he terms them) so that USG could decrypt SSL. > > and the $20M cost per year, which would only pay for something the size of a > portal or a web site, well, that's mysterious. > > sheesh. > > this is not journalism. > > > On Jun 7, 2013, at 3:54 PM, Paul Ferguson wrote: > >> Also of interest: >> >> http://www.guardian.co.uk/world/2013/jun/07/nsa-prism-records-surveillance-questions >> >> - ferg >> >> >> On Fri, Jun 7, 2013 at 3:49 PM, Michael Hallgren >> wrote: >> >>> Le 07/06/2013 19:10, Warren Bailey a ?crit : >>>> Five days ago anyone who would have talked about the government having >>>> this capability would have been issued another tin foil hat. We think we >>>> know the truth now, but why hasn't echelon been brought up? I'm not >>>> calling anyone a liar, but isn't not speaking the truth the same thing? >>> >>> >>> ;-) >>> >>> mh >>> >>>> >>>> >>>> Sent from my Mobile Device. >>>> >>>> >>>> -------- Original message -------- >>>> From: Matthew Petach >>>> Date: 06/07/2013 9:34 AM (GMT-08:00) >>>> To: >>>> Cc: NANOG >>>> Subject: Re: PRISM: NSA/FBI Internet data mining project >>>> >>>> >>>> On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach >>>> wrote: >>>> >>>>> >>>>> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: >>>>> >>>>>> Has fingers directly in servers of top Internet content companies, >>>>>> dates to 2007. Happily, none of the companies listed are transport >>>>>> networks: >>>>>> >>>>>> >>>>>> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html >>>>>> >>>>>> Cheers, >>>>>> -- jra >>>>>> -- >>>>>> Jay R. Ashworth Baylink >>>>>> jra at baylink.com >>>>>> Designer The Things I Think >>>>>> RFC >>>>>> 2100 >>>>>> Ashworth & Associates http://baylink.pitas.com 2000 Land >>>>>> Rover DII >>>>>> St Petersburg FL USA #natog +1 727 >>>>>> 647 1274 >>>>>> >>>>>> >>>>> I've always just assumed that if it's in electronic form, >>>>> someone else is either reading it now, has already read >>>>> it, or will read it as soon as I walk away from the screen. >>>>> >>>>> Much less stress in life that way. ^_^ >>>>> >>>>> Matt >>>>> >>>>> >>>> When I posted this yesterday, I was speaking somewhat >>>> tongue-in-cheek, because we hadn't yet made a formal >>>> statement to the press. Now that we've made our official >>>> reply, I can echo it, and note that whatever fluffed up >>>> powerpoint was passed around to the washington post, >>>> it does not reflect reality. There are no optical taps in >>>> our datacenters funneling information out, there are no >>>> sooper-seekret backdoors in the software that funnel >>>> information to the government. As our formal reply >>>> stated: "Yahoo does not provide the government with >>>> direct access to its servers, systems, or network." >>>> I believe the other major players supposedly listed >>>> in the document have released similar statements, >>>> all indicating a similar lack of super-cheap government >>>> listening capabilities. >>>> >>>> Speaking just for myself, and if you quote me on this >>>> as speaking on anyone else's behalf, you're a complete >>>> fool, if the government was able to build infrastructure >>>> that could listen to all the traffic from a major provider >>>> for a fraction of what it costs them to handle that traffic >>>> in the first place, I'd be truly amazed--and I'd probably >>>> wonder why the company didn't outsource their infrastruture >>>> to the government, if they can build and run it so much >>>> more cheaply than the commercial providers. ;P >>>> 7 companies were listed; if we assume the >>>> burden was split roughly evenly between them, that's >>>> 20M/7, about $2.85M per company per year to tap in, >>>> or about $238,000/month per company listed, to >>>> supposedly snoop on hundreds of gigs per second >>>> of data. Two ways to handle it: tap in, and funnel >>>> copies of all traffic back to distant monitoring posts, >>>> or have local servers digesting and filtering, just >>>> extracting the few nuggets they want, and sending >>>> just those back. >>>> >>>> Let's take the first case; doing optical taps, or other >>>> form of direct traffic mirroring, carrying it untouched >>>> offsite to process; that's going to mean the ability to >>>> siphon off hundreds of Gbps per datacenter and carry >>>> it offsite for $238k/month; let's figure a major player >>>> has data split across at least 3 datacenters, so about >>>> $75K/month per datacenter to carry say 300Gbps of >>>> traffic. It's pretty clearly going to have to be DWDM >>>> on dark fiber at that traffic volume; most recent >>>> quotes I've seen for dark fiber put it at $325/mile >>>> for already-laid-in-ground (new builds are considerably >>>> more, of course). If we figure the three datacenters >>>> are split around just the US, on average you're going >>>> to need to run about 1500 miles to reach their central >>>> listening post; that's $49K/month just to carry the >>>> bitstream, which leaves you just about $25K/month >>>> to run the servers to digest that data; at 5c/kwhr, a >>>> typical server pulling 300 watts is gonna cost you $11/month >>>> to run; let's assume each server can process 2Gbps of >>>> traffic, constantly; 150 servers for the stream of 300Gbps >>>> means we're down to $22K for the rest of our support >>>> costs; figure two sysadmins getting paid $10k/month >>>> to run the servers (120k annual salary), and you've got >>>> just $2k for G&A overhead. >>>> >>>> That's a heck of an efficient operation they'd have to be >>>> running to listen in on all the traffic for the supposed >>>> budget number claimed. >>>> >>>> I'm late for work; I'll follow up with a runthrough of the >>>> other model, doing on-site digestion and processing >>>> later, but I think you can see the point--it's not realistic >>>> to think they can handle the volumes of data being >>>> claimed at the price numbers listed. If they could, >>>> the major providers would already be doing it for >>>> much cheaper than they are today. I mean, the >>>> Utah datacenter they're building is costing them >>>> $2B to build; does anyone really think if they're >>>> overpaying that much for datacenter space, they >>>> could really snoop on provider traffic for only >>>> $238K/month? >>>> >>>> More later--and remember, this is purely my own >>>> rampant speculation, I'm not speaking for anyone, >>>> on behalf of anyone, or even remotely authorized >>>> or acknowledged by any entity on this rambling, >>>> so please don't go quoting this anywhere else, >>>> it'll make you look foolish, and probably get me >>>> in trouble anyhow. :( >>>> >>>> Matt >>> >>> >> >> >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> fergdawgster(at)gmail.com >> > > > From symack at gmail.com Sat Jun 8 00:14:39 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 7 Jun 2013 20:14:39 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: Sorry for the top post!!!! From sakamura at gmail.com Sat Jun 8 00:57:13 2013 From: sakamura at gmail.com (Ishmael Rufus) Date: Fri, 7 Jun 2013 19:57:13 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: So when are we rioting? On Fri, Jun 7, 2013 at 7:14 PM, Nick Khamis wrote: > Tax payer money...... :) > > On 6/7/13, Mark Seiden wrote: > > what a piece of crap this article is. > > > > the guy doesn't understand what sniffing can and can't do. obviously he > > doesn't understand peering or routing, and he doesn't understand what > cdns > > are for. > > > > he doesn't understand the EU safe harbor, saying it applies to govt > > entitites, when it's purely about companies hosting data of EU citizens. > > > > he quotes a source who suggests that the intel community might have > > privileged search access to facebook, which i don't believe. > > > > he even says "company-owned equipment" might refer to the NSA, which i > > thought everybody calls the "agency" so to not confuse with the CIA. > > > > and he suggests that these companies might have given up their "master > > decryption keys" (as he terms them) so that USG could decrypt SSL. > > > > and the $20M cost per year, which would only pay for something the size > of a > > portal or a web site, well, that's mysterious. > > > > sheesh. > > > > this is not journalism. > > > > > > On Jun 7, 2013, at 3:54 PM, Paul Ferguson > wrote: > > > >> Also of interest: > >> > >> > http://www.guardian.co.uk/world/2013/jun/07/nsa-prism-records-surveillance-questions > >> > >> - ferg > >> > >> > >> On Fri, Jun 7, 2013 at 3:49 PM, Michael Hallgren > >> wrote: > >> > >>> Le 07/06/2013 19:10, Warren Bailey a ?crit : > >>>> Five days ago anyone who would have talked about the government having > >>>> this capability would have been issued another tin foil hat. We think > we > >>>> know the truth now, but why hasn't echelon been brought up? I'm not > >>>> calling anyone a liar, but isn't not speaking the truth the same > thing? > >>> > >>> > >>> ;-) > >>> > >>> mh > >>> > >>>> > >>>> > >>>> Sent from my Mobile Device. > >>>> > >>>> > >>>> -------- Original message -------- > >>>> From: Matthew Petach > >>>> Date: 06/07/2013 9:34 AM (GMT-08:00) > >>>> To: > >>>> Cc: NANOG > >>>> Subject: Re: PRISM: NSA/FBI Internet data mining project > >>>> > >>>> > >>>> On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach > >>>> wrote: > >>>> > >>>>> > >>>>> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth > wrote: > >>>>> > >>>>>> Has fingers directly in servers of top Internet content companies, > >>>>>> dates to 2007. Happily, none of the companies listed are transport > >>>>>> networks: > >>>>>> > >>>>>> > >>>>>> > http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html > >>>>>> > >>>>>> Cheers, > >>>>>> -- jra > >>>>>> -- > >>>>>> Jay R. Ashworth Baylink > >>>>>> jra at baylink.com > >>>>>> Designer The Things I Think > >>>>>> RFC > >>>>>> 2100 > >>>>>> Ashworth & Associates http://baylink.pitas.com 2000 > Land > >>>>>> Rover DII > >>>>>> St Petersburg FL USA #natog +1 > 727 > >>>>>> 647 1274 > >>>>>> > >>>>>> > >>>>> I've always just assumed that if it's in electronic form, > >>>>> someone else is either reading it now, has already read > >>>>> it, or will read it as soon as I walk away from the screen. > >>>>> > >>>>> Much less stress in life that way. ^_^ > >>>>> > >>>>> Matt > >>>>> > >>>>> > >>>> When I posted this yesterday, I was speaking somewhat > >>>> tongue-in-cheek, because we hadn't yet made a formal > >>>> statement to the press. Now that we've made our official > >>>> reply, I can echo it, and note that whatever fluffed up > >>>> powerpoint was passed around to the washington post, > >>>> it does not reflect reality. There are no optical taps in > >>>> our datacenters funneling information out, there are no > >>>> sooper-seekret backdoors in the software that funnel > >>>> information to the government. As our formal reply > >>>> stated: "Yahoo does not provide the government with > >>>> direct access to its servers, systems, or network." > >>>> I believe the other major players supposedly listed > >>>> in the document have released similar statements, > >>>> all indicating a similar lack of super-cheap government > >>>> listening capabilities. > >>>> > >>>> Speaking just for myself, and if you quote me on this > >>>> as speaking on anyone else's behalf, you're a complete > >>>> fool, if the government was able to build infrastructure > >>>> that could listen to all the traffic from a major provider > >>>> for a fraction of what it costs them to handle that traffic > >>>> in the first place, I'd be truly amazed--and I'd probably > >>>> wonder why the company didn't outsource their infrastruture > >>>> to the government, if they can build and run it so much > >>>> more cheaply than the commercial providers. ;P > >>>> 7 companies were listed; if we assume the > >>>> burden was split roughly evenly between them, that's > >>>> 20M/7, about $2.85M per company per year to tap in, > >>>> or about $238,000/month per company listed, to > >>>> supposedly snoop on hundreds of gigs per second > >>>> of data. Two ways to handle it: tap in, and funnel > >>>> copies of all traffic back to distant monitoring posts, > >>>> or have local servers digesting and filtering, just > >>>> extracting the few nuggets they want, and sending > >>>> just those back. > >>>> > >>>> Let's take the first case; doing optical taps, or other > >>>> form of direct traffic mirroring, carrying it untouched > >>>> offsite to process; that's going to mean the ability to > >>>> siphon off hundreds of Gbps per datacenter and carry > >>>> it offsite for $238k/month; let's figure a major player > >>>> has data split across at least 3 datacenters, so about > >>>> $75K/month per datacenter to carry say 300Gbps of > >>>> traffic. It's pretty clearly going to have to be DWDM > >>>> on dark fiber at that traffic volume; most recent > >>>> quotes I've seen for dark fiber put it at $325/mile > >>>> for already-laid-in-ground (new builds are considerably > >>>> more, of course). If we figure the three datacenters > >>>> are split around just the US, on average you're going > >>>> to need to run about 1500 miles to reach their central > >>>> listening post; that's $49K/month just to carry the > >>>> bitstream, which leaves you just about $25K/month > >>>> to run the servers to digest that data; at 5c/kwhr, a > >>>> typical server pulling 300 watts is gonna cost you $11/month > >>>> to run; let's assume each server can process 2Gbps of > >>>> traffic, constantly; 150 servers for the stream of 300Gbps > >>>> means we're down to $22K for the rest of our support > >>>> costs; figure two sysadmins getting paid $10k/month > >>>> to run the servers (120k annual salary), and you've got > >>>> just $2k for G&A overhead. > >>>> > >>>> That's a heck of an efficient operation they'd have to be > >>>> running to listen in on all the traffic for the supposed > >>>> budget number claimed. > >>>> > >>>> I'm late for work; I'll follow up with a runthrough of the > >>>> other model, doing on-site digestion and processing > >>>> later, but I think you can see the point--it's not realistic > >>>> to think they can handle the volumes of data being > >>>> claimed at the price numbers listed. If they could, > >>>> the major providers would already be doing it for > >>>> much cheaper than they are today. I mean, the > >>>> Utah datacenter they're building is costing them > >>>> $2B to build; does anyone really think if they're > >>>> overpaying that much for datacenter space, they > >>>> could really snoop on provider traffic for only > >>>> $238K/month? > >>>> > >>>> More later--and remember, this is purely my own > >>>> rampant speculation, I'm not speaking for anyone, > >>>> on behalf of anyone, or even remotely authorized > >>>> or acknowledged by any entity on this rambling, > >>>> so please don't go quoting this anywhere else, > >>>> it'll make you look foolish, and probably get me > >>>> in trouble anyhow. :( > >>>> > >>>> Matt > >>> > >>> > >> > >> > >> > >> -- > >> "Fergie", a.k.a. Paul Ferguson > >> fergdawgster(at)gmail.com > >> > > > > > > > > From nick at pelagiris.org Sat Jun 8 00:59:37 2013 From: nick at pelagiris.org (Nick B) Date: Fri, 7 Jun 2013 20:59:37 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: I'd love to, but American Idle is on in 5 minutes. Maybe next time? Nick On Fri, Jun 7, 2013 at 8:57 PM, Ishmael Rufus wrote: > So when are we rioting? > > > On Fri, Jun 7, 2013 at 7:14 PM, Nick Khamis wrote: > > > Tax payer money...... :) > > > > On 6/7/13, Mark Seiden wrote: > > > what a piece of crap this article is. > > > > > > the guy doesn't understand what sniffing can and can't do. obviously > he > > > doesn't understand peering or routing, and he doesn't understand what > > cdns > > > are for. > > > > > > he doesn't understand the EU safe harbor, saying it applies to govt > > > entitites, when it's purely about companies hosting data of EU > citizens. > > > > > > he quotes a source who suggests that the intel community might have > > > privileged search access to facebook, which i don't believe. > > > > > > he even says "company-owned equipment" might refer to the NSA, which i > > > thought everybody calls the "agency" so to not confuse with the CIA. > > > > > > and he suggests that these companies might have given up their "master > > > decryption keys" (as he terms them) so that USG could decrypt SSL. > > > > > > and the $20M cost per year, which would only pay for something the size > > of a > > > portal or a web site, well, that's mysterious. > > > > > > sheesh. > > > > > > this is not journalism. > > > > > > > > > On Jun 7, 2013, at 3:54 PM, Paul Ferguson > > wrote: > > > > > >> Also of interest: > > >> > > >> > > > http://www.guardian.co.uk/world/2013/jun/07/nsa-prism-records-surveillance-questions > > >> > > >> - ferg > > >> > > >> > > >> On Fri, Jun 7, 2013 at 3:49 PM, Michael Hallgren > > >> wrote: > > >> > > >>> Le 07/06/2013 19:10, Warren Bailey a ?crit : > > >>>> Five days ago anyone who would have talked about the government > having > > >>>> this capability would have been issued another tin foil hat. We > think > > we > > >>>> know the truth now, but why hasn't echelon been brought up? I'm not > > >>>> calling anyone a liar, but isn't not speaking the truth the same > > thing? > > >>> > > >>> > > >>> ;-) > > >>> > > >>> mh > > >>> > > >>>> > > >>>> > > >>>> Sent from my Mobile Device. > > >>>> > > >>>> > > >>>> -------- Original message -------- > > >>>> From: Matthew Petach > > >>>> Date: 06/07/2013 9:34 AM (GMT-08:00) > > >>>> To: > > >>>> Cc: NANOG > > >>>> Subject: Re: PRISM: NSA/FBI Internet data mining project > > >>>> > > >>>> > > >>>> On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach > > >>>> wrote: > > >>>> > > >>>>> > > >>>>> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth > > wrote: > > >>>>> > > >>>>>> Has fingers directly in servers of top Internet content companies, > > >>>>>> dates to 2007. Happily, none of the companies listed are > transport > > >>>>>> networks: > > >>>>>> > > >>>>>> > > >>>>>> > > > http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html > > >>>>>> > > >>>>>> Cheers, > > >>>>>> -- jra > > >>>>>> -- > > >>>>>> Jay R. Ashworth Baylink > > >>>>>> jra at baylink.com > > >>>>>> Designer The Things I Think > > >>>>>> RFC > > >>>>>> 2100 > > >>>>>> Ashworth & Associates http://baylink.pitas.com 2000 > > Land > > >>>>>> Rover DII > > >>>>>> St Petersburg FL USA #natog +1 > > 727 > > >>>>>> 647 1274 > > >>>>>> > > >>>>>> > > >>>>> I've always just assumed that if it's in electronic form, > > >>>>> someone else is either reading it now, has already read > > >>>>> it, or will read it as soon as I walk away from the screen. > > >>>>> > > >>>>> Much less stress in life that way. ^_^ > > >>>>> > > >>>>> Matt > > >>>>> > > >>>>> > > >>>> When I posted this yesterday, I was speaking somewhat > > >>>> tongue-in-cheek, because we hadn't yet made a formal > > >>>> statement to the press. Now that we've made our official > > >>>> reply, I can echo it, and note that whatever fluffed up > > >>>> powerpoint was passed around to the washington post, > > >>>> it does not reflect reality. There are no optical taps in > > >>>> our datacenters funneling information out, there are no > > >>>> sooper-seekret backdoors in the software that funnel > > >>>> information to the government. As our formal reply > > >>>> stated: "Yahoo does not provide the government with > > >>>> direct access to its servers, systems, or network." > > >>>> I believe the other major players supposedly listed > > >>>> in the document have released similar statements, > > >>>> all indicating a similar lack of super-cheap government > > >>>> listening capabilities. > > >>>> > > >>>> Speaking just for myself, and if you quote me on this > > >>>> as speaking on anyone else's behalf, you're a complete > > >>>> fool, if the government was able to build infrastructure > > >>>> that could listen to all the traffic from a major provider > > >>>> for a fraction of what it costs them to handle that traffic > > >>>> in the first place, I'd be truly amazed--and I'd probably > > >>>> wonder why the company didn't outsource their infrastruture > > >>>> to the government, if they can build and run it so much > > >>>> more cheaply than the commercial providers. ;P > > >>>> 7 companies were listed; if we assume the > > >>>> burden was split roughly evenly between them, that's > > >>>> 20M/7, about $2.85M per company per year to tap in, > > >>>> or about $238,000/month per company listed, to > > >>>> supposedly snoop on hundreds of gigs per second > > >>>> of data. Two ways to handle it: tap in, and funnel > > >>>> copies of all traffic back to distant monitoring posts, > > >>>> or have local servers digesting and filtering, just > > >>>> extracting the few nuggets they want, and sending > > >>>> just those back. > > >>>> > > >>>> Let's take the first case; doing optical taps, or other > > >>>> form of direct traffic mirroring, carrying it untouched > > >>>> offsite to process; that's going to mean the ability to > > >>>> siphon off hundreds of Gbps per datacenter and carry > > >>>> it offsite for $238k/month; let's figure a major player > > >>>> has data split across at least 3 datacenters, so about > > >>>> $75K/month per datacenter to carry say 300Gbps of > > >>>> traffic. It's pretty clearly going to have to be DWDM > > >>>> on dark fiber at that traffic volume; most recent > > >>>> quotes I've seen for dark fiber put it at $325/mile > > >>>> for already-laid-in-ground (new builds are considerably > > >>>> more, of course). If we figure the three datacenters > > >>>> are split around just the US, on average you're going > > >>>> to need to run about 1500 miles to reach their central > > >>>> listening post; that's $49K/month just to carry the > > >>>> bitstream, which leaves you just about $25K/month > > >>>> to run the servers to digest that data; at 5c/kwhr, a > > >>>> typical server pulling 300 watts is gonna cost you $11/month > > >>>> to run; let's assume each server can process 2Gbps of > > >>>> traffic, constantly; 150 servers for the stream of 300Gbps > > >>>> means we're down to $22K for the rest of our support > > >>>> costs; figure two sysadmins getting paid $10k/month > > >>>> to run the servers (120k annual salary), and you've got > > >>>> just $2k for G&A overhead. > > >>>> > > >>>> That's a heck of an efficient operation they'd have to be > > >>>> running to listen in on all the traffic for the supposed > > >>>> budget number claimed. > > >>>> > > >>>> I'm late for work; I'll follow up with a runthrough of the > > >>>> other model, doing on-site digestion and processing > > >>>> later, but I think you can see the point--it's not realistic > > >>>> to think they can handle the volumes of data being > > >>>> claimed at the price numbers listed. If they could, > > >>>> the major providers would already be doing it for > > >>>> much cheaper than they are today. I mean, the > > >>>> Utah datacenter they're building is costing them > > >>>> $2B to build; does anyone really think if they're > > >>>> overpaying that much for datacenter space, they > > >>>> could really snoop on provider traffic for only > > >>>> $238K/month? > > >>>> > > >>>> More later--and remember, this is purely my own > > >>>> rampant speculation, I'm not speaking for anyone, > > >>>> on behalf of anyone, or even remotely authorized > > >>>> or acknowledged by any entity on this rambling, > > >>>> so please don't go quoting this anywhere else, > > >>>> it'll make you look foolish, and probably get me > > >>>> in trouble anyhow. :( > > >>>> > > >>>> Matt > > >>> > > >>> > > >> > > >> > > >> > > >> -- > > >> "Fergie", a.k.a. Paul Ferguson > > >> fergdawgster(at)gmail.com > > >> > > > > > > > > > > > > > > From symack at gmail.com Sat Jun 8 01:22:12 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 7 Jun 2013 21:22:12 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <337d509g596l6qg7obc158mr.1370624005739@email.android.com> <51B2635E.6080002@free.fr> Message-ID: Server maintenance at 000000 on my end..... From owen at delong.com Sat Jun 8 01:20:28 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 7 Jun 2013 18:20:28 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607154207.GF8319@dan.olp.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> Message-ID: Dan, While the government has no responsibility to protect my data, they do have a responsibility to respect my privacy. While you are correct in that proper personal security procedures to protect my data from random crackers would, in fact, also protect it from the government, that's a far cry from what is at issue here. The question here is whether or not it should be considered legitimate for the US Government to completely ignore the fourth and fifth amendments to the constitution and build out unprecedented surveillance capabilities capturing vast amounts of data without direct probable cause for that snooping. I'm not so much concerned about them gaining access to data I don't want them to access. I am far more disturbed by the trend which reflects a government which increasingly considers itself unrestrained by the laws it is in place to support and implement. Owen On Jun 7, 2013, at 8:42 AM, Dan White wrote: > On 06/07/13 11:11 -0400, Rob McEwen wrote: >> On 6/7/2013 9:50 AM, Dan White wrote: >>> OpenPGP and other end-to-end protocols protect against all nefarious >>> actors, including state entities. I'll admit my first reaction yesterday >>> after hearing this news was - so what? Network security by its nature >>> presumes that an insecure channel is going to be attacked and >>> compromised. The 4th Amendment is a layer-8 solution to a problem that >>> is better solved lower in the stack. >> >> That is JUST like saying... >> >> || now that the police can freely bust your door down and raid your >> house in a "fishing expedition", without a search warrant, without court >> order, and without "probable cause"... the solution is for you to get a >> stronger metal door and hide all your stuff better.|| > > Hiding stuff better is generally good security practice, particularly in > the absence of a search warrant. How effective those practices are is > really what's important. > > From a data standpoint, those security procedures can be highly > effective, even against law enforcement. But it's not law enforcement that > I worry about the most (understandably, you may have a differing opinion); > It's the random anonymous cracker who isn't beholden to any international > laws or courts. I design my personal security procedures for him. > > That's why I don't, say, send passwords in emails. I don't trust state > entities to protect the transmission of that data. I don't wish to place > that burden on them. > >> You're basically saying that it is OK for governments to defy their >> constitutions and trample over EVERYONE's rights, and that is OK since a >> TINY PERCENTAGE of experts will have exotic means to evade such >> trampling. But to hell with everyone else. They'll just have to become >> good little subjects to the State. If grandma can't do PGP, then she >> deserves it, right? > > I believe it's your responsibility to protect your own data, not the > government's, and certainly not Facebook's. > >> Yet... many people DIED to initiate/preserve/codify such human rights... >> but I guess others just give them away freely. What a shame. Ironically, >> many who think this is no big deal have themselves benefited immensely >> from centuries of freedom and prosperity that resulted from "rule of >> law" and the U.S. Constitution/Bill of Rights. > > Freedom is very important to me, as well as the laws that are in place to > protect them. > > -- > Dan White From sakamura at gmail.com Sat Jun 8 01:30:20 2013 From: sakamura at gmail.com (Ishmael Rufus) Date: Fri, 7 Jun 2013 20:30:20 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> Message-ID: Yeah... so when are we rioting? Because they'll just continue to make laws that circumvent the constitution. On Fri, Jun 7, 2013 at 8:20 PM, Owen DeLong wrote: > Dan, > > While the government has no responsibility to protect my data, they do > have a responsibility to respect my privacy. While you are correct in that > proper personal security procedures to protect my data from random crackers > would, in fact, also protect it from the government, that's a far cry from > what is at issue here. > > The question here is whether or not it should be considered legitimate for > the US Government to completely ignore the fourth and fifth amendments to > the constitution and build out unprecedented surveillance capabilities > capturing vast amounts of data without direct probable cause for that > snooping. > > I'm not so much concerned about them gaining access to data I don't want > them to access. I am far more disturbed by the trend which reflects a > government which increasingly considers itself unrestrained by the laws it > is in place to support and implement. > > Owen > > On Jun 7, 2013, at 8:42 AM, Dan White wrote: > > > On 06/07/13 11:11 -0400, Rob McEwen wrote: > >> On 6/7/2013 9:50 AM, Dan White wrote: > >>> OpenPGP and other end-to-end protocols protect against all nefarious > >>> actors, including state entities. I'll admit my first reaction > yesterday > >>> after hearing this news was - so what? Network security by its nature > >>> presumes that an insecure channel is going to be attacked and > >>> compromised. The 4th Amendment is a layer-8 solution to a problem that > >>> is better solved lower in the stack. > >> > >> That is JUST like saying... > >> > >> || now that the police can freely bust your door down and raid your > >> house in a "fishing expedition", without a search warrant, without court > >> order, and without "probable cause"... the solution is for you to get a > >> stronger metal door and hide all your stuff better.|| > > > > Hiding stuff better is generally good security practice, particularly in > > the absence of a search warrant. How effective those practices are is > > really what's important. > > > > From a data standpoint, those security procedures can be highly > > effective, even against law enforcement. But it's not law enforcement > that > > I worry about the most (understandably, you may have a differing > opinion); > > It's the random anonymous cracker who isn't beholden to any international > > laws or courts. I design my personal security procedures for him. > > > > That's why I don't, say, send passwords in emails. I don't trust state > > entities to protect the transmission of that data. I don't wish to place > > that burden on them. > > > >> You're basically saying that it is OK for governments to defy their > >> constitutions and trample over EVERYONE's rights, and that is OK since a > >> TINY PERCENTAGE of experts will have exotic means to evade such > >> trampling. But to hell with everyone else. They'll just have to become > >> good little subjects to the State. If grandma can't do PGP, then she > >> deserves it, right? > > > > I believe it's your responsibility to protect your own data, not the > > government's, and certainly not Facebook's. > > > >> Yet... many people DIED to initiate/preserve/codify such human rights... > >> but I guess others just give them away freely. What a shame. Ironically, > >> many who think this is no big deal have themselves benefited immensely > >> from centuries of freedom and prosperity that resulted from "rule of > >> law" and the U.S. Constitution/Bill of Rights. > > > > Freedom is very important to me, as well as the laws that are in place to > > protect them. > > > > -- > > Dan White > > > From wbailey at satelliteintelligencegroup.com Sat Jun 8 02:52:56 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 8 Jun 2013 02:52:56 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> , Message-ID: I think we know now, that they will know we are organizing. Sent from my Mobile Device. -------- Original message -------- From: Ishmael Rufus Date: 06/07/2013 6:32 PM (GMT-08:00) To: Owen DeLong Cc: NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project Yeah... so when are we rioting? Because they'll just continue to make laws that circumvent the constitution. On Fri, Jun 7, 2013 at 8:20 PM, Owen DeLong wrote: > Dan, > > While the government has no responsibility to protect my data, they do > have a responsibility to respect my privacy. While you are correct in that > proper personal security procedures to protect my data from random crackers > would, in fact, also protect it from the government, that's a far cry from > what is at issue here. > > The question here is whether or not it should be considered legitimate for > the US Government to completely ignore the fourth and fifth amendments to > the constitution and build out unprecedented surveillance capabilities > capturing vast amounts of data without direct probable cause for that > snooping. > > I'm not so much concerned about them gaining access to data I don't want > them to access. I am far more disturbed by the trend which reflects a > government which increasingly considers itself unrestrained by the laws it > is in place to support and implement. > > Owen > > On Jun 7, 2013, at 8:42 AM, Dan White wrote: > > > On 06/07/13 11:11 -0400, Rob McEwen wrote: > >> On 6/7/2013 9:50 AM, Dan White wrote: > >>> OpenPGP and other end-to-end protocols protect against all nefarious > >>> actors, including state entities. I'll admit my first reaction > yesterday > >>> after hearing this news was - so what? Network security by its nature > >>> presumes that an insecure channel is going to be attacked and > >>> compromised. The 4th Amendment is a layer-8 solution to a problem that > >>> is better solved lower in the stack. > >> > >> That is JUST like saying... > >> > >> || now that the police can freely bust your door down and raid your > >> house in a "fishing expedition", without a search warrant, without court > >> order, and without "probable cause"... the solution is for you to get a > >> stronger metal door and hide all your stuff better.|| > > > > Hiding stuff better is generally good security practice, particularly in > > the absence of a search warrant. How effective those practices are is > > really what's important. > > > > From a data standpoint, those security procedures can be highly > > effective, even against law enforcement. But it's not law enforcement > that > > I worry about the most (understandably, you may have a differing > opinion); > > It's the random anonymous cracker who isn't beholden to any international > > laws or courts. I design my personal security procedures for him. > > > > That's why I don't, say, send passwords in emails. I don't trust state > > entities to protect the transmission of that data. I don't wish to place > > that burden on them. > > > >> You're basically saying that it is OK for governments to defy their > >> constitutions and trample over EVERYONE's rights, and that is OK since a > >> TINY PERCENTAGE of experts will have exotic means to evade such > >> trampling. But to hell with everyone else. They'll just have to become > >> good little subjects to the State. If grandma can't do PGP, then she > >> deserves it, right? > > > > I believe it's your responsibility to protect your own data, not the > > government's, and certainly not Facebook's. > > > >> Yet... many people DIED to initiate/preserve/codify such human rights... > >> but I guess others just give them away freely. What a shame. Ironically, > >> many who think this is no big deal have themselves benefited immensely > >> from centuries of freedom and prosperity that resulted from "rule of > >> law" and the U.S. Constitution/Bill of Rights. > > > > Freedom is very important to me, as well as the laws that are in place to > > protect them. > > > > -- > > Dan White > > > From tvhawaii at shaka.com Sat Jun 8 03:03:43 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 7 Jun 2013 17:03:43 -1000 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) References: <20371516.7332.1370620430594.JavaMail.root@benjamin.baylink.com> Message-ID: <338498886C9A496DA6E9F79EE1375F23@owner59e1f1502> Jay Ashworth wrote: > "He's at the 40... the 30... the 20... this is gonna be the Super Bowl, > folks... the 10... [buffering]" > > Cheers, > -- jra lol...tnx Jay! From jra at baylink.com Sat Jun 8 03:11:43 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 7 Jun 2013 23:11:43 -0400 (EDT) Subject: PRISM Update: NYT says WaPo a bit credulous Message-ID: <5351846.7492.1370661103318.JavaMail.root@benjamin.baylink.com> Well, ok, they don't actually *say* that, but it's the underlying idea behind their own piece, which says that the listed companies didn't really give NSA quite such unfettered access: http://www.nytimes.com/2013/06/08/technology/tech-companies-bristling-concede-to-government-surveillance-efforts.html?pagewanted=all&_r=0 Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rdobbins at arbor.net Sat Jun 8 06:23:19 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 8 Jun 2013 06:23:19 +0000 Subject: PRISM Update: NYT says WaPo a bit credulous In-Reply-To: <5351846.7492.1370661103318.JavaMail.root@benjamin.baylink.com> References: <5351846.7492.1370661103318.JavaMail.root@benjamin.baylink.com> Message-ID: <198E1707-8923-4302-B811-95E807DED840@arbor.net> On Jun 8, 2013, at 10:11 AM, Jay Ashworth wrote: > Well, ok, they don't actually *say* that, but it's the underlying idea behind their own piece, which says that the listed companies didn't really give NSA quite such unfettered access There's another potential explanation: from ----- 'Tech companies might have also denied knowledge of the full scope of cooperation with national security officials because employees whose job it is to comply with FISA requests are not allowed to discuss the details even with others at the company, and in some cases have national security clearance, according to both a former senior government official and a lawyer representing a technology company.' ----- ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From joly at punkcast.com Sat Jun 8 09:47:58 2013 From: joly at punkcast.com (Joly MacFie) Date: Sat, 8 Jun 2013 05:47:58 -0400 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: <20371516.7332.1370620430594.JavaMail.root@benjamin.baylink.com> References: <55B908F4EEBF47F7813EEFE2E2483EC1@owner59e1f1502> <20371516.7332.1370620430594.JavaMail.root@benjamin.baylink.com> Message-ID: I was at an incentive auction discussion earlier in the week where it was suggested that the broadcasters see a rosy future with ATSC beaming to mobile, but there is still work to be done. http://en.wikipedia.org/wiki/ATSC-M/H On Fri, Jun 7, 2013 at 11:53 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Michael Painter" > >> Anyone besides jra remember the last Super Bowl? >> Better this year? Worse? >> I'm sure whomever is listening in would like to know as well. >> >> http://www.multichannel.com/blogs/translation-please/multicast-unicast-and-super-bowl-problem > > Well, in fact, the most recent Massive Failure was the webcast of the > Concert For Boston, on 5/31. They were using a vendor called LiveAlliance.tv, > who did not appear to be farming it out to Limelight or Akamai or Youtube, as > far as I could tell, and they apparently only figured for a scale 5 audience, > and then got more than 500k attempts. > > They got rescued by a vendor named Fast Hockey who are an amateur hockey > webcast aggregator, I gather, and *are* an Akamai client. > > My estimation is that the reason that webcasting will never completely > replace broadcasting is that -- because it is mostly unicast -- its > inherent complexity factor is a) orders of magnitude higher than bcast, and > b) *proportional to the number of viewers*. Like Linux, that doesn't scale. > > And broadcasters are not prone to think of the world in a view where you > have to provide technical support to people just to watch your show. > > "He's at the 40... the 30... the 20... this is gonna be the Super Bowl, > folks... the 10... [buffering]" > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From rsk at gsp.org Sat Jun 8 09:57:27 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 8 Jun 2013 05:57:27 -0400 Subject: PRISM Update: NYT says WaPo a bit credulous In-Reply-To: <198E1707-8923-4302-B811-95E807DED840@arbor.net> References: <5351846.7492.1370661103318.JavaMail.root@benjamin.baylink.com> <198E1707-8923-4302-B811-95E807DED840@arbor.net> Message-ID: <20130608095727.GA8824@gsp.org> On Sat, Jun 08, 2013 at 06:23:19AM +0000, Dobbins, Roland wrote: > There's another potential explanation: [snip] *puts on evil hat, adjusts for snug fit* Targeting the technical people who actually have their hands on the gear might be the best choice. They don't have the power, wealth and soapbox of the Cxx-level people. They are thus far more easily intimidated into silence. Unlike the Cxx people, they actually spend time in data centers. And by keeping the Cxx people in the dark, their public denials will carry more credibility because they will actually believe they're telling the truth. (When's the last time any of them got their hands dirty crawling pulling out raised floor tiles and running cable?) ---rsk From brandon at rd.bbc.co.uk Sat Jun 8 10:08:07 2013 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 8 Jun 2013 11:08:07 +0100 (BST) Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) Message-ID: <201306081008.LAA03811@sunf10.rd.bbc.co.uk> > I was at an incentive auction discussion earlier in the week where it > was suggested that the broadcasters see a rosy future with ATSC > beaming to mobile, but there is still work to be done. They might wish, after many years there has been little take up of the various systems created to do this (we've spent quite some time working on the standards). Nobody wanted to pay for it to be in handsets, other features were seen as more important uses of the space/power. The next try is LTE Broadcast http://en.wikipedia.org/wiki/EMBMS brandon From mysidia at gmail.com Sat Jun 8 11:12:39 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 8 Jun 2013 06:12:39 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607065131.GB21448@besserwisser.org> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607065131.GB21448@besserwisser.org> Message-ID: On 6/7/13, M?ns Nilsson wrote: > Subject: Re: PRISM: NSA/FBI Internet data mining project Date: Fri, Jun 07, > 2013 at 12:25:35AM -0500 Quoting jamie rishaw (j at arpa.com): >> >> Just wait until we find out dark and lit private fiber is getting >> vampired. >> > I'm not even assuming it, I'm convinced. In Sweden, we have a law, > that makes what NSA/FBI did illegal while at the same time legalising, Perhaps strong crypto should be implemented on transceivers at each end of every link, so users could be protected from that without having to implement the crypto themselves at the application layer? :) -- -JH From mpetach at netflight.com Sat Jun 8 12:05:29 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 8 Jun 2013 05:05:29 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607065131.GB21448@besserwisser.org> Message-ID: On Sat, Jun 8, 2013 at 4:12 AM, Jimmy Hess wrote: > On 6/7/13, M?ns Nilsson wrote: > > Subject: Re: PRISM: NSA/FBI Internet data mining project Date: Fri, Jun > 07, > > 2013 at 12:25:35AM -0500 Quoting jamie rishaw (j at arpa.com): > >> > >> Just wait until we find out dark and lit private fiber is getting > >> vampired. > >> > > I'm not even assuming it, I'm convinced. In Sweden, we have a law, > > that makes what NSA/FBI did illegal while at the same time legalising, > > Perhaps strong crypto should be implemented on transceivers at each > end of every link, so users could be protected from that without > having to implement the crypto themselves at the application layer? :) > Would you really trust "crypto" applied by someone else on your behalf? "sure, your data's safe--I triple rot-13'd it myself!" ;P Matt From mike at mikejones.in Sat Jun 8 12:06:14 2013 From: mike at mikejones.in (Mike Jones) Date: Sat, 8 Jun 2013 13:06:14 +0100 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607065131.GB21448@besserwisser.org> Message-ID: On 8 June 2013 12:12, Jimmy Hess wrote: > On 6/7/13, M?ns Nilsson wrote: > > Subject: Re: PRISM: NSA/FBI Internet data mining project Date: Fri, Jun > 07, > > 2013 at 12:25:35AM -0500 Quoting jamie rishaw (j at arpa.com): > >> > >> Just wait until we find out dark and lit private fiber is getting > >> vampired. > >> > > I'm not even assuming it, I'm convinced. In Sweden, we have a law, > > that makes what NSA/FBI did illegal while at the same time legalising, > > Perhaps strong crypto should be implemented on transceivers at each > end of every link, so users could be protected from that without > having to implement the crypto themselves at the application layer? :) > > -- > -JH > > Encrypted wifi doesn't help if the access point is the one doing the sniffing. How often are 'wiretaps' done by tapping in to a physical line vs simply requesting a switch/router copy everything going through it to another port? the CIA might use physical taps to monitor the russian governments traffic, but within the US I imagine they normally just ask the targets ISP to copy the data to them. To be automatic and 'just work' would also mean not having to configure the identity of the devices at the other end of every link. In this case you'll just negotiate an encrypted link to the CIAs sniffer instead of the switch you thought you were talking to. End to end encryption with secure automatic authentication is needed, it's taking a while to gain traction but DANE looks like the solution. When SSL requires the overhead of getting a CA to re-sign everything every year you only use it when you have a reason to. When SSL is a single copy/paste operation to set it up and no maintenance it becomes much harder to justify why you're not doing it. Unfortunately I haven't come across any good ideas yet for p2p type applications were you don't have anywhere to securely publish your certificates. - Mike From wbailey at satelliteintelligencegroup.com Sat Jun 8 15:27:15 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 8 Jun 2013 15:27:15 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607065131.GB21448@besserwisser.org>, Message-ID: They use those very regularly.. There is a widely used model called the KV. Sent from my Mobile Device. -------- Original message -------- From: Jimmy Hess Date: 06/08/2013 4:14 AM (GMT-08:00) To: M?ns Nilsson Cc: goemon at anime.net,NANOG Subject: Re: PRISM: NSA/FBI Internet data mining project On 6/7/13, M?ns Nilsson wrote: > Subject: Re: PRISM: NSA/FBI Internet data mining project Date: Fri, Jun 07, > 2013 at 12:25:35AM -0500 Quoting jamie rishaw (j at arpa.com): >> >> Just wait until we find out dark and lit private fiber is getting >> vampired. >> > I'm not even assuming it, I'm convinced. In Sweden, we have a law, > that makes what NSA/FBI did illegal while at the same time legalising, Perhaps strong crypto should be implemented on transceivers at each end of every link, so users could be protected from that without having to implement the crypto themselves at the application layer? :) -- -JH From bill at herrin.us Sat Jun 8 15:31:55 2013 From: bill at herrin.us (William Herrin) Date: Sat, 8 Jun 2013 11:31:55 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: > Just wait until we find out dark and lit private fiber is getting vampired. Why wait? http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sat Jun 8 15:45:11 2013 From: bill at herrin.us (William Herrin) Date: Sat, 8 Jun 2013 11:45:11 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <13976.1370628323@turing-police.cc.vt.edu> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <1A62CA26-1214-43CA-8E5B-344AC8BEAA25@seiden.com> <13976.1370628323@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 7, 2013 at 2:05 PM, wrote: > On Thu, 06 Jun 2013 22:57:07 -0700, Mark Seiden said: >> and also, only $20m/year? in my experience, the govt cannot do anything like this >> addressing even a single provider for that little money. > > Convince me the *real* number doesn't have another zero. If they're just crunching CDRs as claimed in the news reports, all it takes is a stack of Netezzas (they were originally designed to crunch detail data for utility billing), an automated etl task for the daily telco dumps, a web interface for the agents to submit analysis jobs that's an abstraction of the sql layer and a couple specialists to write queries for more complex analysis requests. I do more complicated work for the government for less money; $20m/year is easily believable. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Bryan at bryanfields.net Sat Jun 8 15:55:05 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Sat, 08 Jun 2013 11:55:05 -0400 Subject: Facebook broken over v6? In-Reply-To: References: <20130607161226.GJ46569@trace.bind.com> <51B2089E.9010108@massar.ch> Message-ID: <51B353D9.506@bryanfields.net> On 6/7/13 12:21 PM, Jeroen Massar wrote: > On 2013-06-07 09:12, Aaron Hughes wrote: >> >> Anyone else getting connection hangs and closes to Facebook? > > Yes, and from a lot of vantage points, thus it is not your local network > that is at fault, seems that there are some IP addresses which are being > returned by some Facebook DNS servers that are actually not properly > provisioned and thus do not respond. > > More to it at: > http://www.sixxs.net/forum/?msg=general-9511818 > > I've informed the Facebook peoples (and bcc'd them on this email), and > apparently they are digging into it from the response I've received. > > Note that using www.v6.facebook.com apparently works fine as that IP is > not affected and is not geo-balanced or something like that thus is > always (afaik) the same. Thus if you like sharing your life and > everything you do, that is the thing to use. It's affecting anyone running dual stack, as the server responds, hangs, times out and then it tries again on v6. At least in the latest FF and Safari browsers, I've not tried chrome. I've cc'd this over to Nanog, as I've not seen anything about it there, and I'm sure others are seeing it. www.v6.facebook.com works fine as a workaround for the time being. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From symack at gmail.com Sat Jun 8 15:58:51 2013 From: symack at gmail.com (Nick Khamis) Date: Sat, 8 Jun 2013 11:58:51 -0400 Subject: OC3/STM-1 Line Card Message-ID: Hello Everyone, Anyone know of a way of bypassing the 90K audiocodes mediant 3000 equipped for STM-1 interface using line cards and a linux box :). What we are looking to do is replace our traditional ISDN DS3 equipped for voice using an STM-1/OC3 backbone and our own put together linux box. Again, this will be used for voice signaling... Kind Regards, Nick. From web at typo.org Sat Jun 8 16:08:29 2013 From: web at typo.org (Wayne E Bouchard) Date: Sat, 8 Jun 2013 09:08:29 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> Message-ID: <20130608160829.GA85215@wakko.typo.org> You can keep a hacker out, true, but you cannot keep the government out. When the force of law can be used to compell you to act against your wishes or your own best interests, all bets are of. Hackers sneak in through the back door. The govt just breaks the front door down and demands entry and that is what appears to have happened here. Remember that part of the issue is the fact that, thanks to the Patriot Act and FISA, not only can you be given a warrant that does not proceed through normal channels, you are forbidden from even acknowledging its very existence or risk prison. That's ideal conspiracy fodder. Add to that the ignorance of the common man combined with the fact that no one here should have any doubt that the NSA is capable of things you and I haven't even imagined yet, and what are you likely to end up with when a snooping story breaks? Nothing short of the NSA being remained to the "National Surveilance Administration". My gripe is that they should not have this sort of power to begin with. Power will be abused, pure and simple. The only way to prevent the abuse of power by government entities is to deny them that power in the first place. So I don't buy the whole thing because as an engineer, I know it's a lot more difficult than people think but, as an engineer, I also know the value of the right technology in just the right place. Do I believe they're snooping my waves and watching my keyboard? No, but with access to the right point (email servers and proxies near the eyeballs) they really don't have to. Besides, if they *DID* want to monitor someone that closely, we all know how easy it is for a somewhat more skilled hacker to get access to a desktop. So I'm up for about half of what is out there with just a touch of skepticism. Even without the whole kit and kaboodle, the information they have access to already is pretty frightening. With it, you can reverse engineer and acquire much more information through indirect means when the right search parameters are used and the right correlations made. Ever made a campaign contribution or a donation to a group like the NRA or CATO? Membership information is not private when they can just go back and look for the credit/debit transaction and compile the list that way. How often do you phone your congresscritter? Easy to identify the politically active by seeing who is placing/receiving calls from a given group. This whole system is just ripe for abuse. The statement the president made on this issue, as I heard it, really boils down to 5 words: "We're the government. Trust us." *shudder* -Wayne On Fri, Jun 07, 2013 at 06:20:28PM -0700, Owen DeLong wrote: > Dan, > > While the government has no responsibility to protect my data, they do have a responsibility to respect my privacy. While you are correct in that proper personal security procedures to protect my data from random crackers would, in fact, also protect it from the government, that's a far cry from what is at issue here. > > The question here is whether or not it should be considered legitimate for the US Government to completely ignore the fourth and fifth amendments to the constitution and build out unprecedented surveillance capabilities capturing vast amounts of data without direct probable cause for that snooping. > > I'm not so much concerned about them gaining access to data I don't want them to access. I am far more disturbed by the trend which reflects a government which increasingly considers itself unrestrained by the laws it is in place to support and implement. > > Owen > > On Jun 7, 2013, at 8:42 AM, Dan White wrote: > > > On 06/07/13 11:11 -0400, Rob McEwen wrote: > >> On 6/7/2013 9:50 AM, Dan White wrote: > >>> OpenPGP and other end-to-end protocols protect against all nefarious > >>> actors, including state entities. I'll admit my first reaction yesterday > >>> after hearing this news was - so what? Network security by its nature > >>> presumes that an insecure channel is going to be attacked and > >>> compromised. The 4th Amendment is a layer-8 solution to a problem that > >>> is better solved lower in the stack. > >> > >> That is JUST like saying... > >> > >> || now that the police can freely bust your door down and raid your > >> house in a "fishing expedition", without a search warrant, without court > >> order, and without "probable cause"... the solution is for you to get a > >> stronger metal door and hide all your stuff better.|| > > > > Hiding stuff better is generally good security practice, particularly in > > the absence of a search warrant. How effective those practices are is > > really what's important. > > > > From a data standpoint, those security procedures can be highly > > effective, even against law enforcement. But it's not law enforcement that > > I worry about the most (understandably, you may have a differing opinion); > > It's the random anonymous cracker who isn't beholden to any international > > laws or courts. I design my personal security procedures for him. > > > > That's why I don't, say, send passwords in emails. I don't trust state > > entities to protect the transmission of that data. I don't wish to place > > that burden on them. > > > >> You're basically saying that it is OK for governments to defy their > >> constitutions and trample over EVERYONE's rights, and that is OK since a > >> TINY PERCENTAGE of experts will have exotic means to evade such > >> trampling. But to hell with everyone else. They'll just have to become > >> good little subjects to the State. If grandma can't do PGP, then she > >> deserves it, right? > > > > I believe it's your responsibility to protect your own data, not the > > government's, and certainly not Facebook's. > > > >> Yet... many people DIED to initiate/preserve/codify such human rights... > >> but I guess others just give them away freely. What a shame. Ironically, > >> many who think this is no big deal have themselves benefited immensely > >> from centuries of freedom and prosperity that resulted from "rule of > >> law" and the U.S. Constitution/Bill of Rights. > > > > Freedom is very important to me, as well as the laws that are in place to > > protect them. > > > > -- > > Dan White > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From cb.list6 at gmail.com Sat Jun 8 16:51:09 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sat, 8 Jun 2013 09:51:09 -0700 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: <201306081008.LAA03811@sunf10.rd.bbc.co.uk> References: <201306081008.LAA03811@sunf10.rd.bbc.co.uk> Message-ID: On Sat, Jun 8, 2013 at 3:08 AM, Brandon Butterworth wrote: >> I was at an incentive auction discussion earlier in the week where it >> was suggested that the broadcasters see a rosy future with ATSC >> beaming to mobile, but there is still work to be done. > > They might wish, after many years there has been little take up of the > various systems created to do this (we've spent quite some time working > on the standards). Nobody wanted to pay for it to be in handsets, other > features were seen as more important uses of the space/power. > > The next try is LTE Broadcast > http://en.wikipedia.org/wiki/EMBMS > Without going into painful detail on the policy, technology or economics, i really don't see EMBMS being widely deployed and successful Not to say some folks won't try to make pigs fly. Vendors make a lot of money at the "pigs flying" BU. I do imagine the invisible hand of tariffs guiding users to better use broadcast TV and Radio for live events. CB > brandon > From wbailey at satelliteintelligencegroup.com Sat Jun 8 17:25:24 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 8 Jun 2013 17:25:24 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130608160829.GA85215@wakko.typo.org> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> , <20130608160829.GA85215@wakko.typo.org> Message-ID: I was just thinking.. Why go after all of these network based information type? Why not just approach dell about some secret iDRAC system for Agent X? Sent from my Mobile Device. -------- Original message -------- From: Wayne E Bouchard Date: 06/08/2013 9:10 AM (GMT-08:00) To: Owen DeLong Cc: nanog at nanog.org Subject: Re: PRISM: NSA/FBI Internet data mining project You can keep a hacker out, true, but you cannot keep the government out. When the force of law can be used to compell you to act against your wishes or your own best interests, all bets are of. Hackers sneak in through the back door. The govt just breaks the front door down and demands entry and that is what appears to have happened here. Remember that part of the issue is the fact that, thanks to the Patriot Act and FISA, not only can you be given a warrant that does not proceed through normal channels, you are forbidden from even acknowledging its very existence or risk prison. That's ideal conspiracy fodder. Add to that the ignorance of the common man combined with the fact that no one here should have any doubt that the NSA is capable of things you and I haven't even imagined yet, and what are you likely to end up with when a snooping story breaks? Nothing short of the NSA being remained to the "National Surveilance Administration". My gripe is that they should not have this sort of power to begin with. Power will be abused, pure and simple. The only way to prevent the abuse of power by government entities is to deny them that power in the first place. So I don't buy the whole thing because as an engineer, I know it's a lot more difficult than people think but, as an engineer, I also know the value of the right technology in just the right place. Do I believe they're snooping my waves and watching my keyboard? No, but with access to the right point (email servers and proxies near the eyeballs) they really don't have to. Besides, if they *DID* want to monitor someone that closely, we all know how easy it is for a somewhat more skilled hacker to get access to a desktop. So I'm up for about half of what is out there with just a touch of skepticism. Even without the whole kit and kaboodle, the information they have access to already is pretty frightening. With it, you can reverse engineer and acquire much more information through indirect means when the right search parameters are used and the right correlations made. Ever made a campaign contribution or a donation to a group like the NRA or CATO? Membership information is not private when they can just go back and look for the credit/debit transaction and compile the list that way. How often do you phone your congresscritter? Easy to identify the politically active by seeing who is placing/receiving calls from a given group. This whole system is just ripe for abuse. The statement the president made on this issue, as I heard it, really boils down to 5 words: "We're the government. Trust us." *shudder* -Wayne On Fri, Jun 07, 2013 at 06:20:28PM -0700, Owen DeLong wrote: > Dan, > > While the government has no responsibility to protect my data, they do have a responsibility to respect my privacy. While you are correct in that proper personal security procedures to protect my data from random crackers would, in fact, also protect it from the government, that's a far cry from what is at issue here. > > The question here is whether or not it should be considered legitimate for the US Government to completely ignore the fourth and fifth amendments to the constitution and build out unprecedented surveillance capabilities capturing vast amounts of data without direct probable cause for that snooping. > > I'm not so much concerned about them gaining access to data I don't want them to access. I am far more disturbed by the trend which reflects a government which increasingly considers itself unrestrained by the laws it is in place to support and implement. > > Owen > > On Jun 7, 2013, at 8:42 AM, Dan White wrote: > > > On 06/07/13 11:11 -0400, Rob McEwen wrote: > >> On 6/7/2013 9:50 AM, Dan White wrote: > >>> OpenPGP and other end-to-end protocols protect against all nefarious > >>> actors, including state entities. I'll admit my first reaction yesterday > >>> after hearing this news was - so what? Network security by its nature > >>> presumes that an insecure channel is going to be attacked and > >>> compromised. The 4th Amendment is a layer-8 solution to a problem that > >>> is better solved lower in the stack. > >> > >> That is JUST like saying... > >> > >> || now that the police can freely bust your door down and raid your > >> house in a "fishing expedition", without a search warrant, without court > >> order, and without "probable cause"... the solution is for you to get a > >> stronger metal door and hide all your stuff better.|| > > > > Hiding stuff better is generally good security practice, particularly in > > the absence of a search warrant. How effective those practices are is > > really what's important. > > > > From a data standpoint, those security procedures can be highly > > effective, even against law enforcement. But it's not law enforcement that > > I worry about the most (understandably, you may have a differing opinion); > > It's the random anonymous cracker who isn't beholden to any international > > laws or courts. I design my personal security procedures for him. > > > > That's why I don't, say, send passwords in emails. I don't trust state > > entities to protect the transmission of that data. I don't wish to place > > that burden on them. > > > >> You're basically saying that it is OK for governments to defy their > >> constitutions and trample over EVERYONE's rights, and that is OK since a > >> TINY PERCENTAGE of experts will have exotic means to evade such > >> trampling. But to hell with everyone else. They'll just have to become > >> good little subjects to the State. If grandma can't do PGP, then she > >> deserves it, right? > > > > I believe it's your responsibility to protect your own data, not the > > government's, and certainly not Facebook's. > > > >> Yet... many people DIED to initiate/preserve/codify such human rights... > >> but I guess others just give them away freely. What a shame. Ironically, > >> many who think this is no big deal have themselves benefited immensely > >> from centuries of freedom and prosperity that resulted from "rule of > >> law" and the U.S. Constitution/Bill of Rights. > > > > Freedom is very important to me, as well as the laws that are in place to > > protect them. > > > > -- > > Dan White > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From kmedcalf at dessus.com Sat Jun 8 17:28:28 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 08 Jun 2013 11:28:28 -0600 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Message-ID: <4d0362f3e7ce1c4fa13c9dce4d6e729b@mail.dessus.com> > "Yahoo does not provide the government with > direct access to its servers, systems, or network." Ah, so you admit that you provide "indirect" access by interposing a firewall and router between your datacenter network and the transport link to the NSA. That is just normal sound security practice when permitting third-party network connections. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Matthew Petach [mailto:mpetach at netflight.com] > Sent: Friday, 07 June, 2013 10:33 > Cc: NANOG > Subject: Re: PRISM: NSA/FBI Internet data mining project > > On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach > wrote: > > > > > > > On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth wrote: > > > >> Has fingers directly in servers of top Internet content companies, > >> dates to 2007. Happily, none of the companies listed are transport > >> networks: > >> > >> > >> http://www.washingtonpost.com/investigations/us-intelligence-mining- > data-from-nine-us-internet-companies-in-broad-secret- > program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html > >> > >> Cheers, > >> -- jra > >> -- > >> Jay R. Ashworth Baylink > >> jra at baylink.com > >> Designer The Things I Think > RFC > >> 2100 > >> Ashworth & Associates http://baylink.pitas.com 2000 Land > >> Rover DII > >> St Petersburg FL USA #natog +1 727 > >> 647 1274 > >> > >> > > > > I've always just assumed that if it's in electronic form, > > someone else is either reading it now, has already read > > it, or will read it as soon as I walk away from the screen. > > > > Much less stress in life that way. ^_^ > > > > Matt > > > > > > When I posted this yesterday, I was speaking somewhat > tongue-in-cheek, because we hadn't yet made a formal > statement to the press. Now that we've made our official > reply, I can echo it, and note that whatever fluffed up > powerpoint was passed around to the washington post, > it does not reflect reality. There are no optical taps in > our datacenters funneling information out, there are no > sooper-seekret backdoors in the software that funnel > information to the government. As our formal reply > stated: "Yahoo does not provide the government with > direct access to its servers, systems, or network." > I believe the other major players supposedly listed > in the document have released similar statements, > all indicating a similar lack of super-cheap government > listening capabilities. > > Speaking just for myself, and if you quote me on this > as speaking on anyone else's behalf, you're a complete > fool, if the government was able to build infrastructure > that could listen to all the traffic from a major provider > for a fraction of what it costs them to handle that traffic > in the first place, I'd be truly amazed--and I'd probably > wonder why the company didn't outsource their infrastruture > to the government, if they can build and run it so much > more cheaply than the commercial providers. ;P > 7 companies were listed; if we assume the > burden was split roughly evenly between them, that's > 20M/7, about $2.85M per company per year to tap in, > or about $238,000/month per company listed, to > supposedly snoop on hundreds of gigs per second > of data. Two ways to handle it: tap in, and funnel > copies of all traffic back to distant monitoring posts, > or have local servers digesting and filtering, just > extracting the few nuggets they want, and sending > just those back. > > Let's take the first case; doing optical taps, or other > form of direct traffic mirroring, carrying it untouched > offsite to process; that's going to mean the ability to > siphon off hundreds of Gbps per datacenter and carry > it offsite for $238k/month; let's figure a major player > has data split across at least 3 datacenters, so about > $75K/month per datacenter to carry say 300Gbps of > traffic. It's pretty clearly going to have to be DWDM > on dark fiber at that traffic volume; most recent > quotes I've seen for dark fiber put it at $325/mile > for already-laid-in-ground (new builds are considerably > more, of course). If we figure the three datacenters > are split around just the US, on average you're going > to need to run about 1500 miles to reach their central > listening post; that's $49K/month just to carry the > bitstream, which leaves you just about $25K/month > to run the servers to digest that data; at 5c/kwhr, a > typical server pulling 300 watts is gonna cost you $11/month > to run; let's assume each server can process 2Gbps of > traffic, constantly; 150 servers for the stream of 300Gbps > means we're down to $22K for the rest of our support > costs; figure two sysadmins getting paid $10k/month > to run the servers (120k annual salary), and you've got > just $2k for G&A overhead. > > That's a heck of an efficient operation they'd have to be > running to listen in on all the traffic for the supposed > budget number claimed. > > I'm late for work; I'll follow up with a runthrough of the > other model, doing on-site digestion and processing > later, but I think you can see the point--it's not realistic > to think they can handle the volumes of data being > claimed at the price numbers listed. If they could, > the major providers would already be doing it for > much cheaper than they are today. I mean, the > Utah datacenter they're building is costing them > $2B to build; does anyone really think if they're > overpaying that much for datacenter space, they > could really snoop on provider traffic for only > $238K/month? > > More later--and remember, this is purely my own > rampant speculation, I'm not speaking for anyone, > on behalf of anyone, or even remotely authorized > or acknowledged by any entity on this rambling, > so please don't go quoting this anywhere else, > it'll make you look foolish, and probably get me > in trouble anyhow. :( > > Matt From wbailey at satelliteintelligencegroup.com Sat Jun 8 17:28:59 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 8 Jun 2013 17:28:59 +0000 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: References: <201306081008.LAA03811@sunf10.rd.bbc.co.uk>, Message-ID: Japan has been doing this exact thing for close to 10 years.. Why is it hard to do? Buffer the video 30 seconds or use a codec that doesn't blow? I use my phone via "4G"and stream media constantly. If you take a look at Charlie Ergen's behavior lately, there won't need to be a lte tv.. Lightsquared is about to be murdered for breaking the Gps and dish will take over as largest provider in the US. Now taking bets. Sent from my Mobile Device. -------- Original message -------- From: "cb.list6" Date: 06/08/2013 9:52 AM (GMT-08:00) To: Brandon Butterworth Cc: nanog at nanog.org Subject: Re: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) On Sat, Jun 8, 2013 at 3:08 AM, Brandon Butterworth wrote: >> I was at an incentive auction discussion earlier in the week where it >> was suggested that the broadcasters see a rosy future with ATSC >> beaming to mobile, but there is still work to be done. > > They might wish, after many years there has been little take up of the > various systems created to do this (we've spent quite some time working > on the standards). Nobody wanted to pay for it to be in handsets, other > features were seen as more important uses of the space/power. > > The next try is LTE Broadcast > http://en.wikipedia.org/wiki/EMBMS > Without going into painful detail on the policy, technology or economics, i really don't see EMBMS being widely deployed and successful Not to say some folks won't try to make pigs fly. Vendors make a lot of money at the "pigs flying" BU. I do imagine the invisible hand of tariffs guiding users to better use broadcast TV and Radio for live events. CB > brandon > From cb.list6 at gmail.com Sat Jun 8 17:37:48 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sat, 8 Jun 2013 10:37:48 -0700 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: References: <201306081008.LAA03811@sunf10.rd.bbc.co.uk> Message-ID: On Sat, Jun 8, 2013 at 10:28 AM, Warren Bailey wrote: > Japan has been doing this exact thing for close to 10 years.. Why is it hard Japan has been doing what exactly? Can you cite it? I am pretty sure by "exact thing" you do not mean EMBMS. > to do? Buffer the video 30 seconds or use a codec that doesn't blow? I use > my phone via "4G"and stream media constantly. If you take a look at Charlie Yes, and by "streaming", you mean downloading discrete video chunks with http. That is the state of the industry today video over unicast TCP / HTTP. It is not EMBMS A very large percentage of mobile data traffic today is video via HTTP http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.html I do not know of any EMBMS deployments. CB > Ergen's behavior lately, there won't need to be a lte tv.. Lightsquared is > about to be murdered for breaking the Gps and dish will take over as largest > provider in the US. Now taking bets. > > > Sent from my Mobile Device. > > > > -------- Original message -------- > From: "cb.list6" > Date: 06/08/2013 9:52 AM (GMT-08:00) > To: Brandon Butterworth > Cc: nanog at nanog.org > Subject: Re: Webcasting as a replacement for traditional broadcasting (was > Re: Wackie 'ol Friday) > > > On Sat, Jun 8, 2013 at 3:08 AM, Brandon Butterworth > wrote: >>> I was at an incentive auction discussion earlier in the week where it >>> was suggested that the broadcasters see a rosy future with ATSC >>> beaming to mobile, but there is still work to be done. >> >> They might wish, after many years there has been little take up of the >> various systems created to do this (we've spent quite some time working >> on the standards). Nobody wanted to pay for it to be in handsets, other >> features were seen as more important uses of the space/power. >> >> The next try is LTE Broadcast >> http://en.wikipedia.org/wiki/EMBMS >> > > Without going into painful detail on the policy, technology or > economics, i really don't see EMBMS being widely deployed and > successful > > Not to say some folks won't try to make pigs fly. Vendors make a lot > of money at the "pigs flying" BU. > > I do imagine the invisible hand of tariffs guiding users to better use > broadcast TV and Radio for live events. > > CB > >> brandon >> > From jra at baylink.com Sat Jun 8 17:45:10 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Jun 2013 13:45:10 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Message-ID: <12762833.7508.1370713510651.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Petach" > Would you really trust "crypto" applied by someone else on your > behalf? > > "sure, your data's safe--I triple rot-13'd it myself!" ;P Oh, do we need triple now? I've been double-ROT13'ing my data for *years*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Jun 8 17:47:12 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Jun 2013 13:47:12 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130608160829.GA85215@wakko.typo.org> Message-ID: <21216201.7510.1370713632678.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Wayne E Bouchard" > Remember that part of the issue is the fact that, thanks to the > Patriot Act and FISA, not only can you be given a warrant that does > not proceed through normal channels, you are forbidden from even > acknowledging its very existence or risk prison. So, who is that that posts a Warrant Canary? Is it still up to date? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From dmiller at tiggee.com Sat Jun 8 18:48:12 2013 From: dmiller at tiggee.com (David Miller) Date: Sat, 08 Jun 2013 14:48:12 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <21216201.7510.1370713632678.JavaMail.root@benjamin.baylink.com> References: <21216201.7510.1370713632678.JavaMail.root@benjamin.baylink.com> Message-ID: <51B37C6C.206@tiggee.com> On 06/08/2013 01:47 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Wayne E Bouchard" >> Remember that part of the issue is the fact that, thanks to the >> Patriot Act and FISA, not only can you be given a warrant that does >> not proceed through normal channels, you are forbidden from even >> acknowledging its very existence or risk prison. > So, who is that that posts a Warrant Canary? > > Is it still up to date? > > Cheers, > -- jra rsync.net? Current as of 2013-06-03 http://www.rsync.net/resources/notices/canary.txt -DMM From jra at baylink.com Sat Jun 8 19:25:07 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 8 Jun 2013 15:25:07 -0400 (EDT) Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: Message-ID: <4720053.7516.1370719507281.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "cb.list6" > On Sat, Jun 8, 2013 at 3:08 AM, Brandon Butterworth > wrote: > > The next try is LTE Broadcast > > http://en.wikipedia.org/wiki/EMBMS > > Without going into painful detail on the policy, technology or > economics, i really don't see EMBMS being widely deployed and > successful Isn't it a shame that the fix was in when ATSC was locked as 8VSB, instead of the much easier to receive while mobile COFDM... which would have cost broadcasters more because it's average transmit power is higher? So anything that costs broadcasters more to do to serve mobile users, I'm fine with, as long as they don't try to charge us for it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cconn at b2b2c.ca Sat Jun 8 19:38:00 2013 From: cconn at b2b2c.ca (Chris Conn) Date: Sat, 08 Jun 2013 15:38:00 -0400 Subject: Facebook broken over v6? In-Reply-To: References: Message-ID: <51B38818.2080400@b2b2c.ca> On 2013-06-08 15:29, Chris Conn wrote: > It's affecting anyone running dual stack, as the server responds, > hangs, times out and then it tries again on v6. At least in the latest > FF and Safari browsers, I've not tried chrome. I've cc'd this over to > Nanog, as I've not seen anything about it there, and I'm sure others > are seeing it. www.v6.facebook.com works fine as a workaround for the > time being. -- Indeed, I have seen this behaviour for at least a week. It seems to somehow be related to geo-located DNS (akamai?) since the timeouts and RSTs I see in the traffic are from IPv6 akamai servers, not facebook itself. I tried de-peering from a number of networks to try and isolate it and it was not transit-specific. I stopped questioning my network when I saw a thread on Sixxs and tunnelbroker about this very issue. Hopefully it won't persist as right now as having Facebook intermittently connect is likely hurting deployment slightly. Chris From rj at telia.net Sat Jun 8 20:13:36 2013 From: rj at telia.net (Rikard Johansson) Date: Sat, 8 Jun 2013 22:13:36 +0200 Subject: Facebook broken over v6? In-Reply-To: <51B38818.2080400@b2b2c.ca> References: <51B38818.2080400@b2b2c.ca> Message-ID: M?ste vara n?t med browsern. Fortsatt god helg! Test IPv6 FAQ Mirrors Stats Test your IPv6 connectivity. Summary Tests Run Share Results / Contact Your IPv4 address on the public Internet appears to be 213.65.35.162 (TELIANET-SWEDEN TeliaSonera AB) Your IPv6 address on the public Internet appears to be 2001:2002:d541:23a2:11fe:f37f:1493:bb73 (TELIANET TeliaNet Global Network) It appears that you use a non managed tunnel mechanism for either IPv4 or IPv6. [more info] Good news! Your current configuration will continue to work as web sites enable IPv6. [more info] Your browser is blocking the test urls. We will try alternate methods, but they may fail to show your IP address; and may affect the quality of the advice given. [more info] Your browser blocked http://ipv6.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites. IPv6 connections work, but connections using DNS names do not use IPv6. For some reason, your browser or your OS is not doing IPv6 DNS 'AAAA' lookups. [more info] Your DNS server (possibly run by your ISP) appears to have IPv6 Internet access. Your readiness score 0/10 for your IPv6 stability and readiness, when publishers are forced to go IPv6 only Click to see test data (Updated server side IPv6 readiness stats) Copyright (C) 2010, 2012 Jason Fesler. All rights reserved. -- r1190 Mirrors | Mission | Source | Email - - Attributions This is a mirror of test-ipv6.com. The views expressed here may or may not reflect the views of the mirror owner. Sent from my mobile phone On 8 jun 2013, at 21:38, Chris Conn wrote: > On 2013-06-08 15:29, Chris Conn wrote: >> It's affecting anyone running dual stack, as the server responds, hangs, times out and then it tries again on v6. At least in the latest FF and Safari browsers, I've not tried chrome. I've cc'd this over to Nanog, as I've not seen anything about it there, and I'm sure others are seeing it. www.v6.facebook.com works fine as a workaround for the time being. -- > > Indeed, I have seen this behaviour for at least a week. It seems to somehow be related to geo-located DNS (akamai?) since the timeouts and RSTs I see in the traffic are from IPv6 akamai servers, not facebook itself. > > I tried de-peering from a number of networks to try and isolate it and it was not transit-specific. I stopped questioning my network when I saw a thread on Sixxs and tunnelbroker about this very issue. > > Hopefully it won't persist as right now as having Facebook intermittently connect is likely hurting deployment slightly. > > Chris > > > > From dsp at fb.com Sat Jun 8 20:29:43 2013 From: dsp at fb.com (Doug Porter) Date: Sat, 8 Jun 2013 13:29:43 -0700 Subject: Facebook broken over v6? In-Reply-To: References: <51B38818.2080400@b2b2c.ca> Message-ID: <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> We're actively investigating the v6 issues. We need more data though. If you're experiencing problems, please email me a tcpdump/pcap or any other debug data you think will help. Thanks, -- dsp From streiner at cluebyfour.org Sat Jun 8 21:35:26 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 8 Jun 2013 17:35:26 -0400 (EDT) Subject: Facebook broken over v6? In-Reply-To: <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> References: <51B38818.2080400@b2b2c.ca> <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> Message-ID: On Sat, 8 Jun 2013, Doug Porter wrote: > We're actively investigating the v6 issues. We need more data > though. If you're experiencing problems, please email me a > tcpdump/pcap or any other debug data you think will help. I'll see what I can grab. I've noticed the issue intermittently both at home (HE IPv6 tunnel over VZ Fios) and at work (dual-stacked .edu). jms From frnkblk at iname.com Sat Jun 8 22:43:14 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Jun 2013 17:43:14 -0500 Subject: Facebook broken over v6? In-Reply-To: <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> References: <51B38818.2080400@b2b2c.ca> <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> Message-ID: <003701ce6499$8fb830f0$af2892d0$@iname.com> Someone must have yanked the AAAA for www.facebook.com, because I see a CNAME to star.c10r.facebook.com, which doesn't have an AAAA. ============================================ DNS server: 199.120.69.24 ; <<>> DiG 9.7.3 <<>> AAAA www.facebook.com @199.120.69.24 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16032 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 3147 IN CNAME star.c10r.facebook.com. ;; AUTHORITY SECTION: c10r.facebook.com. 51 IN SOA a.ns.c10r.facebook.com. dns.facebook.com. 1370731022 300 600 600 300 ;; Query time: 0 msec ;; SERVER: 199.120.69.24#53(199.120.69.24) ;; WHEN: Sat Jun 8 17:41:30 2013 ;; MSG SIZE rcvd: 103 ============================================ DNS server: 167.142.225.5 ; <<>> DiG 9.7.3 <<>> AAAA www.facebook.com @167.142.225.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 963 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 2324 IN CNAME star.c10r.facebook.com. ;; AUTHORITY SECTION: c10r.facebook.com. 44 IN SOA a.ns.c10r.facebook.com. dns.facebook.com. 1370731022 300 600 600 300 ;; Query time: 8 msec ;; SERVER: 167.142.225.5#53(167.142.225.5) ;; WHEN: Sat Jun 8 17:41:30 2013 ;; MSG SIZE rcvd: 103 ============================================ Frank -----Original Message----- From: Doug Porter [mailto:dsp at fb.com] Sent: Saturday, June 08, 2013 3:30 PM Cc: nanog at nanog.org Subject: Re: Facebook broken over v6? We're actively investigating the v6 issues. We need more data though. If you're experiencing problems, please email me a tcpdump/pcap or any other debug data you think will help. Thanks, -- dsp From malayter at gmail.com Sat Jun 8 22:43:55 2013 From: malayter at gmail.com (Ryan Malayter) Date: Sat, 8 Jun 2013 17:43:55 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 7, 2013, at 12:25 AM, jamie rishaw wrote: > > Just wait until we find out dark and lit private fiber is getting vampired. > Speaking from the content provider dide here, but we've always run IPsec on DCIs and even "private" T1s/DS3s back in the day. Doesn't everyone do the same these days? I find it hard to imagine passing any audit/compliance process without doing so. "Private lines" or "dedicated fiber" always pass through much public, unmanaged, and unmonitored space infrastructure. And we know better than to trust our providers to never screw up and mis-route traffic. From frnkblk at iname.com Sat Jun 8 23:14:35 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Jun 2013 18:14:35 -0500 Subject: Facebook broken over v6? In-Reply-To: <8B9D122A1836AF4BB23B7966A4EABEC206962016@pcscmail001.MUTUALTEL.MTCNET.NET> References: <51B38818.2080400@b2b2c.ca> <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> <8B9D122A1836AF4BB23B7966A4EABEC206962016@pcscmail001.MUTUALTEL.MTCNET.NET> Message-ID: <003801ce649d$f0f64ec0$d2e2ec40$@iname.com> And just like that, the AAAA is back again. =) ============================================ DNS server: 167.142.225.5 ; <<>> DiG 9.7.3 <<>> AAAA www.facebook.com @167.142.225.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46006 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 452 IN CNAME star.c10r.facebook.com. star.c10r.facebook.com. 37 IN AAAA 2a03:2880:10:1f02:face:b00c:0:8 ;; AUTHORITY SECTION: c10r.facebook.com. 119251 IN NS b.ns.c10r.facebook.com. c10r.facebook.com. 119251 IN NS a.ns.c10r.facebook.com. ;; ADDITIONAL SECTION: a.ns.c10r.facebook.com. 120993 IN A 69.171.239.11 b.ns.c10r.facebook.com. 120381 IN A 69.171.255.11 ;; Query time: 7 msec ;; SERVER: 167.142.225.5#53(167.142.225.5) ;; WHEN: Sat Jun 8 18:12:42 2013 ;; MSG SIZE rcvd: 153 ============================================ Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Saturday, June 08, 2013 5:43 PM To: 'Doug Porter' Cc: nanog at nanog.org Subject: RE: Facebook broken over v6? Someone must have yanked the AAAA for www.facebook.com, because I see a CNAME to star.c10r.facebook.com, which doesn't have an AAAA. ============================================ DNS server: 199.120.69.24 ; <<>> DiG 9.7.3 <<>> AAAA www.facebook.com @199.120.69.24 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16032 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 3147 IN CNAME star.c10r.facebook.com. ;; AUTHORITY SECTION: c10r.facebook.com. 51 IN SOA a.ns.c10r.facebook.com. dns.facebook.com. 1370731022 300 600 600 300 ;; Query time: 0 msec ;; SERVER: 199.120.69.24#53(199.120.69.24) ;; WHEN: Sat Jun 8 17:41:30 2013 ;; MSG SIZE rcvd: 103 ============================================ DNS server: 167.142.225.5 ; <<>> DiG 9.7.3 <<>> AAAA www.facebook.com @167.142.225.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 963 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.facebook.com. IN AAAA ;; ANSWER SECTION: www.facebook.com. 2324 IN CNAME star.c10r.facebook.com. ;; AUTHORITY SECTION: c10r.facebook.com. 44 IN SOA a.ns.c10r.facebook.com. dns.facebook.com. 1370731022 300 600 600 300 ;; Query time: 8 msec ;; SERVER: 167.142.225.5#53(167.142.225.5) ;; WHEN: Sat Jun 8 17:41:30 2013 ;; MSG SIZE rcvd: 103 ============================================ Frank -----Original Message----- From: Doug Porter [mailto:dsp at fb.com] Sent: Saturday, June 08, 2013 3:30 PM Cc: nanog at nanog.org Subject: Re: Facebook broken over v6? We're actively investigating the v6 issues. We need more data though. If you're experiencing problems, please email me a tcpdump/pcap or any other debug data you think will help. Thanks, -- dsp From james at talkunafraid.co.uk Sun Jun 9 00:20:46 2013 From: james at talkunafraid.co.uk (James Harrison) Date: Sun, 09 Jun 2013 01:20:46 +0100 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <51B3CA5E.1070704@talkunafraid.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2013 16:31, William Herrin wrote: > On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: >> Just wait until we find out dark and lit private fiber is getting >> vampired. > > Why wait? > > http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 > > -Bill > In a similar vein, a new PRISM slide was released by the Guardian this morning: http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server-collection-facebook-google Doesn't specifically say private fiber - just "fiber cables and infrastructure". May just refer to fiber to/from/within complying company infrastructure, ofc, not necessarily anything else. They also apparently have a web 2.0 compliant dashboard with a catchy name and pop-ups with big numbers in: Boundless Informant. http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant-global-datamining Speaking from the other side of the pond it's interesting to see where this is going. GCHQ (the UK NSA equivalent) are being asked stern questions by the government about their involvement and if they've been asking the NSA for UK citizens' data (since they're not allowed to collect it themselves). Cheers, James Harrison -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ =auDI -----END PGP SIGNATURE----- From ben at meh.net.nz Sun Jun 9 00:38:53 2013 From: ben at meh.net.nz (Ben Aitchison) Date: Sun, 9 Jun 2013 12:38:53 +1200 Subject: Facebook broken over v6? In-Reply-To: <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> References: <51B38818.2080400@b2b2c.ca> <60aee791-7c19-439e-971d-a41755c157d8@PRN-CHUB01.TheFacebook.com> Message-ID: <20130609003852.GA32739@meh.net.nz> On Sat, Jun 08, 2013 at 01:29:43PM -0700, Doug Porter wrote: > We're actively investigating the v6 issues. We need more data > though. If you're experiencing problems, please email me a > tcpdump/pcap or any other debug data you think will help. I was experiencing problems, and disabling ipv6 seemed to fix it, and have also been experiencing sometimes slow speeds to google so didn't know if it was concurrent facebook/google issues (which I suspected) or a general ipv6 issue. So I reenabled ipv6, and did tcpdump and it seems to be behaving fine now, although slightly slower than ipv4 even though ipv6 seems to pick a closer data centre than ipv4. Both of which are further away than they used to be. (entry point lax, destination seems to be frc1 for ipv4 and www.v6.facebook.com, and prn1 for ipv6 www.facebook.com. Is there some url that could run a regular curl to to see if it times out off/on? Another concurrent issue, is it seems images are getting slower and slower over time. It seems for some reason that https is forced, even if disabled in profile settings and that cdn usage keeps varying over time, it used to have urls like photos-a.ak.fbcdn.net but now it seeems to have fbcdn-sphotos-a-a.akamaihd.net. Curiously photos-a.ak.fbcdn.net still looks up with < 1 msec ping rather then ~190 msec ping. Ben. From cciehelps at gmail.com Sun Jun 9 02:44:24 2013 From: cciehelps at gmail.com (ku po) Date: Sun, 9 Jun 2013 10:44:24 +0800 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B3CA5E.1070704@talkunafraid.co.uk> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B3CA5E.1070704@talkunafraid.co.uk> Message-ID: What is the point to argue whether they have the capacity to process all the data? They DON'T need to build expensive systems. They just need to make sure when they ask your company for information, these information are available for them and fast enough. So the statement that saying "we don't give them direct access" means nothing!!! The right question is IS THERE A DIRECT CHANNEL for them to ask you for information without providing all the evidence( how could they show you all the evidence when it is security related??), which you can't deny their access. On Sun, Jun 9, 2013 at 8:20 AM, James Harrison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/06/2013 16:31, William Herrin wrote: > > On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: > >> Just wait until we find out dark and lit private fiber is getting > >> vampired. > > > > Why wait? > > > > http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 > > > > -Bill > > > > In a similar vein, a new PRISM slide was released by the Guardian this > morning: > > > http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server-collection-facebook-google > > Doesn't specifically say private fiber - just "fiber cables and > infrastructure". May just refer to fiber to/from/within complying > company infrastructure, ofc, not necessarily anything else. > > They also apparently have a web 2.0 compliant dashboard with a catchy > name and pop-ups with big numbers in: Boundless Informant. > > > http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant-global-datamining > > Speaking from the other side of the pond it's interesting to see where > this is going. GCHQ (the UK NSA equivalent) are being asked stern > questions by the government about their involvement and if they've > been asking the NSA for UK citizens' data (since they're not allowed > to collect it themselves). > > Cheers, > James Harrison > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > > iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD > HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ > =auDI > -----END PGP SIGNATURE----- > > From cciehelps at gmail.com Sun Jun 9 02:58:42 2013 From: cciehelps at gmail.com (ku po) Date: Sun, 9 Jun 2013 10:58:42 +0800 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B3CA5E.1070704@talkunafraid.co.uk> Message-ID: I don't need any wire tapping or decrypting. Let's say I want to see all NANOG emails, I just need to call Larry Page's CSO office and someone will send me a copy. of course I can't give you any evidence, how could I? Does it make sense? On Sun, Jun 9, 2013 at 10:44 AM, ku po wrote: > What is the point to argue whether they have the capacity to process all > the data? > They DON'T need to build expensive systems. > They just need to make sure when they ask your company for information, > these information are available for them and fast enough. > So the statement that saying "we don't give them direct access" means > nothing!!! > The right question is IS THERE A DIRECT CHANNEL for them to ask you for > information without providing all the evidence( how could they show you all > the evidence when it is security related??), which you can't deny their > access. > > > > > On Sun, Jun 9, 2013 at 8:20 AM, James Harrison wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/06/2013 16:31, William Herrin wrote: >> > On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: >> >> Just wait until we find out dark and lit private fiber is getting >> >> vampired. >> > >> > Why wait? >> > >> > http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 >> > >> > -Bill >> > >> >> In a similar vein, a new PRISM slide was released by the Guardian this >> morning: >> >> >> http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server-collection-facebook-google >> >> Doesn't specifically say private fiber - just "fiber cables and >> infrastructure". May just refer to fiber to/from/within complying >> company infrastructure, ofc, not necessarily anything else. >> >> They also apparently have a web 2.0 compliant dashboard with a catchy >> name and pop-ups with big numbers in: Boundless Informant. >> >> >> http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant-global-datamining >> >> Speaking from the other side of the pond it's interesting to see where >> this is going. GCHQ (the UK NSA equivalent) are being asked stern >> questions by the government about their involvement and if they've >> been asking the NSA for UK citizens' data (since they're not allowed >> to collect it themselves). >> >> Cheers, >> James Harrison >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.17 (MingW32) >> >> iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD >> HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ >> =auDI >> -----END PGP SIGNATURE----- >> >> > From jlsparks at gmail.com Sun Jun 9 10:24:20 2013 From: jlsparks at gmail.com (Jason L. Sparks) Date: Sun, 9 Jun 2013 06:24:20 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B3CA5E.1070704@talkunafraid.co.uk> Message-ID: <6BAB4939-1DC1-4E40-8DB3-5CF9E0C87793@gmail.com> To be fair, the reporting (initially) claimed the providers were granting the USG "access directly to their servers." It's understandable and appropriate that the providers pushed back against that apparently erroneous reporting. Jason On Jun 8, 2013, at 22:44, ku po wrote: > What is the point to argue whether they have the capacity to process all > the data? > They DON'T need to build expensive systems. > They just need to make sure when they ask your company for information, > these information are available for them and fast enough. > So the statement that saying "we don't give them direct access" means > nothing!!! > The right question is IS THERE A DIRECT CHANNEL for them to ask you for > information without providing all the evidence( how could they show you all > the evidence when it is security related??), which you can't deny their > access. > > > > > On Sun, Jun 9, 2013 at 8:20 AM, James Harrison wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/06/2013 16:31, William Herrin wrote: >>> On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: >>>> Just wait until we find out dark and lit private fiber is getting >>>> vampired. >>> >>> Why wait? >>> >>> http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 >>> >>> -Bill >> >> In a similar vein, a new PRISM slide was released by the Guardian this >> morning: >> >> >> http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server-collection-facebook-google >> >> Doesn't specifically say private fiber - just "fiber cables and >> infrastructure". May just refer to fiber to/from/within complying >> company infrastructure, ofc, not necessarily anything else. >> >> They also apparently have a web 2.0 compliant dashboard with a catchy >> name and pop-ups with big numbers in: Boundless Informant. >> >> >> http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant-global-datamining >> >> Speaking from the other side of the pond it's interesting to see where >> this is going. GCHQ (the UK NSA equivalent) are being asked stern >> questions by the government about their involvement and if they've >> been asking the NSA for UK citizens' data (since they're not allowed >> to collect it themselves). >> >> Cheers, >> James Harrison >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.17 (MingW32) >> >> iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD >> HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ >> =auDI >> -----END PGP SIGNATURE----- >> >> From m.hallgren at free.fr Sun Jun 9 11:07:04 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Sun, 09 Jun 2013 13:07:04 +0200 Subject: PRISM: NSA/FBI Internet data mining project Message-ID: <7facc0euly5g8iwfad321ene.1370776024619@email.android.com> Yet appears a certain lack of transparency, no?? mh? -------- Message d'origine -------- De : "Jason L. Sparks" Date : A : ku po Cc : NANOG Objet : Re: PRISM: NSA/FBI Internet data mining project To be fair, the reporting (initially) claimed the providers were granting the USG "access directly to their servers."? It's understandable and appropriate that the providers pushed back against that apparently erroneous reporting. Jason On Jun 8, 2013, at 22:44, ku po wrote: > What is the point to argue whether they have the capacity to process all > the data? > They DON'T need to build expensive systems. > They just need to make sure when they ask your company for information, > these information are available for them and fast enough. > So the statement that saying "we don't give them direct access" means > nothing!!! > The right question is IS THERE A DIRECT CHANNEL for them to ask you for > information without providing all the evidence( how could they show you all > the evidence when it is security related??),? which you can't deny their > access. > > > > > On Sun, Jun 9, 2013 at 8:20 AM, James Harrison wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/06/2013 16:31, William Herrin wrote: >>> On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: >>>> Just wait until we find out dark and lit private fiber is getting >>>> vampired. >>> >>> Why wait? >>> >>> http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 >>> >>> -Bill >> >> In a similar vein, a new PRISM slide was released by the Guardian this >> morning: >> >> >> http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server-collection-facebook-google >> >> Doesn't specifically say private fiber - just "fiber cables and >> infrastructure". May just refer to fiber to/from/within complying >> company infrastructure, ofc, not necessarily anything else. >> >> They also apparently have a web 2.0 compliant dashboard with a catchy >> name and pop-ups with big numbers in: Boundless Informant. >> >> >> http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant-global-datamining >> >> Speaking from the other side of the pond it's interesting to see where >> this is going. GCHQ (the UK NSA equivalent) are being asked stern >> questions by the government about their involvement and if they've >> been asking the NSA for UK citizens' data (since they're not allowed >> to collect it themselves). >> >> Cheers, >> James Harrison >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.17 (MingW32) >> >> iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD >> HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ >> =auDI >> -----END PGP SIGNATURE----- >> >> From Ben.Kessler at zenetra.com Sun Jun 9 12:20:46 2013 From: Ben.Kessler at zenetra.com (R. Benjamin Kessler) Date: Sun, 9 Jun 2013 12:20:46 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <0CFF54003CD92945994CF0C0F90D81B6014EFB9F@EXCH1-FWA1.zenetra.local> On Saturday, June 08, 2013 6:44 PM, Ryan Malayter [mailto:malayter at gmail.com] wrote: > Speaking from the content provider dide here, but we've always run IPsec on DCIs and even "private" T1s/DS3s back in the day. > Doesn't everyone do the same these days? I find it hard to imagine passing any audit/compliance process without doing so. > "Private lines" or "dedicated fiber" always pass through much public, unmanaged, and unmonitored space infrastructure. And we know better > than to trust our providers to never screw up and mis-route traffic. I see that there is actually a beast that will do encryption of multiple 10G waves between Cisco ONS boxes - https://www.cisco.com/en/US/prod/collateral/optical/ps5724/ps2006/at_a_glance_c45-728015.pdf How many people are actually doing this? From dwhite at olp.net Sun Jun 9 16:10:34 2013 From: dwhite at olp.net (Dan White) Date: Sun, 9 Jun 2013 11:10:34 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> Message-ID: <20130609161033.GA16372@dan.olp.net> On 06/07/13?18:20?-0700, Owen DeLong wrote: >While the government has no responsibility to protect my data, they do >have a responsibility to respect my privacy. While you are correct in that >proper personal security procedures to protect my data from random >crackers would, in fact, also protect it from the government, that's a far >cry from what is at issue here. > >The question here is whether or not it should be considered legitimate for >the US Government to completely ignore the fourth and fifth amendments to >the constitution and build out unprecedented surveillance capabilities >capturing vast amounts of data without direct probable cause for that >snooping. > >I'm not so much concerned about them gaining access to data I don't want >them to access. I am far more disturbed by the trend which reflects a >government which increasingly considers itself unrestrained by the laws it >is in place to support and implement. Let me put my gold tipped tinfoil hat on in response to your statement. Suppose the following are true: * Meta data for emails sent to and from most US citizens can be captured on a government scale budget * Meta data for all phone calls and skype sessions can also * Cell phone location data - which cell towers your device associates with, over a long period of time - can be captured in log form or stored in a database * Social data can be analyzed to determine who your acquaintances are, and when you communicate with them over time. Now suppose that the NSA contracts with a private company to collect information about terrorist entities, who in turn privately contracts with the top X telecom providers and Y social media companies to obtain all available information that it can, via TAP ports or direct database access. That private organization, through analysis, knows a lot about you, such as every place you've physically been in the last 10 years, what your political leanings are, what criminals you have associated with in that time period, what the likelyhood is that you are a future criminal and of which crimes, how many guns you own, your browsing history and what you like to do in your free time, and . Have your 4th Amendment rights been abridged in this scenario? If you think they have, how confident are you that the court system will agree with you? -- Dan White From wbailey at satelliteintelligencegroup.com Sun Jun 9 16:26:28 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 9 Jun 2013 16:26:28 +0000 Subject: Prism continued Message-ID: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> I suppose this system was part of the 20MM as well? http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the-512107983 Sent from my Mobile Device. From symack at gmail.com Sun Jun 9 16:36:31 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 9 Jun 2013 12:36:31 -0400 Subject: OC3/STM-1 Line Card In-Reply-To: References: Message-ID: Anyone? Good quality SIGTRAN/SS7 on STM-1/OCN? Kind Regards, Nick. From eaptech at gmail.com Sun Jun 9 16:47:34 2013 From: eaptech at gmail.com (Eric Adler) Date: Sun, 9 Jun 2013 12:47:34 -0400 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: <4720053.7516.1370719507281.JavaMail.root@benjamin.baylink.com> References: <4720053.7516.1370719507281.JavaMail.root@benjamin.baylink.com> Message-ID: The view from my side, as both a broadcaster and a consumer of both broadcast and 'webcast' content: >From what I've been led to understand in my time in broadcast*, the decision wasn't made because of power costs but because they (the Grand Alliance and the FCC) believed that 8VSB would work better over the US both due to terrain and propagation differences and due to our markets of television transmitters and need to place co-channel (same frequency) transmitters relatively nearby with minimal interference. Some argue that (C)OFDM would have been a better choice even taking those things into account. Which should have been chosen based on what criteria is a long discussion in and of itself but we've got 8VSB (at least for now). As for the mobile thing, I don't know if anyone had thought that far ahead. It seems silly now since I had a 2" rear-projection portable NTSC TV that was made in the mid-to-late 1980s (Sony Watchman) and now they are trying to 'solve' the mobile delivery 'problem'. ATSC M/H adds a lot of error correction as well as 'training data' to make the M/H stream 'easy' to detect and decode, even with Doppler and multipath effects (see ATSC A/153 part 2 for detail) - this reduces the data rate available for the 'main' (A/53) data significantly and does not create nearly as much available for the M/H (A/153) data. This sounds even sillier when you realize that ATSC standard A/49, first published in 1993, was a "Ghost Canceling Reference Signal for NTSC" (ghosting on NTSC is a symptom of multipath). As for 'webcasting' replacing RF broadcasting, I think we're a ways out if it will even ever happen in the general case yet alone every case. RF broadcast is very efficient, as previously mentioned. As a broadcaster, I push 19.393 Mbps of content 'into the air' for everyone around to receive at once. As a consumer, I have four tuners attached to what amounts to a few pieces of wire and I can receive roughly 80 Mbit of non-blocking data 'through the air'. My ISP provides me a downlink speed of roughly 10 Mbps. If I were in a larger market, I'd be able to receive even more data (non-blocking with more tuners or blocking from my POV if I didn't have enough tuners for every channel); even if the ISP provided downlink speeds scaled up similarly, there would be much more data available 'through the air'. The people who live near me have the opportunity to receive that same 80 Mbit of data without any transit costs. Can CDNs replace some of what is now broadcast? Likely. By reducing data rates (with better compression technologies as well as simply compressing more) and providing content that viewers want, they could (Netflix and others are already doing this with some content). There is, of course, a lingering societal question about "shared viewing experiences" for shows having set delivery schedules by broadcast. Live content and local content, however, will still be (in my opinion) best served by RF broadcast for some time to come due to both the inherent efficiencies in the system and the ease of localization for end-users. * The ATSC Digital Television Standard (A/53) was developed, documented, and formalized from the late 1980s through the mid 1990s (A/53 Part 1, Annex A describes the history). I wasn't working in television until 2000 or so and I wasn't doing television broadcast-related work until 2008. - Eric Eric Adler Broadcast Engineer From tom.taylor.stds at gmail.com Sun Jun 9 16:57:04 2013 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Sun, 09 Jun 2013 12:57:04 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607065131.GB21448@besserwisser.org> Message-ID: <51B4B3E0.3090402@gmail.com> On 08/06/2013 8:05 AM, Matthew Petach wrote: > On Sat, Jun 8, 2013 at 4:12 AM, Jimmy Hess wrote: > >> On 6/7/13, M?ns Nilsson wrote: >>> Subject: Re: PRISM: NSA/FBI Internet data mining project Date: Fri, Jun >> 07, >>> 2013 at 12:25:35AM -0500 Quoting jamie rishaw (j at arpa.com): >>>> >>>> Just wait until we find out dark and lit private fiber is getting >>>> vampired. >>>> >>> I'm not even assuming it, I'm convinced. In Sweden, we have a law, >>> that makes what NSA/FBI did illegal while at the same time legalising, >> >> Perhaps strong crypto should be implemented on transceivers at each >> end of every link, so users could be protected from that without >> having to implement the crypto themselves at the application layer? :) >> > > Would you really trust "crypto" applied by someone else on your behalf? > > "sure, your data's safe--I triple rot-13'd it myself!" ;P > > Matt > . > At least that was an odd number of rotations :) From philfagan at gmail.com Sun Jun 9 17:13:24 2013 From: philfagan at gmail.com (Phil Fagan) Date: Sun, 9 Jun 2013 11:13:24 -0600 Subject: OC3/STM-1 Line Card In-Reply-To: References: Message-ID: Don't you need to drop DS0's out of that STM for signaling? On Sat, Jun 8, 2013 at 9:58 AM, Nick Khamis wrote: > Hello Everyone, > > Anyone know of a way of bypassing the 90K audiocodes mediant 3000 > equipped for STM-1 interface using line cards and a linux box :). > > What we are looking to do is replace our traditional ISDN DS3 equipped > for voice using an STM-1/OC3 backbone and our own put together linux > box. Again, this will be used for voice signaling... > > Kind Regards, > > Nick. > > -- Phil Fagan Denver, CO 970-480-7618 From jfmezei_nanog at vaxination.ca Sun Jun 9 17:20:58 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 09 Jun 2013 13:20:58 -0400 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: References: <4720053.7516.1370719507281.JavaMail.root@benjamin.baylink.com> Message-ID: <51B4B97A.7010509@vaxination.ca> On 13-06-09 12:47, Eric Adler wrote: > TV that was made in the mid-to-late 1980s (Sony Watchman) and now they are > trying to 'solve' the mobile delivery 'problem'. Qualcomm is working on adding "broadcast" capabilities to LTE (this was from recent at a conference (Telecom Summit in Toronto), so I suspect they would implement as multicast). Right now, there is negative incentive for large ISPs to deploy multicasting on their ISP service because the large ISPs are also legacy TV distributors (aka: cable TV) and that business is highly profitable and they aren't about to help lower cost competitors eat into their cable TV business. However, once internet distribution realy takes off, you'll find the motivation to deploy multicasting will grow because ISPs will want to cut their costs (and that may also be the big incentive to really move to IPv6). But when you think about it, the only time multicast becomes useful is for live broadcasts (sports, sometimes news). For the rest, the world is moving to on-demand viewing where multicast does not provide any advantage. And something to consider: while legacy TV is on /24/365, there is not enough programming to fill all the time, hence the many reruns. Same with infotainment networks like CNN who reruns their stories multiple times per hour throughout the day. In an on demand world, the bandwidth will be relative to the amount of content actually being produced, not the number of hours per day. If you have already seen a CNN reprt on its web site, you're not going to watch it again 5 times during the day. But if you are watching CNN on linear TV, you have to keep watching just in case there is something new that is shown. I predict big changes in viewing habits. And this would have implications on how your guys architect your networks. What used to be TV Networks with stations in every city is likely to become cache servers distributed in every city. (some would call them CDNs :-) From mloftis at wgops.com Sun Jun 9 17:29:13 2013 From: mloftis at wgops.com (Michael Loftis) Date: Sun, 9 Jun 2013 10:29:13 -0700 Subject: OC3/STM-1 Line Card In-Reply-To: References: Message-ID: Most modern gear can go all the way to individual DS0's in a single card without a MUX of any kind. OC3/STM-1 is only like 155mbit. On Sun, Jun 9, 2013 at 10:13 AM, Phil Fagan wrote: > Don't you need to drop DS0's out of that STM for signaling? > > > On Sat, Jun 8, 2013 at 9:58 AM, Nick Khamis wrote: > >> Hello Everyone, >> >> Anyone know of a way of bypassing the 90K audiocodes mediant 3000 >> equipped for STM-1 interface using line cards and a linux box :). >> >> What we are looking to do is replace our traditional ISDN DS3 equipped >> for voice using an STM-1/OC3 backbone and our own put together linux >> box. Again, this will be used for voice signaling... >> >> Kind Regards, >> >> Nick. >> >> > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From drohan at gmail.com Sun Jun 9 17:42:22 2013 From: drohan at gmail.com (Daniel Rohan) Date: Sun, 9 Jun 2013 10:42:22 -0700 Subject: Prism continued In-Reply-To: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: Anyone else notice that the Boundless Informant GUI looks suspiciously like the Splunk GUI? And according to the article, it sounds like it does exactly what Splunk is capable of, albeit on a grander scale than I thought possible. dgr On Jun 9, 2013 9:29 AM, "Warren Bailey" < wbailey at satelliteintelligencegroup.com> wrote: > I suppose this system was part of the 20MM as well? > > > http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the-512107983 > > > > Sent from my Mobile Device. > From malayter at gmail.com Sun Jun 9 17:49:44 2013 From: malayter at gmail.com (Ryan Malayter) Date: Sun, 9 Jun 2013 12:49:44 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <0CFF54003CD92945994CF0C0F90D81B6014EFB9F@EXCH1-FWA1.zenetra.local> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <0CFF54003CD92945994CF0C0F90D81B6014EFB9F@EXCH1-FWA1.zenetra.local> Message-ID: <9684A50C-733D-4126-BF3B-A0476BD0E9D1@gmail.com> On Jun 9, 2013, at 7:20 AM, "R. Benjamin Kessler" wrote: > I see that there is actually a beast that will do encryption of multiple 10G waves between Cisco ONS boxes - > > https://www.cisco.com/en/US/prod/collateral/optical/ps5724/ps2006/at_a_glance_c45-728015.pdf > > How many people are actually doing this? Not sure why you would want the massive fail that is layer-2 DCI in the first place, but you certainly don't need this sort of ridiculously expensive gear. Packet encryption is embarrassingly parallel when you have lots of flows, and best distributed throughout the infrastructure to many endpoints. One big expensive box is one big bottleneck and one big SPOF. We actually use cluster-to-cluster and even host-to-host IPsec SAs in certain cases. From philfagan at gmail.com Sun Jun 9 17:50:21 2013 From: philfagan at gmail.com (Phil Fagan) Date: Sun, 9 Jun 2013 11:50:21 -0600 Subject: OC3/STM-1 Line Card In-Reply-To: References: Message-ID: Nick are you trying to run these codecs on linux? On Sun, Jun 9, 2013 at 11:29 AM, Michael Loftis wrote: > Most modern gear can go all the way to individual DS0's in a single > card without a MUX of any kind. OC3/STM-1 is only like 155mbit. > > On Sun, Jun 9, 2013 at 10:13 AM, Phil Fagan wrote: > > Don't you need to drop DS0's out of that STM for signaling? > > > > > > On Sat, Jun 8, 2013 at 9:58 AM, Nick Khamis wrote: > > > >> Hello Everyone, > >> > >> Anyone know of a way of bypassing the 90K audiocodes mediant 3000 > >> equipped for STM-1 interface using line cards and a linux box :). > >> > >> What we are looking to do is replace our traditional ISDN DS3 equipped > >> for voice using an STM-1/OC3 backbone and our own put together linux > >> box. Again, this will be used for voice signaling... > >> > >> Kind Regards, > >> > >> Nick. > >> > >> > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > > -- Phil Fagan Denver, CO 970-480-7618 From kmedcalf at dessus.com Sun Jun 9 18:01:29 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 09 Jun 2013 12:01:29 -0600 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <6BAB4939-1DC1-4E40-8DB3-5CF9E0C87793@gmail.com> Message-ID: <4da965c766237b41bf44ba11bc775956@mail.dessus.com> Of course the access isn't direct -- there is a firewall and a router in between. The access is indirect. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Jason L. Sparks [mailto:jlsparks at gmail.com] > Sent: Sunday, 09 June, 2013 04:24 > To: ku po > Cc: NANOG > Subject: Re: PRISM: NSA/FBI Internet data mining project > > To be fair, the reporting (initially) claimed the providers were granting > the USG "access directly to their servers." It's understandable and > appropriate that the providers pushed back against that apparently > erroneous reporting. > > Jason > > On Jun 8, 2013, at 22:44, ku po wrote: > > > What is the point to argue whether they have the capacity to process all > > the data? > > They DON'T need to build expensive systems. > > They just need to make sure when they ask your company for information, > > these information are available for them and fast enough. > > So the statement that saying "we don't give them direct access" means > > nothing!!! > > The right question is IS THERE A DIRECT CHANNEL for them to ask you for > > information without providing all the evidence( how could they show you > all > > the evidence when it is security related??), which you can't deny their > > access. > > > > > > > > > > On Sun, Jun 9, 2013 at 8:20 AM, James Harrison > wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 08/06/2013 16:31, William Herrin wrote: > >>> On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw wrote: > >>>> Just wait until we find out dark and lit private fiber is getting > >>>> vampired. > >>> > >>> Why wait? > >>> > >>> http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0 > >>> > >>> -Bill > >> > >> In a similar vein, a new PRISM slide was released by the Guardian this > >> morning: > >> > >> > >> http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server- > collection-facebook-google > >> > >> Doesn't specifically say private fiber - just "fiber cables and > >> infrastructure". May just refer to fiber to/from/within complying > >> company infrastructure, ofc, not necessarily anything else. > >> > >> They also apparently have a web 2.0 compliant dashboard with a catchy > >> name and pop-ups with big numbers in: Boundless Informant. > >> > >> > >> http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant- > global-datamining > >> > >> Speaking from the other side of the pond it's interesting to see where > >> this is going. GCHQ (the UK NSA equivalent) are being asked stern > >> questions by the government about their involvement and if they've > >> been asking the NSA for UK citizens' data (since they're not allowed > >> to collect it themselves). > >> > >> Cheers, > >> James Harrison > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v2.0.17 (MingW32) > >> > >> iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD > >> HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ > >> =auDI > >> -----END PGP SIGNATURE----- > >> > >> From rob at invaluement.com Sun Jun 9 18:26:00 2013 From: rob at invaluement.com (Rob McEwen) Date: Sun, 09 Jun 2013 14:26:00 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130609161033.GA16372@dan.olp.net> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> Message-ID: <51B4C8B8.3000006@invaluement.com> Dan, I doubt anyone can answer your question easily because you seem to have contradictions in your scenario. At one point you say: > private company to collect information about terrorist entities, who > in turn privately contracts with the top X telecom providers and Y > social media companies but then you continue: > to obtain all available information that it can, via TAP ports or > direct database access. and then: > That private organization, through analysis, knows a lot about you I'm confused, in your scenario, is the data collection limited to "terrorist entities", or does your statement, "all available information that it can" mean that it gets everyone's info, and then does their filtering later? Additionally, one would hope that by "terrorist entities", you would be referring to those who plan on hurting or killing innocent people, whether that be an Islamofactist terrorist planning to blow up a government building, or a right wing terrorist planning to do the same (for different reasons), or a environmentalists planning to sink a legal whaling boat, or a anti-abortionist planning to blow up an abortion clinic... take your pick. The point being that mass-killing of innocent people is the common thread... NOT the politics. And I hope that you haven't downward defined this to someone that could be easily used to "pick off" political opponents, right? > Have your 4th Amendment rights been abridged in this scenario Sorry if this comes across as rude or snobby, but I think you just need to read the 4th Amendment about 20 times to yourself and let it all soak in. TO ANSWER YOUR QUESTION: If the Federal Government is paying a private entity to do the snooping, then they are a defacto agent of the state. That doesn't make the 4th amendment apply any less applicable. Even then, to abide by the 4th amendment, there should be SPECIFIC persons/orgs AND specific info/items that are being searched where that search is SPECIFICALLY approved by a judge or court IN ADVANCE (no super wide "blanket" approvals, no broad fishing expeditions)... only THEN does the searching for the information meet 4th amendment requirements. The fact that the search was of your e-mail or phone records doesn't make the 4th amendment apply any less than if they were looking inside the drawer in the nightstand next to your bed! There are notable exceptions... for example, an employer is really the owner of the mailbox, not their employee. Therefore, there is an argument that government employees don't have "privacy rights" from the government for their official work e-mail accounts. There are probably several other exceptions like that. But such exceptions are a tiny percentage of the whole. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From mikea at mikea.ath.cx Sun Jun 9 19:23:17 2013 From: mikea at mikea.ath.cx (Mike A) Date: Sun, 9 Jun 2013 14:23:17 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B269FA.9070106@nic-naa.net> References: <13976.1370628323@turing-police.cc.vt.edu> <9152177.7434.1370632093430.JavaMail.root@benjamin.baylink.com> <51B269FA.9070106@nic-naa.net> Message-ID: <20130609192317.GB19600@mikea.ath.cx> On Fri, Jun 07, 2013 at 04:17:14PM -0700, Eric Brunner-Williams wrote: > http://www.guardian.co.uk/world/2013/jun/07/obama-china-targets-cyber-overseas > > the headline may be misleading. > > Presidential Policy Directive 20 defines OCEO as "operations and > related programs or activities ? conducted by or on behalf of the > United States Government, in or through cyberspace, that are intended > to enable or produce cyber effects outside United States government > networks." > > effects outside United States government networks. > > now there's an interesting phrase. > > OCEO == "Offensive Cyber Effects Operations". No more so than describing NSA operations as "research in communications phenomena", which used to be the (UNCLAS) party line. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From bill at herrin.us Sun Jun 9 21:23:28 2013 From: bill at herrin.us (William Herrin) Date: Sun, 9 Jun 2013 17:23:28 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Jun 6, 2013 at 9:28 PM, Leo Bicknell wrote: > While there's a whole political aspect of electing people who pass > better laws, NANOG is not a political action forum. However many > of the people on NANOG are in positions to affect positive change > at their respective employers. > > - Implement HTTPS for all services. > - Implement PGP for e-mail. > - Implement S/MIME for e-mail. > - Build cloud services that encrypt on the client machine, using a key that is only kept on the client machine. > - Create better UI frameworks for managing keys and identities. > - Align data retention policies with the law. > - Scrutinize and reject defective government legal requests. > - When allowed by law, charge law enforcement for access to data. +1 Very few of you work in jobs where the external requirements are so well and rigidly defined that you lack the leeway to include these sorts of efforts. You may not control the feature list but you control the components which compose the features tasked to you. Write it in to the things you do and give the next guy an opportunity to follow your lead. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From m.hallgren at free.fr Sun Jun 9 21:54:09 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Sun, 09 Jun 2013 23:54:09 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B4C8B8.3000006@invaluement.com> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <51B4C8B8.3000006@invaluement.com> Message-ID: <51B4F981.4070000@free.fr> Le 09/06/2013 20:26, Rob McEwen a ?crit : > Dan, > > I doubt anyone can answer your question easily because you seem to have > contradictions in your scenario. At one point you say: > >> private company to collect information about terrorist entities, who >> in turn privately contracts with the top X telecom providers and Y >> social media companies > but then you continue: >> to obtain all available information that it can, via TAP ports or >> direct database access. > and then: >> That private organization, through analysis, knows a lot about you > I'm confused, in your scenario, is the data collection limited to > "terrorist entities", or does your statement, "all available information > that it can" mean that it gets everyone's info, and then does their > filtering later? > > Additionally, one would hope that by "terrorist entities", you would be > referring to those who plan on hurting or killing innocent people, > whether that be an Islamofactist terrorist planning to blow up a > government building, or a right wing terrorist planning to do the same > (for different reasons), or a environmentalists planning to sink a legal > whaling boat, or a anti-abortionist planning to blow up an abortion > clinic... take your pick. The point being that mass-killing of innocent > people is the common thread... NOT the politics. And I hope that you > haven't downward defined this to someone that could be easily used to > "pick off" political opponents, right? > >> Have your 4th Amendment rights been abridged in this scenario > Sorry if this comes across as rude or snobby, but I think you just need > to read the 4th Amendment about 20 times to yourself and let it all soak in. > > TO ANSWER YOUR QUESTION: > If the Federal Government is paying a private entity to do the snooping, > then they are a defacto agent of the state. That doesn't make the 4th > amendment apply any less applicable. Even then, to abide by the 4th > amendment, there should be SPECIFIC persons/orgs AND specific info/items > that are being searched where that search is SPECIFICALLY approved by a > judge or court IN ADVANCE (no super wide "blanket" approvals, no broad > fishing expeditions)... only THEN does the searching for the information > meet 4th amendment requirements. The fact that the search was of your > e-mail or phone records doesn't make the 4th amendment apply any less > than if they were looking inside the drawer in the nightstand next to > your bed! > > There are notable exceptions... for example, an employer is really the > owner of the mailbox, not their employee. Therefore, there is an > argument that government employees don't have "privacy rights" from the > government for their official work e-mail accounts. There are probably > several other exceptions like that. But such exceptions are a tiny > percentage of the whole. Right. And among these exceptions we (still) find, at least in some European countries, the notion of a private sphere also in your professional role. Summing up to that a reasonable amount and type of private communications (for instance, with your bank, childcare, tax office, family, friends, and other with whom you may share urgency as well as office hours and inability of relying efficiently on end-to-en encryption) are likely to happen, and expected to be honored as private, also via your professional communication channels. I think that, in France for instance, you flag these communications by tagging them 'private/perso' or similar and legally expect them to be treated as such. I may stand corrected? A word about a small, yet significant I think, piece in a quite complex puzzle... Cheers, mh > From randy.fischer at gmail.com Sun Jun 9 22:59:16 2013 From: randy.fischer at gmail.com (Randy Fischer) Date: Sun, 9 Jun 2013 18:59:16 -0400 Subject: Mechanics of CALEA taps Message-ID: Dear nanog: Honestly, I expect replies to this question to range between zero and none, but I have to ask it. I understand the CALEA tap mechanism for most ISPs, generally, works like this: * we outsource our CALEA management to company X * we don't even know there's been a request until we've gotten a bill from X. And that's the extent of it. Well, golly Slothrop, maybe someone else has started picking up the tab. Would you even know? Is that possible? Thanks, Randy Fischer From alex at corp.nac.net Mon Jun 10 00:15:29 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Sun, 9 Jun 2013 20:15:29 -0400 Subject: Mechanics of CALEA taps In-Reply-To: References: Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5462F7@EXCHMBX.hq.nac.net> > Honestly, I expect replies to this question to range between zero and none, > but I have to ask it. Surprise! > I understand the CALEA tap mechanism for most ISPs, generally, works like > this: > > * we outsource our CALEA management to company X > * we don't even know there's been a request until we've gotten a bill from X. I've never even thought of the idea of outsourcing CALEA requests. That is probably because I would never consider doing it. Perhaps we are in the minority, but we scrutinize every request of any sort to ensure it has jurisdiction and is valid. I can't even fathom the thought of trusting a third party for this. From tvhawaii at shaka.com Mon Jun 10 00:16:55 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 9 Jun 2013 14:16:55 -1000 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) References: <4720053.7516.1370719507281.JavaMail.root@benjamin.baylink.com> Message-ID: <99804DCC76624234B44D6AA8F5E928BB@owner59e1f1502> Eric Adler wrote: > The view from my side, as both a broadcaster and a consumer of both > broadcast and 'webcast' content: > [snip] Thank you Eric...your comments are very much appreciated. --Michael From morrowc.lists at gmail.com Mon Jun 10 00:43:00 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 9 Jun 2013 20:43:00 -0400 Subject: Mechanics of CALEA taps In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5462F7@EXCHMBX.hq.nac.net> References: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5462F7@EXCHMBX.hq.nac.net> Message-ID: (from back when I cared more about calea as an implementor) On Sun, Jun 9, 2013 at 8:15 PM, Alex Rubenstein wrote: >> Honestly, I expect replies to this question to range between zero and none, >> but I have to ask it. > > Surprise! me too! > >> I understand the CALEA tap mechanism for most ISPs, generally, works like >> this: >> >> * we outsource our CALEA management to company X >> * we don't even know there's been a request until we've gotten a bill from X. > > I've never even thought of the idea of outsourcing CALEA requests. That is probably because I would never consider doing it. > > Perhaps we are in the minority, but we scrutinize every request of any sort to ensure it has jurisdiction and is valid. I can't even fathom the thought of trusting a third party for this. > agreed, since most of the tap-work actually requires changes on network equipment in the network you run, why would you outsource this? Especially when the taps impact forwarding performance of the platforms in question... From jlewis at lewis.org Mon Jun 10 00:48:09 2013 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 9 Jun 2013 20:48:09 -0400 (EDT) Subject: Mechanics of CALEA taps In-Reply-To: References: Message-ID: On Sun, 9 Jun 2013, Randy Fischer wrote: > Dear nanog: > > Honestly, I expect replies to this question to range between zero and none, > but I have to ask it. > > I understand the CALEA tap mechanism for most ISPs, generally, works like > this: > > * we outsource our CALEA management to company X > * we don't even know there's been a request until we've gotten a bill from > X. > > And that's the extent of it. > > Well, golly Slothrop, maybe someone else has started picking up the tab. > Would you even know? > > Is that possible? Inconceivable! That'd be like having your security system monitoring company able to eavesdrop on your house any time they want, just in case. Come to think of it, the latest greatest systems are capable of that. It sounds so stupid to me, I bet someone's doing it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From symack at gmail.com Mon Jun 10 02:05:07 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 9 Jun 2013 22:05:07 -0400 Subject: OC3/STM-1 Line Card In-Reply-To: References: Message-ID: Sorry everyone for the delayed response. Basically we are trying to setup up POPS in specific ares. Each POP should be capable of handling 1500-2000 channels or ~60-80 virutal PRIs "please bare with me". Laying down the 80K for Audiocodes 3000 with an OC interface, or even a Metaswitch would be the "big boys" way of doing. Before going any route, knowing our options are good no? Option 1: OC3 muxed down to 84 T1s -----> 7 X 12 T1s Asterisk Boxes --------> IP Option 2: Metaswitch, Audiocodes swtich Michael Loftis said: >> If you're doing internal stuff you're better off forgetting about SS7 crap, and just doing >> IP/SIP over your OC3. No transcoding, you'll get as good or better audio >> quality, and, more available channels. I would love to cut a deal with a CLEC or and ILEC to sell us a piece of their network (i.e., place our equipment at their location and cut us a piece of the signaling) but no go. Channels are their bread and butter and they are sticking to it. At $6-$15 per circuit, rolling blackout like the kind you would see in Tikrit, Iraq, no thank you.... To answer your question this is for external. We are trying to place ourselves strategically and offer a hosted PRI solution, along with maintaining our existing customer's SIP<-->PSTN network. >> If you're interfacing with the PSTN with SS7 your options are a lot more >> limited as SS7 support is fairly poor in the FOSS world. Very true!!! However, there is no one doing SIGTRAN or SS7 over IP that we know of. We are really trying to stay away from reselling someone's service, as opposed to managing our own trunks as we've been doing for over 10 years. Only now we are looking to scale up and market it. >> Most modern gear can go all the way to individual DS0's in a single >> card without a MUX of any kind. OC3/STM-1 is only like 155mbit. Please elaborate, we are not liking the MUX idea. But we're kind of between a hard spot and a rock :). Phil Fagan said: >> Nick are you trying to run these codecs on linux? Yes but whether we do it by muxing the OC to multiple T1's plugged into *, or using this thing: http://www.gl.com/OC3-OC12-analysis-emulation-card.html I could not resist.... Not sure how many people used this on deployed system. Which brings us to Option 3: Straight OC3 branched out to * with a really cool "Lightseed 1000" like interface on asterisk boxes. No hit for the MUX, not as many * boxes needed.... Life would be so good.... Cheers, N. From jra at baylink.com Mon Jun 10 04:01:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 10 Jun 2013 00:01:58 -0400 (EDT) Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: Message-ID: <27962117.7552.1370836918061.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eric Adler" > The view from my side, as both a broadcaster and a consumer of both > broadcast and 'webcast' content: My own comments were, and are, from the outside, following along cause I'll have to deal with it after they make the choices. > From what I've been led to understand in my time in broadcast*, the > decision wasn't made because of power costs but because they (the Grand > Alliance and the FCC) believed that 8VSB would work better over the US > both due to terrain and propagation differences and due to our markets of > television transmitters and need to place co-channel (same frequency) > transmitters relatively nearby with minimal interference. Indeed. The impression I acquired at the time was that that was the publicly promulgated reason, but the real one was that the people who had to pay the power bills were putting their foot down. > Some argue > the (C)OFDM would have been a better choice even taking those things into > account. Which should have been chosen based on what criteria is a > long discussion in and of itself but we've got 8VSB (at least for now). > > As for the mobile thing, I don't know if anyone had thought that far > ahead. Yup. There was a substantial amount of screaming from the engineering community, *precisely on this point*: 8VSB was *substantially* harder to receive, enough so that it wouldn't be practical to receive it mobil-ly at all, while COFDM wasn't bad at on on mobile receivers. As has been the case in nearly every such argument I can remember in the last 40 years, the engineers lost to the money men, and now all we can do is say "I toldja so". But they were, in fact, told so. TTBOMK. > It seems silly now since I had a 2" rear-projection portable NTSC > TV that was made in the mid-to-late 1980s (Sony Watchman) and now they > are trying to 'solve' the mobile delivery 'problem'. ATSC M/H adds a lot > of error correction as well as 'training data' to make the M/H stream > 'easy' to detect and decode, even with Doppler and multipath effects (see > ATSC A/153 part 2 for detail) - this reduces the data rate available for > the 'main' (A/53) data significantly and does not create nearly as much > available for the M/H (A/153) data. This sounds even sillier when you > realize that ATSC standard A/49, first published in 1993, was a "Ghost > Canceling Reference Signal for NTSC" (ghosting on NTSC is a symptom of > multipath). Yeah. > As for 'webcasting' replacing RF broadcasting, I think we're a ways out if > it will even ever happen in the general case yet alone every case. RF > broadcast is very efficient, as previously mentioned. As a broadcaster, I > push 19.393 Mbps of content 'into the air' for everyone around to receive > at once. As a consumer, I have four tuners attached to what amounts to > a few pieces of wire and I can receive roughly 80 Mbit of non-blocking > data 'through the air'. My ISP provides me a downlink speed of roughly 10 > Mbps. If I were in a larger market, I'd be able to receive even more > data (non-blocking with more tuners or blocking from my POV if I didn't > have enough tuners for every channel); even if the ISP provided downlink > speeds scaled up similarly, there would be much more data available 'through > the air'. The people who live near me have the opportunity to receive that > same 80 Mbit of data without any transit costs. Yupperoni. > Can CDNs replace some of what is now broadcast? Likely. By reducing data > rates (with better compression technologies as well as simply compressing > more) and providing content that viewers want, they could (Netflix and > others are already doing this with some content). There is, of course, > a lingering societal question about "shared viewing experiences" for > shows having set delivery schedules by broadcast. And, quite aside from broadcast networks protecting the ad revenues of their contracted affiliates -- the primary reason for most of the (from an engineering standpoint) stupidity surrounding the intersection of broadcasting and new technology -- social networking is beginning to drive this aspect, to the point where the Golden Globes stopped tape-delaying the west coast broadcast so those viewers didn't get spoiled on twitter. > Live content and local > content, however, will still be (in my opinion) best served by RF broadcast > for some time to come due to both the inherent efficiencies in the > system and the ease of localization for end-users. You bet. > * The ATSC Digital Television Standard (A/53) was developed, documented, > and formalized from the late 1980s through the mid 1990s (A/53 Part 1, > Annex A describes the history). I wasn't working in television until > 2000 or so and I wasn't doing television broadcast-related work until 2008. My production history started in 1983, though with a few years exception, I didn't have much direct connection with the transport; I was merely an (informed) observer. Thanks for your views, Eric. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From matthew at matthew.at Mon Jun 10 04:04:22 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 9 Jun 2013 21:04:22 -0700 Subject: Mechanics of CALEA taps In-Reply-To: References: Message-ID: <136A5D63-45DE-416C-B729-5D56CA3E5322@matthew.at> It is possible, and not just for "ISPs" Matthew Kaufman (Sent from my iPhone) On Jun 9, 2013, at 3:59 PM, Randy Fischer wrote: > Dear nanog: > > Honestly, I expect replies to this question to range between zero and none, > but I have to ask it. > > I understand the CALEA tap mechanism for most ISPs, generally, works like > this: > > * we outsource our CALEA management to company X > * we don't even know there's been a request until we've gotten a bill from > X. > > And that's the extent of it. > > Well, golly Slothrop, maybe someone else has started picking up the tab. > Would you even know? > > Is that possible? > > Thanks, > > Randy Fischer From rob at invaluement.com Mon Jun 10 05:00:24 2013 From: rob at invaluement.com (Rob McEwen) Date: Mon, 10 Jun 2013 01:00:24 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B4C8B8.3000006@invaluement.com> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <51B4C8B8.3000006@invaluement.com> Message-ID: <51B55D68.90906@invaluement.com> On 6/9/2013 2:26 PM, Rob McEwen wrote: > There are notable exceptions... for example, an employer is really the > owner of the mailbox, not their employee. Therefore, there is an > argument that government employees don't have "privacy rights" from the > government for their official work e-mail accounts. There are probably > several other exceptions like that. But such exceptions are a tiny > percentage of the whole. I should mention... there also "exceptions to the exceptions". While it is totally legal and ethical for a boss to snoop on his employee's e-mails (in a business), I would think it would be very unethical and illegal, for example, for the executive branch to snoop on a congressional aide's e-mail, to gain "intel" on political opponents.... even if that congressional aide were a government employee and the e-mail was a ".gov" address. But I'm not sure where those lines are drawn with regards to the US Federal Government. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From mysidia at gmail.com Mon Jun 10 06:53:28 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 10 Jun 2013 01:53:28 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <51B55D68.90906@invaluement.com> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <51B4C8B8.3000006@invaluement.com> <51B55D68.90906@invaluement.com> Message-ID: On 6/10/13, Rob McEwen wrote: > On 6/9/2013 2:26 PM, Rob McEwen wrote: > I should mention... there also "exceptions to the exceptions". While it > is totally legal and ethical for a boss to snoop on his employee's > e-mails (in a business), I would think it would be very unethical and The organization as a legal entity has the legal and moral right, but that right does not necessarily flow to any individual responsible for the daily activities in that organization, or to any individual manager or officer. Only if done in a manner that is consistent with the organization's policies and internal controls: and employees have to be informed if their private email might be discovered and shared, and under what conditions, so they can understand that e-mail has a reduced expectation of privacy. If it wasn't explained to employees, and employees are allowed to use e-mail for personal purposes or very sensitive purposes; then under some circumstances, it is questionable if it is ethical. In the most extreme case; some organization could require a vote of the board to approve administrative snooping on a mailbox. Then a "boss" snooping without the proper authorization, where the org has such rules, could be subject to being sued by the organization. In some organization, there may be employees whose 1st line manager or "boss" has no right whatsoever to snoop on mail; the organization may have internal procedures that have to be followed, for an investigation or discovery of content from email, which might require a CEO signature, not just a request from some boss to "see what's in bob's inbox". In some organizations, there might be signatures from a legal department and a security department required. There might be highly sensitive information in some employee's mailbox that is legally privileged or subject to NDA, that could place the organization at risk, if improperly disclosed to a "boss" or "manager" that did not have the need to know or security clearance for the technical details, when the boss' role is administrative. There might be encrypted mailbox content requiring multiple departments to be involved to provide the backup keys to get the decrypted version. > illegal, for example, for the executive branch to snoop on a > congressional aide's e-mail, to gain "intel" on political opponents.... Hopefully, the federal government had the foresight to require senior congressional reviews, before a request to discover a congressional aide's e-mail could be performed by a member of the executive branch... The government itself has a right to any employee's e-mail. That doesn't mean that right flows to individual people, or that senior members of the executive have a right to circumvent whatever procedures are established to ensure proper use. > even if that congressional aide were a government employee and the > e-mail was a ".gov" address. But I'm not sure where those lines are > drawn with regards to the US Federal Government. > -- > Rob McEwen -- -JH From kauto at huopio.fi Mon Jun 10 08:10:57 2013 From: kauto at huopio.fi (Kauto Huopio) Date: Mon, 10 Jun 2013 11:10:57 +0300 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: I would add opportunistic STARTTLS to all SMTP processing devices. --Kauto On Mon, Jun 10, 2013 at 12:23 AM, William Herrin wrote: > On Thu, Jun 6, 2013 at 9:28 PM, Leo Bicknell wrote: > > While there's a whole political aspect of electing people who pass > > better laws, NANOG is not a political action forum. However many > > of the people on NANOG are in positions to affect positive change > > at their respective employers. > > > > - Implement HTTPS for all services. > > - Implement PGP for e-mail. > > - Implement S/MIME for e-mail. > > - Build cloud services that encrypt on the client machine, using a key > that is only kept on the client machine. > > - Create better UI frameworks for managing keys and identities. > > - Align data retention policies with the law. > > - Scrutinize and reject defective government legal requests. > > - When allowed by law, charge law enforcement for access to data. > > +1 > > Very few of you work in jobs where the external requirements are so > well and rigidly defined that you lack the leeway to include these > sorts of efforts. You may not control the feature list but you control > the components which compose the features tasked to you. Write it in > to the things you do and give the next guy an opportunity to follow > your lead. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Kauto Huopio - kauto at huopio.fi Hansakallionkuja 12 A 1, 02780 Espoo, Finland Tel. +358 40 5008774 From eugen at leitl.org Mon Jun 10 10:08:57 2013 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 10 Jun 2013 12:08:57 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <20130610100857.GU2380@leitl.org> On Mon, Jun 10, 2013 at 11:10:57AM +0300, Kauto Huopio wrote: > I would add opportunistic STARTTLS to all SMTP processing devices. What we actually need is working opportunistic encryption in IPv6, something like http://www.inrialpes.fr/planete/people/chneuman/OE.html From jabley at hopcount.ca Fri Jun 7 15:25:36 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 7 Jun 2013 11:25:36 -0400 Subject: PGP/SSL/TLS really as secure as one thinks? In-Reply-To: <51B1F8CC.9070402@massar.ch> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F8CC.9070402@massar.ch> Message-ID: On 2013-06-07, at 11:14, Jeroen Massar wrote: > On 2013-06-07 06:50, Dan White wrote: > [..] > > A nice 'it is Friday' kind of thought.... > >> OpenPGP and other end-to-end protocols protect against all nefarious >> actors, including state entities. > > If you can't trust the entities where your data is flowing through > because you are unsure if and where they are tapping you, why do you > trust any of the crypto out there that is allowed to exist? :) Defence in depth. PGP-encrypt your transport stream and send it over TLS with client- and server-side certificate validation with a restricted CA list on each endpoint. Using IPSec. Through tor. With the plain-text littered with code words that are meaningless except to your intended recipient, taken from a pre-shared (in-person) code book that changes every day. Then your facebook sessions will be secure. Joe From dmburgess at linktechs.net Mon Jun 10 13:23:37 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 10 Jun 2013 08:23:37 -0500 Subject: Mechanics of CALEA taps References: Message-ID: <50710E9A7E64454C974049FC998EB655E230A5@03-exchange.lti.local> While its possible to do this, you would have to have a device that would not impact performance typically at every exit point, but in a perfect world it would be on the clients CPE device! Our wireless CPE's can do this. I would not that a business model to not bill until a request is completed would work due to the amount of hardware that x company would have to put out. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Randy Fischer [mailto:randy.fischer at gmail.com] Sent: Sunday, June 09, 2013 5:59 PM To: North American Network Operators Group Subject: Mechanics of CALEA taps Dear nanog: Honestly, I expect replies to this question to range between zero and none, but I have to ask it. I understand the CALEA tap mechanism for most ISPs, generally, works like this: * we outsource our CALEA management to company X * we don't even know there's been a request until we've gotten a bill from X. And that's the extent of it. Well, golly Slothrop, maybe someone else has started picking up the tab. Would you even know? Is that possible? Thanks, Randy Fischer From mpetach at netflight.com Mon Jun 10 14:39:43 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Jun 2013 07:39:43 -0700 Subject: PGP/SSL/TLS really as secure as one thinks? In-Reply-To: References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F8CC.9070402@massar.ch> Message-ID: On Fri, Jun 7, 2013 at 8:25 AM, Joe Abley wrote: > > On 2013-06-07, at 11:14, Jeroen Massar wrote: > > > On 2013-06-07 06:50, Dan White wrote: > > [..] > > > > A nice 'it is Friday' kind of thought.... > > > >> OpenPGP and other end-to-end protocols protect against all nefarious > >> actors, including state entities. > > > > If you can't trust the entities where your data is flowing through > > because you are unsure if and where they are tapping you, why do you > > trust any of the crypto out there that is allowed to exist? :) > > Defence in depth. PGP-encrypt your transport stream and send it over TLS > with client- and server-side certificate validation with a restricted CA > list on each endpoint. Using IPSec. Through tor. With the plain-text > littered with code words that are meaningless except to your intended > recipient, taken from a pre-shared (in-person) code book that changes every > day. > > Then your facebook sessions will be secure. > I was most of the way there, except I couldn't figure out how to get a pre-shared codebook to all 5,000 of my facebook friends with minimal overhead... And then it hit me...DIANETICS! Thanks to you, L. Ron Hubbard, my code distribution challenges are a thing of the past. Just keep churning out the endless volumes, and the rotating cypher-key system will last for decades! Matt (for the humour-impaired: ;-P ) From ncnet at sbcglobal.net Mon Jun 10 15:00:10 2013 From: ncnet at sbcglobal.net (Larry Stites) Date: Mon, 10 Jun 2013 08:00:10 -0700 (PDT) Subject: Rep: ncnet Message-ID: <1370876410.94065.YahooMailNeo@web181502.mail.ne1.yahoo.com> Too many of us look upon Americans as dollar chasers. This is a cruel libel, even if it is reiterated thoughtlessly by the Americans themselves.inf: http://www.wyncotkennels.com/perfctway.php6/10/2013 4:00:09 PMBest RegardsLarry Stites From trelane at trelane.net Mon Jun 10 15:16:00 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 10 Jun 2013 11:16:00 -0400 Subject: Rep: ncnet In-Reply-To: <1370876410.94065.YahooMailNeo@web181502.mail.ne1.yahoo.com> References: <1370876410.94065.YahooMailNeo@web181502.mail.ne1.yahoo.com> Message-ID: <51B5EDB0.5030905@trelane.net> On 6/10/2013 11:00 AM, Larry Stites wrote: > Too many of us look upon Americans as dollar chasers. As an Objectivist, I resemble this. I still hate having to agree with a spammer though :( Andrew From wbailey at satelliteintelligencegroup.com Mon Jun 10 15:28:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 10 Jun 2013 15:28:21 +0000 Subject: Mechanics of CALEA taps In-Reply-To: <50710E9A7E64454C974049FC998EB655E230A5@03-exchange.lti.local> References: , <50710E9A7E64454C974049FC998EB655E230A5@03-exchange.lti.local> Message-ID: The only calea intercept I watched take place was with a system made by Sandvine.. And it was pretty shocking. Sent from my Mobile Device. -------- Original message -------- From: Dennis Burgess Date: 06/10/2013 6:25 AM (GMT-08:00) To: Randy Fischer ,nanog at nanog.org Subject: RE: Mechanics of CALEA taps While its possible to do this, you would have to have a device that would not impact performance typically at every exit point, but in a perfect world it would be on the clients CPE device! Our wireless CPE's can do this. I would not that a business model to not bill until a request is completed would work due to the amount of hardware that x company would have to put out. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace -----Original Message----- From: Randy Fischer [mailto:randy.fischer at gmail.com] Sent: Sunday, June 09, 2013 5:59 PM To: North American Network Operators Group Subject: Mechanics of CALEA taps Dear nanog: Honestly, I expect replies to this question to range between zero and none, but I have to ask it. I understand the CALEA tap mechanism for most ISPs, generally, works like this: * we outsource our CALEA management to company X * we don't even know there's been a request until we've gotten a bill from X. And that's the extent of it. Well, golly Slothrop, maybe someone else has started picking up the tab. Would you even know? Is that possible? Thanks, Randy Fischer From adam.vitkovsky at swan.sk Mon Jun 10 15:36:34 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 10 Jun 2013 17:36:34 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> Message-ID: <04f701ce65f0$49f39660$dddac320$@swan.sk> >Happily, none of the companies listed are transport networks: I believe it's logical that government turned to biggest US based ISPs with request to help monitoring communication channels after 2001 events, as back in those days facebook was not around and google was not as prevalent. But to be frank I don't know what was the nature of monitoring, phone calls, internet communication, ... adam From adam.vitkovsky at swan.sk Mon Jun 10 15:36:34 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 10 Jun 2013 17:36:34 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130607132849.GR2380@leitl.org> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <20130607132849.GR2380@leitl.org> Message-ID: <04f901ce65f0$4de060f0$e9a122d0$@swan.sk> > How would you tap a few TBit/s so that you can filter it down to where you can look it at layer 7 in ASICs, and filter out something to a more manageable data rate? Well "lawful-intercept" is on by default. And you don't get to worry about the L7 and filtering/parsing -that's done by the black boxes. adam From dmburgess at linktechs.net Mon Jun 10 16:36:44 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 10 Jun 2013 11:36:44 -0500 Subject: Single AS multiple Dirverse Providers Message-ID: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks. Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in. Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From jabley at hopcount.ca Mon Jun 10 16:43:50 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 10 Jun 2013 18:43:50 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: On 2013-06-10, at 18:36, "Dennis Burgess" wrote: > I have a network that has three peers, two are at one site and the third > is geographically diverse, and there is NO connection between the two > separate networks. > > > > Currently we are announcing several /24s out one network and other /24s > out the second network, they do not overlap. To the internet this works > fine, however, providers a/b at site1 do not send us the two /24s from > site b.. We have requested them to, but have not seen them come in, > nor do we have any filters that would prohibit them from coming in. > > > > Is this normal? Yeah. > Can we receive those routes even though they are from > our own AS? You can stop them from being suppressed inbound by using "neigh x.x.x.x allowas-in" on a cisco, or "set neigh x.x.x.x allowas-in" on JunOS. > What is the "best practice" in this case? I don't know. Above seems reasonable. I've seen people join their sites with tunnels plumbed to router loopbacks in different sites and run IGPs over them before; this gives them inter-site connectivity which makes the question moot. But it involves tunnels. Joe From joelja at bogus.com Mon Jun 10 16:48:04 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 10 Jun 2013 18:48:04 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: <51B60344.6080302@bogus.com> On 6/10/13 6:36 PM, Dennis Burgess wrote: > I have a network that has three peers, two are at one site and the third > is geographically diverse, and there is NO connection between the two > separate networks. > > > > Currently we are announcing several /24s out one network and other /24s > out the second network, they do not overlap. To the internet this works > fine, however, providers a/b at site1 do not send us the two /24s from > site b.. We have requested them to, but have not seen them come in, > nor do we have any filters that would prohibit them from coming in. bgp loop detection ignores these... You need the equivalent of loops 2 (cisco) in your router config to make this work (and it will work fine) > > > Is this normal? Can we receive those routes even though they are from > our own AS? What is the "best practice" in this case? > > > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- > Second Edition " > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > Office: 314-735-0270 Website: > http://www.linktechs.net - Skype: linktechs > > > -- Create Wireless Coverage's with www.towercoverage.com > - 900Mhz - LTE - 3G - 3.65 - TV > Whitespace > > > > From joelja at bogus.com Mon Jun 10 16:52:29 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 10 Jun 2013 18:52:29 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: <51B60344.6080302@bogus.com> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60344.6080302@bogus.com> Message-ID: <51B6044D.5080700@bogus.com> On 6/10/13 6:48 PM, joel jaeggli wrote: > On 6/10/13 6:36 PM, Dennis Burgess wrote: >> I have a network that has three peers, two are at one site and the third >> is geographically diverse, and there is NO connection between the two >> separate networks. >> >> >> Currently we are announcing several /24s out one network and other /24s >> out the second network, they do not overlap. To the internet this works >> fine, however, providers a/b at site1 do not send us the two /24s from >> site b.. We have requested them to, but have not seen them come in, >> nor do we have any filters that would prohibit them from coming in. > bgp loop detection ignores these... > > You need the equivalent of loops 2 (cisco) in your router config to > make this work (and it will work fine) sorry that's juniper style e.g. routing-options { autonomous-system 64999 loops 2; } >> >> Is this normal? Can we receive those routes even though they are from >> our own AS? What is the "best practice" in this case? >> >> >> Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- >> Second Edition " >> >> Link Technologies, Inc -- Mikrotik & WISP Support Services >> >> Office: 314-735-0270 Website: >> http://www.linktechs.net - Skype: linktechs >> >> >> -- Create Wireless Coverage's with www.towercoverage.com >> - 900Mhz - LTE - 3G - 3.65 - TV >> Whitespace >> >> >> > > From jabley at hopcount.ca Mon Jun 10 16:52:57 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 10 Jun 2013 18:52:57 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: On 2013-06-10, at 18:43, Joe Abley wrote: > [...] neigh x.x.x.x allowas-in" on JunOS. Actually, I think that's JunOSe. Or however you capitalise it. Joe From nanog-post at rsuc.gweep.net Mon Jun 10 16:54:02 2013 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 10 Jun 2013 12:54:02 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: <20130610165402.GA75895@gweep.net> On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote: > I have a network that has three peers, two are at one site and the third > is geographically diverse, and there is NO connection between the two > separate networks. So, you have two islands? Technically, that would be separate ASNs as they are separatre routing policies, but the modern world has adapted. > Currently we are announcing several /24s out one network and other /24s > out the second network, they do not overlap. To the internet this works > fine, however, providers a/b at site1 do not send us the two /24s from > site b.. We have requested them to, but have not seen them come in, > nor do we have any filters that would prohibit them from coming in. > > Is this normal? Can we receive those routes even though they are from > our own AS? What is the "best practice" in this case? To prevent loops in the global Internet the BGP specification dictates this behavior, and has in all versions. Depending on your platform and theirs, you will all need to turn several knobs before you are allowed to break these rules. I would recommend that you gain more than passing familiarity with why the protocol is built this way, how it affects your use case, and what concerns you might have WRT your providers before you change the behavior for your case. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG From mpetach at netflight.com Mon Jun 10 16:58:09 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Jun 2013 09:58:09 -0700 Subject: Single AS multiple Dirverse Providers In-Reply-To: References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: On Mon, Jun 10, 2013 at 9:43 AM, Joe Abley wrote: > > On 2013-06-10, at 18:36, "Dennis Burgess" wrote: > > > I have a network that has three peers, two are at one site and the third > > is geographically diverse, and there is NO connection between the two > > separate networks. > > > > Currently we are announcing several /24s out one network and other /24s > > out the second network, they do not overlap. To the internet this works > > fine, however, providers a/b at site1 do not send us the two /24s from > > site b.. We have requested them to, but have not seen them come in, > > nor do we have any filters that would prohibit them from coming in. > > > > Is this normal? > > Yeah. > > > Can we receive those routes even though they are from > > our own AS? > > You can stop them from being suppressed inbound by using "neigh x.x.x.x > allowas-in" on a cisco, or "set neigh x.x.x.x allowas-in" on JunOS. > > > What is the "best practice" in this case? > > I don't know. Above seems reasonable. I've seen people join their sites > with tunnels plumbed to router loopbacks in different sites and run IGPs > over them before; this gives them inter-site connectivity which makes the > question moot. But it involves tunnels. > > > Joe > > > If your upstream provider runs JunOS, they may not be aware that their gear won't send you the routes by default, no matter what their policy says: "The JUNOS software does not advertise the routes learned from one external BGP (EBGP) peer back to the same EBGP peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration." (from http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/id-13225234.html#id-13255463 So, you may need to help walk them through adding the "advertise-peer-as" flag to your neighbor configurations if they use Juniper kit. Matt From patrick at ianai.net Mon Jun 10 17:08:48 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 10 Jun 2013 13:08:48 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: > however, providers a/b at site1 do not send us the two /24s from > site b.. This is probably incorrect. The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. Use the allow-as-in style command posted later in this thread to fix your router. -- TTFN, patrick On Jun 10, 2013, at 12:36 , "Dennis Burgess" wrote: > I have a network that has three peers, two are at one site and the third > is geographically diverse, and there is NO connection between the two > separate networks. > > > > Currently we are announcing several /24s out one network and other /24s > out the second network, they do not overlap. To the internet this works > fine, however, providers a/b at site1 do not send us the two /24s from > site b.. We have requested them to, but have not seen them come in, > nor do we have any filters that would prohibit them from coming in. > > > > Is this normal? Can we receive those routes even though they are from > our own AS? What is the "best practice" in this case? > > > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- > Second Edition " > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > Office: 314-735-0270 Website: > http://www.linktechs.net - Skype: linktechs > > > -- Create Wireless Coverage's with www.towercoverage.com > - 900Mhz - LTE - 3G - 3.65 - TV > Whitespace > > > From patrick at ianai.net Mon Jun 10 17:18:04 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 10 Jun 2013 13:18:04 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <20130610165402.GA75895@gweep.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> Message-ID: <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> On Jun 10, 2013, at 12:54 , Joe Provo wrote: > On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote: >> I have a network that has three peers, two are at one site and the third >> is geographically diverse, and there is NO connection between the two >> separate networks. > > So, you have two islands? Technically, that would be separate > ASNs as they are separatre routing policies, but the modern > world has adapted. Should we change the rules? I know with 64-bit ASNs mean it is tough to run out of ASNs, but not sure we really want each island to be its own AS going forward. Comments from the peanut gallery? -- TTFN, patrick >> Currently we are announcing several /24s out one network and other /24s >> out the second network, they do not overlap. To the internet this works >> fine, however, providers a/b at site1 do not send us the two /24s from >> site b.. We have requested them to, but have not seen them come in, >> nor do we have any filters that would prohibit them from coming in. >> >> Is this normal? Can we receive those routes even though they are from >> our own AS? What is the "best practice" in this case? > > To prevent loops in the global Internet the BGP specification > dictates this behavior, and has in all versions. Depending on > your platform and theirs, you will all need to turn several > knobs before you are allowed to break these rules. I would > recommend that you gain more than passing familiarity with > why the protocol is built this way, how it affects your use > case, and what concerns you might have WRT your providers > before you change the behavior for your case. > > Cheers, > > Joe > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG > From bep at whack.org Mon Jun 10 17:36:53 2013 From: bep at whack.org (Bruce Pinsky) Date: Mon, 10 Jun 2013 10:36:53 -0700 Subject: Single AS multiple Dirverse Providers In-Reply-To: References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: <51B60EB5.4090805@whack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick W. Gilmore wrote: >> however, providers a/b at site1 do not send us the two /24s from >> site b.. > > This is probably incorrect. > > The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. > > Use the allow-as-in style command posted later in this thread to fix your router. > Or maintain "standard" behavior by running a GRE tunnel between the two discontinuous sites and run iBGP over the tunnel. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2DrQACgkQE1XcgMgrtyZVWQCgzeYOVPCWdNz3LKf4AvdsZ2pR I5MAn3ojgD8zaTY4VyaR/7KdaC2YUD7B =nGK/ -----END PGP SIGNATURE----- From patrick at ianai.net Mon Jun 10 17:51:00 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 10 Jun 2013 13:51:00 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <51B60EB5.4090805@whack.org> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> Message-ID: <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> On Jun 10, 2013, at 13:36 , Bruce Pinsky wrote: > Patrick W. Gilmore wrote: > >> however, providers a/b at site1 do not send us the two /24s from > >> site b.. > > > > This is probably incorrect. > > > > The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. > > > > Use the allow-as-in style command posted later in this thread to fix your router. > Or maintain "standard" behavior by running a GRE tunnel between the two > discontinuous sites and run iBGP over the tunnel. Standard how? I don't remember any such standard, but always willing to be educated. Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :) -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mpetach at netflight.com Mon Jun 10 18:05:16 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 10 Jun 2013 11:05:16 -0700 Subject: Single AS multiple Dirverse Providers In-Reply-To: References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: On Mon, Jun 10, 2013 at 10:08 AM, Patrick W. Gilmore wrote: > > however, providers a/b at site1 do not send us the two /24s from > > site b.. > > This is probably incorrect. > > The providers are almost certainly sending you the prefixes, but your > router is dropping them due to loop detection. As noted above, if your *provider* is running JunOS, that is incorrect; by default, Juniper will not send routes out were learned from the same ASN as the one to which the neighbor is configured. http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/id-13225234.html#id-13255463 I've been bitten by this before. Matt > To answer your later question, this is the definition of 'standard' as it > is written into the RFC. > > Use the allow-as-in style command posted later in this thread to fix your > router. > > -- > TTFN, > patrick > > > On Jun 10, 2013, at 12:36 , "Dennis Burgess" > wrote: > > > I have a network that has three peers, two are at one site and the third > > is geographically diverse, and there is NO connection between the two > > separate networks. > > > > > > > > Currently we are announcing several /24s out one network and other /24s > > out the second network, they do not overlap. To the internet this works > > fine, however, providers a/b at site1 do not send us the two /24s from > > site b.. We have requested them to, but have not seen them come in, > > nor do we have any filters that would prohibit them from coming in. > > > > > > > > Is this normal? Can we receive those routes even though they are from > > our own AS? What is the "best practice" in this case? > > > > > > > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- > > Second Edition " > > > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > > > Office: 314-735-0270 Website: > > http://www.linktechs.net - Skype: linktechs > > > > > > -- Create Wireless Coverage's with www.towercoverage.com > > - 900Mhz - LTE - 3G - 3.65 - TV > > Whitespace > > > > > > > > > From bep at whack.org Mon Jun 10 18:07:19 2013 From: bep at whack.org (Bruce Pinsky) Date: Mon, 10 Jun 2013 11:07:19 -0700 Subject: Single AS multiple Dirverse Providers In-Reply-To: <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> Message-ID: <51B615D7.2090909@whack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick W. Gilmore wrote: > On Jun 10, 2013, at 13:36 , Bruce Pinsky wrote: >> Patrick W. Gilmore wrote: > >>>> however, providers a/b at site1 do not send us the two /24s from >>>> site b.. >>> >>> This is probably incorrect. >>> >>> The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. >>> >>> Use the allow-as-in style command posted later in this thread to fix your router. > >> Or maintain "standard" behavior by running a GRE tunnel between the two >> discontinuous sites and run iBGP over the tunnel. > > Standard how? I don't remember any such standard, but always willing to be educated. > > Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :) > "Standard" in the sense of continuing to reject duplicate ASN in the AS path and not using a BGP knob to allow unnatural behavior. If the networks he wishes to advertise for those sites are considered in the same ASN, there should be continuity between those sites, either physical or virtual. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2FdcACgkQE1XcgMgrtybZWQCg8CBl8406YFzmXxZgczPYk3z5 sL0AoMe26Q+6vkyOEaEHjKb1BM2/W6DO =AKb8 -----END PGP SIGNATURE----- From nanog-post at rsuc.gweep.net Mon Jun 10 18:14:05 2013 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 10 Jun 2013 14:14:05 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> Message-ID: <20130610181405.GA11687@gweep.net> On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote: > On Jun 10, 2013, at 12:54 , Joe Provo wrote: > > On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote: > > >> I have a network that has three peers, two are at one site and the third > >> is geographically diverse, and there is NO connection between the two > >> separate networks. > > > > So, you have two islands? Technically, that would be separate > > ASNs as they are separatre routing policies, but the modern > > world has adapted. > > Should we change the rules? I know with 64-bit ASNs mean it is > tough to run out of ASNs, but not sure we really want each island > to be its own AS going forward. > > Comments from the peanut gallery? I missed your proposal for loop detection to replace the current behavior in the above text. Was it compressed? I will admit that it is Not Hard for people who know what they're doing to operate well outside default and standard behavior. That's why I merely recommended that the questioner educate themselves as to the whys and wherefore before just turning knobs. I would submit that not knowing loop detection is a default and valuable feature might indicate the person should understand why and how it affects them. I don't have the hubris to believe that I understand his business needs, nor edge conditions/failure modes where a different solution might be needed. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG From accesss801 at gmail.com Mon Jun 10 18:26:33 2013 From: accesss801 at gmail.com (Dan) Date: Mon, 10 Jun 2013 12:26:33 -0600 Subject: Single AS multiple Dirverse Providers In-Reply-To: <51B615D7.2090909@whack.org> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> <51B615D7.2090909@whack.org> Message-ID: <00C04487-CBBE-4AF1-AF69-18AD6A4D79D4@gmail.com> I wouldn't look at allowing a route in with the same AS as being non-standard. Protocol behavior has to be managed by the administrator based on their own network needs and requirements. One very common tweak that comes to mind is setting next hop self for advertising ebgp learned routes to ibgp neighbors. In SP networks providing mpls vpn services its common to see the same AS used for all sites in a customer vpn and this requires that the PE routers advertise the routes and that the CE routers accept them etc. Similar to what Patrick said about GRE this could be a management nightmare just for ASN's. -Dan On Jun 10, 2013, at 12:07 PM, Bruce Pinsky wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Patrick W. Gilmore wrote: >> On Jun 10, 2013, at 13:36 , Bruce Pinsky wrote: >>> Patrick W. Gilmore wrote: >> >>>>> however, providers a/b at site1 do not send us the two /24s from >>>>> site b.. >>>> >>>> This is probably incorrect. >>>> >>>> The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. >>>> >>>> Use the allow-as-in style command posted later in this thread to fix your router. >> >>> Or maintain "standard" behavior by running a GRE tunnel between the two >>> discontinuous sites and run iBGP over the tunnel. >> >> Standard how? I don't remember any such standard, but always willing to be educated. >> >> Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :) >> > > "Standard" in the sense of continuing to reject duplicate ASN in the AS > path and not using a BGP knob to allow unnatural behavior. > > If the networks he wishes to advertise for those sites are considered in > the same ASN, there should be continuity between those sites, either > physical or virtual. > > - -- > ========= > bep > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlG2FdcACgkQE1XcgMgrtybZWQCg8CBl8406YFzmXxZgczPYk3z5 > sL0AoMe26Q+6vkyOEaEHjKb1BM2/W6DO > =AKb8 > -----END PGP SIGNATURE----- > From bicknell at ufp.org Mon Jun 10 18:42:12 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 10 Jun 2013 13:42:12 -0500 Subject: Single AS multiple Dirverse Providers In-Reply-To: References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: <7FD9CC36-A65C-4A4E-B9A8-2B9C224F7F41@ufp.org> On Jun 10, 2013, at 12:08 PM, Patrick W. Gilmore wrote: >> however, providers a/b at site1 do not send us the two /24s from >> site b.. > > This is probably incorrect. > > The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. > > Use the allow-as-in style command posted later in this thread to fix your router. I've done this many places, and find allow-as-in can be, uh, problematic. :) Everyone says to just turn it on, but it's possible to get some strange paths in your table that way, in some circumstances. For most users having a default route is just as good of a solution. Each site will have a full table minus the small number of prefixes at the other site, and a static default will get packets to your upstream that has those routes. Don't like a default? Just static the netblocks at the other side to a particular provider. Already have a default because you weren't taking full tables? You're good to go, no special config needed. Of course it depends on what your site-to-site requirements are, if they are independent islands or talking to each other with critical data all the time. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at ianai.net Mon Jun 10 19:15:30 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 10 Jun 2013 15:15:30 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <51B615D7.2090909@whack.org> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> <51B615D7.2090909@whack.org> Message-ID: <45274795-8D01-4ED6-A51D-95070F70C5FD@ianai.net> On Jun 10, 2013, at 14:07 , Bruce Pinsky wrote: > Patrick W. Gilmore wrote: > > On Jun 10, 2013, at 13:36 , Bruce Pinsky wrote: > >> Or maintain "standard" behavior by running a GRE tunnel between the two > >> discontinuous sites and run iBGP over the tunnel. > > > > Standard how? I don't remember any such standard, but always willing to be educated. > > > > Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine > > the mess of GRE that would require. (OK, not all are in the same ASN, but I like > > hyperbole. :) > > "Standard" in the sense of continuing to reject duplicate ASN in the AS > path and not using a BGP knob to allow unnatural behavior. "Natural" is a funny word here. The reason you think it is natural is that's the way it has always been done. It's not a law or nature or something ghod has wrought. It is essentially a tribal tradition. Tradition is useful, but not a reason in-and-of itself, especially in the face of reasons to break tradition. I think having 100s of 1000s of discontiguous locations is a pretty good reason. > If the networks he wishes to advertise for those sites are considered in > the same ASN, there should be continuity between those sites, either > physical or virtual. I disagree. There are times it is simply not realistic to expect continuity. The alternative is to expect "networks" with 100s or 1000s of locations to burn 100s or 1000s of ASNs. Which I think is a bit silly. Hence my question about possibly changing the rules. NB: I fully admit I am biased in this. But that doesn't mean I'm wrong. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bross at pobox.com Mon Jun 10 19:17:40 2013 From: bross at pobox.com (Brandon Ross) Date: Mon, 10 Jun 2013 15:17:40 -0400 (EDT) Subject: Single AS multiple Dirverse Providers In-Reply-To: <20130610181405.GA11687@gweep.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> <20130610181405.GA11687@gweep.net> Message-ID: On Mon, 10 Jun 2013, Joe Provo wrote: > I would submit that not knowing loop detection is a default and valuable > feature might indicate the person should understand why and how it > affects them. And I would further submit that the lack of deep protocol knowledge is a good reason to NOT F**K with it! Why is just getting another ASN not the preferred option here? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From patrick at ianai.net Mon Jun 10 19:22:41 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 10 Jun 2013 15:22:41 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <20130610181405.GA11687@gweep.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> <20130610181405.GA11687@gweep.net> Message-ID: <2B2F57F4-9B55-4DB3-960E-21EAF96F3D0F@ianai.net> On Jun 10, 2013, at 14:14 , Joe Provo wrote: > On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote: >> On Jun 10, 2013, at 12:54 , Joe Provo wrote: >>> On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote: >>>> I have a network that has three peers, two are at one site and the third >>>> is geographically diverse, and there is NO connection between the two >>>> separate networks. >>> >>> So, you have two islands? Technically, that would be separate >>> ASNs as they are separatre routing policies, but the modern >>> world has adapted. >> >> Should we change the rules? I know with 64-bit ASNs mean it is >> tough to run out of ASNs, but not sure we really want each island >> to be its own AS going forward. >> >> Comments from the peanut gallery? > > I missed your proposal for loop detection to replace the current > behavior in the above text. Was it compressed? Was not compressed. Don't want to take out loop detection in general. If you are running an island, it is up to you to ensure that island is specifically configured. This makes it no different than lots of other "weird" things on the 'Net. (I put weird in quotes because weird implies out of the ordinary, but there are probably more weird things than "normal" things these days.) > I will admit that it is Not Hard for people who know what > they're doing to operate well outside default and standard > behavior. That's why I merely recommended that the questioner > educate themselves as to the whys and wherefore before just > turning knobs. I would submit that not knowing loop detection > is a default and valuable feature might indicate the person > should understand why and how it affects them. I don't have > the hubris to believe that I understand his business needs, > nor edge conditions/failure modes where a different solution > might be needed. All good points. Is it enough to keep the standard? Or should the standard have a specific carve out, e.g. for stub networks only, not allowing islands to provide transit. Just a straw man. Or we can keep it like it is today, non-standard and let people who know what they are doing violate it at their own peril. The problem with the latter is some ISPs point to standards as if there is no other possible way to do things. Which makes it difficult to be someone who knowingly violates a standard. Anyway, just wondering how others felt. -- TTFN, patrick From job.snijders at atrato.com Mon Jun 10 19:23:35 2013 From: job.snijders at atrato.com (Job Snijders) Date: Mon, 10 Jun 2013 21:23:35 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: <45274795-8D01-4ED6-A51D-95070F70C5FD@ianai.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> <51B615D7.2090909@whack.org> <45274795-8D01-4ED6-A51D-95070F70C5FD@ianai.net> Message-ID: <835D1CC6-CA40-4C39-939A-B444291A2869@atrato.com> Hi, > The alternative is to expect "networks" with 100s or 1000s of locations to burn 100s or 1000s of ASNs. Which I think is a bit silly. Hence my question about possibly changing the rules. I see no issue with that, we have an ASN pool of roughly 4294967280 ASNs. There is no shortage. Also BCP6 section 5 [1] would support the philosophy to just get more ASNs when you need to manage multiple islands. Kind regards, Job [1] - http://tools.ietf.org/html/bcp6#section-5 From patrick at ianai.net Mon Jun 10 19:37:23 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 10 Jun 2013 15:37:23 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <835D1CC6-CA40-4C39-939A-B444291A2869@atrato.com> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> <51B615D7.2090909@whack.org> <45274795-8D01-4ED6-A51D-95070F70C5FD@ianai.net> <835D1CC6-CA40-4C39-939A-B444291A2869@atrato.com> Message-ID: <3E61A1F1-F349-4270-81A0-C04F4DE2B2DB@ianai.net> On Jun 10, 2013, at 15:23 , Job Snijders wrote: >> The alternative is to expect "networks" with 100s or 1000s of locations to burn 100s or 1000s of ASNs. Which I think is a bit silly. Hence my question about possibly changing the rules. > > I see no issue with that, we have an ASN pool of roughly 4294967280 ASNs. There is no shortage. Also BCP6 section 5 [1] would support the philosophy to just get more ASNs when you need to manage multiple islands. Ever tried to get a single peer set up sessions in 50+ places with 50+ ASNs? Neither have I. Nor do I plan to try any time soon. Anyway, looks like the comments lean towards "leave it as it is", and some people will knowingly violate the rules, as has been done since the Internet began. -- TTFN, patrick From nanog-post at rsuc.gweep.net Mon Jun 10 19:46:20 2013 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 10 Jun 2013 15:46:20 -0400 Subject: Single AS multiple Dirverse Providers In-Reply-To: <2B2F57F4-9B55-4DB3-960E-21EAF96F3D0F@ianai.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> <20130610181405.GA11687@gweep.net> <2B2F57F4-9B55-4DB3-960E-21EAF96F3D0F@ianai.net> Message-ID: <20130610194620.GA1630@gweep.net> On Mon, Jun 10, 2013 at 03:22:41PM -0400, Patrick W. Gilmore wrote: > On Jun 10, 2013, at 14:14 , Joe Provo wrote: > > On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote: > >> On Jun 10, 2013, at 12:54 , Joe Provo wrote: > >>> On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote: > > >>>> I have a network that has three peers, two are at one site and the third > >>>> is geographically diverse, and there is NO connection between the two > >>>> separate networks. > >>> > >>> So, you have two islands? Technically, that would be separate > >>> ASNs as they are separatre routing policies, but the modern > >>> world has adapted. > >> > >> Should we change the rules? I know with 64-bit ASNs mean it is > >> tough to run out of ASNs, but not sure we really want each island > >> to be its own AS going forward. > >> > >> Comments from the peanut gallery? > > > > I missed your proposal for loop detection to replace the current > > behavior in the above text. Was it compressed? > > Was not compressed. Don't want to take out loop detection in > general. If you are running an island, it is up to you to ensure > that island is specifically configured. So, you like loop detection but you don't like how it is implemtned? Then I ask again for your suggestion for BGPv5. > This makes it no different than lots of other "weird" things on > the 'Net. (I put weird in quotes because weird implies out of the > ordinary, but there are probably more weird things than "normal" > things these days.) Handwave without data meant to belittle the loop detection concern. "Probably" and "Lots of" are nice rhetorical dodges, but they work better in a conference hall. Let's keep this text to real data. > > I will admit that it is Not Hard for people who know what > > they're doing to operate well outside default and standard > > behavior. That's why I merely recommended that the questioner > > educate themselves as to the whys and wherefore before just > > turning knobs. I would submit that not knowing loop detection > > is a default and valuable feature might indicate the person > > should understand why and how it affects them. I don't have > > the hubris to believe that I understand his business needs, > > nor edge conditions/failure modes where a different solution > > might be needed. > > All good points. > > Is it enough to keep the standard? Or should the standard have a > specific carve out, e.g. for stub networks only, not allowing islands > to provide transit. Just a straw man. I'd be leery of attempting to add anything into the protocol spec that doesn't have an alternative for loop detection. > Or we can keep it like it is today, non-standard and let people > who know what they are doing violate it at their own peril. ...like much of the rest of the 'net: "know what you're doing". > The problem with the latter is some ISPs point to standards as > if there is no other possible way to do things. Which makes it > difficult to be someone who knowingly violates a standard. I'll point out that in this case, it only matters for the relationship between the island AS and its immediate neighbors; if I'm paying for service that doesn't get me what I want, I vote with my wallet (as we've alreays done). You skip the obvious route; we write a BCP for "Operation of BGP Islands: effective ASN reuse". Some will like it, some will throw stones, and some will insist that it just get folded into an update to RFC4271. Interestingly, a quick re-review of BCP126 doesn't tip its toes into these waters, but there might be room to insert it there. > Anyway, just wondering how others felt. You like to remind everyone (when convenient) that you don't run a "network" - perhaps It would be nice to hear if anyone who runs *networks* thinks they can discard AS_PATH based loop detection and they want to cook up Some Other Way for BGPv5. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG From bicknell at ufp.org Mon Jun 10 19:47:33 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 10 Jun 2013 14:47:33 -0500 Subject: Single AS multiple Dirverse Providers In-Reply-To: <2B2F57F4-9B55-4DB3-960E-21EAF96F3D0F@ianai.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> <20130610181405.GA11687@gweep.net> <2B2F57F4-9B55-4DB3-960E-21EAF96F3D0F@ianai.net> Message-ID: <013F3DA4-1864-4AC9-BB51-7096656D2459@ufp.org> On Jun 10, 2013, at 2:22 PM, Patrick W. Gilmore wrote: > Is it enough to keep the standard? Or should the standard have a specific carve out, e.g. for stub networks only, not allowing islands to provide transit. Just a straw man. For the moment I'm not going to make a statement one way or another if this should be enshrined in an RFC or not... I would like to be able to apply a route map to "allow as in" behavior: ip prefix-list SPECIAL permit 192.168.0.0/24 ! route-map SAFETY permit 10 match ip prefix-list SPECIAL set community no-export ! router bgp XXX neighbor a.b.c.d allowas-in route-map SAFETY This is a belt and suspenders approach; first you can limit this behavior to only the netblocks you use at other locations, and be extra safe by marking them no-export on the way in. Implementation should be easy, anything that would normally be rejected as an AS-Path loop gets fed into the route-map instead. This would mitigate almost all of the bad effects I can think of that can happen when the network and/or its upstreams fail to properly apply filters and all the sudden there are a lot more routes "looping" than should be, and no mechanism to stop them anymore! :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From bross at pobox.com Mon Jun 10 21:27:35 2013 From: bross at pobox.com (Brandon Ross) Date: Mon, 10 Jun 2013 17:27:35 -0400 (EDT) Subject: Single AS multiple Dirverse Providers In-Reply-To: <3E61A1F1-F349-4270-81A0-C04F4DE2B2DB@ianai.net> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> <51B615D7.2090909@whack.org> <45274795-8D01-4ED6-A51D-95070F70C5FD@ianai.net> <835D1CC6-CA40-4C39-939A-B444291A2869@atrato.com> <3E61A1F1-F349-4270-81A0-C04F4DE2B2DB@ianai.net> Message-ID: On Mon, 10 Jun 2013, Patrick W. Gilmore wrote: > Ever tried to get a single peer set up sessions in 50+ places with 50+ ASNs? I would submit that it's very likely that someone setting up 50+ places will have gained expert level knowledge of BGP and will understand the compromises they are making by "breaking the rules". I think the point is that if this is your first rodeo, perhaps you should stick with the script. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From dmburgess at linktechs.net Mon Jun 10 21:50:50 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 10 Jun 2013 16:50:50 -0500 Subject: Single AS multiple Dirverse Providers References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <51B60EB5.4090805@whack.org> <16F2DCC0-2F77-4E0F-978F-6EA7066F414A@ianai.net> <51B615D7.2090909@whack.org> <45274795-8D01-4ED6-A51D-95070F70C5FD@ianai.net> <835D1CC6-CA40-4C39-939A-B444291A2869@atrato.com> <3E61A1F1-F349-4270-81A0-C04F4DE2B2DB@ianai.net> Message-ID: <50710E9A7E64454C974049FC998EB655E23134@03-exchange.lti.local> Just to update everyone.. Already had the allowas-in setup, the end result is that the ISPs in question tier2 team did not know that they block inbound updates from their upstream(peers) from known ranges inside their network. So, the upstream was blocking the customer prefix as they thought they should only receive that block from our peer with them, vs. receiving those from the "net" Recently, they fixed their filters on their peers and we have now received the /24s in question. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Brandon Ross [mailto:bross at pobox.com] Sent: Monday, June 10, 2013 4:28 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Single AS multiple Dirverse Providers On Mon, 10 Jun 2013, Patrick W. Gilmore wrote: > Ever tried to get a single peer set up sessions in 50+ places with 50+ ASNs? I would submit that it's very likely that someone setting up 50+ places will have gained expert level knowledge of BGP and will understand the compromises they are making by "breaking the rules". I think the point is that if this is your first rodeo, perhaps you should stick with the script. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From surfer at mauigateway.com Mon Jun 10 23:36:32 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 10 Jun 2013 16:36:32 -0700 Subject: PRISM: NSA/FBI Internet data mining project Message-ID: <20130610163632.D48395EB@resin04.mta.everyone.net> Funny, sort of. The guy was residing in Hawaii. Apologies for the long URLs... Report: NSA contract worker is surveillance source: http://thegardenisland.com/news/state-and-regional/report-nsa-contract-worker-is-surveillance-source/article_2a88ec60-f99c-54a7-8c13-13f6852ccca6.html Hawaii real estate agent: Snowden left on May 1: http://thegardenisland.com/news/state-and-regional/hawaii-real-estate-agent-snowden-left-on-may/article_099ec0db-a823-56a0-8471-af8d7ef16e1b.html funny as well! NSA claims know-how to ensure no illegal spying: http://thegardenisland.com/news/state-and-regional/nsa-claims-know-how-to-ensure-no-illegal-spying/article_ec623964-d23a-53c6-aeb0-14bf325a7f3c.html scott From web at typo.org Mon Jun 10 23:42:08 2013 From: web at typo.org (Wayne E Bouchard) Date: Mon, 10 Jun 2013 16:42:08 -0700 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130610163632.D48395EB@resin04.mta.everyone.net> References: <20130610163632.D48395EB@resin04.mta.everyone.net> Message-ID: <20130610234208.GA94669@wakko.typo.org> On Mon, Jun 10, 2013 at 04:36:32PM -0700, Scott Weeks wrote: > NSA claims know-how to ensure no illegal spying: > http://thegardenisland.com/news/state-and-regional/nsa-claims-know-how-to-ensure-no-illegal-spying/article_ec623964-d23a-53c6-aeb0-14bf325a7f3c.html > > scott "We're the government. Trust us!" --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jlewis at lewis.org Tue Jun 11 01:05:31 2013 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 10 Jun 2013 21:05:31 -0400 (EDT) Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> References: <30675563.7312.1370561742606.JavaMail.root@benjamin.baylink.com> <2D0AF14BA6FB334988BC1F5D4FC38CB826CC5460FF@EXCHMBX.hq.nac.net> Message-ID: On Thu, 6 Jun 2013, Alex Rubenstein wrote: >> I've always just assumed that if it's in electronic form, someone else is either >> reading it now, has already read it, or will read it as soon as I walk away from >> the screen. > > So, you are comfortable just giving up your right to privacy? It's just the way it is? If you're sending it across the internet in the clear, it's not private. If you want privacy, use reasonable encryption. Even with that though, unless you take other precautions, they know who [IP] you're talking to, if they want. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jaydesh9 at gmail.com Tue Jun 11 02:49:04 2013 From: jaydesh9 at gmail.com (Jayram A. Deshpande) Date: Mon, 10 Jun 2013 19:49:04 -0700 Subject: Bogons filtering Message-ID: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> Hello, With IPv4 being almost exhausted[1] , I am curious to know how many net admins have the Bogon filtering ACLs still hanging around ? Google even gave me this expired Internet Draft [2] that seems to have been intended as a BCP. Regards, -Jay. [1] https://www.arin.net/resources/request/ipv4_countdown.html [2] https://tools.ietf.org/id/draft-vegoda-no-more-unallocated-slash8s-01.txt -- "Subvert the paradigm." - C.K. Prahlad -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fergdawgster at gmail.com Tue Jun 11 02:54:13 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 10 Jun 2013 19:54:13 -0700 Subject: Bogons filtering In-Reply-To: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> References: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> Message-ID: Well, there's this from 2012: https://www.team-cymru.org/Services/Bogons/ - ferg On Mon, Jun 10, 2013 at 7:49 PM, Jayram A. Deshpande wrote: Hello, > > > With IPv4 being almost exhausted[1] , I am curious to know how many net > admins have the Bogon filtering ACLs still hanging around ? > > Google even gave me this expired Internet Draft [2] that seems to have > been intended as a BCP. > > > Regards, > -Jay. > > > [1] https://www.arin.net/resources/request/ipv4_countdown.html > [2] > https://tools.ietf.org/id/draft-vegoda-no-more-unallocated-slash8s-01.txt > > -- > "Subvert the paradigm." - C.K. Prahlad > > > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From arturo.servin at gmail.com Tue Jun 11 02:57:39 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 10 Jun 2013 23:57:39 -0300 Subject: Bogons filtering In-Reply-To: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> References: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> Message-ID: <51B69223.2070501@gmail.com> This draft is now RFC6441 and BCP 171 http://tools.ietf.org/html/rfc6441 .as On 6/10/13 11:49 PM, Jayram A. Deshpande wrote: > Hello, > > > With IPv4 being almost exhausted[1] , I am curious to know how many net admins have the Bogon filtering ACLs still hanging around ? > > Google even gave me this expired Internet Draft [2] that seems to have been intended as a BCP. > > > Regards, > -Jay. > > > [1] https://www.arin.net/resources/request/ipv4_countdown.html > [2] https://tools.ietf.org/id/draft-vegoda-no-more-unallocated-slash8s-01.txt > From cb.list6 at gmail.com Tue Jun 11 03:14:55 2013 From: cb.list6 at gmail.com (cb.list6) Date: Mon, 10 Jun 2013 20:14:55 -0700 Subject: Bogons filtering In-Reply-To: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> References: <436F2658-8248-486A-BE4A-11BEB12BB62A@gmail.com> Message-ID: On Jun 10, 2013 7:50 PM, "Jayram A. Deshpande" wrote: > > Hello, > > > With IPv4 being almost exhausted[1] , I am curious to know how many net admins have the Bogon filtering ACLs still hanging around ? > No bogon filters here. Retiring bogon filters is great, one less process to maintain. > Google even gave me this expired Internet Draft [2] that seems to have been intended as a BCP. > > > Regards, > -Jay. > > > [1] https://www.arin.net/resources/request/ipv4_countdown.html > [2] https://tools.ietf.org/id/draft-vegoda-no-more-unallocated-slash8s-01.txt > > -- > "Subvert the paradigm." - C.K. Prahlad > > From tvhawaii at shaka.com Tue Jun 11 05:00:48 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 10 Jun 2013 19:00:48 -1000 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) References: <27962117.7552.1370836918061.JavaMail.root@benjamin.baylink.com> Message-ID: Jay Ashworth wrote: sniip > > And, quite aside from broadcast networks protecting the ad revenues > of their contracted affiliates -- the primary reason for most of the > (from an engineering standpoint) stupidity surrounding the intersection > of broadcasting and new technology -- social networking is beginning > to drive this aspect, to the point where the Golden Globes stopped > tape-delaying the west coast broadcast so those viewers didn't get > spoiled on twitter. > Thanks for your views, Eric. > > Cheers, > -- jra The Sportsbar I deal with has purchased every one of the Ultimate Fighting Championships PPV events (161). Now, after UFC's deal with FOX, the prelims for any fight on FUEL are only shown on...FACEBOOK. Bad Craziness as Hunter Thompson would have said. Thanks for everyone's comments. --Michael From rajiva at cisco.com Tue Jun 11 11:36:12 2013 From: rajiva at cisco.com (Rajiv Asati (rajiva)) Date: Tue, 11 Jun 2013 11:36:12 +0000 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: References: <27962117.7552.1370836918061.JavaMail.root@benjamin.baylink.com>, Message-ID: This is very interesting and insightful. While the broadcasting would seem more efficient (and cheaper in many respect) than webcasting for the live content, the former can't quite serve multiple devices with varying form-factors with the same efficiency. The latter can. Isn't that a key differentiation? Cheers, Rajiv Sent from my Phone On Jun 11, 2013, at 1:03 AM, "Michael Painter" wrote: > Jay Ashworth wrote: > sniip >> And, quite aside from broadcast networks protecting the ad revenues >> of their contracted affiliates -- the primary reason for most of the >> (from an engineering standpoint) stupidity surrounding the intersection >> of broadcasting and new technology -- social networking is beginning >> to drive this aspect, to the point where the Golden Globes stopped >> tape-delaying the west coast broadcast so those viewers didn't get >> spoiled on twitter. >> Thanks for your views, Eric. >> Cheers, >> -- jra > > The Sportsbar I deal with has purchased every one of the Ultimate Fighting Championships PPV events (161). > Now, after UFC's deal with FOX, the prelims for any fight on FUEL are only shown on...FACEBOOK. > > Bad Craziness as Hunter Thompson would have said. > > Thanks for everyone's comments. > --Michael > From berni at birkenwald.de Tue Jun 11 15:39:32 2013 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 11 Jun 2013 15:39:32 +0000 (UTC) Subject: chargen is the new DDoS tool? Message-ID: Heya everyone, we have been getting reports lately about unsecured UDP chargen servers in our network being abused for reflection attacks with spoofed sources http://en.wikipedia.org/wiki/Character_Generator_Protocol | In the UDP implementation of the protocol, the server sends a UDP | datagram containing a random number (between 0 and 512) of characters | every time it receives a datagram from the connecting host. Any data | received by the server is discarded. We are seeing up to 1500 bytes of response though. This seems to be something new. There aren't a lot of systems in our network responding to chargen, but those that do have a 15x amplification factor and generate more traffic than we have seen with abused open resolvers. Anyone else seeing that? Anyone who can think of a legitimate use of chargen/udp these days? Fortunately I can't, so we're going to drop 19/udp at the border within the next hours. Regards, Bernhard From bruns at 2mbit.com Tue Jun 11 16:06:36 2013 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 11 Jun 2013 10:06:36 -0600 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: <51B74B0C.3000704@2mbit.com> On 6/11/13 9:39 AM, Bernhard Schmidt wrote: > Heya everyone, > > we have been getting reports lately about unsecured UDP chargen servers > in our network being abused for reflection attacks with spoofed sources > > http://en.wikipedia.org/wiki/Character_Generator_Protocol > > | In the UDP implementation of the protocol, the server sends a UDP > | datagram containing a random number (between 0 and 512) of characters > | every time it receives a datagram from the connecting host. Any data > | received by the server is discarded. > > We are seeing up to 1500 bytes of response though. > > This seems to be something new. There aren't a lot of systems in our > network responding to chargen, but those that do have a 15x > amplification factor and generate more traffic than we have seen with > abused open resolvers. > > Anyone else seeing that? Anyone who can think of a legitimate use of > chargen/udp these days? Fortunately I can't, so we're going to drop > 19/udp at the border within the next hours. > *checks her calendar* I for a second worried I might have woken up from a 20 year long dream.... Are these like machines time forgot or just really bag configuration choices? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From berni at birkenwald.de Tue Jun 11 16:10:21 2013 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 11 Jun 2013 16:10:21 +0000 (UTC) Subject: chargen is the new DDoS tool? References: <51B74B0C.3000704@2mbit.com> Message-ID: Brielle Bruns wrote: Hey, >> we have been getting reports lately about unsecured UDP chargen servers >> in our network being abused for reflection attacks with spoofed sources >> >> http://en.wikipedia.org/wiki/Character_Generator_Protocol >> >> | In the UDP implementation of the protocol, the server sends a UDP >> | datagram containing a random number (between 0 and 512) of characters >> | every time it receives a datagram from the connecting host. Any data >> | received by the server is discarded. >> >> We are seeing up to 1500 bytes of response though. >> >> This seems to be something new. There aren't a lot of systems in our >> network responding to chargen, but those that do have a 15x >> amplification factor and generate more traffic than we have seen with >> abused open resolvers. >> >> Anyone else seeing that? Anyone who can think of a legitimate use of >> chargen/udp these days? Fortunately I can't, so we're going to drop >> 19/udp at the border within the next hours. >> > > *checks her calendar* I for a second worried I might have woken up from > a 20 year long dream.... > > Are these like machines time forgot or just really bag configuration > choices? Not sure. The affected IPs are strongly clustered around the Faculty of Medicine, so from experience I would assume stone-old boxes. But not sure yet. Bernhard From michael at winkstreaming.com Tue Jun 11 16:10:48 2013 From: michael at winkstreaming.com (Michael McConnell) Date: Tue, 11 Jun 2013 10:10:48 -0600 Subject: Webcasting as a replacement for traditional broadcasting (was Re: Wackie 'ol Friday) In-Reply-To: <20371516.7332.1370620430594.JavaMail.root@benjamin.baylink.com> References: <20371516.7332.1370620430594.JavaMail.root@benjamin.baylink.com> Message-ID: <21EC1E1A-7E11-4478-8B55-7A9F63FE13CF@winkstreaming.com> On Jun 7, 2013, at 9:53 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Michael Painter" > >> Anyone besides jra remember the last Super Bowl? >> Better this year? Worse? >> I'm sure whomever is listening in would like to know as well. >> >> http://www.multichannel.com/blogs/translation-please/multicast-unicast-and-super-bowl-problem > > Well, in fact, the most recent Massive Failure was the webcast of the > Concert For Boston, on 5/31. They were using a vendor called LiveAlliance.tv, > who did not appear to be farming it out to Limelight or Akamai or Youtube, a.. > far as I could tell, and they apparently only figured for a scale 5 audience, > and then got more than 500k attempts. Such a common story. .. > > They got rescued by a vendor named Fast Hockey who are an amateur hockey > webcast aggregator, I gather, and *are* an Akamai client. > > My estimation is that the reason that webcasting will never completely > replace broadcasting is that -- because it is mostly unicast -- its > inherent complexity factor is a) orders of magnitude higher than bcast, and > b) *proportional to the number of viewers*. Like Linux, that doesn't scale. This is the primary reason companies including Internap, Peer1 and XO (The list goes on and on, and includes several company that only provide CDN services) all used to run their own CDN networks and now all three have outsourced this CDN service / sold their customers to Limelight. Edgecast even sold off all their services in Asia and just runs a US based CDN. The general policy in data centres has been 30 - 40% utilisation to allow for bursting and unexpected temporary increases, in CDN its more like 5 - 10% especially when you are a CDN for hire you really can't make any predictions about what your customers might do. Its common for CDN's to have entire rack's sitting powered off that only need to be powered up to join the cluster, our company has multiple full racks per data centre just a alert to the NOC staff or email away from being turned on. > > And broadcasters are not prone to think of the world in a view where you > have to provide technical support to people just to watch your show. > > "He's at the 40... the 30... the 20... this is gonna be the Super Bowl, > folks... the 10... [buffering]" > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com From koalafil at gmail.com Tue Jun 11 13:11:01 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Tue, 11 Jun 2013 15:11:01 +0200 Subject: Call for Papers: RIPE 67 Message-ID: <4FA239C7-519B-475F-8458-683AF64A0E4A@gmail.com> Dear NANOG Community, RIPE Programme Commitee is now seeking proposals for RIPE 67 that will take place in Athens during 14-18 October 2013. Please find the CFP below and note the submission deadline: 4 August. We hope to see your contributions towards a successful programme with Plenary, BoF and Tutorial sessions. If you have any questions, you can contact us at pc [at] ripe [dot] net. Kind regards Filiz Yilmaz Chair, the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc http://www.ripe.net/ripe/meetings/ripe-meetings --------------------------------------------------- Call for Papers: RIPE 67 A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 67 will take place on 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and Tutorial sessions at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data center technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the Plenary, the RIPE PC also offers several time slots for ?Lightning Talks? which are selected immediately before or during the conference. The following requirements apply: - Proposals for Plenary talks, BoFs, Panels and Tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system at: https://ripe67.ripe.net/submit-topic/ Proposals submitted after this date will be considered on a space-available basis. - Presenters should indicate how much time they will require (30 minutes for Plenary talks is a common maximum duration, although some talks can be longer). - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description as well as names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most if not all presenters/panelists will be physically present at the RIPE meeting. - Tutorials are sessions with educational content and are alotted about 2 hours. - BOFs (Birds of a Feather sessions) are informal gatherings on topics of shared interest among RIPE Meeting attendees. Technical facilities and logistical support are limited and provided based on best effort and availability. - Lightning talks should also be submitted using the meeting submission system. They must be short (10 minutes maximum) and often involve more timely topics. They can be submitted at any time. The allocation of lightning talk slots will be announced one day prior to the relevant session. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. ------------------------------------------------------------ From vladg at cmu.edu Tue Jun 11 15:58:57 2013 From: vladg at cmu.edu (Vlad Grigorescu) Date: Tue, 11 Jun 2013 15:58:57 +0000 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: <1202BE242E080642B0CD0AD0A03E8552C88F17@PGH-MSGMB-03.andrew.ad.cmu.edu> We got hit with this in September. UDP/19 became our most busiest port overnight. Most of the systems participating were printers. We dropped it at the border, and had no complaints or ill effects. ?-Vlad Grigorescu Carnegie Mellon University On Jun 11, 2013, at 11:39 AM, Bernhard Schmidt wrote: > Heya everyone, > > we have been getting reports lately about unsecured UDP chargen servers > in our network being abused for reflection attacks with spoofed sources > > http://en.wikipedia.org/wiki/Character_Generator_Protocol > > | In the UDP implementation of the protocol, the server sends a UDP > | datagram containing a random number (between 0 and 512) of characters > | every time it receives a datagram from the connecting host. Any data > | received by the server is discarded. > > We are seeing up to 1500 bytes of response though. > > This seems to be something new. There aren't a lot of systems in our > network responding to chargen, but those that do have a 15x > amplification factor and generate more traffic than we have seen with > abused open resolvers. > > Anyone else seeing that? Anyone who can think of a legitimate use of > chargen/udp these days? Fortunately I can't, so we're going to drop > 19/udp at the border within the next hours. > > Regards, > Bernhard From oliver.borchert at nist.gov Tue Jun 11 16:47:44 2013 From: oliver.borchert at nist.gov (Borchert, Oliver) Date: Tue, 11 Jun 2013 12:47:44 -0400 Subject: NIST - BGP-SRx now based on Quagga 0.99.22 Message-ID: For all that are interested in NIST's RPKI prefix/origin validation reference implementation for Quagga (BGPSRx / QuaggaSRx), we merged the code from Quagga 0.99.16 to be based on Quagga 0.99.22. The code is available at http://www-x.antd.nist.gov/bgpsrx For questions or comments don't hesitate to contact us at bgpsrx-dev at nist.gov Thanks, Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 From charles-lists at knownelement.com Tue Jun 11 17:19:27 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Tue, 11 Jun 2013 12:19:27 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: Hmmm. Do you not run a default deny at your border, which would catch this sort of thing? Granted thats not always possible I suppose. Maybe block all UDP you dont specifically need? Do you have an ids/ips? If not, look at SecurityOnion on a SPAN port, it will provide great insight into whats happening. Generally these sort of legacy services are only used for malicious activity and will light up an ids/ips like a Christmas tree. They must be old boxes. I cant think of any recent os distributions which would even have these services listening, let alone installed. Bernhard Schmidt wrote: >Heya everyone, > >we have been getting reports lately about unsecured UDP chargen servers >in our network being abused for reflection attacks with spoofed sources > >http://en.wikipedia.org/wiki/Character_Generator_Protocol > >| In the UDP implementation of the protocol, the server sends a UDP >| datagram containing a random number (between 0 and 512) of characters >| every time it receives a datagram from the connecting host. Any data >| received by the server is discarded. > >We are seeing up to 1500 bytes of response though. > >This seems to be something new. There aren't a lot of systems in our >network responding to chargen, but those that do have a 15x >amplification factor and generate more traffic than we have seen with >abused open resolvers. > >Anyone else seeing that? Anyone who can think of a legitimate use of >chargen/udp these days? Fortunately I can't, so we're going to drop >19/udp at the border within the next hours. > >Regards, >Bernhard -- Charles Wyble charles at knownelement.com / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From streiner at cluebyfour.org Tue Jun 11 18:55:18 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 11 Jun 2013 14:55:18 -0400 (EDT) Subject: chargen is the new DDoS tool? In-Reply-To: <1202BE242E080642B0CD0AD0A03E8552C88F17@PGH-MSGMB-03.andrew.ad.cmu.edu> References: <1202BE242E080642B0CD0AD0A03E8552C88F17@PGH-MSGMB-03.andrew.ad.cmu.edu> Message-ID: On Tue, 11 Jun 2013, Vlad Grigorescu wrote: > We got hit with this in September. UDP/19 became our most busiest port > overnight. Most of the systems participating were printers. We dropped > it at the border, and had no complaints or ill effects. Dropping the TCP and UDP "small services" like echo (not ICMP echo), chargen and discard as part of default firewall / filter policies probably isn't a bad idea. Those services used to be enabled by default on Cisco routers, but that hasn't been since probably around 11.3 (mid-late 90s). Other than providing another DDoS vector, I'm not aware of any legitimate reason to keep these services running and accessible. As always, YMMV. jms From bicknell at ufp.org Tue Jun 11 19:13:15 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 11 Jun 2013 14:13:15 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: On Jun 11, 2013, at 10:39 AM, Bernhard Schmidt wrote: > This seems to be something new. There aren't a lot of systems in our > network responding to chargen, but those that do have a 15x > amplification factor and generate more traffic than we have seen with > abused open resolvers. The number is non-zero? In 2013? While blocking it at your border is probably a fine way of mitigating the problem, I would recommend doing an internal nmap scan for such things, finding the systems that respond, and talking with their owners. Please report back to NANOG after talking to them letting us know if the owners were still using SunOS 4.x boxes for some reason, had accidentally enabled chargen, or if some malware had set up the servers. Inquiring minds would like to know! -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dedelman at iname.com Tue Jun 11 19:38:45 2013 From: dedelman at iname.com (David Edelman) Date: Tue, 11 Jun 2013 15:38:45 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: <016d01ce66db$4b433610$e1c9a230$@iname.com> I can just see someone spoofing a packet from victimA port 7/UDP to victimB port 19/UDP. --Dave -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Tuesday, June 11, 2013 3:13 PM To: Bernhard Schmidt Cc: nanog at nanog.org Subject: Re: chargen is the new DDoS tool? On Jun 11, 2013, at 10:39 AM, Bernhard Schmidt wrote: > This seems to be something new. There aren't a lot of systems in our > network responding to chargen, but those that do have a 15x > amplification factor and generate more traffic than we have seen with > abused open resolvers. The number is non-zero? In 2013? While blocking it at your border is probably a fine way of mitigating the problem, I would recommend doing an internal nmap scan for such things, finding the systems that respond, and talking with their owners. Please report back to NANOG after talking to them letting us know if the owners were still using SunOS 4.x boxes for some reason, had accidentally enabled chargen, or if some malware had set up the servers. Inquiring minds would like to know! -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From Valdis.Kletnieks at vt.edu Tue Jun 11 20:10:30 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 11 Jun 2013 16:10:30 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: Your message of "Tue, 11 Jun 2013 15:38:45 -0400." <016d01ce66db$4b433610$e1c9a230$@iname.com> References: <016d01ce66db$4b433610$e1c9a230$@iname.com> Message-ID: <24466.1370981430@turing-police.cc.vt.edu> On Tue, 11 Jun 2013 15:38:45 -0400, "David Edelman" said: > I can just see someone spoofing a packet from victimA port 7/UDP to victimB > port 19/UDP. For a while, it was possible to spoof packets to create a TCP connection from a machine's chargen port to its own discard port and walk away while it burned to the ground. Fun times. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mysidia at gmail.com Tue Jun 11 23:09:39 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 11 Jun 2013 18:09:39 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: References: <1202BE242E080642B0CD0AD0A03E8552C88F17@PGH-MSGMB-03.andrew.ad.cmu.edu> Message-ID: On 6/11/13, Justin M. Streiner wrote: > Other than providing another DDoS vector, I'm not aware of any legitimate > reason to keep these services running and accessible. As always, YMMV. They are useful for troubleshooting and diagnostic purposes. Just be sure to limit the maximum possible response rate and bandwidth for any source network, and be sure to truncate the length of the response to the length of the original query, so they cannot be used for amplification. If you can't do that, then shut them off :) The risk that they be used to DoS the server that runs those services remains. > jms -- -JH From rick.robino at ipfabrics.com Tue Jun 11 23:22:42 2013 From: rick.robino at ipfabrics.com (Rick Robino) Date: Tue, 11 Jun 2013 16:22:42 -0700 Subject: Mechanics of CALEA taps Message-ID: > Message: 1 > Date: Sun, 9 Jun 2013 18:59:16 -0400 > From: Randy Fischer > To: North American Network Operators Group > Subject: Mechanics of CALEA taps > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Dear nanog: > > Honestly, I expect replies to this question to range between zero and none, > but I have to ask it. > > I understand the CALEA tap mechanism for most ISPs, generally, works like > this: > > * we outsource our CALEA management to company X > * we don't even know there's been a request until we've gotten a bill from > X. > > And that's the extent of it. > > Well, golly Slothrop, maybe someone else has started picking up the tab. > Would you even know? > > Is that possible? > > Thanks, > > Randy Fischer Operators can choose to be involved, or they can choose not to be involved, according to the specs - the extent is ultimately up to them. It is perhaps possible that some operators know nothing more about the intercepts happening on their network than what their bill tells them. I can believe that but I would hope that it is rare. Likewise, I believe that any operator who makes an effort to understand and have control over their network could be fooled so easily. CALEA tap mechanism does not necessarily work as you have outlined. The telecom industry fought for and won two other options that give the operator more involvement and authority over the execution of the intercepts. All of the options end up impacting your network, as you have to decide how to feed a copy of all of the data belonging to the subscriber(s) named in a warrant to a CALEA probe. The probe drops all of the packets that don't belong to the subject, then it ASN.1-encodes the data and tunnels it over the public network to a law-enforcement agency (or their contractor). That's generally how it works. Once the taps and probes and mediation device are in place, it's just a matter of provisioning. But that engineering is the tough part - after that just about all you see is the warrant itself, and then some phone calls and email from the law-enforcment folks setting up the transport stuff. No lawyers visit, no law-enforcement officials visit, you just get a warrant and then how you handle it is up to you. So if an operator chooses to engage themselves instead of handing control over to someone else, they can be quite sure of what is happening. For reasons I don't quite understand, however, it doesn't seem like many operators who don't otherwise outsource ISP services do tend to outsource CALEA. In my opinion, if you manage your own DNS and/or mail servers, you can handle CALEA. Not only could it save you some money, but it gives you a discrete way to isolate test-traffic on your network with a more intuitive filter (ie subscriber name) than just an IP or a MAC address.* If you live in wireshark all day then you will appreciate having the haystack separated from the needle before it enters your system. The three options are: 1. Rent CALEA gear - hand warrant to company X 2. Build your own CALEA gear - evaluate and execute the warrant yourself. 3. Buy company Y's gear - evaluate and execute the warrant yourself. Obviously one could outsource the evaluation of a warrant to a third party; and sure you could probably have a private line between you and the LEA... the details vary, I am drawing a very generic picture here. So, generally, the biggest problem is a technical one: how to add this "tap" feature to your network - either with real physical taps or mirror-ports of some kind. There are lots of such considerations and lots of options. Once they're done you can probably make use of them for worthwhile operational purposes, but probably only with options 2 and 3. The smaller problem is the legal one: is a lawyer required to read the warrant and then make the provisioning call, or not? * Disclosure: I try not to be biased, but I do work for a vendor of a CALEA probe product, so "caveat lector". Comments submitted here have nothing to do with my employer, however, and are provided only as a help to those that really don't know that they can and ought to be fully involved and aware of any "taps". -- Rick Robino -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdobbins at arbor.net Tue Jun 11 23:33:36 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 11 Jun 2013 23:33:36 +0000 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: <0455C42E-3136-4155-90FC-04EBFD4EBBFC@arbor.net> On Jun 12, 2013, at 2:13 AM, Leo Bicknell wrote: > The number is non-zero? In 2013? These are largely modern printers and other 'embedded' devices which are running OS configurations apparently cribbed out of 20-year-old gopher docs. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From philfagan at gmail.com Tue Jun 11 23:36:13 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 11 Jun 2013 17:36:13 -0600 Subject: Cisco ASA SME's Message-ID: Any ASA sme's out there? -- Phil Fagan Denver, CO 970-480-7618 From rdobbins at arbor.net Tue Jun 11 23:42:02 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 11 Jun 2013 23:42:02 +0000 Subject: Cisco ASA SME's In-Reply-To: References: Message-ID: <165D9B8F-64DA-494E-990F-02261FF34E82@arbor.net> On Jun 12, 2013, at 6:36 AM, Phil Fagan wrote: > Any ASA sme's out there? Suggest you check on the cisco-nsp list. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From philfagan at gmail.com Tue Jun 11 23:45:02 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 11 Jun 2013 17:45:02 -0600 Subject: Cisco ASA SME's In-Reply-To: <165D9B8F-64DA-494E-990F-02261FF34E82@arbor.net> References: <165D9B8F-64DA-494E-990F-02261FF34E82@arbor.net> Message-ID: Thank you On Tue, Jun 11, 2013 at 5:42 PM, Dobbins, Roland wrote: > > On Jun 12, 2013, at 6:36 AM, Phil Fagan wrote: > > > Any ASA sme's out there? > > Suggest you check on the cisco-nsp list. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -- Phil Fagan Denver, CO 970-480-7618 From jfbeam at gmail.com Tue Jun 11 23:52:02 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 11 Jun 2013 19:52:02 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: <51B74B0C.3000704@2mbit.com> References: <51B74B0C.3000704@2mbit.com> Message-ID: On Tue, 11 Jun 2013 12:06:36 -0400, Brielle Bruns wrote: > Are these like machines time forgot or just really bag configuration > choices? All of the above plus very poorly managed network / network security. (sadly a Given(tm) for anything ending dot-e-d-u.) a) why are *printers* given public IPs? and b) why are internet hosts allowed to talk to them? I actually *very* surprised your printers are still functional if the whole internet can reach them. Being an edu, even if they aren't globally reachable, there is *plenty* mischievousness already inside the borders! Securing a campus from the world... easy; securing a campus from it's own users... good luck with that. --Ricky From msa at latt.net Tue Jun 11 23:57:17 2013 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 11 Jun 2013 19:57:17 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> Message-ID: <20130611235717.GA3395@puck.nether.net> On Tue, Jun 11, 2013 at 07:52:02PM -0400, Ricky Beam wrote: > All of the above plus very poorly managed network / network > security. (sadly a Given(tm) for anything ending dot-e-d-u.) a) why > are *printers* given public IPs? and b) why are internet hosts > allowed to talk to them? I actually *very* surprised your printers > are still functional if the whole internet can reach them. You've never worked for one, have you? Guess what, they have /16s, they use them, and they like the ability to print from one side of campus to the other. Are you suggesting gigantic NATs with 120,000 students and faculty behind them? I have a hard time blaming a school for this. I have an easy time wondering why printer manufacturers are including chargen support in firmware. --msa From joe at nethead.com Wed Jun 12 00:07:19 2013 From: joe at nethead.com (Joe Hamelin) Date: Tue, 11 Jun 2013 17:07:19 -0700 Subject: chargen is the new DDoS tool? In-Reply-To: <20130611235717.GA3395@puck.nether.net> References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: On Tue, Jun 11, 2013 at 4:57 PM, Majdi S. Abbas wrote: > > I have a hard time blaming a school for this. I have an easy > time wondering why printer manufacturers are including chargen support > in firmware. Isn't that what printer do? Generate characters? It was in the design spec. /me thinks of PHB going down port list, "yep, need that one!" -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jfbeam at gmail.com Wed Jun 12 01:37:04 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 11 Jun 2013 21:37:04 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: <20130611235717.GA3395@puck.nether.net> References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: On Tue, 11 Jun 2013 19:57:17 -0400, Majdi S. Abbas wrote: > You've never worked for one, have you? Indeed I have. Which is why I haven't for a great many years. Academics tend to be, well, academic. That is, rather far out of touch with the realities of running / securing a network. I've used the work "incompotent" in previous conversations, but that's mostly a factor of overwork in an environment where few people are ever fired for such. > Guess what, they have /16s, they use them, and they like > the ability to print from one side of campus to the other. Are you > suggesting gigantic NATs with 120,000 students and faculty behind them? Guess what, there are companies that have /8's, and they manage to keep their network(s) reasonably secured. I'm not talking about uber-large NAT; I'm talking about proper boundry security. If you cannot figure out how to keep the internet away from your printers, you should look into other lines of employment. Limiting access of the residential network into the departmental networks, is one of the first things in the design of a res-net. Otherwise, there's 25k potential script kiddies (or infected home computers now on your network) waiting to attack everything on campus. But we're headed into the weeds here... > I have a hard time blaming a school for this. I have an easy > time wondering why printer manufacturers are including chargen support > in firmware. I have the same bewilderment about people allowing such unsolicited traffic into their network(s) in the first place. Even with IPv6 (where there's no NAT forcing the issue), I run a default deny policy... if nothing asked for it, it doesn't get in. Also, why the hell aren't providers not doing anything to limit spoofing?!? I'll staring right at you AT&T (former Bellsouth.) --Ricky From mysidia at gmail.com Wed Jun 12 02:52:52 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 11 Jun 2013 21:52:52 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: <20130611235717.GA3395@puck.nether.net> References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: On 6/11/13, Majdi S. Abbas wrote: > On Tue, Jun 11, 2013 at 07:52:02PM -0400, Ricky Beam wrote: >> All of the above plus very poorly managed network / network >> security. (sadly a Given(tm) for anything ending dot-e-d-u.) a) why >> are *printers* given public IPs? and b) why are internet hosts >> allowed to talk to them? I actually *very* surprised your printers >> are still functional if the whole internet can reach them. Who really has a solid motive to make them stop working (other than a printer manufacturer who wants to sell them more) ? > Guess what, they have /16s, they use them, and they like > the ability to print from one side of campus to the other. Are you > suggesting gigantic NATs with 120,000 students and faculty behind them? A per-building NAT would work, with static translations for printers in that building, and an ACL with an allow list including IPsec traffic to the printer from the campus' IP range. They don't have to use NAT though to avoid unnecessary exposure of services on internal equipment to the larger world. > I have a hard time blaming a school for this. I have an easy > time wondering why printer manufacturers are including chargen support > in firmware. > They probably built their printer on top of a general purpose or embedded OS they purchased from someone else, or reused, that included an IP stack -- as well as other features that were unnecessary for their use case. Or the chargen tool may have been used during stress tests to verify proper networking, and that the IP stack processed bits without corrupting them; with the manufacturer forgetting/neglecting to turn off the unnecessary feature, forgetting to remove/disable that bit of software, or seeing no need to, before mass producing. > --msa -- -JH From Valdis.Kletnieks at vt.edu Wed Jun 12 02:55:12 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 11 Jun 2013 22:55:12 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: Your message of "Tue, 11 Jun 2013 21:37:04 -0400." References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: <78392.1371005712@turing-police.cc.vt.edu> On Tue, 11 Jun 2013 21:37:04 -0400, "Ricky Beam" said: > Indeed I have. Which is why I haven't for a great many years. Academics > tend to be, well, academic. That is, rather far out of touch with the > realities of running / securing a network. Do you have any actual evidence that a .edu of (say) 2K employees is statistically *measurably* less secure than a .com of 2K employees? We keep hearing that meme - and yet, looking at the archives of this list, I see a lot more stories of network providers who should know better doing stupid stuff than I see of .edu's doing stupid stuff. The Verizon report says small business is actually the biggest cesspit of abuse: http://money.cnn.com/2013/04/22/smallbusiness/small-business-cybercrime/index.html http://www.verizonenterprise.com/DBIR/2013/ ~100 employee firms in health care appear to be a particular lost cause. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From leo.vegoda at icann.org Tue Jun 11 22:10:40 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 11 Jun 2013 15:10:40 -0700 Subject: IANA AS Numbers registry update Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E0DE9D92@EXVPMBX100-1.exc.icann.org> Hi, The IANA AS Numbers registry has been updated to reflect two changes. LACNIC has returned the range 61440-62463 in exchange for a block composed of two non-contiguous ranges: 61440-61951 263168-263679 Both ranges were allocated today. You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers Regards, Leo Vegoda leo.vegoda at icann.org ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 ******************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From jfbeam at gmail.com Wed Jun 12 03:27:05 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 11 Jun 2013 23:27:05 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: On Tue, 11 Jun 2013 22:52:52 -0400, Jimmy Hess wrote: > Who really has a solid motive to make them stop working (other than a > printer manufacturer who wants to sell them more) ? Duh, so people cannot print to them. (amungst various other creative pranks) From a cybercriminal pov, to swipe the things you're printing... like that CC authorization form you just printed, or a confidential contract, etc. (also, in many offices, the printer is also the scanner and fax) --Ricky From jfbeam at gmail.com Wed Jun 12 04:02:40 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 12 Jun 2013 00:02:40 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: <78392.1371005712@turing-police.cc.vt.edu> References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> <78392.1371005712@turing-police.cc.vt.edu> Message-ID: On Tue, 11 Jun 2013 22:55:12 -0400, wrote: > Do you have any actual evidence that a .edu of (say) 2K employees > is statistically *measurably* less secure than a .com of 2K employees? We're sorta lookin' at one now. :-) But seriously, how do you measure one's security? The scope is constantly changing. While there are companies one can pay to do this, those reports are *very* rarely published. And I've not heard of a single edu performing such an audit. The only statistics we have to run with are of *known* breaches. And that's a very bad metric as a company with no security at all that's had no (reported) intrusions appears to have very good security, while a company with extensive security looks very bad after a few breaches. One has noone sniffing around at all, while the other has teams going at it with pick-axes. One likely has noone in charge of security, while the other has an entire security department. From dhubbard at dino.hostasaurus.com Wed Jun 12 04:14:33 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 12 Jun 2013 00:14:33 -0400 Subject: Any Level 3 / GBLX things going on tonight? Message-ID: I just got a bunch of bgpmon alerts that our prefixes were being seen as announced through GBLX 3549 from bgpmon's Finland location peer. David From dhubbard at dino.hostasaurus.com Wed Jun 12 04:29:23 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 12 Jun 2013 00:29:23 -0400 Subject: Any Level 3 / GBLX things going on tonight? References: Message-ID: And now the announcements are withdrawn. Good times. > -----Original Message----- > From: David Hubbard > Sent: Wednesday, June 12, 2013 12:15 AM > To: nanog at nanog.org > Subject: Any Level 3 / GBLX things going on tonight? > > I just got a bunch of bgpmon alerts that our prefixes were being > seen as announced through GBLX 3549 from bgpmon's Finland location > peer. > > David > > > From damian at google.com Wed Jun 12 06:26:02 2013 From: damian at google.com (Damian Menscher) Date: Tue, 11 Jun 2013 23:26:02 -0700 Subject: chargen is the new DDoS tool? In-Reply-To: References: Message-ID: On Tue, Jun 11, 2013 at 8:39 AM, Bernhard Schmidt wrote: > we have been getting reports lately about unsecured UDP chargen servers > in our network being abused for reflection attacks with spoofed sources > > Anyone else seeing that? Anyone who can think of a legitimate use of > chargen/udp these days? Fortunately I can't, so we're going to drop > 19/udp at the border within the next hours. > FWIW, last August we noticed 2.5Gbps of chargen being reflected off ~160 IPs (with large responses in violation of the RFC). As I recall, some quick investigation indicated it was mostly printers. I notified several of the worst offenders (rated by bandwidth). While I think it's silly to be exposing chargen to the world (especially as a default service in a printer!), the real problem here is networks that allow spoofed traffic onto the public internet. In the rare cases we see spoofed traffic I put special effort into tracing them to their source, and then following up to educate those providers about egress filtering. I'd appreciate it if others did the same. Damian From ag4ve.us at gmail.com Wed Jun 12 08:17:40 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 12 Jun 2013 04:17:40 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> <78392.1371005712@turing-police.cc.vt.edu> Message-ID: This is basically untrue. I can deal with a good rant as long as there's some value in it. As it is (I'm sorta sorry) I picked this apart. On Jun 12, 2013 12:04 AM, "Ricky Beam" wrote: > > On Tue, 11 Jun 2013 22:55:12 -0400, wrote: >> > > But seriously, how do you measure one's security? Banks and insurance companies supposedly have some interesting actuarial data on this. > The scope is constantly changing. Not really. The old tricks are the best tricks. And when a default install of Windows still allows you to request old NTLM authentication and most people don't think twice about this, there's a problem. > While there are companies one can pay to do this, those reports are *very* rarely published. It seems you are referring to two things - exploit writing vs pen testing. While I hate saying this, there are automated tools that could clean up most networks for a few K (they can also take down things if you aren't careful so I'm not saying spend 2k and forget about it). Basically, not everyone needs to pay for a professional test out of the gate - fix the easily found stuff and then consider next steps. As for exploit writing, you can pay for this and have an 0day for between $10 and $50k (AFAIK - not what I do with my time / money) but while you've got stuff with known issues on the net that any scanner can find, thinking someone is going to think about using an 0day to break into your stuff is a comical wet dream. > And I've not heard of a single edu performing such an audit. And you won't. I'm not going to tell you about past problems with my stuff because even after I think I've fixed everything, maybe I missed something that you can now easily find with the information I've disclosed. There are information sharing agreements between entities generally in the same industry (maybe even some group like this for edu?). But this will help with source and signatures, if your network is like a sieve, fix that first :) > The only statistics we have to run with are of *known* breaches. As I indicated above, 0days are expensive and no one is going to waste one on you. Put another way, if someone does, go home proud - you're in with the big boys (military, power plants, spy agencies) someone paid top dollar for your stuff because you had everything else closed. > And that's a very bad metric as a company with no security at all that's had no (reported) intrusions appears to have very good security, while a company with extensive security looks very bad after a few breaches. I'll take that metric any day :) Most companies only release a break in if they leak customer data. The only recent example I can think of where this wasn't true was the Canadian company that develops SCATA software disclosing that China stole their stuff. Second, if you look at the stocks of public companies that were hacked a year later, they're always up. The exception to this is HBGary who pissed of anonymous and are no longer in business (they had shady practices that were disclosed by the hack - don't do this). > One has noone sniffing around at all, while the other has teams going at it with pick-axes. If you have no one sniffing around, you've got issues. > One likely has noone in charge of security, while the other has an entire security department. Whether you have a CSO in name or not might not matter. Depending on the size of the organization (and politics), a CTO that understands security can do just as much. From mysidia at gmail.com Wed Jun 12 08:51:01 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 12 Jun 2013 03:51:01 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> <78392.1371005712@turing-police.cc.vt.edu> Message-ID: On 6/12/13, shawn wilson wrote: > This is basically untrue. I can deal with a good rant as long as there's > some value in it. As it is (I'm sorta sorry) I picked this apart. > On Jun 12, 2013 12:04 AM, "Ricky Beam" wrote: >> On Tue, 11 Jun 2013 22:55:12 -0400, wrote: >>> >> > >> But seriously, how do you measure one's security? > Banks and insurance companies supposedly have some interesting actuarial > data on this. >> The scope is constantly changing. > Not really. The old tricks are the best tricks. And when a default install By best, you must mean effective against the greatest number of targets. > of Windows still allows you to request old NTLM authentication and most > people don't think twice about this, there's a problem. Backwards compatibility and protocol downgrade-ability is a PITA. > It seems you are referring to two things - exploit writing vs pen testing. > While I hate saying this, there are automated tools that could clean up > most networks for a few K (they can also take down things if you aren't > careful so I'm not saying spend 2k and forget about it). Basically, not For the orgs that the 2K tool is likely to be most useful for, $2k is a lot of cash. The scan tools that are really worth the trouble start around 5K, and people don't like making much investment in security products, until they know they have a known breach on their hands. Many are likely to forego both, purchase the cheapest firewall appliance they can find, that claims to have antivirus functionality, maybe some stateful TCP filtering, and Web policy enforcement to restrict surfing activity; and feel safe, "the firewall protects us", no other security planning or products or services req'd. > As I indicated above, 0days are expensive and no one is going to waste one > on you. Put another way, if someone does, go home proud - you're in with [snip] I would call this wishful thinking; 0days are expensive, so the people who want to use them, will want to get the most value they can get out of the 0day, before the bug gets fixed. That means both small numbers of high value targets, and, then... large numbers of lesser value targets. If you have a computer connected to the internet, some bandwidth, and a web browser or e-mail address, you are a probable target. If a 0day is used against you, it's most likely to be used against your web browser visiting a "trusted" site you normally visit. The baddies can help protect their investment in 0day exploit code, by making sure that by the time you detect it, the exploit code is long gone, so the infection vector will be unknown. -- -JH From ag4ve.us at gmail.com Wed Jun 12 09:14:03 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 12 Jun 2013 05:14:03 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> <78392.1371005712@turing-police.cc.vt.edu> Message-ID: On Wed, Jun 12, 2013 at 4:51 AM, Jimmy Hess wrote: > On 6/12/13, shawn wilson wrote: >>> The scope is constantly changing. >> Not really. The old tricks are the best tricks. And when a default install > By best, you must mean effective against the greatest number of targets. > By best, I mean effective - end of story. >> of Windows still allows you to request old NTLM authentication and most >> people don't think twice about this, there's a problem. > > Backwards compatibility and protocol downgrade-ability is a PITA. > Yes, telling people that NT/2k can't be on your network might be a PITA, but not using software or hardware that has gone EOL is sometimes just a sensible business practice. >> It seems you are referring to two things - exploit writing vs pen testing. >> While I hate saying this, there are automated tools that could clean up >> most networks for a few K (they can also take down things if you aren't >> careful so I'm not saying spend 2k and forget about it). Basically, not > > For the orgs that the 2K tool is likely to be most useful for, $2k is > a lot of cash. > The scan tools that are really worth the trouble start around 5K, and > people don't like making much investment in security products, until > they know they have a known breach on their hands. Many are likely > to forego both, purchase the cheapest firewall appliance they can > find, that claims to have antivirus functionality, maybe some > stateful TCP filtering, and Web policy enforcement to restrict surfing > activity; and feel safe, "the firewall protects us", no other > security planning or products or services req'd. > I don't really care to price stuff so I might be a little off here (most of this stuff has free components). Nessus starts at around $1k, Armitage is about the same (but no auto-pown, darn), Metasploit Pro is a few grand. My point being, you can have a decent scanner (Nessus) catching the really bad stuff for not much money (I dislike this line of thought, but if you aren't knowledgeable to use tools and just want a report for a grand, there you go). >> As I indicated above, 0days are expensive and no one is going to waste one >> on you. Put another way, if someone does, go home proud - you're in with > [snip] > > I would call this wishful thinking; 0days are expensive, so the > people who want to use them, will want to get the most value they can > get out of the 0day, before the bug gets fixed. > Odays are expensive, so when you see them, someone (Google, Firefox, Adobe, etc) have generally paid for them. Once you see them, they are not odays (dispite what people like to call recently disclosed public vulns - it ain't an 0day). > That means both small numbers of high value targets, and, then... > large numbers of lesser value targets. If you have a computer > connected to the internet, some bandwidth, and a web browser or e-mail > address, you are a probable target. > No, this means Stuxnet, Doqu, Flame. This means, I spent a million on people pounding on stuff for a year, I'm going to take out a nuclear facility or go after Google or RSA. I want things more valuable than your student's social security numbers. > If a 0day is used against you, it's most likely to be used against > your web browser visiting a "trusted" site you normally visit. > I don't have anything to back this up off hand, but my gut tells me that most drive by web site malware isn't that well thought out. > The baddies can help protect their investment in 0day exploit code, > by making sure that by the time you detect it, the exploit code is > long gone, so the infection vector will be unknown. > If the US government can't prevent companies from analyzing their work, do you really think random "baddies" can? Seriously?... No really, seriously? Here's the point, once you use an Oday, it is not an 0day. It's burnt. It might still work on some people, but chances are all your high value targets know about it and it won't work on them. From Joel.Snyder at Opus1.COM Wed Jun 12 09:21:25 2013 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 12 Jun 2013 11:21:25 +0200 Subject: chargen is the new DDoS tool? Message-ID: <51B83D95.8050000@opus1.com> >> Do you have any actual evidence that a .edu of (say) 2K employees >> is statistically *measurably* less secure than a .com of 2K employees? >We're sorta lookin' at one now. >But seriously, how do you measure one's security? In ounces, unless it's a European university, in which case you use liters. Older systems of measuring security involving mass (pounds and kilos) have been deprecated, and you should not be using them anymore in serious evaluations, although some older CSOs will insist. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From mysidia at gmail.com Wed Jun 12 10:21:51 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 12 Jun 2013 05:21:51 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: <51B83D95.8050000@opus1.com> References: <51B83D95.8050000@opus1.com> Message-ID: On 6/12/13, Joel M Snyder wrote: > >But seriously, how do you measure one's security? > In ounces, unless it's a European university, in which case you use > liters. Older systems of measuring security involving mass (pounds and > kilos) have been deprecated, and you should not be using them anymore in You need to count the number of employees/users, information assets, applications, systems, IP addresses on your network, and network ports on your switch, processes running on all your machines, files stored on your servers; and place them in the disjoint non-overlapping categories. Then decide a 'weight' for each object, 'impact'; for example, the cost of formatting and reinstalling a server, buying new hardware if a device has been bricked; or the cost of re-creating work from scratch, or settling the lawsuit if your environment's security failure allows this particular file's content to be disclosed, lost, corrupted, or made temporarily unavailable due to a DoS. The weight should be the greatest possible cost of breach, or misbehavior of that object, be that an application, OS, user, switchport, or MAC address, but Users, Applications, Servers, Workstations, Network Devices, and "Documents directories" are some useful categories to use. Then assign a probability of each object, based on the expectation of a breach, given the series of expected attacks over a period of time. Then for each category, take a ratio of the sums of all objects for each category Sum of ( ( 1 minus Probability that an attack succeeds ) X ( Weight ) ) Divided by (Sum of the Weights) Example, I have 5 Windows XP servers on my network, which cost me $100 to recover and replace from attack, for the period of time of 1 year, no firewall, RDP open to the world; so there is a 90% chance estimated that an attacker will eventually find the vulnerability on average over the series of attacks I expect to find in one year, except on one system I patched, so there is a 40% chance. (0.6 * $100 + 0.1 * $100 + 0.1 * $100 + .... ) divided by $500 Then when faced with the complete series of attacks, I expect to lose $400 out of $500; so my OS category is 10% secure for the year, in that case. Your percentage security is the _lowest_, _least desirable_, or _worst_ metric over all the distinct categories you cared about. > jms -- -JH From rsk at gsp.org Wed Jun 12 10:32:25 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 12 Jun 2013 06:32:25 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: <20130612103225.GA11112@gsp.org> I'm going to bypass the academic vs. non-academic security argument because I've worked everywhere, and from a security viewpoint, there is plenty of fail to go around. On Tue, Jun 11, 2013 at 09:37:04PM -0400, Ricky Beam wrote: > I run a default deny > policy... if nothing asked for it, it doesn't get in. This is a fine thing and good thing. But as you've expressed it here, it's incomplete, because of that last clause: "it doesn't get in". For default-deny to be effective, it has to be bidirectional. Please don't tell me it can't be done. I've done it. Repeatedly. It's a LOT of work. (Although progess in toolsets keeps making it easier.) But it's also essential, since your responsibility is not just to defend your operation from the Internet, but to defend the Internet from your operation. ---rsk From aaron.glenn at gmail.com Wed Jun 12 11:14:44 2013 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Wed, 12 Jun 2013 14:14:44 +0300 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> <78392.1371005712@turing-police.cc.vt.edu> Message-ID: On Wed, Jun 12, 2013 at 11:17 AM, shawn wilson wrote: > > > Banks and insurance companies supposedly have some interesting actuarial > data on this. > Do you know of any publicly available sources? thanks, aaron From nick at pelagiris.org Wed Jun 12 11:24:59 2013 From: nick at pelagiris.org (Nick B) Date: Wed, 12 Jun 2013 07:24:59 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: <51B83D95.8050000@opus1.com> References: <51B83D95.8050000@opus1.com> Message-ID: I thought the modern measure was hours and dollars wasted... Err I mean spent. Nick On Jun 12, 2013 5:21 AM, "Joel M Snyder" wrote: > > >> Do you have any actual evidence that a .edu of (say) 2K employees > >> is statistically *measurably* less secure than a .com of 2K employees? > > >We're sorta lookin' at one now. > > >But seriously, how do you measure one's security? > > In ounces, unless it's a European university, in which case you use > liters. Older systems of measuring security involving mass (pounds and > kilos) have been deprecated, and you should not be using them anymore in > serious evaluations, although some older CSOs will insist. > > jms > > -- > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 > Senior Partner, Opus One Phone: +1 520 324 0494 > jms at Opus1.COM http://www.opus1.com/jms > > From ag4ve.us at gmail.com Wed Jun 12 11:48:29 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 12 Jun 2013 07:48:29 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> <78392.1371005712@turing-police.cc.vt.edu> Message-ID: On Wed, Jun 12, 2013 at 7:14 AM, Aaron Glenn wrote: > On Wed, Jun 12, 2013 at 11:17 AM, shawn wilson wrote: >> >> >> Banks and insurance companies supposedly have some interesting actuarial >> data on this. >> > > Do you know of any publicly available sources? > I don't. There's a US entity that represents credit card companies that has their own type of "Verizon Data Breach Investigations Report" where you might find some iinfo of this type. You might also look at how/if AlienVault and others rank threats which should give you the "how hard is this hack" and "how hard is this to fix" figure. The theory behind generating this type of actuarial data should be more available than it is. I have a feeling that companies who have this information look at entities in the same type of business and make educated guesses on how breaches affected their bottom line based on stock vaule and the like. There is probably some private data sharing here as well. From ag4ve.us at gmail.com Wed Jun 12 13:21:49 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 12 Jun 2013 09:21:49 -0400 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> <20130611235717.GA3395@puck.nether.net> Message-ID: Getting back to the topic. I just saw quite a few of our hosts scanned for this by 192.111.155.106 which doesn't say much on its own as http://dacentec.com/ is a hosting company. On Tue, Jun 11, 2013 at 11:27 PM, Ricky Beam wrote: > On Tue, 11 Jun 2013 22:52:52 -0400, Jimmy Hess wrote: >> >> Who really has a solid motive to make them stop working (other than a >> printer manufacturer who wants to sell them more) ? > > > Duh, so people cannot print to them. (amungst various other creative pranks) > > From a cybercriminal pov, to swipe the things you're printing... like that > CC authorization form you just printed, or a confidential contract, etc. > (also, in many offices, the printer is also the scanner and fax) > > --Ricky > From m4rtntns at gmail.com Wed Jun 12 11:38:57 2013 From: m4rtntns at gmail.com (Martin T) Date: Wed, 12 Jun 2013 14:38:57 +0300 Subject: How ISP's in ARIN region create automatic prefix-filters? Message-ID: Hi, as I understand, ARIN whois database does not contain "route" objects, which are used for example in RIPE region for automatic BGP prefix filter generation. How does this work in ARIN region? I know that at least some ISP's operating in ARIN region use their own whois databases(for example rr.level3.net) which mirror content from other RIR databases, but are there other methods how they update their internal databases with records? regards, Martin From jabley at hopcount.ca Wed Jun 12 14:47:51 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 12 Jun 2013 16:47:51 +0200 Subject: How ISP's in ARIN region create automatic prefix-filters? In-Reply-To: References: Message-ID: <51BE46A4-0D29-4BBB-B573-C9F307ADAB2B@hopcount.ca> On 2013-06-12, at 13:38, Martin T wrote: > as I understand, ARIN whois database does not contain "route" objects, > which are used for example in RIPE region for automatic BGP prefix > filter generation. whois.arin.net:43 is for assignment/allocation information. Does not use RPSL. rr.arin.net:43 is a routing registry that uses RPSL. > How does this work in ARIN region? I know that at > least some ISP's operating in ARIN region use their own whois > databases(for example rr.level3.net) which mirror content from other > RIR databases, but are there other methods how they update their > internal databases with records? My general advice for anybody who cares to listen is to use the RIPE db for your objects if you are based in the ARIN region. It saves time if/when you come to peer with an organisation based in the RIPE region, and it makes your objects easy to find for anybody who wants to look for them. You can install a route in the RIPE db corresponding to number resources assigned elsewhere by authenticating against the RIPE-NCC-RPSL-MNT maintainer object, for which the plain-text password is "RPSL". Since your new route object will specify mnt-by MAINT-YOURS you will also need to authenticate against that (my favourite method is PGP). Joe mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE auth: MD5-PW # Filtered remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT source: RIPE # Filtered From jtk at cymru.com Wed Jun 12 15:11:38 2013 From: jtk at cymru.com (John Kristoff) Date: Wed, 12 Jun 2013 10:11:38 -0500 Subject: chargen is the new DDoS tool? In-Reply-To: References: <51B74B0C.3000704@2mbit.com> Message-ID: <20130612101138.36b8c5be@localhost> On Tue, 11 Jun 2013 19:52:02 -0400 "Ricky Beam" wrote: > All of the above plus very poorly managed network / network > security. (sadly a Given(tm) for anything ending dot-e-d-u.) That broad sweeping characterization, without any evidence, can be as casually dismissed without evidence. However, I will go on record, as I'm sure many others will as well, but in my experience the .edu community, particularly the medium to larger schools who have dedicated IT staff, are often amongst the best managed networks, with regards to security or otherwise. If there is any issue with that sector, you should contact the REN-ISAC, one of the most well executed security constituent groups I've ever seen. They tirelessly reach out and assist on most any educational related incident. John From jlightfoot at gmail.com Wed Jun 12 23:35:26 2013 From: jlightfoot at gmail.com (John Lightfoot) Date: Wed, 12 Jun 2013 19:35:26 -0400 Subject: Prism continued In-Reply-To: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: Let's see: Requires "always-on" internet connection Only available with Kinect Includes infrared sensor Manufactured by Microsoft, the first company to sign up for Prism When can I get my Xbox One?? http://www.nbcnews.com/technology/new-kinect-can-track-you-so-well-you-may- not-6C10287970 On 6/9/13 12:26 PM, "Warren Bailey" wrote: >I suppose this system was part of the 20MM as well? > >http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the- >512107983 > > > >Sent from my Mobile Device. From baconzombie at gmail.com Wed Jun 12 23:46:27 2013 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 13 Jun 2013 00:46:27 +0100 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: There is no way they could of paid for all the Splunk licencing costs which the budget quoted before.... On 9 June 2013 18:42, Daniel Rohan wrote: > Anyone else notice that the Boundless Informant GUI looks suspiciously like > the Splunk GUI? > > And according to the article, it sounds like it does exactly what Splunk is > capable of, albeit on a grander scale than I thought possible. > > dgr > On Jun 9, 2013 9:29 AM, "Warren Bailey" < > wbailey at satelliteintelligencegroup.com> wrote: > >> I suppose this system was part of the 20MM as well? >> >> >> http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the-512107983 >> >> >> >> Sent from my Mobile Device. >> -- BaconZombie LOAD "*",8,1 From philfagan at gmail.com Wed Jun 12 23:55:39 2013 From: philfagan at gmail.com (Phil Fagan) Date: Wed, 12 Jun 2013 17:55:39 -0600 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: Speaking of Splunk; is that really the tool of choice? On Wed, Jun 12, 2013 at 5:46 PM, Bacon Zombie wrote: > There is no way they could of paid for all the Splunk licencing costs > which the budget quoted before.... > > On 9 June 2013 18:42, Daniel Rohan wrote: > > Anyone else notice that the Boundless Informant GUI looks suspiciously > like > > the Splunk GUI? > > > > And according to the article, it sounds like it does exactly what Splunk > is > > capable of, albeit on a grander scale than I thought possible. > > > > dgr > > On Jun 9, 2013 9:29 AM, "Warren Bailey" < > > wbailey at satelliteintelligencegroup.com> wrote: > > > >> I suppose this system was part of the 20MM as well? > >> > >> > >> > http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the-512107983 > >> > >> > >> > >> Sent from my Mobile Device. > >> > > > > -- > > > BaconZombie > > LOAD "*",8,1 > > -- Phil Fagan Denver, CO 970-480-7618 From eyeronic.design at gmail.com Wed Jun 12 23:59:04 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 12 Jun 2013 16:59:04 -0700 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: It would make sense. It's a friggin' sick syslog analyzer. Expensive as hell, but awesome. On Wed, Jun 12, 2013 at 4:55 PM, Phil Fagan wrote: > Speaking of Splunk; is that really the tool of choice? > > > On Wed, Jun 12, 2013 at 5:46 PM, Bacon Zombie wrote: > >> There is no way they could of paid for all the Splunk licencing costs >> which the budget quoted before.... >> >> On 9 June 2013 18:42, Daniel Rohan wrote: >> > Anyone else notice that the Boundless Informant GUI looks suspiciously >> like >> > the Splunk GUI? >> > >> > And according to the article, it sounds like it does exactly what Splunk >> is >> > capable of, albeit on a grander scale than I thought possible. >> > >> > dgr >> > On Jun 9, 2013 9:29 AM, "Warren Bailey" < >> > wbailey at satelliteintelligencegroup.com> wrote: >> > >> >> I suppose this system was part of the 20MM as well? >> >> >> >> >> >> >> http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the-512107983 >> >> >> >> >> >> >> >> Sent from my Mobile Device. >> >> >> >> >> >> -- >> >> >> BaconZombie >> >> LOAD "*",8,1 >> >> > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jeff-kell at utc.edu Thu Jun 13 00:10:17 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 12 Jun 2013 20:10:17 -0400 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: <51B90DE9.8090801@utc.edu> On 6/12/2013 7:59 PM, Mike Hale wrote: > It would make sense. It's a friggin' sick syslog analyzer. Expensive > as hell, but awesome. Compare it to most any other SIEM (ArcSight?) and it's a bargain. But still, yeah. Jeff From surfer at mauigateway.com Thu Jun 13 00:13:45 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 Jun 2013 17:13:45 -0700 Subject: Prism continued Message-ID: <20130612171345.D489ABA2@m0005296.ppops.net> --- eyeronic.design at gmail.com wrote: From: Mike Hale >> Splunk It would make sense. It's a friggin' sick syslog analyzer. Expensive as hell, but awesome. ------------------------------------------------------ So is "tail -f /var/log/router.log | egrep -v 'term1|term2|term3'" or "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" ;-) scott From philfagan at gmail.com Thu Jun 13 00:30:04 2013 From: philfagan at gmail.com (Phil Fagan) Date: Wed, 12 Jun 2013 18:30:04 -0600 Subject: Prism continued In-Reply-To: <20130612171345.D489ABA2@m0005296.ppops.net> References: <20130612171345.D489ABA2@m0005296.ppops.net> Message-ID: And a basic front-end and your in business!! On Jun 12, 2013 6:15 PM, "Scott Weeks" wrote: > > > --- eyeronic.design at gmail.com wrote: > From: Mike Hale > > >> Splunk > > It would make sense. It's a friggin' sick syslog analyzer. Expensive > as hell, but awesome. > ------------------------------------------------------ > > > So is "tail -f /var/log/router.log | egrep -v 'term1|term2|term3'" > or "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" > > > ;-) > scott > > From dougb at dougbarton.us Thu Jun 13 00:34:22 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 12 Jun 2013 17:34:22 -0700 Subject: Prism continued In-Reply-To: <20130612171345.D489ABA2@m0005296.ppops.net> References: <20130612171345.D489ABA2@m0005296.ppops.net> Message-ID: <51B9138E.5020107@dougbarton.us> On 06/12/2013 05:13 PM, Scott Weeks wrote: > "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" Prototypical "useless use of cat" :) From surfer at mauigateway.com Thu Jun 13 01:01:55 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 Jun 2013 18:01:55 -0700 Subject: Prism continued Message-ID: <20130612180155.D489A8E7@m0005296.ppops.net> --- dougb at dougbarton.us wrote: From: Doug Barton On 06/12/2013 05:13 PM, Scott Weeks wrote: > "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" Prototypical "useless use of cat" :) ----------------------------------------------------- What would you use and what's wrong with concatenation of a file with nothing? 1+0=1 ;) scott From surfer at mauigateway.com Thu Jun 13 01:12:17 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 Jun 2013 18:12:17 -0700 Subject: Prism continued Message-ID: <20130612181217.D489A85E@m0005296.ppops.net> On Jun 12, 2013, at 9:01 PM, "Scott Weeks" wrote: > --- dougb at dougbarton.us wrote: > From: Doug Barton > > On 06/12/2013 05:13 PM, Scott Weeks wrote: >> "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" > > Prototypical "useless use of cat" :) > ----------------------------------------------------- > > > What would you use and what's wrong with concatenation > of a file with nothing? 1+0=1 ;) --------------------------------------- Wow, a person gets corrected quickly here! ;-) And the answer is... "egrep -v 'term1|term2|term3' /var/log/router.log | less" All I can say is DOH! :-) scott From chip at 2bithacker.net Thu Jun 13 01:13:37 2013 From: chip at 2bithacker.net (Chip Marshall) Date: Wed, 12 Jun 2013 21:13:37 -0400 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: <20130613011337.GB46731@2bithacker.net> On 2013-06-12, Phil Fagan sent: > Speaking of Splunk; is that really the tool of choice? I've been hearing a lot of good things about logstash these days too, if you prefer the open source route. http://logstash.net/ -- Chip Marshall http://2bithacker.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Jun 13 01:30:53 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 12 Jun 2013 21:30:53 -0400 Subject: Prism continued In-Reply-To: Your message of "Thu, 13 Jun 2013 00:46:27 +0100." References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> Message-ID: <5292.1371087053@turing-police.cc.vt.edu> On Thu, 13 Jun 2013 00:46:27 +0100, Bacon Zombie said: > There is no way they could of paid for all the Splunk licencing costs > which the budget quoted before.... That's assuming they paid full list price. Ask the ex-CEO of Qwest what happens if you try to turn down an offer the NSA makes you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From fergdawgster at gmail.com Thu Jun 13 01:35:07 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 12 Jun 2013 18:35:07 -0700 Subject: Prism continued In-Reply-To: <5292.1371087053@turing-police.cc.vt.edu> References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <5292.1371087053@turing-police.cc.vt.edu> Message-ID: On Wed, Jun 12, 2013 at 6:30 PM, wrote: > > Ask the ex-CEO of Qwest what happens if you try to turn down an > offer the NSA makes you. :) +1 - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From jof at thejof.com Thu Jun 13 01:35:35 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Wed, 12 Jun 2013 18:35:35 -0700 Subject: Prism continued In-Reply-To: <20130613011337.GB46731@2bithacker.net> References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <20130613011337.GB46731@2bithacker.net> Message-ID: Logstash and Splunk are both wonderful, in my experience. What sets them apart from just a plain grep(1) is that they build an index that points keywords to to logging events (lines). What if you're looking for events related to a specific interface or LSP? Not a problem with a modest log volume, as grep can tear through text nearly as quickly as your disk can pass it up. However, once you have a ton of historical logs, or just a large volume, grep becomes way to slow as you have to retrieve tons of unrelated log messages to check if they're what you're looking for. Having an index gives you a way to search for that interface or LSP name, and get a listing of all the locations that contain log events matching what you're looking for. In the PRISM context, I highly doubt their using Splunk for any kind of analysis beyond systems and network management. It's not good at indexing non-texty-things. What if you need to search for events that were geographically proximate to one another? That takes a special kind of index. On Wed, Jun 12, 2013 at 6:13 PM, Chip Marshall wrote: > On 2013-06-12, Phil Fagan sent: >> Speaking of Splunk; is that really the tool of choice? > > I've been hearing a lot of good things about logstash these days > too, if you prefer the open source route. > > http://logstash.net/ > > -- > Chip Marshall > http://2bithacker.net/ From charles-lists at knownelement.com Thu Jun 13 04:00:57 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Wed, 12 Jun 2013 23:00:57 -0500 Subject: Prism continued In-Reply-To: References: <20130612171345.D489ABA2@m0005296.ppops.net> Message-ID: Decent frontend... hmm... grep --color Monies please! Phil Fagan wrote: >And a basic front-end and your in business!! >On Jun 12, 2013 6:15 PM, "Scott Weeks" wrote: > >> >> >> --- eyeronic.design at gmail.com wrote: >> From: Mike Hale >> >> >> Splunk >> >> It would make sense. It's a friggin' sick syslog analyzer. >Expensive >> as hell, but awesome. >> ------------------------------------------------------ >> >> >> So is "tail -f /var/log/router.log | egrep -v 'term1|term2|term3'" >> or "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" >> >> >> ;-) >> scott >> >> -- Charles Wyble charles at knownelement.com / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From charles-lists at knownelement.com Thu Jun 13 04:04:27 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Wed, 12 Jun 2013 23:04:27 -0500 Subject: Prism continued In-Reply-To: <20130613011337.GB46731@2bithacker.net> References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <20130613011337.GB46731@2bithacker.net> Message-ID: <4aeef7a0-5776-4eaa-b414-2c4a9cc568ea@email.android.com> Also checkout kibana.org for a rather splunk like experience. Chip Marshall wrote: >On 2013-06-12, Phil Fagan sent: >> Speaking of Splunk; is that really the tool of choice? > >I've been hearing a lot of good things about logstash these days >too, if you prefer the open source route. > >http://logstash.net/ > >-- >Chip Marshall >http://2bithacker.net/ -- Charles Wyble charles at knownelement.com / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From eugen at leitl.org Thu Jun 13 06:47:33 2013 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 13 Jun 2013 08:47:33 +0200 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <20130613011337.GB46731@2bithacker.net> Message-ID: <20130613064733.GR22824@leitl.org> On Wed, Jun 12, 2013 at 06:35:35PM -0700, Jonathan Lassoff wrote: > In the PRISM context, I highly doubt their using Splunk for any kind > of analysis beyond systems and network management. It's not good at > indexing non-texty-things. > What if you need to search for events that were geographically > proximate to one another? That takes a special kind of index. PostgreSQL has PostGIS, but I doubt it's high-performance. From goemon at anime.net Thu Jun 13 06:47:06 2013 From: goemon at anime.net (goemon at anime.net) Date: Wed, 12 Jun 2013 23:47:06 -0700 (PDT) Subject: Prism continued In-Reply-To: References: Message-ID: cellphones with cameras are probably better for the purposes of covert mass surveillance, especially ones with front facing cameras. far more of them out there, and wireless to boot. suprised everyone gets their panties in a bunch over presumed games console monitoring, what about all your iphones already out there? -Dan On Wed, 12 Jun 2013, John Lightfoot wrote: > Let's see: > > Requires "always-on" internet connection > > Only available with Kinect > Includes infrared sensor > Manufactured by Microsoft, the first company to sign up for Prism > > When can I get my Xbox One?? > > http://www.nbcnews.com/technology/new-kinect-can-track-you-so-well-you-may- > not-6C10287970 > > > > On 6/9/13 12:26 PM, "Warren Bailey" > wrote: > >> I suppose this system was part of the 20MM as well? >> >> http://gizmodo.com/meet-boundless-informant-the-nsa-tool-that-watches-the- >> 512107983 >> >> >> >> Sent from my Mobile Device. > > > From noonslists at gmail.com Thu Jun 13 07:02:08 2013 From: noonslists at gmail.com (Noon Silk) Date: Thu, 13 Jun 2013 17:02:08 +1000 Subject: Prism continued In-Reply-To: References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <20130613011337.GB46731@2bithacker.net> Message-ID: On Thu, Jun 13, 2013 at 11:35 AM, Jonathan Lassoff wrote: > > In the PRISM context, I highly doubt their using Splunk for any kind > of analysis beyond systems and network management. It's not good at > indexing non-texty-things. > What if you need to search for events that were geographically > proximate to one another? That takes a special kind of index. I was under the impression stuff like Palantir was used a bit, in this context (but I don't even have nth-hand evidence for that.) -- Noon Silk From rsk at gsp.org Thu Jun 13 10:52:23 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 13 Jun 2013 06:52:23 -0400 Subject: Prism continued In-Reply-To: <5292.1371087053@turing-police.cc.vt.edu> References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <5292.1371087053@turing-police.cc.vt.edu> Message-ID: <20130613105223.GA18446@gsp.org> On Wed, Jun 12, 2013 at 09:30:53PM -0400, Valdis.Kletnieks at vt.edu wrote: > Ask the ex-CEO of Qwest what happens if you try to turn down an > offer the NSA makes you. :) Ah, yes. This: https://mailman.stanford.edu/pipermail/liberationtech/2013-June/008815.html ---rsk From jlewis at lewis.org Thu Jun 13 14:20:14 2013 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 13 Jun 2013 10:20:14 -0400 (EDT) Subject: Prism continued In-Reply-To: References: Message-ID: On Wed, 12 Jun 2013 goemon at anime.net wrote: > cellphones with cameras are probably better for the purposes of covert mass > surveillance, especially ones with front facing cameras. far more of them out > there, and wireless to boot. > > suprised everyone gets their panties in a bunch over presumed games console > monitoring, what about all your iphones already out there? My iPhone lives in a holster that covers both cameras when not in use or charging. Do you throw a sheet over your gaming console when you're not using it? Would hacking (or abusing) Xbox One and using Kinect for remote surveillance create "house RATs"? :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From carey at ar-ballbat.org Thu Jun 13 15:01:39 2013 From: carey at ar-ballbat.org (Andrew Carey) Date: Thu, 13 Jun 2013 08:01:39 -0700 Subject: Prism continued In-Reply-To: <20130613105223.GA18446@gsp.org> References: <7txclrs1u8k2v59mff7wl36q.1370795185787@email.android.com> <5292.1371087053@turing-police.cc.vt.edu> <20130613105223.GA18446@gsp.org> Message-ID: On Jun 13, 2013, at 3:52, Rich Kulawiec wrote: > On Wed, Jun 12, 2013 at 09:30:53PM -0400, Valdis.Kletnieks at vt.edu wrote: >> Ask the ex-CEO of Qwest what happens if you try to turn down an >> offer the NSA makes you. :) > > Ah, yes. This: > > https://mailman.stanford.edu/pipermail/liberationtech/2013-June/008815.html And Bernie Ebbers was framed, too? The linked email above erroneously describes Nacchio's defense as DOJ's theory, which is even more ridiculous (defense to insider trading charge is trading on insider information-- ok...). As nice as it would have to have a martyr, Nacchio isn't it. From randy at psg.com Thu Jun 13 16:10:39 2013 From: randy at psg.com (Randy Bush) Date: Thu, 13 Jun 2013 18:10:39 +0200 Subject: huawei Message-ID: we really should not be putting huawei kit into the backbone, there might be backdoors where they can spy on our traffic oh well, so much for that randy From philfagan at gmail.com Thu Jun 13 16:14:16 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 10:14:16 -0600 Subject: huawei In-Reply-To: References: Message-ID: I've always wondered about that....would you know that the Huawei is leaking data? On Thu, Jun 13, 2013 at 10:10 AM, Randy Bush wrote: > we really should not be putting huawei kit into the backbone, there > might be backdoors where they can spy on our traffic > > oh > > well, so much for that > > randy > > -- Phil Fagan Denver, CO 970-480-7618 From symack at gmail.com Thu Jun 13 16:18:56 2013 From: symack at gmail.com (Nick Khamis) Date: Thu, 13 Jun 2013 12:18:56 -0400 Subject: huawei In-Reply-To: References: Message-ID: A local clec here in Canada just teamed up with this company to provide cell service to the north: http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for-3g-wireless-network-in-northern-canada/ Scary.... N. From patrick at ianai.net Thu Jun 13 16:22:26 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 13 Jun 2013 12:22:26 -0400 Subject: huawei In-Reply-To: References: Message-ID: <83EF87B2-75D1-4405-8270-CE07CFDCC286@ianai.net> On Jun 13, 2013, at 12:18 , Nick Khamis wrote: > A local clec here in Canada just teamed up with this company to > provide cell service to the north: > > http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for-3g-wireless-network-in-northern-canada/ > > Scary.... Why? Do you think Huawei has a magic ability to transmit data without you noticing? If you don't want to use Hauwei because they stole code or did other nasty things, I'm right there with you. If you believe a router can somehow magically duplicate info and transport it back to China (ignoring CT/CU's inability to have congestion free links), I think you are confused. -- TTFN, patrick From randy at psg.com Thu Jun 13 16:22:24 2013 From: randy at psg.com (Randy Bush) Date: Thu, 13 Jun 2013 18:22:24 +0200 Subject: huawei In-Reply-To: References: Message-ID: > I've always wondered about that....would you know that the Huawei is > leaking data? yes. they have a contract to leak it to the NSA From drais at icantclick.org Thu Jun 13 16:26:50 2013 From: drais at icantclick.org (david raistrick) Date: Thu, 13 Jun 2013 12:26:50 -0400 (EDT) Subject: huawei In-Reply-To: References: Message-ID: On Thu, 13 Jun 2013, Phil Fagan wrote: > I've always wondered about that....would you know that the Huawei is > leaking data? the puddle on the floor isn't a giveaway? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From saku at ytti.fi Thu Jun 13 16:31:55 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 13 Jun 2013 19:31:55 +0300 Subject: huawei In-Reply-To: <83EF87B2-75D1-4405-8270-CE07CFDCC286@ianai.net> References: <83EF87B2-75D1-4405-8270-CE07CFDCC286@ianai.net> Message-ID: <20130613163155.GA18740@pob.ytti.fi> On (2013-06-13 12:22 -0400), Patrick W. Gilmore wrote: > Do you think Huawei has a magic ability to transmit data without you noticing? I always found it dubious that public sector can drop them from tender citing publicly about spying, when AFAIK Huawei hasn't never actually been to court about it much less found guilty of it. It's convenient way to devaluate one competitor. I'm just not sure if it's actually legal in $my_locale to invent reasons to exclude vendor in public sector RFQs. -- ++ytti From m.hallgren at free.fr Thu Jun 13 16:33:32 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 13 Jun 2013 18:33:32 +0200 Subject: huawei In-Reply-To: References: Message-ID: <51B9F45C.7010700@free.fr> Le 13/06/2013 18:22, Randy Bush a ?crit : >> I've always wondered about that....would you know that the Huawei is >> leaking data? > yes. they have a contract to leak it to the NSA :-) mh > From philfagan at gmail.com Thu Jun 13 16:34:28 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 10:34:28 -0600 Subject: huawei In-Reply-To: References: Message-ID: Yeah, I can't imagine there is any real magic there...mystical protocol not seen over transport. On Thu, Jun 13, 2013 at 10:26 AM, david raistrick wrote: > On Thu, 13 Jun 2013, Phil Fagan wrote: > > I've always wondered about that....would you know that the Huawei is >> leaking data? >> > > the puddle on the floor isn't a giveaway? > > > > > -- > david raistrick http://www.netmeister.org/**news/learn2quote.html > drais at icantclick.org ascii ribbon campaign - stop html mail > http://www.asciiribbon.org/ > > > > -- Phil Fagan Denver, CO 970-480-7618 From patrick at ianai.net Thu Jun 13 16:35:48 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 13 Jun 2013 12:35:48 -0400 Subject: huawei In-Reply-To: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: On Jun 13, 2013, at 12:28 , "Avi Freedman" wrote: > I disagree. > > There have already been lab demos of sfps that could inject frames and APTs are pretty advanced, sinister, and can be hard to detect now. > > I'm not suggesting Huawei is or isn't enabling badness globally but I think it would be technically feasible. I am assuming a not-Hauwei-only network. The idea that a router could send things through other routers without someone who is looking for it noticing is ludicrous. Of course, most people aren't paying attention, a few extra frames wouldn't be noticed most likely. But if you are worried about it, you should be looking. Also, I find it difficult to believe Hauwei has the ability to do DPI or something inside their box and still route at reasonable speeds is a bit silly. Perhaps they only duplicate packets based on source/dest IP address or something that is magically messaged from the mother ship, but I am dubious. It should be trivial to prove to yourself the box is, or is not, doing something evil if you actually try. -- TTFN, patrick > ------Original Message------ > From: Patrick W. Gilmore > To: NANOG list > Subject: Re: huawei > Sent: Jun 13, 2013 12:22 PM > > On Jun 13, 2013, at 12:18 , Nick Khamis wrote: > >> A local clec here in Canada just teamed up with this company to >> provide cell service to the north: >> >> http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for-3g-wireless-network-in-northern-canada/ >> >> Scary.... > > Why? > > Do you think Huawei has a magic ability to transmit data without you noticing? > > If you don't want to use Hauwei because they stole code or did other nasty things, I'm right there with you. If you believe a router can somehow magically duplicate info and transport it back to China (ignoring CT/CU's inability to have congestion free links), I think you are confused. > > -- > TTFN, > patrick > > > From mike at mtcc.com Thu Jun 13 16:39:21 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 13 Jun 2013 09:39:21 -0700 Subject: huawei In-Reply-To: <20130613163155.GA18740@pob.ytti.fi> References: <83EF87B2-75D1-4405-8270-CE07CFDCC286@ianai.net> <20130613163155.GA18740@pob.ytti.fi> Message-ID: <51B9F5B9.5040105@mtcc.com> On 06/13/2013 09:31 AM, Saku Ytti wrote: > On (2013-06-13 12:22 -0400), Patrick W. Gilmore wrote: > >> Do you think Huawei has a magic ability to transmit data without you noticing? > I always found it dubious that public sector can drop them from tender > citing publicly about spying, when AFAIK Huawei hasn't never actually been > to court about it much less found guilty of it. > > It's convenient way to devaluate one competitor. I'm just not sure if it's > actually legal in $my_locale to invent reasons to exclude vendor in public > sector RFQs. > Er, um, there are more ways to spy than virtual wires back to the mothership... Mike From job.snijders at atrato.com Thu Jun 13 16:48:41 2013 From: job.snijders at atrato.com (Job Snijders) Date: Thu, 13 Jun 2013 18:48:41 +0200 Subject: peeringdb accuracy research In-Reply-To: References: Message-ID: <4AE99398-F324-4255-9248-570D92222DF7@atrato.com> My dear fellow networkers, Good news everyone, 99% of the parsable data in PeeringDB is valid! :-) Measuring this number would have been inpossible without all the submissions to the research app. Thank you! If you are interested in the details, please see these slides: http://nanog.org/sites/default/files/wed.general.peeringdb.accuracy.snijders.14.pdf Kind regards, Job On May 23, 2013, at 12:28 PM, Job Snijders wrote: > Dear fellow networkers, > > I need your help! > > For the good of PeeringDB I am researching the accuracy of the current PeeringDB > data set. We plan to compare three sources of information: peeringdb itself, > publicly available listings from IXP operators ... and the ultimate source of > truth: user submitted information, e.g. your "show bgp sum". > > Why? I'd rather trust 10 sightings in the wild than one entry in PeeringDB! :-) > > What can you do? > ---------------- > > We've created a webapp where you can copy + paste the output from your routers' > show ip bgp sum / show bgp sum / show ipv6 bgp sum. The webapp extracts the ASN > and remote IP for the sessions and store those after your confirmation. > > Go to the following URL and submit your BGP data now! > > https://research.peeringdb.com/ > > If you prefer, you can also submit the data in CSV format [2]. > > What data are we using, exactly? > -------------------------------- > > Only the following tuples of information are used: > > (remote_ASN, remote_IP) > > All other data is purged from the data set: I don't care if you are even > exchanging prefixes or how many, nor does it matter what your own ASN is. The > _only_ thing that matters is that you confirm that you have a BGP session up > and running with a certain remote IP and ASN. You can submit such confirmations > by copying + pasting your routers' bgp summaries. > > Please submit your BGP summaries from all your IXP facing routers! > > So when will I hear back about this? > ------------------------------------ > > I will present the findings at the upcoming NANOG meeting in New Orleans [1]. > Given that the NANOG meeting is approaching rapidly, I urge you to submit your > data sooner rather than later. :-) > > Kind regards, > > Job Snijders > > [1] - CSV format should be formatted like column 1: ASN, column 2: remote IP, > separated by a comma. example: "5580,195.69.144.229" > [2] - http://www.nanog.org/meetings/abstract?id=2140 > > > -- AS5580 - Atrato IP Networks From philfagan at gmail.com Thu Jun 13 16:50:28 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 10:50:28 -0600 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: So, DPI, duplication, injection into frames. If each Hauwei knows of each other....I supose you could create a Hauwei backbone and slowly pick and pull peices of what you want out of the flow. But how realistic is that really... On Thu, Jun 13, 2013 at 10:35 AM, Patrick W. Gilmore wrote: > On Jun 13, 2013, at 12:28 , "Avi Freedman" wrote: > > > I disagree. > > > > There have already been lab demos of sfps that could inject frames and > APTs are pretty advanced, sinister, and can be hard to detect now. > > > > I'm not suggesting Huawei is or isn't enabling badness globally but I > think it would be technically feasible. > > I am assuming a not-Hauwei-only network. > > The idea that a router could send things through other routers without > someone who is looking for it noticing is ludicrous. > > Of course, most people aren't paying attention, a few extra frames > wouldn't be noticed most likely. But if you are worried about it, you > should be looking. > > Also, I find it difficult to believe Hauwei has the ability to do DPI or > something inside their box and still route at reasonable speeds is a bit > silly. Perhaps they only duplicate packets based on source/dest IP address > or something that is magically messaged from the mother ship, but I am > dubious. > > It should be trivial to prove to yourself the box is, or is not, doing > something evil if you actually try. > > -- > TTFN, > patrick > > > > ------Original Message------ > > From: Patrick W. Gilmore > > To: NANOG list > > Subject: Re: huawei > > Sent: Jun 13, 2013 12:22 PM > > > > On Jun 13, 2013, at 12:18 , Nick Khamis wrote: > > > >> A local clec here in Canada just teamed up with this company to > >> provide cell service to the north: > >> > >> > http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for-3g-wireless-network-in-northern-canada/ > >> > >> Scary.... > > > > Why? > > > > Do you think Huawei has a magic ability to transmit data without you > noticing? > > > > If you don't want to use Hauwei because they stole code or did other > nasty things, I'm right there with you. If you believe a router can somehow > magically duplicate info and transport it back to China (ignoring CT/CU's > inability to have congestion free links), I think you are confused. > > > > -- > > TTFN, > > patrick > > > > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From mike at mtcc.com Thu Jun 13 16:49:51 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 13 Jun 2013 09:49:51 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: <51B9F82F.9090205@mtcc.com> On 06/13/2013 09:35 AM, Patrick W. Gilmore wrote: > > I am assuming a not-Hauwei-only network. > > The idea that a router could send things through other routers without someone who is looking for it noticing is ludicrous. > ::cough:: steganography ::cough:: Mike From wbailey at satelliteintelligencegroup.com Thu Jun 13 16:56:55 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 13 Jun 2013 16:56:55 +0000 Subject: huawei In-Reply-To: <83EF87B2-75D1-4405-8270-CE07CFDCC286@ianai.net> References: , <83EF87B2-75D1-4405-8270-CE07CFDCC286@ianai.net> Message-ID: That was exact statement from the DoD, prior to them finding out they had a bunch of Chinese fake gear with real back doors built in. I can appreciate a difference of opinion, but anyone would installs the PRC's cellular solution is a fool. Never mind security, they just simply don't work. There are several of those Chinese network equipment manufacturers.. Tegra comes to mind too.. As a footnote, the Iranian government would have thought you were bat shit crazy if you told them there was a secret set of programs running on their centrifuge SCADA network, which was completely true. You don't need to relay data out to cause harm or watch over something, you simply have to visit more. ;) Sent from my Mobile Device. -------- Original message -------- From: "Patrick W. Gilmore" Date: 06/13/2013 9:24 AM (GMT-08:00) To: NANOG list Subject: Re: huawei On Jun 13, 2013, at 12:18 , Nick Khamis wrote: > A local clec here in Canada just teamed up with this company to > provide cell service to the north: > > http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for-3g-wireless-network-in-northern-canada/ > > Scary.... Why? Do you think Huawei has a magic ability to transmit data without you noticing? If you don't want to use Hauwei because they stole code or did other nasty things, I'm right there with you. If you believe a router can somehow magically duplicate info and transport it back to China (ignoring CT/CU's inability to have congestion free links), I think you are confused. -- TTFN, patrick From symack at gmail.com Thu Jun 13 17:09:42 2013 From: symack at gmail.com (Nick Khamis) Date: Thu, 13 Jun 2013 13:09:42 -0400 Subject: huawei In-Reply-To: <51B9F82F.9090205@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: On 6/13/13, Michael Thomas wrote: > On 06/13/2013 09:35 AM, Patrick W. Gilmore wrote: >> >> I am assuming a not-Hauwei-only network. >> >> The idea that a router could send things through other routers without >> someone who is looking for it noticing is ludicrous. >> > > ::cough:: steganography ::cough:: > > Mike > > Well put! N. From kevind at inmotionhosting.com Thu Jun 13 17:07:21 2013 From: kevind at inmotionhosting.com (Kevin D) Date: Thu, 13 Jun 2013 12:07:21 -0500 Subject: Cisco optics in Northern Virginia Message-ID: Does anyone know where I could find a supplier of Cisco (or compatible) optics in Northern Virginia? We're in a pinch in Ashburn and really need to find a GLC-LH-SM locally. Thanks in advance. -Kevin Dougherty From khelms at zcorum.com Thu Jun 13 17:20:40 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 13:20:40 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: Not really, no one has claimed it's impossible to hide traffic. What is true is that it's not feasible to do so at scale without it becoming obvious. Steganography is great for hiding traffic inside of legitimate traffic between two hosts but if one of my routers starts sending cay photos somewhere, no matter how cute, I'm gonna consider that suspicious. That's an absurd example (hopefully funny) but _any_ from one of my routers over time would be obvious, especially since to be effective this would have to go on much of the time and in many routers. Hiding all that isn't feasible for a really technically astute company and they're not in that category yet (IMO). On Jun 13, 2013 1:10 PM, "Nick Khamis" wrote: > On 6/13/13, Michael Thomas wrote: > > On 06/13/2013 09:35 AM, Patrick W. Gilmore wrote: > >> > >> I am assuming a not-Hauwei-only network. > >> > >> The idea that a router could send things through other routers without > >> someone who is looking for it noticing is ludicrous. > >> > > > > ::cough:: steganography ::cough:: > > > > Mike > > > > > > Well put! > > N. > > From mike at mtcc.com Thu Jun 13 17:24:20 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 13 Jun 2013 10:24:20 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: <51BA0044.2050601@mtcc.com> On 06/13/2013 10:20 AM, Scott Helms wrote: > > Not really, no one has claimed it's impossible to hide traffic. What is true is that it's not feasible to do so at scale without it becoming obvious. Steganography is great for hiding traffic inside of legitimate traffic between two hosts but if one of my routers starts sending cay photos somewhere, no matter how cute, I'm gonna consider that suspicious. That's an absurd example (hopefully funny) but _any_ from one of my routers over time would be obvious, especially since to be effective this would have to go on much of the time and in many routers. Hiding all that isn't feasible for a really technically astute company and they're not in that category yet (IMO). > It all depends on what you're trying to accomplish. Hijacking many cat photos to send your cat photo... how deep is your DPI? Remember also, the answer to the universe fits in 6 bits... Mike From nick at foobar.org Thu Jun 13 17:25:15 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Jun 2013 18:25:15 +0100 Subject: peeringdb accuracy research In-Reply-To: <4AE99398-F324-4255-9248-570D92222DF7@atrato.com> References: <4AE99398-F324-4255-9248-570D92222DF7@atrato.com> Message-ID: <51BA007B.4010004@foobar.org> On 13/06/2013 17:48, Job Snijders wrote: > Good news everyone, 99% of the parsable data in PeeringDB is valid! :-) you mean: 99% of the parsable data in PeeringDB which is maintained by people conscientious enough to provide the output of "show bgp sum" from their routers, is valid. Good talk, and interesting research, but I have a feeling that there might be some unintentional researcher bias creeping in there. :-) Nick From wbailey at satelliteintelligencegroup.com Thu Jun 13 17:35:55 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 13 Jun 2013 17:35:55 +0000 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> , Message-ID: They are a state controlled company. You think the PRC's party members dont call the shots? I've been to Beijing for work.. I can assure you the government has a very known presence through the private community. Often times, graduates of their state run colleges enter the "private" sector to help their collective needs. China is an odd place, but in my opinion often they are underestimated. Look at their stealth plane, that's a good starting point on their ability to borrow technology and implement it quickly. It's about numbers over there, not sense. Sent from my Mobile Device. -------- Original message -------- From: Scott Helms Date: 06/13/2013 10:22 AM (GMT-08:00) To: Nick Khamis Cc: NANOG Subject: Re: huawei Not really, no one has claimed it's impossible to hide traffic. What is true is that it's not feasible to do so at scale without it becoming obvious. Steganography is great for hiding traffic inside of legitimate traffic between two hosts but if one of my routers starts sending cay photos somewhere, no matter how cute, I'm gonna consider that suspicious. That's an absurd example (hopefully funny) but _any_ from one of my routers over time would be obvious, especially since to be effective this would have to go on much of the time and in many routers. Hiding all that isn't feasible for a really technically astute company and they're not in that category yet (IMO). On Jun 13, 2013 1:10 PM, "Nick Khamis" wrote: > On 6/13/13, Michael Thomas wrote: > > On 06/13/2013 09:35 AM, Patrick W. Gilmore wrote: > >> > >> I am assuming a not-Hauwei-only network. > >> > >> The idea that a router could send things through other routers without > >> someone who is looking for it noticing is ludicrous. > >> > > > > ::cough:: steganography ::cough:: > > > > Mike > > > > > > Well put! > > N. > > From bicknell at ufp.org Thu Jun 13 17:42:38 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 13 Jun 2013 12:42:38 -0500 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: <33448B0E-AA52-4904-85EE-1DF2A7E3F8E8@ufp.org> On Jun 13, 2013, at 11:35 AM, Patrick W. Gilmore wrote: > Also, I find it difficult to believe Hauwei has the ability to do DPI or something inside their box and still route at reasonable speeds is a bit silly. Perhaps they only duplicate packets based on source/dest IP address or something that is magically messaged from the mother ship, but I am dubious. This could be a latent, not used feature from _any_ vendor. A hard coded backdoor password and username. A sequence of port-knocking that enables ssh on an alternate port with no ACL. Logins through that mechanism not in syslog, not in the currently logged in user table, perhaps the process(es) hidden from view. Do we really trust Cisco and Juniper more than Hueawei? :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From khelms at zcorum.com Thu Jun 13 17:45:03 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 13:45:03 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA0044.2050601@mtcc.com> Message-ID: That is far more feasible than mass interception and forwarding of traffic, though there is (AFAIK) no indication that such a kill switch exists. I also think that if China wanted to do something nefarious a far better target would be Lenovo, which still seems to be an accepted vendor in US government circled judging from the number I've seen in DC this week and laptops have far more horsepower and storage most pieces of networking gear. On Jun 13, 2013 1:35 PM, "Mark Gallagher" wrote: > I think one of the possibilities suggested beyond call-home or backdoors > was that they might have installed a secret kill-switch to be activated > against 'enemy' nodes in time of war was an cyber shock and awe campaign. > > mg > > > > > > On Thu, Jun 13, 2013 at 8:24 PM, Michael Thomas wrote: > >> On 06/13/2013 10:20 AM, Scott Helms wrote: >> >>> >>> Not really, no one has claimed it's impossible to hide traffic. What >>> is true is that it's not feasible to do so at scale without it becoming >>> obvious. Steganography is great for hiding traffic inside of legitimate >>> traffic between two hosts but if one of my routers starts sending cay >>> photos somewhere, no matter how cute, I'm gonna consider that suspicious. >>> That's an absurd example (hopefully funny) but _any_ from one of my >>> routers over time would be obvious, especially since to be effective this >>> would have to go on much of the time and in many routers. Hiding all that >>> isn't feasible for a really technically astute company and they're not in >>> that category yet (IMO). >>> >>> >> It all depends on what you're trying to accomplish. Hijacking many cat >> photos to >> send your cat photo... how deep is your DPI? >> >> Remember also, the answer to the universe fits in 6 bits... >> >> Mike >> >> > From philfagan at gmail.com Thu Jun 13 17:54:40 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 11:54:40 -0600 Subject: huawei In-Reply-To: <33448B0E-AA52-4904-85EE-1DF2A7E3F8E8@ufp.org> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <33448B0E-AA52-4904-85EE-1DF2A7E3F8E8@ufp.org> Message-ID: This is a good point; unless your taping your traffic and examining it for anything outside of the norm then would you ever see it? However, we are talking transport protocols, no? I would certainly hope the OOB network was monitored and controlled. Hmm.....a network of clients/servers strategically located at Huewai POPS with a sole pupose of creating sessions destined for control servers so as to create the ability to inject payload into packets that are actually destined for where you want the data to go. On Thu, Jun 13, 2013 at 11:42 AM, Leo Bicknell wrote: > > On Jun 13, 2013, at 11:35 AM, Patrick W. Gilmore > wrote: > > > Also, I find it difficult to believe Hauwei has the ability to do DPI or > something inside their box and still route at reasonable speeds is a bit > silly. Perhaps they only duplicate packets based on source/dest IP address > or something that is magically messaged from the mother ship, but I am > dubious. > > This could be a latent, not used feature from _any_ vendor. > > A hard coded backdoor password and username. A sequence of port-knocking > that enables ssh on an alternate port with no ACL. Logins through that > mechanism not in syslog, not in the currently logged in user table, perhaps > the process(es) hidden from view. > > Do we really trust Cisco and Juniper more than Hueawei? :) > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From nick at foobar.org Thu Jun 13 17:56:19 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Jun 2013 18:56:19 +0100 Subject: huawei In-Reply-To: <33448B0E-AA52-4904-85EE-1DF2A7E3F8E8@ufp.org> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <33448B0E-AA52-4904-85EE-1DF2A7E3F8E8@ufp.org> Message-ID: <51BA07C3.8000605@foobar.org> On 13/06/2013 18:42, Leo Bicknell wrote: > A hard coded backdoor password and username. e.g.: http://www.phenoelit.org/dpl/dpl.html Or alternatively if you want access to any huawei device with software older than about a year ago: http://phenoelit.org/stuff/Huawei_DEFCON_XX.pdf > A sequence of > port-knocking that enables ssh on an alternate port with no ACL. e.g. > http://krebsonsecurity.com/2013/01/backdoors-found-in-barracuda-networks-gear/ There's no need to resort to malice to explain these problems when alternative explanations exist. Nick From sfischer1967 at gmail.com Thu Jun 13 17:57:35 2013 From: sfischer1967 at gmail.com (Steven Fischer) Date: Thu, 13 Jun 2013 13:57:35 -0400 Subject: Cisco optics in Northern Virginia In-Reply-To: References: Message-ID: you could call universal understanding in herndon...not finding their number immediately On Thursday, June 13, 2013, Kevin D wrote: > Does anyone know where I could find a supplier of Cisco (or compatible) > optics in Northern Virginia? We're in a pinch in Ashburn and really need to > find a GLC-LH-SM locally. > > Thanks in advance. > > -Kevin Dougherty > -- 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 mis at seiden.com Thu Jun 13 17:59:22 2013 From: mis at seiden.com (Mark Seiden) Date: Thu, 13 Jun 2013 10:59:22 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: there are lots of other attack scenarios besides the simple one you suggest, as people who try to analyze malware payloads by their outbound network activity have figured out. an attack could be time-driven, or driven by some very hard to interpret network signalling (such as a response to something the router would have a perfectly legitimate reason to ask an attacker about). which means you need to watch for an indefinite length of time (possibly forever) to see behavior. (in the malware world, the question is: how long do you run this in your sandbox to find the command and control?) covert channels have been known for many years, and outbound data could be encoded in a covert channel by timing (which is much more difficult to notice than content modification such as steganography as there are no specs and few expectations about timing). see http://www.crypto.com/papers/jbug-Usenix06-final.pdf for an wonderful example of a keyboard specially modified to leak passwords by modulating the timing in an ssh channel snooped between the admin and the router. the volume of data need not be huge. a login and password, for example, can be leaked out in a covert channel without the likelihood of anyone noticing, and would provide subsequent access to the router in case of need, which is good enough for many military purposes. finally, denial of service on a network component could be implemented by watching for a sequence of out of spec packets of death. only someone doing impossibly exhaustive fuzzing might see the result, and it would be indistinguishable from a bug. On Jun 13, 2013, at 9:35 AM, "Patrick W. Gilmore" wrote: > On Jun 13, 2013, at 12:28 , "Avi Freedman" wrote: > >> I disagree. >> >> There have already been lab demos of sfps that could inject frames and APTs are pretty advanced, sinister, and can be hard to detect now. >> >> I'm not suggesting Huawei is or isn't enabling badness globally but I think it would be technically feasible. > > I am assuming a not-Hauwei-only network. > > The idea that a router could send things through other routers without someone who is looking for it noticing is ludicrous. > > Of course, most people aren't paying attention, a few extra frames wouldn't be noticed most likely. But if you are worried about it, you should be looking. > > Also, I find it difficult to believe Hauwei has the ability to do DPI or something inside their box and still route at reasonable speeds is a bit silly. Perhaps they only duplicate packets based on source/dest IP address or something that is magically messaged from the mother ship, but I am dubious. > > It should be trivial to prove to yourself the box is, or is not, doing something evil if you actually try. > > -- > TTFN, > patrick > > >> ------Original Message------ >> From: Patrick W. Gilmore >> To: NANOG list >> Subject: Re: huawei >> Sent: Jun 13, 2013 12:22 PM >> >> On Jun 13, 2013, at 12:18 , Nick Khamis wrote: >> >>> A local clec here in Canada just teamed up with this company to >>> provide cell service to the north: >>> >>> http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for-3g-wireless-network-in-northern-canada/ >>> >>> Scary.... >> >> Why? >> >> Do you think Huawei has a magic ability to transmit data without you noticing? >> >> If you don't want to use Hauwei because they stole code or did other nasty things, I'm right there with you. If you believe a router can somehow magically duplicate info and transport it back to China (ignoring CT/CU's inability to have congestion free links), I think you are confused. >> >> -- >> TTFN, >> patrick >> >> >> > > From Bryan at bryanfields.net Thu Jun 13 19:28:00 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 13 Jun 2013 15:28:00 -0400 Subject: huawei (ZTE too) In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> , Message-ID: <51BA1D40.6050301@bryanfields.net> On 6/13/13 1:35 PM, Warren Bailey wrote: > They are a state controlled company. You think the PRC's party members dont > call the shots? I've been to Beijing for work.. I can assure you the > government has a very known presence through the private community. Often > times, graduates of their state run colleges enter the "private" sector to > help their collective needs. China is an odd place, but in my opinion often > they are underestimated. Look at their stealth plane, that's a good > starting point on their ability to borrow technology and implement it > quickly. It's about numbers over there, not sense. My objection to ZTE/Hauwei when I was at a cellular telco was just this. I said "there was no way I can agree with Chinese nationals having unfettered access to our network". Sure the CLI was crap/nonexistent and full of bugs, but I never thought the product was phoning home. I assumed there was a backdoor, like every other product and this was dealt with via ACL's and bastion boxes. I did not think highly of the product, and did not want to select it. However ZTE made the offer to put 6 support engineers in our main switch office 24/7 for the first year, and open an office down the street. Our SVP creamed himself over this level of "support" and they got the contract. It's an awesome idea, build gear that's cheap enough you can't say no to, and use the support personnel as spies. It provides a perfect cover story to cycle in loads of engineers. Only one or two does the support, the rest can observe/record/share the internal details of everything they see. They are playing our love of "But Wait There's More!". Give us everything at deep discounts or for free and receive direct access to the core of every major telecom company on the planet. For a few hundred million dollars the Chinese government has intelligence on anyone or anything world wide, and their agents are welcomed with open arms. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From morrowc.lists at gmail.com Thu Jun 13 19:32:28 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Jun 2013 15:32:28 -0400 Subject: huawei (ZTE too) In-Reply-To: <51BA1D40.6050301@bryanfields.net> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> Message-ID: On Thu, Jun 13, 2013 at 3:28 PM, Bryan Fields wrote: > They are playing our love of "But Wait There's More!". Give us everything at > deep discounts or for free and receive direct access to the core of every > major telecom company on the planet. For a few hundred million dollars the > Chinese government has intelligence on anyone or anything world wide, and > their agents are welcomed with open arms. both cisco and juniper do this as well.. with phone-home full show-tech-equivalent data collection systems... all pushed into an internal DB ready for marketing/etc... I'm sure other vendors (ALU/etc) all do this as well... the addition of 'Dedicated Support Engineers' sitting in your faciltiy is neat, but also not 'new' wrt cisco/juniper. (I also happen to think that this is probably the method most likely used to exfil data of interest) From ewust at umich.edu Thu Jun 13 19:32:51 2013 From: ewust at umich.edu (Eric Wustrow) Date: Thu, 13 Jun 2013 15:32:51 -0400 Subject: Blocking TCP flows? Message-ID: Hi all, I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 gbps link, with new blocked flows being dropped within a millisecond or so of being added. I've been looking into using OpenFlow on an HP Procurve, but I don't know much in this area, so I'm looking for better alternatives. Ideally, such a device would add minimal latency (many/expandable CAM entries?), can handle many programatically added flows (hundreds per second), and would be deployable in a production network (fails in bypass mode). Are there any COTS devices I should be looking at? Or is the market for this all under the table to pro-censorship governments? Thanks, -Eric From Joel.Snyder at Opus1.COM Thu Jun 13 19:36:15 2013 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Thu, 13 Jun 2013 21:36:15 +0200 Subject: huawei Message-ID: <51BA1F2F.5010407@opus1.com> If this hasn't been beaten to death, a longer discussion of the threat of Huawei/ZTE is discussed in this article I wrote for Information Security a few months back: http://searchsecurity.techtarget.com/feature/The-Huawei-security-risk-Factors-to-consider-before-buying-Chinese-IT jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From swmike at swm.pp.se Thu Jun 13 19:41:48 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 13 Jun 2013 21:41:48 +0200 (CEST) Subject: huawei (ZTE too) In-Reply-To: <51BA1D40.6050301@bryanfields.net> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> , <51BA1D40.6050301@bryanfields.net> Message-ID: On Thu, 13 Jun 2013, Bryan Fields wrote: > My objection to ZTE/Hauwei when I was at a cellular telco was just this. > I said "there was no way I can agree with Chinese nationals having > unfettered access to our network". Why would anyone outside of the US agree to have US products in their network, using the same rationale? At least with China they don't pretend they're not spying on our own population. -- Mikael Abrahamsson email: swmike at swm.pp.se From wbailey at satelliteintelligencegroup.com Thu Jun 13 19:44:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 13 Jun 2013 19:44:21 +0000 Subject: huawei (ZTE too) In-Reply-To: <51BA1D40.6050301@bryanfields.net> Message-ID: Is that also not possibly the case with Cisco, Juniper, XYZ network equipment vendors? If the Chinese are doing it, I would imagine we (along with our pals) are doing it as well. It'll be interesting to see what NSA dox this guy drops in the coming days and weeks ahead. All of the TV pundits were screaming Hong Kong was going to give him up, until he released information on a program relating to penetrating foreign government networks. I think the dynamics of China and their behavior after the release(s) will factor in greatly into contract awards in the future. Granted he hasn't released any information on compromising physical hardware for the moment, but if that were to come to light it would murder .cn imports of gear almost immediately. If we were doing it, and they weren't .. They will now. At the end of the day, we are almost ALWAYS more than willing to give them our IP and state secrets in order to (a) buy something really cheap or (b) sell something really expensive. I'm sure it's completely understood within the intelligence communities what capabilities the Chinese have, mostly because we probably gave or sold it to them at some point. They haven't ALWAYS made their own hardware, and they still bring quite a bit in through creative channels. On 6/13/13 12:28 PM, "Bryan Fields" wrote: >On 6/13/13 1:35 PM, Warren Bailey wrote: >> They are a state controlled company. You think the PRC's party members >>dont >> call the shots? I've been to Beijing for work.. I can assure you the >> government has a very known presence through the private community. >>Often >> times, graduates of their state run colleges enter the "private" sector >>to >> help their collective needs. China is an odd place, but in my opinion >>often >> they are underestimated. Look at their stealth plane, that's a good >> starting point on their ability to borrow technology and implement it >> quickly. It's about numbers over there, not sense. > >My objection to ZTE/Hauwei when I was at a cellular telco was just this. >I >said "there was no way I can agree with Chinese nationals having >unfettered >access to our network". > >Sure the CLI was crap/nonexistent and full of bugs, but I never thought >the >product was phoning home. I assumed there was a backdoor, like every >other >product and this was dealt with via ACL's and bastion boxes. > >I did not think highly of the product, and did not want to select it. >However >ZTE made the offer to put 6 support engineers in our main switch office >24/7 >for the first year, and open an office down the street. Our SVP creamed >himself over this level of "support" and they got the contract. > >It's an awesome idea, build gear that's cheap enough you can't say no to, >and >use the support personnel as spies. It provides a perfect cover story to >cycle in loads of engineers. Only one or two does the support, the rest >can >observe/record/share the internal details of everything they see. > >They are playing our love of "But Wait There's More!". Give us everything >at >deep discounts or for free and receive direct access to the core of every >major telecom company on the planet. For a few hundred million dollars >the >Chinese government has intelligence on anyone or anything world wide, and >their agents are welcomed with open arms. > > >-- >Bryan Fields > >727-409-1194 - Voice >727-214-2508 - Fax >http://bryanfields.net > From Bryan at bryanfields.net Thu Jun 13 19:47:39 2013 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 13 Jun 2013 15:47:39 -0400 Subject: huawei (ZTE too) In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> , <51BA1D40.6050301@bryanfields.net> Message-ID: <51BA21DB.7090206@bryanfields.net> On 6/13/13 3:41 PM, Mikael Abrahamsson wrote: >> > My objection to ZTE/Hauwei when I was at a cellular telco was just this. >> > I said "there was no way I can agree with Chinese nationals having >> > unfettered access to our network". > Why would anyone outside of the US agree to have US products in their > network, using the same rationale? At least with China they don't pretend > they're not spying on our own population. /me taps nose -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From davidpeahi at gmail.com Thu Jun 13 20:01:03 2013 From: davidpeahi at gmail.com (david peahi) Date: Thu, 13 Jun 2013 13:01:03 -0700 Subject: huawei (ZTE too) In-Reply-To: <51BA1D40.6050301@bryanfields.net> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> Message-ID: Apologies for making what could be construed as an off topic, political comment, but doesn't everyone in the USA know by now that the PRC represents a dagger aimed at the economic and national security of America? A military invasion in slow motion as it were? David On Thu, Jun 13, 2013 at 12:28 PM, Bryan Fields wrote: > On 6/13/13 1:35 PM, Warren Bailey wrote: > > They are a state controlled company. You think the PRC's party members > dont > > call the shots? I've been to Beijing for work.. I can assure you the > > government has a very known presence through the private community. Often > > times, graduates of their state run colleges enter the "private" sector > to > > help their collective needs. China is an odd place, but in my opinion > often > > they are underestimated. Look at their stealth plane, that's a good > > starting point on their ability to borrow technology and implement it > > quickly. It's about numbers over there, not sense. > > My objection to ZTE/Hauwei when I was at a cellular telco was just this. I > said "there was no way I can agree with Chinese nationals having unfettered > access to our network". > > Sure the CLI was crap/nonexistent and full of bugs, but I never thought the > product was phoning home. I assumed there was a backdoor, like every other > product and this was dealt with via ACL's and bastion boxes. > > I did not think highly of the product, and did not want to select it. > However > ZTE made the offer to put 6 support engineers in our main switch office > 24/7 > for the first year, and open an office down the street. Our SVP creamed > himself over this level of "support" and they got the contract. > > It's an awesome idea, build gear that's cheap enough you can't say no to, > and > use the support personnel as spies. It provides a perfect cover story to > cycle in loads of engineers. Only one or two does the support, the rest > can > observe/record/share the internal details of everything they see. > > They are playing our love of "But Wait There's More!". Give us everything > at > deep discounts or for free and receive direct access to the core of every > major telecom company on the planet. For a few hundred million dollars the > Chinese government has intelligence on anyone or anything world wide, and > their agents are welcomed with open arms. > > > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net > > From morrowc.lists at gmail.com Thu Jun 13 20:03:15 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Jun 2013 16:03:15 -0400 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 3:32 PM, Eric Wustrow wrote: > Hi all, > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 gbps > link, with new blocked flows being dropped within a millisecond or so of > being > added. I've been looking into using OpenFlow on an HP Procurve, but I don't > know much in this area, so I'm looking for better alternatives. > this sounds like a job for the arista box with the FGPA onboard, no? > Ideally, such a device would add minimal latency (many/expandable CAM > entries?), can handle many programatically added flows (hundreds per > second), > and would be deployable in a production network (fails in bypass mode). Are > there any > COTS devices I should be looking at? Or is the market for this all under > the table to > pro-censorship governments? > > Thanks, > > -Eric From jeroen at massar.ch Thu Jun 13 20:36:17 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Thu, 13 Jun 2013 13:36:17 -0700 Subject: huawei (ZTE too) In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> Message-ID: <51BA2D41.8040906@massar.ch> On 2013-06-13 13:01, david peahi wrote: > Apologies for making what could be construed as an off topic, political > comment, but doesn't everyone in the USA know by now that the PRC > represents a dagger aimed at the economic and national security of America? > A military invasion in slow motion as it were? Please realize that one can make that statement from every side of the fence. It all just depends on which side of the fence you are born, if you consider one thing "good" or "evil" and as recent events show, you should be looking a bit closer at the home base... And now after this whole flood of messages about this... lets please go back to operations, thanks! Greets, Jeroen From philfagan at gmail.com Thu Jun 13 20:47:58 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 14:47:58 -0600 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: I didn't think the bus up to the FGPA was very beefy...wouldn't you need to send flows up there off the data-plane for inspection? On Thu, Jun 13, 2013 at 2:03 PM, Christopher Morrow wrote: > On Thu, Jun 13, 2013 at 3:32 PM, Eric Wustrow wrote: > > Hi all, > > > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 > gbps > > link, with new blocked flows being dropped within a millisecond or so of > > being > > added. I've been looking into using OpenFlow on an HP Procurve, but I > don't > > know much in this area, so I'm looking for better alternatives. > > > > this sounds like a job for the arista box with the FGPA onboard, no? > > > > Ideally, such a device would add minimal latency (many/expandable CAM > > entries?), can handle many programatically added flows (hundreds per > > second), > > and would be deployable in a production network (fails in bypass mode). > Are > > there any > > COTS devices I should be looking at? Or is the market for this all under > > the table to > > pro-censorship governments? > > > > Thanks, > > > > -Eric > > -- Phil Fagan Denver, CO 970-480-7618 From morrowc.lists at gmail.com Thu Jun 13 20:52:53 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Jun 2013 16:52:53 -0400 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 4:47 PM, Phil Fagan wrote: > I didn't think the bus up to the FGPA was very beefy...wouldn't you need to > send flows up there off the data-plane for inspection? > not sure, but their docs talk about using the fpga for doing HFT... so I presume it's got the abiliity to see all traffic on at least on interface, eh? (I believe the fpga is really connected to the bus as a 10g link... but I haven't tried this I've only read their docs) > On Thu, Jun 13, 2013 at 2:03 PM, Christopher Morrow > wrote: >> >> On Thu, Jun 13, 2013 at 3:32 PM, Eric Wustrow wrote: >> > Hi all, >> > >> > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 >> > gbps >> > link, with new blocked flows being dropped within a millisecond or so of >> > being >> > added. I've been looking into using OpenFlow on an HP Procurve, but I >> > don't >> > know much in this area, so I'm looking for better alternatives. >> > >> >> this sounds like a job for the arista box with the FGPA onboard, no? >> >> >> > Ideally, such a device would add minimal latency (many/expandable CAM >> > entries?), can handle many programatically added flows (hundreds per >> > second), >> > and would be deployable in a production network (fails in bypass mode). >> > Are >> > there any >> > COTS devices I should be looking at? Or is the market for this all under >> > the table to >> > pro-censorship governments? >> > >> > Thanks, >> > >> > -Eric >> > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 From markwgallagher at gmail.com Thu Jun 13 17:35:43 2013 From: markwgallagher at gmail.com (Mark Gallagher) Date: Thu, 13 Jun 2013 20:35:43 +0300 Subject: huawei In-Reply-To: <51BA0044.2050601@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA0044.2050601@mtcc.com> Message-ID: I think one of the possibilities suggested beyond call-home or backdoors was that they might have installed a secret kill-switch to be activated against 'enemy' nodes in time of war was an cyber shock and awe campaign. mg On Thu, Jun 13, 2013 at 8:24 PM, Michael Thomas wrote: > On 06/13/2013 10:20 AM, Scott Helms wrote: > >> >> Not really, no one has claimed it's impossible to hide traffic. What is >> true is that it's not feasible to do so at scale without it becoming >> obvious. Steganography is great for hiding traffic inside of legitimate >> traffic between two hosts but if one of my routers starts sending cay >> photos somewhere, no matter how cute, I'm gonna consider that suspicious. >> That's an absurd example (hopefully funny) but _any_ from one of my >> routers over time would be obvious, especially since to be effective this >> would have to go on much of the time and in many routers. Hiding all that >> isn't feasible for a really technically astute company and they're not in >> that category yet (IMO). >> >> > It all depends on what you're trying to accomplish. Hijacking many cat > photos to > send your cat photo... how deep is your DPI? > > Remember also, the answer to the universe fits in 6 bits... > > Mike > > From kevind at inmotionhosting.com Thu Jun 13 21:09:32 2013 From: kevind at inmotionhosting.com (Kevin D) Date: Thu, 13 Jun 2013 16:09:32 -0500 Subject: Cisco optics in Northern Virginia In-Reply-To: References: Message-ID: Thank you everyone for the help with this. We got what we needed. -Kevin Dougherty On Thu, Jun 13, 2013 at 12:07 PM, Kevin D wrote: > Does anyone know where I could find a supplier of Cisco (or compatible) > optics in Northern Virginia? We're in a pinch in Ashburn and really need to > find a GLC-LH-SM locally. > > Thanks in advance. > > -Kevin Dougherty > From jof at thejof.com Thu Jun 13 21:11:51 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 13 Jun 2013 14:11:51 -0700 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: Are you trying to block flows from becoming established, knowing what you're looking for ahead of time, or are you looking to examine a stream of flow establishments, and will snipe off some flows once you've determined that they should be blocked? If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you want to block ahead of time, just place an ACL. It depends on the platform, but those that implement them in hardware can filter a lot of traffic very quickly. However, they're not a great tool when you want to dynamically reconfigure the rules. For high-touch inspection, I'd recommend a stripe of Linux boxes, with traffic being ECMP-balanced across all of them, sitting in-line on the traffic path. It adds a tiny bit of latency, but can scale up to process large traffic paths and apply complex inspections on the traffic. Cheers, jof On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow wrote: > Hi all, > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 gbps > link, with new blocked flows being dropped within a millisecond or so of > being > added. I've been looking into using OpenFlow on an HP Procurve, but I don't > know much in this area, so I'm looking for better alternatives. > > Ideally, such a device would add minimal latency (many/expandable CAM > entries?), can handle many programatically added flows (hundreds per > second), > and would be deployable in a production network (fails in bypass mode). Are > there any > COTS devices I should be looking at? Or is the market for this all under > the table to > pro-censorship governments? > > Thanks, > > -Eric From randy at psg.com Thu Jun 13 21:26:47 2013 From: randy at psg.com (Randy Bush) Date: Thu, 13 Jun 2013 23:26:47 +0200 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: > They are a state controlled company. You think the PRC's party members > dont call the shots? and you live in a police and surveillance state where the govt sniffs evey packet you send, ever phone call you make, ... other than style, what's the dfference? oh, i guess the chinese are only bombing their neighbors, not folk half a planet away. the differentiation may be an acquired taste. From davidpeahi at gmail.com Thu Jun 13 21:28:40 2013 From: davidpeahi at gmail.com (david peahi) Date: Thu, 13 Jun 2013 14:28:40 -0700 Subject: huawei (ZTE too) In-Reply-To: <51BA2D41.8040906@massar.ch> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> <51BA2D41.8040906@massar.ch> Message-ID: Last I heard NANOG stands for North American Network Operators Group. Anti-American comments are not welcome here.. David On Thu, Jun 13, 2013 at 1:36 PM, Jeroen Massar wrote: > On 2013-06-13 13:01, david peahi wrote: > > Apologies for making what could be construed as an off topic, political > > comment, but doesn't everyone in the USA know by now that the PRC > > represents a dagger aimed at the economic and national security of > America? > > A military invasion in slow motion as it were? > > Please realize that one can make that statement from every side of the > fence. > > It all just depends on which side of the fence you are born, if you > consider one thing "good" or "evil" and as recent events show, you > should be looking a bit closer at the home base... > > And now after this whole flood of messages about this... lets please go > back to operations, thanks! > > Greets, > Jeroen > > From jeroen at massar.ch Thu Jun 13 21:45:13 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Thu, 13 Jun 2013 14:45:13 -0700 Subject: huawei (ZTE too) In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> <51BA2D41.8040906@massar.ch> Message-ID: <51BA3D69.7070307@massar.ch> On 2013-06-13 14:28, david peahi wrote: > > Last I heard NANOG stands for North American Network Operators Group. > Anti-American comments are not welcome here.. (IMHO there was nothing 'anti-american' about my statement, though I guess it completely depends on what the definition of that would be; I am sure that a more longer standing NANOG member will personally kick me in the head to enlighten me if it was though...) Even though NANOG starts with the letters "NA", it is the most important public Internet operator forum, worldwide, hence why NANOG also has a lot of members from around the rest of world and gets input, and heck, presentations from the rest of the world, because that little Internet thing is worldwide. Also note that any impact happening on the Internet in the US has wide-spread consequences to the rest of the world and a back-door in gear in the US will be a back-door for the rest of the world too and they will be more than happy to know about that and will act and decide in similar fashion. But I think I wrote something about the O part of NANOG.... thus I'll /dev/null further list responses to this as it will just end up in a more useless flamewar. Greets, Jeroen (Written from the SFO area... not from a hotel in HK ;) From surfer at mauigateway.com Thu Jun 13 22:01:33 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 13 Jun 2013 15:01:33 -0700 Subject: huawei (ZTE too) Message-ID: <20130613150133.D4884C24@m0005296.ppops.net> On 2013-06-13 14:28, david peahi wrote: > > Last I heard NANOG stands for North American Network Operators Group. > Anti-American comments are not welcome here.. --------------------------------------------- Smiley? Smiley? I'm looking for the :-) but I don't see one. How about "crazy eyes"? <8-) scott From geekgirl at gmail.com Thu Jun 13 22:24:42 2013 From: geekgirl at gmail.com (Leslie) Date: Thu, 13 Jun 2013 15:24:42 -0700 Subject: huawei (ZTE too) In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> <51BA2D41.8040906@massar.ch> Message-ID: On Thu, Jun 13, 2013 at 2:28 PM, david peahi wrote: > Last I heard NANOG stands for North American Network Operators Group. > Anti-American comments are not welcome here.. > > As a matter of fact, North America includes 23 unique countries, not just the United States - http://en.wikipedia.org/wiki/North_america And, if you look at the NewNOG bylaws - http://www.nanog.org/governance/documents/NANOG-Bylaws-October2011.pdf - nothing is mentioned about disparaging any specific country. In fact the mission statement seems to be "The purpose of NANOG is to provide forums in the North American region for education and the sharing of knowledge for the Internet operations community." Leslie David > > > On Thu, Jun 13, 2013 at 1:36 PM, Jeroen Massar wrote: > > > On 2013-06-13 13:01, david peahi wrote: > > > Apologies for making what could be construed as an off topic, political > > > comment, but doesn't everyone in the USA know by now that the PRC > > > represents a dagger aimed at the economic and national security of > > America? > > > A military invasion in slow motion as it were? > > > > Please realize that one can make that statement from every side of the > > fence. > > > > It all just depends on which side of the fence you are born, if you > > consider one thing "good" or "evil" and as recent events show, you > > should be looking a bit closer at the home base... > > > > And now after this whole flood of messages about this... lets please go > > back to operations, thanks! > > > > Greets, > > Jeroen > > > > > From rsk at gsp.org Thu Jun 13 22:30:41 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 13 Jun 2013 18:30:41 -0400 Subject: huawei In-Reply-To: References: Message-ID: <20130613223041.GA4349@gsp.org> On Thu, Jun 13, 2013 at 06:10:39PM +0200, Randy Bush wrote: > we really should not be putting huawei kit into the backbone, there > might be backdoors where they can spy on our traffic This paper may be relevant to the topic at hand (h/t to Rob Slade): http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD-Microchips-From-China Abstract: This paper is a short summary of the first real world detection of a backdoor in a military grade FPGA. Using an innovative patented technique we were able to detect and analyse in the first documented case of its kind, a backdoor inserted into the Actel/Microsemi ProASIC3 chips. The backdoor was found to exist on the silicon itself, it was not present in any firmware loaded onto the chip. Using Pipeline Emission Analysis (PEA), a technique pioneered by our sponsor, we were able to extract the secret key to activate the backdoor. This way an attacker can disable all the security on the chip, reprogram crypto and access keys, modify low-level silicon features, access unencrypted configuration bitstream or permanently damage the device. Clearly this means the device is wide open to intellectual property theft, fraud, re-programming as well as reverse engineering of the design which allows the introduction of a new backdoor or Trojan. Most concerning, it is not possible to patch the backdoor in chips already deployed, meaning those using this family of chips have to accept the fact it can be easily compromised or it will have to be physically replaced after a redesign of the silicon itself. Unfortunately, it doesn't appear possible to download this paper without signing up for scribd. Perhaps it's available elsewhere without such onerous requirements. ---rsk From philfagan at gmail.com Thu Jun 13 22:37:57 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 16:37:57 -0600 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: I really like the idea of a stripe of linux boxes doing the heavy lifting. Any suggestions on platforms, card types, and chip types that might be better purposed at processing this type of data? I assume you could write some fast Perl to ingest and manage the tables? What would the package of choice be for something like this? On Thu, Jun 13, 2013 at 3:11 PM, Jonathan Lassoff wrote: > Are you trying to block flows from becoming established, knowing what > you're looking for ahead of time, or are you looking to examine a > stream of flow establishments, and will snipe off some flows once > you've determined that they should be blocked? > > If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you > want to block ahead of time, just place an ACL. It depends on the > platform, but those that implement them in hardware can filter a lot > of traffic very quickly. > However, they're not a great tool when you want to dynamically > reconfigure the rules. > > For high-touch inspection, I'd recommend a stripe of Linux boxes, with > traffic being ECMP-balanced across all of them, sitting in-line on the > traffic path. It adds a tiny bit of latency, but can scale up to > process large traffic paths and apply complex inspections on the > traffic. > > Cheers, > jof > > On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow wrote: > > Hi all, > > > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 > gbps > > link, with new blocked flows being dropped within a millisecond or so of > > being > > added. I've been looking into using OpenFlow on an HP Procurve, but I > don't > > know much in this area, so I'm looking for better alternatives. > > > > Ideally, such a device would add minimal latency (many/expandable CAM > > entries?), can handle many programatically added flows (hundreds per > > second), > > and would be deployable in a production network (fails in bypass mode). > Are > > there any > > COTS devices I should be looking at? Or is the market for this all under > > the table to > > pro-censorship governments? > > > > Thanks, > > > > -Eric > > -- Phil Fagan Denver, CO 970-480-7618 From philfagan at gmail.com Thu Jun 13 22:38:46 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 16:38:46 -0600 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: I would assume something FreeBSD based might be best.... On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan wrote: > I really like the idea of a stripe of linux boxes doing the heavy lifting. > Any suggestions on platforms, card types, and chip types that might be > better purposed at processing this type of data? > > I assume you could write some fast Perl to ingest and manage the tables? > What would the package of choice be for something like this? > > > On Thu, Jun 13, 2013 at 3:11 PM, Jonathan Lassoff wrote: > >> Are you trying to block flows from becoming established, knowing what >> you're looking for ahead of time, or are you looking to examine a >> stream of flow establishments, and will snipe off some flows once >> you've determined that they should be blocked? >> >> If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you >> want to block ahead of time, just place an ACL. It depends on the >> platform, but those that implement them in hardware can filter a lot >> of traffic very quickly. >> However, they're not a great tool when you want to dynamically >> reconfigure the rules. >> >> For high-touch inspection, I'd recommend a stripe of Linux boxes, with >> traffic being ECMP-balanced across all of them, sitting in-line on the >> traffic path. It adds a tiny bit of latency, but can scale up to >> process large traffic paths and apply complex inspections on the >> traffic. >> >> Cheers, >> jof >> >> On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow wrote: >> > Hi all, >> > >> > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 >> gbps >> > link, with new blocked flows being dropped within a millisecond or so of >> > being >> > added. I've been looking into using OpenFlow on an HP Procurve, but I >> don't >> > know much in this area, so I'm looking for better alternatives. >> > >> > Ideally, such a device would add minimal latency (many/expandable CAM >> > entries?), can handle many programatically added flows (hundreds per >> > second), >> > and would be deployable in a production network (fails in bypass mode). >> Are >> > there any >> > COTS devices I should be looking at? Or is the market for this all under >> > the table to >> > pro-censorship governments? >> > >> > Thanks, >> > >> > -Eric >> >> > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- Phil Fagan Denver, CO 970-480-7618 From morrowc.lists at gmail.com Thu Jun 13 22:41:46 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 Jun 2013 18:41:46 -0400 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 6:37 PM, Phil Fagan wrote: > fast Perl haha :) that's cute. From bill at herrin.us Thu Jun 13 22:45:18 2013 From: bill at herrin.us (William Herrin) Date: Thu, 13 Jun 2013 18:45:18 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: On Thu, Jun 13, 2013 at 1:20 PM, Scott Helms wrote: > if one of my routers starts sending cat > photos somewhere, no matter how cute, I'm gonna consider that suspicious. Hi Scott, If once every 24 hours or so your router borrows the source IP of a packet it recently passed and uses it to send a burst of 20 intentionally unacknowledged packets containing a cat photo, your odds of noticing are very close to zero and your odds of tracing it to the router are even worse. Implementing a magic-packet remote kill switch is even easier... and completely undetectable until used. With a little effort you could implement it in the forwarding hardware where even a thorough analysis of the firmware image can't detect it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeff-kell at utc.edu Thu Jun 13 22:48:48 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 13 Jun 2013 18:48:48 -0400 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: <51BA4C50.2090902@utc.edu> Better still, http://dilbert.com/strips/comic/1996-09-07/ Jeff On 6/13/2013 6:41 PM, Christopher Morrow wrote: > On Thu, Jun 13, 2013 at 6:37 PM, Phil Fagan wrote: >> fast Perl > haha :) that's cute. > From jof at thejof.com Thu Jun 13 22:49:25 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 13 Jun 2013 15:49:25 -0700 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 3:38 PM, Phil Fagan wrote: > I would assume something FreeBSD based might be best.... Meh... personal choice. I prefer Linux, mostly because I know it best and most network application development is taking place there. > On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan wrote: >> >> I really like the idea of a stripe of linux boxes doing the heavy lifting. >> Any suggestions on platforms, card types, and chip types that might be >> better purposed at processing this type of data? Personally, I'd use modern-ish Intel Ethernet NICs. They seem to have the best support in the kernel. >> I assume you could write some fast Perl to ingest and manage the tables? >> What would the package of choice be for something like this? Heh... "fast" Perl. As for programming the processing, I would do as much as possible in the kernel, as passing packets off to userland really slows everything down. If you really need to, I'd do something with Go and/or C these days. Using iptables and the "string" module to match patterns, you can chew through packets pretty efficiently. This comes with the caveat that this can only match against strings contained within a single packet; this doesn't do L4 stream reconstruction. You can do some incredibly-parallel stuff with ntop's PF_RING code, if you blow more traffic through a single core than it can chew through. It all depends on what you're trying to do. --j >> >> >> On Thu, Jun 13, 2013 at 3:11 PM, Jonathan Lassoff wrote: >>> >>> Are you trying to block flows from becoming established, knowing what >>> you're looking for ahead of time, or are you looking to examine a >>> stream of flow establishments, and will snipe off some flows once >>> you've determined that they should be blocked? >>> >>> If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you >>> want to block ahead of time, just place an ACL. It depends on the >>> platform, but those that implement them in hardware can filter a lot >>> of traffic very quickly. >>> However, they're not a great tool when you want to dynamically >>> reconfigure the rules. >>> >>> For high-touch inspection, I'd recommend a stripe of Linux boxes, with >>> traffic being ECMP-balanced across all of them, sitting in-line on the >>> traffic path. It adds a tiny bit of latency, but can scale up to >>> process large traffic paths and apply complex inspections on the >>> traffic. >>> >>> Cheers, >>> jof >>> >>> On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow wrote: >>> > Hi all, >>> > >>> > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 >>> > gbps >>> > link, with new blocked flows being dropped within a millisecond or so >>> > of >>> > being >>> > added. I've been looking into using OpenFlow on an HP Procurve, but I >>> > don't >>> > know much in this area, so I'm looking for better alternatives. >>> > >>> > Ideally, such a device would add minimal latency (many/expandable CAM >>> > entries?), can handle many programatically added flows (hundreds per >>> > second), >>> > and would be deployable in a production network (fails in bypass mode). >>> > Are >>> > there any >>> > COTS devices I should be looking at? Or is the market for this all >>> > under >>> > the table to >>> > pro-censorship governments? >>> > >>> > Thanks, >>> > >>> > -Eric >>> >> >> >> >> -- >> Phil Fagan >> Denver, CO >> 970-480-7618 > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 From surfer at mauigateway.com Thu Jun 13 22:52:56 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 13 Jun 2013 15:52:56 -0700 Subject: huawei Message-ID: <20130613155256.D48845DD@m0005296.ppops.net> --- rsk at gsp.org wrote: From: Rich Kulawiec On Thu, Jun 13, 2013 at 06:10:39PM +0200, Randy Bush wrote: > we really should not be putting huawei kit into the backbone, there > might be backdoors where they can spy on our traffic This paper may be relevant to the topic at hand (h/t to Rob Slade): http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD-Microchips-From-China Unfortunately, it doesn't appear possible to download this paper without signing up for scribd. Perhaps it's available elsewhere without such onerous requirements. --------------------------------- http://www.cl.cam.ac.uk/~sps32/ches2012-backdoor.pdf scott From choprboy at dakotacom.net Thu Jun 13 22:55:24 2013 From: choprboy at dakotacom.net (Adrian) Date: Thu, 13 Jun 2013 15:55:24 -0700 Subject: huawei In-Reply-To: <20130613223041.GA4349@gsp.org> References: <20130613223041.GA4349@gsp.org> Message-ID: <201306131555.24512.choprboy@dakotacom.net> On Thursday 13 June 2013 15:30, Rich Kulawiec wrote: > On Thu, Jun 13, 2013 at 06:10:39PM +0200, Randy Bush wrote: > > we really should not be putting huawei kit into the backbone, there > > might be backdoors where they can spy on our traffic > > This paper may be relevant to the topic at hand (h/t to Rob Slade): > > http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD-Microchips-Fr >om-China Extraordinary claims require extra ordinary proof. http://erratasec.blogspot.com/2012/05/bogus-story-no-chinese-backdoor-in.html http://www.csoonline.com/article/707542/china-not-to-blame-for-backdoor-in-us-military-chip Adrian From pmbailey2 at yahoo.com Thu Jun 13 23:02:23 2013 From: pmbailey2 at yahoo.com (Patrick Bailey) Date: Thu, 13 Jun 2013 19:02:23 -0400 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: Procera Networks -- http://proceranetworks.com That will do what you want. Thanks, --- Patrick Bailey On Jun 13, 2013, at 3:32 PM, Eric Wustrow wrote: > Hi all, > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 gbps > link, with new blocked flows being dropped within a millisecond or so of > being > added. I've been looking into using OpenFlow on an HP Procurve, but I don't > know much in this area, so I'm looking for better alternatives. > > Ideally, such a device would add minimal latency (many/expandable CAM > entries?), can handle many programatically added flows (hundreds per > second), > and would be deployable in a production network (fails in bypass mode). Are > there any > COTS devices I should be looking at? Or is the market for this all under > the table to > pro-censorship governments? > > Thanks, > > -Eric From philfagan at gmail.com Thu Jun 13 23:05:06 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 17:05:06 -0600 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: Yeah, I only thought of perl cause I'm used to running through 'while true' loops and someone showed me Perl was about 400x faster....good thing I'm not running through 10gb/s worth of data :-D Figured getting closer to hardware was the way to go.....I'll have to check out PF_RING. On Thu, Jun 13, 2013 at 4:49 PM, Jonathan Lassoff wrote: > On Thu, Jun 13, 2013 at 3:38 PM, Phil Fagan wrote: > > I would assume something FreeBSD based might be best.... > > Meh... personal choice. I prefer Linux, mostly because I know it best > and most network application development is taking place there. > > > On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan wrote: > >> > >> I really like the idea of a stripe of linux boxes doing the heavy > lifting. > >> Any suggestions on platforms, card types, and chip types that might be > >> better purposed at processing this type of data? > > Personally, I'd use modern-ish Intel Ethernet NICs. They seem to have > the best support in the kernel. > > >> I assume you could write some fast Perl to ingest and manage the tables? > >> What would the package of choice be for something like this? > > Heh... "fast" Perl. > As for programming the processing, I would do as much as possible in > the kernel, as passing packets off to userland really slows everything > down. > If you really need to, I'd do something with Go and/or C these days. > > Using iptables and the "string" module to match patterns, you can chew > through packets pretty efficiently. This comes with the caveat that > this can only match against strings contained within a single packet; > this doesn't do L4 stream reconstruction. > > You can do some incredibly-parallel stuff with ntop's PF_RING code, if > you blow more traffic through a single core than it can chew through. > > It all depends on what you're trying to do. > > --j > >> > >> > >> On Thu, Jun 13, 2013 at 3:11 PM, Jonathan Lassoff > wrote: > >>> > >>> Are you trying to block flows from becoming established, knowing what > >>> you're looking for ahead of time, or are you looking to examine a > >>> stream of flow establishments, and will snipe off some flows once > >>> you've determined that they should be blocked? > >>> > >>> If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you > >>> want to block ahead of time, just place an ACL. It depends on the > >>> platform, but those that implement them in hardware can filter a lot > >>> of traffic very quickly. > >>> However, they're not a great tool when you want to dynamically > >>> reconfigure the rules. > >>> > >>> For high-touch inspection, I'd recommend a stripe of Linux boxes, with > >>> traffic being ECMP-balanced across all of them, sitting in-line on the > >>> traffic path. It adds a tiny bit of latency, but can scale up to > >>> process large traffic paths and apply complex inspections on the > >>> traffic. > >>> > >>> Cheers, > >>> jof > >>> > >>> On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow > wrote: > >>> > Hi all, > >>> > > >>> > I'm looking for a way to block individual TCP flows (5-tuple) on a > 1-10 > >>> > gbps > >>> > link, with new blocked flows being dropped within a millisecond or so > >>> > of > >>> > being > >>> > added. I've been looking into using OpenFlow on an HP Procurve, but I > >>> > don't > >>> > know much in this area, so I'm looking for better alternatives. > >>> > > >>> > Ideally, such a device would add minimal latency (many/expandable CAM > >>> > entries?), can handle many programatically added flows (hundreds per > >>> > second), > >>> > and would be deployable in a production network (fails in bypass > mode). > >>> > Are > >>> > there any > >>> > COTS devices I should be looking at? Or is the market for this all > >>> > under > >>> > the table to > >>> > pro-censorship governments? > >>> > > >>> > Thanks, > >>> > > >>> > -Eric > >>> > >> > >> > >> > >> -- > >> Phil Fagan > >> Denver, CO > >> 970-480-7618 > > > > > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > -- Phil Fagan Denver, CO 970-480-7618 From ag4ve.us at gmail.com Thu Jun 13 23:31:41 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 13 Jun 2013 19:31:41 -0400 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: Johnathan is correct about not using perl for this. There are some iptables modules, but they're all out of date or incomplete (I mention this because if you get around to making them work decent, I'll love you for it). Otherwise, perl -> IPC::Run -> ipt isn't going to gain you anything. And I'd be amazed if you could even keep up with a gbit. Per signature detection, see Bro. Though, it seems the ipt state module might fit the bill just fine. And you could log that and then have an ETL that scraped your log file and created a new ACL based on that (so that hardware could do the majority of the work). I'm sure an ipt -> acl isn't a new idea and you can probably find something that handles most edge cases. On Jun 13, 2013 7:12 PM, "Phil Fagan" wrote: > Yeah, I only thought of perl cause I'm used to running through 'while true' > loops and someone showed me Perl was about 400x faster....good thing I'm > not running through 10gb/s worth of data :-D > > Figured getting closer to hardware was the way to go.....I'll have to check > out PF_RING. > > > > > On Thu, Jun 13, 2013 at 4:49 PM, Jonathan Lassoff wrote: > > > On Thu, Jun 13, 2013 at 3:38 PM, Phil Fagan wrote: > > > I would assume something FreeBSD based might be best.... > > > > Meh... personal choice. I prefer Linux, mostly because I know it best > > and most network application development is taking place there. > > > > > On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan > wrote: > > >> > > >> I really like the idea of a stripe of linux boxes doing the heavy > > lifting. > > >> Any suggestions on platforms, card types, and chip types that might be > > >> better purposed at processing this type of data? > > > > Personally, I'd use modern-ish Intel Ethernet NICs. They seem to have > > the best support in the kernel. > > > > >> I assume you could write some fast Perl to ingest and manage the > tables? > > >> What would the package of choice be for something like this? > > > > Heh... "fast" Perl. > > As for programming the processing, I would do as much as possible in > > the kernel, as passing packets off to userland really slows everything > > down. > > If you really need to, I'd do something with Go and/or C these days. > > > > Using iptables and the "string" module to match patterns, you can chew > > through packets pretty efficiently. This comes with the caveat that > > this can only match against strings contained within a single packet; > > this doesn't do L4 stream reconstruction. > > > > You can do some incredibly-parallel stuff with ntop's PF_RING code, if > > you blow more traffic through a single core than it can chew through. > > > > It all depends on what you're trying to do. > > > > --j > > >> > > >> > > >> On Thu, Jun 13, 2013 at 3:11 PM, Jonathan Lassoff > > wrote: > > >>> > > >>> Are you trying to block flows from becoming established, knowing what > > >>> you're looking for ahead of time, or are you looking to examine a > > >>> stream of flow establishments, and will snipe off some flows once > > >>> you've determined that they should be blocked? > > >>> > > >>> If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you > > >>> want to block ahead of time, just place an ACL. It depends on the > > >>> platform, but those that implement them in hardware can filter a lot > > >>> of traffic very quickly. > > >>> However, they're not a great tool when you want to dynamically > > >>> reconfigure the rules. > > >>> > > >>> For high-touch inspection, I'd recommend a stripe of Linux boxes, > with > > >>> traffic being ECMP-balanced across all of them, sitting in-line on > the > > >>> traffic path. It adds a tiny bit of latency, but can scale up to > > >>> process large traffic paths and apply complex inspections on the > > >>> traffic. > > >>> > > >>> Cheers, > > >>> jof > > >>> > > >>> On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow > > wrote: > > >>> > Hi all, > > >>> > > > >>> > I'm looking for a way to block individual TCP flows (5-tuple) on a > > 1-10 > > >>> > gbps > > >>> > link, with new blocked flows being dropped within a millisecond or > so > > >>> > of > > >>> > being > > >>> > added. I've been looking into using OpenFlow on an HP Procurve, > but I > > >>> > don't > > >>> > know much in this area, so I'm looking for better alternatives. > > >>> > > > >>> > Ideally, such a device would add minimal latency (many/expandable > CAM > > >>> > entries?), can handle many programatically added flows (hundreds > per > > >>> > second), > > >>> > and would be deployable in a production network (fails in bypass > > mode). > > >>> > Are > > >>> > there any > > >>> > COTS devices I should be looking at? Or is the market for this all > > >>> > under > > >>> > the table to > > >>> > pro-censorship governments? > > >>> > > > >>> > Thanks, > > >>> > > > >>> > -Eric > > >>> > > >> > > >> > > >> > > >> -- > > >> Phil Fagan > > >> Denver, CO > > >> 970-480-7618 > > > > > > > > > > > > > > > -- > > > Phil Fagan > > > Denver, CO > > > 970-480-7618 > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > From woody at pch.net Fri Jun 14 00:00:36 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 13 Jun 2013 17:00:36 -0700 Subject: huawei (ZTE too) In-Reply-To: <20130613150133.D4884C24@m0005296.ppops.net> References: <20130613150133.D4884C24@m0005296.ppops.net> Message-ID: <74815D56-7AD1-44F4-B3C0-934471241E98@pch.net> On Jun 13, 2013, at 3:01 PM, "Scott Weeks" wrote: > On 2013-06-13 14:28, david peahi wrote: >> >> Last I heard NANOG stands for North American Network Operators Group. >> Anti-American comments are not welcome here.. > Smiley? Smiley? I'm looking for the :-) but I don't > see one. How about "crazy eyes"? <8-) Sorry, he can't hear you over his freedom. -Bill From mis at seiden.com Fri Jun 14 00:02:45 2013 From: mis at seiden.com (Mark Seiden) Date: Thu, 13 Jun 2013 17:02:45 -0700 Subject: huawei In-Reply-To: <20130613155256.D48845DD@m0005296.ppops.net> References: <20130613155256.D48845DD@m0005296.ppops.net> Message-ID: <30315F20-40DA-41E9-A439-9721C35C5B49@seiden.com> paper is downloadable from http://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf On Jun 13, 2013, at 3:52 PM, "Scott Weeks" wrote: > --- rsk at gsp.org wrote: > From: Rich Kulawiec > > On Thu, Jun 13, 2013 at 06:10:39PM +0200, Randy Bush wrote: >> we really should not be putting huawei kit into the backbone, there >> might be backdoors where they can spy on our traffic > > This paper may be relevant to the topic at hand (h/t to Rob Slade): > > http://www.scribd.com/doc/95282643/Backdoors-Embedded-in-DoD-Microchips-From-China > > > Unfortunately, it doesn't appear possible to download this paper without > signing up for scribd. Perhaps it's available elsewhere without such > onerous requirements. > --------------------------------- > > > > > http://www.cl.cam.ac.uk/~sps32/ches2012-backdoor.pdf > > scott > From khelms at zcorum.com Fri Jun 14 00:28:06 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 20:28:06 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: Bill, Certainly everything you said is correct and at the same time is not useful for the kinds traffic interception that's been implied. 20 packets of random traffic capture is extraordinarily unlikely to contain anything of interest and eve if you do happen to get a juicy fragment your chances of getting more ate virtually nil. An effective system must either capture and transmit large numbers of packets or have a command and control system in order to target smaller captures against a shifting list of addresses. Either of those things are very detectable. I've spent a significant amount of time looking at botnet traffic which has the same kind of requirements. On Jun 13, 2013 6:45 PM, "William Herrin" wrote: > On Thu, Jun 13, 2013 at 1:20 PM, Scott Helms wrote: > > if one of my routers starts sending cat > > photos somewhere, no matter how cute, I'm gonna consider that suspicious. > > Hi Scott, > > If once every 24 hours or so your router borrows the source IP of a > packet it recently passed and uses it to send a burst of 20 > intentionally unacknowledged packets containing a cat photo, your odds > of noticing are very close to zero and your odds of tracing it to the > router are even worse. > > Implementing a magic-packet remote kill switch is even easier... and > completely undetectable until used. With a little effort you could > implement it in the forwarding hardware where even a thorough analysis > of the firmware image can't detect it. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From mike at mtcc.com Fri Jun 14 00:39:18 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 13 Jun 2013 17:39:18 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> Message-ID: <51BA6636.1010403@mtcc.com> On 06/13/2013 05:28 PM, Scott Helms wrote: > Bill, > > Certainly everything you said is correct and at the same time is not useful > for the kinds traffic interception that's been implied. 20 packets of > random traffic capture is extraordinarily unlikely to contain anything of > interest and eve if you do happen to get a juicy fragment your chances of > getting more ate virtually nil. An effective system must either capture > and transmit large numbers of packets or have a command and control system > in order to target smaller captures against a shifting list of addresses. > Either of those things are very detectable. I've spent a significant > amount of time looking at botnet traffic which has the same kind of > requirements. > I think you're having a failure of imagination that anything less than a massive amount of information sent back to the attacker could be useful. I think there are lots and lots of things that could be extremely useful that would only require a simple message with "got here" back to the attacker if the "got here" condition was sufficiently interesting. Spying doesn't have the same motivations as typical botnets for illicit commerce. Mike From mis at seiden.com Fri Jun 14 00:53:34 2013 From: mis at seiden.com (Mark Seiden) Date: Thu, 13 Jun 2013 17:53:34 -0700 Subject: huawei In-Reply-To: <51BA6636.1010403@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> Message-ID: On Jun 13, 2013, at 5:39 PM, Michael Thomas wrote: > On 06/13/2013 05:28 PM, Scott Helms wrote: >> Bill, >> >> Certainly everything you said is correct and at the same time is not useful >> for the kinds traffic interception that's been implied. 20 packets of >> random traffic capture is extraordinarily unlikely to contain anything of >> interest and eve if you do happen to get a juicy fragment your chances of >> getting more ate virtually nil. An effective system must either capture >> and transmit large numbers of packets or have a command and control system >> in order to target smaller captures against a shifting list of addresses. >> Either of those things are very detectable. I've spent a significant >> amount of time looking at botnet traffic which has the same kind of >> requirements. >> > > I think you're having a failure of imagination that anything less than > a massive amount of information sent back to the attacker could be > useful. I think there are lots and lots of things that could be extremely > useful that would only require a simple message with "got here" back to the > attacker if the "got here" condition was sufficiently interesting. Spying doesn't > have the same motivations as typical botnets for illicit commerce. > > Mike > and even botnets for illicit commerce may only be interested something that is small and may not change very often so will not need regular exflitration... e.g. on a server, the current password of a user who can sudo or a few private keys From khelms at zcorum.com Fri Jun 14 01:11:35 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 21:11:35 -0400 Subject: huawei In-Reply-To: <51BA6636.1010403@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> Message-ID: Not at all Michael, but that is a targeted piece of data and that means a command and control system. I challenge your imagination to come up with a common scenario where a non targeted "I'm/they're here" that's useful to either the company or the Chinese government keeping in mind that you have no fore knowledge of where these devices might be deployed. Also, no oneseems to want to touch the fact that doing this kind of snooping would be several orders of magnitude easier on laptops and desktops which have been sold by Lenovo for much longer than networking gear by Huawei. On Jun 13, 2013 8:39 PM, "Michael Thomas" wrote: > On 06/13/2013 05:28 PM, Scott Helms wrote: > >> Bill, >> >> Certainly everything you said is correct and at the same time is not >> useful >> for the kinds traffic interception that's been implied. 20 packets of >> random traffic capture is extraordinarily unlikely to contain anything of >> interest and eve if you do happen to get a juicy fragment your chances of >> getting more ate virtually nil. An effective system must either capture >> and transmit large numbers of packets or have a command and control system >> in order to target smaller captures against a shifting list of addresses. >> Either of those things are very detectable. I've spent a significant >> amount of time looking at botnet traffic which has the same kind of >> requirements. >> >> > I think you're having a failure of imagination that anything less than > a massive amount of information sent back to the attacker could be > useful. I think there are lots and lots of things that could be extremely > useful that would only require a simple message with "got here" back to the > attacker if the "got here" condition was sufficiently interesting. Spying > doesn't > have the same motivations as typical botnets for illicit commerce. > > Mike > From kmedcalf at dessus.com Fri Jun 14 01:34:08 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 13 Jun 2013 19:34:08 -0600 Subject: huawei (ZTE too) Message-ID: There is more than just y'all's in North America ?.? --- Sent from Samsung Mobile? -------- Original message -------- From: Jeroen Massar Date: To: david peahi Cc: NANOG list Subject: Re: huawei (ZTE too) From mike at mtcc.com Fri Jun 14 01:53:28 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 13 Jun 2013 18:53:28 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> Message-ID: <51BA7798.40300@mtcc.com> On 06/13/2013 06:11 PM, Scott Helms wrote: > > Not at all Michael, but that is a targeted piece of data and that means a command and control system. I challenge your imagination to come up with a common scenario where a non targeted "I'm/they're here" that's useful to either the company or the Chinese government keeping in mind that you have no fore knowledge of where these devices might be deployed. Also, no oneseems to want to touch the fact that doing this kind of snooping would be several orders of magnitude easier on laptops and desktops which have been sold by Lenovo for much longer than networking gear by Huawei. > > Non targeted? Why be so narrow? For a targeted use, something that detects, oh say, "we [the Syrians] gassed the rebels" in some stream and sends it out a covert channel would be very interesting. Remember that vast sums of money are spent on these intelligence gathering systems. Whether they're targeting routers is really hard to say -- the attacker has the advantage of knowing what they're looking for and we don't. So in a router? It may just be opportunistic that they're easier or safer to penetrate? We really don't know. Things are rarely as they appear on the surface. Mike, "I just heard the Syria example from the Newshour as I typed... this isn't hard" From khelms at zcorum.com Fri Jun 14 01:57:14 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 21:57:14 -0400 Subject: huawei In-Reply-To: <51BA7798.40300@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <51BA7798.40300@mtcc.com> Message-ID: What you're describing is a command and control channel unless you're suggesting that the router itself had the capacity to somehow discern that. That's the problem with all the pixie dust theories. The router can't, it doesn't know who the rebels are much less their net block ahead of time. Something has to pass rules to the box to be able trigger off of. On Jun 13, 2013 9:53 PM, "Michael Thomas" wrote: > On 06/13/2013 06:11 PM, Scott Helms wrote: > >> >> Not at all Michael, but that is a targeted piece of data and that means >> a command and control system. I challenge your imagination to come up >> with a common scenario where a non targeted "I'm/they're here" that's >> useful to either the company or the Chinese government keeping in mind that >> you have no fore knowledge of where these devices might be deployed. >> Also, no oneseems to want to touch the fact that doing this kind of >> snooping would be several orders of magnitude easier on laptops and >> desktops which have been sold by Lenovo for much longer than networking >> gear by Huawei. >> >> >> > Non targeted? Why be so narrow? For a targeted use, something that detects, > oh say, "we [the Syrians] gassed the rebels" in some stream and sends it > out a > covert channel would be very interesting. Remember that vast sums of > money are > spent on these intelligence gathering systems. Whether they're targeting > routers is > really hard to say -- the attacker has the advantage of knowing what > they're looking for > and we don't. So in a router? It may just be opportunistic that they're > easier or safer > to penetrate? We really don't know. Things are rarely as they appear on > the surface. > > > Mike, "I just heard the Syria example from the Newshour as I typed... this > isn't hard" > From mysidia at gmail.com Fri Jun 14 01:58:42 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 13 Jun 2013 20:58:42 -0500 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: On 6/13/13, Patrick W. Gilmore wrote: > It should be trivial to prove to yourself the box is, or is not, doing > something evil if you actually try. What if it's not doing anything evil 99% of the time... after all 90%+ of traffic may be of no interest to a potential adversary, but there is a backdoor mechanism that allows "targetted evilness" to be enabled? Sniffing on a targetted IP address can be disguised as "legitimate" return traffic, to a connection actually initiated from the "backdoor data interaction point" to some other web server, creating a ruse.. A low-bandwidth fabricated return flow on top of the legitimate return flow once every few months, or every few days is extremely likely to go unnoticed, on any network that has a significantly large amount of normal production traffic. > -- > TTFN, > patrick -- -JH From mike at mtcc.com Fri Jun 14 02:05:02 2013 From: mike at mtcc.com (Michael Thomas) Date: Thu, 13 Jun 2013 19:05:02 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <51BA7798.40300@mtcc.com> Message-ID: <51BA7A4E.6030907@mtcc.com> On 06/13/2013 06:57 PM, Scott Helms wrote: > > What you're describing is a command and control channel unless you're suggesting that the router itself had the capacity to somehow discern that. That's the problem with all the pixie dust theories. The router can't, it doesn't know who the rebels are much less their net block ahead of time. Something has to pass rules to the box to be able trigger off of. > I think you're misunderstanding: the router is watching traffic and gives clues that "we're gassing the rebels" that was added to all of the DPI vectors which get surreptitiously added to the other DPI terms unbeknownst to the owner and sent back to the attacker. That's enormously powerful. All it takes is sufficient money and motivation. Is this speculative? Of course -- I'm not a spook. Is it possible? You bet. Mike From khelms at zcorum.com Fri Jun 14 02:11:37 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 22:11:37 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: Targeted how without an active C&C system? On Jun 13, 2013 10:01 PM, "Jimmy Hess" wrote: > On 6/13/13, Patrick W. Gilmore wrote: > > It should be trivial to prove to yourself the box is, or is not, doing > > something evil if you actually try. > > What if it's not doing anything evil 99% of the time... after all > 90%+ of traffic may be of no interest to a potential adversary, but > there is a backdoor mechanism that allows "targetted evilness" to be > enabled? > > Sniffing on a targetted IP address can be disguised as "legitimate" > return traffic, to a connection actually initiated from the "backdoor > data interaction point" to some other web server, creating a ruse.. > > A low-bandwidth fabricated return flow on top of the legitimate > return flow once every few months, or every few days is extremely > likely to go unnoticed, on any network that has a significantly > large amount of normal production traffic. > > > > -- > > TTFN, > > patrick > -- > -JH > > From khelms at zcorum.com Fri Jun 14 02:16:29 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 13 Jun 2013 22:16:29 -0400 Subject: huawei In-Reply-To: <51BA7A4E.6030907@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <51BA7798.40300@mtcc.com> <51BA7A4E.6030907@mtcc.com> Message-ID: What protocol is a DPI vector? In what way is making a router even remotely efficient as a method of end to end covert communication? There are thousands (if not millions) of ways for two hosts to exchange data without it being detectable that's much faster and cheaper than involving the network infrastructure. Kill switches and secret back doors are all feasible but the rest of this is fantasy. On Jun 13, 2013 10:05 PM, "Michael Thomas" wrote: > On 06/13/2013 06:57 PM, Scott Helms wrote: > >> >> What you're describing is a command and control channel unless you're >> suggesting that the router itself had the capacity to somehow discern that. >> That's the problem with all the pixie dust theories. The router can't, >> it doesn't know who the rebels are much less their net block ahead of time. >> Something has to pass rules to the box to be able trigger off of. >> >> > I think you're misunderstanding: the router is watching traffic and gives > clues > that "we're gassing the rebels" that was added to all of the DPI vectors > which get surreptitiously added to the other DPI terms unbeknownst to the > owner and sent back to the attacker. That's enormously powerful. All it > takes > is sufficient money and motivation. Is this speculative? Of course -- I'm > not > a spook. Is it possible? You bet. > > Mike > From philfagan at gmail.com Fri Jun 14 02:37:03 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 13 Jun 2013 20:37:03 -0600 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <51BA7798.40300@mtcc.com> <51BA7A4E.6030907@mtcc.com> Message-ID: What protocols have empty space in the headers whereby I can add my 'message' and send it along with legit traffic? I would think most all.. On Thu, Jun 13, 2013 at 8:16 PM, Scott Helms wrote: > What protocol is a DPI vector? In what way is making a router even > remotely efficient as a method of end to end covert communication? There > are thousands (if not millions) of ways for two hosts to exchange data > without it being detectable that's much faster and cheaper than involving > the network infrastructure. > > Kill switches and secret back doors are all feasible but the rest of this > is fantasy. > On Jun 13, 2013 10:05 PM, "Michael Thomas" wrote: > > > On 06/13/2013 06:57 PM, Scott Helms wrote: > > > >> > >> What you're describing is a command and control channel unless you're > >> suggesting that the router itself had the capacity to somehow discern > that. > >> That's the problem with all the pixie dust theories. The router > can't, > >> it doesn't know who the rebels are much less their net block ahead of > time. > >> Something has to pass rules to the box to be able trigger off of. > >> > >> > > I think you're misunderstanding: the router is watching traffic and gives > > clues > > that "we're gassing the rebels" that was added to all of the DPI vectors > > which get surreptitiously added to the other DPI terms unbeknownst to the > > owner and sent back to the attacker. That's enormously powerful. All it > > takes > > is sufficient money and motivation. Is this speculative? Of course -- I'm > > not > > a spook. Is it possible? You bet. > > > > Mike > > > -- Phil Fagan Denver, CO 970-480-7618 From mysidia at gmail.com Fri Jun 14 02:57:50 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 13 Jun 2013 21:57:50 -0500 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> Message-ID: On 6/13/13, Scott Helms wrote: > Targeted how without an active C&C system? How have you determined that there is not one? Conceptually, the "simplest" backdoored router, could have a mechanism, where crafted packets that would ordinarily be forwarded on, contain some "magic bit pattern" in the source address or other parameter, that cause the packet to bypass ACLs and be punted directly to software. So the simplest conceivable C&C system, could be "one guy" checking if random IP addresses they have personally decided are interesting, are behind a backdoored router. By sending a crafted port 53 DNS request, with some encrypted material with a digitally signed hash based on a timestamp, the source IP, and the destination IP being probed. And waiting for the magicaly structured "ICMP Destination unreachable/Admin prohibited" error reply packet, containing some covert bit pattern confirming the presence and system identification of a backdoored unit on the path to the 'interesting' remote host. -- -JH From eugen at leitl.org Fri Jun 14 06:47:46 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 14 Jun 2013 08:47:46 +0200 Subject: huawei In-Reply-To: References: Message-ID: <20130614064746.GA22824@leitl.org> On Thu, Jun 13, 2013 at 10:34:28AM -0600, Phil Fagan wrote: > Yeah, I can't imagine there is any real magic there...mystical protocol not > seen over transport. Compromised NICs can leak info through side channels (timing) but it's too low bandwidth. For end user devices with backdoors (remote vulnerabilities are like sloppy backdoors) you could get away with 'it's just part of a botnet', perhaps. From akennykant at gmail.com Fri Jun 14 06:47:56 2013 From: akennykant at gmail.com (Kenny Kant) Date: Fri, 14 Jun 2013 01:47:56 -0500 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: <4D31764A-87EA-48C3-80F2-6E91B1775393@gmail.com> +1 for Bro http://www.bro.org http://packetpushers.net/healthy-paranoia-show-11-bro-the-outer-limits-of-ids/ Sent from my iPad On Jun 13, 2013, at 2:32 PM, Eric Wustrow wrote: > Hi all, > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 gbps > link, with new blocked flows being dropped within a millisecond or so of > being > added. I've been looking into using OpenFlow on an HP Procurve, but I don't > know much in this area, so I'm looking for better alternatives. > > Ideally, such a device would add minimal latency (many/expandable CAM > entries?), can handle many programatically added flows (hundreds per > second), > and would be deployable in a production network (fails in bypass mode). Are > there any > COTS devices I should be looking at? Or is the market for this all under > the table to > pro-censorship governments? > > Thanks, > > -Eric From rdobbins at arbor.net Fri Jun 14 07:15:17 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 14 Jun 2013 07:15:17 +0000 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: <2901AB0C-77FC-405A-BA59-047D064E1CC3@arbor.net> On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote: > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 gbps link, with new blocked flows being dropped within a millisecond or so of > being added. What's the actual application for this mechanism? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rsk at gsp.org Fri Jun 14 10:24:40 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 14 Jun 2013 06:24:40 -0400 Subject: huawei In-Reply-To: <201306131555.24512.choprboy@dakotacom.net> References: <20130613223041.GA4349@gsp.org> <201306131555.24512.choprboy@dakotacom.net> Message-ID: <20130614102440.GA25103@gsp.org> On Thu, Jun 13, 2013 at 03:55:24PM -0700, Adrian wrote: > Extraordinary claims require extra ordinary proof. Thanks for the pointers; most enlightening. (And I say that even before coffee has taken full effect. I'll re-read once it has.) However, and perhaps I should have explained this in my original message, whether or not this was an oops! of leftover debugging, whether or not the Chinese actually did this, whether or not the chip meets military operational temperature requirements, etc., are all secondary to the point I was (poorly) trying to make. Let me try again. (1) There is often a presumption, when, let's say, a particularly sophisticated piece of malware is analyzed, or a large botnet is detected, or a security hole is uncovered in a piece of software, that it's the worst one -- because it's the worst one *publicly known to date*. But that's wishful thinking. There's probably a nastier piece of malware out there. There's probably a larger botnet. There's probably a bigger security hole in that piece of software. Whatever the severity distribution of these is (and I don't think that's knowable) it would be amazing if we just happened to hit on the one that's at the extreme end of the curve. Reality is usually not that convenient. Thus however bad these things are, and we can certainly debate that (and we have) (and we will), there's probably something worse that we're not debating because we don't know about it. (2) As Bruce Schneier has observed, attacks always get better. So even if, against the odds, we happen to be lucky enough to be looking at something that really, really is at the far end of the severity distribution -- tomorrow there will be something worse. ---rsk From oscar.vives at gmail.com Fri Jun 14 11:29:29 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Fri, 14 Jun 2013 13:29:29 +0200 Subject: huawei (ZTE too) In-Reply-To: References: Message-ID: I am only a lurker in this list. I am curious why nobody has mentioned open source. Theres no way all these router-thingies would have all his source code visible? a house made of glass? -- -- ?in del ?ensaje. From rsk at gsp.org Fri Jun 14 12:47:21 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 14 Jun 2013 08:47:21 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> Message-ID: <20130614124721.GB28378@gsp.org> On Thu, Jun 13, 2013 at 09:11:35PM -0400, Scott Helms wrote: > I challenge your imagination to come up with a > common scenario where a non targeted "I'm/they're here" that's useful to > either the company or the Chinese government keeping in mind that you have > no fore knowledge of where these devices might be deployed. How about "code that watches for password changes on the device, captures them, quietly and slowly leaks them a bit at a time"? And I do mean "slowly": passwords don't change all that often, so if it takes a week to transmit one, that's not a concern. Passwords also get reused, so knowledge of the pair (Device1, Password1) is often useful when considering (Device2, Device3, ... DeviceN). You're right: nobody would know a priori where the devices are going. But why would [some of the] attackers care? And it's not strictly necessary to have the devices transmit the info to a pre-designated listener: it could be inserted in ALL traffic [1] so that the device is always (slowly) broadcasting its own password. Yes, this is very inefficient; yes, that might mean that transmission of the password back to the attackers isn't guaranteed; yes that might mean that it takes a much longer time to harvest passwords. But if the attackers' goal is to harvest as many passwords as possible, then efficiency and speed aren't important. (After all, many of the devices might sit in boxes for a long time. Or be installed on networks that are air-gapped. Or otherwise might never report anything useful.) What's much more important is undetectability, and given that almost all the detection mechanisms in play look for something like "lots of traffic to/from an unexpected location" the best way to avoid that is to be very slow, very quiet and very undirected. Yeah, yeah, yeah, I know: far-fetched. But yesterday's "far-fetched" keeps turning out to be today's reality with monotonous regularity. And: suppose *you* were an attacker with a multi-billion dollar budget, thousands of people, and years to work: don't you think you could pull this off, too? ---rsk [1] Perhaps disused packet header fields. Or perhaps, more cleverly, buried in the packet itself. Or otherwise concealed in other ways that make it very hard to pick out unless you know, a priori, what you're looking for. From qlixed at gmail.com Fri Jun 14 01:24:18 2013 From: qlixed at gmail.com (QliX=D! [aka EHB]) Date: Thu, 13 Jun 2013 22:24:18 -0300 Subject: Blocking TCP flows? In-Reply-To: References: Message-ID: ROFL... I ca n't even typeee... so funny... perl fast.... oh goosh... El jun 13, 2013 7:46 PM, "Christopher Morrow" escribi?: > On Thu, Jun 13, 2013 at 6:37 PM, Phil Fagan wrote: > > fast Perl > > haha :) that's cute. > > From tom.taylor.stds at gmail.com Fri Jun 14 14:21:25 2013 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Fri, 14 Jun 2013 10:21:25 -0400 Subject: huawei In-Reply-To: <20130614124721.GB28378@gsp.org> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: <51BB26E5.5030800@gmail.com> Disclosure: I've been consulting to a group in Huawei for six years, ever since I retired from Nortel. I have seen no sign of anything except competent gathering of competitive information at meetings, the same as we did at Nortel. I would not have expected to see anything else, of course. As a Canadian, I cast a somewhat skeptical eye on claims of Huawei being a particular security hazard. My personal view, without any evidence outside of the newspapers, is that the claims are commercially and politically motivated. I note that Cisco equipment, for instance, is also manufactured in China, but no one has taken that any further. The IPR scandal is twenty years in the past, now. I've watched my own group mature and visited their Shenzhen campus of 10,000-plus engineers from time to time, and I would say that Huawei is well able to generate their own technology these days. It's fun to speculate on how one might insert back doors in products, but I'm not sure there's reason to tie such speculation to particular vendors. Tom Taylor From JFaraone at paulo.com Fri Jun 14 15:51:34 2013 From: JFaraone at paulo.com (Jason Faraone) Date: Fri, 14 Jun 2013 15:51:34 +0000 Subject: Citrix Netscaler Rewrite Issue Message-ID: I've been sitting here frustrated for a bit this morning so hopefully someone here can shed some light... I have a Citrix Netscaler appliance (v10.0) and I would like to rewrite a URL - essentially when someone visits www.example.com, I would like to redirect them to www.example.com/pls/apex/f?p=103:1 This seems to work well enough until I get to the question mark, at which point things fall apart. "The requested URL /pls/apex/f was not found on this server." Typically I would just escape the character and be done with it, but no amount of voodoo I've thrown at this thing can find the right combination of characters. Here is a screencap of what I have in place now: http://i.imgur.com/u4lms3b.png Can anyone shoot a suggestion my way off list? Knowing that I'm a few characters away from victory is maddening... Thanks, Jason From randy at psg.com Fri Jun 14 16:22:23 2013 From: randy at psg.com (Randy Bush) Date: Fri, 14 Jun 2013 18:22:23 +0200 Subject: huawei (ZTE too) In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA1D40.6050301@bryanfields.net> <51BA2D41.8040906@massar.ch> Message-ID: > Last I heard NANOG stands for North American Network Operators Group. > Anti-American comments are not welcome here.. LOL From contact at jpluscplusm.com Fri Jun 14 16:19:11 2013 From: contact at jpluscplusm.com (Jonathan Matthews) Date: Fri, 14 Jun 2013 17:19:11 +0100 Subject: Citrix Netscaler Rewrite Issue In-Reply-To: References: Message-ID: On 14 June 2013 16:51, Jason Faraone wrote: > I've been sitting here frustrated for a bit this morning so hopefully someone here can shed some light... > > I have a Citrix Netscaler appliance (v10.0) and I would like to rewrite a URL - essentially when someone visits www.example.com, I would like to redirect them to www.example.com/pls/apex/f?p=103:1 > > This seems to work well enough until I get to the question mark, at which point things fall apart. > > "The requested URL /pls/apex/f was not found on this server." I don't think the problem is with the Netscaler or your escaping; I think that whatever's serving www.example.com doesn't have a page for /pls/apex/f and is quite correctly telling you this. The part after the question mark is called the "query string", and it's (usually) used to communicate parameters to a page - a page which must already exist (except in very specific circumstances), without the query string. What happens if you "curl -v www.example.com"? Do you see the 30[23] redirect coming back? If so, it's a server-side problem and not an issue with the appliance. Jonathan -- Jonathan Matthews Oxford, London, UK http://www.jpluscplusm.com/contact.html From jra at baylink.com Fri Jun 14 16:39:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Jun 2013 12:39:02 -0400 (EDT) Subject: huawei In-Reply-To: <20130614064746.GA22824@leitl.org> Message-ID: <13283621.7899.1371227942621.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eugen Leitl" > On Thu, Jun 13, 2013 at 10:34:28AM -0600, Phil Fagan wrote: > > Yeah, I can't imagine there is any real magic there...mystical > > protocol not seen over transport. > > Compromised NICs can leak info through side channels (timing) but > it's too low bandwidth. For end user devices with backdoors > (remote vulnerabilities are like sloppy backdoors) you could > get away with 'it's just part of a botnet', perhaps. And the scope can be pretty big... Oh, look! This VZW 4G hockey puck was made by... ZTE. And it has a GPS receiver in it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From JFaraone at paulo.com Fri Jun 14 16:45:17 2013 From: JFaraone at paulo.com (Jason Faraone) Date: Fri, 14 Jun 2013 16:45:17 +0000 Subject: Citrix Netscaler Rewrite Issue In-Reply-To: References: Message-ID: My understanding is that everything after the question mark is used to specify which application for Oracle Application Express to load. For example, /pls/apex/f?p=103:1 and /pls/apex/f?p=102 would load two completely unrelated applications. Because of this, I need the full URL passed along. In the past, I've used an index.html file to redirect users to the proper URL. Since I'm migrating from an Apache server running as a reverse proxy to a Netscaler appliance, this approach is no longer feasible. -----Original Message----- From: Jonathan Matthews [mailto:contact at jpluscplusm.com] Sent: Friday, June 14, 2013 11:19 AM To: nanog at nanog.org Subject: Re: Citrix Netscaler Rewrite Issue On 14 June 2013 16:51, Jason Faraone wrote: > I've been sitting here frustrated for a bit this morning so hopefully someone here can shed some light... > > I have a Citrix Netscaler appliance (v10.0) and I would like to > rewrite a URL - essentially when someone visits > www.example.com, I would like to redirect them > to > www.example.com/pls/apex/f?p=103:1 =103:1> > > This seems to work well enough until I get to the question mark, at which point things fall apart. > > "The requested URL /pls/apex/f was not found on this server." I don't think the problem is with the Netscaler or your escaping; I think that whatever's serving www.example.com doesn't have a page for /pls/apex/f and is quite correctly telling you this. The part after the question mark is called the "query string", and it's (usually) used to communicate parameters to a page - a page which must already exist (except in very specific circumstances), without the query string. What happens if you "curl -v www.example.com"? Do you see the 30[23] redirect coming back? If so, it's a server-side problem and not an issue with the appliance. Jonathan -- Jonathan Matthews Oxford, London, UK http://www.jpluscplusm.com/contact.html From james at smithwaysecurity.com Fri Jun 14 16:46:49 2013 From: james at smithwaysecurity.com (James Smith) Date: Fri, 14 Jun 2013 11:46:49 -0500 Subject: Bell Aliant- Outage! Message-ID: <89ed55103b241f95c38afffefebd471f@smithwaysecurity.com> Does anyone have any details on the massive Bell aliant customer internet outage which affected Fiber/DSL/3G/LTE services in New Brunswick, Atlantic Canada ? -- Sincerely; James Smith CEO, CEH, Security Analyst Email: james at smithwaysecurity.com CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - From contact at jpluscplusm.com Fri Jun 14 16:58:15 2013 From: contact at jpluscplusm.com (Jonathan Matthews) Date: Fri, 14 Jun 2013 17:58:15 +0100 Subject: Citrix Netscaler Rewrite Issue In-Reply-To: References: Message-ID: On 14 June 2013 17:45, Jason Faraone wrote: > My understanding is that everything after the question mark is used to specify which application for Oracle Application Express to load. It's still just the query string as far as the client and Netscalar are concerned. > For example, /pls/apex/f?p=103:1 and /pls/apex/f?p=102 would load two completely unrelated applications. Because of this, I need the full URL passed along. That's orthogonal to the problem you described. > In the past, I've used an index.html file to redirect users to the proper URL. Since I'm migrating from an Apache server running as a reverse proxy to a Netscaler appliance, this approach is no longer feasible. I ask again: what happens if you "curl -v www.example.com"? [ I stand by what I said originally: the problem exists on your backend server, not on the Netscaler. ] Jonathan From Valdis.Kletnieks at vt.edu Fri Jun 14 16:59:52 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 14 Jun 2013 12:59:52 -0400 Subject: huawei In-Reply-To: Your message of "Fri, 14 Jun 2013 10:21:25 -0400." <51BB26E5.5030800@gmail.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <51BB26E5.5030800@gmail.com> Message-ID: <5720.1371229192@turing-police.cc.vt.edu> On Fri, 14 Jun 2013 10:21:25 -0400, Tom Taylor said: > It's fun to speculate on how one might insert back doors in products, > but I'm not sure there's reason to tie such speculation to particular > vendors. It's so much fun we've been doing it *at least* since we all wondered where IBM got the S-boxes from. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From khelms at zcorum.com Fri Jun 14 17:21:09 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 14 Jun 2013 13:21:09 -0400 Subject: huawei In-Reply-To: <20130614124721.GB28378@gsp.org> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: On Fri, Jun 14, 2013 at 8:47 AM, Rich Kulawiec wrote: > On Thu, Jun 13, 2013 at 09:11:35PM -0400, Scott Helms wrote: > > I challenge your imagination to come up with a > > common scenario where a non targeted "I'm/they're here" that's useful to > > either the company or the Chinese government keeping in mind that you > have > > no fore knowledge of where these devices might be deployed. > > How about "code that watches for password changes on the device, > captures them, quietly and slowly leaks them a bit at a time"? > And I do mean "slowly": passwords don't change all that often, > so if it takes a week to transmit one, that's not a concern. > > This is feasible, but frankly unlikely because AFAIK no one disputes that backdoors (intentional or not) are in most if not all gear. Having said that, it would still be pretty obvious in mass and over time to have packets going to a predesignated host. Its not really possible for a box to know whether its in a "real" network or a lab with Spirent or other traffic generator hooked to it. > Passwords also get reused, so knowledge of the pair (Device1, Password1) > is often useful when considering (Device2, Device3, ... DeviceN). > > You're right: nobody would know a priori where the devices are going. > But why would [some of the] attackers care? > It really depends on what someone wants to accomplish. There are lots of things that are possible, but not feasible simply because there are cheaper/faster/better ways of accomplishing the same thing. Shutting down a network is pretty easy so if you have a kill switch and a backdoor (both likely and easy) then why do you care about the passwords of the devices near by? You can knock out a core router in other ways. > > And it's not strictly necessary to have the devices transmit the info > to a pre-designated listener: it could be inserted in ALL traffic [1] > so that the device is always (slowly) broadcasting its own password. > Yes, this is very inefficient; yes, that might mean that transmission > of the password back to the attackers isn't guaranteed; yes that might > mean that it takes a much longer time to harvest passwords. > How? There is truly not that much room in the IP packet to play games and if you're modifying all your traffic this would again be pretty easy to spot. Again, the easiest/cheapest method is that there is a backdoor there already. > > But if the attackers' goal is to harvest as many passwords as possible, > then efficiency and speed aren't important. (After all, many of the > devices might sit in boxes for a long time. Or be installed on networks > that are air-gapped. Or otherwise might never report anything useful.) > What's much more important is undetectability, and given that almost > all the detection mechanisms in play look for something like "lots of > traffic to/from an unexpected location" the best way to avoid that is > to be very slow, very quiet and very undirected. > > Yeah, yeah, yeah, I know: far-fetched. But yesterday's "far-fetched" > keeps turning out to be today's reality with monotonous regularity. > Not really, things that are far fetched can become reality but only in cases where something underlying changes. > > And: suppose *you* were an attacker with a multi-billion dollar budget, > thousands of people, and years to work: don't you think you could pull > this off, too? > I could certainly and as I've pointed out, I wouldn't even consider routers outside of disruptive attacks. If you want to steal information you want to be as close to the end user target as you can be so your signal to noise ratio is better. If I wanted to do this and had the resources of the Chinese government then I'd be much more focused on Lenovo than Huawei. The parts that are most interesting in Huawei aren't the core pieces but rather the consumer and office gear. > > ---rsk > > [1] Perhaps disused packet header fields. Or perhaps, more cleverly, > buried in the packet itself. Or otherwise concealed in other ways that > make it very hard to pick out unless you know, a priori, what you're > looking for. > There are a couple of places you could stick something, but it would stick out like a sore thumb in Wireshark. From wbailey at satelliteintelligencegroup.com Fri Jun 14 17:48:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 14 Jun 2013 17:48:54 +0000 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org>, Message-ID: I would imagine the people running an ultra ninja spy network would have people working for them in their enemies national hardware supply chain, you can put your code in their gear. I don't know why everyone thinks their email or router password being comprised is the end result. A worm was placed into a SCADA (Seimens) controller that manipulated the rotation of centrifuges. If I can do THAT.. Why would I care about some lame box at your office? I would love to know how much effort the NSA puts into playing with other national covert surveillance programs. The Chinese have been saying for years they aren't rooting dot com and dot gov, but I would bet money the NSA has been watching them do it for as long as it has been around (which REALLY passes off the Chinese) . When you have endless money and time, there are no bounds. We (Americans) think in terms of Presidential cycles and Holidays. They (Chinese) tend to have a little different view on things, time is progress. I encourage all of you to watch Vice on HBO tonight. If you enjoy it, there is an episode a week or two back showing these massive (3-5k units) housing developments that are sitting completely empty. As it turns out, the Chinese are building because that is how they measure their economic growth. If they are building, they are growing. Never mind they have no one to sleep there, let alone ever intend to make their money back. I suppose I should wrap up my rant with: Government (world wide) spends a tremendous amount of time and money on keeping things secure. They used to house sensitive information in vaults with guys standing 24x7 with Uzis, but as the information age has approached they have lost touch with reality. All of these security screenings, background checks, spying, and a 29 year old anime fan with a smokin' girlfriend smuggled thumb drives out and flew to China. He mentioned he had access to the location of every CIA station and operative in the world - which means he had access to their AD controller. This shit isn't mystical, it's new. Sent from my Mobile Device. -------- Original message -------- From: Scott Helms Date: 06/14/2013 10:23 AM (GMT-08:00) To: Rich Kulawiec Cc: NANOG Subject: Re: huawei On Fri, Jun 14, 2013 at 8:47 AM, Rich Kulawiec wrote: > On Thu, Jun 13, 2013 at 09:11:35PM -0400, Scott Helms wrote: > > I challenge your imagination to come up with a > > common scenario where a non targeted "I'm/they're here" that's useful to > > either the company or the Chinese government keeping in mind that you > have > > no fore knowledge of where these devices might be deployed. > > How about "code that watches for password changes on the device, > captures them, quietly and slowly leaks them a bit at a time"? > And I do mean "slowly": passwords don't change all that often, > so if it takes a week to transmit one, that's not a concern. > > This is feasible, but frankly unlikely because AFAIK no one disputes that backdoors (intentional or not) are in most if not all gear. Having said that, it would still be pretty obvious in mass and over time to have packets going to a predesignated host. Its not really possible for a box to know whether its in a "real" network or a lab with Spirent or other traffic generator hooked to it. > Passwords also get reused, so knowledge of the pair (Device1, Password1) > is often useful when considering (Device2, Device3, ... DeviceN). > > You're right: nobody would know a priori where the devices are going. > But why would [some of the] attackers care? > It really depends on what someone wants to accomplish. There are lots of things that are possible, but not feasible simply because there are cheaper/faster/better ways of accomplishing the same thing. Shutting down a network is pretty easy so if you have a kill switch and a backdoor (both likely and easy) then why do you care about the passwords of the devices near by? You can knock out a core router in other ways. > > And it's not strictly necessary to have the devices transmit the info > to a pre-designated listener: it could be inserted in ALL traffic [1] > so that the device is always (slowly) broadcasting its own password. > Yes, this is very inefficient; yes, that might mean that transmission > of the password back to the attackers isn't guaranteed; yes that might > mean that it takes a much longer time to harvest passwords. > How? There is truly not that much room in the IP packet to play games and if you're modifying all your traffic this would again be pretty easy to spot. Again, the easiest/cheapest method is that there is a backdoor there already. > > But if the attackers' goal is to harvest as many passwords as possible, > then efficiency and speed aren't important. (After all, many of the > devices might sit in boxes for a long time. Or be installed on networks > that are air-gapped. Or otherwise might never report anything useful.) > What's much more important is undetectability, and given that almost > all the detection mechanisms in play look for something like "lots of > traffic to/from an unexpected location" the best way to avoid that is > to be very slow, very quiet and very undirected. > > Yeah, yeah, yeah, I know: far-fetched. But yesterday's "far-fetched" > keeps turning out to be today's reality with monotonous regularity. > Not really, things that are far fetched can become reality but only in cases where something underlying changes. > > And: suppose *you* were an attacker with a multi-billion dollar budget, > thousands of people, and years to work: don't you think you could pull > this off, too? > I could certainly and as I've pointed out, I wouldn't even consider routers outside of disruptive attacks. If you want to steal information you want to be as close to the end user target as you can be so your signal to noise ratio is better. If I wanted to do this and had the resources of the Chinese government then I'd be much more focused on Lenovo than Huawei. The parts that are most interesting in Huawei aren't the core pieces but rather the consumer and office gear. > > ---rsk > > [1] Perhaps disused packet header fields. Or perhaps, more cleverly, > buried in the packet itself. Or otherwise concealed in other ways that > make it very hard to pick out unless you know, a priori, what you're > looking for. > There are a couple of places you could stick something, but it would stick out like a sore thumb in Wireshark. From Valdis.Kletnieks at vt.edu Fri Jun 14 17:51:32 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 14 Jun 2013 13:51:32 -0400 Subject: huawei In-Reply-To: Your message of "Fri, 14 Jun 2013 13:21:09 -0400." References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: <9245.1371232292@turing-police.cc.vt.edu> On Fri, 14 Jun 2013 13:21:09 -0400, Scott Helms said: > How? There is truly not that much room in the IP packet to play games and > if you're modifying all your traffic this would again be pretty easy to > spot. Again, the easiest/cheapest method is that there is a backdoor there > already. Do you actually examine your traffic and drop packets that have non-zeros in reserved fields? (Remember what that did to the deployment of ECN?) And there's plenty of room if you stick a TCP or IP option header in there. Do you actually check for those too? How fast can you send data to a cooperating router down the way if you splat the low 3 bits of TCP timestamps on a connection routed towards the cooperating router? (SUre, you just busted somebody's RTT calculation, but it will just decide it's a high-jitter path and deal with it). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Fri Jun 14 17:52:31 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 14 Jun 2013 17:52:31 +0000 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org>, Message-ID: Ps.. Has anyone seen evidence echelon is actually PRISM? Sent from my Mobile Device. -------- Original message -------- From: Scott Helms Date: 06/14/2013 10:23 AM (GMT-08:00) To: Rich Kulawiec Cc: NANOG Subject: Re: huawei On Fri, Jun 14, 2013 at 8:47 AM, Rich Kulawiec wrote: > On Thu, Jun 13, 2013 at 09:11:35PM -0400, Scott Helms wrote: > > I challenge your imagination to come up with a > > common scenario where a non targeted "I'm/they're here" that's useful to > > either the company or the Chinese government keeping in mind that you > have > > no fore knowledge of where these devices might be deployed. > > How about "code that watches for password changes on the device, > captures them, quietly and slowly leaks them a bit at a time"? > And I do mean "slowly": passwords don't change all that often, > so if it takes a week to transmit one, that's not a concern. > > This is feasible, but frankly unlikely because AFAIK no one disputes that backdoors (intentional or not) are in most if not all gear. Having said that, it would still be pretty obvious in mass and over time to have packets going to a predesignated host. Its not really possible for a box to know whether its in a "real" network or a lab with Spirent or other traffic generator hooked to it. > Passwords also get reused, so knowledge of the pair (Device1, Password1) > is often useful when considering (Device2, Device3, ... DeviceN). > > You're right: nobody would know a priori where the devices are going. > But why would [some of the] attackers care? > It really depends on what someone wants to accomplish. There are lots of things that are possible, but not feasible simply because there are cheaper/faster/better ways of accomplishing the same thing. Shutting down a network is pretty easy so if you have a kill switch and a backdoor (both likely and easy) then why do you care about the passwords of the devices near by? You can knock out a core router in other ways. > > And it's not strictly necessary to have the devices transmit the info > to a pre-designated listener: it could be inserted in ALL traffic [1] > so that the device is always (slowly) broadcasting its own password. > Yes, this is very inefficient; yes, that might mean that transmission > of the password back to the attackers isn't guaranteed; yes that might > mean that it takes a much longer time to harvest passwords. > How? There is truly not that much room in the IP packet to play games and if you're modifying all your traffic this would again be pretty easy to spot. Again, the easiest/cheapest method is that there is a backdoor there already. > > But if the attackers' goal is to harvest as many passwords as possible, > then efficiency and speed aren't important. (After all, many of the > devices might sit in boxes for a long time. Or be installed on networks > that are air-gapped. Or otherwise might never report anything useful.) > What's much more important is undetectability, and given that almost > all the detection mechanisms in play look for something like "lots of > traffic to/from an unexpected location" the best way to avoid that is > to be very slow, very quiet and very undirected. > > Yeah, yeah, yeah, I know: far-fetched. But yesterday's "far-fetched" > keeps turning out to be today's reality with monotonous regularity. > Not really, things that are far fetched can become reality but only in cases where something underlying changes. > > And: suppose *you* were an attacker with a multi-billion dollar budget, > thousands of people, and years to work: don't you think you could pull > this off, too? > I could certainly and as I've pointed out, I wouldn't even consider routers outside of disruptive attacks. If you want to steal information you want to be as close to the end user target as you can be so your signal to noise ratio is better. If I wanted to do this and had the resources of the Chinese government then I'd be much more focused on Lenovo than Huawei. The parts that are most interesting in Huawei aren't the core pieces but rather the consumer and office gear. > > ---rsk > > [1] Perhaps disused packet header fields. Or perhaps, more cleverly, > buried in the packet itself. Or otherwise concealed in other ways that > make it very hard to pick out unless you know, a priori, what you're > looking for. > There are a couple of places you could stick something, but it would stick out like a sore thumb in Wireshark. From mike at mtcc.com Fri Jun 14 17:59:01 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 14 Jun 2013 10:59:01 -0700 Subject: huawei In-Reply-To: <9245.1371232292@turing-police.cc.vt.edu> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <9245.1371232292@turing-police.cc.vt.edu> Message-ID: <51BB59E5.70305@mtcc.com> On 06/14/2013 10:51 AM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 14 Jun 2013 13:21:09 -0400, Scott Helms said: > >> How? There is truly not that much room in the IP packet to play games and >> if you're modifying all your traffic this would again be pretty easy to >> spot. Again, the easiest/cheapest method is that there is a backdoor there >> already. > Do you actually examine your traffic and drop packets that have non-zeros > in reserved fields? (Remember what that did to the deployment of ECN?) > > And there's plenty of room if you stick a TCP or IP option header in there. Do > you actually check for those too? > > How fast can you send data to a cooperating router down the way if you splat > the low 3 bits of TCP timestamps on a connection routed towards the cooperating > router? (SUre, you just busted somebody's RTT calculation, but it will just > decide it's a high-jitter path and deal with it). > Right. The asymmetry here is staggering. That's why they are hugely advantaged aside from the staggering asymmetry in funding. The only thing that we have on our side is that with enough eyeballs low probabilities become better, but the military well knows that problem for centuries, I'm sure. Mike From ewust at umich.edu Fri Jun 14 18:30:51 2013 From: ewust at umich.edu (Eric Wustrow) Date: Fri, 14 Jun 2013 14:30:51 -0400 Subject: Blocking TCP flows? In-Reply-To: <2901AB0C-77FC-405A-BA59-047D064E1CC3@arbor.net> References: <2901AB0C-77FC-405A-BA59-047D064E1CC3@arbor.net> Message-ID: Oddly enough, anticensorship. We use similar technology as the censors (DPI, flow blocking), but use our system in a non-censoring country's ISP to detect secret tags in connections from censored countries, and serve as a proxy for them. Once we detect a flow with a secret tag passing through the ISP, we block the real flow, and start spoofing half of the connection. We use this covert channel to communicate to the client and act as a proxy. To the censor, this looks like a normal connection to some innocuous, unrelated (and unblocked) website. The obvious difficulty is convincing ISPs to deploy such a proxy. More details can be found at https://telex.cc/ On Fri, Jun 14, 2013 at 3:15 AM, Dobbins, Roland wrote: > > On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote: > > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 > gbps link, with new blocked flows being dropped within a millisecond or so > of > > being added. > > What's the actual application for this mechanism? > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > From cscora at apnic.net Fri Jun 14 18:33:11 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Jun 2013 04:33:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201306141833.r5EIXBZv007290@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Jun, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 455698 Prefixes after maximum aggregation: 185776 Deaggregation factor: 2.45 Unique aggregates announced to Internet: 226123 Total ASes present in the Internet Routing Table: 44284 Prefixes per ASN: 10.29 Origin-only ASes present in the Internet Routing Table: 34691 Origin ASes announcing only one prefix: 16153 Transit ASes present in the Internet Routing Table: 5876 Transit-only ASes present in the Internet Routing Table: 150 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 55 Max AS path prepend of ASN ( 56484) 51 Prefixes from unregistered ASNs in the Routing Table: 844 Unregistered ASNs in the Routing Table: 367 Number of 32-bit ASNs allocated by the RIRs: 4791 Number of 32-bit ASNs visible in the Routing Table: 3717 Prefixes from 32-bit ASNs in the Routing Table: 10806 Special use prefixes present in the Routing Table: 25 Prefixes being announced from unallocated address space: 229 Number of addresses announced to Internet: 2642097068 Equivalent to 157 /8s, 123 /16s and 51 /24s Percentage of available address space announced: 71.4 Percentage of allocated address space announced: 71.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.6 Total number of prefixes smaller than registry allocations: 159877 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109564 Total APNIC prefixes after maximum aggregation: 33495 APNIC Deaggregation factor: 3.27 Prefixes being announced from the APNIC address blocks: 111077 Unique aggregates announced from the APNIC address blocks: 45247 APNIC Region origin ASes present in the Internet Routing Table: 4852 APNIC Prefixes per ASN: 22.89 APNIC Region origin ASes announcing only one prefix: 1226 APNIC Region transit ASes present in the Internet Routing Table: 822 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 572 Number of APNIC addresses announced to Internet: 725150944 Equivalent to 43 /8s, 56 /16s and 236 /24s Percentage of available APNIC address space announced: 84.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 158888 Total ARIN prefixes after maximum aggregation: 80309 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 159495 Unique aggregates announced from the ARIN address blocks: 73943 ARIN Region origin ASes present in the Internet Routing Table: 15730 ARIN Prefixes per ASN: 10.14 ARIN Region origin ASes announcing only one prefix: 5982 ARIN Region transit ASes present in the Internet Routing Table: 1647 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1081940032 Equivalent to 64 /8s, 125 /16s and 24 /24s Percentage of available ARIN address space announced: 57.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 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 117300 Total RIPE prefixes after maximum aggregation: 60050 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 120868 Unique aggregates announced from the RIPE address blocks: 78057 RIPE Region origin ASes present in the Internet Routing Table: 17215 RIPE Prefixes per ASN: 7.02 RIPE Region origin ASes announcing only one prefix: 8166 RIPE Region transit ASes present in the Internet Routing Table: 2833 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2358 Number of RIPE addresses announced to Internet: 656316516 Equivalent to 39 /8s, 30 /16s and 152 /24s Percentage of available RIPE address space announced: 95.4 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-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 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, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 48304 Total LACNIC prefixes after maximum aggregation: 9400 LACNIC Deaggregation factor: 5.14 Prefixes being announced from the LACNIC address blocks: 52699 Unique aggregates announced from the LACNIC address blocks: 24771 LACNIC Region origin ASes present in the Internet Routing Table: 1960 LACNIC Prefixes per ASN: 26.89 LACNIC Region origin ASes announcing only one prefix: 590 LACNIC Region transit ASes present in the Internet Routing Table: 364 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 762 Number of LACNIC addresses announced to Internet: 131745576 Equivalent to 7 /8s, 218 /16s and 71 /24s Percentage of available LACNIC address space announced: 78.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10741 Total AfriNIC prefixes after maximum aggregation: 2481 AfriNIC Deaggregation factor: 4.33 Prefixes being announced from the AfriNIC address blocks: 11330 Unique aggregates announced from the AfriNIC address blocks: 3893 AfriNIC Region origin ASes present in the Internet Routing Table: 632 AfriNIC Prefixes per ASN: 17.93 AfriNIC Region origin ASes announcing only one prefix: 189 AfriNIC Region transit ASes present in the Internet Routing Table: 129 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46645504 Equivalent to 2 /8s, 199 /16s and 193 /24s Percentage of available AfriNIC address space announced: 46.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2945 11561 922 Korea Telecom (KIX) 17974 2545 855 91 PT TELEKOMUNIKASI INDONESIA 7545 1999 320 108 TPG Internet Pty Ltd 4755 1744 391 191 TATA Communications formerly 9829 1517 1205 40 BSNL National Internet Backbo 9583 1218 91 503 Sify Limited 7552 1162 1080 13 Vietel Corporation 4808 1144 2124 334 CNCGROUP IP network: China169 9498 1129 309 70 BHARTI Airtel Ltd. 24560 1077 394 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3007 3691 75 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 1785 1992 677 124 PaeTec Communications, Inc. 22773 1984 2927 122 Cox Communications, Inc. 20115 1665 1618 615 Charter Communications 4323 1625 1138 406 Time Warner Telecom 701 1535 11143 800 UUNET Technologies, Inc. 30036 1328 297 642 Mediacom Communications Corp 7018 1297 11039 830 AT&T WorldNet Services 11492 1218 216 359 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1667 544 16 Corbina telecom 34984 1276 244 222 BILISIM TELEKOM 2118 1069 97 13 EUnet/RELCOM Autonomous Syste 20940 891 312 695 Akamai Technologies European 13188 808 98 82 Educational Network 31148 802 40 25 FreeNet ISP 8551 772 370 44 Bezeq International 6830 766 2376 440 UPC Distribution Services 12479 677 786 59 Uni2 Autonomous System 34744 676 173 59 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2660 418 208 TVCABLE BOGOTA 28573 2655 1534 167 NET Servicos de Comunicao S.A 7303 1730 1154 225 Telecom Argentina Stet-France 8151 1283 2721 401 UniNet S.A. de C.V. 18881 995 844 20 Global Village Telecom 6503 865 434 65 AVANTEL, S.A. 27947 842 89 106 Telconet S.A 3816 715 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 6147 665 374 25 Telefonica Del Peru Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1237 80 4 MOBITEL 24863 885 274 31 LINKdotNET AS number 6713 537 617 25 Itissalat Al-MAGHRIB 8452 455 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 261 922 219 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 29571 205 17 9 Ci Telecom Autonomous system 12258 192 28 66 Vodacom Internet Company 29975 191 667 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3007 3691 75 bellsouth.net, inc. 4766 2945 11561 922 Korea Telecom (KIX) 10620 2660 418 208 TVCABLE BOGOTA 28573 2655 1534 167 NET Servicos de Comunicao S.A 17974 2545 855 91 PT TELEKOMUNIKASI INDONESIA 18566 2065 382 184 Covad Communications 7545 1999 320 108 TPG Internet Pty Ltd 1785 1992 677 124 PaeTec Communications, Inc. 22773 1984 2927 122 Cox Communications, Inc. 4755 1744 391 191 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2655 2488 NET Servicos de Comunicao S.A 17974 2545 2454 PT TELEKOMUNIKASI INDONESIA 10620 2660 2452 TVCABLE BOGOTA 4766 2945 2023 Korea Telecom (KIX) 7545 1999 1891 TPG Internet Pty Ltd 18566 2065 1881 Covad Communications 1785 1992 1868 PaeTec Communications, Inc. 22773 1984 1862 Cox Communications, Inc. 8402 1667 1651 Corbina telecom 4755 1744 1553 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.57.0/24 60993 Totalsoft SA 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:11 /10:30 /11:91 /12:250 /13:484 /14:899 /15:1600 /16:12706 /17:6653 /18:11160 /19:22176 /20:32045 /21:34349 /22:47590 /23:42254 /24:239425 /25:1305 /26:1660 /27:851 /28:46 /29:61 /30:18 /31:0 /32:17 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 6389 1726 3007 bellsouth.net, inc. 8402 1363 1667 Corbina telecom 22773 1292 1984 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1196 1328 Mediacom Communications Corp 11492 1180 1218 Cable One 1785 1062 1992 PaeTec Communications, Inc. 6983 1011 1138 ITC^Deltacom 10620 991 2660 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:818 2:841 3:3 4:19 5:791 6:12 8:556 12:1923 13:3 14:836 15:11 16:3 17:10 20:17 23:370 24:1765 27:1473 31:1320 32:43 33:2 34:5 36:40 37:1855 38:874 39:2 40:170 41:2693 42:195 44:6 46:1929 47:2 49:660 50:734 52:11 54:35 55:5 57:26 58:1150 59:575 60:314 61:1405 62:1126 63:2022 64:4320 65:2162 66:4178 67:2054 68:1081 69:3264 70:786 71:488 72:1917 74:2475 75:323 76:303 77:1134 78:1051 79:614 80:1273 81:1007 82:654 83:577 84:541 85:1163 86:454 87:994 88:538 89:1748 90:147 91:5526 92:606 93:1667 94:1865 95:1653 96:513 97:346 98:1005 99:42 100:30 101:327 103:2790 105:517 106:146 107:208 108:514 109:1822 110:904 111:1053 112:544 113:813 114:709 115:964 116:963 117:799 118:1093 119:1313 120:379 121:730 122:1798 123:1220 124:1368 125:1377 128:639 129:223 130:326 131:662 132:341 133:148 134:267 135:67 136:222 137:242 138:359 139:193 140:212 141:332 142:538 143:383 144:500 145:93 146:507 147:384 148:686 149:369 150:157 151:506 152:419 153:188 154:42 155:408 156:268 157:396 158:279 159:732 160:343 161:447 162:420 163:221 164:598 165:497 166:273 167:597 168:1018 169:130 170:1052 171:181 172:21 173:1584 174:546 175:469 176:966 177:2057 178:1860 179:29 180:1460 181:465 182:1231 183:387 184:692 185:540 186:2293 187:1289 188:2150 189:1250 190:6835 192:6721 193:5667 194:4590 195:3430 196:1348 197:936 198:4482 199:5338 200:5988 201:2238 202:8827 203:8901 204:4514 205:2578 206:2799 207:2845 208:4046 209:3618 210:2956 211:1506 212:2186 213:1972 214:926 215:98 216:5235 217:1621 218:619 219:335 220:1281 221:557 222:322 223:456 End of report From khelms at zcorum.com Fri Jun 14 18:35:08 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 14 Jun 2013 14:35:08 -0400 Subject: huawei In-Reply-To: <9245.1371232292@turing-police.cc.vt.edu> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <9245.1371232292@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 14, 2013 at 1:51 PM, wrote: > On Fri, 14 Jun 2013 13:21:09 -0400, Scott Helms said: > > > How? There is truly not that much room in the IP packet to play games > and > > if you're modifying all your traffic this would again be pretty easy to > > spot. Again, the easiest/cheapest method is that there is a backdoor > there > > already. > > Do you actually examine your traffic and drop packets that have non-zeros > in reserved fields? (Remember what that did to the deployment of ECN?) > > And there's plenty of room if you stick a TCP or IP option header in > there. Do > you actually check for those too? > When I think something odd is happening or I'm benchmarking new gear from a new vendor, yes I do but the main point is that there is so little benefit for them do this why would they bother? > > How fast can you send data to a cooperating router down the way if you > splat > the low 3 bits of TCP timestamps on a connection routed towards the > cooperating > router? (SUre, you just busted somebody's RTT calculation, but it will just > decide it's a high-jitter path and deal with it). > In $random_deployment they have no idea what the topology is and odd behavior is *always *noticed over time. The amount of time it would take to transmit useful information would nearly guarantees someone noticing and the more successful the exploit was the more chance for discovery there would be. From erik.levinson at uberflip.com Fri Jun 14 18:37:28 2013 From: erik.levinson at uberflip.com (Erik Levinson) Date: Fri, 14 Jun 2013 14:37:28 -0400 Subject: GoDaddy DNS contact Message-ID: <51BB62E8.4010207@uberflip.com> Hello, Unfortunately we have some domains where GoDaddy is used as the registrar and primary DNS, with secondary DNS provided by another provider. I've been e-mailing back and forth with GoDaddy support for over three days because for the apex of one domain their authoritative name servers are returning an extra A record which is not visible in their zone editor UI. This extra A record causes a GoDaddy "parking" page to be shown when browsing to the root of the domain. I'm sending them something that looks like this: $ dig +short THEDOMAINGOESHERE @pdns01.domaincontrol.com WHAT-I-ACTUALLY-CONFIGURED 50.63.202.40 They refuse to acknowledge that there's a problem and suggest we remove the secondary DNS provider because, according to them, the secondary DNS is what's randomly adding a GoDaddy parking service A record. I'm not including the actual domain above because we have private registration on it and it's used for an unbranded part of our service for resellers. If anyone knows a GoDaddy contact who could help, I'd appreciate getting the info. Thanks -- Erik Levinson CTO, Uberflip 416-900-3830 1183 King Street West, Suite 100 Toronto ON M6K 3C5 www.uberflip.com From mike at mtcc.com Fri Jun 14 18:57:30 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 14 Jun 2013 11:57:30 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <9245.1371232292@turing-police.cc.vt.edu> Message-ID: <51BB679A.3030303@mtcc.com> On 06/14/2013 11:35 AM, Scott Helms wrote: > In $random_deployment they have no idea what the topology is and odd behavior is *always *noticed over time. The amount of time it would take to transmit useful information would nearly guarantees someone noticing and the more successful the exploit was the more chance for discovery there would be. As a software developer for many, many years, I can guarantee you that is categorically wrong. I'd venture to say you probably don't even notice half. And that's for things that are just bugs or misfeatures. Something that was purposeful and done by people who know what they're doing... your odds in Vegas are better IMO. Mike, who's seen way too many "how in the hell did that ever work?" From chris.burri at hotmail.ch Fri Jun 14 18:55:37 2013 From: chris.burri at hotmail.ch (chris burri) Date: Fri, 14 Jun 2013 20:55:37 +0200 Subject: FW: Transparent 1Gig Ethernet over IP/Ethernet? In-Reply-To: References: Message-ID: Hi all, I need to transparently (especially LACP frames) transport a gigabit Ethernet link with at least 1500 MTU over either IP or Ethernet. Jumbo frames are enabled on the transport backbone. While I need "full" (some encap overhead will be acceptable) GigE wire speed, encryption is unnecessary. Can anyone suggest a product -ideally some low-maintenance, high-reliability, perhaps ASIC-based hardware- that can do this? TIA Chris From philfagan at gmail.com Fri Jun 14 19:34:16 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 14 Jun 2013 13:34:16 -0600 Subject: Blocking TCP flows? In-Reply-To: References: <2901AB0C-77FC-405A-BA59-047D064E1CC3@arbor.net> Message-ID: I think we just discussed this over in the huawei list ;-) This is pretty awesome! On Fri, Jun 14, 2013 at 12:30 PM, Eric Wustrow wrote: > Oddly enough, anticensorship. We use similar technology as the censors > (DPI, flow blocking), but use our system in a non-censoring country's ISP > to detect secret tags in connections from censored countries, and serve as > a proxy for them. Once we detect a flow with a secret tag passing through > the ISP, we block the real flow, and start spoofing half of the connection. > We use this covert channel to communicate to the client and act as a proxy. > To the censor, this looks like a normal connection to some innocuous, > unrelated (and unblocked) website. The obvious difficulty is convincing > ISPs to deploy such a proxy. More details can be found at > https://telex.cc/ > > > > On Fri, Jun 14, 2013 at 3:15 AM, Dobbins, Roland > wrote: > > > > > On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote: > > > > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 > > gbps link, with new blocked flows being dropped within a millisecond or > so > > of > > > being added. > > > > What's the actual application for this mechanism? > > > > ----------------------------------------------------------------------- > > Roland Dobbins // > > > > Luck is the residue of opportunity and design. > > > > -- John Milton > > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From Valdis.Kletnieks at vt.edu Fri Jun 14 19:45:46 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 14 Jun 2013 15:45:46 -0400 Subject: huawei In-Reply-To: Your message of "Fri, 14 Jun 2013 14:35:08 -0400." References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <9245.1371232292@turing-police.cc.vt.edu> Message-ID: <14777.1371239146@turing-police.cc.vt.edu> On Fri, 14 Jun 2013 14:35:08 -0400, Scott Helms said: > In $random_deployment they have no idea what the topology is and odd > behavior is *always *noticed over time. Severe selection bias in that statement. Odd *noticed* behavior is always noticed. There's literally *no* way to know how many times somebody's looked at a packet trace trying to diagnose something else and failed to notice something subtly odd. (Donald Rumsfeld correctly identified these as "unknown unknowns"). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From william.allen.simpson at gmail.com Fri Jun 14 20:19:38 2013 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 14 Jun 2013 16:19:38 -0400 Subject: how in the hell did that ever work? [was: huawei] In-Reply-To: <51BB679A.3030303@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <9245.1371232292@turing-police.cc.vt.edu> <51BB679A.3030303@mtcc.com> Message-ID: <51BB7ADA.1010303@gmail.com> On 6/14/13 2:57 PM, Michael Thomas wrote: > On 06/14/2013 11:35 AM, Scott Helms wrote: >> In $random_deployment they have no idea what the topology is and odd behavior is *always *noticed over time. The amount of time it would take to transmit useful information would nearly guarantees someone noticing and the more successful the exploit was >> the more chance for discovery there would be. > > As a software developer for many, many years, I can guarantee you > that is categorically wrong. I'd venture to say you probably don't even > notice half. And that's for things that are just bugs or misfeatures. > Something that was purposeful and done by people who know what > they're doing... your odds in Vegas are better IMO. > > Mike, who's seen way too many "how in the hell did that ever work?" > Ah, how well I remember the '91 Interop. One new dialup network access server worked great everywhere -- except going through 3Com routers. Something wrong with 3Com routers? Ha! No, after a lot of network packet debugging, it turned out the NAS was setting IP version to 0. (A tiny bug in a compile.) Only 3Com was checking the IP version! That is, by definition, only 3Com routers actually worked properly!!! And we had a lot more router vendors in those days.... From paul.zugnoni at jivesoftware.com Fri Jun 14 20:22:28 2013 From: paul.zugnoni at jivesoftware.com (Paul Zugnoni) Date: Fri, 14 Jun 2013 20:22:28 +0000 Subject: TWT 24.55.0.0/18 blacklisted by Team Cymru 38.229.66.20 Message-ID: <73A9A2579638014A8254BF9FE31DDB24795A59CC@mbx6.jiveland.com> Have at least one user, a TWT broadband customer, reporting his IP as being within 24.55.0.0/18, which I'm receiving from Team Cymru 38.229.66.20 Bogon peer. Anyone from TWT aware? > show route receive-protocol bgp 38.229.66.20 24.55.0.0/18 terse inet.0: 458306 destinations, 2258530 routes (458303 active, 2 holddown, 2 hidden) Restart Complete Prefix Nexthop MED Lclpref AS path * 24.55.0.0/18 38.229.66.20 65332 I >From all my transit providers, it's origin is 11427. Paul Zugnoni From andrew.koch at tdstelecom.com Fri Jun 14 20:42:12 2013 From: andrew.koch at tdstelecom.com (Koch, Andrew) Date: Fri, 14 Jun 2013 20:42:12 +0000 Subject: TWT 24.55.0.0/18 blacklisted by Team Cymru 38.229.66.20 In-Reply-To: <73A9A2579638014A8254BF9FE31DDB24795A59CC@mbx6.jiveland.com> References: <73A9A2579638014A8254BF9FE31DDB24795A59CC@mbx6.jiveland.com> Message-ID: <9FD362844B11AF4BBFE6DBFE0B5619511E81A470@cmailbox7> On June 14, 2013 15:22 Paul Zugnoni [mailto:paul.zugnoni at jivesoftware.com] wrote: > Have at least one user, a TWT broadband customer, reporting his IP as > being within 24.55.0.0/18, which I'm receiving from Team Cymru > 38.229.66.20 Bogon peer. Anyone from TWT aware? > > > show route receive-protocol bgp 38.229.66.20 24.55.0.0/18 terse > > inet.0: 458306 destinations, 2258530 routes (458303 active, 2 holddown, 2 > hidden) > Restart Complete > Prefix Nexthop MED Lclpref AS path > * 24.55.0.0/18 38.229.66.20 65332 I > > From all my transit providers, it's origin is 11427. That prefix does not show on the HTTP version http://www.team-ymru.org/Services/Bogons/fullbogons-ipv4.txt (# last updated 1371214084 (Fri Jun 14 12:48:04 2013 GMT). It appears this prefix was allocated by ARIN a couple weeks ago. NetRange: 24.55.0.0 - 24.55.63.255 CIDR: 24.55.0.0/18 OriginAS: AS11427 NetName: RRSW NetHandle: NET-24-55-0-0-1 Parent: NET-24-0-0-0-0 NetType: Direct Allocation RegDate: 2013-05-28 Updated: 2013-05-28 Ref: http://whois.arin.net/rest/net/NET-24-55-0-0-1 I reported the mismatch between the BGP and HTTP feeds to support at cymru, but have not received a response yet. You may need to filter the announcement out from Team Cymru until they figure out why the BGP feed is not updated. Andy Koch TDS Telecom - IP Network Operations andrew.koch at tdstelecom.com From cidr-report at potaroo.net Fri Jun 14 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Jun 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201306142200.r5EM00fW048988@wattle.apnic.net> This report has been generated at Fri Jun 14 21:13:22 2013 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 07-06-13 457163 260461 08-06-13 457241 260445 09-06-13 457065 260403 10-06-13 457095 260442 11-06-13 457230 260407 12-06-13 457470 260195 13-06-13 457316 260303 14-06-13 457227 260695 AS Summary 44409 Number of ASes in routing system 18362 Number of ASes announcing only one prefix 3007 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116803552 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 14Jun13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 457785 260717 197068 43.0% All ASes AS6389 3007 79 2928 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2812 111 2701 96.1% NET Servi?os de Comunica??o S.A. AS17974 2544 535 2009 79.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2945 938 2007 68.1% KIXS-AS-KR Korea Telecom AS10620 2660 825 1835 69.0% Telmex Colombia S.A. AS22773 1984 152 1832 92.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 474 1591 77.0% COVAD - Covad Communications Co. AS7303 1732 454 1278 73.8% Telecom Argentina S.A. AS4323 1628 410 1218 74.8% TWTC - tw telecom holdings, inc. AS4755 1743 586 1157 66.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1069 85 984 92.0% RELCOM-AS OOO "NPO Relcom" AS7552 1162 194 968 83.3% VIETEL-AS-AP Vietel Corporation AS18881 995 44 951 95.6% Global Village Telecom AS36998 1237 301 936 75.7% SDN-MOBITEL AS1785 1992 1149 843 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1002 182 820 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1144 392 752 65.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1535 803 732 47.7% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 843 139 704 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS22561 1191 511 680 57.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS855 734 55 679 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1289 617 672 52.1% Uninet S.A. de C.V. AS24560 1077 410 667 61.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6983 1138 477 661 58.1% ITCDELTA - ITC^Deltacom AS7545 2006 1354 652 32.5% TPG-INTERNET-AP TPG Telecom Limited AS17676 732 109 623 85.1% GIGAINFRA Softbank BB Corp. AS6147 665 48 617 92.8% Telefonica del Peru S.A.A. AS3549 1050 440 610 58.1% GBLX Global Crossing Ltd. AS34744 676 72 604 89.3% GVM S.C. GVM SISTEM 2003 S.R.L. AS31148 802 210 592 73.8% FREENET-AS Freenet Ltd. Total 45459 12156 33303 73.3% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 115.31.64.0/20 AS17639 COMCLARK-AS ComClark Network & Technology Corp. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.50.176.0/24 AS38267 120.50.177.0/24 AS38267 120.50.178.0/24 AS38267 120.50.179.0/24 AS38267 120.50.180.0/24 AS38267 120.50.181.0/24 AS38267 120.50.182.0/24 AS38267 120.50.183.0/24 AS38267 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.128.0/20 AS32738 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 195.248.240.0/23 AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.70.56.0/21 AS32738 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.127.223.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jun 14 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Jun 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201306142200.r5EM0218049004@wattle.apnic.net> BGP Update Report Interval: 06-Jun-13 -to- 13-Jun-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 191638 8.3% 470.9 -- SDN-MOBITEL 2 - AS27947 49625 2.1% 149.5 -- Telconet S.A 3 - AS8402 41688 1.8% 26.9 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS4837 39287 1.7% 72.9 -- CHINA169-BACKBONE CNCGROUP China169 Backbone 5 - AS18403 35542 1.5% 70.8 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 6 - AS9829 34126 1.5% 46.9 -- BSNL-NIB National Internet Backbone 7 - AS11492 25202 1.1% 47.9 -- CABLEONE - CABLE ONE, INC. 8 - AS17974 23969 1.0% 12.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS7552 23096 1.0% 19.6 -- VIETEL-AS-AP Vietel Corporation 10 - AS27738 20083 0.9% 35.1 -- Ecuadortelecom S.A. 11 - AS2911 19434 0.8% 9717.0 -- CITI4 - Citicorp 12 - AS28573 17318 0.8% 8.0 -- NET Servi?os de Comunica??o S.A. 13 - AS9416 16478 0.7% 4119.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 14 - AS53189 14565 0.6% 539.4 -- NS Telecomunica??es Ltda 15 - AS14420 13361 0.6% 45.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 16 - AS10620 12579 0.5% 4.8 -- Telmex Colombia S.A. 17 - AS30693 11508 0.5% 123.7 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 18 - AS50710 11064 0.5% 47.3 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 19 - AS60974 11001 0.5% 224.5 -- NAICOMS Naicoms EOOD 20 - AS33776 10474 0.5% 56.9 -- STARCOMMS-ASN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9854 9980 0.4% 9980.0 -- KTO-AS-KR KTO 2 - AS2911 19434 0.8% 9717.0 -- CITI4 - Citicorp 3 - AS6629 7424 0.3% 7424.0 -- NOAA-AS - NOAA 4 - AS8137 4834 0.2% 4834.0 -- DISNEYONLINE-AS - Disney Online 5 - AS42334 4542 0.2% 4542.0 -- BBP-AS Broadband Plus s.a.l. 6 - AS9416 16478 0.7% 4119.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - AS14733 7502 0.3% 3751.0 -- AS14733 - Barclays Capital Inc. 8 - AS6174 6292 0.3% 3146.0 -- SPRINTLINK8 - Sprint 9 - AS36225 2913 0.1% 2913.0 -- INFINITEIT-ASN-01 - Infinite IT Solutions Inc. 10 - AS14680 6729 0.3% 2243.0 -- REALE-6 - Auction.com 11 - AS37367 3705 0.2% 1852.5 -- CALLKEY 12 - AS14453 5891 0.2% 1178.2 -- AS-AKN - ADVANCED KNOWLEDGE NETWORKS 13 - AS57201 1167 0.1% 1167.0 -- EDF-AS Estonian Defence Forces 14 - AS3909 9245 0.4% 1155.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 15 - AS16982 1150 0.1% 1150.0 -- SUSQUEHANNA-26 - Susquehanna Bank 16 - AS16921 3003 0.1% 1001.0 -- INTELIGLOBE-1 - Inteliglobe USA, Inc. 17 - AS36153 938 0.0% 938.0 -- AVCTHSV - Avocent Huntsville Corporation 18 - AS22688 869 0.0% 869.0 -- DOLGENCORP - Dollar General Corporation 19 - AS8253 820 0.0% 820.0 -- DUTHNET-AS Democritus University of Thrace 20 - AS27164 2233 0.1% 744.3 -- US-INTERNET - Global Reach Communications LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 211.214.206.0/24 9980 0.4% AS9854 -- KTO-AS-KR KTO 2 - 192.193.196.0/24 9717 0.4% AS2911 -- CITI4 - Citicorp 3 - 192.193.195.0/24 9717 0.4% AS2911 -- CITI4 - Citicorp 4 - 92.246.207.0/24 9308 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 5 - 203.118.232.0/21 8394 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 203.118.224.0/21 8082 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - 192.107.15.0/24 7501 0.3% AS14733 -- AS14733 - Barclays Capital Inc. 8 - 192.58.232.0/24 7424 0.3% AS6629 -- NOAA-AS - NOAA 9 - 12.139.133.0/24 5651 0.2% AS14680 -- REALE-6 - Auction.com 10 - 173.232.235.0/24 5626 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 11 - 173.232.234.0/24 5624 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 12 - 202.41.70.0/24 5152 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 13 - 198.187.189.0/24 4834 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 14 - 69.38.178.0/24 4679 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 15 - 62.84.76.0/24 4542 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 16 - 64.187.64.0/23 4359 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 17 - 204.245.102.0/24 3828 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 18 - 41.75.40.0/21 3703 0.1% AS37367 -- CALLKEY 19 - 5.102.192.0/19 3620 0.1% AS47956 -- XFONE XFONE COMMUNICATION LTD 20 - 64.187.64.0/24 3350 0.1% AS16608 -- KENTEC - Kentec Communications, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From bclaise at cisco.com Fri Jun 14 23:04:39 2013 From: bclaise at cisco.com (Benoit Claise) Date: Sat, 15 Jun 2013 01:04:39 +0200 Subject: Fwd: WG Review: Large-Scale Measurement of Broadband Performance (lmap) In-Reply-To: <20130614154155.24228.49697.idtracker@ietfa.amsl.com> References: <20130614154155.24228.49697.idtracker@ietfa.amsl.com> Message-ID: <51BBA187.3070202@cisco.com> Dear all, FYI. Please your feedback to the IETF mailing list, or directly to Joel (in the cc) and me Regards, Benoit -------- Original Message -------- Subject: WG Review: Large-Scale Measurement of Broadband Performance (lmap) Date: Fri, 14 Jun 2013 08:41:55 -0700 From: The IESG Reply-To: ietf at ietf.org To: IETF-Announce CC: lmap WG A new IETF working group has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-06-24. Large-Scale Measurement of Broadband Performance (lmap) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Benoit Claise Mailing list Address: lmap at ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/lmap Archive: http://www.ietf.org/mail-archive/web/lmap Charter: The Large-Scale Measurement of Broadband Performance (LMAP) working group standardizes the LMAP measurement system for performance measurements of broadband access devices such as home and enterprise edge routers, personal computers, mobile devices, set top box, whether wired or wireless. Measuring portions of the Internet on a large scale is essential for accurate characterizations of performance over time and geography, for network diagnostic investigations by providers and their users, and for collecting information to support public policy development. The goal is to have the measurements (made using the same metrics and mechanisms) for a large number of points on the Internet, and to have the results collected and stored in the same form. The LMAP working group is chartered to specify an information model, the associated data models, and select/extend one or more protocols for the secure communication: 1. A Control Protocol, from a Controller to instruct Measurement Agents what performance metrics to measure, when to measure them, how/when to report the measurement results to a Collector, 2. A Report Protocol, for a Measurement Agent to report the results to the Collector. The data models should be extensible for new and additional measurements. LMAP will consider re-use of existing data models languages. A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). However, the components of an LMAP measurement system can be deployed in administrative domains that are not owned by the measuring organization. Thus, the system of functions deployed by a single organization constitutes a single LMAP domain which may span ownership or other administrative boundaries. The LMAP architecture will allow for measurements that utilize either IPv4 or IPv6, or possibly both. Devices containing Measurement Agents may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols. It is assumed that different organization's LMAP measurement domains can overlap, and that active measurement packets appear along with normal user traffic when crossing another organization's network. There is no requirement to specify a mechanism for coordination between the LMAP measurements in overlapping domains (for instance a home network with MAs on the home gateway, set top box and laptop). In principle, there are no restrictions on the type of device in which the MA function resides. Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category. LMAP will not standardize performance metrics. The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined. Standardizing control of end users Measurement Agents is out of scope. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Inter-organization communication of results is out of scope of the LMAP charter. The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter. Service parameters, such as product category, can be useful to decide which measurements to run and how to interpret the results. These parameters are already gathered and stored by existing operations systems. Discovering the service parameters on the MAs or sharing the service parameters between MAs are out of the scope. However, if the service parameters are available to the MAs, they could be reported with the measurement results in the Report Protocol. Deciding the set of measurements to run is a business decision and is out of scope of the LMAP charter. Protection against the intentional or malicious insertion of inaccuracies into the overall system or measurement process (sometimes known as "gaming the system") is outside the scope of work. The LMAP working group will coordinate with other standards bodies working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the information model, and with other IETF working groups in the areas of data models, protocols, multiple interface management, and measurement of performance metrics. The LMAP WG will produce the following work items: 1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints 2. The LMAP Use Cases - provides the motivating use cases as a basis for the work 3. Information Model, the abstract definition of the information carried from the Controller to the MA and the information carried from the MA to the Collector. It includes * The metric(s) that can be measured and values for its parameters such as the Peer MA participating in the measurement and the desired environmental conditions (for example, only conduct the measurement when there is no user traffic observed) * The schedule: when the measurement should be run and how the results should be reported (when and to which Collector) * The report: the metric(s) measured and when, the actual result, and supporting metadata such as location. Result reports may be organized in batches or may be reported immediately, such as for an on-demand measurement. 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Milestones: Sep 2013 Initial WG I-D for the LMAP Framework including terminology Sep 2013 Initial WG I-D for the LMAP Use cases Dec 2013 Submit the LMAP Framework I-D to the IESG for consideration as Informational RFC Dec 2013 Submit I-D on the LMAP Use cases to the IESG for consideration as Informational RFC Jan 2014 Initial WG I-D for LMAP Information models Apr 2014 Initial WG I-D for the Control protocol Apr 2014 Initial WG I-D for the Report protocol Apr 2014 Initial WG I-D for a Data model for LMAP control information Apr 2014 Initial WG I-D for a Data model for LMAP report information Jul 2014 Submit the LMAP Information models I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Control protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Report protocol I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Data model for LMAP control I-D to the IESG for consideration as Standards track RFC Dec 2014 Submit the Data model for LMAP report I-D to the IESG for consideration as Standards track RFC From mysidia at gmail.com Fri Jun 14 23:35:38 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 14 Jun 2013 18:35:38 -0500 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: On 6/14/13, Scott Helms wrote: > backdoors (intentional or not) are in most if not all gear. Having said > that, it would still be pretty obvious in mass and over time to have > packets going to a predesignated host. Its not really possible for a box > to know whether its in a "real" network or a lab with Spirent or other > traffic generator hooked to it. It wouldn't have to send packets to a predefined host. Conceivably, it could leak bits of information by modulating the timing of packets forwarded by it, the spacing in times of packets from simple legitimate HTTP, DNS, or ICMP response, from behind the router, for protocols involving multiple RTTs, could be used to encode bits of information to be transmitted covertly. ; furthermore, the signalling to start communicating over the "timing based" hidden channel, could be established in various ways that would thoroughly disguise the malicious nature of the attacker's signalling. -- -JH From khelms at zcorum.com Fri Jun 14 23:51:22 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 14 Jun 2013 19:51:22 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: Really? In a completely controlled network then yes, but not in a production system. There is far too much random noise and actual latency for that to be feasible. On Jun 14, 2013 7:35 PM, "Jimmy Hess" wrote: > On 6/14/13, Scott Helms wrote: > > > backdoors (intentional or not) are in most if not all gear. Having said > > that, it would still be pretty obvious in mass and over time to have > > packets going to a predesignated host. Its not really possible for a box > > to know whether its in a "real" network or a lab with Spirent or other > > traffic generator hooked to it. > > It wouldn't have to send packets to a predefined host. > > Conceivably, it could leak bits of information by modulating the > timing of packets forwarded by it, the spacing in times of packets > from simple legitimate HTTP, DNS, or ICMP response, from behind the > router, for protocols involving multiple RTTs, could be used to > encode bits of information to be transmitted covertly. > > ; furthermore, the signalling to start communicating over the > "timing based" hidden channel, could be established in various > ways that would thoroughly disguise the malicious nature of the > attacker's signalling. > > -- > -JH > From mysidia at gmail.com Sat Jun 15 00:12:59 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 14 Jun 2013 19:12:59 -0500 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: On 6/14/13, Scott Helms wrote: > Really? In a completely controlled network then yes, but not in a > production system. There is far too much random noise and actual latency > for that to be feasible. I think you might be applying an oversimplified assumption the situation. Noise limits the capacity of a channel, and increases the number of gyrations required to encode a bit, so that it can be received without error. The degree of 'random noise', 'actual latency variation', and 'natural packet ordering' can be estimated, to identify the noise. Even with noise, you can figure out, that the average value which the errors were centered around increased by 5ms or 10ms, when a sequence of packets with certain sizes, certain checksum values, and certain ephemeral ports were processed in a certain sequence, after a sufficient number of repetitions. -- -JH From khelms at zcorum.com Sat Jun 15 00:34:49 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 14 Jun 2013 20:34:49 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: Is it possible? Yes, but it's not feasible because the data rate would be too low. That's what I'm trying to get across. There are lots things that can be done but many of those are not useful. I could encode communications in fireworks displays, but that's not effective for any sort of communication system. On Jun 14, 2013 8:13 PM, "Jimmy Hess" wrote: > On 6/14/13, Scott Helms wrote: > > Really? In a completely controlled network then yes, but not in a > > production system. There is far too much random noise and actual latency > > for that to be feasible. > > I think you might be applying an oversimplified assumption the > situation. Noise limits the capacity of a channel, and increases > the number of gyrations required to encode a bit, so that it can be > received without error. > > The degree of 'random noise', 'actual latency variation', and > 'natural packet ordering' can be estimated, to identify the noise. > > Even with noise, you can figure out, that the average value which > the errors were centered around increased by 5ms or 10ms, when a > sequence of packets with certain sizes, certain checksum values, and > certain ephemeral ports were processed in a certain sequence, > after a sufficient number of repetitions. > > -- > -JH > From andrew.koch at tdstelecom.com Sat Jun 15 00:43:13 2013 From: andrew.koch at tdstelecom.com (Koch, Andrew) Date: Sat, 15 Jun 2013 00:43:13 +0000 Subject: TWT 24.55.0.0/18 blacklisted by Team Cymru 38.229.66.20 In-Reply-To: <9FD362844B11AF4BBFE6DBFE0B5619511E81A470@cmailbox7> References: <73A9A2579638014A8254BF9FE31DDB24795A59CC@mbx6.jiveland.com> <9FD362844B11AF4BBFE6DBFE0B5619511E81A470@cmailbox7> Message-ID: <88137bc1-0d75-44d3-9e8e-47c6153b3591@CMAILHUB1.corp.tds.local> On June 14, 2013 15:42, Koch, Andrew [mailto:andrew.koch at tdstelecom.com] wrote: > On June 14, 2013 15:22 Paul Zugnoni [mailto:paul.zugnoni at jivesoftware.com] > wrote: > > Have at least one user, a TWT broadband customer, reporting his IP as > > being within 24.55.0.0/18, which I'm receiving from Team Cymru > > 38.229.66.20 Bogon peer. > I reported the mismatch between the BGP and HTTP feeds to support at cymru, > but have not received a response yet. You may need to filter the > announcement out from Team Cymru until they figure out why the BGP feed is > not updated. Team Cymru contacted me that this should now be resolved. I have confirmed that this prefix is no longer received via the full-bogons BGP feed. Andy Koch TDS Telecom - IP Network Operations andrew.koch at tdstelecom.com From wbailey at satelliteintelligencegroup.com Sat Jun 15 00:46:26 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 15 Jun 2013 00:46:26 +0000 Subject: huawei In-Reply-To: Message-ID: It is if you're trying to figure out something far away, smoke signals come to mind (seriously). Any amount of noise seen (aside from AWGN, obviously) in the world is not a big deal. We have pretty neat ways to clean up noise in bandwidth channels. ;) http://www.comtechefdata.com/technologies/doubletalk is one of the plays we roll out all the time. Applied Signal (father of ninja magic mentioned above) had offices in Crypto City, but were eaten by Raytheon a while back and I'm unsure if they're still around. Food for thought, but really - don't sweat the noise. On 6/14/13 5:34 PM, "Scott Helms" wrote: >Is it possible? Yes, but it's not feasible because the data rate would be >too low. That's what I'm trying to get across. There are lots things >that >can be done but many of those are not useful. > >I could encode communications in fireworks displays, but that's not >effective for any sort of communication system. >On Jun 14, 2013 8:13 PM, "Jimmy Hess" wrote: > >> On 6/14/13, Scott Helms wrote: >> > Really? In a completely controlled network then yes, but not in a >> > production system. There is far too much random noise and actual >>latency >> > for that to be feasible. >> >> I think you might be applying an oversimplified assumption the >> situation. Noise limits the capacity of a channel, and increases >> the number of gyrations required to encode a bit, so that it can be >> received without error. >> >> The degree of 'random noise', 'actual latency variation', and >> 'natural packet ordering' can be estimated, to identify the noise. >> >> Even with noise, you can figure out, that the average value which >> the errors were centered around increased by 5ms or 10ms, when a >> sequence of packets with certain sizes, certain checksum values, and >> certain ephemeral ports were processed in a certain sequence, >> after a sufficient number of repetitions. >> >> -- >> -JH >> From mike at mtcc.com Sat Jun 15 01:09:40 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 14 Jun 2013 18:09:40 -0700 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: <51BBBED4.1080705@mtcc.com> On 06/14/2013 05:34 PM, Scott Helms wrote: > Is it possible? Yes, but it's not feasible because the data rate would be > too low. That's what I'm trying to get across. There are lots things that > can be done but many of those are not useful. > > I could encode communications in fireworks displays, but that's not > effective for any sort of communication system. > You're really hung up on bit rate, and you really shouldn't. Back in the days before gigabit pipes, tapping out morse was considered a data rate beyond belief. Ships used flags and signaling lights well into the second world war at least. The higher the value of the information, the lower the bit rate you need to transmit it (I think this might formally be information entropy, but I'm not certain). You might think that there is nothing of particularly high value to be had within the confines of what a (compromised) router can produce, but I'd say prepare to be surprised. I'm not much of a military guy, but some of the stuff they dream up makes you go "how on earth did you think that up?". And that's just the unclassified widely known stuff. Part of the issue when you say "it could be done cheaper somewhere else" presupposes we know the economics of what they're trying to do. We don't, so we should assume that routers just like everything else are a target, and that you almost certainly won't notice it if they are. Mike From khelms at zcorum.com Sat Jun 15 03:13:39 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 14 Jun 2013 23:13:39 -0400 Subject: huawei In-Reply-To: <51BBBED4.1080705@mtcc.com> References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <51BBBED4.1080705@mtcc.com> Message-ID: I was a "military guy"back in the day 31m and 31q to be precise. On Jun 14, 2013 9:09 PM, "Michael Thomas" wrote: > On 06/14/2013 05:34 PM, Scott Helms wrote: > >> Is it possible? Yes, but it's not feasible because the data rate would be >> too low. That's what I'm trying to get across. There are lots things >> that >> can be done but many of those are not useful. >> >> I could encode communications in fireworks displays, but that's not >> effective for any sort of communication system. >> >> > You're really hung up on bit rate, and you really shouldn't. Back in > the days before gigabit pipes, tapping out morse was considered > a data rate beyond belief. Ships used flags and signaling lights well > into the second world war at least. The higher the value of the > information, the lower the bit rate you need to transmit it (I think > this might formally be information entropy, but I'm not certain). > > You might think that there is nothing of particularly high value to be > had within the confines of what a (compromised) router can produce, > but I'd say prepare to be surprised. I'm not much of a military guy, but > some of the stuff they dream up makes you go "how on earth did you > think that up?". And that's just the unclassified widely known stuff. > Part of the issue when you say "it could be done cheaper somewhere > else" presupposes we know the economics of what they're trying to do. > We don't, so we should assume that routers just like everything else are > a target, and that you almost certainly won't notice it if they are. > > Mike > From mysidia at gmail.com Sat Jun 15 06:56:34 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 15 Jun 2013 01:56:34 -0500 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: On 6/14/13, Scott Helms wrote: > Is it possible? Yes, but it's not feasible because the data rate would be > too low. That's what I'm trying to get across. There are lots things that > can be done but many of those are not useful. [snip] I agree that the data rate will be low. I don't agree that it's not feasible. There will be indeed be _plenty_ of ways that a low bit rate channel can do everything the right adversary needs. A few bits for second is plenty of data rate for sending control commands/rule changes to a router backdoor mechanism, stealing passwords, or leaking cryptographic keys required to decrypt the VPN data stream intercepted from elsewhere on the network, leaking counters, snmp communities, or interface descriptions, or criteria-selected forwarded data samples, etc.... -- -JH From mansaxel at besserwisser.org Sat Jun 15 07:30:09 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 15 Jun 2013 09:30:09 +0200 Subject: Prism continued In-Reply-To: <20130612171345.D489ABA2@m0005296.ppops.net> References: <20130612171345.D489ABA2@m0005296.ppops.net> Message-ID: <20130615073009.GA22491@besserwisser.org> Subject: Re: Prism continued Date: Wed, Jun 12, 2013 at 05:13:45PM -0700 Quoting Scott Weeks (surfer at mauigateway.com): > or "cat /var/log/router.log | egrep -v 'term1|term2|term3' | less" Surely you mean egrep -v 'term1|term2|term3' /var/log/router.log | less (http://partmaps.org/era/unix/award.html) -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 While you're chewing, think of STEVEN SPIELBERG'S bank account ... his will have the same effect as two "STARCH BLOCKERS"! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From eugen at leitl.org Sat Jun 15 08:12:36 2013 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 15 Jun 2013 10:12:36 +0200 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: <20130615081236.GU22824@leitl.org> On Fri, Jun 14, 2013 at 07:51:22PM -0400, Scott Helms wrote: > Really? In a completely controlled network then yes, but not in a > production system. There is far too much random noise and actual latency > for that to be feasible. The coding used for the stegano side channel can be made quite robust, see watermarking. From eugen at leitl.org Sat Jun 15 08:19:55 2013 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 15 Jun 2013 10:19:55 +0200 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: <20130615081955.GW22824@leitl.org> On Fri, Jun 14, 2013 at 08:34:49PM -0400, Scott Helms wrote: > Is it possible? Yes, but it's not feasible because the data rate would be > too low. That's what I'm trying to get across. There are lots things that > can be done but many of those are not useful. > > I could encode communications in fireworks displays, but that's not > effective for any sort of communication system. Depends on the value of secrets leaked. Secret keys don't have a lot of bits, and change rarely, if ever. Shell code is typically compact, too. Something which requires several side effects acting constructively is completely invisible, even if you're reading the source. From khelms at zcorum.com Sat Jun 15 11:44:32 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 15 Jun 2013 07:44:32 -0400 Subject: huawei In-Reply-To: <20130615081236.GU22824@leitl.org> References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615081236.GU22824@leitl.org> Message-ID: With the CPU and RAM available in a router that has to actually continue functioning at the same time? Exactly how much data through put would you consider to be usable in this scenario? Again, my point is not that its impossible but that all these things are impractical AND there are easier/faster/cheaper ways of capturing traffic. There are also easier/faster/cheaper ways of disrupting traffic. Routers in the core are great places to execute a targeted man in the middle attack. They're great places to disrupt traffic by behaving erratically, intentionally mangling dynamic routing protocols, or by simply going dark. They're terrible places for gathering non-targeted information because the amount of data flowing through them means that that the likelihood of any give packet having any value is very very low. If the goal includes stealing data then leveraging edge routing is much more realistic and leveraging PCs is several orders of magnitude better because there is much more available horsepower and its much easier to make a PC passively listen for interesting data on its own. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Sat, Jun 15, 2013 at 4:12 AM, Eugen Leitl wrote: > On Fri, Jun 14, 2013 at 07:51:22PM -0400, Scott Helms wrote: > > Really? In a completely controlled network then yes, but not in a > > production system. There is far too much random noise and actual latency > > for that to be feasible. > > The coding used for the stegano side channel can be made quite robust, > see watermarking. > > From khelms at zcorum.com Sat Jun 15 11:49:53 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 15 Jun 2013 07:49:53 -0400 Subject: huawei In-Reply-To: References: <2116700651-1371140872-cardhu_decombobulator_blackberry.rim.net-420291214-@b4.c20.bise6.blackberry> <51B9F82F.9090205@mtcc.com> <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: I can't agree Jimmy, I don't see a few bps being anywhere close to being useful in any of the scenarios your describe especially because there are easier ways of doing those things. To do any of that the first thing you have to do is establish the C&C channel so now you have a very low bit rate bi-directional communication so by the time the C&C asks the router to start stealing a key the IP of one of the IPSEC tunnel has changed. If the router intercepts traffic for a given IP or block what is going to do with it? It has very little non-volatile storage and we have such a low bit rate of communication that it can't just send a copy. A core router seldom has so many spare CPU cycles & free RAM that it can afford to read through the data and glean the interesting bits. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Sat, Jun 15, 2013 at 2:56 AM, Jimmy Hess wrote: > On 6/14/13, Scott Helms wrote: > > Is it possible? Yes, but it's not feasible because the data rate would > be > > too low. That's what I'm trying to get across. There are lots things > that > > can be done but many of those are not useful. > [snip] > > I agree that the data rate will be low. I don't agree that it's not > feasible. > > There will be indeed be _plenty_ of ways that a low bit rate channel > can do everything the right adversary needs. > > A few bits for second is plenty of data rate for sending control > commands/rule changes to a router backdoor mechanism, stealing > passwords, or leaking cryptographic keys required to decrypt the VPN > data stream intercepted from elsewhere on the network, leaking > counters, snmp communities, or interface descriptions, or > criteria-selected forwarded data samples, etc.... > > > -- > -JH > From mysidia at gmail.com Sat Jun 15 11:57:16 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 15 Jun 2013 06:57:16 -0500 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615081236.GU22824@leitl.org> Message-ID: On 6/15/13, Scott Helms wrote: > They're terrible places for gathering non-targeted information because the > amount of data flowing through them means that that the likelihood of any > give packet having any value is very very low. If the goal includes [snip] The probability of a low-likelihood or infrequent event approaches 100%, given sufficient time, persistence, and creativity. Even if 1% or less of packets passing through are interesting; that happens to be more than enough to provide a snoop gains, and cause damage to a legitimate user. The potential existence of 'better' options; doesn't mean backdooring of routers wouldn't be included in part of a nation state or other bad actor's backdooring program. -- -JH From khelms at zcorum.com Sat Jun 15 12:10:29 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 15 Jun 2013 08:10:29 -0400 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615081236.GU22824@leitl.org> Message-ID: Jimmy, This I agree with and in fact I said in earlier parts of this conversation that the existence of a kill switch and/or backdoor in Huawei gear wouldn't surprise me at all. Of course I'd say the same thing about pretty much all the gear manufacturers and its really just a question of who has or can get access to that information for a given manufacturer. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Sat, Jun 15, 2013 at 7:57 AM, Jimmy Hess wrote: > On 6/15/13, Scott Helms wrote: > > They're terrible places for gathering non-targeted information because > the > > amount of data flowing through them means that that the likelihood of any > > give packet having any value is very very low. If the goal includes > [snip] > > The probability of a low-likelihood or infrequent event approaches > 100%, given sufficient time, persistence, and creativity. Even if > 1% or less of packets passing through are interesting; that happens > to be more than enough to provide a snoop gains, and cause damage to > a legitimate user. > > The potential existence of 'better' options; doesn't mean backdooring > of routers wouldn't be included in part of a nation state or other bad > actor's backdooring program. > > -- > -JH > From rsk at gsp.org Sat Jun 15 12:13:50 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 15 Jun 2013 08:13:50 -0400 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> Message-ID: <20130615121350.GA29516@gsp.org> First: this is a fascinating discussion. Thank you. Second: On Sat, Jun 15, 2013 at 01:56:34AM -0500, Jimmy Hess wrote: > There will be indeed be _plenty_ of ways that a low bit rate channel > can do everything the right adversary needs. > > A few bits for second is plenty of data rate for sending control > commands/rule changes to a router backdoor mechanism, stealing > passwords, or leaking cryptographic keys required to decrypt the VPN > data stream intercepted from elsewhere on the network, leaking > counters, snmp communities, or interface descriptions, or > criteria-selected forwarded data samples, etc.... I was actually thinking much slower: a few bits per *day*. Maybe slower yet. (So what if it takes a month to transmit a single 15-character password?) For people who think in terms of instant gratification, or perhaps, in next-quarter terms, or perhaps, in next-year terms, that might be unacceptabe. But for people who think in terms of next-decade or beyond, it might suffice. And if the goal is not "get the password for router 12345" but "get as many as possible", then a scattered, random, slow approach might yield the best results -- *because* it's scattered, random, and slow. ---rsk From mike at mtcc.com Sat Jun 15 15:03:59 2013 From: mike at mtcc.com (Michael Thomas) Date: Sat, 15 Jun 2013 08:03:59 -0700 Subject: huawei In-Reply-To: <20130615121350.GA29516@gsp.org> References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615121350.GA29516@gsp.org> Message-ID: <51BC825F.4050803@mtcc.com> On 06/15/2013 05:13 AM, Rich Kulawiec wrote: > First: this is a fascinating discussion. Thank you. > > Second: > > On Sat, Jun 15, 2013 at 01:56:34AM -0500, Jimmy Hess wrote: >> There will be indeed be _plenty_ of ways that a low bit rate channel >> can do everything the right adversary needs. >> >> A few bits for second is plenty of data rate for sending control >> commands/rule changes to a router backdoor mechanism, stealing >> passwords, or leaking cryptographic keys required to decrypt the VPN >> data stream intercepted from elsewhere on the network, leaking >> counters, snmp communities, or interface descriptions, or >> criteria-selected forwarded data samples, etc.... > I was actually thinking much slower: a few bits per *day*. Maybe slower yet. > > (So what if it takes a month to transmit a single 15-character password?) > > For people who think in terms of instant gratification, or perhaps, > in next-quarter terms, or perhaps, in next-year terms, that might be > unacceptabe. But for people who think in terms of next-decade or > beyond, it might suffice. > > And if the goal is not "get the password for router 12345" but "get as > many as possible", then a scattered, random, slow approach might yield > the best results -- *because* it's scattered, random, and slow. > And all of us here by virtue of talking about it do not have a day job which involves thinking all of this stuff up. A lot of the stuff the DoD is willing to talk about is seriously brilliant, and that's just the public stuff. Information really, really wants to be free. Getting access to poorly defended routers is probably the easy part for them. Masking the payloads is something that they get paid the big bux for in general, so it is seriously naive to think they don't have dozens of tricks they employ on a daily basis. The only thing we really have to counter their ingenuity, IMO, are laws and other layer 8 impediments. Mike, still wonders if this phenomenon is just a restatement of entropy From randy at psg.com Sat Jun 15 15:35:45 2013 From: randy at psg.com (Randy Bush) Date: Sat, 15 Jun 2013 17:35:45 +0200 Subject: huawei In-Reply-To: <51BC825F.4050803@mtcc.com> References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615121350.GA29516@gsp.org> <51BC825F.4050803@mtcc.com> Message-ID: i wonder if and how many governments are worried about when the nsa tells cisco to send the kill switch signal to their routers. randy From joelja at bogus.com Sat Jun 15 15:56:19 2013 From: joelja at bogus.com (joel jaeggli) Date: Sat, 15 Jun 2013 17:56:19 +0200 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615121350.GA29516@gsp.org> <51BC825F.4050803@mtcc.com> Message-ID: <51BC8EA3.3010008@bogus.com> On 6/15/13 5:35 PM, Randy Bush wrote: > i wonder if and how many governments are worried about when the nsa > tells cisco to send the kill switch signal to their routers. Having worked for an Israel-based security vendor I'd opine: A. That many sovereign states are concerned about sourcing for reasons that seem to involve other state actors. B. That I am much happier not being in a position where I get paid to care about this. > randy > From cb.list6 at gmail.com Sat Jun 15 16:00:50 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sat, 15 Jun 2013 09:00:50 -0700 Subject: huawei In-Reply-To: References: <51BA6636.1010403@mtcc.com> <20130614124721.GB28378@gsp.org> <20130615121350.GA29516@gsp.org> <51BC825F.4050803@mtcc.com> Message-ID: On Sat, Jun 15, 2013 at 8:35 AM, Randy Bush wrote: > i wonder if and how many governments are worried about when the nsa > tells cisco to send the kill switch signal to their routers. > > randy > What kill switch ? http://www.cisco.com/en/US/products/csa/cisco-sa-20090325-udp.html http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120530-iosxr From jra at baylink.com Sat Jun 15 18:11:00 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 15 Jun 2013 14:11:00 -0400 (EDT) Subject: huawei In-Reply-To: Message-ID: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Is it possible? Yes, but it's not feasible because the data rate would be > too low. That's what I'm trying to get across. There are lots things that > can be done but many of those are not useful. > > I could encode communications in fireworks displays, but that's not > effective for any sort of communication system. At this point, of course, we hearken back to the Multics system, which needed -- in order to get the B1(?) common criteria security rating that it had -- to prevent Covert Channel communication between processes of different security levels *by means as low-bandwidth as sending morse code by modulating the system load*. So I don't think "there's too little bandwidth" is a good enough argument, Scott. But there's a much more important issue here: In some cases, like the Verizon Wireless 4G puck I mentioned earlier, manufactured by ZTE, *you can't see the back side of the device*. There's nearly no practical way for a subscriber to know what's coming out of the 4G side of that radio, so it could be doing anything it likes. Verizon Wireless proper could know, but they have no particular reason to look and, some might argue, lots of reasons not to want to know. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Jun 15 20:21:05 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 15 Jun 2013 16:21:05 -0400 (EDT) Subject: huawei In-Reply-To: Message-ID: <18573183.7965.1371327665538.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jazz Kenny" > What about through SDR? ie. http://nuand.com/ > > I mean, 'subscriber' seems to indicate a layman, but SDR isn't too complex > to get running for someone with a modicum of electronics experience - > especially in this day and age, where oscilloscopes and frequency analysis is available > to anyone with some Google-fu. Stipulated. Though the airlink encryption might give one pause as well. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Sat Jun 15 21:21:43 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 15 Jun 2013 14:21:43 -0700 Subject: Prism continued In-Reply-To: References: Message-ID: On Thu, Jun 13, 2013 at 7:20 AM, Jon Lewis wrote: > On Wed, 12 Jun 2013 goemon at anime.net wrote: > > cellphones with cameras are probably better for the purposes of covert >> mass surveillance, especially ones with front facing cameras. far more of >> them out there, and wireless to boot. >> >> suprised everyone gets their panties in a bunch over presumed games >> console monitoring, what about all your iphones already out there? >> > > My iPhone lives in a holster that covers both cameras when not in use or > charging. Do you throw a sheet over your gaming console when you're not > using it? > You'd be amazed at how many hours of footage the government has of the inside of my pants pockets... :D Matt From MGauvin at dryden.ca Sat Jun 15 21:28:34 2013 From: MGauvin at dryden.ca (Mark Gauvin) Date: Sat, 15 Jun 2013 16:28:34 -0500 Subject: Prism continued In-Reply-To: References: Message-ID: Only victim in all of this is the poor NSA contractor who had to sift thru my browser history Sent from my iPhone On 2013-06-15, at 4:24 PM, "Matthew Petach" wrote: > On Thu, Jun 13, 2013 at 7:20 AM, Jon Lewis wrote: > >> On Wed, 12 Jun 2013 goemon at anime.net wrote: >> >> cellphones with cameras are probably better for the purposes of covert >>> mass surveillance, especially ones with front facing cameras. far more of >>> them out there, and wireless to boot. >>> >>> suprised everyone gets their panties in a bunch over presumed games >>> console monitoring, what about all your iphones already out there? >> >> My iPhone lives in a holster that covers both cameras when not in use or >> charging. Do you throw a sheet over your gaming console when you're not >> using it? > > You'd be amazed at how many hours of footage > the government has of the inside of my pants > pockets... > > :D > > Matt From randy_94108 at yahoo.com Sat Jun 15 22:42:48 2013 From: randy_94108 at yahoo.com (Randy) Date: Sat, 15 Jun 2013 15:42:48 -0700 (PDT) Subject: Prism continued In-Reply-To: Message-ID: <1371336168.53969.YahooMailClassic@web184703.mail.ne1.yahoo.com> ...yes indeed given smella-vision ;-) ./Randy --- On Sat, 6/15/13, Mark Gauvin wrote: > From: Mark Gauvin > Subject: Re: Prism continued > To: "Matthew Petach" > Cc: "nanog at nanog.org" > Date: Saturday, June 15, 2013, 2:28 PM > Only victim in all of this is the > poor NSA contractor who had to sift thru my browser history > > Sent from my iPhone > > On 2013-06-15, at 4:24 PM, "Matthew Petach" > wrote: > > > On Thu, Jun 13, 2013 at 7:20 AM, Jon Lewis > wrote: > > > >> On Wed, 12 Jun 2013 goemon at anime.net > wrote: > >> > >> cellphones with cameras are probably better for the > purposes of covert > >>> mass surveillance, especially ones with front > facing cameras. far more of > >>> them out there, and wireless to boot. > >>> > >>> suprised everyone gets their panties in a bunch > over presumed games > >>> console monitoring, what about all your iphones > already out there? > >> > >> My iPhone lives in a holster that covers both > cameras when not in use or > >> charging.? Do you throw a sheet over your > gaming console when you're not > >> using it? > > > > You'd be amazed at how many hours of footage > > the government has of the inside of my pants > > pockets... > > > > :D > > > > Matt > > From trapperjohn117 at gmail.com Sat Jun 15 19:50:51 2013 From: trapperjohn117 at gmail.com (Jazz Kenny) Date: Sat, 15 Jun 2013 12:50:51 -0700 Subject: huawei In-Reply-To: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> References: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> Message-ID: What about through SDR? ie. http://nuand.com/ I mean, 'subscriber' seems to indicate a layman, but SDR isn't too complex to get running for someone with a modicum of electronics experience - especially in this day and age, where oscilloscopes and frequency analysis is available to anyone with some Google-fu. On Sat, Jun 15, 2013 at 11:11 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > Is it possible? Yes, but it's not feasible because the data rate would be > > too low. That's what I'm trying to get across. There are lots things that > > can be done but many of those are not useful. > > > > I could encode communications in fireworks displays, but that's not > > effective for any sort of communication system. > > At this point, of course, we hearken back to the Multics system, which > needed -- in order to get the B1(?) common criteria security rating that it > had -- to prevent Covert Channel communication between processes of > different > security levels *by means as low-bandwidth as sending morse code by > modulating the system load*. > > So I don't think "there's too little bandwidth" is a good enough argument, > Scott. > > But there's a much more important issue here: > > In some cases, like the Verizon Wireless 4G puck I mentioned earlier, > manufactured by ZTE, *you can't see the back side of the device*. There's > nearly no practical way for a subscriber to know what's coming out of the > 4G side of that radio, so it could be doing anything it likes. > > Verizon Wireless proper could know, but they have no particular reason to > look > and, some might argue, lots of reasons not to want to know. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From nanog at jima.us Sun Jun 16 05:52:19 2013 From: nanog at jima.us (Jima) Date: Sat, 15 Jun 2013 23:52:19 -0600 Subject: Spam to NANOG-specific email addresses? Message-ID: <51BD5293.9050606@jima.us> Esteemed colleagues, Did anyone else get a Twitter invite from @washsuntimes to their NANOG-use-only email addresses? Granted, mine was with my old one, but it was still very much specific to this list. Maybe not the best place to harvest addresses. Jima From philfagan at gmail.com Sun Jun 16 15:59:08 2013 From: philfagan at gmail.com (Phil Fagan) Date: Sun, 16 Jun 2013 09:59:08 -0600 Subject: Blocking TCP flows? In-Reply-To: References: <2901AB0C-77FC-405A-BA59-047D064E1CC3@arbor.net> Message-ID: Eric, I haven't read the full paper yet, however, are you simply acting as a proxy and redirecting based on the secret tag found in the header? What is your expectation for session/second use? I would think you would need to scale largely, however, I don't have a good understanding of how large the market is for users trying to obfuscate the states firewall/proxy/dns controls etc. ISP seems like a great place to live for that; what have they said so far? On Fri, Jun 14, 2013 at 12:30 PM, Eric Wustrow wrote: > Oddly enough, anticensorship. We use similar technology as the censors > (DPI, flow blocking), but use our system in a non-censoring country's ISP > to detect secret tags in connections from censored countries, and serve as > a proxy for them. Once we detect a flow with a secret tag passing through > the ISP, we block the real flow, and start spoofing half of the connection. > We use this covert channel to communicate to the client and act as a proxy. > To the censor, this looks like a normal connection to some innocuous, > unrelated (and unblocked) website. The obvious difficulty is convincing > ISPs to deploy such a proxy. More details can be found at > https://telex.cc/ > > > > On Fri, Jun 14, 2013 at 3:15 AM, Dobbins, Roland > wrote: > > > > > On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote: > > > > > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10 > > gbps link, with new blocked flows being dropped within a millisecond or > so > > of > > > being added. > > > > What's the actual application for this mechanism? > > > > ----------------------------------------------------------------------- > > Roland Dobbins // > > > > Luck is the residue of opportunity and design. > > > > -- John Milton > > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From philfagan at gmail.com Sun Jun 16 16:02:48 2013 From: philfagan at gmail.com (Phil Fagan) Date: Sun, 16 Jun 2013 10:02:48 -0600 Subject: huawei In-Reply-To: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> References: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> Message-ID: Jay, That's a very interesting point about the 4G puck....do you mean modulating data over side-lobes? To your point, I as a subscriber would have no way every knowing that unless of course I hooked up my specanny and started to try to decode the sidelobes....I imagine most folks don't do that ( if thats how one would even go about it ) On Sat, Jun 15, 2013 at 12:11 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > Is it possible? Yes, but it's not feasible because the data rate would be > > too low. That's what I'm trying to get across. There are lots things that > > can be done but many of those are not useful. > > > > I could encode communications in fireworks displays, but that's not > > effective for any sort of communication system. > > At this point, of course, we hearken back to the Multics system, which > needed -- in order to get the B1(?) common criteria security rating that it > had -- to prevent Covert Channel communication between processes of > different > security levels *by means as low-bandwidth as sending morse code by > modulating the system load*. > > So I don't think "there's too little bandwidth" is a good enough argument, > Scott. > > But there's a much more important issue here: > > In some cases, like the Verizon Wireless 4G puck I mentioned earlier, > manufactured by ZTE, *you can't see the back side of the device*. There's > nearly no practical way for a subscriber to know what's coming out of the > 4G side of that radio, so it could be doing anything it likes. > > Verizon Wireless proper could know, but they have no particular reason to > look > and, some might argue, lots of reasons not to want to know. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Phil Fagan Denver, CO 970-480-7618 From m4rtntns at gmail.com Sun Jun 16 19:19:29 2013 From: m4rtntns at gmail.com (Martin T) Date: Sun, 16 Jun 2013 22:19:29 +0300 Subject: How ISP's in ARIN region create automatic prefix-filters? In-Reply-To: <51BE46A4-0D29-4BBB-B573-C9F307ADAB2B@hopcount.ca> References: <51BE46A4-0D29-4BBB-B573-C9F307ADAB2B@hopcount.ca> Message-ID: Joe, ok, so in ARIN region there are two separate databases- "ARIN?s Registration database" and "ARIN?s Routing Registry database". If there is a database containing routing policy information in ARIN region as well, then why do you suggest to use RIPE database? I mean shouldn't most ISP's in RIPE region use radb or their own whois database which mirrors all major IRR databases and thus rr.arin.net among the others? regards, Martin 2013/6/12 Joe Abley > > On 2013-06-12, at 13:38, Martin T wrote: > > > as I understand, ARIN whois database does not contain "route" objects, > > which are used for example in RIPE region for automatic BGP prefix > > filter generation. > > whois.arin.net:43 is for assignment/allocation information. Does not use > RPSL. > > rr.arin.net:43 is a routing registry that uses RPSL. > > > How does this work in ARIN region? I know that at > > least some ISP's operating in ARIN region use their own whois > > databases(for example rr.level3.net) which mirror content from other > > RIR databases, but are there other methods how they update their > > internal databases with records? > > My general advice for anybody who cares to listen is to use the RIPE db > for your objects if you are based in the ARIN region. It saves time if/when > you come to peer with an organisation based in the RIPE region, and it > makes your objects easy to find for anybody who wants to look for them. > > You can install a route in the RIPE db corresponding to number resources > assigned elsewhere by authenticating against the RIPE-NCC-RPSL-MNT > maintainer object, for which the plain-text password is "RPSL". Since your > new route object will specify mnt-by MAINT-YOURS you will also need to > authenticate against that (my favourite method is PGP). > > > Joe > > mntner: RIPE-NCC-RPSL-MNT > descr: This maintainer may be used to create objects to represent > descr: routing policy in the RIPE Database for number resources > not > descr: allocated or assigned from the RIPE NCC. > admin-c: RD132-RIPE > auth: MD5-PW # Filtered > remarks: ******************************************************* > remarks: * The password for this object is 'RPSL', without the * > remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * > remarks: ******************************************************* > mnt-by: RIPE-DBM-MNT > referral-by: RIPE-DBM-MNT > source: RIPE # Filtered From jra at baylink.com Sun Jun 16 19:44:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 16 Jun 2013 15:44:41 -0400 (EDT) Subject: huawei In-Reply-To: Message-ID: <6863081.7999.1371411881688.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Phil Fagan" > That's a very interesting point about the 4G puck....do you mean > modulating > data over side-lobes? To your point, I as a subscriber would have no > way > every knowing that unless of course I hooked up my specanny and > started to > try to decode the sidelobes....I imagine most folks don't do that ( if > thats how one would even go about it ) Not at all. The *standard air-data link* coming out the back of the puck, in "4G" (protip: it's not) LTE, *is not something that the user can see*, without great effort. So, that commercial end-user customer of Verizon has no way to see what extra data *the puck itself* might be phoning home with. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From trapperjohn117 at gmail.com Sun Jun 16 20:05:46 2013 From: trapperjohn117 at gmail.com (Jazz Kenny) Date: Sun, 16 Jun 2013 13:05:46 -0700 Subject: huawei In-Reply-To: References: <6863081.7999.1371411881688.JavaMail.root@benjamin.baylink.com> Message-ID: Why is it so difficult? Hiding communications is an intriguing subject - My ears perked up a bit at the Multics remark - Morse is something that probably never would have even crossed my mind. EDIT: Okay, now it's sent to the list. DOHF! On Sun, Jun 16, 2013 at 1:03 PM, Jazz Kenny wrote: > Why is it so difficult? Hiding communications is an intriguing subject - > My ears perked up a bit at the Multics remark - Morse is something that > probably never would have even crossed my mind. > > > On Sun, Jun 16, 2013 at 12:44 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >> > From: "Phil Fagan" >> >> > That's a very interesting point about the 4G puck....do you mean >> > modulating >> > data over side-lobes? To your point, I as a subscriber would have no >> > way >> > every knowing that unless of course I hooked up my specanny and >> > started to >> > try to decode the sidelobes....I imagine most folks don't do that ( if >> > thats how one would even go about it ) >> >> Not at all. >> >> The *standard air-data link* coming out the back of the puck, in "4G" >> (protip: >> it's not) LTE, *is not something that the user can see*, without great >> effort. >> >> So, that commercial end-user customer of Verizon has no way to see what >> extra data *the puck itself* might be phoning home with. >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 >> 647 1274 >> >> > From chris.burri at hotmail.ch Sun Jun 16 23:34:09 2013 From: chris.burri at hotmail.ch (chris burri) Date: Mon, 17 Jun 2013 01:34:09 +0200 Subject: huawei In-Reply-To: References: , <6863081.7999.1371411881688.JavaMail.root@benjamin.baylink.com>, , Message-ID: Concerning covert communications, I have a short story to tell: Several years ago, I used to play World of Warcraft. The Game allows for LUA scripting, and the developers added some limitations as to prevent bot scripting. One of the limitations was that you could not export data from or import into the game (file load and save LUA functions were present, but have been disabled by Blizzard). To circumvent this limitation (I have some history of doing things deemed "impossible" by others...), I did two things: First, I wrote a LUA script that placed a field of 1024 dots on the screen. The script accepted a string of up to 128 chars and encoded it in binary. It would then set the dots on the screen according to the bits, white for 1 and black for 0. Finally, it would trigger a screenshot. The second part of the exercise was a small VB.NET program that watched the screenshot folder for new files. If a new screenshot was detected, it loaded the file and tried to find the dot-field within the new screenshot. If found, it would decode the binary - et voila: Data exported from the Game into an external program. Greetings Chris --- -= Amat Victoria Curam =- > Date: Sun, 16 Jun 2013 13:05:46 -0700 > Subject: Re: huawei > From: trapperjohn117 at gmail.com > To: nanog at nanog.org > > Why is it so difficult? Hiding communications is an intriguing subject - My > ears perked up a bit at the Multics remark - Morse is something that > probably never would have even crossed my mind. From wbailey at satelliteintelligencegroup.com Sun Jun 16 23:40:02 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 16 Jun 2013 23:40:02 +0000 Subject: huawei In-Reply-To: <6863081.7999.1371411881688.JavaMail.root@benjamin.baylink.com> References: , <6863081.7999.1371411881688.JavaMail.root@benjamin.baylink.com> Message-ID: If it was that easy why did the feds come up with that bts spoofed? Sent from my Mobile Device. -------- Original message -------- From: Jay Ashworth Date: 06/16/2013 12:46 PM (GMT-08:00) To: NANOG Subject: Re: huawei ----- Original Message ----- > From: "Phil Fagan" > That's a very interesting point about the 4G puck....do you mean > modulating > data over side-lobes? To your point, I as a subscriber would have no > way > every knowing that unless of course I hooked up my specanny and > started to > try to decode the sidelobes....I imagine most folks don't do that ( if > thats how one would even go about it ) Not at all. The *standard air-data link* coming out the back of the puck, in "4G" (protip: it's not) LTE, *is not something that the user can see*, without great effort. So, that commercial end-user customer of Verizon has no way to see what extra data *the puck itself* might be phoning home with. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From philfagan at gmail.com Mon Jun 17 00:27:32 2013 From: philfagan at gmail.com (Phil Fagan) Date: Sun, 16 Jun 2013 18:27:32 -0600 Subject: huawei In-Reply-To: References: <6863081.7999.1371411881688.JavaMail.root@benjamin.baylink.com> Message-ID: was this posted using HTTP? On Sun, Jun 16, 2013 at 5:34 PM, chris burri wrote: > Concerning covert communications, I have a short story to tell: > > Several years ago, I used to play World of Warcraft. The Game allows for > LUA scripting, and the developers added some limitations as to prevent bot > scripting. One of the limitations was that you could not export data from > or import into the game (file load and save LUA functions were present, but > have been disabled by Blizzard). > > To circumvent this limitation (I have some history of doing things deemed > "impossible" by others...), I did two things: > > First, I wrote a LUA script that placed a field of 1024 dots on the > screen. The script accepted a string of up to 128 chars and encoded it in > binary. It would then set the dots on the screen according to the bits, > white for 1 and black for 0. Finally, it would trigger a screenshot. > > The second part of the exercise was a small VB.NET program that watched > the screenshot folder for new files. If a new screenshot was detected, it > loaded the file and tried to find the dot-field within the new screenshot. > If found, it would decode the binary - et voila: Data exported from the > Game into an external program. > > Greetings > Chris > > > --- > > -= Amat Victoria Curam =- > > > > Date: Sun, 16 Jun 2013 13:05:46 -0700 > > Subject: Re: huawei > > From: trapperjohn117 at gmail.com > > To: nanog at nanog.org > > > > Why is it so difficult? Hiding communications is an intriguing subject - > My > > ears perked up a bit at the Multics remark - Morse is something that > > probably never would have even crossed my mind. > > -- Phil Fagan Denver, CO 970-480-7618 From michael at winkstreaming.com Mon Jun 17 00:40:13 2013 From: michael at winkstreaming.com (Michael McConnell) Date: Sun, 16 Jun 2013 18:40:13 -0600 Subject: Multihop eBGP peering or VPN based eBGP peering Message-ID: Hello all, Any idea why more companies don't offer eBGP peering / multi hop peering? Its very common for providers to offer single or double hop peering, so why not 5 or 10 hops? In many cases people find it logical to perform single or double hop peering, why is peering any greater always frowned upon. I understand the logic that you can't control the path beyond a point, however I still see numerous advantages. One obvious advantages one is, imagine you east coast data centre and you had a eBGP peering session with a west coast router, you'd be able to control ingress via the west coast. (aka routing around an region outage that is effecting ingress) For example during the last hurricane around New Jersey, numerous tier 1's were down towards the atlantic and every peer for the atlantic was effected. One could have just made the ingress via the west coast the logical route. Thoughts? Mike -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com From jvanoppen at spectrumnet.us Mon Jun 17 04:30:11 2013 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 17 Jun 2013 04:30:11 +0000 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: References: Message-ID: Perhaps I am missing something from your advantage list, but why would you want to exchange routing information with a network to which you don't have a connection due to a local failure? I think you are attempting to abstract routing from the underlying physical infrastructure a bit too much. If the power is out in the carrier pop to which you are connected, they don't have a way to give you traffic so why would a multi-hop session help. BGP being down is rarely something that happens on its own, it is typically due to something far more physical (router failure, pop outage, circuit outage, etc). John -----Original Message----- From: Michael McConnell [mailto:michael at winkstreaming.com] Sent: Sunday, June 16, 2013 5:40 PM To: nanog at nanog.org Subject: Multihop eBGP peering or VPN based eBGP peering Hello all, Any idea why more companies don't offer eBGP peering / multi hop peering? Its very common for providers to offer single or double hop peering, so why not 5 or 10 hops? In many cases people find it logical to perform single or double hop peering, why is peering any greater always frowned upon. I understand the logic that you can't control the path beyond a point, however I still see numerous advantages. One obvious advantages one is, imagine you east coast data centre and you had a eBGP peering session with a west coast router, you'd be able to control ingress via the west coast. (aka routing around an region outage that is effecting ingress) For example during the last hurricane around New Jersey, numerous tier 1's were down towards the atlantic and every peer for the atlantic was effected. One could have just made the ingress via the west coast the logical route. Thoughts? Mike -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com From otis at ocosa.com Mon Jun 17 04:36:46 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Sun, 16 Jun 2013 23:36:46 -0500 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: References: Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0186F4@ocsbs.ocosa.com> -----Original Message----- From: Michael McConnell [mailto:michael at winkstreaming.com] Sent: Sunday, June 16, 2013 7:40 PM To: nanog at nanog.org Subject: Multihop eBGP peering or VPN based eBGP peering >Any idea why more companies don't offer eBGP peering / multi hop peering? Its very common for providers to offer single or double hop peering, so why not 5 or 10 hops? In many cases people find it logical to perform single or double hop peering, why is >peering any greater always frowned upon. I understand the logic that you can't control the path beyond a point, however I still see numerous advantages. The norm has always been if you are peering with someone you have router in the location you are peering. Thus, direct connection!!! But I've seen folks do what you are describing but in terms of their own networks thru use of GRE Tunnels. The main point of peering is having better connectivity and dropping traffic directly or closest to its destination. >One obvious advantages one is, imagine you east coast data centre and you had a eBGP peering session with a west coast router, you'd be able to control ingress via the west coast. (aka routing around an region outage that is effecting ingress) For >example during the last hurricane around New Jersey, numerous tier 1's were down towards the atlantic and every peer for the atlantic was effected. One could have just made the ingress via the west coast the logical route. I do see this advantage being an obvious workable logical one. However, large providers typically have their own network (layers 1-3) coast to coast if were talking USA. But in the case of the hurricane situation many were without power so you can have a router west coast and announce from that router but how will you get traffic back to east coast if that's your data center? You see you can have routers all over but if your data center (CDN) is without power you are done. Otis From patrick at ianai.net Mon Jun 17 06:36:42 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 17 Jun 2013 02:36:42 -0400 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B0186F4@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B0186F4@ocsbs.ocosa.com> Message-ID: <052541AB-C89B-4BFA-A3A3-F6B8EF7A80FF@ianai.net> On Jun 17, 2013, at 00:36 , "Otis L. Surratt, Jr." wrote: >> Any idea why more companies don't offer eBGP peering / multi hop >> peering? Its very common for providers to offer single or double hop >> peering, so why not 5 or 10 hops? In many cases people find it logical >> to perform single or double hop peering, why is >peering any greater >> always frowned upon. I understand the logic that you can't control the >> path beyond a point, however I still see numerous advantages. > > The norm has always been if you are peering with someone you have router > in the location you are peering. Thus, direct connection!!! > But I've seen folks do what you are describing but in terms of their own > networks thru use of GRE Tunnels. The main point of peering is having > better connectivity and dropping traffic directly or closest to its > destination. First, inside your own network is not eBGP. iBGP has no hop limitation (well, 255). If you have you seen someone do eBGP "inside their own network", they were actually doing it between two separate networks they owned. If you saw someone do eBGP over a GRE tunnel, that is a direct connection, not multi-hop. [Cue discussion from last week about multiple islands in the same ASN.] >> One obvious advantages one is, imagine you east coast data centre and >> you had a eBGP peering session with a west coast router, you'd be able >> to control ingress via the west coast. (aka routing around an region >> outage that is effecting ingress) For >example during the last hurricane >> around New Jersey, numerous tier 1's were down towards the atlantic and >> every peer for the atlantic was effected. One could have just made the >> ingress via the west coast the logical route. > > I do see this advantage being an obvious workable logical one. However, > large providers typically have their own network (layers 1-3) coast to > coast if were talking USA. But in the case of the hurricane situation > many were without power so you can have a router west coast and announce > from that router but how will you get traffic back to east coast if > that's your data center? > > You see you can have routers all over but if your data center (CDN) is > without power you are done. I do not see an advantage here. You are on the east coast and you want to re-direct traffic to the west coast, so you announce a prefix to a west coast router and ask it to propagate that prefix to its peers. How do you guarantee that router has a route back to the east coast for that prefix? Remember, a prefix announcement is a promise to deliver traffic to that prefix. You are suggesting asking a router to make a promise when that router has no guarantee of reachability. In your hurricane example, perhaps the west coast router reaches that prefix through one of the down east coast routers? Now you have blackholed that prefix when a router in, say, Chicago or Dallas would have announced it properly and had reachability. If you want to control where a prefix ingresses another network, first you need a transit relationship with that network. Most modern transit networks have community-based signaling, allowing you to do what you suggest and more (e.g. "prepend to peer $X" or "do not announce to peer $Y"). -- TTFN, patrick From randy at psg.com Mon Jun 17 05:27:11 2013 From: randy at psg.com (Randy Bush) Date: Mon, 17 Jun 2013 07:27:11 +0200 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: References: Message-ID: > Perhaps I am missing something from your advantage list, but why would > you want to exchange routing information with a network to which you > don't have a connection due to a local failure? I think you are > attempting to abstract routing from the underlying physical > infrastructure a bit too much. If the power is out in the carrier pop > to which you are connected, they don't have a way to give you traffic > so why would a multi-hop session help. > > BGP being down is rarely something that happens on its own, it is > typically due to something far more physical (router failure, pop > outage, circuit outage, etc). any time routing signaling comes from a source to which you can not directly deliver payload you will be in a load of grief when something goes wrong. abjure route servers. route reflectors should be in the data plane, ... in general, when layer N is not congruent with layer N-1 (and N+1), you have a recipe for exciting times. and well run ops is not supposed to be exciting. randy From otis at ocosa.com Mon Jun 17 13:25:45 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Mon, 17 Jun 2013 08:25:45 -0500 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: <052541AB-C89B-4BFA-A3A3-F6B8EF7A80FF@ianai.net> References: <5FE1FB6D43B8A647BBC821840C1AEA8B0186F4@ocsbs.ocosa.com> <052541AB-C89B-4BFA-A3A3-F6B8EF7A80FF@ianai.net> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0186F6@ocsbs.ocosa.com> -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Monday, June 17, 2013 1:37 AM To: NANOG list Subject: Re: Multihop eBGP peering or VPN based eBGP peering On Jun 17, 2013, at 00:36 , "Otis L. Surratt, Jr." wrote: >First, inside your own network is not eBGP. iBGP has no hop limitation (well, 255). If you have you seen someone do eBGP "inside their own network", they were actually doing it between two separate networks they owned. >If you saw someone do eBGP over a GRE tunnel, that is a direct connection, not multi-hop. [Cue discussion from last week about multiple islands in the same ASN.] I know eBGP is not iBGP. And yes, it was two separate ASNs. The point was in my experience, providers will prefer direction connection (you can physically plug into switch port or router port) to establish an eBGP session with you versus a GRE Tunnel. And some do not allow it. >I do not see an advantage here. >You are on the east coast and you want to re-direct traffic to the west coast, so you announce a prefix to a west coast router and ask it to propagate that prefix to its peers. How do you guarantee that router has a route back to the east coast for that >prefix? >Remember, a prefix announcement is a promise to deliver traffic to that prefix. You are suggesting asking a router to make a promise when that router has no guarantee of reachability. In your hurricane example, perhaps the west coast router reaches >that prefix through one of the down east coast routers? Now you have blackholed that prefix when a router in, say, Chicago or Dallas would have announced it properly and had reachability. >If you want to control where a prefix ingresses another network, first you need a transit relationship with that network. Most modern transit networks have community-based signaling, allowing you to do what you suggest and more (e.g. "prepend to peer >$X" or "do not announce to peer $Y"). " You see you can have routers all over but if your data center (CDN) is without power you are done." Patrick, I was saying "done" in terms of being over, no more, not happening. :) But that was if you had all of the necessary network measures accounted for and content served via the east coast data center only. But I did forget to clarify (not CDN, or single served content). I was assuming the OP had the proper relationships network wise (transit/private/public peering) so it would work when you put it all together properly. I also, took into account the OP is a CDN so they probably have content distributed at a minimum in separate regions anyway so it wouldn't matter if the east coast DC is offline as the content is still reachable via the west coast data center which would null and void the OPs example. Like I explained, I was thinking the OP had the proper relationships to re-direct traffic to the west coast at that point that's why I said "I do see this advantage being an obvious workable logical one." I didn't say it was perfect but workable (work was still needed to complete it). From cra at WPI.EDU Mon Jun 17 19:36:15 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 17 Jun 2013 15:36:15 -0400 Subject: recommended outdoor enclosures Message-ID: <20130617193615.GI1245@angus.ind.WPI.EDU> I'm in need of my first free-standing, pad-mounted outdoor enclosure, 19" rack rails, 12-18 rack units, with about 400W of heat load inside, for use in the Massachusetts climate. What do people recommend as far as contruction, cooling/heating options, NEMA ratings, security options, etc. for this use? I was hoping to keep the inside temperature between 50 and 85 degrees Fahrenheit, although my worst-case components are rated for 41 to 104 F (4 - 40 C). If a full mechanical A/C system can be avoided, even better. A thermo-electric cooler would be nice. Thanks. From dave at temk.in Mon Jun 17 19:33:37 2013 From: dave at temk.in (David Temkin) Date: Mon, 17 Jun 2013 15:33:37 -0400 Subject: NANOG 59 - Important Schedule Notice & Call For Presentations. Please read! Message-ID: NANOG Community, I hope everyone enjoyed New Orleans as much as I did! It's truly one of my favorite cities in the world. Fresh off a great meeting, we're already starting to get ready for NANOG 59 in Phoenix. If you have a topic you'd like to speak about, the program committee would love to consider it. Please watch http://www.nanog.org/meetings/nanog59/callforpresentations for more information. After considering feedback from members, speakers, ARIN, and sponsors we have decided to make a small tweak to the program timing at NANOG 59. We will continue with the Monday-Wednesday format, however we will move the ARIN Track and Tutorials to Tuesday morning, highlighting their importance to the program. The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch. The exact schedule layout can be found at http://www.nanog.org/meetings/nanog59/preagenda and is also attached in JPG format to this email. If you wish to submit a presentation, please keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 16-Aug-2013 Slides Due: 30-Aug-2013 Topic List Posted: 06-Sep-2013 Final Agenda Published: 27-Sep-2013 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Phoenix! -Dave Temkin (Chair, NANOG Program Committee) -------------- next part -------------- A non-text attachment was scrubbed... Name: MTW-DTv2.1.jpg Type: image/jpeg Size: 163590 bytes Desc: not available URL: From alex at pssclabs.com Mon Jun 17 19:42:31 2013 From: alex at pssclabs.com (Alex Lesser) Date: Mon, 17 Jun 2013 15:42:31 -0400 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: <51BF66A7.4030905@pssclabs.com> I came across this once. Seems interesting but we have never used it ourselves. 400 Watts is not much so I believe this unit may even be overkill. http://www.ellipticalmedia.com/raserhd.html On 6/17/2013 3:36 PM, Chuck Anderson wrote: > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > for use in the Massachusetts climate. What do people recommend as far > as contruction, cooling/heating options, NEMA ratings, security > options, etc. for this use? > > I was hoping to keep the inside temperature between 50 and 85 degrees > Fahrenheit, although my worst-case components are rated for 41 to 104 > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > better. A thermo-electric cooler would be nice. > > Thanks. > > > From lathama at gmail.com Mon Jun 17 19:44:15 2013 From: lathama at gmail.com (Andrew Latham) Date: Mon, 17 Jun 2013 15:44:15 -0400 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: On Mon, Jun 17, 2013 at 3:36 PM, Chuck Anderson wrote: > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > for use in the Massachusetts climate. What do people recommend as far > as contruction, cooling/heating options, NEMA ratings, security > options, etc. for this use? > > I was hoping to keep the inside temperature between 50 and 85 degrees > Fahrenheit, although my worst-case components are rated for 41 to 104 > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > better. A thermo-electric cooler would be nice. > > Thanks. Stab in the dark but are you looking for something like this[1] or larger? 1. http://www.hoffmanonline.com/product_catalog/product_detail.aspx?cat_1=34&cat_2=2346&cat_3=302499&catid=302499&itemid=302509&view=overview -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From joshbaird at gmail.com Mon Jun 17 19:44:56 2013 From: joshbaird at gmail.com (Josh Baird) Date: Mon, 17 Jun 2013 15:44:56 -0400 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: http://www.ddbunlimited.com/ Be prepared to drop some coin. Josh On Mon, Jun 17, 2013 at 3:36 PM, Chuck Anderson wrote: > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > for use in the Massachusetts climate. What do people recommend as far > as contruction, cooling/heating options, NEMA ratings, security > options, etc. for this use? > > I was hoping to keep the inside temperature between 50 and 85 degrees > Fahrenheit, although my worst-case components are rated for 41 to 104 > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > better. A thermo-electric cooler would be nice. > > Thanks. > > From jackson.tim at gmail.com Mon Jun 17 19:49:29 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 17 Jun 2013 12:49:29 -0700 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: Alpha's Radium Minibays should be a good start of what to look at and seems to fit your requirements: http://www.alpha.ca/web2/products/enclosures/outdoor-enclosures-medium/item/radium-minibay-series On Mon, Jun 17, 2013 at 12:36 PM, Chuck Anderson wrote: > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > for use in the Massachusetts climate. What do people recommend as far > as contruction, cooling/heating options, NEMA ratings, security > options, etc. for this use? > > I was hoping to keep the inside temperature between 50 and 85 degrees > Fahrenheit, although my worst-case components are rated for 41 to 104 > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > better. A thermo-electric cooler would be nice. > > Thanks. > From cabenth at gmail.com Mon Jun 17 19:51:28 2013 From: cabenth at gmail.com (eric clark) Date: Mon, 17 Jun 2013 12:51:28 -0700 Subject: 10gig coast to coast Message-ID: Greetings I may be needing 10 gig from the West Coast to the East Coast some time in the next year. I've got my ideas on what that would cost, but I don't have anything that big. This could be a leased line, part of a cloud with Verizon, NTT, Sprint, or whoever as the provider, etc. I'm just looking to see what a budget cost for something like this is, and who can provide such service. Your help is greatly appreciated, feel free to respond directly or to the thread. E From mike.lyon at gmail.com Mon Jun 17 19:53:32 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 17 Jun 2013 12:53:32 -0700 Subject: recommended outdoor enclosures In-Reply-To: <51BF66A7.4030905@pssclabs.com> References: <20130617193615.GI1245@angus.ind.WPI.EDU> <51BF66A7.4030905@pssclabs.com> Message-ID: <-5570916671464437901@unknownmsgid> http://www.ddbunlimited.com/ -mike Sent from my iPhone On Jun 17, 2013, at 12:49, Alex Lesser wrote: I came across this once. Seems interesting but we have never used it ourselves. 400 Watts is not much so I believe this unit may even be overkill. http://www.ellipticalmedia.com/raserhd.html On 6/17/2013 3:36 PM, Chuck Anderson wrote: I'm in need of my first free-standing, pad-mounted outdoor enclosure, 19" rack rails, 12-18 rack units, with about 400W of heat load inside, for use in the Massachusetts climate. What do people recommend as far as contruction, cooling/heating options, NEMA ratings, security options, etc. for this use? I was hoping to keep the inside temperature between 50 and 85 degrees Fahrenheit, although my worst-case components are rated for 41 to 104 F (4 - 40 C). If a full mechanical A/C system can be avoided, even better. A thermo-electric cooler would be nice. Thanks. From Valdis.Kletnieks at vt.edu Mon Jun 17 20:10:10 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 17 Jun 2013 16:10:10 -0400 Subject: 10gig coast to coast In-Reply-To: Your message of "Mon, 17 Jun 2013 12:51:28 -0700." References: Message-ID: <29050.1371499810@turing-police.cc.vt.edu> On Mon, 17 Jun 2013 12:51:28 -0700, eric clark said: > I may be needing 10 gig from the West Coast to the East Coast Might want to be more specific. Catalina Island, CA to Buxton, NC (home of Cape Hatteras High School) will probably be way different than downtown LA to downtown Boston. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From fohdeesha at gmail.com Mon Jun 17 20:19:07 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Mon, 17 Jun 2013 16:19:07 -0400 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: <51BF6F3B.4020508@gmail.com> This is by far a "cheaper" option, but should work just fine. I'm about to do the same myself. Grab a used cab here - http://www.usedtowers.com/CABINETS/CABINETS.htm Some of those come with the factory huge AC systems built for thousands of watts of equipment inside, but if you're like me and will have 300-400 watts max, grab a non-cooled cabinet for cheap. Then pick up one of these guys and slap it on, buy the capacity you need. You can get them with a heating option as well, they're thermoelectric and very affordable- http://www.eicsolutions.com/thermoelectric-air-conditioners.php -- Jon Sands Fohdeesha Media http://fohdeesha.com/ From joe at nethead.com Mon Jun 17 20:19:14 2013 From: joe at nethead.com (Joe Hamelin) Date: Mon, 17 Jun 2013 13:19:14 -0700 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: Clearwire uses these and they are very nice. www.*ddb*unlimited.com -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Mon, Jun 17, 2013 at 12:36 PM, Chuck Anderson wrote: > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > for use in the Massachusetts climate. What do people recommend as far > as contruction, cooling/heating options, NEMA ratings, security > options, etc. for this use? > > I was hoping to keep the inside temperature between 50 and 85 degrees > Fahrenheit, although my worst-case components are rated for 41 to 104 > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > better. A thermo-electric cooler would be nice. > > Thanks. > > From davidpeahi at gmail.com Mon Jun 17 20:22:26 2013 From: davidpeahi at gmail.com (david peahi) Date: Mon, 17 Jun 2013 13:22:26 -0700 Subject: recommended outdoor enclosures In-Reply-To: <20130617193615.GI1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: I have had success with the opposite approach using equipment rated from -40 C to +85 C (+185 F), no fans, sealed NEMA4 or NEMA12 Hoffman enclosures, cooling by equipment heat sinks. Ethernet switches and optics rated -40 C to +85 C This configuration has worked with the same equipment for at least 6 years in an environment where summer ambient temperatures reach 120-130 F, and winter ambient 0 F. Hoffman makes a 72" high NEMA12 enclosure with a swing-out 19" telco rack. On Mon, Jun 17, 2013 at 12:36 PM, Chuck Anderson wrote: > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > for use in the Massachusetts climate. What do people recommend as far > as contruction, cooling/heating options, NEMA ratings, security > options, etc. for this use? > > I was hoping to keep the inside temperature between 50 and 85 degrees > Fahrenheit, although my worst-case components are rated for 41 to 104 > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > better. A thermo-electric cooler would be nice. > > Thanks. > > From cra at WPI.EDU Mon Jun 17 20:28:15 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 17 Jun 2013 16:28:15 -0400 Subject: recommended outdoor enclosures In-Reply-To: <51BF6F3B.4020508@gmail.com> References: <20130617193615.GI1245@angus.ind.WPI.EDU> <51BF6F3B.4020508@gmail.com> Message-ID: <20130617202814.GJ1245@angus.ind.WPI.EDU> On Mon, Jun 17, 2013 at 04:19:07PM -0400, Jon Sands wrote: > This is by far a "cheaper" option, but should work just fine. I'm > about to do the same myself. > > Grab a used cab here - http://www.usedtowers.com/CABINETS/CABINETS.htm > > Some of those come with the factory huge AC systems built for > thousands of watts of equipment inside, but if you're like me and > will have 300-400 watts max, grab a non-cooled cabinet for cheap. > > Then pick up one of these guys and slap it on, buy the capacity you > need. You can get them with a heating option as well, they're > thermoelectric and very affordable- > http://www.eicsolutions.com/thermoelectric-air-conditioners.php "very affordable"? I looked at those and they cost more than twice the cost of the cabinet itself. But I might end up going with them anyway, 1500 BTU would cover the 400 watts I generate inside the cabinet, but I'm more concerned about the outdoor environment/solar heating effects. How many BTU should I add to account for that? From fohdeesha at gmail.com Mon Jun 17 20:33:19 2013 From: fohdeesha at gmail.com (Jon Sands) Date: Mon, 17 Jun 2013 16:33:19 -0400 Subject: recommended outdoor enclosures In-Reply-To: <20130617202814.GJ1245@angus.ind.WPI.EDU> References: <20130617193615.GI1245@angus.ind.WPI.EDU> <51BF6F3B.4020508@gmail.com> <20130617202814.GJ1245@angus.ind.WPI.EDU> Message-ID: <51BF728F.50208@gmail.com> Woah, the last quote I got from them was less than half the price of a cab. I guess I'm cooling less equipment? What model are you looking at? On 6/17/2013 4:28 PM, Chuck Anderson wrote: > On Mon, Jun 17, 2013 at 04:19:07PM -0400, Jon Sands wrote: >> This is by far a "cheaper" option, but should work just fine. I'm >> about to do the same myself. >> >> Grab a used cab here - http://www.usedtowers.com/CABINETS/CABINETS.htm >> >> Some of those come with the factory huge AC systems built for >> thousands of watts of equipment inside, but if you're like me and >> will have 300-400 watts max, grab a non-cooled cabinet for cheap. >> >> Then pick up one of these guys and slap it on, buy the capacity you >> need. You can get them with a heating option as well, they're >> thermoelectric and very affordable- >> http://www.eicsolutions.com/thermoelectric-air-conditioners.php > "very affordable"? I looked at those and they cost more than twice > the cost of the cabinet itself. But I might end up going with them > anyway, 1500 BTU would cover the 400 watts I generate inside the > cabinet, but I'm more concerned about the outdoor environment/solar > heating effects. How many BTU should I add to account for that? -- Jon Sands Fohdeesha Media http://fohdeesha.com/ From cra at WPI.EDU Mon Jun 17 20:34:02 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 17 Jun 2013 16:34:02 -0400 Subject: recommended outdoor enclosures In-Reply-To: References: <20130617193615.GI1245@angus.ind.WPI.EDU> Message-ID: <20130617203401.GK1245@angus.ind.WPI.EDU> Unfortunately, I have some specific non-commodity circuit boards I'm dealing with, so I have to accommodate their environmental requirements. On Mon, Jun 17, 2013 at 01:22:26PM -0700, david peahi wrote: > I have had success with the opposite approach using equipment rated from > -40 C to +85 C (+185 F), no fans, sealed NEMA4 or NEMA12 Hoffman > enclosures, cooling by equipment heat sinks. Ethernet switches and optics > rated -40 C to +85 C > This configuration has worked with the same equipment for at least 6 years > in an environment where summer ambient temperatures reach 120-130 F, and > winter ambient 0 F. Hoffman makes a 72" high NEMA12 enclosure with a > swing-out 19" telco rack. > > > On Mon, Jun 17, 2013 at 12:36 PM, Chuck Anderson wrote: > > > I'm in need of my first free-standing, pad-mounted outdoor enclosure, > > 19" rack rails, 12-18 rack units, with about 400W of heat load inside, > > for use in the Massachusetts climate. What do people recommend as far > > as contruction, cooling/heating options, NEMA ratings, security > > options, etc. for this use? > > > > I was hoping to keep the inside temperature between 50 and 85 degrees > > Fahrenheit, although my worst-case components are rated for 41 to 104 > > F (4 - 40 C). If a full mechanical A/C system can be avoided, even > > better. A thermo-electric cooler would be nice. > > > > Thanks. From cabenth at gmail.com Mon Jun 17 22:22:17 2013 From: cabenth at gmail.com (eric clark) Date: Mon, 17 Jun 2013 15:22:17 -0700 Subject: 10gig coast to coast In-Reply-To: <29050.1371499810@turing-police.cc.vt.edu> References: <29050.1371499810@turing-police.cc.vt.edu> Message-ID: Fair enough Seattle to Boston is the general route, real close. On Monday, June 17, 2013, wrote: > On Mon, 17 Jun 2013 12:51:28 -0700, eric clark said: > > > I may be needing 10 gig from the West Coast to the East Coast > > Might want to be more specific. Catalina Island, CA to Buxton, NC > (home of Cape Hatteras High School) will probably be way different > than downtown LA to downtown Boston. > From carlos at race.com Tue Jun 18 01:48:27 2013 From: carlos at race.com (Carlos Alcantar) Date: Tue, 18 Jun 2013 01:48:27 +0000 Subject: 10gig coast to coast In-Reply-To: Message-ID: It's typically that the last mile portion of the circuit is going to cost you the most, so it's important to know those details. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: eric clark Date: Monday, June 17, 2013 3:22 PM To: "Valdis.Kletnieks at vt.edu" Cc: "nanog at nanog.org" Subject: Re: 10gig coast to coast Fair enough Seattle to Boston is the general route, real close. On Monday, June 17, 2013, wrote: > On Mon, 17 Jun 2013 12:51:28 -0700, eric clark said: > > > I may be needing 10 gig from the West Coast to the East Coast > > Might want to be more specific. Catalina Island, CA to Buxton, NC > (home of Cape Hatteras High School) will probably be way different > than downtown LA to downtown Boston. > From george.herbert at gmail.com Tue Jun 18 02:32:17 2013 From: george.herbert at gmail.com (George Herbert) Date: Mon, 17 Jun 2013 19:32:17 -0700 Subject: 10gig coast to coast In-Reply-To: References: Message-ID: Also, what are reliability and redundancy requirements. 10 gigs of bare naked fiber is one thing, but if you need extra paths redundancy, figure that out now and specify. Is this latency, bandwidth, both? Mission critical, business critical, less priority? 24x7x365, or subset of that, or intermittent only? On Mon, Jun 17, 2013 at 6:48 PM, Carlos Alcantar wrote: > It's typically that the last mile portion of the circuit is going to cost > you the most, so it's important to know those details. > > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com > > > > > > -----Original Message----- > From: eric clark > Date: Monday, June 17, 2013 3:22 PM > To: "Valdis.Kletnieks at vt.edu" > Cc: "nanog at nanog.org" > Subject: Re: 10gig coast to coast > > Fair enough > > Seattle to Boston is the general route, real close. > > On Monday, June 17, 2013, wrote: > > > On Mon, 17 Jun 2013 12:51:28 -0700, eric clark said: > > > > > I may be needing 10 gig from the West Coast to the East Coast > > > > Might want to be more specific. Catalina Island, CA to Buxton, NC > > (home of Cape Hatteras High School) will probably be way different > > than downtown LA to downtown Boston. > > > > > > -- -george william herbert george.herbert at gmail.com From jeff-kell at utc.edu Tue Jun 18 02:42:00 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 17 Jun 2013 22:42:00 -0400 Subject: 10gig coast to coast In-Reply-To: References: Message-ID: <51BFC8F8.3080009@utc.edu> On 6/17/2013 10:32 PM, George Herbert wrote: > Also, what are reliability and redundancy requirements. > > 10 gigs of bare naked fiber is one thing, but if you need extra paths > redundancy, figure that out now and specify. > > Is this latency, bandwidth, both? Mission critical, business critical, > less priority? 24x7x365, or subset of that, or intermittent only? And are you looking for "dark fiber" or can you deal with a lambda? Can you supply tuned optics for the passive mux carriers? Dark coast-to-coast is going to cost you a few appendages. You may land a lambda for a reasonable price depending on the endpoints, you'll need an established carrier with DWDM gear on both ends. Jeff From cabenth at gmail.com Tue Jun 18 03:48:39 2013 From: cabenth at gmail.com (Eric Clark) Date: Mon, 17 Jun 2013 20:48:39 -0700 Subject: 10gig coast to coast In-Reply-To: References: Message-ID: <921BCA88-1F28-4872-897C-AA0E621DF3F9@gmail.com> all of these questions are valid. The guys who will use it would love to have line rate on the 10G, for a single conversation, but that's not going to happen. So, there's a certain amount of expectation management. For the purpose we're proposing, this would be an additional link to an existing office, a link for test/lab traffic specifically. We would run the lab management on the existing link (s) and provide some sort of restricted failover as well. Sorry I'm not going into more detail, just trying to balance the need for some info versus ... you know. This link wouldn't need to be 5 Nines, but with the office primary and backup, we can provide the connectivity almost 100% of the time. Thanks for all the comments everyone, they have been helpful. Eric On Jun 17, 2013, at 7:32 PM, George Herbert wrote: > Also, what are reliability and redundancy requirements. > > 10 gigs of bare naked fiber is one thing, but if you need extra paths > redundancy, figure that out now and specify. > > Is this latency, bandwidth, both? Mission critical, business critical, > less priority? 24x7x365, or subset of that, or intermittent only? > > > On Mon, Jun 17, 2013 at 6:48 PM, Carlos Alcantar wrote: > >> It's typically that the last mile portion of the circuit is going to cost >> you the most, so it's important to know those details. >> >> Carlos Alcantar >> Race Communications / Race Team Member >> 1325 Howard Ave. #604, Burlingame, CA. 94010 >> Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com >> >> >> >> >> >> -----Original Message----- >> From: eric clark >> Date: Monday, June 17, 2013 3:22 PM >> To: "Valdis.Kletnieks at vt.edu" >> Cc: "nanog at nanog.org" >> Subject: Re: 10gig coast to coast >> >> Fair enough >> >> Seattle to Boston is the general route, real close. >> >> On Monday, June 17, 2013, wrote: >> >>> On Mon, 17 Jun 2013 12:51:28 -0700, eric clark said: >>> >>>> I may be needing 10 gig from the West Coast to the East Coast >>> >>> Might want to be more specific. Catalina Island, CA to Buxton, NC >>> (home of Cape Hatteras High School) will probably be way different >>> than downtown LA to downtown Boston. >>> >> >> >> >> > > > -- > -george william herbert > george.herbert at gmail.com From cabenth at gmail.com Tue Jun 18 03:51:30 2013 From: cabenth at gmail.com (Eric Clark) Date: Mon, 17 Jun 2013 20:51:30 -0700 Subject: 10gig coast to coast In-Reply-To: <51BFC8F8.3080009@utc.edu> References: <51BFC8F8.3080009@utc.edu> Message-ID: <7631E0D7-A436-48AB-B855-16D0D4703FFD@gmail.com> I'm looking for options. With dark fiber, obviously, I have the ultimate in options. However, its the ultimate in cost as you say. The requirement we have is 10gig of actual throughput. Precisely what mechanism is used to transport it isn't all that important, though I'm certain that there will be complaints... :) I'd LOVE to have me some DWDM, always wanted to run some of that gear, but at that point, why stop at 10G On Jun 17, 2013, at 7:42 PM, Jeff Kell wrote: > On 6/17/2013 10:32 PM, George Herbert wrote: >> Also, what are reliability and redundancy requirements. >> >> 10 gigs of bare naked fiber is one thing, but if you need extra paths >> redundancy, figure that out now and specify. >> >> Is this latency, bandwidth, both? Mission critical, business critical, >> less priority? 24x7x365, or subset of that, or intermittent only? > > And are you looking for "dark fiber" or can you deal with a lambda? Can > you supply tuned optics for the passive mux carriers? > > Dark coast-to-coast is going to cost you a few appendages. You may land > a lambda for a reasonable price depending on the endpoints, you'll need > an established carrier with DWDM gear on both ends. > > Jeff > > From philfagan at gmail.com Tue Jun 18 04:04:52 2013 From: philfagan at gmail.com (Phil Fagan) Date: Mon, 17 Jun 2013 22:04:52 -0600 Subject: 10gig coast to coast In-Reply-To: <7631E0D7-A436-48AB-B855-16D0D4703FFD@gmail.com> References: <51BFC8F8.3080009@utc.edu> <7631E0D7-A436-48AB-B855-16D0D4703FFD@gmail.com> Message-ID: I've had pretty good luck with CenturyLinks 10G wave offerings: http://shop.centurylink.com/largebusiness/enterprisesolutions/products/ethernet/qwave.html Ethernet hand-off at both sites with IPsec or GRE provided a pretty solid environment. You should be able to take advantage of some UDP blasters at what the latency profile will look like for you. Otherwise you could always thread the crap out of whatever it is your transactioning across the link to make up for TCP's jackknifes along with other tuning. On Mon, Jun 17, 2013 at 9:51 PM, Eric Clark wrote: > I'm looking for options. > > With dark fiber, obviously, I have the ultimate in options. > > However, its the ultimate in cost as you say. > > The requirement we have is 10gig of actual throughput. Precisely what > mechanism is used to transport it isn't all that important, though I'm > certain that there will be complaints... :) > > I'd LOVE to have me some DWDM, always wanted to run some of that gear, but > at that point, why stop at 10G > > On Jun 17, 2013, at 7:42 PM, Jeff Kell wrote: > > > On 6/17/2013 10:32 PM, George Herbert wrote: > >> Also, what are reliability and redundancy requirements. > >> > >> 10 gigs of bare naked fiber is one thing, but if you need extra paths > >> redundancy, figure that out now and specify. > >> > >> Is this latency, bandwidth, both? Mission critical, business critical, > >> less priority? 24x7x365, or subset of that, or intermittent only? > > > > And are you looking for "dark fiber" or can you deal with a lambda? Can > > you supply tuned optics for the passive mux carriers? > > > > Dark coast-to-coast is going to cost you a few appendages. You may land > > a lambda for a reasonable price depending on the endpoints, you'll need > > an established carrier with DWDM gear on both ends. > > > > Jeff > > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From adam.vitkovsky at swan.sk Tue Jun 18 08:08:56 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Tue, 18 Jun 2013 10:08:56 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: <013F3DA4-1864-4AC9-BB51-7096656D2459@ufp.org> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> <20130610165402.GA75895@gweep.net> <668B8361-F10C-45B2-B64C-D6A0702FF440@ianai.net> <20130610181405.GA11687@gweep.net> <2B2F57F4-9B55-4DB3-960E-21EAF96F3D0F@ianai.net> <013F3DA4-1864-4AC9-BB51-7096656D2459@ufp.org> Message-ID: <011901ce6bfb$14493b30$3cdbb190$@swan.sk> > neighbor a.b.c.d allowas-in route-map SAFETY Wow this would be so cool, I'll definitely mention this to our SE. I was wondering if the internet service is realized as MPLS VRF than the ISP could do as-override which is pretty standard for VPN services. What I'm curious about is the percentage of tier2/3 ISPs doing full internet in a VRF over common MPLS backbone as I guess it's not that common. adam From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Tue Jun 18 12:08:02 2013 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Tue, 18 Jun 2013 14:08:02 +0200 Subject: Single AS multiple Dirverse Providers In-Reply-To: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB655E230D9@03-exchange.lti.local> Message-ID: <4413278.orTY2iJmub@gentoovm> A BGP speaker will not accept routes with its own AS in the path, nor should it. Whilst a number of people have suggested using allowas-in, I'd personally not recommend it as loop prevention is generally a good thing - if you ever added a BGP speaker to one network that also had internet peerings (plus iBGP to the existing router) allowas-in would result in internal traffic going over the external link since eBGP is preferred over iBGP. You could of course prevent that by mangling attributes, but why create the potential work and pain for yourself? Instead, I'd suggest setting up iBGP peerings for each of the upstreams, rewriting the next hop address of received routes to the upstream of that particular interface. Since it would really be pointless/wasteful to advertise your internet routes over iBGP, be sure to restrict it to just your own networks. Doing it this way means that you can quite easily just spin up a new peering if you get a real backbone link, and you don't take on the downsides of using allowas-in. Regards Oliver On Monday 10 June 2013 11:36:44 Dennis Burgess wrote: > I have a network that has three peers, two are at one site and the third > is geographically diverse, and there is NO connection between the two > separate networks. > > > > Currently we are announcing several /24s out one network and other /24s > out the second network, they do not overlap. To the internet this works > fine, however, providers a/b at site1 do not send us the two /24s from > site b.. We have requested them to, but have not seen them come in, > nor do we have any filters that would prohibit them from coming in. > > > > Is this normal? Can we receive those routes even though they are from > our own AS? What is the "best practice" in this case? > > > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- > Second Edition " > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > Office: 314-735-0270 Website: > http://www.linktechs.net - Skype: linktechs > > > -- Create Wireless Coverage's with www.towercoverage.com > - 900Mhz - LTE - 3G - 3.65 - TV > Whitespace From jakob.heitz at ericsson.com Tue Jun 18 13:20:34 2013 From: jakob.heitz at ericsson.com (Jakob Heitz) Date: Tue, 18 Jun 2013 13:20:34 +0000 Subject: 10gig coast to coast In-Reply-To: References: Message-ID: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> > Date: Mon, 17 Jun 2013 22:04:52 -0600 > From: Phil Fagan > ... you could always > thread the crap out of whatever it is your transactioning across the link > to make up for TCP's jackknifes... What is a TCP jackknife? Cheers. Jakob. From freimer at freimer.org Tue Jun 18 13:28:41 2013 From: freimer at freimer.org (Fred Reimer) Date: Tue, 18 Jun 2013 13:28:41 +0000 Subject: 10gig coast to coast In-Reply-To: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> Message-ID: It is also called a "sawtooth" or similar terms. Just google "tcp sawtooth" and you will see many references, and images that depict the traffic pattern. HTH, Fred Reimer | Secure Network Solutions Architect Presidio | www.presidio.com 3250 W. Commercial Blvd Suite 360, Oakland Park, FL 33309 D: 954.703.1490 | C: 954.298.1697 | F: 407.284.6681 | freimer at presidio.com CCIE 23812, CISSP 107125, HP MASE, TPCSE 2265 On 6/18/13 9:20 AM, "Jakob Heitz" wrote: >> Date: Mon, 17 Jun 2013 22:04:52 -0600 >> From: Phil Fagan >> ... you could always >> thread the crap out of whatever it is your transactioning across the >>link >> to make up for TCP's jackknifes... > >What is a TCP jackknife? > >Cheers. >Jakob. > From jakob.heitz at ericsson.com Tue Jun 18 13:45:37 2013 From: jakob.heitz at ericsson.com (Jakob Heitz) Date: Tue, 18 Jun 2013 13:45:37 +0000 Subject: 10gig coast to coast In-Reply-To: References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com>, Message-ID: <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> Thanks Fred. Sawtooth is more familiar. How much of that do you actually see in practice? Cheers, Jakob. On Jun 18, 2013, at 6:27 AM, "Fred Reimer" wrote: > It is also called a "sawtooth" or similar terms. Just google "tcp > sawtooth" and you will see many references, and images that depict the > traffic pattern. > > HTH, > > Fred Reimer | Secure Network Solutions Architect > Presidio | www.presidio.com > 3250 W. Commercial Blvd Suite 360, Oakland Park, FL 33309 > D: 954.703.1490 | C: 954.298.1697 | F: 407.284.6681 | freimer at presidio.com > CCIE 23812, CISSP 107125, HP MASE, TPCSE 2265 > > > > > On 6/18/13 9:20 AM, "Jakob Heitz" wrote: > >>> Date: Mon, 17 Jun 2013 22:04:52 -0600 >>> From: Phil Fagan >>> ... you could always >>> thread the crap out of whatever it is your transactioning across the >>> link >>> to make up for TCP's jackknifes... >> >> What is a TCP jackknife? >> >> Cheers. >> Jakob. >> > From philfagan at gmail.com Tue Jun 18 14:15:58 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 18 Jun 2013 08:15:58 -0600 Subject: 10gig coast to coast In-Reply-To: <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> Message-ID: Sorry; yes Sawtooth is the more accurate term. I see this on a daily occurance with large data-set transfers; generally if the data-set is large multiples of the initial window. I've never tested medium latency( <100ms) with small enough payloads where it may pay-off threading out many thousands of sessions. However, medium latency with large files (50M-10G) threads well in the sub 200 range and does a pretty good job at filling several Gig links. None of this is scientific; just my observations from the wild.....infulenced by end to end tunings per environment. On Tue, Jun 18, 2013 at 7:45 AM, Jakob Heitz wrote: > Thanks Fred. Sawtooth is more familiar. > How much of that do you actually see in practice? > > Cheers, > Jakob. > > > On Jun 18, 2013, at 6:27 AM, "Fred Reimer" wrote: > > > It is also called a "sawtooth" or similar terms. Just google "tcp > > sawtooth" and you will see many references, and images that depict the > > traffic pattern. > > > > HTH, > > > > Fred Reimer | Secure Network Solutions Architect > > Presidio | www.presidio.com > > 3250 W. Commercial Blvd Suite 360, Oakland Park, FL 33309 > > D: 954.703.1490 | C: 954.298.1697 | F: 407.284.6681 | > freimer at presidio.com > > CCIE 23812, CISSP 107125, HP MASE, TPCSE 2265 > > > > > > > > > > On 6/18/13 9:20 AM, "Jakob Heitz" wrote: > > > >>> Date: Mon, 17 Jun 2013 22:04:52 -0600 > >>> From: Phil Fagan > >>> ... you could always > >>> thread the crap out of whatever it is your transactioning across the > >>> link > >>> to make up for TCP's jackknifes... > >> > >> What is a TCP jackknife? > >> > >> Cheers. > >> Jakob. > >> > > > > -- Phil Fagan Denver, CO 970-480-7618 From james.braunegg at micron21.com Tue Jun 18 15:53:48 2013 From: james.braunegg at micron21.com (James Braunegg) Date: Tue, 18 Jun 2013 15:53:48 +0000 Subject: 10gig coast to coast In-Reply-To: References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> Message-ID: Dear All We Deal with TCP window size all day every day across the southern cross from LA to Australia which adds around 160ms... I've given up looking for a solution to get around physical physics of sending TCP traffic a long distance at a high speed.... UDP traffic however comes in very fast.... Kindest Regards James Braunegg W:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Phil Fagan [mailto:philfagan at gmail.com] Sent: Wednesday, June 19, 2013 12:16 AM To: Jakob Heitz Cc: Subject: Re: 10gig coast to coast Sorry; yes Sawtooth is the more accurate term. I see this on a daily occurance with large data-set transfers; generally if the data-set is large multiples of the initial window. I've never tested medium latency( <100ms) with small enough payloads where it may pay-off threading out many thousands of sessions. However, medium latency with large files (50M-10G) threads well in the sub 200 range and does a pretty good job at filling several Gig links. None of this is scientific; just my observations from the wild.....infulenced by end to end tunings per environment. On Tue, Jun 18, 2013 at 7:45 AM, Jakob Heitz wrote: > Thanks Fred. Sawtooth is more familiar. > How much of that do you actually see in practice? > > Cheers, > Jakob. > > > On Jun 18, 2013, at 6:27 AM, "Fred Reimer" wrote: > > > It is also called a "sawtooth" or similar terms. Just google "tcp > > sawtooth" and you will see many references, and images that depict > > the traffic pattern. > > > > HTH, > > > > Fred Reimer | Secure Network Solutions Architect Presidio | > > www.presidio.com > > 3250 W. Commercial Blvd Suite 360, Oakland Park, FL 33309 > > D: 954.703.1490 | C: 954.298.1697 | F: 407.284.6681 | > freimer at presidio.com > > CCIE 23812, CISSP 107125, HP MASE, TPCSE 2265 > > > > > > > > > > On 6/18/13 9:20 AM, "Jakob Heitz" wrote: > > > >>> Date: Mon, 17 Jun 2013 22:04:52 -0600 > >>> From: Phil Fagan ... you could always thread > >>> the crap out of whatever it is your transactioning across the link > >>> to make up for TCP's jackknifes... > >> > >> What is a TCP jackknife? > >> > >> Cheers. > >> Jakob. > >> > > > > -- Phil Fagan Denver, CO 970-480-7618 From tony at ellipticalmobilesolutions.com Tue Jun 18 16:35:30 2013 From: tony at ellipticalmobilesolutions.com (Tony Cole) Date: Tue, 18 Jun 2013 16:35:30 +0000 Subject: recommended outdoor enclosures Message-ID: <4b6bf11a8c644353a74fd25ea30ee6c7@BLUPR04MB165.namprd04.prod.outlook.com> The Skid-mounted C3Spear in a NEMA4 version would work perfectly for this application. http://www.ellipticalmobilesolutions.com/c3spear.html From khelms at zcorum.com Tue Jun 18 17:17:36 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 18 Jun 2013 13:17:36 -0400 Subject: huawei In-Reply-To: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> References: <27475396.7949.1371319860946.JavaMail.root@benjamin.baylink.com> Message-ID: So I'm clear, its not just a "low bit rate" argument. Its a low bit rate, combined with little spare horsepower (CPU & RAM), little non-volatile storage, and a deluge of information to sort through in order to find something useful. If core routers weren't in the core, where they have access to lots of data, they'd never be considered as targets for data interception. To that point there are other, better, places to intercept data that has both better throughput and fewer challenges (ie less expensive). Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Sat, Jun 15, 2013 at 2:11 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > Is it possible? Yes, but it's not feasible because the data rate would be > > too low. That's what I'm trying to get across. There are lots things that > > can be done but many of those are not useful. > > > > I could encode communications in fireworks displays, but that's not > > effective for any sort of communication system. > > At this point, of course, we hearken back to the Multics system, which > needed -- in order to get the B1(?) common criteria security rating that it > had -- to prevent Covert Channel communication between processes of > different > security levels *by means as low-bandwidth as sending morse code by > modulating the system load*. > > So I don't think "there's too little bandwidth" is a good enough argument, > Scott. > > But there's a much more important issue here: > > In some cases, like the Verizon Wireless 4G puck I mentioned earlier, > manufactured by ZTE, *you can't see the back side of the device*. There's > nearly no practical way for a subscriber to know what's coming out of the > 4G side of that radio, so it could be doing anything it likes. > > Verizon Wireless proper could know, but they have no particular reason to > look > and, some might argue, lots of reasons not to want to know. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From Valdis.Kletnieks at vt.edu Tue Jun 18 17:18:49 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 18 Jun 2013 13:18:49 -0400 Subject: 10gig coast to coast In-Reply-To: Your message of "Tue, 18 Jun 2013 15:53:48 -0000." References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> Message-ID: <6185.1371575929@turing-police.cc.vt.edu> On Tue, 18 Jun 2013 15:53:48 -0000, James Braunegg said: > We Deal with TCP window size all day every day across the southern cross from > LA to Australia which adds around 160ms... I've given up looking for a > solution to get around physical physics of sending TCP traffic a long distance > at a high speed.... http://www.extremetech.com/extreme/141651-caltech-and-uvic-set-339gbps-internet-speed-record It's apparently doable. ;) A quick cheat sheet for the low-hanging fruit: http://www.psc.edu/index.php/networking/641-tcp-tune Though to get to *really* high througput, you may have to play some games with TCP slow-start so it's not quite as slow (otherwise for long hauls it can take literally hours to open the window after a packet burp at 10G or higher) Also, you may want to look at CODEL or related queueing disciplines to minimize the amount of trouble that bufferbloat can cause you at high speeds. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From trapperjohn117 at gmail.com Tue Jun 18 20:25:36 2013 From: trapperjohn117 at gmail.com (Jazz Kenny) Date: Tue, 18 Jun 2013 13:25:36 -0700 Subject: huawei (oscilloscopes and frequency analysis) In-Reply-To: <063001ce6b68$4eabb610$ec032230$@swalter.com> References: <063001ce6b68$4eabb610$ec032230$@swalter.com> Message-ID: On Mon, Jun 17, 2013 at 7:38 AM, Tony Patti wrote: > Thanks, I liked your pointer to the SDR. > > But can I ask you for a bit more info about your statement > > "where oscilloscopes and frequency analysis is available to anyone with some > Google-fu" > > We don't need as much test equipment before? > > (as a guy with an oscilloscope in his basement, I don't see how Google can > do what that device can). > > > > Thanks, > > Tony All I meant was that the tools are relatively accessible to anyone with the desire to look - An oscilloscope with the necessary freq. range to study 4G communications can be bought or fabricated (all that's really needed is a microcontroller with an ADC, some gain amps and time), an appropriate SDR to intercept the signals shouldn't be too hard to source, and that community has been blowing up for a few years now. Hell, there are even a couple examples of LGA 4G receivers floating around in the wild (gtm801, for example). Ignoring all of that, there are commercial options like the YellowFin 4G analyzer. No idea how much one of those costs, though. Now, like Jay said, there are the issues of encryption and such, but that's just another barrier to entry. A little Google-fu could probably source a paper dealing with its implementation, at least. I doubt it would be easy, but if the motivation exists, the required test bed is easily assembled, and the information is available. Not like we're talking about intercepted military GPS bands or something. It's a consumer device that can sit on a workbench and be tested at the leisure of the security researcher. - J. From philfagan at gmail.com Tue Jun 18 20:31:37 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 18 Jun 2013 14:31:37 -0600 Subject: huawei (oscilloscopes and frequency analysis) In-Reply-To: References: <063001ce6b68$4eabb610$ec032230$@swalter.com> Message-ID: now THAT would be a cool project! On Tue, Jun 18, 2013 at 2:25 PM, Jazz Kenny wrote: > On Mon, Jun 17, 2013 at 7:38 AM, Tony Patti wrote: > > Thanks, I liked your pointer to the SDR. > > > > But can I ask you for a bit more info about your statement > > > > "where oscilloscopes and frequency analysis is available to anyone with > some > > Google-fu" > > > > We don't need as much test equipment before? > > > > (as a guy with an oscilloscope in his basement, I don't see how Google > can > > do what that device can). > > > > > > > > Thanks, > > > > Tony > > All I meant was that the tools are relatively accessible to anyone > with the desire to look - An oscilloscope with the necessary freq. > range to study 4G communications can be bought or fabricated (all > that's really needed is a microcontroller with an ADC, some gain amps > and time), an appropriate SDR to intercept the signals shouldn't be > too hard to source, and that community has been blowing up for a few > years now. Hell, there are even a couple examples of LGA 4G receivers > floating around in the wild (gtm801, for example). Ignoring all of > that, there are commercial options like the YellowFin 4G analyzer. No > idea how much one of those costs, though. > > Now, like Jay said, there are the issues of encryption and such, but > that's just another barrier to entry. A little Google-fu could > probably source a paper dealing with its implementation, at least. > > I doubt it would be easy, but if the motivation exists, the required > test bed is easily assembled, and the information is available. Not > like we're talking about intercepted military GPS bands or something. > It's a consumer device that can sit on a workbench and be tested at > the leisure of the security researcher. > > - J. > > -- Phil Fagan Denver, CO 970-480-7618 From blueneon at gmail.com Tue Jun 18 21:42:29 2013 From: blueneon at gmail.com (Tom Morris) Date: Tue, 18 Jun 2013 17:42:29 -0400 Subject: huawei (oscilloscopes and frequency analysis) In-Reply-To: References: <063001ce6b68$4eabb610$ec032230$@swalter.com> Message-ID: There's already code out there for the GNURadio project's software defined radio infrastructure that supports some very basic LTE analysis.... using a $20 or less USB DTV tuner stick!! Only a matter of time before some radio devices with a lot more bandwidth become affordable and easily accessible. https://github.com/Evrytania/LTE-Cell-Scanner On Tue, Jun 18, 2013 at 4:31 PM, Phil Fagan wrote: > now THAT would be a cool project! > > > On Tue, Jun 18, 2013 at 2:25 PM, Jazz Kenny >wrote: > > > On Mon, Jun 17, 2013 at 7:38 AM, Tony Patti wrote: > > > Thanks, I liked your pointer to the SDR. > > > > > > But can I ask you for a bit more info about your statement > > > > > > "where oscilloscopes and frequency analysis is available to anyone with > > some > > > Google-fu" > > > > > > We don't need as much test equipment before? > > > > > > (as a guy with an oscilloscope in his basement, I don't see how Google > > can > > > do what that device can). > > > > > > > > > > > > Thanks, > > > > > > Tony > > > > All I meant was that the tools are relatively accessible to anyone > > with the desire to look - An oscilloscope with the necessary freq. > > range to study 4G communications can be bought or fabricated (all > > that's really needed is a microcontroller with an ADC, some gain amps > > and time), an appropriate SDR to intercept the signals shouldn't be > > too hard to source, and that community has been blowing up for a few > > years now. Hell, there are even a couple examples of LGA 4G receivers > > floating around in the wild (gtm801, for example). Ignoring all of > > that, there are commercial options like the YellowFin 4G analyzer. No > > idea how much one of those costs, though. > > > > Now, like Jay said, there are the issues of encryption and such, but > > that's just another barrier to entry. A little Google-fu could > > probably source a paper dealing with its implementation, at least. > > > > I doubt it would be easy, but if the motivation exists, the required > > test bed is easily assembled, and the information is available. Not > > like we're talking about intercepted military GPS bands or something. > > It's a consumer device that can sit on a workbench and be tested at > > the leisure of the security researcher. > > > > - J. > > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- -- Tom Morris, KG4CYX Mad Scientist For Hire Chairman, South Florida Tropical Hamboree / Miami Hamfest Engineer, WRGP Radiate FM, Florida International University 786-228-7087 151.820 Megacycles From reichert at numachi.com Tue Jun 18 22:52:54 2013 From: reichert at numachi.com (Brian Reichert) Date: Tue, 18 Jun 2013 18:52:54 -0400 Subject: huawei (oscilloscopes and frequency analysis) In-Reply-To: References: <063001ce6b68$4eabb610$ec032230$@swalter.com> Message-ID: <20130618225254.GL11165@numachi.com> On Tue, Jun 18, 2013 at 02:31:37PM -0600, Phil Fagan wrote: > now THAT would be a cool project! (I missed the beginnig of this thread; sorry if this is a repeat.) There was the fellow demonstrating a spoofed 2G GSM tower at DefCon recently: http://www.forbes.com/sites/firewall/2010/07/31/despite-fcc-scare-tactics-researcher-demos-att-eavesdropping/ And the YouTube video was pretty cool to watch, for technical depth. https://www.youtube.com/watch?v=rXVHPNhsOzo Part of his talk described how he could (up a point) block 3G, to cause phones to fail over to 2G, where he could get them. 4G is a whole different thing, but the talk was educational, nonetheless... > -- > Phil Fagan > Denver, CO > 970-480-7618 -- Brian Reichert BSD admin/developer at large From blake.mailinglist at pfankuch.me Tue Jun 18 23:53:50 2013 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Tue, 18 Jun 2013 23:53:50 +0000 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... Message-ID: Howdy, I have been working on a proposal for the organization I work for to move into the 10gbit datacenter. We have a small datacenter currently of about 1000 ports of 1gbit. We have traditionally been a full Cisco shop, however I was asked to do a price comparison as well as features with other major alternative vendors. I was also asked to do some digging as far as what "the real world" thinks about these possible vendors. We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit to a very specialized implementation. With all of our technology, we try to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime yearly so stability is preferable to cool features. We currently have single supervisors in all of our switches (not my decision) and it has bit us recently. Everything we are looking at needs to support NSF/SSO/VSS of some kind. What we have been looking to replace it with in Cisco world is Nexus 7004 Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically we will be under 800 ports of 10gbit (excluding Blades) which puts us in a tough spot from what I can find. Currently everything we have is EOR, however TOR would make more sense allowing us to switch to SFP+ twinax connectivity to servers. With this in mind, I have a few questions... It was mandated that I look at a company "Arista Networks" and investigate possible options. I had not heard much about them, so I look to the experts. Pro's and Con's? Real world experience? Looks to me they have a lot of cool features, but I'm slightly concerned with how new they might be, how reliable it would be as well as their QA/bugfix history. Also 24x4 support and hardware replacement. Everything in our datacenter currently has a 2 or 4 hour cisco contract on it and critical core components have a cold spare in inventory. Dell Force 10... I know Dell tries to get you to drink the Koolaid on this solution, I was a former Dell Partner and they even pushed me to get demo equipment going... What's the experience with their chassis switches? Stability? Configuration sanity? What do people like? What do people hate? Juniper. What do people like? What do people hate? Have the Layer 2 issues of historical age gone away? Is the config still xml ish? It has been about 5 years since I worked with anything Juniper. Extreme networks. I know very little about them historically. What is good, what is bad? Is the config sane? I would be happy to compile any information I find, as well as our sanitized internal conclusions. On and off list responses welcome. If there is another vendor anyone would suggest, please add them to the list with similarly asked questions. Thanks! Blake From philfagan at gmail.com Wed Jun 19 00:08:27 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 18 Jun 2013 18:08:27 -0600 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: I love JUNOS, don't really care for IOS. I really trust Cisco and Juniper's hardware, with that being said Arista is your best bet for cheapest port. I've only seen Arista in lab, not in the wild yet so I can't speak for how I would trust them. You mention getting bit by single sups, I believe as of late Arista has had issue with OSPF failover time between dual-sups in HA setups. I used to have a Dell laptop....but I'm sure their great too. In the end for me I only trust Cisco or Juniper. I've been burnt by Foundry and am waiting to on Arista. On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < blake.mailinglist at pfankuch.me> wrote: > Howdy, > I have been working on a proposal for the organization I > work for to move into the 10gbit datacenter. We have a small datacenter > currently of about 1000 ports of 1gbit. We have traditionally been a full > Cisco shop, however I was asked to do a price comparison as well as > features with other major alternative vendors. I was also asked to do some > digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit > to a very specialized implementation. With all of our technology, we try > to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime > yearly so stability is preferable to cool features. We currently have > single supervisors in all of our switches (not my decision) and it has bit > us recently. Everything we are looking at needs to support NSF/SSO/VSS of > some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 > Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as > well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically > we will be under 800 ports of 10gbit (excluding Blades) which puts us in a > tough spot from what I can find. Currently everything we have is EOR, > however TOR would make more sense allowing us to switch to SFP+ twinax > connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate > possible options. I had not heard much about them, so I look to the > experts. Pro's and Con's? Real world experience? Looks to me they have a > lot of cool features, but I'm slightly concerned with how new they might > be, how reliable it would be as well as their QA/bugfix history. Also 24x4 > support and hardware replacement. Everything in our datacenter currently > has a 2 or 4 hour cisco contract on it and critical core components have a > cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this > solution, I was a former Dell Partner and they even pushed me to get demo > equipment going... What's the experience with their chassis switches? > Stability? Configuration sanity? What do people like? What do people > hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 > issues of historical age gone away? Is the config still xml ish? It has > been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is > good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our > sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the > list with similarly asked questions. > > Thanks! > > Blake > -- Phil Fagan Denver, CO 970-480-7618 From james.braunegg at micron21.com Wed Jun 19 00:24:15 2013 From: james.braunegg at micron21.com (James Braunegg) Date: Wed, 19 Jun 2013 00:24:15 +0000 Subject: 10gig coast to coast In-Reply-To: <6185.1371575929@turing-police.cc.vt.edu> References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> <6185.1371575929@turing-police.cc.vt.edu> Message-ID: Dear Valdis Thanks for your comments, whilst I know you can optimize servers for TCP windowing I was more talking about network backhaul where you don't have control over the server sending the traffic. ie backhauling IP transit over the southern cross cable system Kindest Regards James Braunegg W:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Wednesday, June 19, 2013 3:19 AM To: James Braunegg Cc: Phil Fagan; Jakob Heitz; Subject: Re: 10gig coast to coast On Tue, 18 Jun 2013 15:53:48 -0000, James Braunegg said: > We Deal with TCP window size all day every day across the southern > cross from LA to Australia which adds around 160ms... I've given up > looking for a solution to get around physical physics of sending TCP > traffic a long distance at a high speed.... http://www.extremetech.com/extreme/141651-caltech-and-uvic-set-339gbps-internet-speed-record It's apparently doable. ;) A quick cheat sheet for the low-hanging fruit: http://www.psc.edu/index.php/networking/641-tcp-tune Though to get to *really* high througput, you may have to play some games with TCP slow-start so it's not quite as slow (otherwise for long hauls it can take literally hours to open the window after a packet burp at 10G or higher) Also, you may want to look at CODEL or related queueing disciplines to minimize the amount of trouble that bufferbloat can cause you at high speeds. From blake.mailinglist at pfankuch.me Wed Jun 19 00:31:44 2013 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Wed, 19 Jun 2013 00:31:44 +0000 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: Let me also clarify, Price per port is not the final deciding factor. We are looking much more at a combination of daily operational sanity, troubleshooting features, operational feature set, vendor support quality and price. Support is absolute key. When we need help, we need help quickly and knowledgeable support. The name checkpoint comes to mind when I think of something I DON?T want for support quality. It also causes nausea? Thanks, Blake From: Phil Fagan [mailto:philfagan at gmail.com] Sent: Tuesday, June 18, 2013 6:08 PM To: Blake Pfankuch - Mailing List Cc: NANOG (nanog at nanog.org) Subject: Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... I love JUNOS, don't really care for IOS. I really trust Cisco and Juniper's hardware, with that being said Arista is your best bet for cheapest port. I've only seen Arista in lab, not in the wild yet so I can't speak for how I would trust them. You mention getting bit by single sups, I believe as of late Arista has had issue with OSPF failover time between dual-sups in HA setups. I used to have a Dell laptop....but I'm sure their great too. In the end for me I only trust Cisco or Juniper. I've been burnt by Foundry and am waiting to on Arista. On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List > wrote: Howdy, I have been working on a proposal for the organization I work for to move into the 10gbit datacenter. We have a small datacenter currently of about 1000 ports of 1gbit. We have traditionally been a full Cisco shop, however I was asked to do a price comparison as well as features with other major alternative vendors. I was also asked to do some digging as far as what "the real world" thinks about these possible vendors. We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit to a very specialized implementation. With all of our technology, we try to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime yearly so stability is preferable to cool features. We currently have single supervisors in all of our switches (not my decision) and it has bit us recently. Everything we are looking at needs to support NSF/SSO/VSS of some kind. What we have been looking to replace it with in Cisco world is Nexus 7004 Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically we will be under 800 ports of 10gbit (excluding Blades) which puts us in a tough spot from what I can find. Currently everything we have is EOR, however TOR would make more sense allowing us to switch to SFP+ twinax connectivity to servers. With this in mind, I have a few questions... It was mandated that I look at a company "Arista Networks" and investigate possible options. I had not heard much about them, so I look to the experts. Pro's and Con's? Real world experience? Looks to me they have a lot of cool features, but I'm slightly concerned with how new they might be, how reliable it would be as well as their QA/bugfix history. Also 24x4 support and hardware replacement. Everything in our datacenter currently has a 2 or 4 hour cisco contract on it and critical core components have a cold spare in inventory. Dell Force 10... I know Dell tries to get you to drink the Koolaid on this solution, I was a former Dell Partner and they even pushed me to get demo equipment going... What's the experience with their chassis switches? Stability? Configuration sanity? What do people like? What do people hate? Juniper. What do people like? What do people hate? Have the Layer 2 issues of historical age gone away? Is the config still xml ish? It has been about 5 years since I worked with anything Juniper. Extreme networks. I know very little about them historically. What is good, what is bad? Is the config sane? I would be happy to compile any information I find, as well as our sanitized internal conclusions. On and off list responses welcome. If there is another vendor anyone would suggest, please add them to the list with similarly asked questions. Thanks! Blake -- Phil Fagan Denver, CO 970-480-7618 From d.nostra at gmail.com Wed Jun 19 00:47:54 2013 From: d.nostra at gmail.com (Michel de Nostredame) Date: Tue, 18 Jun 2013 17:47:54 -0700 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: DELL Force10 switches (not DELL Power Connect) run so far so good in our environment. the combination of S4810 and Z9000 make good sense on both operation and capex point of view. There were three headaches for us in the beginning of adaption. Force10 calculates frame size with CRC32, say if your IP MTU is 9000 on VMware then the trunk port on Force10 should be 9022. Although it clearly documented in manual but still troublesome for people who lives in Cisco world for all his past life and want to use non-default MTU (1500) on Force10 switch. Another headache was Force10 needs to manually config MTU (if not use default MTU) on every interface even if the interface is member of port-channel and you do already config MTU on PO interface The last one was the way how it creates VLANs. Not like Cisco, Force10 cannot creates say hundreds of VLANs in one single line, but need to create VLAN interface one by one, even if they are purely layer-2 VLAN, not RVI. However, those 3 things can be managed by script or by using the free deployment tool, AFM, from DELL. Beside those 3, so far the switches run rock solid. One very good benefit is Force10 does not (almost) have virtual port limitation like Cisco does. (Force10 has completely no limit when use RSTP. and 250 x ports when use PVST. You can google "Cisco virtual port limit".) This freedom is extremely important when operate large flat layer-2 network for VM. On Tue, Jun 18, 2013 at 5:08 PM, Phil Fagan wrote: > I love JUNOS, don't really care for IOS. I really trust Cisco and Juniper's > hardware, with that being said Arista is your best bet for cheapest port. > I've only seen Arista in lab, not in the wild yet so I can't speak for how > I would trust them. You mention getting bit by single sups, I believe as of > late Arista has had issue with OSPF failover time between dual-sups in HA > setups. > > I used to have a Dell laptop....but I'm sure their great too. In the end > for me I only trust Cisco or Juniper. I've been burnt by Foundry and am > waiting to on Arista. > > > On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < > blake.mailinglist at pfankuch.me> wrote: > >> Howdy, >> I have been working on a proposal for the organization I >> work for to move into the 10gbit datacenter. We have a small datacenter >> currently of about 1000 ports of 1gbit. We have traditionally been a full >> Cisco shop, however I was asked to do a price comparison as well as >> features with other major alternative vendors. I was also asked to do some >> digging as far as what "the real world" thinks about these possible vendors. >> >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco >> 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit >> to a very specialized implementation. With all of our technology, we try >> to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime >> yearly so stability is preferable to cool features. We currently have >> single supervisors in all of our switches (not my decision) and it has bit >> us recently. Everything we are looking at needs to support NSF/SSO/VSS of >> some kind. >> >> What we have been looking to replace it with in Cisco world is Nexus 7004 >> Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as >> well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically >> we will be under 800 ports of 10gbit (excluding Blades) which puts us in a >> tough spot from what I can find. Currently everything we have is EOR, >> however TOR would make more sense allowing us to switch to SFP+ twinax >> connectivity to servers. >> >> With this in mind, I have a few questions... >> >> It was mandated that I look at a company "Arista Networks" and investigate >> possible options. I had not heard much about them, so I look to the >> experts. Pro's and Con's? Real world experience? Looks to me they have a >> lot of cool features, but I'm slightly concerned with how new they might >> be, how reliable it would be as well as their QA/bugfix history. Also 24x4 >> support and hardware replacement. Everything in our datacenter currently >> has a 2 or 4 hour cisco contract on it and critical core components have a >> cold spare in inventory. >> >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on this >> solution, I was a former Dell Partner and they even pushed me to get demo >> equipment going... What's the experience with their chassis switches? >> Stability? Configuration sanity? What do people like? What do people >> hate? >> >> Juniper. What do people like? What do people hate? Have the Layer 2 >> issues of historical age gone away? Is the config still xml ish? It has >> been about 5 years since I worked with anything Juniper. >> >> Extreme networks. I know very little about them historically. What is >> good, what is bad? Is the config sane? >> >> I would be happy to compile any information I find, as well as our >> sanitized internal conclusions. On and off list responses welcome. >> >> If there is another vendor anyone would suggest, please add them to the >> list with similarly asked questions. >> >> Thanks! >> >> Blake >> > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- -- Michel~ From Valdis.Kletnieks at vt.edu Wed Jun 19 00:47:41 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 18 Jun 2013 20:47:41 -0400 Subject: 10gig coast to coast In-Reply-To: Your message of "Wed, 19 Jun 2013 00:24:15 -0000." References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> <6185.1371575929@turing-police.cc.vt.edu> Message-ID: <56300.1371602861@turing-police.cc.vt.edu> On Wed, 19 Jun 2013 00:24:15 -0000, James Braunegg said: > Thanks for your comments, whilst I know you can optimize servers for TCP > windowing I was more talking about network backhaul where you don't have > control over the server sending the traffic. If you don't have control over the server, why are you allowing your customer to make their misconfiguration your problem? (Mostly a rhetorical question, as I know damned well how this sort of thing ends up happening) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From d.nostra at gmail.com Wed Jun 19 00:56:53 2013 From: d.nostra at gmail.com (Michel de Nostredame) Date: Tue, 18 Jun 2013 17:56:53 -0700 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: On Tue, Jun 18, 2013 at 5:31 PM, Blake Pfankuch - Mailing List wrote: > Let me also clarify, Price per port is not the final deciding factor. We are looking much more at a combination of daily operational sanity, troubleshooting features, operational feature set, vendor support quality and price. > > Support is absolute key. When we need help, we need help quickly and knowledgeable support. The name checkpoint comes to mind when I think of something I DON?T want for support quality. It also causes nausea? > > Thanks, > > Blake I would say Force10 support is very good, especially in bay area that their HQ is locally here. Most of our questions can be addressed within only few days even in one day. That probably because our environment is too simple? Layer-2 TOR S4810, Layer-3 Core Z9000, runs OSPF and VLT (multiple chassis LAG, this is something like Cisco VPC/VSS.) From ben at meh.net.nz Wed Jun 19 01:08:30 2013 From: ben at meh.net.nz (Ben Aitchison) Date: Wed, 19 Jun 2013 13:08:30 +1200 Subject: 10gig coast to coast In-Reply-To: <56300.1371602861@turing-police.cc.vt.edu> References: <986E5BA7-8951-44E3-A590-8725077FD3A5@ericsson.com> <55E49981-B86E-4425-BB39-C2B6AC100DC8@ericsson.com> <6185.1371575929@turing-police.cc.vt.edu> <56300.1371602861@turing-police.cc.vt.edu> Message-ID: <20130619010830.GB32739@meh.net.nz> On Tue, Jun 18, 2013 at 08:47:41PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 19 Jun 2013 00:24:15 -0000, James Braunegg said: > > > Thanks for your comments, whilst I know you can optimize servers for TCP > > windowing I was more talking about network backhaul where you don't have > > control over the server sending the traffic. > > If you don't have control over the server, why are you allowing your > customer to make their misconfiguration your problem? (Mostly a rhetorical > question, as I know damned well how this sort of thing ends up happening) maybe his customers are connecting to normal internet servers. there's a lot of servers with strangely low limits on window size out there. like on speedtest.net under palo alto there's "Fiber Internet Center" which seems to have a window size of 128k. it requests files from 66.201.42.23, and if you do something like: curl -O http://66.201.42.23/speedtest/random4000x4000.jpg then do ping 66.201.42.23 then divide 1000 by the latency, for example 1000 / 160 then muitply by 128 then that number is about what curl will show on a fast connection. speedtest.net seems to use 2 parallel connections which raises the speed slightly, but it seems reasonably common to come across sites with sub-optimal tcp/ip configurations, like a while back i noticed www.godaddy.com seems to use 2 packets initial window size, and if using a proxy server that sends Via they seem to disable compression, so the web page will load very slowly from a remote location using a proxy server. Using recent Linux default kernels network speeds can be very good over high latency connections both for small files, and larger files assuming minimal packet loss. The combination of initial window size of 10 packets and cubic congestion control helps both small and large tranfers, and Linux has been improving their TCP/IP stack a lot. But there are still quite a few less ideal TCP/IP peers around. Also big buffers really help microbursts of traffic on fast connections. And using small buffers can really increase the sawtooth effects of TCP/IP. With all this talk of buffer bloat, in my experience sfq works better than codel for long distance throughput.. Ben. From philfagan at gmail.com Wed Jun 19 01:11:01 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 18 Jun 2013 19:11:01 -0600 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: I've had nothing but good luck with Juniper support and well with Cisco you pay for support too. I will say Arista support was great, however, I'm still hesitant to put them in full production; but I think that is lack of experience with them speaking. Do the bake off in your lab and let'm run! On Tue, Jun 18, 2013 at 6:31 PM, Blake Pfankuch - Mailing List < blake.mailinglist at pfankuch.me> wrote: > Let me also clarify, Price per port is not the final deciding factor. > We are looking much more at a combination of daily operational sanity, > troubleshooting features, operational feature set, vendor support quality > and price.**** > > ** ** > > Support is absolute key. When we need help, we need help quickly and > knowledgeable support. The name checkpoint comes to mind when I think of > something I DON?T want for support quality. It also causes nausea?**** > > ** ** > > Thanks,**** > > ** ** > > Blake**** > > ** ** > > *From:* Phil Fagan [mailto:philfagan at gmail.com] > *Sent:* Tuesday, June 18, 2013 6:08 PM > *To:* Blake Pfankuch - Mailing List > *Cc:* NANOG (nanog at nanog.org) > *Subject:* Re: Network Vendor suggestions/reviews, Arista Networks, Dell > Force10, Juniper, Extreme Networks etc...**** > > ** ** > > I love JUNOS, don't really care for IOS. I really trust Cisco and > Juniper's hardware, with that being said Arista is your best bet for > cheapest port. I've only seen Arista in lab, not in the wild yet so I can't > speak for how I would trust them. You mention getting bit by single sups, I > believe as of late Arista has had issue with OSPF failover time between > dual-sups in HA setups.**** > > ** ** > > I used to have a Dell laptop....but I'm sure their great too. In the end > for me I only trust Cisco or Juniper. I've been burnt by Foundry and am > waiting to on Arista. **** > > ** ** > > On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < > blake.mailinglist at pfankuch.me> wrote:**** > > Howdy, > I have been working on a proposal for the organization I > work for to move into the 10gbit datacenter. We have a small datacenter > currently of about 1000 ports of 1gbit. We have traditionally been a full > Cisco shop, however I was asked to do a price comparison as well as > features with other major alternative vendors. I was also asked to do some > digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit > to a very specialized implementation. With all of our technology, we try > to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime > yearly so stability is preferable to cool features. We currently have > single supervisors in all of our switches (not my decision) and it has bit > us recently. Everything we are looking at needs to support NSF/SSO/VSS of > some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 > Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as > well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically > we will be under 800 ports of 10gbit (excluding Blades) which puts us in a > tough spot from what I can find. Currently everything we have is EOR, > however TOR would make more sense allowing us to switch to SFP+ twinax > connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate > possible options. I had not heard much about them, so I look to the > experts. Pro's and Con's? Real world experience? Looks to me they have a > lot of cool features, but I'm slightly concerned with how new they might > be, how reliable it would be as well as their QA/bugfix history. Also 24x4 > support and hardware replacement. Everything in our datacenter currently > has a 2 or 4 hour cisco contract on it and critical core components have a > cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this > solution, I was a former Dell Partner and they even pushed me to get demo > equipment going... What's the experience with their chassis switches? > Stability? Configuration sanity? What do people like? What do people > hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 > issues of historical age gone away? Is the config still xml ish? It has > been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is > good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our > sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the > list with similarly asked questions. > > Thanks! > > Blake**** > > > > **** > > ** ** > > -- **** > > Phil Fagan**** > > Denver, CO**** > > 970-480-7618**** > -- Phil Fagan Denver, CO 970-480-7618 From eyeronic.design at gmail.com Wed Jun 19 01:27:34 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 18 Jun 2013 18:27:34 -0700 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: I'm exact opposite of Phil. I love IOS and hate JunOS....for that single reason, I'm really against buying Juniper in our shop for pretty much anything. :) Still, to be fair, the hardware seems to be really, really stable and well built. I don't think we've had a failure across our Junipers in the short time I've been with my day job. As far as support goes...the only time we had issues with our Nexus gear I was actually really, really disappointed with Cisco. We were upgrading our firmware, ran into some major issues with VPC and HSRP due some firmware changes, and the Tac engineer we got sucked *massive* lemons. When I call Tac with a situation like this, I expect someone who can code a working config from scratch based on the old config, not someone who's going to sit there scratching his head, running useless packet captures, and being silent when we ask questions. *sigh* /rant off On Tue, Jun 18, 2013 at 6:11 PM, Phil Fagan wrote: > I've had nothing but good luck with Juniper support and well with Cisco you > pay for support too. I will say Arista support was great, however, I'm > still hesitant to put them in full production; but I think that is lack of > experience with them speaking. > > Do the bake off in your lab and let'm run! > > > On Tue, Jun 18, 2013 at 6:31 PM, Blake Pfankuch - Mailing List < > blake.mailinglist at pfankuch.me> wrote: > >> Let me also clarify, Price per port is not the final deciding factor. >> We are looking much more at a combination of daily operational sanity, >> troubleshooting features, operational feature set, vendor support quality >> and price.**** >> >> ** ** >> >> Support is absolute key. When we need help, we need help quickly and >> knowledgeable support. The name checkpoint comes to mind when I think of >> something I DON?T want for support quality. It also causes nausea?**** >> >> ** ** >> >> Thanks,**** >> >> ** ** >> >> Blake**** >> >> ** ** >> >> *From:* Phil Fagan [mailto:philfagan at gmail.com] >> *Sent:* Tuesday, June 18, 2013 6:08 PM >> *To:* Blake Pfankuch - Mailing List >> *Cc:* NANOG (nanog at nanog.org) >> *Subject:* Re: Network Vendor suggestions/reviews, Arista Networks, Dell >> Force10, Juniper, Extreme Networks etc...**** >> >> ** ** >> >> I love JUNOS, don't really care for IOS. I really trust Cisco and >> Juniper's hardware, with that being said Arista is your best bet for >> cheapest port. I've only seen Arista in lab, not in the wild yet so I can't >> speak for how I would trust them. You mention getting bit by single sups, I >> believe as of late Arista has had issue with OSPF failover time between >> dual-sups in HA setups.**** >> >> ** ** >> >> I used to have a Dell laptop....but I'm sure their great too. In the end >> for me I only trust Cisco or Juniper. I've been burnt by Foundry and am >> waiting to on Arista. **** >> >> ** ** >> >> On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < >> blake.mailinglist at pfankuch.me> wrote:**** >> >> Howdy, >> I have been working on a proposal for the organization I >> work for to move into the 10gbit datacenter. We have a small datacenter >> currently of about 1000 ports of 1gbit. We have traditionally been a full >> Cisco shop, however I was asked to do a price comparison as well as >> features with other major alternative vendors. I was also asked to do some >> digging as far as what "the real world" thinks about these possible vendors. >> >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco >> 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit >> to a very specialized implementation. With all of our technology, we try >> to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime >> yearly so stability is preferable to cool features. We currently have >> single supervisors in all of our switches (not my decision) and it has bit >> us recently. Everything we are looking at needs to support NSF/SSO/VSS of >> some kind. >> >> What we have been looking to replace it with in Cisco world is Nexus 7004 >> Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as >> well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically >> we will be under 800 ports of 10gbit (excluding Blades) which puts us in a >> tough spot from what I can find. Currently everything we have is EOR, >> however TOR would make more sense allowing us to switch to SFP+ twinax >> connectivity to servers. >> >> With this in mind, I have a few questions... >> >> It was mandated that I look at a company "Arista Networks" and investigate >> possible options. I had not heard much about them, so I look to the >> experts. Pro's and Con's? Real world experience? Looks to me they have a >> lot of cool features, but I'm slightly concerned with how new they might >> be, how reliable it would be as well as their QA/bugfix history. Also 24x4 >> support and hardware replacement. Everything in our datacenter currently >> has a 2 or 4 hour cisco contract on it and critical core components have a >> cold spare in inventory. >> >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on this >> solution, I was a former Dell Partner and they even pushed me to get demo >> equipment going... What's the experience with their chassis switches? >> Stability? Configuration sanity? What do people like? What do people >> hate? >> >> Juniper. What do people like? What do people hate? Have the Layer 2 >> issues of historical age gone away? Is the config still xml ish? It has >> been about 5 years since I worked with anything Juniper. >> >> Extreme networks. I know very little about them historically. What is >> good, what is bad? Is the config sane? >> >> I would be happy to compile any information I find, as well as our >> sanitized internal conclusions. On and off list responses welcome. >> >> If there is another vendor anyone would suggest, please add them to the >> list with similarly asked questions. >> >> Thanks! >> >> Blake**** >> >> >> >> **** >> >> ** ** >> >> -- **** >> >> Phil Fagan**** >> >> Denver, CO**** >> >> 970-480-7618**** >> > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From philfagan at gmail.com Wed Jun 19 02:14:18 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 18 Jun 2013 20:14:18 -0600 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: Mike brings up a good point though; the effort, cost, and risk of introducing a new CLI to an environment sometimes is masked until you really need to dig in and work through outages. Familiarity with a codebase or at least with how the code "thinks" should go a long way when deciding what to put in your racks. Of course, how do you quantify that? On Tue, Jun 18, 2013 at 7:27 PM, Mike Hale wrote: > I'm exact opposite of Phil. I love IOS and hate JunOS....for that > single reason, I'm really against buying Juniper in our shop for > pretty much anything. :) > > Still, to be fair, the hardware seems to be really, really stable and > well built. I don't think we've had a failure across our Junipers in > the short time I've been with my day job. > > As far as support goes...the only time we had issues with our Nexus > gear I was actually really, really disappointed with Cisco. We were > upgrading our firmware, ran into some major issues with VPC and HSRP > due some firmware changes, and the Tac engineer we got sucked > *massive* lemons. When I call Tac with a situation like this, I > expect someone who can code a working config from scratch based on the > old config, not someone who's going to sit there scratching his head, > running useless packet captures, and being silent when we ask > questions. *sigh* > > /rant off > > On Tue, Jun 18, 2013 at 6:11 PM, Phil Fagan wrote: > > I've had nothing but good luck with Juniper support and well with Cisco > you > > pay for support too. I will say Arista support was great, however, I'm > > still hesitant to put them in full production; but I think that is lack > of > > experience with them speaking. > > > > Do the bake off in your lab and let'm run! > > > > > > On Tue, Jun 18, 2013 at 6:31 PM, Blake Pfankuch - Mailing List < > > blake.mailinglist at pfankuch.me> wrote: > > > >> Let me also clarify, Price per port is not the final deciding factor. > >> We are looking much more at a combination of daily operational sanity, > >> troubleshooting features, operational feature set, vendor support > quality > >> and price.**** > >> > >> ** ** > >> > >> Support is absolute key. When we need help, we need help quickly and > >> knowledgeable support. The name checkpoint comes to mind when I think > of > >> something I DON?T want for support quality. It also causes nausea?**** > >> > >> ** ** > >> > >> Thanks,**** > >> > >> ** ** > >> > >> Blake**** > >> > >> ** ** > >> > >> *From:* Phil Fagan [mailto:philfagan at gmail.com] > >> *Sent:* Tuesday, June 18, 2013 6:08 PM > >> *To:* Blake Pfankuch - Mailing List > >> *Cc:* NANOG (nanog at nanog.org) > >> *Subject:* Re: Network Vendor suggestions/reviews, Arista Networks, Dell > >> Force10, Juniper, Extreme Networks etc...**** > >> > >> ** ** > >> > >> I love JUNOS, don't really care for IOS. I really trust Cisco and > >> Juniper's hardware, with that being said Arista is your best bet for > >> cheapest port. I've only seen Arista in lab, not in the wild yet so I > can't > >> speak for how I would trust them. You mention getting bit by single > sups, I > >> believe as of late Arista has had issue with OSPF failover time between > >> dual-sups in HA setups.**** > >> > >> ** ** > >> > >> I used to have a Dell laptop....but I'm sure their great too. In the end > >> for me I only trust Cisco or Juniper. I've been burnt by Foundry and am > >> waiting to on Arista. **** > >> > >> ** ** > >> > >> On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < > >> blake.mailinglist at pfankuch.me> wrote:**** > >> > >> Howdy, > >> I have been working on a proposal for the organization I > >> work for to move into the 10gbit datacenter. We have a small datacenter > >> currently of about 1000 ports of 1gbit. We have traditionally been a > full > >> Cisco shop, however I was asked to do a price comparison as well as > >> features with other major alternative vendors. I was also asked to do > some > >> digging as far as what "the real world" thinks about these possible > vendors. > >> > >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > >> 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing > 10gbit > >> to a very specialized implementation. With all of our technology, we > try > >> to not be bleeding edge, but oozing edge. We need 5 9's or more of > uptime > >> yearly so stability is preferable to cool features. We currently have > >> single supervisors in all of our switches (not my decision) and it has > bit > >> us recently. Everything we are looking at needs to support NSF/SSO/VSS > of > >> some kind. > >> > >> What we have been looking to replace it with in Cisco world is Nexus > 7004 > >> Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access > as > >> well as 2200 Fabric Extenders within our Dell Blade Chassis. > Realistically > >> we will be under 800 ports of 10gbit (excluding Blades) which puts us > in a > >> tough spot from what I can find. Currently everything we have is EOR, > >> however TOR would make more sense allowing us to switch to SFP+ twinax > >> connectivity to servers. > >> > >> With this in mind, I have a few questions... > >> > >> It was mandated that I look at a company "Arista Networks" and > investigate > >> possible options. I had not heard much about them, so I look to the > >> experts. Pro's and Con's? Real world experience? Looks to me they > have a > >> lot of cool features, but I'm slightly concerned with how new they might > >> be, how reliable it would be as well as their QA/bugfix history. Also > 24x4 > >> support and hardware replacement. Everything in our datacenter > currently > >> has a 2 or 4 hour cisco contract on it and critical core components > have a > >> cold spare in inventory. > >> > >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on > this > >> solution, I was a former Dell Partner and they even pushed me to get > demo > >> equipment going... What's the experience with their chassis switches? > >> Stability? Configuration sanity? What do people like? What do people > >> hate? > >> > >> Juniper. What do people like? What do people hate? Have the Layer 2 > >> issues of historical age gone away? Is the config still xml ish? It > has > >> been about 5 years since I worked with anything Juniper. > >> > >> Extreme networks. I know very little about them historically. What is > >> good, what is bad? Is the config sane? > >> > >> I would be happy to compile any information I find, as well as our > >> sanitized internal conclusions. On and off list responses welcome. > >> > >> If there is another vendor anyone would suggest, please add them to the > >> list with similarly asked questions. > >> > >> Thanks! > >> > >> Blake**** > >> > >> > >> > >> **** > >> > >> ** ** > >> > >> -- **** > >> > >> Phil Fagan**** > >> > >> Denver, CO**** > >> > >> 970-480-7618**** > >> > > > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > -- Phil Fagan Denver, CO 970-480-7618 From brent at brentrjones.com Wed Jun 19 03:17:51 2013 From: brent at brentrjones.com (Brent Jones) Date: Tue, 18 Jun 2013 20:17:51 -0700 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: On Tue, Jun 18, 2013 at 4:53 PM, Blake Pfankuch - Mailing List < blake.mailinglist at pfankuch.me> wrote: > Howdy, > I have been working on a proposal for the organization I > work for to move into the 10gbit datacenter. We have a small datacenter > currently of about 1000 ports of 1gbit. We have traditionally been a full > Cisco shop, however I was asked to do a price comparison as well as > features with other major alternative vendors. I was also asked to do some > digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit > to a very specialized implementation. With all of our technology, we try > to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime > yearly so stability is preferable to cool features. We currently have > single supervisors in all of our switches (not my decision) and it has bit > us recently. Everything we are looking at needs to support NSF/SSO/VSS of > some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 > Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as > well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically > we will be under 800 ports of 10gbit (excluding Blades) which puts us in a > tough spot from what I can find. Currently everything we have is EOR, > however TOR would make more sense allowing us to switch to SFP+ twinax > connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate > possible options. I had not heard much about them, so I look to the > experts. Pro's and Con's? Real world experience? Looks to me they have a > lot of cool features, but I'm slightly concerned with how new they might > be, how reliable it would be as well as their QA/bugfix history. Also 24x4 > support and hardware replacement. Everything in our datacenter currently > has a 2 or 4 hour cisco contract on it and critical core components have a > cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this > solution, I was a former Dell Partner and they even pushed me to get demo > equipment going... What's the experience with their chassis switches? > Stability? Configuration sanity? What do people like? What do people > hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 > issues of historical age gone away? Is the config still xml ish? It has > been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is > good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our > sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the > list with similarly asked questions. > > Thanks! > > Blake > Coming from first hand experience, all network equipment vendors have strengths and weaknesses. Personally, I prefer the Junos CLI and ecosystem, but it is a learning curve, especially with a larger team who may not be familiar with it. But I found once I grasped the "Junos way", I'm significantly more productive with less errors, and "commit confirmed" is much better than Cisco comparable rollback methods. Juniper also offers several methods for automation: Junoscript/SLAX, Netconf, and now Puppet integration. I also have experience with Force10, and minor experience with Arista, both good vendors. They will be immieditely familiar to your team, since they use the same commands mostly. I find Juniper's virtual chassis to be among the better stacking technologies, but everyone has their own take. Force10 and Arista do really good multi-chassis LAG, as well as the Juniper QFX lineup. These days, vendors are really competitive on pricing and offerings, so you really can't go wrong :) -- Brent Jones brent at brentrjones.com From qlixed at gmail.com Wed Jun 19 00:29:10 2013 From: qlixed at gmail.com (QliX=D! [aka EHB]) Date: Tue, 18 Jun 2013 21:29:10 -0300 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: Go juniper!!! Full junos equipment on the network means same OS for switches, routers, and firewalls. You have high end equipment to support a core tier1 backbone, and also a simpliest 24 port sw soho range. All with the same config languaje. You can use the management software called junos space to make complex deploys like a brezee. Space have multiple modules that you can use to manage, configure and monitor all the junos equipment family. You can setup the delivery and assurance process with this software. Also you can automatize some things with scripts and junos space have an api to interact with other software. SDN also is part of all this things. Take a good and deep look over the juniper ecosystem, is really great. And became from the shitty ios and horrible management products from cisco, you can see a big change and big plus on this with juniper. ~EHB~ El jun 18, 2013 8:54 PM, "Blake Pfankuch - Mailing List" < blake.mailinglist at pfankuch.me> escribi?: > Howdy, > I have been working on a proposal for the organization I > work for to move into the 10gbit datacenter. We have a small datacenter > currently of about 1000 ports of 1gbit. We have traditionally been a full > Cisco shop, however I was asked to do a price comparison as well as > features with other major alternative vendors. I was also asked to do some > digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit > to a very specialized implementation. With all of our technology, we try > to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime > yearly so stability is preferable to cool features. We currently have > single supervisors in all of our switches (not my decision) and it has bit > us recently. Everything we are looking at needs to support NSF/SSO/VSS of > some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 > Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as > well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically > we will be under 800 ports of 10gbit (excluding Blades) which puts us in a > tough spot from what I can find. Currently everything we have is EOR, > however TOR would make more sense allowing us to switch to SFP+ twinax > connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate > possible options. I had not heard much about them, so I look to the > experts. Pro's and Con's? Real world experience? Looks to me they have a > lot of cool features, but I'm slightly concerned with how new they might > be, how reliable it would be as well as their QA/bugfix history. Also 24x4 > support and hardware replacement. Everything in our datacenter currently > has a 2 or 4 hour cisco contract on it and critical core components have a > cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this > solution, I was a former Dell Partner and they even pushed me to get demo > equipment going... What's the experience with their chassis switches? > Stability? Configuration sanity? What do people like? What do people > hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 > issues of historical age gone away? Is the config still xml ish? It has > been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is > good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our > sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the > list with similarly asked questions. > > Thanks! > > Blake > From ebais at a2b-internet.com Wed Jun 19 06:21:06 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 19 Jun 2013 08:21:06 +0200 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: Hi Blake, Purple is the new Green. I would have a vote for Extreme Networks if you look for a high density, low latency, non blocking setup. Their BD X8 could do 768 10G's per chassis (2304 ports per rack). Later this year the BD X8 will also do the new gen 100G. Their switches are one of the fastest switches you can find for a datacenter setup, along with their TOR switch, the 48 port 10G 1U switch, the X670/X670V. From a pricepoint in purchase but also in power consumption and management cost, Extreme Networks will be a clear winner. If you are looking for options like certain sw features, Extreme works like a charm in a MPLS/ VPLS setup, MLAGG, OSPF and v6. They also put a lot of effort in SW API's like perl /XML interfaces for automation, which makes it great to script against. Their CLI has a bit different structure vs Cisco IOS or the Juniper cli, but very easy to pickup. We do a lot with Extreme in our own ISP network, I would recommend them in any Cisco 6509 replacement project. Regards, Erik Bais Op 19 jun. 2013 om 01:53 heeft Blake Pfankuch - Mailing List het volgende geschreven: > Howdy, > I have been working on a proposal for the organization I work for to move into the 10gbit datacenter. We have a small datacenter currently of about 1000 ports of 1gbit. We have traditionally been a full Cisco shop, however I was asked to do a price comparison as well as features with other major alternative vendors. I was also asked to do some digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit to a very specialized implementation. With all of our technology, we try to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime yearly so stability is preferable to cool features. We currently have single supervisors in all of our switches (not my decision) and it has bit us recently. Everything we are looking at needs to support NSF/SSO/VSS of some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically we will be under 800 ports of 10gbit (excluding Blades) which puts us in a tough spot from what I can find. Currently everything we have is EOR, however TOR would make more sense allowing us to switch to SFP+ twinax connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate possible options. I had not heard much about them, so I look to the experts. Pro's and Con's? Real world experience? Looks to me they have a lot of cool features, but I'm slightly concerned with how new they might be, how reliable it would be as well as their QA/bugfix history. Also 24x4 support and hardware replacement. Everything in our datacenter currently has a 2 or 4 hour cisco contract on it and critical core components have a cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this solution, I was a former Dell Partner and they even pushed me to get demo equipment going... What's the experience with their chassis switches? Stability? Configuration sanity? What do people like? What do people hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 issues of historical age gone away? Is the config still xml ish? It has been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the list with similarly asked questions. > > Thanks! > > Blake From andreas.larsen at ip-only.se Wed Jun 19 06:26:36 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Wed, 19 Jun 2013 08:26:36 +0200 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: Message-ID: I have worked with both Extreme, Juniper, Cisco and Brocade and Avaya. Extreme. Great boxes stable and afforadable when it comes to 10GE and 40GE. Truly one XOS for all boxes, lowend x440 has the same XOS as 48*10GE device.Support sucks very bad though if you can't get your SE to support you. Juniper Great boxes, very nice CLI, good support with a nice ticketsystem and good kb. However I have found alot of bugs that needs to be corrected in the switch series that are somewhat annoying. Cisco Good boxes, expensive great support and a amazing KB. Brocade Good boxed, a tad expensive. Open to opensoucre when it comes to SDN stuff. Avaya Great boxes, SPB all the way =), not a solid true OS yet but some different ones on different boxes, but to my mind the SPB solution gives you the most flexability in a datacenter today and you can even in the long run mix vendors if you like since it's open and standarized. Short rant =) Hope you find the vendor you like the best and by all means take in a couple of them for test. Med v?nlig h?lsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se Den 2013-06-19 05:17 skrev Brent Jones : >On Tue, Jun 18, 2013 at 4:53 PM, Blake Pfankuch - Mailing List < >blake.mailinglist at pfankuch.me> wrote: > >> Howdy, >> I have been working on a proposal for the organization I >> work for to move into the 10gbit datacenter. We have a small datacenter >> currently of about 1000 ports of 1gbit. We have traditionally been a >>full >> Cisco shop, however I was asked to do a price comparison as well as >> features with other major alternative vendors. I was also asked to do >>some >> digging as far as what "the real world" thinks about these possible >>vendors. >> >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco >> 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing >>10gbit >> to a very specialized implementation. With all of our technology, we >>try >> to not be bleeding edge, but oozing edge. We need 5 9's or more of >>uptime >> yearly so stability is preferable to cool features. We currently have >> single supervisors in all of our switches (not my decision) and it has >>bit >> us recently. Everything we are looking at needs to support NSF/SSO/VSS >>of >> some kind. >> >> What we have been looking to replace it with in Cisco world is Nexus >>7004 >> Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access >>as >> well as 2200 Fabric Extenders within our Dell Blade Chassis. >>Realistically >> we will be under 800 ports of 10gbit (excluding Blades) which puts us >>in a >> tough spot from what I can find. Currently everything we have is EOR, >> however TOR would make more sense allowing us to switch to SFP+ twinax >> connectivity to servers. >> >> With this in mind, I have a few questions... >> >> It was mandated that I look at a company "Arista Networks" and >>investigate >> possible options. I had not heard much about them, so I look to the >> experts. Pro's and Con's? Real world experience? Looks to me they >>have a >> lot of cool features, but I'm slightly concerned with how new they might >> be, how reliable it would be as well as their QA/bugfix history. Also >>24x4 >> support and hardware replacement. Everything in our datacenter >>currently >> has a 2 or 4 hour cisco contract on it and critical core components >>have a >> cold spare in inventory. >> >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on >>this >> solution, I was a former Dell Partner and they even pushed me to get >>demo >> equipment going... What's the experience with their chassis switches? >> Stability? Configuration sanity? What do people like? What do people >> hate? >> >> Juniper. What do people like? What do people hate? Have the Layer 2 >> issues of historical age gone away? Is the config still xml ish? It >>has >> been about 5 years since I worked with anything Juniper. >> >> Extreme networks. I know very little about them historically. What is >> good, what is bad? Is the config sane? >> >> I would be happy to compile any information I find, as well as our >> sanitized internal conclusions. On and off list responses welcome. >> >> If there is another vendor anyone would suggest, please add them to the >> list with similarly asked questions. >> >> Thanks! >> >> Blake >> > >Coming from first hand experience, all network equipment vendors have >strengths and weaknesses. >Personally, I prefer the Junos CLI and ecosystem, but it is a learning >curve, especially with a larger team who may not be familiar with it. >But I found once I grasped the "Junos way", I'm significantly more >productive with less errors, and "commit confirmed" is much better than >Cisco comparable rollback methods. >Juniper also offers several methods for automation: Junoscript/SLAX, >Netconf, and now Puppet integration. > >I also have experience with Force10, and minor experience with Arista, >both >good vendors. They will be immieditely familiar to your team, since they >use the same commands mostly. >I find Juniper's virtual chassis to be among the better stacking >technologies, but everyone has their own take. Force10 and Arista do >really >good multi-chassis LAG, as well as the Juniper QFX lineup. > >These days, vendors are really competitive on pricing and offerings, so >you >really can't go wrong :) > >-- >Brent Jones >brent at brentrjones.com From rodrick.brown at gmail.com Wed Jun 19 06:51:43 2013 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Wed, 19 Jun 2013 02:51:43 -0400 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: References: Message-ID: <-4218283544114823749@unknownmsgid> Arista is rock solid they have both an IOS like cli and a standard unix shell you can even run tcpdump on their switches. Arista claim to fame came about 3-4 years back when they had at the time one of the fastest non-blocking cut though 10Gbe switches using the fulcrum asic geared for low latency environments the financial sector ate it up and loved it. Facebook is also a huge Arista shop. Sent from my iPhone On Jun 18, 2013, at 7:56 PM, Blake Pfankuch - Mailing List wrote: > Howdy, > I have been working on a proposal for the organization I work for to move into the 10gbit datacenter. We have a small datacenter currently of about 1000 ports of 1gbit. We have traditionally been a full Cisco shop, however I was asked to do a price comparison as well as features with other major alternative vendors. I was also asked to do some digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit to a very specialized implementation. With all of our technology, we try to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime yearly so stability is preferable to cool features. We currently have single supervisors in all of our switches (not my decision) and it has bit us recently. Everything we are looking at needs to support NSF/SSO/VSS of some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically we will be under 800 ports of 10gbit (excluding Blades) which puts us in a tough spot from what I can find. Currently everything we have is EOR, however TOR would make more sense allowing us to switch to SFP+ twinax connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate possible options. I had not heard much about them, so I look to the experts. Pro's and Con's? Real world experience? Looks to me they have a lot of cool features, but I'm slightly concerned with how new they might be, how reliable it would be as well as their QA/bugfix history. Also 24x4 support and hardware replacement. Everything in our datacenter currently has a 2 or 4 hour cisco contract on it and critical core components have a cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this solution, I was a former Dell Partner and they even pushed me to get demo equipment going... What's the experience with their chassis switches? Stability? Configuration sanity? What do people like? What do people hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 issues of historical age gone away? Is the config still xml ish? It has been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the list with similarly asked questions. > > Thanks! > > Blake From randy at psg.com Wed Jun 19 10:05:21 2013 From: randy at psg.com (Randy Bush) Date: Wed, 19 Jun 2013 19:05:21 +0900 Subject: gTLDs opened up Message-ID: AfriNIC put these wonderful people on stage at the African Internet Summit. -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130618_101455.jpg Type: image/jpeg Size: 58851 bytes Desc: not available URL: -------------- next part -------------- In parallel, I should offer /16s from an alternet IP space for USD1,000, buy one and get one free. randy From owen at delong.com Wed Jun 19 10:14:16 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Jun 2013 12:14:16 +0200 Subject: gTLDs opened up In-Reply-To: References: Message-ID: <981B22D0-2AF6-486E-8E5D-A9C95CE5FA4E@delong.com> AfriNIC did not put them on the stage. AIS was not convened by AfriNIC. It is very much like holding APNIC responsible for the content of other parts of an APRICOT meeting. It just doesn't reflect the facts. I agree that these TLD sellers are rather silly, but the organizers of the conference chose to allow free speech. You are, of course, free to criticize as you wish, but ideally, you should at least direct your criticism at those responsible. Owen On Jun 19, 2013, at 12:05 PM, Randy Bush wrote: > AfriNIC put these wonderful people on stage at the African Internet > Summit. > > <20130618_101455.jpg> > In parallel, I should offer /16s from an alternet IP space for USD1,000, > buy one and get one free. > > > > randy From jeroen at massar.ch Wed Jun 19 11:04:01 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 19 Jun 2013 13:04:01 +0200 Subject: gTLDs opened up In-Reply-To: <981B22D0-2AF6-486E-8E5D-A9C95CE5FA4E@delong.com> References: <981B22D0-2AF6-486E-8E5D-A9C95CE5FA4E@delong.com> Message-ID: <51C19021.10300@massar.ch> On 2013-06-19 12:14, Owen DeLong wrote: > You are, of course, free to criticize as you wish, but ideally, you > should at least direct your criticism at those responsible. Indeed, you should point out the simple fact that anybody with a budget can simply buy their time to sound like they belong somewhere and that people approve of what you do, and being the 'lunch sponsor' gets you there; ergo: verify what those sponsor's message is before letting them pay for spamming at your conference... Greets, Jeroen From randy at psg.com Wed Jun 19 11:06:42 2013 From: randy at psg.com (Randy Bush) Date: Wed, 19 Jun 2013 20:06:42 +0900 Subject: [afnog] gTLDs opened up In-Reply-To: <01F5D8FC-690C-47C4-91B4-AA11DE3A09F3@afrinic.net> References: <01F5D8FC-690C-47C4-91B4-AA11DE3A09F3@afrinic.net> Message-ID: > How is AFRINIC responsible of that? >> AfriNIC put these wonderful people on stage at the African Internet >> Summit. afrinic put them on the stage. it is said because you needed to fill slots in the program, but i really do not know why or care. randy From mysidia at gmail.com Wed Jun 19 12:34:06 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 19 Jun 2013 07:34:06 -0500 Subject: gTLDs opened up In-Reply-To: <981B22D0-2AF6-486E-8E5D-A9C95CE5FA4E@delong.com> References: <981B22D0-2AF6-486E-8E5D-A9C95CE5FA4E@delong.com> Message-ID: On 6/19/13, Owen DeLong wrote: > I agree that these TLD sellers are rather silly, but the organizers of the > conference chose to allow free speech. I'm not sure it matters. Besides, you can always ignore their presentation, abstain from the meeting, go home, or bitch on NANOG; I'll agree TLD seller speeches are a waste of your time - well, unless the folks are from ICANN, who probably will be selling gTLDs en mass before too long, as they undergo technical feasability studies ---- and of course "the answer to a feasibility study is almost always ?yes?". (see Robert Glass, Facts and Fallacies) Although, the bitching on NANOG bit only really serves to draw more attention to their existence, which is what the unauthorized 3rd party TLD selllers want anyways. > You are, of course, free to criticize as you wish, but ideally, you should > at least direct your criticism at those responsible. AfriNic kind of choses to associate themselves, by allowing their meeting to be at a venue, and proximal in time to the TLD sellers' speech. > Owen -- -JH From tglassey at earthlink.net Wed Jun 19 12:43:12 2013 From: tglassey at earthlink.net (tsg) Date: Wed, 19 Jun 2013 05:43:12 -0700 Subject: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... In-Reply-To: <-4218283544114823749@unknownmsgid> References: <-4218283544114823749@unknownmsgid> Message-ID: <51C1A760.5080903@earthlink.net> On 06/18/2013 11:51 PM, Rodrick Brown wrote: > Arista is rock solid they have both an IOS like cli and a standard > unix shell you can even run tcpdump on their switches. > > Arista claim to fame came about 3-4 years back when they had at the > time one of the fastest non-blocking cut though 10Gbe switches using > the fulcrum asic geared for low latency environments the financial > sector ate it up and loved it. Facebook is also a huge Arista shop. Most of the trading framework is as well - it runs on 7124's in many cases and especially the new 7124FX units which are FPGA based and wickedly fast. The other thing you can get from Juniper is time services. Their TCA gear is the rebranded Juniper-Expanded Brilliant-Telecom technology. Todd > > Sent from my iPhone > > On Jun 18, 2013, at 7:56 PM, Blake Pfankuch - Mailing List > wrote: > >> Howdy, >> I have been working on a proposal for the organization I work for to move into the 10gbit datacenter. We have a small datacenter currently of about 1000 ports of 1gbit. We have traditionally been a full Cisco shop, however I was asked to do a price comparison as well as features with other major alternative vendors. I was also asked to do some digging as far as what "the real world" thinks about these possible vendors. >> >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit to a very specialized implementation. With all of our technology, we try to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime yearly so stability is preferable to cool features. We currently have single supervisors in all of our switches (not my decision) and it has bit us recently. Everything we are looking at needs to support NSF/SSO/VSS of some kind. >> >> What we have been looking to replace it with in Cisco world is Nexus 7004 Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically we will be under 800 ports of 10gbit (excluding Blades) which puts us in a tough spot from what I can find. Currently everything we have is EOR, however TOR would make more sense allowing us to switch to SFP+ twinax connectivity to servers. >> >> With this in mind, I have a few questions... >> >> It was mandated that I look at a company "Arista Networks" and investigate possible options. I had not heard much about them, so I look to the experts. Pro's and Con's? Real world experience? Looks to me they have a lot of cool features, but I'm slightly concerned with how new they might be, how reliable it would be as well as their QA/bugfix history. Also 24x4 support and hardware replacement. Everything in our datacenter currently has a 2 or 4 hour cisco contract on it and critical core components have a cold spare in inventory. >> >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on this solution, I was a former Dell Partner and they even pushed me to get demo equipment going... What's the experience with their chassis switches? Stability? Configuration sanity? What do people like? What do people hate? >> >> Juniper. What do people like? What do people hate? Have the Layer 2 issues of historical age gone away? Is the config still xml ish? It has been about 5 years since I worked with anything Juniper. >> >> Extreme networks. I know very little about them historically. What is good, what is bad? Is the config sane? >> >> I would be happy to compile any information I find, as well as our sanitized internal conclusions. On and off list responses welcome. >> >> If there is another vendor anyone would suggest, please add them to the list with similarly asked questions. >> >> Thanks! >> >> Blake > -- // Standard "perasonal email" disclaimers apply From cliff.bowles at apollogrp.edu Wed Jun 19 15:58:22 2013 From: cliff.bowles at apollogrp.edu (Cliff Bowles) Date: Wed, 19 Jun 2013 08:58:22 -0700 Subject: NANOG Digest, Vol 65, Issue 74 In-Reply-To: References: Message-ID: <1A5C3257AD8D4946A4B497A6FAF501743AA6745234@EXCH07-01.apollogrp.edu> As stated, every vendor has its merits. If you really put some time into developing a list of requirements and then structure a bakeoff that tests those, you will learn a lot. Some things to think about: * don't let JUNOS or any other CLI deter you. You just need to factor in training and hiring efforts/costs. We switched to Juniper for 50+ campus routers (haven't used their switches yet) because they had way better bang for the buck. The engineers that whined about it not being Cisco were not the ones I cared to keep. The engineers that went out and learned JUNOS then slapped it on their resume were, by far, the more reliable and skilled engineers. Also, when you are hiring, I bet that you will find that engineers with substantial experience in other platforms will also perform very well on the technical interviews. They will probably know advanced BGP, MPLS, tunneling, multicast, QOS and other stuff that your average interviewee does not. It's a mindset. *politics: we replaced a large section of our network with Foundry (a price-per-port) decision. They worked as well as any vendor out there, but their support was... not polished as Cisco or Juniper. But the real problem came from the low level support engineers who had a CCNA and were Cisco-oriented. Now, when we had Cisco blade/power/code failures, it was a "network failure". When the Foundry had a problem, it was a "Foundry failure". I watched a huge outage due to a poor spanning tree design get branded as a Foundry issue. Management hears this enough and eventually we are told to replace the Foundry switches. I pulled ticket logs and proved that the support team had nearly twice the amount of open tickets and logged failures with Cisco as they did with Foundry, but it didn't matter. *politics again: If you are a big cisco shop and you decide to use another vendor somewhere, I GUARANTEE that a regional sales VP and some ducklings in suits will soon walk directly into the CIO's office. They will argue that the bakeoff was skewed, that price-per-port value doesn't factor in a lot of other value that cisco brings, they will even question the skillset of your engineers who performed the bakeoff, etc... they will instill Fear-Uncertainty-Doubt. They will offer another 2 or 3 % discount, they will throw in free professional services, and so on. Hell, they may put a Cisco employee on your board of directors. Short story - if there's a lot of money involved, you may wind up back with Cisco. I've seen it more than once That being said, I don't dislike Cisco at all. Their support is top notch and their training is pretty good. They take good care of their clients. A LOT of their products are good... some are not. But I did want to prepare you for the fun if you seriously consider another vendor. We have selected Mellanox for a small data warehouse, but that was a point solution due to the Infiniband requirements. We have selected Arista for a large Hadoop deployment. So far, they are a great product and a great value. Support seems good, but we haven't called them much yet. That's a good thing. One other thing to consider is future state and emerging technologies. If you are an architect or if you work with architecture to obtain design direction, ask about future needs for multi-tenancy, SDN, automation and such. I think you'll find that not only is Arista way out ahead of some vendors with this, they are using Open source code, more or less. Cisco has onePK, but their automation and API integration is not only proprietary, it's misleading. I haven't seen the other vendor solutions yet, so I can't say who is BEST at automation, orchestration, and SDN... So... determine what's important to your network today and in 3-5 years, then look at what's being offered. cwb -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Tuesday, June 18, 2013 8:18 PM To: nanog at nanog.org Subject: NANOG Digest, Vol 65, Issue 74 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... (Phil Fagan) 2. Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... (Mike Hale) 3. Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... (Phil Fagan) 4. Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... (Brent Jones) ---------------------------------------------------------------------- Message: 1 Date: Tue, 18 Jun 2013 19:11:01 -0600 From: Phil Fagan To: Blake Pfankuch - Mailing List Cc: "NANOG \(nanog at nanog.org\)" Subject: Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... Message-ID: Content-Type: text/plain; charset=UTF-8 I've had nothing but good luck with Juniper support and well with Cisco you pay for support too. I will say Arista support was great, however, I'm still hesitant to put them in full production; but I think that is lack of experience with them speaking. Do the bake off in your lab and let'm run! On Tue, Jun 18, 2013 at 6:31 PM, Blake Pfankuch - Mailing List < blake.mailinglist at pfankuch.me> wrote: > Let me also clarify, Price per port is not the final deciding factor. > We are looking much more at a combination of daily operational sanity, > troubleshooting features, operational feature set, vendor support > quality and price.**** > > ** ** > > Support is absolute key. When we need help, we need help quickly and > knowledgeable support. The name checkpoint comes to mind when I think > of something I DON?T want for support quality. It also causes > nausea?**** > > ** ** > > Thanks,**** > > ** ** > > Blake**** > > ** ** > > *From:* Phil Fagan [mailto:philfagan at gmail.com] > *Sent:* Tuesday, June 18, 2013 6:08 PM > *To:* Blake Pfankuch - Mailing List > *Cc:* NANOG (nanog at nanog.org) > *Subject:* Re: Network Vendor suggestions/reviews, Arista Networks, > Dell Force10, Juniper, Extreme Networks etc...**** > > ** ** > > I love JUNOS, don't really care for IOS. I really trust Cisco and > Juniper's hardware, with that being said Arista is your best bet for > cheapest port. I've only seen Arista in lab, not in the wild yet so I > can't speak for how I would trust them. You mention getting bit by > single sups, I believe as of late Arista has had issue with OSPF > failover time between dual-sups in HA setups.**** > > ** ** > > I used to have a Dell laptop....but I'm sure their great too. In the > end for me I only trust Cisco or Juniper. I've been burnt by Foundry > and am waiting to on Arista. **** > > ** ** > > On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < > blake.mailinglist at pfankuch.me> wrote:**** > > Howdy, > I have been working on a proposal for the organization > I work for to move into the 10gbit datacenter. We have a small > datacenter currently of about 1000 ports of 1gbit. We have > traditionally been a full Cisco shop, however I was asked to do a > price comparison as well as features with other major alternative > vendors. I was also asked to do some digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 > Cisco > 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing > 10gbit to a very specialized implementation. With all of our > technology, we try to not be bleeding edge, but oozing edge. We need > 5 9's or more of uptime yearly so stability is preferable to cool > features. We currently have single supervisors in all of our switches > (not my decision) and it has bit us recently. Everything we are > looking at needs to support NSF/SSO/VSS of some kind. > > What we have been looking to replace it with in Cisco world is Nexus > 7004 Core and Nexus 5596UP with 2200 series Fabric extenders for > Dist/Access as well as 2200 Fabric Extenders within our Dell Blade > Chassis. Realistically we will be under 800 ports of 10gbit > (excluding Blades) which puts us in a tough spot from what I can find. > Currently everything we have is EOR, however TOR would make more sense > allowing us to switch to SFP+ twinax connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and > investigate possible options. I had not heard much about them, so I > look to the experts. Pro's and Con's? Real world experience? Looks > to me they have a lot of cool features, but I'm slightly concerned > with how new they might be, how reliable it would be as well as their > QA/bugfix history. Also 24x4 support and hardware replacement. > Everything in our datacenter currently has a 2 or 4 hour cisco > contract on it and critical core components have a cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on > this solution, I was a former Dell Partner and they even pushed me to > get demo equipment going... What's the experience with their chassis switches? > Stability? Configuration sanity? What do people like? What do > people hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 > issues of historical age gone away? Is the config still xml ish? It > has been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What > is good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our > sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to > the list with similarly asked questions. > > Thanks! > > Blake**** > > > > **** > > ** ** > > -- **** > > Phil Fagan**** > > Denver, CO**** > > 970-480-7618**** > -- Phil Fagan Denver, CO 970-480-7618 ------------------------------ Message: 2 Date: Tue, 18 Jun 2013 18:27:34 -0700 From: Mike Hale To: Phil Fagan Cc: "NANOG \(nanog at nanog.org\)" Subject: Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... Message-ID: Content-Type: text/plain; charset=windows-1252 I'm exact opposite of Phil. I love IOS and hate JunOS....for that single reason, I'm really against buying Juniper in our shop for pretty much anything. :) Still, to be fair, the hardware seems to be really, really stable and well built. I don't think we've had a failure across our Junipers in the short time I've been with my day job. As far as support goes...the only time we had issues with our Nexus gear I was actually really, really disappointed with Cisco. We were upgrading our firmware, ran into some major issues with VPC and HSRP due some firmware changes, and the Tac engineer we got sucked *massive* lemons. When I call Tac with a situation like this, I expect someone who can code a working config from scratch based on the old config, not someone who's going to sit there scratching his head, running useless packet captures, and being silent when we ask questions. *sigh* /rant off On Tue, Jun 18, 2013 at 6:11 PM, Phil Fagan wrote: > I've had nothing but good luck with Juniper support and well with Cisco you > pay for support too. I will say Arista support was great, however, I'm > still hesitant to put them in full production; but I think that is lack of > experience with them speaking. > > Do the bake off in your lab and let'm run! > > > On Tue, Jun 18, 2013 at 6:31 PM, Blake Pfankuch - Mailing List < > blake.mailinglist at pfankuch.me> wrote: > >> Let me also clarify, Price per port is not the final deciding factor. >> We are looking much more at a combination of daily operational sanity, >> troubleshooting features, operational feature set, vendor support quality >> and price.**** >> >> ** ** >> >> Support is absolute key. When we need help, we need help quickly and >> knowledgeable support. The name checkpoint comes to mind when I think of >> something I DON?T want for support quality. It also causes nausea?**** >> >> ** ** >> >> Thanks,**** >> >> ** ** >> >> Blake**** >> >> ** ** >> >> *From:* Phil Fagan [mailto:philfagan at gmail.com] >> *Sent:* Tuesday, June 18, 2013 6:08 PM >> *To:* Blake Pfankuch - Mailing List >> *Cc:* NANOG (nanog at nanog.org) >> *Subject:* Re: Network Vendor suggestions/reviews, Arista Networks, Dell >> Force10, Juniper, Extreme Networks etc...**** >> >> ** ** >> >> I love JUNOS, don't really care for IOS. I really trust Cisco and >> Juniper's hardware, with that being said Arista is your best bet for >> cheapest port. I've only seen Arista in lab, not in the wild yet so I can't >> speak for how I would trust them. You mention getting bit by single sups, I >> believe as of late Arista has had issue with OSPF failover time between >> dual-sups in HA setups.**** >> >> ** ** >> >> I used to have a Dell laptop....but I'm sure their great too. In the end >> for me I only trust Cisco or Juniper. I've been burnt by Foundry and am >> waiting to on Arista. **** >> >> ** ** >> >> On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < >> blake.mailinglist at pfankuch.me> wrote:**** >> >> Howdy, >> I have been working on a proposal for the organization I >> work for to move into the 10gbit datacenter. We have a small datacenter >> currently of about 1000 ports of 1gbit. We have traditionally been a full >> Cisco shop, however I was asked to do a price comparison as well as >> features with other major alternative vendors. I was also asked to do some >> digging as far as what "the real world" thinks about these possible vendors. >> >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco >> 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit >> to a very specialized implementation. With all of our technology, we try >> to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime >> yearly so stability is preferable to cool features. We currently have >> single supervisors in all of our switches (not my decision) and it has bit >> us recently. Everything we are looking at needs to support NSF/SSO/VSS of >> some kind. >> >> What we have been looking to replace it with in Cisco world is Nexus 7004 >> Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as >> well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically >> we will be under 800 ports of 10gbit (excluding Blades) which puts us in a >> tough spot from what I can find. Currently everything we have is EOR, >> however TOR would make more sense allowing us to switch to SFP+ twinax >> connectivity to servers. >> >> With this in mind, I have a few questions... >> >> It was mandated that I look at a company "Arista Networks" and investigate >> possible options. I had not heard much about them, so I look to the >> experts. Pro's and Con's? Real world experience? Looks to me they have a >> lot of cool features, but I'm slightly concerned with how new they might >> be, how reliable it would be as well as their QA/bugfix history. Also 24x4 >> support and hardware replacement. Everything in our datacenter currently >> has a 2 or 4 hour cisco contract on it and critical core components have a >> cold spare in inventory. >> >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on this >> solution, I was a former Dell Partner and they even pushed me to get demo >> equipment going... What's the experience with their chassis switches? >> Stability? Configuration sanity? What do people like? What do people >> hate? >> >> Juniper. What do people like? What do people hate? Have the Layer 2 >> issues of historical age gone away? Is the config still xml ish? It has >> been about 5 years since I worked with anything Juniper. >> >> Extreme networks. I know very little about them historically. What is >> good, what is bad? Is the config sane? >> >> I would be happy to compile any information I find, as well as our >> sanitized internal conclusions. On and off list responses welcome. >> >> If there is another vendor anyone would suggest, please add them to the >> list with similarly asked questions. >> >> Thanks! >> >> Blake**** >> >> >> >> **** >> >> ** ** >> >> -- **** >> >> Phil Fagan**** >> >> Denver, CO**** >> >> 970-480-7618**** >> > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ------------------------------ Message: 3 Date: Tue, 18 Jun 2013 20:14:18 -0600 From: Phil Fagan To: Mike Hale Cc: "NANOG \(nanog at nanog.org\)" Subject: Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... Message-ID: Content-Type: text/plain; charset=UTF-8 Mike brings up a good point though; the effort, cost, and risk of introducing a new CLI to an environment sometimes is masked until you really need to dig in and work through outages. Familiarity with a codebase or at least with how the code "thinks" should go a long way when deciding what to put in your racks. Of course, how do you quantify that? On Tue, Jun 18, 2013 at 7:27 PM, Mike Hale wrote: > I'm exact opposite of Phil. I love IOS and hate JunOS....for that > single reason, I'm really against buying Juniper in our shop for > pretty much anything. :) > > Still, to be fair, the hardware seems to be really, really stable and > well built. I don't think we've had a failure across our Junipers in > the short time I've been with my day job. > > As far as support goes...the only time we had issues with our Nexus > gear I was actually really, really disappointed with Cisco. We were > upgrading our firmware, ran into some major issues with VPC and HSRP > due some firmware changes, and the Tac engineer we got sucked > *massive* lemons. When I call Tac with a situation like this, I > expect someone who can code a working config from scratch based on the > old config, not someone who's going to sit there scratching his head, > running useless packet captures, and being silent when we ask > questions. *sigh* > > /rant off > > On Tue, Jun 18, 2013 at 6:11 PM, Phil Fagan wrote: > > I've had nothing but good luck with Juniper support and well with Cisco > you > > pay for support too. I will say Arista support was great, however, I'm > > still hesitant to put them in full production; but I think that is lack > of > > experience with them speaking. > > > > Do the bake off in your lab and let'm run! > > > > > > On Tue, Jun 18, 2013 at 6:31 PM, Blake Pfankuch - Mailing List < > > blake.mailinglist at pfankuch.me> wrote: > > > >> Let me also clarify, Price per port is not the final deciding factor. > >> We are looking much more at a combination of daily operational sanity, > >> troubleshooting features, operational feature set, vendor support > quality > >> and price.**** > >> > >> ** ** > >> > >> Support is absolute key. When we need help, we need help quickly and > >> knowledgeable support. The name checkpoint comes to mind when I think > of > >> something I DON?T want for support quality. It also causes nausea?**** > >> > >> ** ** > >> > >> Thanks,**** > >> > >> ** ** > >> > >> Blake**** > >> > >> ** ** > >> > >> *From:* Phil Fagan [mailto:philfagan at gmail.com] > >> *Sent:* Tuesday, June 18, 2013 6:08 PM > >> *To:* Blake Pfankuch - Mailing List > >> *Cc:* NANOG (nanog at nanog.org) > >> *Subject:* Re: Network Vendor suggestions/reviews, Arista Networks, Dell > >> Force10, Juniper, Extreme Networks etc...**** > >> > >> ** ** > >> > >> I love JUNOS, don't really care for IOS. I really trust Cisco and > >> Juniper's hardware, with that being said Arista is your best bet for > >> cheapest port. I've only seen Arista in lab, not in the wild yet so I > can't > >> speak for how I would trust them. You mention getting bit by single > sups, I > >> believe as of late Arista has had issue with OSPF failover time between > >> dual-sups in HA setups.**** > >> > >> ** ** > >> > >> I used to have a Dell laptop....but I'm sure their great too. In the end > >> for me I only trust Cisco or Juniper. I've been burnt by Foundry and am > >> waiting to on Arista. **** > >> > >> ** ** > >> > >> On Tue, Jun 18, 2013 at 5:53 PM, Blake Pfankuch - Mailing List < > >> blake.mailinglist at pfankuch.me> wrote:**** > >> > >> Howdy, > >> I have been working on a proposal for the organization I > >> work for to move into the 10gbit datacenter. We have a small datacenter > >> currently of about 1000 ports of 1gbit. We have traditionally been a > full > >> Cisco shop, however I was asked to do a price comparison as well as > >> features with other major alternative vendors. I was also asked to do > some > >> digging as far as what "the real world" thinks about these possible > vendors. > >> > >> We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > >> 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing > 10gbit > >> to a very specialized implementation. With all of our technology, we > try > >> to not be bleeding edge, but oozing edge. We need 5 9's or more of > uptime > >> yearly so stability is preferable to cool features. We currently have > >> single supervisors in all of our switches (not my decision) and it has > bit > >> us recently. Everything we are looking at needs to support NSF/SSO/VSS > of > >> some kind. > >> > >> What we have been looking to replace it with in Cisco world is Nexus > 7004 > >> Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access > as > >> well as 2200 Fabric Extenders within our Dell Blade Chassis. > Realistically > >> we will be under 800 ports of 10gbit (excluding Blades) which puts us > in a > >> tough spot from what I can find. Currently everything we have is EOR, > >> however TOR would make more sense allowing us to switch to SFP+ twinax > >> connectivity to servers. > >> > >> With this in mind, I have a few questions... > >> > >> It was mandated that I look at a company "Arista Networks" and > investigate > >> possible options. I had not heard much about them, so I look to the > >> experts. Pro's and Con's? Real world experience? Looks to me they > have a > >> lot of cool features, but I'm slightly concerned with how new they might > >> be, how reliable it would be as well as their QA/bugfix history. Also > 24x4 > >> support and hardware replacement. Everything in our datacenter > currently > >> has a 2 or 4 hour cisco contract on it and critical core components > have a > >> cold spare in inventory. > >> > >> Dell Force 10... I know Dell tries to get you to drink the Koolaid on > this > >> solution, I was a former Dell Partner and they even pushed me to get > demo > >> equipment going... What's the experience with their chassis switches? > >> Stability? Configuration sanity? What do people like? What do people > >> hate? > >> > >> Juniper. What do people like? What do people hate? Have the Layer 2 > >> issues of historical age gone away? Is the config still xml ish? It > has > >> been about 5 years since I worked with anything Juniper. > >> > >> Extreme networks. I know very little about them historically. What is > >> good, what is bad? Is the config sane? > >> > >> I would be happy to compile any information I find, as well as our > >> sanitized internal conclusions. On and off list responses welcome. > >> > >> If there is another vendor anyone would suggest, please add them to the > >> list with similarly asked questions. > >> > >> Thanks! > >> > >> Blake**** > >> > >> > >> > >> **** > >> > >> ** ** > >> > >> -- **** > >> > >> Phil Fagan**** > >> > >> Denver, CO**** > >> > >> 970-480-7618**** > >> > > > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > -- Phil Fagan Denver, CO 970-480-7618 ------------------------------ Message: 4 Date: Tue, 18 Jun 2013 20:17:51 -0700 From: Brent Jones To: Blake Pfankuch - Mailing List Cc: "NANOG \(nanog at nanog.org\)" Subject: Re: Network Vendor suggestions/reviews, Arista Networks, Dell Force10, Juniper, Extreme Networks etc... Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 18, 2013 at 4:53 PM, Blake Pfankuch - Mailing List < blake.mailinglist at pfankuch.me> wrote: > Howdy, > I have been working on a proposal for the organization I > work for to move into the 10gbit datacenter. We have a small datacenter > currently of about 1000 ports of 1gbit. We have traditionally been a full > Cisco shop, however I was asked to do a price comparison as well as > features with other major alternative vendors. I was also asked to do some > digging as far as what "the real world" thinks about these possible vendors. > > We currently have 2 Cisco 6509's with 8 48 port cards Sup 3BXL, 2 Cisco > 4506 with 5x 48 port card and Sup V's and 2 4900M switches providing 10gbit > to a very specialized implementation. With all of our technology, we try > to not be bleeding edge, but oozing edge. We need 5 9's or more of uptime > yearly so stability is preferable to cool features. We currently have > single supervisors in all of our switches (not my decision) and it has bit > us recently. Everything we are looking at needs to support NSF/SSO/VSS of > some kind. > > What we have been looking to replace it with in Cisco world is Nexus 7004 > Core and Nexus 5596UP with 2200 series Fabric extenders for Dist/Access as > well as 2200 Fabric Extenders within our Dell Blade Chassis. Realistically > we will be under 800 ports of 10gbit (excluding Blades) which puts us in a > tough spot from what I can find. Currently everything we have is EOR, > however TOR would make more sense allowing us to switch to SFP+ twinax > connectivity to servers. > > With this in mind, I have a few questions... > > It was mandated that I look at a company "Arista Networks" and investigate > possible options. I had not heard much about them, so I look to the > experts. Pro's and Con's? Real world experience? Looks to me they have a > lot of cool features, but I'm slightly concerned with how new they might > be, how reliable it would be as well as their QA/bugfix history. Also 24x4 > support and hardware replacement. Everything in our datacenter currently > has a 2 or 4 hour cisco contract on it and critical core components have a > cold spare in inventory. > > Dell Force 10... I know Dell tries to get you to drink the Koolaid on this > solution, I was a former Dell Partner and they even pushed me to get demo > equipment going... What's the experience with their chassis switches? > Stability? Configuration sanity? What do people like? What do people > hate? > > Juniper. What do people like? What do people hate? Have the Layer 2 > issues of historical age gone away? Is the config still xml ish? It has > been about 5 years since I worked with anything Juniper. > > Extreme networks. I know very little about them historically. What is > good, what is bad? Is the config sane? > > I would be happy to compile any information I find, as well as our > sanitized internal conclusions. On and off list responses welcome. > > If there is another vendor anyone would suggest, please add them to the > list with similarly asked questions. > > Thanks! > > Blake > Coming from first hand experience, all network equipment vendors have strengths and weaknesses. Personally, I prefer the Junos CLI and ecosystem, but it is a learning curve, especially with a larger team who may not be familiar with it. But I found once I grasped the "Junos way", I'm significantly more productive with less errors, and "commit confirmed" is much better than Cisco comparable rollback methods. Juniper also offers several methods for automation: Junoscript/SLAX, Netconf, and now Puppet integration. I also have experience with Force10, and minor experience with Arista, both good vendors. They will be immieditely familiar to your team, since they use the same commands mostly. I find Juniper's virtual chassis to be among the better stacking technologies, but everyone has their own take. Force10 and Arista do really good multi-chassis LAG, as well as the Juniper QFX lineup. These days, vendors are really competitive on pricing and offerings, so you really can't go wrong :) -- Brent Jones brent at brentrjones.com End of NANOG Digest, Vol 65, Issue 74 ************************************* This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From blueneon at gmail.com Wed Jun 19 17:04:17 2013 From: blueneon at gmail.com (Tom Morris) Date: Wed, 19 Jun 2013 13:04:17 -0400 Subject: If you thought you had wire management issues in your facilities... Message-ID: Radio Free Asia, Washington DC. https://www.facebook.com/photo.php?fbid=485799631503312&set=gm.536342003094118&type=1 Just remember, you're probably in better shape than them. If you look carefully on the right side you can see where some cables were left abandoned in place because they'd become unremovable from that giant set of dreadlocks. -- -- Tom Morris, KG4CYX Mad Scientist For Hire Chairman, South Florida Tropical Hamboree / Miami Hamfest Engineer, WRGP Radiate FM, Florida International University 786-228-7087 151.820 Megacycles From web at typo.org Wed Jun 19 19:04:40 2013 From: web at typo.org (Wayne E Bouchard) Date: Wed, 19 Jun 2013 12:04:40 -0700 Subject: If you thought you had wire management issues in your facilities... In-Reply-To: References: Message-ID: <20130619190440.GA31919@wakko.typo.org> *shrug* Enh.. Looks pretty much like any colo site I've ever been in that's been maintained by nothing but remote hands for the previous 4 years... (equinix, are you paying attention?) -Wayne On Wed, Jun 19, 2013 at 01:04:17PM -0400, Tom Morris wrote: > Radio Free Asia, Washington DC. > https://www.facebook.com/photo.php?fbid=485799631503312&set=gm.536342003094118&type=1 > > Just remember, you're probably in better shape than them. If you look > carefully on the right side you can see where some cables were left > abandoned in place because they'd become unremovable from that giant set of > dreadlocks. > > -- > -- > Tom Morris, KG4CYX > Mad Scientist For Hire > Chairman, South Florida Tropical Hamboree / Miami Hamfest > Engineer, WRGP Radiate FM, Florida International University > 786-228-7087 > 151.820 Megacycles --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From george.herbert at gmail.com Wed Jun 19 21:08:03 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 19 Jun 2013 14:08:03 -0700 Subject: If you thought you had wire management issues in your facilities... In-Reply-To: References: Message-ID: That's nothing. I was in a business office colo facility in San Jose in the 2001 timeframe, that had a (as I recall) 12-rack long patch panel setup for the 2 or 3 floors they occupied. All the phones and LANs used the same panels. They'd used red cable for everything. There was no - zero - cable management. There was a literally hand-deep (tip of my fingers to my wrist) spaghetti mess of wire from side to side, top to bottom, across the whole set of racks. Going in every direction. No cable in the entire room had a label on either end. The LAN switches didn't properly handle spanning tree, so if you looped it, under the tangle of wires the whole room's switches would all start blinking in unison, which was your sign to unplug what you just plugged in and figure out what went wrong. I walked in, examined the situation, went to Frys, purchased green and blue cables (for phone and net, respectively, did my new switch, gateway, and phone hookup, labeled both ends of all my cables, and fled. New owners took over as we were leaving for our permanent office six months later. They had a crew in to rewire it. I walked in and was pulling my switch and gateway out, and they commented that mine were the only properly done cables, and profusely thanked us for giving them at least a few ports they could identify both ends of... On Wed, Jun 19, 2013 at 10:04 AM, Tom Morris wrote: > Radio Free Asia, Washington DC. > > https://www.facebook.com/photo.php?fbid=485799631503312&set=gm.536342003094118&type=1 > > Just remember, you're probably in better shape than them. If you look > carefully on the right side you can see where some cables were left > abandoned in place because they'd become unremovable from that giant set of > dreadlocks. > > -- > -- > Tom Morris, KG4CYX > Mad Scientist For Hire > Chairman, South Florida Tropical Hamboree / Miami Hamfest > Engineer, WRGP Radiate FM, Florida International University > 786-228-7087 > 151.820 Megacycles > -- -george william herbert george.herbert at gmail.com From randy at psg.com Wed Jun 19 22:14:44 2013 From: randy at psg.com (Randy Bush) Date: Thu, 20 Jun 2013 07:14:44 +0900 Subject: net neutrality and peering wars continue Message-ID: good article by Stacey Higginbotham http://gigaom.com/2013/06/19/peering-pressure-the-secret-battle-to-control-the-future-of-the-internet/ From ren.provo at gmail.com Wed Jun 19 22:59:13 2013 From: ren.provo at gmail.com (Ren Provo) Date: Wed, 19 Jun 2013 18:59:13 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: Message-ID: Even better by Verizon - http://publicpolicy.verizon.com/blog/entry/unbalanced-peering-and-the-real-story-behind-the-verizon-cogent-dispute Some may recognize the name of the author for the WSJ article given she attended NANOG in Orlando - http://online.wsj.com/article_email/SB10001424127887323836504578553170167992666-lMyQjAxMTAzMDEwOTExNDkyWj.html On Wed, Jun 19, 2013 at 6:14 PM, Randy Bush wrote: > good article by Stacey Higginbotham > > http://gigaom.com/2013/06/19/peering-pressure-the-secret-battle-to-control-the-future-of-the-internet/ > From randy at psg.com Wed Jun 19 23:03:27 2013 From: randy at psg.com (Randy Bush) Date: Thu, 20 Jun 2013 08:03:27 +0900 Subject: net neutrality and peering wars continue In-Reply-To: References: Message-ID: > Even better by Verizon - > http://publicpolicy.verizon.com/blog/entry/unbalanced-peering-and-the-real-story-behind-the-verizon-cogent-dispute > > Some may recognize the name of the author for the WSJ article given > she attended NANOG in Orlando - > http://online.wsj.com/article_email/SB10001424127887323836504578553170167992666-lMyQjAxMTAzMDEwOTExNDkyWj.html >> >> http://gigaom.com/2013/06/19/peering-pressure-the-secret-battle-to-control-the-future-of-the-internet/ as someone who does not really buy the balanced traffic story, some are eyeballs and some are eye candy and that's just life, seems like a lot of words to justify various attempts at control, higgenbottom's point. randy From ikiris at gmail.com Wed Jun 19 23:12:10 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 19 Jun 2013 18:12:10 -0500 Subject: net neutrality and peering wars continue In-Reply-To: References: Message-ID: Or alternately: Verizon wishes money to accept data it requested from other vendors, film at 11. It's all in the application of the angular momentum... -Blake On Wed, Jun 19, 2013 at 6:03 PM, Randy Bush wrote: > > Even better by Verizon - > > > http://publicpolicy.verizon.com/blog/entry/unbalanced-peering-and-the-real-story-behind-the-verizon-cogent-dispute > > > > Some may recognize the name of the author for the WSJ article given > > she attended NANOG in Orlando - > > > http://online.wsj.com/article_email/SB10001424127887323836504578553170167992666-lMyQjAxMTAzMDEwOTExNDkyWj.html > >> > >> > http://gigaom.com/2013/06/19/peering-pressure-the-secret-battle-to-control-the-future-of-the-internet/ > > as someone who does not really buy the balanced traffic story, some are > eyeballs and some are eye candy and that's just life, seems like a lot > of words to justify various attempts at control, higgenbottom's point. > > randy > > From bicknell at ufp.org Wed Jun 19 23:39:48 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Jun 2013 18:39:48 -0500 Subject: net neutrality and peering wars continue In-Reply-To: References: Message-ID: <09F4B042-43B1-4922-8D64-9A506D3425AA@ufp.org> On Jun 19, 2013, at 6:03 PM, Randy Bush wrote: > as someone who does not really buy the balanced traffic story, some are > eyeballs and some are eye candy and that's just life, seems like a lot > of words to justify various attempts at control, higgenbottom's point. I agree with Randy, but will go one further. Requiring a balanced ratio is extremely bad business because it incentivizes your competitors to compete in your home market. You're a content provider who can't meet ratio requirements? You go into the eyeball space, perhaps by purchasing an eyeball provider, or creating one. Google Fiber, anyone? Having a requirement that's basically "you must compete with me on all the products I sell" is a really dumb peering policy, but that's how the big guys use ratio. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Wed Jun 19 23:42:55 2013 From: bill at herrin.us (William Herrin) Date: Wed, 19 Jun 2013 19:42:55 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: Message-ID: On Wed, Jun 19, 2013 at 7:12 PM, Blake Dunlap wrote: > Verizon wishes money to accept data it requested from other vendors, film > at 11. The phrase you're looking for is, "double billing." Same byte, two payers. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dorian at blackrose.org Wed Jun 19 23:44:15 2013 From: dorian at blackrose.org (Dorian Kim) Date: Wed, 19 Jun 2013 19:44:15 -0400 Subject: net neutrality and peering wars continue In-Reply-To: <09F4B042-43B1-4922-8D64-9A506D3425AA@ufp.org> References: <09F4B042-43B1-4922-8D64-9A506D3425AA@ufp.org> Message-ID: <20130619234415.GB13338@blackrose.org> On Wed, Jun 19, 2013 at 06:39:48PM -0500, Leo Bicknell wrote: > > On Jun 19, 2013, at 6:03 PM, Randy Bush wrote: > > > as someone who does not really buy the balanced traffic story, some are > > eyeballs and some are eye candy and that's just life, seems like a lot > > of words to justify various attempts at control, higgenbottom's point. > > I agree with Randy, but will go one further. > > Requiring a balanced ratio is extremely bad business because it incentivizes your competitors to compete in your home market. > > You're a content provider who can't meet ratio requirements? You go into the eyeball space, perhaps by purchasing an eyeball provider, or creating one. > > Google Fiber, anyone? > > Having a requirement that's basically "you must compete with me on all the products I sell" is a really dumb peering policy, but that's how the big guys use ratio. At the end of the day though, this comes down to a clash of business models and the reason why it's a public spectacle, and of public policy interest is due to the wide spread legacy of monopoly driven public investment in the last mile infrastructure. -dorian From jfesler at gigo.com Wed Jun 19 23:55:01 2013 From: jfesler at gigo.com (Jason Fesler) Date: Wed, 19 Jun 2013 16:55:01 -0700 Subject: Wiki for people doing IPv6-only testing Message-ID: On a recent IPv6 providers call, there was a desire for participants to share information with each other on what works and what breaks in an IPv6-only environment. I offered to set that up. It was further suggested I should share this with more than just that small community; to anyone who might be doing work to test out IPv6-only scenarios. http://wiki.test-ipv6.com This is distinct from ARIN's wiki in so far that this is less about being a general IPv6 resource and more about the IPv6-only scenario resource. Contributions are welcome, but we're requiring folks to sign up before contributing to keep the spam down. -jfesler at gigo.com / jfesler at test-ipv6.com From web at typo.org Thu Jun 20 00:02:49 2013 From: web at typo.org (Wayne E Bouchard) Date: Wed, 19 Jun 2013 17:02:49 -0700 Subject: net neutrality and peering wars continue In-Reply-To: <20130619234415.GB13338@blackrose.org> References: <09F4B042-43B1-4922-8D64-9A506D3425AA@ufp.org> <20130619234415.GB13338@blackrose.org> Message-ID: <20130620000249.GA32794@wakko.typo.org> On Wed, Jun 19, 2013 at 07:44:15PM -0400, Dorian Kim wrote: > On Wed, Jun 19, 2013 at 06:39:48PM -0500, Leo Bicknell wrote: > > > > On Jun 19, 2013, at 6:03 PM, Randy Bush wrote: > > > > > as someone who does not really buy the balanced traffic story, some are > > > eyeballs and some are eye candy and that's just life, seems like a lot > > > of words to justify various attempts at control, higgenbottom's point. > > > > I agree with Randy, but will go one further. > > > > Requiring a balanced ratio is extremely bad business because it incentivizes your competitors to compete in your home market. > > > > You're a content provider who can't meet ratio requirements? You go into the eyeball space, perhaps by purchasing an eyeball provider, or creating one. > > > > Google Fiber, anyone? > > > > Having a requirement that's basically "you must compete with me on all the products I sell" is a really dumb peering policy, but that's how the big guys use ratio. > > At the end of the day though, this comes down to a clash of business models and the > reason why it's a public spectacle, and of public policy interest is due to the > wide spread legacy of monopoly driven public investment in the last mile > infrastructure. > > -dorian At the risk of inflaming passions, I'll share my opinion on this whole topic and then disappear back into my cubicle. For my part, peering ratios never made sense anyway except in the pure transit world. I mean, content providers are being punished by eyeball networks because the traffic is one way. Well, DUH! But everyone overlooks two simple facts: 1) Web pages don't generate traffic, users do. Content sits there taking up disk space until a user comes to grab it. (Not quite the case with data miners such as Google, but you get the idea.) 2) Users would not generate traffic unless there were content they want to access. Whether that is web pages, commerce pages such as Amazon or ebay, streams, or peer-to-peer game traffic, if there's nothing interesting, there's nothing happening. So both sides have an equal claim to "it's all your fault" and one seeking to punish the other is completely moronic. Traffic interchange is good. Period. It puts the users closer to the content and the content closer to the user and everyone wins. So I never once understood why everyone was all fired up about ratios. It just never made any sense to me from the get-go. To have government get into this will certainly not help the problem, it will just make it a hundred times worse. Remember the old saying that the eight most terrifying words in the English language are, "I'm from the government. I'm here to help." and boy will they try to "help". You'll be lucky if you as a company can keep still your doors open after they get done "helping" you. Anyhow, just my two bits. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From David.Siegel at Level3.com Thu Jun 20 00:26:56 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 20 Jun 2013 00:26:56 +0000 Subject: net neutrality and peering wars continue In-Reply-To: <20130620000249.GA32794@wakko.typo.org> References: <09F4B042-43B1-4922-8D64-9A506D3425AA@ufp.org> <20130619234415.GB13338@blackrose.org> <20130620000249.GA32794@wakko.typo.org> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC04868AF04@USIDCWVEMBX10.corp.global.level3.com> Hi Wayne, Another important point not to be missed is that these days, thanks to CDN technology, a heavy inbound ratio does not necessarily indicate a high cost burden like it did pre-CDN tech. Even more ironically, the unwillingness of a peer to upgrade connections due to the ratio excuse results in the CDN having to source traffic from non-optimal locations just to get the bits into the other network, thereby increasing the cost burden of the broadband network. If it were true that these issues were only about cost there would be plenty of common ground to negotiate acceptable peering terms, don't you think? Dave -----Original Message----- From: Wayne E Bouchard [mailto:web at typo.org] Sent: Wednesday, June 19, 2013 6:03 PM To: Dorian Kim Cc: North American Network Operators' Group Subject: Re: net neutrality and peering wars continue On Wed, Jun 19, 2013 at 07:44:15PM -0400, Dorian Kim wrote: > On Wed, Jun 19, 2013 at 06:39:48PM -0500, Leo Bicknell wrote: > > > > On Jun 19, 2013, at 6:03 PM, Randy Bush wrote: > > > > > as someone who does not really buy the balanced traffic story, > > > some are eyeballs and some are eye candy and that's just life, > > > seems like a lot of words to justify various attempts at control, higgenbottom's point. > > > > I agree with Randy, but will go one further. > > > > Requiring a balanced ratio is extremely bad business because it incentivizes your competitors to compete in your home market. > > > > You're a content provider who can't meet ratio requirements? You go into the eyeball space, perhaps by purchasing an eyeball provider, or creating one. > > > > Google Fiber, anyone? > > > > Having a requirement that's basically "you must compete with me on all the products I sell" is a really dumb peering policy, but that's how the big guys use ratio. > > At the end of the day though, this comes down to a clash of business > models and the reason why it's a public spectacle, and of public > policy interest is due to the wide spread legacy of monopoly driven > public investment in the last mile infrastructure. > > -dorian At the risk of inflaming passions, I'll share my opinion on this whole topic and then disappear back into my cubicle. For my part, peering ratios never made sense anyway except in the pure transit world. I mean, content providers are being punished by eyeball networks because the traffic is one way. Well, DUH! But everyone overlooks two simple facts: 1) Web pages don't generate traffic, users do. Content sits there taking up disk space until a user comes to grab it. (Not quite the case with data miners such as Google, but you get the idea.) 2) Users would not generate traffic unless there were content they want to access. Whether that is web pages, commerce pages such as Amazon or ebay, streams, or peer-to-peer game traffic, if there's nothing interesting, there's nothing happening. So both sides have an equal claim to "it's all your fault" and one seeking to punish the other is completely moronic. Traffic interchange is good. Period. It puts the users closer to the content and the content closer to the user and everyone wins. So I never once understood why everyone was all fired up about ratios. It just never made any sense to me from the get-go. To have government get into this will certainly not help the problem, it will just make it a hundred times worse. Remember the old saying that the eight most terrifying words in the English language are, "I'm from the government. I'm here to help." and boy will they try to "help". You'll be lucky if you as a company can keep still your doors open after they get done "helping" you. Anyhow, just my two bits. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From bensons at queuefull.net Thu Jun 20 00:31:29 2013 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 19 Jun 2013 20:31:29 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: Message-ID: <51C24D61.6000104@queuefull.net> On 2013-06-19 7:03 PM, Randy Bush wrote: > as someone who does not really buy the balanced traffic story, some > are eyeballs and some are eye candy and that's just life, seems like a > lot of words to justify various attempts at control, higgenbottom's > point. randy What do you mean "not really buy the balanced traffic story"? Ratio can matter when routing is asymmetric. (If costs can be approximated as distance x volume, forwarding hot-potato places a higher burden on the recipient...) And we've basically designed protocols that route asymmetrically by default. Measuring traffic ratios is the laziest solution to this problem, and thus the one we should've expected. Cheers, -Benson From bicknell at ufp.org Thu Jun 20 00:46:38 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Jun 2013 19:46:38 -0500 Subject: net neutrality and peering wars continue In-Reply-To: <51C24D61.6000104@queuefull.net> References: <51C24D61.6000104@queuefull.net> Message-ID: On Jun 19, 2013, at 7:31 PM, Benson Schliesser wrote: > What do you mean "not really buy the balanced traffic story"? Ratio can matter when routing is asymmetric. (If costs can be approximated as distance x volume, forwarding hot-potato places a higher burden on the recipient...) And we've basically designed protocols that route asymmetrically by default. Measuring traffic ratios is the laziest solution to this problem, and thus the one we should've expected. That was a great argument in 1993, and was in fact largely true in system that existed at that time. However today what you describe no longer really makes any sense. While it is technically true that the protocols favor asymmetric routing, your theory is based on the idea that a content site exists in one location, and does not want to optimize the user experience. That really doesn't describe any of the large sources/sinks today. When you access "www.majorwebsite.com" today a lot of science (hi Akamai!) goes into directing users to servers that are close to them, trying to optimize things like RTT to improve performance. Content providers are generally doing the exact opposite of hot potato, they are cold potatoing entire racks into data centers close to the eyeballs at great cost to improve performance. But to the extent a few people still have traffic patterns where they can asymmetrically route a large amount of traffic, the situation has also changed. In 1993 this was somewhat hard to detect, report, and share. Today any major provider has a netflow infrastructure where they can watch this phenomena in real time, no one is pulling the wool over their eyes. There are also plenty of fixes, for instance providers can exchange MED's to cold potato traffic, or could charge a sliding fee to recover the supposed differences. The denial of peering also makes bad business sense from a dollars perspective. Let's say someone is asymmetric routing and causing an eyeball network extra long haul transport. Today they deny them peering due to ratio. The chance that the content network will buy full-priced transit from the eyeball network? Zero. It doesn't happen. Instead they will buy from some other provider who already has peering, and dump off the traffic. So the eyeball network still gets the traffic, gets it hidden in a larger traffic flow where they can't complain if it comes from one place, and get $0 for the trouble. A much better business arrangement would be to tie a sliding fee to the ratio. Peering up to 2:1 is free. Up to 4:1 is $0.50/meg, up to 6:1 is $1.00/meg, up to 10:1 is $1.50 a meg. Eyeball network gets to recover their long haul transport costs, it's cheaper to the CDN than buying transit, and they can maintain a direct relationship where they can keep up with each other using things like Netflow reporting. While I'm sure there's some network somewhere that does a sane paid peering product like this, I've sure never seen it. For almost all networks it's a pure binary decision, free peering or full priced transit. Quite frankly, if the people with MBA's understood the technical aspects of peering all of the current peering policies would be thrown out, and most of the peering coordinators fired. "Settlement" is a dirty word in the IP realm, but the basic concept makes sense. What was a bad idea was the telco idea of accounting for every call, every bit of data. Remember AT&T's 900 page iPhone bills when they first came out? Doing a settlement based on detailed traffic accounting would be stupid, but doing settlements based on traffic levels, and bit-mile costs would make a lot of sense, with balanced traffic being free. Oh, and guess what, if people interconnected between CDN and eyeball networks better the users would see better experiences, and might be more likely to be satisfied with their service, and thus buy more. It's good business to have a product people like. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bensons at queuefull.net Thu Jun 20 02:21:57 2013 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 19 Jun 2013 22:21:57 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> Message-ID: <51C26745.6010003@queuefull.net> On 2013-06-19 8:46 PM, Leo Bicknell wrote: > > That was a great argument in 1993, and was in fact largely true in system that existed at that time. However today what you describe no longer really makes any sense. > > While it is technically true that the protocols favor asymmetric routing, your theory is based on the idea that a content site exists in one location, and does not want to optimize the user experience. > ... > > A much better business arrangement would be to tie a sliding fee to the ratio. Peering up to 2:1 is free. Up to 4:1 is $0.50/meg, up to 6:1 is $1.00/meg, up to 10:1 is $1.50 a meg. Eyeball network gets to recover their long haul transport costs, it's cheaper to the CDN than buying transit, Agreed that CDN, traffic steering, etc, changes the impact of routing protocols. But I think you made my point. The sending peer (or their customer) has more control over cost. And we don't really have a good proxy for evaluating relative burdens. That's not to suggest that peering disputes are really about technical capabilities. Nor fairness, even... Cheers, -Benson From David.Siegel at Level3.com Thu Jun 20 03:41:14 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 20 Jun 2013 03:41:14 +0000 Subject: net neutrality and peering wars continue In-Reply-To: <51C26745.6010003@queuefull.net> References: <51C24D61.6000104@queuefull.net> , <51C26745.6010003@queuefull.net> Message-ID: <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> Well, with net flow Analytics, it's not really the case that we don't have a way of evaluating the relative burdens. Every major net flow Analytics vendor is implementing some type of distance measurement capability so that each party can calculate not only how much traffic they carry for each peer, but how far. Dave -- 520.229.7627 cell On Jun 19, 2013, at 8:23 PM, "Benson Schliesser" wrote: > > On 2013-06-19 8:46 PM, Leo Bicknell wrote: >> >> That was a great argument in 1993, and was in fact largely true in system that existed at that time. However today what you describe no longer really makes any sense. >> >> While it is technically true that the protocols favor asymmetric routing, your theory is based on the idea that a content site exists in one location, and does not want to optimize the user experience. >> ... >> >> A much better business arrangement would be to tie a sliding fee to the ratio. Peering up to 2:1 is free. Up to 4:1 is $0.50/meg, up to 6:1 is $1.00/meg, up to 10:1 is $1.50 a meg. Eyeball network gets to recover their long haul transport costs, it's cheaper to the CDN than buying transit, > > Agreed that CDN, traffic steering, etc, changes the impact of routing protocols. But I think you made my point. The sending peer (or their customer) has more control over cost. And we don't really have a good proxy for evaluating relative burdens. > > That's not to suggest that peering disputes are really about technical capabilities. Nor fairness, even... > > Cheers, > -Benson > > > From zaid at zaidali.com Thu Jun 20 03:42:29 2013 From: zaid at zaidali.com (Zaid Ali Kahn) Date: Wed, 19 Jun 2013 20:42:29 -0700 Subject: Need help in flushing DNS Message-ID: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> Reaching out to DNS operators around the globe. Linkedin.com has had some issues with DNS and would like DNS operators to flush their DNS. If you see www.linkedin.com resolving NS to ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. Any other info please reach out to me off-list. Zaid From effinjdent at gmail.com Thu Jun 20 04:02:51 2013 From: effinjdent at gmail.com (Jerry Dent) Date: Wed, 19 Jun 2013 23:02:51 -0500 Subject: net neutrality and peering wars continue In-Reply-To: <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> Message-ID: Let's not kid ourselves, the transit providers are just as greedy. Even the tier 2 ones (minus HE). My favorite is when they turn down your request because you have an out of band circuit in a remote pop with them. As if we're stuffing 800G of traffic down a 1G circuit that's never seen 100K of traffic on it. Or the "It would jeopardize our peering agreements with other providers" ... followed by a call from one of their sales guys the next day. On Wed, Jun 19, 2013 at 10:41 PM, Siegel, David wrote: > Well, with net flow Analytics, it's not really the case that we don't have > a way of evaluating the relative burdens. Every major net flow Analytics > vendor is implementing some type of distance measurement capability so that > each party can calculate not only how much traffic they carry for each > peer, but how far. > > Dave > > -- > 520.229.7627 cell > > > On Jun 19, 2013, at 8:23 PM, "Benson Schliesser" > wrote: > > > > > On 2013-06-19 8:46 PM, Leo Bicknell wrote: > >> > >> That was a great argument in 1993, and was in fact largely true in > system that existed at that time. However today what you describe no > longer really makes any sense. > >> > >> While it is technically true that the protocols favor asymmetric > routing, your theory is based on the idea that a content site exists in one > location, and does not want to optimize the user experience. > >> ... > >> > >> A much better business arrangement would be to tie a sliding fee to the > ratio. Peering up to 2:1 is free. Up to 4:1 is $0.50/meg, up to 6:1 is > $1.00/meg, up to 10:1 is $1.50 a meg. Eyeball network gets to recover > their long haul transport costs, it's cheaper to the CDN than buying > transit, > > > > Agreed that CDN, traffic steering, etc, changes the impact of routing > protocols. But I think you made my point. The sending peer (or their > customer) has more control over cost. And we don't really have a good proxy > for evaluating relative burdens. > > > > That's not to suggest that peering disputes are really about technical > capabilities. Nor fairness, even... > > > > Cheers, > > -Benson > > > > > > > > From johnl at iecc.com Thu Jun 20 05:19:12 2013 From: johnl at iecc.com (John Levine) Date: 20 Jun 2013 05:19:12 -0000 Subject: Need help in flushing DNS In-Reply-To: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> Message-ID: <20130620051912.51966.qmail@joyce.lan> >Reaching out to DNS operators around the globe. Linkedin.com has had some issues with DNS >and would like DNS operators to flush their DNS. If you see www.linkedin.com resolving NS to >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > >Any other info please reach out to me off-list. While you're at it, www.usps.com, www.fidelity.com, and other well known sites have had DNS poisoning problems. When I restarted my cache, they look OK. From shortdudey123 at gmail.com Thu Jun 20 05:30:21 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 19 Jun 2013 22:30:21 -0700 Subject: Need help in flushing DNS In-Reply-To: <20130620051912.51966.qmail@joyce.lan> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Yelp is evidently also affected On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > >Reaching out to DNS operators around the globe. Linkedin.com has had some > issues with DNS > >and would like DNS operators to flush their DNS. If you see > www.linkedin.com resolving NS to > >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > > > >Any other info please reach out to me off-list. > > While you're at it, www.usps.com, www.fidelity.com, and other well > known sites have had DNS poisoning problems. When I restarted my > cache, they look OK. > > > From patrick at ianai.net Thu Jun 20 05:32:17 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 20 Jun 2013 01:32:17 -0400 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: On Jun 20, 2013, at 01:30 , Grant Ridder wrote: > Yelp is evidently also affected Not from here. If the NS or www points to 204.11.56.0/24 for a production domain/hostname, that's "bad". Yelp seems to be resolving normally for me. -- TTFN, patrick > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > >>> Reaching out to DNS operators around the globe. Linkedin.com has had some >> issues with DNS >>> and would like DNS operators to flush their DNS. If you see >> www.linkedin.com resolving NS to >>> ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. >>> >>> Any other info please reach out to me off-list. >> >> While you're at it, www.usps.com, www.fidelity.com, and other well >> known sites have had DNS poisoning problems. When I restarted my >> cache, they look OK. >> >> >> > From fergdawgster at gmail.com Thu Jun 20 05:34:44 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 19 Jun 2013 22:34:44 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Sure enough: ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;yelp.com. IN A ;; ANSWER SECTION: yelp.com. 300 IN A 204.11.56.20 ;; Query time: 143 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 20 07:33:13 2013 ;; MSG SIZE rcvd: 42 NetRange: 204.11.56.0 - 204.11.59.255 CIDR: 204.11.56.0/22 OriginAS: AS40034 NetName: CONFLUENCE-NETWORKS--TX3 NetHandle: NET-204-11-56-0-1 Parent: NET-204-0-0-0-0 NetType: Direct Allocation Comment: Hosted in Austin TX. Comment: Abuse : Comment: abuse at confluence-networks.com Comment: +1-917-386-6118 RegDate: 2012-09-24 Updated: 2012-09-24 Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 OrgName: Confluence Networks Inc OrgId: CN Address: 3rd Floor, Omar Hodge Building, Wickhams Address: Cay I, P.O. Box 362 City: Road Town StateProv: Tortola PostalCode: VG1110 Country: VG RegDate: 2011-04-07 Updated: 2011-07-05 Ref: http://whois.arin.net/rest/org/CN OrgAbuseHandle: ABUSE3065-ARIN OrgAbuseName: Abuse Admin OrgAbusePhone: +1-917-386-6118 OrgAbuseEmail: abuse at confluence-networks.com OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN OrgNOCHandle: NOCAD51-ARIN OrgNOCName: NOC Admin OrgNOCPhone: +1-415-462-7734 OrgNOCEmail: noc at confluence-networks.com OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN OrgTechHandle: TECHA29-ARIN OrgTechName: Tech Admin OrgTechPhone: +1-415-358-0858 OrgTechEmail: ipadmin at confluence-networks.com OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # - ferg On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder wrote: > Yelp is evidently also affected > > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > >> >Reaching out to DNS operators around the globe. Linkedin.com has had some >> issues with DNS >> >and would like DNS operators to flush their DNS. If you see >> www.linkedin.com resolving NS to >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. >> > >> >Any other info please reach out to me off-list. >> >> While you're at it, www.usps.com, www.fidelity.com, and other well >> known sites have had DNS poisoning problems. When I restarted my >> cache, they look OK. >> >> >> -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From tom at cloudflare.com Thu Jun 20 05:44:06 2013 From: tom at cloudflare.com (Tom Paseka) Date: Wed, 19 Jun 2013 22:44:06 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore wrote: > On Jun 20, 2013, at 01:30 , Grant Ridder wrote: > > > Yelp is evidently also affected > > Not from here. > Patrick: $ dig NS yelp.com @8.8.8.8 +short ns1620.ztomy.com. ns2620.ztomy.com. Some DNS servers have the bad records - TLD for .com is updated already. Cheers, Tom From fergdawgster at gmail.com Thu Jun 20 05:49:22 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 19 Jun 2013 22:49:22 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: > On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore wrote: > >> On Jun 20, 2013, at 01:30 , Grant Ridder wrote: >> >> > Yelp is evidently also affected >> >> Not from here. >> > > Patrick: > > $ dig NS yelp.com @8.8.8.8 +short > ns1620.ztomy.com. > ns2620.ztomy.com. > > Some DNS servers have the bad records - TLD for .com is updated already. > > Cheers, > Tom Ditto local: ; <<>> DiG 9.7.3 <<>> @[foohost] yelp.com NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20230 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;yelp.com. IN NS ;; ANSWER SECTION: yelp.com. 300 IN NS ns1620.ztomy.com. yelp.com. 300 IN NS ns2620.ztomy.com. ;; Query time: 143 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 20 07:48:06 2013 ;; MSG SIZE rcvd: 74 - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From alex.buie at frozenfeline.net Thu Jun 20 05:49:40 2013 From: alex.buie at frozenfeline.net (Alex Buie) Date: Wed, 19 Jun 2013 22:49:40 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Anyone have news/explanation about what's happening/happened? On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson wrote: > Sure enough: > > > > ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;yelp.com. IN A > > ;; ANSWER SECTION: > yelp.com. 300 IN A 204.11.56.20 > > ;; Query time: 143 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu Jun 20 07:33:13 2013 > ;; MSG SIZE rcvd: 42 > > > > > > NetRange: 204.11.56.0 - 204.11.59.255 > CIDR: 204.11.56.0/22 > OriginAS: AS40034 > NetName: CONFLUENCE-NETWORKS--TX3 > NetHandle: NET-204-11-56-0-1 > Parent: NET-204-0-0-0-0 > NetType: Direct Allocation > Comment: Hosted in Austin TX. > Comment: Abuse : > Comment: abuse at confluence-networks.com > Comment: +1-917-386-6118 > RegDate: 2012-09-24 > Updated: 2012-09-24 > Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 > > OrgName: Confluence Networks Inc > OrgId: CN > Address: 3rd Floor, Omar Hodge Building, Wickhams > Address: Cay I, P.O. Box 362 > City: Road Town > StateProv: Tortola > PostalCode: VG1110 > Country: VG > RegDate: 2011-04-07 > Updated: 2011-07-05 > Ref: http://whois.arin.net/rest/org/CN > > OrgAbuseHandle: ABUSE3065-ARIN > OrgAbuseName: Abuse Admin > OrgAbusePhone: +1-917-386-6118 > OrgAbuseEmail: abuse at confluence-networks.com > OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN > > OrgNOCHandle: NOCAD51-ARIN > OrgNOCName: NOC Admin > OrgNOCPhone: +1-415-462-7734 > OrgNOCEmail: noc at confluence-networks.com > OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN > > OrgTechHandle: TECHA29-ARIN > OrgTechName: Tech Admin > OrgTechPhone: +1-415-358-0858 > OrgTechEmail: ipadmin at confluence-networks.com > OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN > > > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at: https://www.arin.net/whois_tou.html > # > > - ferg > > > > On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder > wrote: > > > Yelp is evidently also affected > > > > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > > > >> >Reaching out to DNS operators around the globe. Linkedin.com has had > some > >> issues with DNS > >> >and would like DNS operators to flush their DNS. If you see > >> www.linkedin.com resolving NS to > >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > >> > > >> >Any other info please reach out to me off-list. > >> > >> While you're at it, www.usps.com, www.fidelity.com, and other well > >> known sites have had DNS poisoning problems. When I restarted my > >> cache, they look OK. > >> > >> > >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > From shortdudey123 at gmail.com Thu Jun 20 06:00:01 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 19 Jun 2013 23:00:01 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: The only apparent link is registration thru network solutions On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie wrote: > Anyone have news/explanation about what's happening/happened? > > > On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson >wrote: > > > Sure enough: > > > > > > > > ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;yelp.com. IN A > > > > ;; ANSWER SECTION: > > yelp.com. 300 IN A 204.11.56.20 > > > > ;; Query time: 143 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Thu Jun 20 07:33:13 2013 > > ;; MSG SIZE rcvd: 42 > > > > > > > > > > > > NetRange: 204.11.56.0 - 204.11.59.255 > > CIDR: 204.11.56.0/22 > > OriginAS: AS40034 > > NetName: CONFLUENCE-NETWORKS--TX3 > > NetHandle: NET-204-11-56-0-1 > > Parent: NET-204-0-0-0-0 > > NetType: Direct Allocation > > Comment: Hosted in Austin TX. > > Comment: Abuse : > > Comment: abuse at confluence-networks.com > > Comment: +1-917-386-6118 > > RegDate: 2012-09-24 > > Updated: 2012-09-24 > > Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 > > > > OrgName: Confluence Networks Inc > > OrgId: CN > > Address: 3rd Floor, Omar Hodge Building, Wickhams > > Address: Cay I, P.O. Box 362 > > City: Road Town > > StateProv: Tortola > > PostalCode: VG1110 > > Country: VG > > RegDate: 2011-04-07 > > Updated: 2011-07-05 > > Ref: http://whois.arin.net/rest/org/CN > > > > OrgAbuseHandle: ABUSE3065-ARIN > > OrgAbuseName: Abuse Admin > > OrgAbusePhone: +1-917-386-6118 > > OrgAbuseEmail: abuse at confluence-networks.com > > OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN > > > > OrgNOCHandle: NOCAD51-ARIN > > OrgNOCName: NOC Admin > > OrgNOCPhone: +1-415-462-7734 > > OrgNOCEmail: noc at confluence-networks.com > > OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN > > > > OrgTechHandle: TECHA29-ARIN > > OrgTechName: Tech Admin > > OrgTechPhone: +1-415-358-0858 > > OrgTechEmail: ipadmin at confluence-networks.com > > OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN > > > > > > # > > # ARIN WHOIS data and services are subject to the Terms of Use > > # available at: https://www.arin.net/whois_tou.html > > # > > > > - ferg > > > > > > > > On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder > > wrote: > > > > > Yelp is evidently also affected > > > > > > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > > > > > >> >Reaching out to DNS operators around the globe. Linkedin.com has had > > some > > >> issues with DNS > > >> >and would like DNS operators to flush their DNS. If you see > > >> www.linkedin.com resolving NS to > > >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > > >> > > > >> >Any other info please reach out to me off-list. > > >> > > >> While you're at it, www.usps.com, www.fidelity.com, and other well > > >> known sites have had DNS poisoning problems. When I restarted my > > >> cache, they look OK. > > >> > > >> > > >> > > > > > > > > -- > > "Fergie", a.k.a. Paul Ferguson > > fergdawgster(at)gmail.com > > > > > From fergdawgster at gmail.com Thu Jun 20 06:02:44 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 19 Jun 2013 23:02:44 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Hanlon's razor? Misconfiguration. Perhaps not done in malice, but I have no idea where the poison leaked in, or why. :-) - ferg On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie wrote: > Anyone have news/explanation about what's happening/happened? > > > On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson wrote: > >> Sure enough: >> >> >> >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;yelp.com. IN A >> >> ;; ANSWER SECTION: >> yelp.com. 300 IN A 204.11.56.20 >> >> ;; Query time: 143 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: Thu Jun 20 07:33:13 2013 >> ;; MSG SIZE rcvd: 42 >> >> >> >> >> >> NetRange: 204.11.56.0 - 204.11.59.255 >> CIDR: 204.11.56.0/22 >> OriginAS: AS40034 >> NetName: CONFLUENCE-NETWORKS--TX3 >> NetHandle: NET-204-11-56-0-1 >> Parent: NET-204-0-0-0-0 >> NetType: Direct Allocation >> Comment: Hosted in Austin TX. >> Comment: Abuse : >> Comment: abuse at confluence-networks.com >> Comment: +1-917-386-6118 >> RegDate: 2012-09-24 >> Updated: 2012-09-24 >> Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 >> >> OrgName: Confluence Networks Inc >> OrgId: CN >> Address: 3rd Floor, Omar Hodge Building, Wickhams >> Address: Cay I, P.O. Box 362 >> City: Road Town >> StateProv: Tortola >> PostalCode: VG1110 >> Country: VG >> RegDate: 2011-04-07 >> Updated: 2011-07-05 >> Ref: http://whois.arin.net/rest/org/CN >> >> OrgAbuseHandle: ABUSE3065-ARIN >> OrgAbuseName: Abuse Admin >> OrgAbusePhone: +1-917-386-6118 >> OrgAbuseEmail: abuse at confluence-networks.com >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN >> >> OrgNOCHandle: NOCAD51-ARIN >> OrgNOCName: NOC Admin >> OrgNOCPhone: +1-415-462-7734 >> OrgNOCEmail: noc at confluence-networks.com >> OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN >> >> OrgTechHandle: TECHA29-ARIN >> OrgTechName: Tech Admin >> OrgTechPhone: +1-415-358-0858 >> OrgTechEmail: ipadmin at confluence-networks.com >> OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN >> >> >> # >> # ARIN WHOIS data and services are subject to the Terms of Use >> # available at: https://www.arin.net/whois_tou.html >> # >> >> - ferg >> >> >> >> On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder >> wrote: >> >> > Yelp is evidently also affected >> > >> > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: >> > >> >> >Reaching out to DNS operators around the globe. Linkedin.com has had >> some >> >> issues with DNS >> >> >and would like DNS operators to flush their DNS. If you see >> >> www.linkedin.com resolving NS to >> >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. >> >> > >> >> >Any other info please reach out to me off-list. >> >> >> >> While you're at it, www.usps.com, www.fidelity.com, and other well >> >> known sites have had DNS poisoning problems. When I restarted my >> >> cache, they look OK. >> >> >> >> >> >> >> >> >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> fergdawgster(at)gmail.com >> >> -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From mysidia at gmail.com Thu Jun 20 06:23:23 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Jun 2013 01:23:23 -0500 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: On 6/20/13, Paul Ferguson wrote: > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore I think "ztomy.com" smells really bad for some reason, looks like 100% advertising; sure doesn't "appear" to be a DNS hosting provider, I sure can't imagine two major domains entering incorrect authoritative nameserver list changes on the same day... http://www.dailychanges.com/ztomy.com/#transferred-in "The domain ztomy.com was registered on November 22, 2007, and we have nameserver history going back to December 9, 2007. It is listed as a nameserver for 182,174 domains Currently displaying 50 of 1,602 domain names transferred into ztomy.com on June 19, 2013." >> wrote: >>> On Jun 20, 2013, at 01:30 , Grant Ridder >>> wrote: >>> > Yelp is evidently also affected >>> Not from here. >> Patrick: >> $ dig NS yelp.com @8.8.8.8 +short >> ns1620.ztomy.com. >> ns2620.ztomy.com. -- -JH From drc at virtualized.org Thu Jun 20 06:45:07 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 19 Jun 2013 23:45:07 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: <89B8B14E-1D20-4016-A42D-2BEE22B9E3D9@virtualized.org> On Jun 19, 2013, at 11:23 PM, Jimmy Hess wrote: > On 6/20/13, Paul Ferguson wrote: >> On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: >>> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore > I think "ztomy.com" smells really bad for some reason, looks like > 100% advertising; IIRC, Confluence Networks/ztomy pounce on expired domains to sell ads or somesuch. I seem to recall them grabbing the parent domain of name servers for ben.edu last year... Regards, -drc From andree+nanog at toonk.nl Thu Jun 20 07:31:21 2013 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 20 Jun 2013 00:31:21 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: <51C2AFC9.5060500@toonk.nl> .-- My secret spy satellite informs me that at 2013-06-19 10:34 PM Paul Ferguson wrote: > ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > ;; ANSWER SECTION: > yelp.com. 300 IN A 204.11.56.20 Interesting to see that traffic to this IP addresses is going through prolexic... I guess they're considering this as a DOS. andree at bofh:~/src$ traceroute 204.11.57.20 traceroute to 204.11.57.20 (204.11.57.20), 64 hops max, 52 byte packets 1 10.200.200.200 (10.200.200.200) 17.089 ms 13.144 ms 13.552 ms 2 67.215.89.1 (67.215.89.1) 20.963 ms 15.371 ms 17.026 ms 3 67.215.93.14 (67.215.93.14) 20.486 ms 14.458 ms 16.917 ms 4 ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145) 19.449 ms 19.375 ms 15.274 ms 5 ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242) 17.107 ms 23.272 ms 16.019 ms 6 209.200.184.34 (209.200.184.34) 14.878 ms 19.062 ms 15.776 ms 7 unknown.prolexic.com (72.52.30.126) 67.871 ms 64.376 ms 66.988 ms 8 domain.not.configured (204.11.57.20) 71.729 ms 65.830 ms 67.823 ms Reflection attacks are so yesterday... Cheers, Andree From fergdawgster at gmail.com Thu Jun 20 07:38:53 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 20 Jun 2013 00:38:53 -0700 Subject: Need help in flushing DNS In-Reply-To: <51C2AFC9.5060500@toonk.nl> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <51C2AFC9.5060500@toonk.nl> Message-ID: I have no knowledge of any DDoS -related activity involving Yelp! and Prolexic. Even if there is one, the fact that their DNS records have been poisoned has not direct relationship to any current DDoS (there isn't one that I am aware of). - ferg On Thu, Jun 20, 2013 at 12:31 AM, Andree Toonk wrote: > .-- My secret spy satellite informs me that at 2013-06-19 10:34 PM Paul > Ferguson wrote: > >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > >> ;; ANSWER SECTION: >> yelp.com. 300 IN A 204.11.56.20 > > Interesting to see that traffic to this IP addresses is going through > prolexic... > I guess they're considering this as a DOS. > > andree at bofh:~/src$ traceroute 204.11.57.20 > traceroute to 204.11.57.20 (204.11.57.20), 64 hops max, 52 byte packets > 1 10.200.200.200 (10.200.200.200) 17.089 ms 13.144 ms 13.552 ms > 2 67.215.89.1 (67.215.89.1) 20.963 ms 15.371 ms 17.026 ms > 3 67.215.93.14 (67.215.93.14) 20.486 ms 14.458 ms 16.917 ms > 4 ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145) 19.449 > ms 19.375 ms 15.274 ms > 5 ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242) 17.107 > ms 23.272 ms 16.019 ms > 6 209.200.184.34 (209.200.184.34) 14.878 ms 19.062 ms 15.776 ms > 7 unknown.prolexic.com (72.52.30.126) 67.871 ms 64.376 ms 66.988 ms > 8 domain.not.configured (204.11.57.20) 71.729 ms 65.830 ms 67.823 ms > > > Reflection attacks are so yesterday... > > Cheers, > Andree > > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From andree+nanog at toonk.nl Thu Jun 20 08:08:34 2013 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 20 Jun 2013 01:08:34 -0700 Subject: Need help in flushing DNS In-Reply-To: <51C2AFC9.5060500@toonk.nl> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <51C2AFC9.5060500@toonk.nl> Message-ID: <51C2B882.1030204@toonk.nl> .-- My secret spy satellite informs me that at 2013-06-20 12:31 AM Andree Toonk wrote: > .-- My secret spy satellite informs me that at 2013-06-19 10:34 PM Paul > Ferguson wrote: > >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > >> ;; ANSWER SECTION: >> yelp.com. 300 IN A 204.11.56.20 > > Interesting to see that traffic to this IP addresses is going through > prolexic... > I guess they're considering this as a DOS. > > andree at bofh:~/src$ traceroute 204.11.57.20 > traceroute to 204.11.57.20 (204.11.57.20), 64 hops max, 52 byte packets > 1 10.200.200.200 (10.200.200.200) 17.089 ms 13.144 ms 13.552 ms > 2 67.215.89.1 (67.215.89.1) 20.963 ms 15.371 ms 17.026 ms > 3 67.215.93.14 (67.215.93.14) 20.486 ms 14.458 ms 16.917 ms > 4 ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145) 19.449 > ms 19.375 ms 15.274 ms > 5 ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242) 17.107 > ms 23.272 ms 16.019 ms > 6 209.200.184.34 (209.200.184.34) 14.878 ms 19.062 ms 15.776 ms > 7 unknown.prolexic.com (72.52.30.126) 67.871 ms 64.376 ms 66.988 ms > 8 domain.not.configured (204.11.57.20) 71.729 ms 65.830 ms 67.823 ms Slight correction for the archives, the trace above was going to 204.11.57.20 (not 204.11.56.20) which is the IP of the NS server (ns1620.ztomy.com), which also goes through prolexic (see above) andree at bofh:~/src$ dig @a.gtld-servers.net www.craigslist.com ns ; <<>> DiG 9.8.3-P1 <<>> @a.gtld-servers.net www.craigslist.com ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52520 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.craigslist.com. IN NS ;; AUTHORITY SECTION: craigslist.com. 172800 IN NS ns1620.ztomy.com. craigslist.com. 172800 IN NS ns2620.ztomy.com. ;; ADDITIONAL SECTION: ns1620.ztomy.com. 172800 IN A 204.11.56.20 ns2620.ztomy.com. 172800 IN A 204.11.57.20 ;; Query time: 120 msec ;; SERVER: 192.5.6.30#53(192.5.6.30) ;; WHEN: Thu Jun 20 00:50:49 2013 ;; MSG SIZE rcvd: 116 This is the trace to 204.11.56.20 also via prolexic andree at bofh:~/src$ sudo tcptraceroute 204.11.56.20 80 Tracing the path to 204.11.56.20 on TCP port 80 (http), 30 hops max 1 10.200.200.200 14.840 ms 21.474 ms 13.641 ms 2 67.215.89.1 19.265 ms 13.646 ms 14.769 ms 3 67.215.93.14 15.000 ms 15.161 ms 15.159 ms 4 ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145) 15.358 ms 14.852 ms 16.432 ms 5 ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242) 13.735 ms 16.149 ms 17.957 ms 6 204.11.56.20 [open] 15.447 ms 16.897 ms 15.821 ms Btw, one more interesting detail these used to be announced as one /23. As of this week that's two /24's currently 204.11.56.0/24 (june 17) and 204.11.57.0/24 (june 19) Andree From andree+nanog at toonk.nl Thu Jun 20 08:14:27 2013 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 20 Jun 2013 01:14:27 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <51C2AFC9.5060500@toonk.nl> Message-ID: <51C2B9E3.4070500@toonk.nl> Hi, .-- My secret spy satellite informs me that at 2013-06-20 12:38 AM Paul Ferguson wrote: > I have no knowledge of any DDoS -related activity involving Yelp! and > Prolexic. Even if there is one, the fact that their DNS records have > been poisoned has not direct relationship to any current DDoS (there > isn't one that I am aware of). That's not what I was trying to say. The domains like yelp, linkedin, craigslist all incorrectly have (or had) NS record like: ns1620.ztomy.com. 172800 IN A 204.11.56.20 ns2620.ztomy.com. 172800 IN A 204.11.57.20 Traffic to these IP's is going through Prolexic (see previous mail). Thought that was interesting... Andree From list at mass-distortion.net Thu Jun 20 10:15:06 2013 From: list at mass-distortion.net (Charles Richards) Date: Thu, 20 Jun 2013 04:15:06 -0600 Subject: Need help in flushing DNS In-Reply-To: <89B8B14E-1D20-4016-A42D-2BEE22B9E3D9@virtualized.org> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <89B8B14E-1D20-4016-A42D-2BEE22B9E3D9@virtualized.org> Message-ID: <20BAEAF5-2C68-494B-908F-EFE563948B42@mass-distortion.net> I have domains that are *not* expired, which are being affected by this. Domains are hosted via Dynect, and are resolving into this 204.11.56.0/24 range across the globe. Dynect management portal was down until minutes ago as well. - Charles On Jun 20, 2013, at 12:45 AM, David Conrad wrote: > On Jun 19, 2013, at 11:23 PM, Jimmy Hess wrote: >> On 6/20/13, Paul Ferguson wrote: >>> On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: >>>> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore >> I think "ztomy.com" smells really bad for some reason, looks like >> 100% advertising; > > IIRC, Confluence Networks/ztomy pounce on expired domains to sell ads or somesuch. I seem to recall them grabbing the parent domain of name servers for ben.edu last year... > > Regards, > -drc > > From woody at pch.net Thu Jun 20 11:07:52 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 20 Jun 2013 04:07:52 -0700 Subject: net neutrality and peering wars continue In-Reply-To: <51C26745.6010003@queuefull.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> Message-ID: <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> On Jun 19, 2013, at 7:21 PM, Benson Schliesser wrote: > The sending peer (or their customer) has more control over cost. I'll assume that, by "sending peer," you mean the content network. If so, I disagree. The content network has no control whatsoever over the location of the eyeball customer. The eyeball customer has sole control over his or her own location, while the content network has sole control over the location from which they reply to requests. Therefore, control is shared between the two sides. And both are incentivized to minimize costs. If both minimize their costs, overall costs are minimized. That's why this system works. -Bill From j at arpa.com Thu Jun 20 11:57:31 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 20 Jun 2013 06:57:31 -0500 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Smileyface aside, I'm disappointed to see operators simply flushing caches and not performing at the least a dumpdb for possible future forensic analysis. This is what I call the "Windows solution," - 'Oh, just reboot, and it'll work'. We're better than that. (Aren't we?) On Thu, Jun 20, 2013 at 1:02 AM, Paul Ferguson wrote: > Hanlon's razor? Misconfiguration. Perhaps not done in malice, but I > have no idea where the poison leaked in, or why. :-) > > - ferg > > On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie > wrote: > > > Anyone have news/explanation about what's happening/happened? > > > > > > On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson >wrote: > > > >> Sure enough: > >> > >> > >> > >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > >> ; (1 server found) > >> ;; global options: +cmd > >> ;; Got answer: > >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > >> > >> ;; QUESTION SECTION: > >> ;yelp.com. IN A > >> > >> ;; ANSWER SECTION: > >> yelp.com. 300 IN A 204.11.56.20 > >> > >> ;; Query time: 143 msec > >> ;; SERVER: 127.0.0.1#53(127.0.0.1) > >> ;; WHEN: Thu Jun 20 07:33:13 2013 > >> ;; MSG SIZE rcvd: 42 > >> > >> > >> > >> > >> > >> NetRange: 204.11.56.0 - 204.11.59.255 > >> CIDR: 204.11.56.0/22 > >> OriginAS: AS40034 > >> NetName: CONFLUENCE-NETWORKS--TX3 > >> NetHandle: NET-204-11-56-0-1 > >> Parent: NET-204-0-0-0-0 > >> NetType: Direct Allocation > >> Comment: Hosted in Austin TX. > >> Comment: Abuse : > >> Comment: abuse at confluence-networks.com > >> Comment: +1-917-386-6118 > >> RegDate: 2012-09-24 > >> Updated: 2012-09-24 > >> Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 > >> > >> OrgName: Confluence Networks Inc > >> OrgId: CN > >> Address: 3rd Floor, Omar Hodge Building, Wickhams > >> Address: Cay I, P.O. Box 362 > >> City: Road Town > >> StateProv: Tortola > >> PostalCode: VG1110 > >> Country: VG > >> RegDate: 2011-04-07 > >> Updated: 2011-07-05 > >> Ref: http://whois.arin.net/rest/org/CN > >> > >> OrgAbuseHandle: ABUSE3065-ARIN > >> OrgAbuseName: Abuse Admin > >> OrgAbusePhone: +1-917-386-6118 > >> OrgAbuseEmail: abuse at confluence-networks.com > >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN > >> > >> OrgNOCHandle: NOCAD51-ARIN > >> OrgNOCName: NOC Admin > >> OrgNOCPhone: +1-415-462-7734 > >> OrgNOCEmail: noc at confluence-networks.com > >> OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN > >> > >> OrgTechHandle: TECHA29-ARIN > >> OrgTechName: Tech Admin > >> OrgTechPhone: +1-415-358-0858 > >> OrgTechEmail: ipadmin at confluence-networks.com > >> OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN > >> > >> > >> # > >> # ARIN WHOIS data and services are subject to the Terms of Use > >> # available at: https://www.arin.net/whois_tou.html > >> # > >> > >> - ferg > >> > >> > >> > >> On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder > > >> wrote: > >> > >> > Yelp is evidently also affected > >> > > >> > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > >> > > >> >> >Reaching out to DNS operators around the globe. Linkedin.com has had > >> some > >> >> issues with DNS > >> >> >and would like DNS operators to flush their DNS. If you see > >> >> www.linkedin.com resolving NS to > >> >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > >> >> > > >> >> >Any other info please reach out to me off-list. > >> >> > >> >> While you're at it, www.usps.com, www.fidelity.com, and other well > >> >> known sites have had DNS poisoning problems. When I restarted my > >> >> cache, they look OK. > >> >> > >> >> > >> >> > >> > >> > >> > >> -- > >> "Fergie", a.k.a. Paul Ferguson > >> fergdawgster(at)gmail.com > >> > >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From asullivan at dyn.com Thu Jun 20 12:04:14 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 20 Jun 2013 08:04:14 -0400 Subject: Need help in flushing DNS In-Reply-To: <20130620051912.51966.qmail@joyce.lan> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: I am not speaking officially, but the evidence so far is that this was not DNS poisoning, but domain name hijacking. My colleagues will have more to say later today. On Thu, Jun 20, 2013 at 1:19 AM, John Levine wrote: > >Reaching out to DNS operators around the globe. Linkedin.com has had some > issues with DNS > >and would like DNS operators to flush their DNS. If you see > www.linkedin.com resolving NS to > >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > > > >Any other info please reach out to me off-list. > > While you're at it, www.usps.com, www.fidelity.com, and other well > known sites have had DNS poisoning problems. When I restarted my > cache, they look OK. > > > From marty at supine.com Thu Jun 20 12:08:43 2013 From: marty at supine.com (Martin Barry) Date: Thu, 20 Jun 2013 14:08:43 +0200 Subject: net neutrality and peering wars continue In-Reply-To: <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> Message-ID: On 20 June 2013 13:07, Bill Woodcock wrote: > > On Jun 19, 2013, at 7:21 PM, Benson Schliesser > wrote: > > The sending peer (or their customer) has more control over cost. > > I'll assume that, by "sending peer," you mean the content network. If so, > I disagree. The content network has no control whatsoever over the > location of the eyeball customer. The eyeball customer has sole control > over his or her own location, while the content network has sole control > over the location from which they reply to requests. > > Therefore, control is shared between the two sides. And both are > incentivized to minimize costs. If both minimize their costs, overall > costs are minimized. That's why this system works. > > I think his point was that the receiving side can massage their BGP announcements all they like but the sending network has more instantaneous control over how the traffic will flow. This is before analysis, communication, application of policies / contractual arrangements, de-peering etc.etc. kick in. cheers Marty From bensons at queuefull.net Thu Jun 20 12:37:47 2013 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 20 Jun 2013 08:37:47 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> Message-ID: <-5367783170688464759@unknownmsgid> On Jun 20, 2013, at 8:09, Martin Barry wrote: > On 20 June 2013 13:07, Bill Woodcock wrote: > >> On Jun 19, 2013, at 7:21 PM, Benson Schliesser >> wrote: >>> The sending peer (or their customer) has more control over cost. >> >> I'll assume that, by "sending peer," you mean the content network. If so, >> I disagree. The content network has no control whatsoever over the >> location of the eyeball customer. >> ... > I think his point was that the receiving side can massage their BGP > announcements all they like but the sending network has more instantaneous > control over how the traffic will flow. This is before analysis, > communication, application of policies / contractual arrangements, > de-peering etc.etc. kick in. Right. By "sending peer" I meant the network transmitting a packet, unidirectional flow, or other aggregate of traffic into another network. I'm not assuming anything about whether they are offering "content" or something else - I think it would be better to talk about peering fairness at the network layer, rather than the business / service layer. Cheers, -Benson From bensons at queuefull.net Thu Jun 20 12:44:53 2013 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 20 Jun 2013 08:44:53 -0400 Subject: net neutrality and peering wars continue In-Reply-To: <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> Message-ID: <-9038073839096182563@unknownmsgid> On Jun 19, 2013, at 23:41, "Siegel, David" wrote: > Well, with net flow Analytics, it's not really the case that we don't have a way of evaluating the relative burdens. Every major net flow Analytics vendor is implementing some type of distance measurement capability so that each party can calculate not only how much traffic they carry for each peer, but how far. Admittedly, it's been a few years since I looked at such tools... So please help me understand: does the tool evaluate distance (and therefore burden) as it extends into the peer's network, or just into the local network? And in either case, is this kind of data normalized and shared between peers? It seems like there could be a mechanism here to evaluate fairness of burdens, but I'm skeptical that these tools are used in such a way. I'd be glad to be incorrect. ;) Cheers, -Benson From dwcarder at wisc.edu Thu Jun 20 13:40:47 2013 From: dwcarder at wisc.edu (Dale W. Carder) Date: Thu, 20 Jun 2013 08:40:47 -0500 Subject: Wiki for people doing IPv6-only testing In-Reply-To: References: Message-ID: <20130620134046.GB431@ricotta.doit.wisc.edu> Thus spake Jason Fesler (jfesler at gigo.com) on Wed, Jun 19, 2013 at 04:55:01PM -0700: > On a recent IPv6 providers call, there was a desire for participants > to share information with each other on what works and what breaks in > an IPv6-only environment. I offered to set that up. It was further > suggested I should share this with more than just that small > community; to anyone who might be doing work to test out IPv6-only > scenarios. > > http://wiki.test-ipv6.com You may also want to check out the work Ron Broersma has done at DREN. Dale From David.Siegel at Level3.com Thu Jun 20 14:11:20 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 20 Jun 2013 14:11:20 +0000 Subject: net neutrality and peering wars continue In-Reply-To: <-9038073839096182563@unknownmsgid> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> The tools cannot estimate burden into the peers network very well, particularly when longest-exit routing is implement to balance the mileage burden, so each party shares their information with each other and compares data in order to make decisions. It's not common, but there are a handful of peers that share this information with each other. Dave -----Original Message----- From: Benson Schliesser [mailto:bensons at queuefull.net] Sent: Thursday, June 20, 2013 6:45 AM To: Siegel, David Cc: North American Network Operators' Group Subject: Re: net neutrality and peering wars continue On Jun 19, 2013, at 23:41, "Siegel, David" wrote: > Well, with net flow Analytics, it's not really the case that we don't have a way of evaluating the relative burdens. Every major net flow Analytics vendor is implementing some type of distance measurement capability so that each party can calculate not only how much traffic they carry for each peer, but how far. Admittedly, it's been a few years since I looked at such tools... So please help me understand: does the tool evaluate distance (and therefore burden) as it extends into the peer's network, or just into the local network? And in either case, is this kind of data normalized and shared between peers? It seems like there could be a mechanism here to evaluate fairness of burdens, but I'm skeptical that these tools are used in such a way. I'd be glad to be incorrect. ;) Cheers, -Benson From woody at pch.net Thu Jun 20 14:58:01 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 20 Jun 2013 07:58:01 -0700 Subject: net neutrality and peering wars continue In-Reply-To: <-5367783170688464759@unknownmsgid> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> Message-ID: On Jun 20, 2013, at 5:37 AM, Benson Schliesser wrote: > Right. By "sending peer" I meant the network transmitting a packet, > unidirectional flow, or other aggregate of traffic into another > network. I'm not assuming anything about whether they are offering > "content" or something else - I think it would be better to talk about > peering fairness at the network layer, rather than the business / > service layer. In that case, it's essentially never an issue, since essentially every packet in one direction is balanced by a packet in the other direction, so rotational symmetry takes care of the "fairness." I think you may be taking your argument too far, though, since by this logic, the sending and receiving networks also have control over what they choose to transit and receive, and I think that discounts too far the reality that it is in fact the _customers_ that are making all of these decisions, and the networks are, in the aggregate, inflexible in their need to service customers. What a customer will pay to do, a service provider will take money to perform. It's not really service providers (in aggregate) making these decisions. It's customers. -Bill From frnkblk at iname.com Thu Jun 20 15:36:20 2013 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 20 Jun 2013 10:36:20 -0500 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: <000001ce6dcb$e99aad60$bcd00820$@iname.com> Some news coverage here with pretty pictures of LinkedIn access: http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacki ng/ Frank -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Thursday, June 20, 2013 1:23 AM To: Paul Ferguson Cc: NANOG list Subject: Re: Need help in flushing DNS On 6/20/13, Paul Ferguson wrote: > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore I think "ztomy.com" smells really bad for some reason, looks like 100% advertising; sure doesn't "appear" to be a DNS hosting provider, I sure can't imagine two major domains entering incorrect authoritative nameserver list changes on the same day... http://www.dailychanges.com/ztomy.com/#transferred-in "The domain ztomy.com was registered on November 22, 2007, and we have nameserver history going back to December 9, 2007. It is listed as a nameserver for 182,174 domains Currently displaying 50 of 1,602 domain names transferred into ztomy.com on June 19, 2013." >> wrote: >>> On Jun 20, 2013, at 01:30 , Grant Ridder >>> wrote: >>> > Yelp is evidently also affected >>> Not from here. >> Patrick: >> $ dig NS yelp.com @8.8.8.8 +short >> ns1620.ztomy.com. >> ns2620.ztomy.com. -- -JH From philfagan at gmail.com Thu Jun 20 15:49:30 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 20 Jun 2013 09:49:30 -0600 Subject: Need help in flushing DNS In-Reply-To: <000001ce6dcb$e99aad60$bcd00820$@iname.com> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <000001ce6dcb$e99aad60$bcd00820$@iname.com> Message-ID: Is there an organization that coordinates outages like this amongst the industry? On Thu, Jun 20, 2013 at 9:36 AM, Frank Bulk wrote: > Some news coverage here with pretty pictures of LinkedIn access: > > http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacki > ng/ > > Frank > > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Thursday, June 20, 2013 1:23 AM > To: Paul Ferguson > Cc: NANOG list > Subject: Re: Need help in flushing DNS > > On 6/20/13, Paul Ferguson wrote: > > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: > >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore > > I think "ztomy.com" smells really bad for some reason, looks like > 100% advertising; > sure doesn't "appear" to be a DNS hosting provider, I sure can't > imagine two major domains entering incorrect authoritative > nameserver list changes on the same day... > > http://www.dailychanges.com/ztomy.com/#transferred-in > > "The domain ztomy.com was registered on November 22, 2007, and we have > nameserver history going back to December 9, 2007. It is listed as a > nameserver for 182,174 domains > Currently displaying 50 of 1,602 domain names transferred into > ztomy.com on June 19, 2013." > > > >> wrote: > >>> On Jun 20, 2013, at 01:30 , Grant Ridder > >>> wrote: > >>> > Yelp is evidently also affected > >>> Not from here. > >> Patrick: > >> $ dig NS yelp.com @8.8.8.8 +short > >> ns1620.ztomy.com. > >> ns2620.ztomy.com. > > -- > -JH > > > > > -- Phil Fagan Denver, CO 970-480-7618 From fergdawgster at gmail.com Thu Jun 20 15:53:36 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 20 Jun 2013 08:53:36 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <000001ce6dcb$e99aad60$bcd00820$@iname.com> Message-ID: I'm sure that folks in the ICANN SSAC will be talking about this subject well in to the future once a postmortem is completed. Also, perhaps even the DNS-OARC community. Coordination? This is the Internet! :-) - ferg On Thu, Jun 20, 2013 at 8:49 AM, Phil Fagan wrote: > Is there an organization that coordinates outages like this amongst the > industry? > > > On Thu, Jun 20, 2013 at 9:36 AM, Frank Bulk wrote: > >> Some news coverage here with pretty pictures of LinkedIn access: >> >> http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacki >> ng/ >> >> Frank >> >> -----Original Message----- >> From: Jimmy Hess [mailto:mysidia at gmail.com] >> Sent: Thursday, June 20, 2013 1:23 AM >> To: Paul Ferguson >> Cc: NANOG list >> Subject: Re: Need help in flushing DNS >> >> On 6/20/13, Paul Ferguson wrote: >> > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka wrote: >> >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore >> >> I think "ztomy.com" smells really bad for some reason, looks like >> 100% advertising; >> sure doesn't "appear" to be a DNS hosting provider, I sure can't >> imagine two major domains entering incorrect authoritative >> nameserver list changes on the same day... >> >> http://www.dailychanges.com/ztomy.com/#transferred-in >> >> "The domain ztomy.com was registered on November 22, 2007, and we have >> nameserver history going back to December 9, 2007. It is listed as a >> nameserver for 182,174 domains >> Currently displaying 50 of 1,602 domain names transferred into >> ztomy.com on June 19, 2013." >> >> >> >> wrote: >> >>> On Jun 20, 2013, at 01:30 , Grant Ridder >> >>> wrote: >> >>> > Yelp is evidently also affected >> >>> Not from here. >> >> Patrick: >> >> $ dig NS yelp.com @8.8.8.8 +short >> >> ns1620.ztomy.com. >> >> ns2620.ztomy.com. >> >> -- >> -JH >> >> >> >> >> > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From philfagan at gmail.com Thu Jun 20 15:55:46 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 20 Jun 2013 09:55:46 -0600 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <000001ce6dcb$e99aad60$bcd00820$@iname.com> Message-ID: Hah..knew it On Thu, Jun 20, 2013 at 9:53 AM, Paul Ferguson wrote: > I'm sure that folks in the ICANN SSAC will be talking about this > subject well in to the future once a postmortem is completed. Also, > perhaps even the DNS-OARC community. > > Coordination? This is the Internet! :-) > > - ferg > > On Thu, Jun 20, 2013 at 8:49 AM, Phil Fagan wrote: > > > Is there an organization that coordinates outages like this amongst the > > industry? > > > > > > On Thu, Jun 20, 2013 at 9:36 AM, Frank Bulk wrote: > > > >> Some news coverage here with pretty pictures of LinkedIn access: > >> > >> > http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacki > >> ng/< > http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacking/ > > > >> > >> Frank > >> > >> -----Original Message----- > >> From: Jimmy Hess [mailto:mysidia at gmail.com] > >> Sent: Thursday, June 20, 2013 1:23 AM > >> To: Paul Ferguson > >> Cc: NANOG list > >> Subject: Re: Need help in flushing DNS > >> > >> On 6/20/13, Paul Ferguson wrote: > >> > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka > wrote: > >> >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore > >> > >> I think "ztomy.com" smells really bad for some reason, looks like > >> 100% advertising; > >> sure doesn't "appear" to be a DNS hosting provider, I sure can't > >> imagine two major domains entering incorrect authoritative > >> nameserver list changes on the same day... > >> > >> http://www.dailychanges.com/ztomy.com/#transferred-in > >> > >> "The domain ztomy.com was registered on November 22, 2007, and we have > >> nameserver history going back to December 9, 2007. It is listed as a > >> nameserver for 182,174 domains > >> Currently displaying 50 of 1,602 domain names transferred into > >> ztomy.com on June 19, 2013." > >> > >> > >> >> wrote: > >> >>> On Jun 20, 2013, at 01:30 , Grant Ridder > >> >>> wrote: > >> >>> > Yelp is evidently also affected > >> >>> Not from here. > >> >> Patrick: > >> >> $ dig NS yelp.com @8.8.8.8 +short > >> >> ns1620.ztomy.com. > >> >> ns2620.ztomy.com. > >> > >> -- > >> -JH > >> > >> > >> > >> > >> > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > -- Phil Fagan Denver, CO 970-480-7618 From chip.gwyn at gmail.com Thu Jun 20 15:59:00 2013 From: chip.gwyn at gmail.com (chip) Date: Thu, 20 Jun 2013 11:59:00 -0400 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <000001ce6dcb$e99aad60$bcd00820$@iname.com> Message-ID: I don't think there's one recognized authority. However, https://isc.sans.edu/ is pretty up to date. --chip On Thu, Jun 20, 2013 at 11:53 AM, Paul Ferguson wrote: > I'm sure that folks in the ICANN SSAC will be talking about this > subject well in to the future once a postmortem is completed. Also, > perhaps even the DNS-OARC community. > > Coordination? This is the Internet! :-) > > - ferg > > On Thu, Jun 20, 2013 at 8:49 AM, Phil Fagan wrote: > > > Is there an organization that coordinates outages like this amongst the > > industry? > > > > > > On Thu, Jun 20, 2013 at 9:36 AM, Frank Bulk wrote: > > > >> Some news coverage here with pretty pictures of LinkedIn access: > >> > >> > http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacki > >> ng/< > http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacking/ > > > >> > >> Frank > >> > >> -----Original Message----- > >> From: Jimmy Hess [mailto:mysidia at gmail.com] > >> Sent: Thursday, June 20, 2013 1:23 AM > >> To: Paul Ferguson > >> Cc: NANOG list > >> Subject: Re: Need help in flushing DNS > >> > >> On 6/20/13, Paul Ferguson wrote: > >> > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka > wrote: > >> >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore > >> > >> I think "ztomy.com" smells really bad for some reason, looks like > >> 100% advertising; > >> sure doesn't "appear" to be a DNS hosting provider, I sure can't > >> imagine two major domains entering incorrect authoritative > >> nameserver list changes on the same day... > >> > >> http://www.dailychanges.com/ztomy.com/#transferred-in > >> > >> "The domain ztomy.com was registered on November 22, 2007, and we have > >> nameserver history going back to December 9, 2007. It is listed as a > >> nameserver for 182,174 domains > >> Currently displaying 50 of 1,602 domain names transferred into > >> ztomy.com on June 19, 2013." > >> > >> > >> >> wrote: > >> >>> On Jun 20, 2013, at 01:30 , Grant Ridder > >> >>> wrote: > >> >>> > Yelp is evidently also affected > >> >>> Not from here. > >> >> Patrick: > >> >> $ dig NS yelp.com @8.8.8.8 +short > >> >> ns1620.ztomy.com. > >> >> ns2620.ztomy.com. > >> > >> -- > >> -JH > >> > >> > >> > >> > >> > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From philfagan at gmail.com Thu Jun 20 16:01:48 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 20 Jun 2013 10:01:48 -0600 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <000001ce6dcb$e99aad60$bcd00820$@iname.com> Message-ID: Is there a need for such authority or coordination center? On Thu, Jun 20, 2013 at 9:59 AM, chip wrote: > I don't think there's one recognized authority. However, > https://isc.sans.edu/ is pretty up to date. > > --chip > > > On Thu, Jun 20, 2013 at 11:53 AM, Paul Ferguson wrote: > >> I'm sure that folks in the ICANN SSAC will be talking about this >> subject well in to the future once a postmortem is completed. Also, >> perhaps even the DNS-OARC community. >> >> Coordination? This is the Internet! :-) >> >> - ferg >> >> On Thu, Jun 20, 2013 at 8:49 AM, Phil Fagan wrote: >> >> > Is there an organization that coordinates outages like this amongst the >> > industry? >> > >> > >> > On Thu, Jun 20, 2013 at 9:36 AM, Frank Bulk wrote: >> > >> >> Some news coverage here with pretty pictures of LinkedIn access: >> >> >> >> >> http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacki >> >> ng/< >> http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacking/ >> > >> >> >> >> Frank >> >> >> >> -----Original Message----- >> >> From: Jimmy Hess [mailto:mysidia at gmail.com] >> >> Sent: Thursday, June 20, 2013 1:23 AM >> >> To: Paul Ferguson >> >> Cc: NANOG list >> >> Subject: Re: Need help in flushing DNS >> >> >> >> On 6/20/13, Paul Ferguson wrote: >> >> > On Wed, Jun 19, 2013 at 10:44 PM, Tom Paseka >> wrote: >> >> >> On Wed, Jun 19, 2013 at 10:32 PM, Patrick W. Gilmore >> >> >> >> I think "ztomy.com" smells really bad for some reason, looks like >> >> 100% advertising; >> >> sure doesn't "appear" to be a DNS hosting provider, I sure can't >> >> imagine two major domains entering incorrect authoritative >> >> nameserver list changes on the same day... >> >> >> >> http://www.dailychanges.com/ztomy.com/#transferred-in >> >> >> >> "The domain ztomy.com was registered on November 22, 2007, and we have >> >> nameserver history going back to December 9, 2007. It is listed as a >> >> nameserver for 182,174 domains >> >> Currently displaying 50 of 1,602 domain names transferred into >> >> ztomy.com on June 19, 2013." >> >> >> >> >> >> >> wrote: >> >> >>> On Jun 20, 2013, at 01:30 , Grant Ridder >> >> >>> wrote: >> >> >>> > Yelp is evidently also affected >> >> >>> Not from here. >> >> >> Patrick: >> >> >> $ dig NS yelp.com @8.8.8.8 +short >> >> >> ns1620.ztomy.com. >> >> >> ns2620.ztomy.com. >> >> >> >> -- >> >> -JH >> >> >> >> >> >> >> >> >> >> >> > >> > >> > -- >> > Phil Fagan >> > Denver, CO >> > 970-480-7618 >> >> >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> fergdawgster(at)gmail.com >> >> > > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... > -- Phil Fagan Denver, CO 970-480-7618 From niels=nanog at bakker.net Thu Jun 20 16:30:07 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 20 Jun 2013 18:30:07 +0200 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> <000001ce6dcb$e99aad60$bcd00820$@iname.com> Message-ID: <20130620163007.GU55976@burnout.tpb.net> * philfagan at gmail.com (Phil Fagan) [Thu 20 Jun 2013, 17:50 CEST]: >Is there an organization that coordinates outages like this amongst >the industry? No; all outages on the Internet happen independently from each other and are not coordinated to (not) coincide in any way. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From jared at puck.nether.net Thu Jun 20 16:36:17 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Jun 2013 12:36:17 -0400 Subject: Need help in flushing DNS In-Reply-To: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> Message-ID: http://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/ - Jared On Jun 19, 2013, at 11:42 PM, Zaid Ali Kahn wrote: > Reaching out to DNS operators around the globe. Linkedin.com has had some issues with DNS and would like DNS operators to flush their DNS. If you see www.linkedin.com resolving NS to ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > > Any other info please reach out to me off-list. > > Zaid > > From brandon at rd.bbc.co.uk Thu Jun 20 17:10:19 2013 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 20 Jun 2013 18:10:19 +0100 (BST) Subject: Need help in flushing DNS Message-ID: <201306201710.SAA25508@sunf10.rd.bbc.co.uk> > Is there an organization that coordinates outages like this amongst the > industry? No, usually they are surprise outages though Anonymous have tried coordinating a few brandon From philfagan at gmail.com Thu Jun 20 17:13:04 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 20 Jun 2013 11:13:04 -0600 Subject: Need help in flushing DNS In-Reply-To: <201306201710.SAA25508@sunf10.rd.bbc.co.uk> References: <201306201710.SAA25508@sunf10.rd.bbc.co.uk> Message-ID: I should caveat.....coordinate the "recovery" of. On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth wrote: > > Is there an organization that coordinates outages like this amongst the > > industry? > > No, usually they are surprise outages though Anonymous have tried > coordinating a few > > brandon > -- Phil Fagan Denver, CO 970-480-7618 From fergdawgster at gmail.com Thu Jun 20 17:25:08 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 20 Jun 2013 10:25:08 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <201306201710.SAA25508@sunf10.rd.bbc.co.uk> Message-ID: I am betting that Netsol doesn't need any more "coordination" at the moment -- their phones are probably ringing off-the-hook. There are still ~400 domains still pointing to the ztomy NS: ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;parsonstech.com. IN NS ;; ANSWER SECTION: parsonstech.com. 172800 IN NS ns2617.ztomy.com. parsonstech.com. 172800 IN NS ns1617.ztomy.com. ;; Query time: 286 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 20 19:16:25 2013 ;; MSG SIZE rcvd: 81 - ferg On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan wrote: > I should caveat.....coordinate the "recovery" of. > > > On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth > wrote: > >> > Is there an organization that coordinates outages like this amongst the >> > industry? >> >> No, usually they are surprise outages though Anonymous have tried >> coordinating a few >> >> brandon >> > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From philfagan at gmail.com Thu Jun 20 17:29:19 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 20 Jun 2013 11:29:19 -0600 Subject: Need help in flushing DNS In-Reply-To: References: <201306201710.SAA25508@sunf10.rd.bbc.co.uk> Message-ID: Agree'd in these "smaller" scenario's I just wonder if in a larger scale scenario, whatever that might look like, if its necessary. Whereby many organizations who provide "services" are effected. Perhaps the result of a State led campaign ....topic for another day. On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson wrote: > I am betting that Netsol doesn't need any more "coordination" at the > moment -- their phones are probably ringing off-the-hook. There are > still ~400 domains still pointing to the ztomy NS: > > > ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;parsonstech.com. IN NS > > ;; ANSWER SECTION: > parsonstech.com. 172800 IN NS ns2617.ztomy.com. > parsonstech.com. 172800 IN NS ns1617.ztomy.com. > > ;; Query time: 286 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu Jun 20 19:16:25 2013 > ;; MSG SIZE rcvd: 81 > > - ferg > > On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan wrote: > > > I should caveat.....coordinate the "recovery" of. > > > > > > On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth > > wrote: > > > >> > Is there an organization that coordinates outages like this amongst > the > >> > industry? > >> > >> No, usually they are surprise outages though Anonymous have tried > >> coordinating a few > >> > >> brandon > >> > > > > > > > > -- > > Phil Fagan > > Denver, CO > > 970-480-7618 > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > -- Phil Fagan Denver, CO 970-480-7618 From j at arpa.com Thu Jun 20 19:53:27 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 20 Jun 2013 14:53:27 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) Message-ID: This is most definitely a coordinated and planned attack. And by 'attack' I mean hijacking of domain names. I show as of this morning nearly fifty thousand domain names that appear suspicious. I'm tempted to call uscentcom and/or related agencies (which agencies, who the hell knows, as ICE seems to have some sort of authority over domains (nearly two hundred fifty of them as I type this in COM alone and another thirty-some in NET). Anyone credentialed (credentialed /n/., "I know you or know of you,") wanting data, e-mail me off-list for some TLD goodness. On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan wrote: > Agree'd in these "smaller" scenario's I just wonder if in a larger scale > scenario, whatever that might look like, if its necessary. Whereby many > organizations who provide "services" are effected. Perhaps the result of a > State led campaign ....topic for another day. > > > > > On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson >wrote: > > > I am betting that Netsol doesn't need any more "coordination" at the > > moment -- their phones are probably ringing off-the-hook. There are > > still ~400 domains still pointing to the ztomy NS: > > > > > > ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS > > ; (1 server found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;parsonstech.com. IN NS > > > > ;; ANSWER SECTION: > > parsonstech.com. 172800 IN NS ns2617.ztomy.com. > > parsonstech.com. 172800 IN NS ns1617.ztomy.com. > > > > ;; Query time: 286 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Thu Jun 20 19:16:25 2013 > > ;; MSG SIZE rcvd: 81 > > > > - ferg > > > > On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan > wrote: > > > > > I should caveat.....coordinate the "recovery" of. > > > > > > > > > On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth > > > wrote: > > > > > >> > Is there an organization that coordinates outages like this amongst > > the > > >> > industry? > > >> > > >> No, usually they are surprise outages though Anonymous have tried > > >> coordinating a few > > >> > > >> brandon > > >> > > > > > > > > > > > > -- > > > Phil Fagan > > > Denver, CO > > > 970-480-7618 > > > > > > > > -- > > "Fergie", a.k.a. Paul Ferguson > > fergdawgster(at)gmail.com > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From jared at puck.nether.net Thu Jun 20 19:57:12 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Jun 2013 15:57:12 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: It seems there may be a need for some sort of 'dns-health' check out there that can be done in semi-realtime. I ran a report for someone earlier today on a domain doing an xref against open resolver data searching for valid responses vs invalid ones. Is this of value? Does it need to be automated? - Jared On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: > This is most definitely a coordinated and planned attack. > > And by 'attack' I mean hijacking of domain names. > > I show as of this morning nearly fifty thousand domain names that appear > suspicious. > > I'm tempted to call uscentcom and/or related agencies (which agencies, who > the hell knows, as ICE seems to have some sort of authority over domains > (nearly two hundred fifty of them as I type this in COM alone and another > thirty-some in NET). > > Anyone credentialed (credentialed /n/., "I know you or know of you,") > wanting data, e-mail me off-list for some TLD goodness. > > > > > > > On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan wrote: > >> Agree'd in these "smaller" scenario's I just wonder if in a larger scale >> scenario, whatever that might look like, if its necessary. Whereby many >> organizations who provide "services" are effected. Perhaps the result of a >> State led campaign ....topic for another day. >> >> >> >> >> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson >> wrote: >> >>> I am betting that Netsol doesn't need any more "coordination" at the >>> moment -- their phones are probably ringing off-the-hook. There are >>> still ~400 domains still pointing to the ztomy NS: >>> >>> >>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS >>> ; (1 server found) >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;parsonstech.com. IN NS >>> >>> ;; ANSWER SECTION: >>> parsonstech.com. 172800 IN NS ns2617.ztomy.com. >>> parsonstech.com. 172800 IN NS ns1617.ztomy.com. >>> >>> ;; Query time: 286 msec >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>> ;; WHEN: Thu Jun 20 19:16:25 2013 >>> ;; MSG SIZE rcvd: 81 >>> >>> - ferg >>> >>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan >> wrote: >>> >>>> I should caveat.....coordinate the "recovery" of. >>>> >>>> >>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth >>>> wrote: >>>> >>>>>> Is there an organization that coordinates outages like this amongst >>> the >>>>>> industry? >>>>> >>>>> No, usually they are surprise outages though Anonymous have tried >>>>> coordinating a few >>>>> >>>>> brandon >>>>> >>>> >>>> >>>> >>>> -- >>>> Phil Fagan >>>> Denver, CO >>>> 970-480-7618 >>> >>> >>> >>> -- >>> "Fergie", a.k.a. Paul Ferguson >>> fergdawgster(at)gmail.com >>> >> >> >> >> -- >> Phil Fagan >> Denver, CO >> 970-480-7618 >> > > > > -- > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > [Impressive C-level Title Here], arpa / arpa labs From j at arpa.com Thu Jun 20 20:02:28 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 20 Jun 2013 15:02:28 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: I'm rechecking realtime ns1620/2620 DNS right now and, looking at the output, I see an odd number of domains (that have changed) with a listed nameserver of "localhost.". Is this some sort of tactic I'm unaware of? On Thu, Jun 20, 2013 at 2:57 PM, Jared Mauch wrote: > It seems there may be a need for some sort of 'dns-health' check out there > that can be done in semi-realtime. > > I ran a report for someone earlier today on a domain doing an xref against > open resolver data searching for valid responses vs invalid ones. > > Is this of value? Does it need to be automated? > > - Jared > > On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: > > > This is most definitely a coordinated and planned attack. > > > > And by 'attack' I mean hijacking of domain names. > > > > I show as of this morning nearly fifty thousand domain names that appear > > suspicious. > > > > I'm tempted to call uscentcom and/or related agencies (which agencies, > who > > the hell knows, as ICE seems to have some sort of authority over domains > > (nearly two hundred fifty of them as I type this in COM alone and another > > thirty-some in NET). > > > > Anyone credentialed (credentialed /n/., "I know you or know of you,") > > wanting data, e-mail me off-list for some TLD goodness. > > > > > > > > > > > > > > On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan > wrote: > > > >> Agree'd in these "smaller" scenario's I just wonder if in a larger scale > >> scenario, whatever that might look like, if its necessary. Whereby many > >> organizations who provide "services" are effected. Perhaps the result > of a > >> State led campaign ....topic for another day. > >> > >> > >> > >> > >> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson >>> wrote: > >> > >>> I am betting that Netsol doesn't need any more "coordination" at the > >>> moment -- their phones are probably ringing off-the-hook. There are > >>> still ~400 domains still pointing to the ztomy NS: > >>> > >>> > >>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS > >>> ; (1 server found) > >>> ;; global options: +cmd > >>> ;; Got answer: > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > >>> > >>> ;; QUESTION SECTION: > >>> ;parsonstech.com. IN NS > >>> > >>> ;; ANSWER SECTION: > >>> parsonstech.com. 172800 IN NS ns2617.ztomy.com. > >>> parsonstech.com. 172800 IN NS ns1617.ztomy.com. > >>> > >>> ;; Query time: 286 msec > >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) > >>> ;; WHEN: Thu Jun 20 19:16:25 2013 > >>> ;; MSG SIZE rcvd: 81 > >>> > >>> - ferg > >>> > >>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan > >> wrote: > >>> > >>>> I should caveat.....coordinate the "recovery" of. > >>>> > >>>> > >>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth > >>>> wrote: > >>>> > >>>>>> Is there an organization that coordinates outages like this amongst > >>> the > >>>>>> industry? > >>>>> > >>>>> No, usually they are surprise outages though Anonymous have tried > >>>>> coordinating a few > >>>>> > >>>>> brandon > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Phil Fagan > >>>> Denver, CO > >>>> 970-480-7618 > >>> > >>> > >>> > >>> -- > >>> "Fergie", a.k.a. Paul Ferguson > >>> fergdawgster(at)gmail.com > >>> > >> > >> > >> > >> -- > >> Phil Fagan > >> Denver, CO > >> 970-480-7618 > >> > > > > > > > > -- > > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > > [Impressive C-level Title Here], arpa / arpa labs > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From randy at psg.com Thu Jun 20 20:09:57 2013 From: randy at psg.com (Randy Bush) Date: Fri, 21 Jun 2013 05:09:57 +0900 Subject: net neutrality and peering wars continue In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> Message-ID: > The tools cannot estimate burden into the peers network very well, > particularly when longest-exit routing is implement to balance the > mileage burden, so each party shares their information with each other > and compares data in order to make decisions. > > It's not common, but there are a handful of peers that share this > information with each other. i have not been able to find it easily, but some years back rexford and others published on a crypto method for peers to negotiate traffic adjustment between multiple peering points with minimal disclosure. it was a cool paper. randy From george.herbert at gmail.com Thu Jun 20 20:14:00 2013 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Jun 2013 13:14:00 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: Poisoning a domain's NS records with localhost will most certainly DOS the domain, yes. I have not yet seen the source of this; if anyone has a clue where the updates are coming from please post the info. Is there anything about ztomy.com that has been seen that's supicious as in they might be the origin? This could be them, or could be a joe-job against them. I do not want to point a finger lacking any sort of actual data dump of the poisoning activity... On Thu, Jun 20, 2013 at 1:02 PM, jamie rishaw wrote: > I'm rechecking realtime ns1620/2620 DNS right now and, looking at the > output, I see an odd number of domains (that have changed) with a listed > nameserver of "localhost.". > > Is this some sort of tactic I'm unaware of? > > > On Thu, Jun 20, 2013 at 2:57 PM, Jared Mauch > wrote: > > > It seems there may be a need for some sort of 'dns-health' check out > there > > that can be done in semi-realtime. > > > > I ran a report for someone earlier today on a domain doing an xref > against > > open resolver data searching for valid responses vs invalid ones. > > > > Is this of value? Does it need to be automated? > > > > - Jared > > > > On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: > > > > > This is most definitely a coordinated and planned attack. > > > > > > And by 'attack' I mean hijacking of domain names. > > > > > > I show as of this morning nearly fifty thousand domain names that > appear > > > suspicious. > > > > > > I'm tempted to call uscentcom and/or related agencies (which agencies, > > who > > > the hell knows, as ICE seems to have some sort of authority over > domains > > > (nearly two hundred fifty of them as I type this in COM alone and > another > > > thirty-some in NET). > > > > > > Anyone credentialed (credentialed /n/., "I know you or know of you,") > > > wanting data, e-mail me off-list for some TLD goodness. > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan > > wrote: > > > > > >> Agree'd in these "smaller" scenario's I just wonder if in a larger > scale > > >> scenario, whatever that might look like, if its necessary. Whereby > many > > >> organizations who provide "services" are effected. Perhaps the result > > of a > > >> State led campaign ....topic for another day. > > >> > > >> > > >> > > >> > > >> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson < > fergdawgster at gmail.com > > >>> wrote: > > >> > > >>> I am betting that Netsol doesn't need any more "coordination" at the > > >>> moment -- their phones are probably ringing off-the-hook. There are > > >>> still ~400 domains still pointing to the ztomy NS: > > >>> > > >>> > > >>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS > > >>> ; (1 server found) > > >>> ;; global options: +cmd > > >>> ;; Got answer: > > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 > > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > >>> > > >>> ;; QUESTION SECTION: > > >>> ;parsonstech.com. IN NS > > >>> > > >>> ;; ANSWER SECTION: > > >>> parsonstech.com. 172800 IN NS ns2617.ztomy.com. > > >>> parsonstech.com. 172800 IN NS ns1617.ztomy.com. > > >>> > > >>> ;; Query time: 286 msec > > >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) > > >>> ;; WHEN: Thu Jun 20 19:16:25 2013 > > >>> ;; MSG SIZE rcvd: 81 > > >>> > > >>> - ferg > > >>> > > >>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan > > >> wrote: > > >>> > > >>>> I should caveat.....coordinate the "recovery" of. > > >>>> > > >>>> > > >>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth > > >>>> wrote: > > >>>> > > >>>>>> Is there an organization that coordinates outages like this > amongst > > >>> the > > >>>>>> industry? > > >>>>> > > >>>>> No, usually they are surprise outages though Anonymous have tried > > >>>>> coordinating a few > > >>>>> > > >>>>> brandon > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Phil Fagan > > >>>> Denver, CO > > >>>> 970-480-7618 > > >>> > > >>> > > >>> > > >>> -- > > >>> "Fergie", a.k.a. Paul Ferguson > > >>> fergdawgster(at)gmail.com > > >>> > > >> > > >> > > >> > > >> -- > > >> Phil Fagan > > >> Denver, CO > > >> 970-480-7618 > > >> > > > > > > > > > > > > -- > > > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > > > [Impressive C-level Title Here], arpa / arpa labs > > > > > > > -- > Jamie Rishaw // .com.arpa at j <- reverse it. ish. > [Impressive C-level Title Here], arpa / arpa labs > -- -george william herbert george.herbert at gmail.com From j at arpa.com Thu Jun 20 20:21:07 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 20 Jun 2013 15:21:07 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: It's not poisoning. They somehow were able to modify the NS records; one would presume, at the registrar/s. As far as the logic of the DNS, it is functioning as designed (What's up, Vix!) - There's another aspect of this that caused this situation. Any Alexa or similar people on this list (Goog PR, etc)? I'd love to bulk submit a domain list for some analytics. Contact me off list. On Thu, Jun 20, 2013 at 3:14 PM, George Herbert wrote: > Poisoning a domain's NS records with localhost will most certainly DOS the > domain, yes. > > I have not yet seen the source of this; if anyone has a clue where the > updates are coming from please post the info. > > Is there anything about ztomy.com that has been seen that's supicious as > in they might be the origin? This could be them, or could be a joe-job > against them. I do not want to point a finger lacking any sort of actual > data dump of the poisoning activity... > > > > > On Thu, Jun 20, 2013 at 1:02 PM, jamie rishaw wrote: > >> I'm rechecking realtime ns1620/2620 DNS right now and, looking at the >> output, I see an odd number of domains (that have changed) with a listed >> nameserver of "localhost.". >> >> Is this some sort of tactic I'm unaware of? >> >> >> On Thu, Jun 20, 2013 at 2:57 PM, Jared Mauch >> wrote: >> >> > It seems there may be a need for some sort of 'dns-health' check out >> there >> > that can be done in semi-realtime. >> > >> > I ran a report for someone earlier today on a domain doing an xref >> against >> > open resolver data searching for valid responses vs invalid ones. >> > >> > Is this of value? Does it need to be automated? >> > >> > - Jared >> > >> > On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: >> > >> > > This is most definitely a coordinated and planned attack. >> > > >> > > And by 'attack' I mean hijacking of domain names. >> > > >> > > I show as of this morning nearly fifty thousand domain names that >> appear >> > > suspicious. >> > > >> > > I'm tempted to call uscentcom and/or related agencies (which agencies, >> > who >> > > the hell knows, as ICE seems to have some sort of authority over >> domains >> > > (nearly two hundred fifty of them as I type this in COM alone and >> another >> > > thirty-some in NET). >> > > >> > > Anyone credentialed (credentialed /n/., "I know you or know of you,") >> > > wanting data, e-mail me off-list for some TLD goodness. >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan >> > wrote: >> > > >> > >> Agree'd in these "smaller" scenario's I just wonder if in a larger >> scale >> > >> scenario, whatever that might look like, if its necessary. Whereby >> many >> > >> organizations who provide "services" are effected. Perhaps the result >> > of a >> > >> State led campaign ....topic for another day. >> > >> >> > >> >> > >> >> > >> >> > >> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson < >> fergdawgster at gmail.com >> > >>> wrote: >> > >> >> > >>> I am betting that Netsol doesn't need any more "coordination" at the >> > >>> moment -- their phones are probably ringing off-the-hook. There are >> > >>> still ~400 domains still pointing to the ztomy NS: >> > >>> >> > >>> >> > >>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS >> > >>> ; (1 server found) >> > >>> ;; global options: +cmd >> > >>> ;; Got answer: >> > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 >> > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >> > >>> >> > >>> ;; QUESTION SECTION: >> > >>> ;parsonstech.com. IN NS >> > >>> >> > >>> ;; ANSWER SECTION: >> > >>> parsonstech.com. 172800 IN NS ns2617.ztomy.com. >> > >>> parsonstech.com. 172800 IN NS ns1617.ztomy.com. >> > >>> >> > >>> ;; Query time: 286 msec >> > >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> > >>> ;; WHEN: Thu Jun 20 19:16:25 2013 >> > >>> ;; MSG SIZE rcvd: 81 >> > >>> >> > >>> - ferg >> > >>> >> > >>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan >> > >> wrote: >> > >>> >> > >>>> I should caveat.....coordinate the "recovery" of. >> > >>>> >> > >>>> >> > >>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth >> > >>>> wrote: >> > >>>> >> > >>>>>> Is there an organization that coordinates outages like this >> amongst >> > >>> the >> > >>>>>> industry? >> > >>>>> >> > >>>>> No, usually they are surprise outages though Anonymous have tried >> > >>>>> coordinating a few >> > >>>>> >> > >>>>> brandon >> > >>>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> Phil Fagan >> > >>>> Denver, CO >> > >>>> 970-480-7618 >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> "Fergie", a.k.a. Paul Ferguson >> > >>> fergdawgster(at)gmail.com >> > >>> >> > >> >> > >> >> > >> >> > >> -- >> > >> Phil Fagan >> > >> Denver, CO >> > >> 970-480-7618 >> > >> >> > > >> > > >> > > >> > > -- >> > > Jamie Rishaw // .com.arpa at j <- reverse it. ish. >> > > [Impressive C-level Title Here], arpa / arpa labs >> > >> > >> >> >> -- >> Jamie Rishaw // .com.arpa at j <- reverse it. ish. >> [Impressive C-level Title Here], arpa / arpa labs >> > > > > -- > -george william herbert > george.herbert at gmail.com > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From andrew.fried at gmail.com Thu Jun 20 20:35:45 2013 From: andrew.fried at gmail.com (Andrew Fried) Date: Thu, 20 Jun 2013 16:35:45 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: <51C367A1.5010603@gmail.com> Not so easy and straightforward to do. You'll find that a lot of the big names out there frequently tweak DNS, which will result in a non-stop stream of "alerts". Andy Andrew Fried andrew.fried at gmail.com On 6/20/13 3:57 PM, Jared Mauch wrote: > It seems there may be a need for some sort of 'dns-health' check out there that can be done in semi-realtime. > > I ran a report for someone earlier today on a domain doing an xref against open resolver data searching for valid responses vs invalid ones. > > Is this of value? Does it need to be automated? > > - Jared > > On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: > >> This is most definitely a coordinated and planned attack. >> >> And by 'attack' I mean hijacking of domain names. >> >> I show as of this morning nearly fifty thousand domain names that appear >> suspicious. >> >> I'm tempted to call uscentcom and/or related agencies (which agencies, who >> the hell knows, as ICE seems to have some sort of authority over domains >> (nearly two hundred fifty of them as I type this in COM alone and another >> thirty-some in NET). >> >> Anyone credentialed (credentialed /n/., "I know you or know of you,") >> wanting data, e-mail me off-list for some TLD goodness. >> >> >> >> >> >> >> On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan wrote: >> >>> Agree'd in these "smaller" scenario's I just wonder if in a larger scale >>> scenario, whatever that might look like, if its necessary. Whereby many >>> organizations who provide "services" are effected. Perhaps the result of a >>> State led campaign ....topic for another day. >>> >>> >>> >>> >>> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson >>> wrote: >>> >>>> I am betting that Netsol doesn't need any more "coordination" at the >>>> moment -- their phones are probably ringing off-the-hook. There are >>>> still ~400 domains still pointing to the ztomy NS: >>>> >>>> >>>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS >>>> ; (1 server found) >>>> ;; global options: +cmd >>>> ;; Got answer: >>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 >>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >>>> >>>> ;; QUESTION SECTION: >>>> ;parsonstech.com. IN NS >>>> >>>> ;; ANSWER SECTION: >>>> parsonstech.com. 172800 IN NS ns2617.ztomy.com. >>>> parsonstech.com. 172800 IN NS ns1617.ztomy.com. >>>> >>>> ;; Query time: 286 msec >>>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>>> ;; WHEN: Thu Jun 20 19:16:25 2013 >>>> ;; MSG SIZE rcvd: 81 >>>> >>>> - ferg >>>> >>>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan >>> wrote: >>>> >>>>> I should caveat.....coordinate the "recovery" of. >>>>> >>>>> >>>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth >>>>> wrote: >>>>> >>>>>>> Is there an organization that coordinates outages like this amongst >>>> the >>>>>>> industry? >>>>>> >>>>>> No, usually they are surprise outages though Anonymous have tried >>>>>> coordinating a few >>>>>> >>>>>> brandon >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Phil Fagan >>>>> Denver, CO >>>>> 970-480-7618 >>>> >>>> >>>> >>>> -- >>>> "Fergie", a.k.a. Paul Ferguson >>>> fergdawgster(at)gmail.com >>>> >>> >>> >>> >>> -- >>> Phil Fagan >>> Denver, CO >>> 970-480-7618 >>> >> >> >> >> -- >> Jamie Rishaw // .com.arpa at j <- reverse it. ish. >> [Impressive C-level Title Here], arpa / arpa labs > > From j at arpa.com Thu Jun 20 20:37:29 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 20 Jun 2013 15:37:29 -0500 Subject: Fwd: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: Wait, wait. whois doesnt jive with dns. .. Conspiracy Theory Hat On : - Did someone gain access to the COM dispersion zone, or parts thereof? - Did someone figure out how to [ insert theory here ] ? I'm looking at domains that were solidly pointing at ztomy at 2:30AM (that are 'recovered' to other nameservers) that show no "updates" in `whois` records. Curiouser and curiouser. Paul? ---------- Forwarded message ---------- From: jamie rishaw Date: Thu, Jun 20, 2013 at 3:21 PM Subject: Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS) To: George Herbert Cc: Jared Mauch , NANOG It's not poisoning. They somehow were able to modify the NS records; one would presume, at the registrar/s. As far as the logic of the DNS, it is functioning as designed (What's up, Vix!) - There's another aspect of this that caused this situation. Any Alexa or similar people on this list (Goog PR, etc)? I'd love to bulk submit a domain list for some analytics. Contact me off list. On Thu, Jun 20, 2013 at 3:14 PM, George Herbert wrote: > Poisoning a domain's NS records with localhost will most certainly DOS the > domain, yes. > > I have not yet seen the source of this; if anyone has a clue where the > updates are coming from please post the info. > > Is there anything about ztomy.com that has been seen that's supicious as > in they might be the origin? This could be them, or could be a joe-job > against them. I do not want to point a finger lacking any sort of actual > data dump of the poisoning activity... > > > > > On Thu, Jun 20, 2013 at 1:02 PM, jamie rishaw wrote: > >> I'm rechecking realtime ns1620/2620 DNS right now and, looking at the >> output, I see an odd number of domains (that have changed) with a listed >> nameserver of "localhost.". >> >> Is this some sort of tactic I'm unaware of? >> >> >> On Thu, Jun 20, 2013 at 2:57 PM, Jared Mauch >> wrote: >> >> > It seems there may be a need for some sort of 'dns-health' check out >> there >> > that can be done in semi-realtime. >> > >> > I ran a report for someone earlier today on a domain doing an xref >> against >> > open resolver data searching for valid responses vs invalid ones. >> > >> > Is this of value? Does it need to be automated? >> > >> > - Jared >> > >> > On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: >> > >> > > This is most definitely a coordinated and planned attack. >> > > >> > > And by 'attack' I mean hijacking of domain names. >> > > >> > > I show as of this morning nearly fifty thousand domain names that >> appear >> > > suspicious. >> > > >> > > I'm tempted to call uscentcom and/or related agencies (which agencies, >> > who >> > > the hell knows, as ICE seems to have some sort of authority over >> domains >> > > (nearly two hundred fifty of them as I type this in COM alone and >> another >> > > thirty-some in NET). >> > > >> > > Anyone credentialed (credentialed /n/., "I know you or know of you,") >> > > wanting data, e-mail me off-list for some TLD goodness. >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan >> > wrote: >> > > >> > >> Agree'd in these "smaller" scenario's I just wonder if in a larger >> scale >> > >> scenario, whatever that might look like, if its necessary. Whereby >> many >> > >> organizations who provide "services" are effected. Perhaps the result >> > of a >> > >> State led campaign ....topic for another day. >> > >> >> > >> >> > >> >> > >> >> > >> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson < >> fergdawgster at gmail.com >> > >>> wrote: >> > >> >> > >>> I am betting that Netsol doesn't need any more "coordination" at the >> > >>> moment -- their phones are probably ringing off-the-hook. There are >> > >>> still ~400 domains still pointing to the ztomy NS: >> > >>> >> > >>> >> > >>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS >> > >>> ; (1 server found) >> > >>> ;; global options: +cmd >> > >>> ;; Got answer: >> > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 >> > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >> > >>> >> > >>> ;; QUESTION SECTION: >> > >>> ;parsonstech.com. IN NS >> > >>> >> > >>> ;; ANSWER SECTION: >> > >>> parsonstech.com. 172800 IN NS ns2617.ztomy.com. >> > >>> parsonstech.com. 172800 IN NS ns1617.ztomy.com. >> > >>> >> > >>> ;; Query time: 286 msec >> > >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> > >>> ;; WHEN: Thu Jun 20 19:16:25 2013 >> > >>> ;; MSG SIZE rcvd: 81 >> > >>> >> > >>> - ferg >> > >>> >> > >>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan >> > >> wrote: >> > >>> >> > >>>> I should caveat.....coordinate the "recovery" of. >> > >>>> >> > >>>> >> > >>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth >> > >>>> wrote: >> > >>>> >> > >>>>>> Is there an organization that coordinates outages like this >> amongst >> > >>> the >> > >>>>>> industry? >> > >>>>> >> > >>>>> No, usually they are surprise outages though Anonymous have tried >> > >>>>> coordinating a few >> > >>>>> >> > >>>>> brandon >> > >>>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> Phil Fagan >> > >>>> Denver, CO >> > >>>> 970-480-7618 >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> "Fergie", a.k.a. Paul Ferguson >> > >>> fergdawgster(at)gmail.com >> > >>> >> > >> >> > >> >> > >> >> > >> -- >> > >> Phil Fagan >> > >> Denver, CO >> > >> 970-480-7618 >> > >> >> > > >> > > >> > > > -- > -george william herbert > george.herbert at gmail.com > From niels=nanog at bakker.net Thu Jun 20 20:39:56 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 20 Jun 2013 22:39:56 +0200 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> Message-ID: <20130620203956.GV55976@burnout.tpb.net> * woody at pch.net (Bill Woodcock) [Thu 20 Jun 2013, 16:59 CEST]: >On Jun 20, 2013, at 5:37 AM, Benson Schliesser wrote: >>Right. By "sending peer" I meant the network transmitting a >>packet, unidirectional flow, or other aggregate of traffic into >>another network. I'm not assuming anything about whether they are >>offering "content" or something else - I think it would be better >>to talk about peering fairness at the network layer, rather than >>the business / service layer. >In that case, it's essentially never an issue, since essentially >every packet in one direction is balanced by a packet in the other >direction, so rotational symmetry takes care of the "fairness." You're mistaken if you think that CDNs have equal number of packets going in and out. >I think you may be taking your argument too far, though, since by >this logic, the sending and receiving networks also have control >over what they choose to transit and receive, and I think that >discounts too far the reality that it is in fact the _customers_ >that are making all of these decisions, and the networks are, in the >aggregate, inflexible in their need to service customers. What a >customer will pay to do, a service provider will take money to >perform. It's not really service providers (in aggregate) making >these decisions. It's customers. I think the point is here that networks are nudging these decisions by making certain services suck more than others by way of preferential network access. -- Niels. From mysidia at gmail.com Thu Jun 20 20:46:07 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Jun 2013 15:46:07 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: On 6/20/13, jamie rishaw wrote: > It's not poisoning. They somehow were able to modify the NS records; one > would presume, at the registrar/s. https://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/ -- -JH From jeffshultz at wvi.com Thu Jun 20 21:08:18 2013 From: jeffshultz at wvi.com (Jeff Shultz) Date: Thu, 20 Jun 2013 14:08:18 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: <51C36F42.9060307@wvi.com> On 6/20/2013 1:46 PM, Jimmy Hess wrote: > On 6/20/13, jamie rishaw wrote: >> It's not poisoning. They somehow were able to modify the NS records; one >> would presume, at the registrar/s. > > https://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/ > > -- > -JH > "small number of Network Solutions customers" They must be staffed with physicists, astronomers, or economists.... I don't know anyone else that would consider "nearly fifty thousand" (from a previous post by Phil Fagan) to be a small number. -- Jeff Shultz From cabo at tzi.org Thu Jun 20 21:10:30 2013 From: cabo at tzi.org (Carsten Bormann) Date: Thu, 20 Jun 2013 23:10:30 +0200 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: Wild speculation: netsol says this is a human error incurred during DDOS mitigation. ztomy.com is a wild-card DNS provider that seems to use prolexic. Now imagine someone at netsol or its DDOS service providers fat-fingered their DDOS-averting routing in such a way that netsol DNS traffic arrived at ztomy.com instead of a netsol server. The ztomy.com server would know how to answer the queries... I have no data to base this speculation on. Gr??e, Carsten From gabor at logmein.com Thu Jun 20 21:23:13 2013 From: gabor at logmein.com (Gabor Tokaji) Date: Thu, 20 Jun 2013 21:23:13 +0000 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: <6BAC646CEA21CA4386B6F70797DA934F048B4C1D@usand-mbx02.3amlabs.net> Hello everyone, I'm new here. +1 to this theory. I've been watching what's happening since 3am Eastern, because a domain of mine (of the many at NetSol) was a victim of this event. -Gabor -----Original Message----- From: Carsten Bormann [mailto:cabo at tzi.org] Sent: Thursday, June 20, 2013 5:11 PM To: NANOG list Subject: Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS) Wild speculation: netsol says this is a human error incurred during DDOS mitigation. ztomy.com is a wild-card DNS provider that seems to use prolexic. Now imagine someone at netsol or its DDOS service providers fat-fingered their DDOS-averting routing in such a way that netsol DNS traffic arrived at ztomy.com instead of a netsol server. The ztomy.com server would know how to answer the queries... I have no data to base this speculation on. Gr??e, Carsten From Valdis.Kletnieks at vt.edu Thu Jun 20 21:28:17 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jun 2013 17:28:17 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: Your message of "Thu, 20 Jun 2013 14:08:18 -0700." <51C36F42.9060307@wvi.com> References: <51C36F42.9060307@wvi.com> Message-ID: <32662.1371763697@turing-police.cc.vt.edu> On Thu, 20 Jun 2013 14:08:18 -0700, Jeff Shultz said: > "small number of Network Solutions customers" > > They must be staffed with physicists, astronomers, or economists.... I > don't know anyone else that would consider "nearly fifty thousand" (from > a previous post by Phil Fagan) to be a small number. It's relatively small when you consider there's something like 140M .com's -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Jun 20 21:29:11 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jun 2013 17:29:11 -0400 Subject: net neutrality and peering wars continue In-Reply-To: Your message of "Thu, 20 Jun 2013 22:39:56 +0200." <20130620203956.GV55976@burnout.tpb.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> Message-ID: <32722.1371763751@turing-police.cc.vt.edu> On Thu, 20 Jun 2013 22:39:56 +0200, Niels Bakker said: > You're mistaken if you think that CDNs have equal number of packets > going in and out. And even if the number of packets match, there's the whole "1500 bytes of data, 64 bytes of ACK" thing to factor in... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From owen at delong.com Thu Jun 20 21:32:55 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jun 2013 23:32:55 +0200 Subject: net neutrality and peering wars continue In-Reply-To: <20130620203956.GV55976@burnout.tpb.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> Message-ID: <5548E336-5A14-4975-A308-0551D25DA183@delong.com> On Jun 20, 2013, at 10:39 PM, Niels Bakker wrote: > * woody at pch.net (Bill Woodcock) [Thu 20 Jun 2013, 16:59 CEST]: >> On Jun 20, 2013, at 5:37 AM, Benson Schliesser wrote: > >>> Right. By "sending peer" I meant the network transmitting a packet, unidirectional flow, or other aggregate of traffic into another network. I'm not assuming anything about whether they are offering "content" or something else - I think it would be better to talk about peering fairness at the network layer, rather than the business / service layer. >> In that case, it's essentially never an issue, since essentially every packet in one direction is balanced by a packet in the other direction, so rotational symmetry takes care of the "fairness." > > You're mistaken if you think that CDNs have equal number of packets going in and out. They are roughly equal (modulo delayed acks, etc.). However, the number of octets is very different from the number of packets. There is much greater asymmetry in number of octets than in number of packets. To the best of my knowledge, most (if not all) of the peering agreements that discuss traffic ratios do so in terms of data transferred, not number of datagrams. Owen From rijilv at riji.lv Thu Jun 20 21:42:51 2013 From: rijilv at riji.lv (RijilV) Date: Thu, 20 Jun 2013 14:42:51 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <32662.1371763697@turing-police.cc.vt.edu> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: On 20 June 2013 14:28, wrote: > On Thu, 20 Jun 2013 14:08:18 -0700, Jeff Shultz said: > > > "small number of Network Solutions customers" > > > > They must be staffed with physicists, astronomers, or economists.... I > > don't know anyone else that would consider "nearly fifty thousand" (from > > a previous post by Phil Fagan) to be a small number. > > It's relatively small when you consider there's something like 140M .com's > > So it's okay to screw over "nearly fifty thousand" customer domains because there are 140M .com's? When talking about inadvertently effecting that many folks I don't think it is appropriate to trivialize the customer impact by calling it small when you're talking about a handful of large websites that aren't somehow magically shared over those 140M .coms. Also it is untrue to limit it to only "the websites" given how many other things folks are likely to be using DNS for... .r' From randy at psg.com Thu Jun 20 21:49:03 2013 From: randy at psg.com (Randy Bush) Date: Fri, 21 Jun 2013 06:49:03 +0900 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: > So it's okay to screw over "nearly fifty thousand" customer domains because > there are 140M .com's? luckily, none of the rest of us make mistakes From rlambert.lists at gmail.com Thu Jun 20 21:51:17 2013 From: rlambert.lists at gmail.com (Ryan - Lists) Date: Thu, 20 Jun 2013 17:51:17 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: <7733F4C3-7F05-4A8D-80EE-A2A415A35DED@gmail.com> I don't think he was saying that at all. Just stating that from a pure numbers standpoint 50k/140mil is a small percentage. OTOH, I agree to your point - Network Solutions definitely downplayed this in their release. Curiously so. Sent from my iPhone On Jun 20, 2013, at 5:42 PM, RijilV wrote: > On 20 June 2013 14:28, wrote: > >> On Thu, 20 Jun 2013 14:08:18 -0700, Jeff Shultz said: >> >>> "small number of Network Solutions customers" >>> >>> They must be staffed with physicists, astronomers, or economists.... I >>> don't know anyone else that would consider "nearly fifty thousand" (from >>> a previous post by Phil Fagan) to be a small number. >> >> It's relatively small when you consider there's something like 140M .com's > So it's okay to screw over "nearly fifty thousand" customer domains because > there are 140M .com's? When talking about inadvertently effecting that > many folks I don't think it is appropriate to trivialize the customer > impact by calling it small when you're talking about a handful of large > websites that aren't somehow magically shared over those 140M .coms. Also > it is untrue to limit it to only "the websites" given how many other things > folks are likely to be using DNS for... > > .r' From sparctacus at gmail.com Thu Jun 20 22:10:37 2013 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 20 Jun 2013 15:10:37 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: On Thu, Jun 20, 2013 at 2:49 PM, Randy Bush wrote: > > So it's okay to screw over "nearly fifty thousand" customer domains > because > > there are 140M .com's? > > luckily, none of the rest of us make mistakes > > Ages ago I responded on a Cisco list where the topic was biggest screwup you've made. I posted that I once forgot the implicit deny in an ACL and accidentally blocked all traffic between 4 locations in 2 states for a company I was working for. Downtime was a very brutal 60 seconds. Someone very insightful responded with "anyone who hasn't done similar is lying about the 10 years on their resume". So the real question would be, why wasn't there someone who has already done this in the past working on this zone? ;) -B From rgolodner at infratection.com Thu Jun 20 22:12:18 2013 From: rgolodner at infratection.com (Richard Golodner) Date: Thu, 20 Jun 2013 17:12:18 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: <1371766338.2374.3.camel@Andromeda> On Thu, 2013-06-20 at 14:42 -0700, RijilV wrote: > On 20 June 2013 14:28, wrote: > > > On Thu, 20 Jun 2013 14:08:18 -0700, Jeff Shultz said: > > > > > "small number of Network Solutions customers" > > > > > > They must be staffed with physicists, astronomers, or economists.... I > > > don't know anyone else that would consider "nearly fifty thousand" (from > > > a previous post by Phil Fagan) to be a small number. > > > > It's relatively small when you consider there's something like 140M .com's > > > > > So it's okay to screw over "nearly fifty thousand" customer domains because > there are 140M .com's? When talking about inadvertently effecting that > many folks I don't think it is appropriate to trivialize the customer > impact by calling it small when you're talking about a handful of large > websites that aren't somehow magically shared over those 140M .coms. Also > it is untrue to limit it to only "the websites" given how many other things > folks are likely to be using DNS for... > > .r' > I think you are reading it the wrong way. Mr.Kletnieks never said it was okay. He just stated that the numbers were trivial when compared to the rest of potential customers being affected. Be cool, Richard Golodner From niels=nanog at bakker.net Thu Jun 20 22:26:01 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 21 Jun 2013 00:26:01 +0200 Subject: net neutrality and peering wars continue In-Reply-To: <5548E336-5A14-4975-A308-0551D25DA183@delong.com> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <5548E336-5A14-4975-A308-0551D25DA183@delong.com> Message-ID: <20130620222601.GW55976@burnout.tpb.net> * owen at delong.com (Owen DeLong) [Thu 20 Jun 2013, 23:38 CEST]: >On Jun 20, 2013, at 10:39 PM, Niels Bakker wrote: >> * woody at pch.net (Bill Woodcock) [Thu 20 Jun 2013, 16:59 CEST]: >>>On Jun 20, 2013, at 5:37 AM, Benson Schliesser >>> wrote: >>>>Right. By "sending peer" I meant the network transmitting a packet [...] >>>every packet in one direction is balanced by a packet in the other direction >> >>You're mistaken if you think that CDNs have equal number of >>packets going in and out. > >They are roughly equal (modulo delayed acks, etc.). However, the >number of octets is very different from the number of packets. There >is much greater asymmetry in number of octets than in number of >packets. Thank you, Captain Obvious. Also, if you don't have data, best to keep your opinion to yourself, because you might well be wrong. -- Niels. From randy at psg.com Thu Jun 20 22:28:29 2013 From: randy at psg.com (Randy Bush) Date: Fri, 21 Jun 2013 07:28:29 +0900 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <1371766338.2374.3.camel@Andromeda> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: netsol screwed up. they screwed up bigtime. they are shoveling kitty litter over it as fast as they can, and they have a professional kitty litter, aka pr, department. but none of this is surprising. and dnssec did not save us. is there anything which could have? randy From george.herbert at gmail.com Thu Jun 20 22:37:29 2013 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Jun 2013 15:37:29 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: <1109A012-A458-46FC-8440-CD3B67CE8EAD@gmail.com> At the DNS Servers or service provider level, one can (and I often do) have redundant providers. At the registrar level? ... Not with our current infrastructure, as far as I know how. The Internet: Discovering new SPOF since 1969! George William Herbert Sent from my iPhone On Jun 20, 2013, at 3:28 PM, Randy Bush wrote: > netsol screwed up. they screwed up bigtime. they are shoveling kitty > litter over it as fast as they can, and they have a professional kitty > litter, aka pr, department. > > but none of this is surprising. > > and dnssec did not save us. is there anything which could have? > > randy > > From philfagan at gmail.com Thu Jun 20 22:39:00 2013 From: philfagan at gmail.com (Phil Fagan) Date: Thu, 20 Jun 2013 16:39:00 -0600 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: ....at what point is the Internet a piece of infrastructure whereby we actually need a way to watch this thing holistically as it is one system and not just a bunch of inter-jointed systems? Who's job is it to do nothing but ensure that the state of DNS and other services is running as it should....who's the clearing house here. On Thu, Jun 20, 2013 at 4:28 PM, Randy Bush wrote: > netsol screwed up. they screwed up bigtime. they are shoveling kitty > litter over it as fast as they can, and they have a professional kitty > litter, aka pr, department. > > but none of this is surprising. > > and dnssec did not save us. is there anything which could have? > > randy > > > -- Phil Fagan Denver, CO 970-480-7618 From NANOG at enger.us Thu Jun 20 22:47:54 2013 From: NANOG at enger.us (Robert M. Enger) Date: Thu, 20 Jun 2013 15:47:54 -0700 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> Message-ID: <51C3869A.4080008@enger.us> Perhaps last-mile operators should A) advertise each of their metropolitan regional systems as a separate AS B) establish an interconnection point in each region where they will accept traffic destined for their in-region customers without charging any fee This leaves the operational model of WAN backbone transit networks unchanged: fights about traffic balance and settlement fees can continue in perpetuity. Those big sources who fall afoul of balance can opt to deliver traffic directly to the last-mile network(s) in given markets. Transfers WAN networking cost-burden to the content originator (through their agents: CDN operators or transit providers) Reduces financial burden on last-mile operator (demand is reduced on their company operated backbone and/or transit capacity that they purchase) RESULTS Customers get to receive content they are requesting: technical and political impediments are removed. Last-mile operator only has to improve in-region network facilities: to deliver the data that their own customers have requested From j at arpa.com Thu Jun 20 22:51:44 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 20 Jun 2013 17:51:44 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: No. The ztomy nameservers appeared in this morning's master .COM zonefile as /authoritative/ for the number of domains I mentioned. It is a clear change from just a couple of days ago, when the listed nameservers were nowhere to be seen. I have solid data to back this up, straight from Verisign GRS (Verisign), the authoritative registry for .COM, .NET and others. j On Thu, Jun 20, 2013 at 4:10 PM, Carsten Bormann wrote: > Wild speculation: > > netsol says this is a human error incurred during DDOS mitigation. > ztomy.com is a wild-card DNS provider that seems to use prolexic. > Now imagine someone at netsol or its DDOS service providers > fat-fingered their DDOS-averting routing in such a way that netsol > DNS traffic arrived at ztomy.com instead of a netsol server. > The ztomy.com server would know how to answer the queries... > > I have no data to base this speculation on. > > Gr??e, Carsten > > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From bicknell at ufp.org Thu Jun 20 23:18:48 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 20 Jun 2013 18:18:48 -0500 Subject: net neutrality and peering wars continue In-Reply-To: <51C3869A.4080008@enger.us> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> Message-ID: On Jun 20, 2013, at 5:47 PM, Robert M. Enger wrote: > Perhaps last-mile operators should > A) advertise each of their metropolitan regional systems as a separate AS > B) establish an interconnection point in each region where they will accept traffic destined for their in-region customers without charging any fee C) Buck up and carry the traffic their customers are paying them to carry. Least I just sound like a complainer, I actually think this makes rational business sense. The concept of peering was always "equal benefit", not "equal cost". No one ever compares the price of building last mile transport to the cost of building huge data centers all over with content close to the users. The whole "bit-mile" thing represents an insignificant portion of the cost, long haul (in large quantities) is dirt cheap compared to last mile or data center build costs. If you think of a pure content play peering with a pure eyeball play there is equal benefit, in fact symbiosis, neither could exist without the other. The traffic flow will be highly asymmetric. Eyeball networks also artificially cap their own ratios with their products. Cable and DSL are both 3x-10x down, x up products. Their TOS policies prohibit running servers. Any eyeball network with a asymmetric edge technology and no-server TOS need only look in the mirror to see why their aggregate ratio is hosed. Lastly, simple economics. Let's theorize about a large eyeball network with say 20M subscribers, and a large content network with say 100G of peering traffic to go to those subscribers. * Choice A would be to squeeze the peer for bad ratio in the hope of getting them to pay for, or be behind some other transit customer. Let's be generous and say $3/meg/month, so the 100G of traffic might generate $300,000/month of revenue. Let's even say you can squeeze 5 CDN's for that amount, $1.5M/month total. * Choice B would be to squeeze the subscribers for more revenue to carry the 100G of "imbalanced traffic". Perhaps an extra $0.10/sub/month. That would be $2M/month in extra revenue. Now, consider the customer satisfaction issue? Would your broadband customers pay an extra $0.10 per month if Netflix and Amazon streaming never went out in the middle of a movie? Would they move up to a higher tier of service? A smart end user ISP would find a way to get uncongested paths to the content their users want, and make it rock solid reliable. The good service will more than support not only cost recovery, but higher revenue levels than squeezing peers. Of course we have evidence that most end user ISP's are not smart, they squeeze peers and have some of the lowest customer satisfaction rankings of not just ISP's, but all service providers! They want to claim consumers don't want Gigabit fiber, but then congest peers so badly there's no reason for a consumer to pay for more than the slowest speed. Squeezing peers is a prime case of cutting off your nose to spite your face. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From freimer at freimer.org Thu Jun 20 23:21:10 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 20 Jun 2013 23:21:10 +0000 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: Message-ID: I, for one, would not be in favor of an authoritarian rule over DNS, or any other Internet system, to "ensure that the state of [the] service[s] is running as it should." I suppose one could view such an authoritarian rule over (sub) systems to be a good thing, as in there is someone to complain to when things don't work, but recent events show that it is also easily abused. I much rather prefer the current cooperative administration of the Internet. Thanks, Fred Reimer On 6/20/13 6:39 PM, "Phil Fagan" wrote: >....at what point is the Internet a piece of infrastructure whereby we >actually need a way to watch this thing holistically as it is one system >and not just a bunch of inter-jointed systems? Who's job is it to do >nothing but ensure that the state of DNS and other services is running as >it should....who's the clearing house here. > > >On Thu, Jun 20, 2013 at 4:28 PM, Randy Bush wrote: > >> netsol screwed up. they screwed up bigtime. they are shoveling kitty >> litter over it as fast as they can, and they have a professional kitty >> litter, aka pr, department. >> >> but none of this is surprising. >> >> and dnssec did not save us. is there anything which could have? >> >> randy >> >> >> > > >-- >Phil Fagan >Denver, CO >970-480-7618 From tmorizot at gmail.com Thu Jun 20 23:41:47 2013 From: tmorizot at gmail.com (Timothy Morizot) Date: Thu, 20 Jun 2013 18:41:47 -0500 Subject: Fwd: Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: On Jun 20, 2013 5:31 PM, "Randy Bush" wrote: > and dnssec did not save us. is there anything which could have? Hmmm. DNSSEC wouldn't have prevented an outage. But from everything I've seen reported, had the zones been signed, validating recursive resolvers (comcast, google, much of federal government, mine) would have returned servfail and would not have cached the bad nameservers in their good cache. Users would have simply failed to connect instead of being sent to the wrong page and recovery would have been quicker and easier. From my perspective as someone responsible for DNS at a fairly large enterprise, that would have been preferable. But then, the zones for which I'm responsible are signed. YMMV, Scott From mysidia at gmail.com Fri Jun 21 00:22:33 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Jun 2013 19:22:33 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: On 6/20/13, Randy Bush wrote: > netsol screwed up. they screwed up bigtime. they are shoveling kitty > litter over it as fast as they can, and they have a professional kitty > litter, aka pr, department. > but none of this is surprising. > and dnssec did not save us. is there anything which could have? What's puzzling is the "How the heck did they do that?" The registrar doesn't maintain the .COM database that contains the list of nameservers.... they had to submit changes to all those records. So, why weren't there security controls to make sure that the registrar could not submit changes without appropriate authorization from the Administrative/Tech contact? > randy -- -JH From rubensk at gmail.com Fri Jun 21 00:29:06 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 20 Jun 2013 21:29:06 -0300 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: On Thu, Jun 20, 2013 at 8:41 PM, Timothy Morizot wrote: > On Jun 20, 2013 5:31 PM, "Randy Bush" wrote: > > and dnssec did not save us. is there anything which could have? > > Hmmm. DNSSEC wouldn't have prevented an outage. But from everything I've > seen reported, had the zones been signed, validating recursive resolvers > (comcast, google, much of federal government, mine) would have returned > servfail and would not have cached the bad nameservers in their good cache. > > Users would have simply failed to connect instead of being sent to the > wrong page and recovery would have been quicker and easier. From my > perspective as someone responsible for DNS at a fairly large enterprise, > that would have been preferable. > > But then, the zones for which I'm responsible are signed. > In this case of registrar compromise, DS record could have been changed alongside NS records, so DNSSEC would only have been a early warning, because uncoordinated DS change disrupts service. As soon as previous timeouts played out, new DS/NS pairs would be considered as trustworthy as the old ones. Rubens From tmorizot at gmail.com Fri Jun 21 00:44:30 2013 From: tmorizot at gmail.com (Timothy Morizot) Date: Thu, 20 Jun 2013 19:44:30 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: On Jun 20, 2013 7:30 PM, "Rubens Kuhl" wrote: > In this case of registrar compromise, DS record could have been changed > alongside NS records, so DNSSEC would only have been a early warning, > because uncoordinated DS change disrupts service. As soon as previous > timeouts played out, new DS/NS pairs would be considered as trustworthy as > the old ones. Since DS records typically have a ttl of 24 hours, that protection should not be underestimated even in the case of registrar compromise. However, everything released so far indicates this was a netsol error and not a compromise. And it was an error corrected fairly quickly from what I can tell. The impact was prolonged because the bad nameservers were cached in resolvers across the Internet. Of course, very few details have actually been released, so that construction could be wrong. But even in the worst case DNSSEC would have provided some mitigation for a time. From jeff at ocjtech.us Fri Jun 21 00:45:59 2013 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 20 Jun 2013 19:45:59 -0500 Subject: Network diagnostics for the end user In-Reply-To: References: Message-ID: Are there any tools out there that we could give to our end users to help diagnose network problems? We get a lot of "the Internet is slow" support calls and it would be helpful if we had something that would run on the end user's computer and help characterize the problem. We have central monitoring system of course but that doesn't always give a complete picture, as the problem could always be on the end user's computer - slow hard drive, not enough memory, wrong name servers, etc. From ikiris at gmail.com Fri Jun 21 00:58:47 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 20 Jun 2013 19:58:47 -0500 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> Message-ID: It's only cutting off your nose to spite your face if you look at the internet BU in a vacuum. The issue comes when they can get far more money from their existing product line, than what they get being a dumb bandwidth pipe to their customers. They don't want reasonable or even unreasonable pricing per meg, they want content to pay for access to their customers in the same range of cost that they currently get from their other arm's subscribers or to sit down and shut up and stop competing with their much more profitable broadcast arm. Because they can't just charge a premium on the internet access itself, as their customers would leave due to competition from providers that *are* just dumb pipes to transit based content. -Blake On Thu, Jun 20, 2013 at 6:18 PM, Leo Bicknell wrote: > > On Jun 20, 2013, at 5:47 PM, Robert M. Enger wrote: > > > Perhaps last-mile operators should > > A) advertise each of their metropolitan regional systems as a separate AS > > B) establish an interconnection point in each region where they will > accept traffic destined for their in-region customers without charging any > fee > > C) Buck up and carry the traffic their customers are paying them to carry. > > Least I just sound like a complainer, I actually think this makes rational > business sense. > > The concept of peering was always "equal benefit", not "equal cost". No > one ever compares the price of building last mile transport to the cost of > building huge data centers all over with content close to the users. The > whole "bit-mile" thing represents an insignificant portion of the cost, > long haul (in large quantities) is dirt cheap compared to last mile or data > center build costs. If you think of a pure content play peering with a > pure eyeball play there is equal benefit, in fact symbiosis, neither could > exist without the other. The traffic flow will be highly asymmetric. > > Eyeball networks also artificially cap their own ratios with their > products. Cable and DSL are both 3x-10x down, x up products. Their TOS > policies prohibit running servers. Any eyeball network with a asymmetric > edge technology and no-server TOS need only look in the mirror to see why > their aggregate ratio is hosed. > > Lastly, simple economics. Let's theorize about a large eyeball network > with say 20M subscribers, and a large content network with say 100G of > peering traffic to go to those subscribers. > > * Choice A would be to squeeze the peer for bad ratio in the hope of > getting them to pay for, or be behind some other transit customer. Let's > be generous and say $3/meg/month, so the 100G of traffic might generate > $300,000/month of revenue. Let's even say you can squeeze 5 CDN's for that > amount, $1.5M/month total. > > * Choice B would be to squeeze the subscribers for more revenue to carry > the 100G of "imbalanced traffic". Perhaps an extra $0.10/sub/month. That > would be $2M/month in extra revenue. > > Now, consider the customer satisfaction issue? Would your broadband > customers pay an extra $0.10 per month if Netflix and Amazon streaming > never went out in the middle of a movie? Would they move up to a higher > tier of service? > > A smart end user ISP would find a way to get uncongested paths to the > content their users want, and make it rock solid reliable. The good > service will more than support not only cost recovery, but higher revenue > levels than squeezing peers. Of course we have evidence that most end user > ISP's are not smart, they squeeze peers and have some of the lowest > customer satisfaction rankings of not just ISP's, but all service > providers! They want to claim consumers don't want Gigabit fiber, but then > congest peers so badly there's no reason for a consumer to pay for more > than the slowest speed. > > Squeezing peers is a prime case of cutting off your nose to spite your > face. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From aaron at heyaaron.com Fri Jun 21 01:10:20 2013 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 20 Jun 2013 18:10:20 -0700 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> Message-ID: Maybe someone could enlighten my ignorance on this issue. Why is there a variable charge for bandwidth anyways? In a very simplistic setup, if I have a router that costs $X and I run a $5 CAT6 cable to someone elses router which cost them $Y, plus a bit of maintenance time to set up the connections, tweak ACLs, etc... So now there's an interconnect between two providers at 1 gigabit, and the only issue I see is the routers needing to be replaced within Z years when it dies or when it needs to handle a 10 gigabit connection. So it seems I should be able to say "Here's a 1 gigabit connection. It will cost $Q over Z years or you can pay $Q/Z yearly", etc... And wouldn't the costs go down if I had a bunch of dialup/DSL/cable/fiber users as they are paying to lower the costs of interconnects so they get content with less latency and fewer bottlenecks? -A On Thu, Jun 20, 2013 at 4:18 PM, Leo Bicknell wrote: > > On Jun 20, 2013, at 5:47 PM, Robert M. Enger wrote: > > > Perhaps last-mile operators should > > A) advertise each of their metropolitan regional systems as a separate AS > > B) establish an interconnection point in each region where they will > accept traffic destined for their in-region customers without charging any > fee > > C) Buck up and carry the traffic their customers are paying them to carry. > > Least I just sound like a complainer, I actually think this makes rational > business sense. > > The concept of peering was always "equal benefit", not "equal cost". No > one ever compares the price of building last mile transport to the cost of > building huge data centers all over with content close to the users. The > whole "bit-mile" thing represents an insignificant portion of the cost, > long haul (in large quantities) is dirt cheap compared to last mile or data > center build costs. If you think of a pure content play peering with a > pure eyeball play there is equal benefit, in fact symbiosis, neither could > exist without the other. The traffic flow will be highly asymmetric. > > Eyeball networks also artificially cap their own ratios with their > products. Cable and DSL are both 3x-10x down, x up products. Their TOS > policies prohibit running servers. Any eyeball network with a asymmetric > edge technology and no-server TOS need only look in the mirror to see why > their aggregate ratio is hosed. > > Lastly, simple economics. Let's theorize about a large eyeball network > with say 20M subscribers, and a large content network with say 100G of > peering traffic to go to those subscribers. > > * Choice A would be to squeeze the peer for bad ratio in the hope of > getting them to pay for, or be behind some other transit customer. Let's > be generous and say $3/meg/month, so the 100G of traffic might generate > $300,000/month of revenue. Let's even say you can squeeze 5 CDN's for that > amount, $1.5M/month total. > > * Choice B would be to squeeze the subscribers for more revenue to carry > the 100G of "imbalanced traffic". Perhaps an extra $0.10/sub/month. That > would be $2M/month in extra revenue. > > Now, consider the customer satisfaction issue? Would your broadband > customers pay an extra $0.10 per month if Netflix and Amazon streaming > never went out in the middle of a movie? Would they move up to a higher > tier of service? > > A smart end user ISP would find a way to get uncongested paths to the > content their users want, and make it rock solid reliable. The good > service will more than support not only cost recovery, but higher revenue > levels than squeezing peers. Of course we have evidence that most end user > ISP's are not smart, they squeeze peers and have some of the lowest > customer satisfaction rankings of not just ISP's, but all service > providers! They want to claim consumers don't want Gigabit fiber, but then > congest peers so badly there's no reason for a consumer to pay for more > than the slowest speed. > > Squeezing peers is a prime case of cutting off your nose to spite your > face. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From jared at puck.nether.net Fri Jun 21 02:26:39 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 20 Jun 2013 22:26:39 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> Message-ID: On Jun 20, 2013, at 9:10 PM, "Aaron C. de Bruyn" wrote: > Why is there a variable charge for bandwidth anyways? > > In a very simplistic setup, if I have a router that costs $X and I run a $5 > CAT6 cable to someone elses router which cost them $Y, plus a bit of > maintenance time to set up the connections, tweak ACLs, etc... > > So now there's an interconnect between two providers at 1 gigabit, and the > only issue I see is the routers needing to be replaced within Z years when > it dies or when it needs to handle a 10 gigabit connection. Many things aren't as obvious as you state above. Take for example routing table growth. There's going to be a big boom in selling routers (or turning off full routes) when folks devices melt at 512k routes in the coming years. Operating a router takes a lot of things, including power, space, people to rack it, swap failing or failed hardware, OPEX to the vendor to cover support contract (assuming you have one), fiber cleaning kits, new patch cables, optics, etc. These costs are variable per city and location as space/power can be different. This doesn't include telecom costs, which may be up/down depending on if you are using leased/dark/IRU or other services. Building fiber, data centers, can be quite capital expensive. Fiber, expect 50-100k per mile (for example). It can be even more depending on the market and situation. Much of that cost is in the labor to the technicians as well as local permits as opposed to what the fiber actually costs. Many people have fiber they built 10 years ago, or even older. Folks like AT&T have been breathing life into their copper plant that was built over the past 100 years. Having that existing right-of-way makes permit costs lower, or allows you to get a blanket permit for entire cities/counties in cases. Some cable company has a presentation out there (maybe it was at a cable labs conference, or otherwise) I saw about average breaks per year. This costs splicing crews that you either have to pay to be on call or outsource to a contract company for emergency restoration. http://www.southern-telecom.com/AFL%20Reliability.pdf has some details about these. > So it seems I should be able to say "Here's a 1 gigabit connection. It > will cost $Q over Z years or you can pay $Q/Z yearly", etc... > > And wouldn't the costs go down if I had a bunch of dialup/DSL/cable/fiber > users as they are paying to lower the costs of interconnects so they get > content with less latency and fewer bottlenecks? There was a presentation by Vijay about the costs of customer support. Many states have minimum wages higher than the federal minimum wage, but even that being said, you need to pay someone, train them, give them a computer, manager, phone and other guidance to provide support for billing, customer retention and sales. I recall Vijay saying that if a customer phoned for support it wiped out the entire profit from the customer for the lifetime of them being a customer. That may not still be the case, but there are costs each time you provide a staff person to answer that phone. Sometimes it's due to outage, sometimes it's PBKAC, sometimes you don't know and have to further research the issue. Your overhead costs may be much higher due to the type of other costs you bear (pension, union contracts, etc..) vs a competitor that doesn't have that same structure. This is often seen in the airline industry. I for one would like to see more competition in the last mile in the US, but I think the only people that will do it will be folks like sonic.net, google and other smaller independent telcos. Take someone like Allband Communications in Michigan. They brought POTS service (just recently) to locations that Verizon/AT&T were unwilling to build. The person who wanted the phone service ended up having to start a telco to get POTS service there. They just went triple-play since it was the same cost to trench fiber as to put in the copper. - Jared From jeff-kell at utc.edu Fri Jun 21 02:55:58 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 20 Jun 2013 22:55:58 -0400 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> Message-ID: <51C3C0BE.6050900@utc.edu> On 6/20/2013 10:26 PM, Jared Mauch wrote: > Many things aren't as obvious as you state above. Take for example routing table growth. There's going to be a big boom in selling routers (or turning off full routes) when folks devices melt at 512k routes in the coming years. Indeed. We're running PFC3CXL's and had already reallocated FIB TCAM to 768K IPv4s in anticipation. We also had maximum-prefix 500000 with a warning at 90%, and today it triggered (or at least first time I noticed it)... we ran > 450K prefixes from 3 providers about 1:30 EDT today and got the warnings. The end is near :) If you haven't made provisions, please do so now :) Jeff From hank at efes.iucc.ac.il Fri Jun 21 03:03:19 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 21 Jun 2013 06:03:19 +0300 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <1371766338.2374.3.camel@Andromeda> <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <1371766338.2374.3.camel@Andromeda> Message-ID: <5.1.1.6.2.20130621060215.01f8ee20@efes.iucc.ac.il> At 07:28 21/06/2013 +0900, Randy Bush wrote: >netsol screwed up. they screwed up bigtime. they are shoveling kitty >litter over it as fast as they can, and they have a professional kitty >litter, aka pr, department. They are too busy adding new revenue: http://www.streetinsider.com/Corporate+News/NetSol+%28NTWK%29+Enters+$10M+Agreement+for+Financial+Suite+Implementation/8434663.html -Hank From hank at efes.iucc.ac.il Fri Jun 21 03:09:36 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 21 Jun 2013 06:09:36 +0300 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <1371766338.2374.3.camel@Andromeda> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: <5.1.1.6.2.20130621060749.01f7bc90@efes.iucc.ac.il> At 17:12 20/06/2013 -0500, Richard Golodner wrote: > I think you are reading it the wrong way. Mr.Kletnieks never said it >was okay. He just stated that the numbers were trivial when compared to >the rest of potential customers being affected. > Be cool, Richard Golodner and Netsol agrees with you: http://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/ "a small number of Network Solutions customers were inadvertently affected for up to several hours." -Hank From nanog-post at rsuc.gweep.net Fri Jun 21 03:19:38 2013 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 20 Jun 2013 23:19:38 -0400 Subject: net neutrality and peering wars continue In-Reply-To: <20130620222601.GW55976@burnout.tpb.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <5548E336-5A14-4975-A308-0551D25DA183@delong.com> <20130620222601.GW55976@burnout.tpb.net> Message-ID: <20130621031938.GA28303@gweep.net> On Fri, Jun 21, 2013 at 12:26:01AM +0200, Niels Bakker wrote: [snip] > Also, if you don't have data, best to keep your opinion to yourself, > because you might well be wrong. The deuce you say! Replacing uninformed conjecture and conspiracy theories with actual data? Next thing you know there will be actual engineering discussions instead ... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG From hmurray at megapathdsl.net Fri Jun 21 03:25:24 2013 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 20 Jun 2013 20:25:24 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) Message-ID: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> > ....at what point is the Internet a piece of infrastructure whereby we > actually need a way to watch this thing holistically as it is one system and > not just a bunch of inter-jointed systems? Who's job is it to do nothing but > ensure that the state of DNS and other services is running as it > should....who's the clearing house here. > The Internet: Discovering new SPOF since 1969! :) Thanks. Perhaps we should setup a distributed system for checking things rather than another SPOF. That's distributed both geographically and administratively and using several code-bases. In this context, I'd expect lots of false alarms due to people changing their DNS servers but forgetting to inform their monitoring setup (either internal or outsourced). How would you check/verify that the communication path from the monitoring agency to the right people in your NOC was working correctly? -- These are my opinions. I hate spam. From jlewis at lewis.org Fri Jun 21 03:42:13 2013 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 20 Jun 2013 23:42:13 -0400 (EDT) Subject: net neutrality and peering wars continue In-Reply-To: <51C3C0BE.6050900@utc.edu> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> <51C3C0BE.6050900@utc.edu> Message-ID: On Thu, 20 Jun 2013, Jeff Kell wrote: > On 6/20/2013 10:26 PM, Jared Mauch wrote: >> Many things aren't as obvious as you state above. Take for example routing table growth. There's going to be a big boom in selling routers (or turning off full routes) when folks devices melt at 512k routes in the coming years. > > Indeed. We're running PFC3CXL's and had already reallocated FIB TCAM to > 768K IPv4s in anticipation. We also had maximum-prefix 500000 with a > warning at 90%, and today it triggered (or at least first time I noticed > it)... we ran > 450K prefixes from 3 providers about 1:30 EDT today and > got the warnings. > > The end is near :) If you haven't made provisions, please do so now :) It's like 2008 all over again, but worse. In 2008, the Sup2 was nearing the end of its ability to hold full v4 routes. The "good news" back then was that you could upgrade to Sup720-3bxls for a little more than (IIRC) about $10k per unit. This time, at least as of today, Cisco hasn't provided an upgrade path that'll keep the 6500 family usable for a full-table router when the "1 Million" route slots aren't enough to hold your 768k v4 routes and 128k v6 routes. At this rate, if they do produce a PFC that takes the 6500 to several million routes, it's probably going to be too late for those to be available in any real quantity on the secondary market. Maybe that's the plan. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ag4ve.us at gmail.com Fri Jun 21 03:42:24 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 20 Jun 2013 23:42:24 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> References: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> Message-ID: I think ICANN would have to add a delay in where a request was sent out to make sure everyone was on the same page and then what happens the couple thousand (more) times a day that someone isn't updated or is misconfigured? I think Netsol should be fined. Maybe even a class action suite filed against them for lost business. And that's it. On Jun 20, 2013 11:28 PM, "Hal Murray" wrote: > > > ....at what point is the Internet a piece of infrastructure whereby we > > actually need a way to watch this thing holistically as it is one system > and > > not just a bunch of inter-jointed systems? Who's job is it to do nothing > but > > ensure that the state of DNS and other services is running as it > > should....who's the clearing house here. > > > The Internet: Discovering new SPOF since 1969! > :) Thanks. > > Perhaps we should setup a distributed system for checking things rather > than > another SPOF. That's distributed both geographically and administratively > and using several code-bases. > > In this context, I'd expect lots of false alarms due to people changing > their > DNS servers but forgetting to inform their monitoring setup (either > internal > or outsourced). > > How would you check/verify that the communication path from the monitoring > agency to the right people in your NOC was working correctly? > > > -- > These are my opinions. I hate spam. > > > > > From Valdis.Kletnieks at vt.edu Fri Jun 21 03:45:13 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 Jun 2013 23:45:13 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: Your message of "Thu, 20 Jun 2013 20:25:24 -0700." <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> References: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> Message-ID: <54642.1371786313@turing-police.cc.vt.edu> On Thu, 20 Jun 2013 20:25:24 -0700, Hal Murray said: > How would you check/verify that the communication path from the monitoring > agency to the right people in your NOC was working correctly? Remember to consider the possible impact of a false-positive report over an unauthenticated channel. Because if it's possible, somebody will try it, just because they just want to watch stuff burn. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From khuon at NEEBU.Net Fri Jun 21 04:47:04 2013 From: khuon at NEEBU.Net (Jake Khuon) Date: Thu, 20 Jun 2013 21:47:04 -0700 Subject: Network diagnostics for the end user In-Reply-To: References: Message-ID: <51C3DAC8.1000801@NEEBU.Net> On 20/06/13 17:45, Jeffrey Ollie wrote: > Are there any tools out there that we could give to our end users to help > diagnose network problems? We get a lot of "the Internet is slow" support > calls and it would be helpful if we had something that would run on the end > user's computer and help characterize the problem. We have central > monitoring system of course but that doesn't always give a complete > picture, as the problem could always be on the end user's computer - slow > hard drive, not enough memory, wrong name servers, etc. I personally like ICSI Netalyzr for identifying gross issues. http://netalyzr.icsi.berkeley.edu/ -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From randy at psg.com Fri Jun 21 05:23:27 2013 From: randy at psg.com (Randy Bush) Date: Fri, 21 Jun 2013 14:23:27 +0900 Subject: Network diagnostics for the end user In-Reply-To: <51C3DAC8.1000801@NEEBU.Net> References: <51C3DAC8.1000801@NEEBU.Net> Message-ID: > I personally like ICSI Netalyzr for identifying gross issues. > http://netalyzr.icsi.berkeley.edu/ +42 From woody at pch.net Fri Jun 21 08:54:42 2013 From: woody at pch.net (Bill Woodcock) Date: Fri, 21 Jun 2013 01:54:42 -0700 Subject: net neutrality and peering wars continue In-Reply-To: <20130620203956.GV55976@burnout.tpb.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> Message-ID: <55F0705A-34A2-4071-AB09-0259B2D72F7A@pch.net> On Jun 20, 2013, at 1:39 PM, Niels Bakker wrote: > You're mistaken if you think that CDNs have equal number of packets going in and out. I'm aware that neither the quantity nor the size of packets in each direction are equal. I'm just hard-pressed to think of a reason why this matters, and so tend to hand-wave about it a bit? To a rough approximation, flows are balanced. Someone requests something, and an answer follows. Requests tend to be small, but if someone requests something large, a large answer follows. Conversely, people also send things, which are followed by small acknowledgements. Again, this only matters if you place a great deal of importance both on the notion that size equals fairness, and that fairness is more important than efficiency. I would argue that neither are true. I'm far more interested in seeing the cost of Internet service go down, than seeing two providers saddled with equally high costs in the name of fairness. And costs go down most quickly when each provider retains the full incentivization of its own ability to minimize costs. Not when they have to worry about "fairness" in an arbitrary metric, relative to other providers. The only occasion I can think of when traffic flows of symmetric volume have an economic benefit are when a third party is imposing excess rent on circuits, such that the cost of upgrading capacity is higher than the cost of "traffic engineering" flows to fill reverse paths. And that's hardly the sort of mental pretzels I want carriers to be having to worry about, instead of moving bits to customers. > I think the point is here that networks are nudging these decisions by making certain services suck more than others by way of preferential network access. I agree completely that that's the problem. But it didn't appear to be what Benson was talking about. -Bill From mysidia at gmail.com Fri Jun 21 10:00:21 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 21 Jun 2013 05:00:21 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> References: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> Message-ID: On 6/20/13, Hal Murray wrote: > Perhaps we should setup a distributed system for checking things rather than > another SPOF. That's distributed both geographically and administratively > and using several code-bases. [snip] I would be in favor of being able to pay two "competitive" to be registrars for a domain, and assign them two roles: "Registrar Primary" and "Registrar Auditor" With the requirement that all changes to the domain be initiated with my "Primary Registrar", AND no major change would be allowed to take effect until validated by my secondary "change Auditor Registrar" Including changes to NS records, DS records, contacts, unlocking, renewal, deactivation, or transfers. Essentially, forcing me to submit the same change to both registrars, but denying either registrar the capability of forging authorization or submitting changes that I had not authorized. Also (in some measure) protecting me from identity theft, and other security issues -- since there are now two accounts with two providers, possibly with different authentication procedures. -- -JH From mysidia at gmail.com Fri Jun 21 10:02:03 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 21 Jun 2013 05:02:03 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <32662.1371763697@turing-police.cc.vt.edu> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: On 6/20/13, Valdis.Kletnieks at vt.edu wrote: > > It's relatively small when you consider there's something like 140M .com's Yeah... I'm in agreement about that's probably what is going on... It's relatively small, but absolutely large, and absolute numbers matter. 5 domains is small, 50k is not, even if Netsol has a 100 billion domains. If I had 50,000 fingers; I might think differently. But the definition of a large number doesn't change to people, just because you also have a massive number of that thing. The phrase "a small number" means an absolutely small number, so it seems like a really really misleading if not possibly dishonest PR spin; they could have said "a small proportion" or "a relatively small number", in that case. -- -JH From eugen at leitl.org Fri Jun 21 10:32:09 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 21 Jun 2013 12:32:09 +0200 Subject: Server Sky - Internet and computation in orbit Message-ID: <20130621103209.GD22824@leitl.org> (This may be Wacky Friday, but this one is not tongue in cheek -- the name Keith Lofstrom should ring a bell). http://server-sky.com/ Server Sky - internet and computation in orbit It is easier to move terabits than kilograms or megawatts. Space solar power will solve the energy crisis. Sooner if we process space power into high value computation before we send it to earth. Computation is most valuable where it is rarest - in the rural developing world. Human attention is the most valuable resource on earth, and Server Sky space-based internet can transport that attention from where it is most abundant to where it is most valued. Click RecentChanges on any page to see what I've been working on lately. This website is a public work in progress - warts and all. Server Sky thinsats are ultralight films of glass that convert sunlight into computation and communications. Powered by solar cells, propelled and steered by light pressure, networked and located by microwaves, and cooled by radiation into deep space. Arrays of tens of thousands of thinsats act as highly redundant computation and database servers, as well as phased array antennas to reach thousands of transceivers on the ground. First generation thinsats are 20 centimeters across (about 8 inches) and 0.08 millimeters (80 microns) thick, and weigh 5 grams. They can be mass produced with off-the-shelf semiconductor and display technologies. Thousands of radio chips provide intra-array, inter-array, and ground communication, as well as precise location information. Thinsats are launched stacked by the thousands in solid cylinders, shrouded and vibration isolated inside a traditional satellite bus. Traditional data centers consume almost 3% of US electrical power, and this fraction is growing rapidly. Server arrays in orbit can grow to virtually unlimited computation power, communicate with the whole world, pay for themselves with electricity savings, and greatly reduce pollution and resource usage in the biosphere. The goal is an energy and space launch growth path that follows Moore's Law, with the cost of energy and launch halving every two years. Server Sky may cost two to ten times as much as ground-based computation in 2015, but is may cost 100 times less in 2035. The computation growth driven by Moore's Law is solving difficult problems from genetics to improved manufacture for semiconductors. If Server Sky and Moore's Law can do the same for clean energy, we can get rid of the carbon fuel plants, undam the rivers, and reduce atmospheric CO2 far sooner than we had dared hope. Energy production systems based on manual manufacturing, human construction assembly, and the use of terrestrial land, biological habitat, and surface water, packaged to survive weather, gravity, and corrosion, cannot grow at the same rate as Moore's Law. Server Sky is speculative. The most likely technical showstopper is radiation damage. The most likely practical showstopper is misunderstanding. Working together, we can fix the latter. Why Bother? 212 Acres and a Marble Thinsat Detailed Description Thinsat Propulsion and Navigation Deployment orbits Launching Thinsats from Earth Radios for communication, interconnect, synchronization, radar, and orientation The Space Environment - Radiation, Drag, Collisions, Erosion Manufacturing Thinsats Biological and Environmental Effects Future Possibilities - low cost launch, terascale arrays, beam power to Earth, scientific sensors Criticism Contact Us Participate . . . . Mailing List Signup] The Launch Loop, a speculative space launch system useful for launching Server Sky. This website is under construction - many of the sections need filling in. If you want to improve spelling, add expertise, etc... send me an ASCII (not html) email and I will add you to the editor's list. From bkain1 at ford.com Fri Jun 21 12:26:06 2013 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Fri, 21 Jun 2013 12:26:06 +0000 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <5.1.1.6.2.20130621060749.01f7bc90@efes.iucc.ac.il> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <5.1.1.6.2.20130621060749.01f7bc90@efes.iucc.ac.il> Message-ID: <7DB845D64966DC44A1CC592780539B4BE752B6@nafmbx47.exchange.ford.com> I remember when I used to own a small ISP and NetSOL "lost" 1/3 of the domains. Just lost them. And it wasn't a DDOS, it was their screw up. It went on for days -----Original Message----- From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] Sent: Thursday, June 20, 2013 11:10 PM To: Richard Golodner Cc: nanog at nanog.org Subject: Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS) At 17:12 20/06/2013 -0500, Richard Golodner wrote: > I think you are reading it the wrong way. Mr.Kletnieks never said it >was okay. He just stated that the numbers were trivial when compared to >the rest of potential customers being affected. > Be cool, Richard Golodner and Netsol agrees with you: http://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/ "a small number of Network Solutions customers were inadvertently affected for up to several hours." -Hank From bensons at queuefull.net Fri Jun 21 14:20:21 2013 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 21 Jun 2013 10:20:21 -0400 Subject: net neutrality and peering wars continue In-Reply-To: <55F0705A-34A2-4071-AB09-0259B2D72F7A@pch.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <55F0705A-34A2-4071-AB09-0259B2D72F7A@pch.net> Message-ID: <51C46125.3020405@queuefull.net> On 2013-06-21 4:54 AM, Bill Woodcock wrote: > Again, this only matters if you place a great deal of importance both on the notion that size equals fairness, and that fairness is more important than efficiency. > ... >> I think the point is here that networks are nudging these decisions by making certain services suck more than others by way of preferential network access. > I agree completely that that's the problem. But it didn't appear to be what Benson was talking about. > It's clear to me that you don't understand what I've said. But whether you're being obtuse or simply disagreeing, there is little value in repeating my specific points. Instead, in hope of encouraging useful discussion, I'll try to step back and describe things more broadly. The behaviors of networks are driven (in almost all cases) by the needs of business. In other words, decisions about peering, performance, etc, are all driven by a P&L sheet. So, clearly, these networks will try to minimize their costs (whether "fair" or not). And any imbalance between peers' cost burdens is an easy target. If one peer's routing behavior forces the other to carry more traffic a farther distance, then there is likely to be a dispute at some point - contrary to some hand-wave comments, carrying multiple gigs of traffic across the continent does have a meaningful cost, and pushing that cost onto somebody else is good for business. This is where so-called "bit mile peering" agreements can help - neutralize arguments about balance in order to focus on what matters. Of course there is still the "P" side of a P&L sheet to consider, and networks will surely attempt to capture some of the success of their peers' business models. But take away the legitimate "fairness" excuses and we can see the real issue in these cases. Not that we have built the best (standard, interoperable, cheap) tools to make bit-mile peering possible... But that's a good conversation to have. Cheers, -Benson From owen at delong.com Fri Jun 21 14:48:32 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Jun 2013 16:48:32 +0200 Subject: net neutrality and peering wars continue In-Reply-To: <51C46125.3020405@queuefull.net> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <55F0705A-34A2-4071-AB09-0259B2D72F7A@pch.net> <51C46125.3020405@queuefull.net> Message-ID: On Jun 21, 2013, at 4:20 PM, Benson Schliesser wrote: > On 2013-06-21 4:54 AM, Bill Woodcock wrote: >> Again, this only matters if you place a great deal of importance both on the notion that size equals fairness, and that fairness is more important than efficiency. >> ... >>> I think the point is here that networks are nudging these decisions by making certain services suck more than others by way of preferential network access. >> I agree completely that that's the problem. But it didn't appear to be what Benson was talking about. >> > > It's clear to me that you don't understand what I've said. But whether you're being obtuse or simply disagreeing, there is little value in repeating my specific points. Instead, in hope of encouraging useful discussion, I'll try to step back and describe things more broadly. > > The behaviors of networks are driven (in almost all cases) by the needs of business. In other words, decisions about peering, performance, etc, are all driven by a P&L sheet. This isn't exactly true and it turns out that the subtle difference from this fact is very important. They are driven not by a P&L sheet, but by executive's opinions of what will improve the P&L sheet. There is ample evidence that promiscuous peering can actually reduce costs across the board and increase revenues, image, good will, performance, and even transit purchases. There is also evidence that turning off peers tends to hamper revenue growth, degrade performance, create a negative image for the organization, reduce good will, etc. One need look no further than the history of SPRINT for a graphic example. In the early 2000's when SPRINT started depeering, they were darn near the epicenter of internet transit. Today, they're yet another also ran among major telco-based ISPs. Sure, their peering policy alone is likely not the only cause of this decline in stature, but it certainly contributed. > So, clearly, these networks will try to minimize their costs (whether "fair" or not). And any imbalance between peers' cost burdens is an easy target. If one peer's routing behavior forces the other to carry more traffic a farther distance, then there is likely to be a dispute at some point - contrary to some hand-wave comments, carrying multiple gigs of traffic across the continent does have a meaningful cost, and pushing that cost onto somebody else is good for business. Reasonable automation means that it costs nearly nothing to add peers at public exchange points once you are present at that exchange point. The problem with looking only at the cost of moving the bits around in this equation is that it ignores where the value proposition for delivering those bits lies. In reality, if an eyeball ISP doesn't maintain sufficient peering relationships to deliver the traffic the eyeballs are requesting, the eyeballs will become displeased with said ISP. In many cases, this is less relevant than it should be because the eyeball network is either a true monopoly, an effective monopoly (30/10Mbps cable vs. 1.5Mbps/384k DSL means that cable is an effective monopoly for all practical purposes), or a duopoly where both choices are nearly equally poor. In markets served by multiple high speed providers, you tend to find that consumers gravitate towards the ones that don't engage in peering wars to the point that they degrade service to those customers. On the other hand, if a content provider does not maintain sufficient capacity to reach the eyeball networks in a way that the eyeball networks are willing to accept said traffic, the content provider is at risk of losing subscribers. Since content tends to have many competitors capable of delivering an equivalent service, content providers have less leverage in any such dispute. Their customers don't want to hear "You're on Comcast and they don't like us" as an excuse when the service doesn't work. They'll go find a provider Comcast likes. The bottom line is that these ridiculous disputes are expensive to both sides and degrade service for their mutual customers. I make a point of opening tickets every time this becomes a performance issue for me. If more consumers did, then perhaps that cost would help drive better decisions from the executives at these providers. The other problem that plays into this is, as someone noted, many of these providers are in the internet business as a secondary market for revenue added to their primary business. They'd rather not see their primary business revenues driven onto the internet and off of their traditional services. As such, there is a perceived P&L gain to the other services by degrading the performance of competing services delivered over the internet. Attempting to use this fact to leverage (extort) money from the content providers to make up those revenues also makes for an easy target in the board room. > This is where so-called "bit mile peering" agreements can help - neutralize arguments about balance in order to focus on what matters. Of course there is still the "P" side of a P&L sheet to consider, and networks will surely attempt to capture some of the success of their peers' business models. But take away the legitimate "fairness" excuses and we can see the real issue in these cases. The problem I see with "bit mile peering" agreements is that the measurement of traffic that would be necessary to make such an agreement function reliably and verifiably by both sides would likely cost more than the moving of the traffic in question. I'd hate to see the internet degrade to telco style billing where it often cost $0.90 of every $1 collected to cover the costs of the call accounting and billing systems. > Not that we have built the best (standard, interoperable, cheap) tools to make bit-mile peering possible... But that's a good conversation to have. It might be an interesting conversation to have, but at the end of the day, I am concerned that the costs of the tools and their operations exceeds the cost being accounted. In such a case, it is often better to simply write off the cost. It's like trying to recover all the screws/nuts/washers that fall on the floor in an assembly plant in order to save money. The cost of retrieving and sorting them vastly exceeds their value. Owen From dwhite at olp.net Fri Jun 21 14:56:18 2013 From: dwhite at olp.net (Dan White) Date: Fri, 21 Jun 2013 09:56:18 -0500 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130609161033.GA16372@dan.olp.net> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> Message-ID: <20130621145618.GC7243@dan.olp.net> On 06/09/13?11:10?-0500, Dan White wrote: >Let me put my gold tipped tinfoil hat on in response to your statement. http://www.guardian.co.uk/world/2013/jun/20/fisa-court-nsa-without-warrant If accurate, this is extremely concerning: Top secret documents submitted to the court that oversees surveillance by US intelligence agencies show the judges have signed off on broad orders which allow the NSA to make use of information "inadvertently" collected from domestic US communications without a warrant. The documents show that even under authorities governing the collection of foreign intelligence from foreign targets, US communications can still be collected, retained and used. ...However, alongside those provisions, the Fisa court-approved policies allow the NSA to: ? Keep data that could potentially contain details of US persons for up to five years; Retain and make use of "inadvertently acquired" domestic communications if they contain usable intelligence, information on criminal activity, threat of harm to people or property, are encrypted, or are believed to contain any information relevant to cybersecurity; All protections afforded by the fourth amendment have essentially been thrown into the (rather large) bit bucket by the FISA court, when it comes to any bits which leave your premise. -- Dan White From Valdis.Kletnieks at vt.edu Fri Jun 21 15:08:50 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 21 Jun 2013 11:08:50 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: Your message of "Thu, 20 Jun 2013 23:42:24 -0400." References: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> Message-ID: <21242.1371827330@turing-police.cc.vt.edu> On Thu, 20 Jun 2013 23:42:24 -0400, shawn wilson said: > I think Netsol should be fined. Maybe even a class action suite filed > against them for lost business. And that's it. So your contract with NetSol has an SLA guarantee in it, and you can demonstrate that (a) said SLA has been violated and (b) that NetSol has not made the contracted restitution? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From philfagan at gmail.com Fri Jun 21 15:10:14 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 21 Jun 2013 09:10:14 -0600 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <20130621145618.GC7243@dan.olp.net> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <20130621145618.GC7243@dan.olp.net> Message-ID: I would think this is only an issue if they throw out the Fourth in that when they use that data collected "inadvertantly" to build a case a against you they use no other data collected under a proper warrent. If the purpose was to actually collect data on you, in the event you do something , they can simply run a query against this data post court order...then that's crossing the line. I personally think there is nothing wrong with monitoring US communications - big difference between monitoring US communications and monitoring US persons communications. On Fri, Jun 21, 2013 at 8:56 AM, Dan White wrote: > On 06/09/13 11:10 -0500, Dan White wrote: > >> Let me put my gold tipped tinfoil hat on in response to your statement. >> > > http://www.guardian.co.uk/**world/2013/jun/20/fisa-court-** > nsa-without-warrant > > If accurate, this is extremely concerning: > > > > Top secret documents submitted to the court that oversees surveillance > by US > intelligence agencies show the judges have signed off on broad orders > which > allow the NSA to make use of information "inadvertently" collected from > domestic US communications without a warrant. > > The documents show that even under authorities governing the collection > of > foreign intelligence from foreign targets, US communications can still be > collected, retained and used. > > ...However, alongside those provisions, the Fisa court-approved policies > allow the NSA to: > > ? Keep data that could potentially contain details of US persons for up > to five years; > > Retain and make use of "inadvertently acquired" domestic communications > if they contain usable intelligence, information on criminal activity, > threat of harm to people or property, are encrypted, or are believed to > contain any information relevant to cybersecurity; > > > > All protections afforded by the fourth amendment have essentially been > thrown into the (rather large) bit bucket by the FISA court, when it comes > to any bits which leave your premise. > > -- > Dan White > > -- Phil Fagan Denver, CO 970-480-7618 From owen at delong.com Fri Jun 21 15:19:51 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Jun 2013 17:19:51 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <20130621145618.GC7243@dan.olp.net> Message-ID: <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: > I would think this is only an issue if they throw out the Fourth in that when they use that data collected "inadvertantly" to build a case a against you they use no other data collected under a proper warrant. That statement ignores a longstanding legal principle known as "fruit of the poison tree". > If the purpose was to actually collect data on you, in the event you do something , they can simply run a query against this data post court order...then that's crossing the line. Indeed, they don't even seem to be required to bother with the court order any more. The standing FISA order seems to pretty much allow them to do all the required line crossing without any additional court order. > I personally think there is nothing wrong with monitoring US communications - big difference between monitoring US communications and monitoring US persons communications. It's pretty clear that they are likely monitoring both. Owen > > > On Fri, Jun 21, 2013 at 8:56 AM, Dan White wrote: > On 06/09/13 11:10 -0500, Dan White wrote: > Let me put my gold tipped tinfoil hat on in response to your statement. > > http://www.guardian.co.uk/world/2013/jun/20/fisa-court-nsa-without-warrant > > If accurate, this is extremely concerning: > > > > Top secret documents submitted to the court that oversees surveillance by US > intelligence agencies show the judges have signed off on broad orders which > allow the NSA to make use of information "inadvertently" collected from > domestic US communications without a warrant. > > The documents show that even under authorities governing the collection of > foreign intelligence from foreign targets, US communications can still be > collected, retained and used. > > ...However, alongside those provisions, the Fisa court-approved policies > allow the NSA to: > > ? Keep data that could potentially contain details of US persons for up > to five years; > > Retain and make use of "inadvertently acquired" domestic communications > if they contain usable intelligence, information on criminal activity, > threat of harm to people or property, are encrypted, or are believed to > contain any information relevant to cybersecurity; > > > > All protections afforded by the fourth amendment have essentially been > thrown into the (rather large) bit bucket by the FISA court, when it comes > to any bits which leave your premise. > > -- > Dan White > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 From philfagan at gmail.com Fri Jun 21 15:30:19 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 21 Jun 2013 09:30:19 -0600 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <20130621145618.GC7243@dan.olp.net> <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> Message-ID: Good point; apparently the doctorine does protect against the case whereby any collected data would have been found anway "with a court order." On Fri, Jun 21, 2013 at 9:19 AM, Owen DeLong wrote: > > On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: > > I would think this is only an issue if they throw out the Fourth in that > when they use that data collected "inadvertantly" to build a case a against > you they use no other data collected under a proper warrant. > > > That statement ignores a longstanding legal principle known as "fruit of > the poison tree". > > If the purpose was to actually collect data on you, in the event you do > something , they can simply run a query against this data post court > order...then that's crossing the line. > > > Indeed, they don't even seem to be required to bother with the court order > any more. The standing FISA order seems to pretty much allow them to do all > the required line crossing without any additional court order. > > I personally think there is nothing wrong with monitoring US > communications - big difference between monitoring US communications and > monitoring US persons communications. > > > It's pretty clear that they are likely monitoring both. > > Owen > > > > On Fri, Jun 21, 2013 at 8:56 AM, Dan White wrote: > >> On 06/09/13 11:10 -0500, Dan White wrote: >> >>> Let me put my gold tipped tinfoil hat on in response to your statement. >>> >> >> http://www.guardian.co.uk/**world/2013/jun/20/fisa-court-** >> nsa-without-warrant >> >> If accurate, this is extremely concerning: >> >> >> >> Top secret documents submitted to the court that oversees surveillance >> by US >> intelligence agencies show the judges have signed off on broad orders >> which >> allow the NSA to make use of information "inadvertently" collected from >> domestic US communications without a warrant. >> >> The documents show that even under authorities governing the collection >> of >> foreign intelligence from foreign targets, US communications can still >> be >> collected, retained and used. >> >> ...However, alongside those provisions, the Fisa court-approved policies >> allow the NSA to: >> >> ? Keep data that could potentially contain details of US persons for up >> to five years; >> >> Retain and make use of "inadvertently acquired" domestic >> communications >> if they contain usable intelligence, information on criminal activity, >> threat of harm to people or property, are encrypted, or are believed >> to >> contain any information relevant to cybersecurity; >> >> >> >> All protections afforded by the fourth amendment have essentially been >> thrown into the (rather large) bit bucket by the FISA court, when it comes >> to any bits which leave your premise. >> >> -- >> Dan White >> >> > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > > > -- Phil Fagan Denver, CO 970-480-7618 From nicolai-nanog at chocolatine.org Fri Jun 21 16:15:35 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Fri, 21 Jun 2013 11:15:35 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <32662.1371763697@turing-police.cc.vt.edu> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: <20130621161534.GA14380@vectra.student.iastate.edu> On Thu, Jun 20, 2013 at 05:28:17PM -0400, Valdis.Kletnieks at vt.edu wrote: > It's relatively small when you consider there's something like 140M .com's Just FWIW, the current size of .com is roughly 109M domains. Someday it will reach 140M but not today. Nicolai From davidianwalker at gmail.com Fri Jun 21 16:50:30 2013 From: davidianwalker at gmail.com (David Walker) Date: Sat, 22 Jun 2013 02:20:30 +0930 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: Message-ID: > https://www.networksolutions.com/blog/2013/06/important-update-for-network-solutions-customers-experiencing-website-issues/ Why are they infinitely looping a script on their web server to check for a cookie? Are these people insane? From johnl at iecc.com Fri Jun 21 18:01:02 2013 From: johnl at iecc.com (John Levine) Date: 21 Jun 2013 18:01:02 -0000 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: Message-ID: <20130621180102.93770.qmail@joyce.lan> >"Registrar Primary" and "Registrar Auditor" There are certainly registrars who are more security oriented than Netsol. If you haven't followed all of the corporate buying and selling, Netsol is now part of web.com, so their business is more to support web hosting than to be a registrar. I expect that if you put your domain at Markmonitor or CSC corporate domains, you would not have this problem, and you would pay accordingly. From bill at herrin.us Fri Jun 21 18:31:46 2013 From: bill at herrin.us (William Herrin) Date: Fri, 21 Jun 2013 14:31:46 -0400 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <20130621145618.GC7243@dan.olp.net> <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> Message-ID: On Fri, Jun 21, 2013 at 11:19 AM, Owen DeLong wrote: > On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: >> I would think this is only an issue if they throw out the Fourth in that when >> they use that data collected "inadvertantly" to build a case a against you >> they use no other data collected under a proper warrant. > > That statement ignores a longstanding legal principle known as "fruit of the poison tree". Howdy, In spite of what you may have seen on TV, law enforcement is not required to ignore evidence of a crime which turns up during a lawful search merely because it's evidence of a different crime. Fruit of the poisonous tree applies when the original search for whatever it was they were originally looking for is unlawful. Supposedly the FISA court found the NSA's troll for terrorists to be lawful. Once that's true, evidence of any crime may be lawfully introduced in court. For a fun read, check out the Ilustrated Guide to Criminal Law: http://lawcomic.net/guide/?p=18 Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cscora at apnic.net Fri Jun 21 18:33:19 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Jun 2013 04:33:19 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201306211833.r5LIXJtM016464@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Jun, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 457502 Prefixes after maximum aggregation: 186225 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 227498 Total ASes present in the Internet Routing Table: 44356 Prefixes per ASN: 10.31 Origin-only ASes present in the Internet Routing Table: 34763 Origin ASes announcing only one prefix: 16168 Transit ASes present in the Internet Routing Table: 5859 Transit-only ASes present in the Internet Routing Table: 143 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 1392 Unregistered ASNs in the Routing Table: 609 Number of 32-bit ASNs allocated by the RIRs: 4809 Number of 32-bit ASNs visible in the Routing Table: 3734 Prefixes from 32-bit ASNs in the Routing Table: 10899 Special use prefixes present in the Routing Table: 25 Prefixes being announced from unallocated address space: 222 Number of addresses announced to Internet: 2642684428 Equivalent to 157 /8s, 132 /16s and 42 /24s Percentage of available address space announced: 71.4 Percentage of allocated address space announced: 71.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.6 Total number of prefixes smaller than registry allocations: 160098 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110296 Total APNIC prefixes after maximum aggregation: 33646 APNIC Deaggregation factor: 3.28 Prefixes being announced from the APNIC address blocks: 112510 Unique aggregates announced from the APNIC address blocks: 46108 APNIC Region origin ASes present in the Internet Routing Table: 4852 APNIC Prefixes per ASN: 23.19 APNIC Region origin ASes announcing only one prefix: 1220 APNIC Region transit ASes present in the Internet Routing Table: 819 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 583 Number of APNIC addresses announced to Internet: 725408992 Equivalent to 43 /8s, 60 /16s and 220 /24s Percentage of available APNIC address space announced: 84.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 158910 Total ARIN prefixes after maximum aggregation: 80418 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 159578 Unique aggregates announced from the ARIN address blocks: 74067 ARIN Region origin ASes present in the Internet Routing Table: 15746 ARIN Prefixes per ASN: 10.13 ARIN Region origin ASes announcing only one prefix: 5994 ARIN Region transit ASes present in the Internet Routing Table: 1644 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1081744192 Equivalent to 64 /8s, 122 /16s and 27 /24s Percentage of available ARIN address space announced: 57.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 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 117878 Total RIPE prefixes after maximum aggregation: 60243 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 120804 Unique aggregates announced from the RIPE address blocks: 78364 RIPE Region origin ASes present in the Internet Routing Table: 17245 RIPE Prefixes per ASN: 7.01 RIPE Region origin ASes announcing only one prefix: 8181 RIPE Region transit ASes present in the Internet Routing Table: 2830 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2360 Number of RIPE addresses announced to Internet: 656483940 Equivalent to 39 /8s, 33 /16s and 38 /24s Percentage of available RIPE address space announced: 95.4 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-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 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, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 48510 Total LACNIC prefixes after maximum aggregation: 9360 LACNIC Deaggregation factor: 5.18 Prefixes being announced from the LACNIC address blocks: 52885 Unique aggregates announced from the LACNIC address blocks: 24810 LACNIC Region origin ASes present in the Internet Routing Table: 1968 LACNIC Prefixes per ASN: 26.87 LACNIC Region origin ASes announcing only one prefix: 583 LACNIC Region transit ASes present in the Internet Routing Table: 356 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 766 Number of LACNIC addresses announced to Internet: 132418440 Equivalent to 7 /8s, 228 /16s and 139 /24s Percentage of available LACNIC address space announced: 78.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10911 Total AfriNIC prefixes after maximum aggregation: 2517 AfriNIC Deaggregation factor: 4.33 Prefixes being announced from the AfriNIC address blocks: 11503 Unique aggregates announced from the AfriNIC address blocks: 3944 AfriNIC Region origin ASes present in the Internet Routing Table: 640 AfriNIC Prefixes per ASN: 17.97 AfriNIC Region origin ASes announcing only one prefix: 190 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46313472 Equivalent to 2 /8s, 194 /16s and 176 /24s Percentage of available AfriNIC address space announced: 46.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2944 11561 922 Korea Telecom (KIX) 17974 2556 855 91 PT TELEKOMUNIKASI INDONESIA 7545 2010 320 109 TPG Internet Pty Ltd 4755 1749 391 191 TATA Communications formerly 9829 1518 1205 40 BSNL National Internet Backbo 7552 1494 1082 9 Vietel Corporation 9583 1284 98 539 Sify Limited 4808 1146 2124 334 CNCGROUP IP network: China169 9498 1135 309 71 BHARTI Airtel Ltd. 24560 1077 394 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2998 3691 73 bellsouth.net, inc. 18566 2064 382 184 Covad Communications 1785 1993 678 125 PaeTec Communications, Inc. 22773 1984 2927 123 Cox Communications, Inc. 20115 1666 1617 617 Charter Communications 4323 1623 1137 402 Time Warner Telecom 701 1533 11143 800 UUNET Technologies, Inc. 30036 1336 301 645 Mediacom Communications Corp 7018 1301 11039 832 AT&T WorldNet Services 11492 1221 217 360 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1686 544 16 Corbina telecom 34984 1279 244 222 BILISIM TELEKOM 2118 1069 97 13 EUnet/RELCOM Autonomous Syste 20940 890 308 697 Akamai Technologies European 13188 825 98 79 Educational Network 31148 805 40 25 FreeNet ISP 8551 772 370 44 Bezeq International 6830 765 2376 439 UPC Distribution Services 12479 684 789 57 Uni2 Autonomous System 34744 675 172 76 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2804 1558 107 NET Servicos de Comunicao S.A 10620 2662 418 209 TVCABLE BOGOTA 7303 1732 1155 221 Telecom Argentina Stet-France 8151 1257 2719 384 UniNet S.A. de C.V. 18881 1001 844 20 Global Village Telecom 6503 864 434 64 AVANTEL, S.A. 27947 840 89 105 Telconet S.A 3816 715 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 6147 663 374 25 Telefonica Del Peru Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1237 80 4 MOBITEL 24863 883 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 464 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 261 922 219 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 29571 207 17 12 Ci Telecom Autonomous system 36992 198 527 21 Etisalat MISR 12258 193 28 66 Vodacom Internet Company Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2998 3691 73 bellsouth.net, inc. 4766 2944 11561 922 Korea Telecom (KIX) 28573 2804 1558 107 NET Servicos de Comunicao S.A 10620 2662 418 209 TVCABLE BOGOTA 17974 2556 855 91 PT TELEKOMUNIKASI INDONESIA 18566 2064 382 184 Covad Communications 7545 2010 320 109 TPG Internet Pty Ltd 1785 1993 678 125 PaeTec Communications, Inc. 22773 1984 2927 123 Cox Communications, Inc. 4755 1749 391 191 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2804 2697 NET Servicos de Comunicao S.A 17974 2556 2465 PT TELEKOMUNIKASI INDONESIA 10620 2662 2453 TVCABLE BOGOTA 4766 2944 2022 Korea Telecom (KIX) 7545 2010 1901 TPG Internet Pty Ltd 18566 2064 1880 Covad Communications 1785 1993 1868 PaeTec Communications, Inc. 22773 1984 1861 Cox Communications, Inc. 8402 1686 1670 Corbina telecom 4755 1749 1558 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.57.0/24 60993 Totalsoft SA 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:11 /10:30 /11:91 /12:250 /13:483 /14:900 /15:1603 /16:12707 /17:6652 /18:11188 /19:22220 /20:32166 /21:34525 /22:47754 /23:42327 /24:240620 /25:1303 /26:1659 /27:849 /28:46 /29:65 /30:19 /31:0 /32:17 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2015 2064 Covad Communications 6389 1721 2998 bellsouth.net, inc. 8402 1382 1686 Corbina telecom 22773 1289 1984 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1203 1336 Mediacom Communications Corp 11492 1183 1221 Cable One 1785 1062 1993 PaeTec Communications, Inc. 6983 1011 1141 ITC^Deltacom 10620 992 2662 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:832 2:836 3:3 4:19 5:800 6:15 8:557 12:1924 13:3 14:849 15:11 16:3 17:10 20:17 23:280 24:1769 27:1494 31:1262 32:43 33:2 34:5 36:47 37:1869 38:880 39:2 40:170 41:2780 42:202 44:8 46:1909 47:2 49:1322 50:734 52:12 54:35 55:7 57:26 58:1162 59:575 60:317 61:1411 62:1122 63:2027 64:4314 65:2159 66:4175 67:2073 68:1075 69:3271 70:856 71:489 72:1916 74:2475 75:322 76:303 77:1123 78:1028 79:612 80:1262 81:1008 82:624 83:582 84:540 85:1169 86:436 87:992 88:541 89:1747 90:147 91:5522 92:607 93:1721 94:1878 95:1668 96:515 97:346 98:1011 99:42 100:30 101:329 103:2834 105:517 106:142 107:207 108:513 109:1836 110:905 111:1060 112:546 113:814 114:712 115:973 116:980 117:841 118:1105 119:1323 120:388 121:733 122:1793 123:1214 124:1373 125:1419 128:638 129:223 130:310 131:662 132:358 133:155 134:268 135:67 136:223 137:245 138:350 139:192 140:210 141:330 142:532 143:382 144:500 145:94 146:507 147:380 148:670 149:348 150:157 151:533 152:420 153:189 154:23 155:414 156:270 157:397 158:279 159:727 160:344 161:448 162:451 163:222 164:604 165:498 166:243 167:596 168:1035 169:129 170:1052 171:181 172:21 173:1578 174:539 175:470 176:985 177:2083 178:1857 179:44 180:1457 181:466 182:1227 183:388 184:655 185:553 186:2268 187:1291 188:2147 189:1285 190:6802 192:6735 193:5671 194:4602 195:3438 196:1358 197:944 198:4494 199:5340 200:5988 201:2230 202:8827 203:8912 204:4516 205:2567 206:2801 207:2843 208:4055 209:3683 210:2943 211:1514 212:2181 213:1968 214:925 215:99 216:5310 217:1620 218:619 219:335 220:1306 221:553 222:325 223:457 End of report From philfagan at gmail.com Fri Jun 21 18:42:32 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 21 Jun 2013 12:42:32 -0600 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <20130621145618.GC7243@dan.olp.net> <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> Message-ID: I guess the moral here is....don't do anything "wrong." :-D On Fri, Jun 21, 2013 at 12:31 PM, William Herrin wrote: > On Fri, Jun 21, 2013 at 11:19 AM, Owen DeLong wrote: > > On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: > >> I would think this is only an issue if they throw out the Fourth in > that when > >> they use that data collected "inadvertantly" to build a case a against > you > >> they use no other data collected under a proper warrant. > > > > That statement ignores a longstanding legal principle known as "fruit of > the poison tree". > > Howdy, > > In spite of what you may have seen on TV, law enforcement is not > required to ignore evidence of a crime which turns up during a lawful > search merely because it's evidence of a different crime. Fruit of the > poisonous tree applies when the original search for whatever it was > they were originally looking for is unlawful. Supposedly the FISA > court found the NSA's troll for terrorists to be lawful. Once that's > true, evidence of any crime may be lawfully introduced in court. > > > For a fun read, check out the Ilustrated Guide to Criminal Law: > http://lawcomic.net/guide/?p=18 > > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Phil Fagan Denver, CO 970-480-7618 From wbailey at satelliteintelligencegroup.com Fri Jun 21 19:10:09 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 21 Jun 2013 19:10:09 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Message-ID: The United States Constitution* *See Terms and Conditions for details, not all citizens apply, void where prohibited, subject to change at any time. On 6/21/13 11:42 AM, "Phil Fagan" wrote: >I guess the moral here is....don't do anything "wrong." > >:-D > > >On Fri, Jun 21, 2013 at 12:31 PM, William Herrin wrote: > >> On Fri, Jun 21, 2013 at 11:19 AM, Owen DeLong wrote: >> > On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: >> >> I would think this is only an issue if they throw out the Fourth in >> that when >> >> they use that data collected "inadvertantly" to build a case a >>against >> you >> >> they use no other data collected under a proper warrant. >> > >> > That statement ignores a longstanding legal principle known as "fruit >>of >> the poison tree". >> >> Howdy, >> >> In spite of what you may have seen on TV, law enforcement is not >> required to ignore evidence of a crime which turns up during a lawful >> search merely because it's evidence of a different crime. Fruit of the >> poisonous tree applies when the original search for whatever it was >> they were originally looking for is unlawful. Supposedly the FISA >> court found the NSA's troll for terrorists to be lawful. Once that's >> true, evidence of any crime may be lawfully introduced in court. >> >> >> For a fun read, check out the Ilustrated Guide to Criminal Law: >> http://lawcomic.net/guide/?p=18 >> >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> > > >-- >Phil Fagan >Denver, CO >970-480-7618 From philfagan at gmail.com Fri Jun 21 19:11:13 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 21 Jun 2013 13:11:13 -0600 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: Message-ID: Hah! On Fri, Jun 21, 2013 at 1:10 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > The United States Constitution* > > *See Terms and Conditions for details, not all citizens apply, void where > prohibited, subject to change at any time. > > On 6/21/13 11:42 AM, "Phil Fagan" wrote: > > >I guess the moral here is....don't do anything "wrong." > > > >:-D > > > > > >On Fri, Jun 21, 2013 at 12:31 PM, William Herrin wrote: > > > >> On Fri, Jun 21, 2013 at 11:19 AM, Owen DeLong wrote: > >> > On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: > >> >> I would think this is only an issue if they throw out the Fourth in > >> that when > >> >> they use that data collected "inadvertantly" to build a case a > >>against > >> you > >> >> they use no other data collected under a proper warrant. > >> > > >> > That statement ignores a longstanding legal principle known as "fruit > >>of > >> the poison tree". > >> > >> Howdy, > >> > >> In spite of what you may have seen on TV, law enforcement is not > >> required to ignore evidence of a crime which turns up during a lawful > >> search merely because it's evidence of a different crime. Fruit of the > >> poisonous tree applies when the original search for whatever it was > >> they were originally looking for is unlawful. Supposedly the FISA > >> court found the NSA's troll for terrorists to be lawful. Once that's > >> true, evidence of any crime may be lawfully introduced in court. > >> > >> > >> For a fun read, check out the Ilustrated Guide to Criminal Law: > >> http://lawcomic.net/guide/?p=18 > >> > >> > >> Regards, > >> Bill Herrin > >> > >> > >> -- > >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us > >> 3005 Crane Dr. ...................... Web: > >> Falls Church, VA 22042-3004 > >> > >> > > > > > >-- > >Phil Fagan > >Denver, CO > >970-480-7618 > > -- Phil Fagan Denver, CO 970-480-7618 From michael at winkstreaming.com Fri Jun 21 19:56:02 2013 From: michael at winkstreaming.com (Michael McConnell) Date: Fri, 21 Jun 2013 13:56:02 -0600 Subject: /25's prefixes announced into global routing table? Message-ID: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Hello all, As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size? Cheers, Mike -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com From msa at latt.net Fri Jun 21 20:14:07 2013 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 21 Jun 2013 16:14:07 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Message-ID: <20130621201407.GA4370@puck.nether.net> On Fri, Jun 21, 2013 at 01:56:02PM -0600, Michael McConnell wrote: > As the IPv4 space get smaller and smaller, does anyone think we'll see > a time when /25's will be accepted for global BGP prefix announcement. > The current smallest size is a /24 and generally ok for most people, but > the crunch gets tighter, routers continue to have more and more ram will > it always be /24 the smallest size? RAM != FIB. The forwarding hardware is generally going to be the limit, and that's going to be painful enough as we approach a half million prefixes. You couldn't even consider such a thing until after that pain point. --msa From Grzegorz at Janoszka.pl Fri Jun 21 21:15:08 2013 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 21 Jun 2013 23:15:08 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Message-ID: <51C4C25C.50002@Janoszka.pl> On 21-06-13 21:56, Michael McConnell wrote: > As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size? As the fragmentation will progress and we will be closing to the magic limit of 500.000, people will filter out /24 and then /23 and so on. Back to static (default) routing! -- Grzegorz Janoszka From cidr-report at potaroo.net Fri Jun 21 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Jun 2013 22:00:01 GMT Subject: The Cidr Report Message-ID: <201306212200.r5LM01SV064991@wattle.apnic.net> This report has been generated at Fri Jun 21 21:13:56 2013 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 14-06-13 457227 260704 15-06-13 457743 260696 16-06-13 457703 260705 17-06-13 457783 260821 18-06-13 457828 260945 19-06-13 457884 260605 20-06-13 457589 260690 21-06-13 457753 261049 AS Summary 44478 Number of ASes in routing system 18393 Number of ASes announcing only one prefix 2998 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116801504 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 21Jun13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 458608 261038 197570 43.1% All ASes AS6389 2998 77 2921 97.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2802 107 2695 96.2% NET Servi?os de Comunica??o S.A. AS17974 2555 539 2016 78.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2950 958 1992 67.5% KIXS-AS-KR Korea Telecom AS10620 2662 828 1834 68.9% Telmex Colombia S.A. AS22773 1984 162 1822 91.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2064 474 1590 77.0% COVAD - Covad Communications Co. AS7303 1732 454 1278 73.8% Telecom Argentina S.A. AS4323 1627 406 1221 75.0% TWTC - tw telecom holdings, inc. AS4755 1748 586 1162 66.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1069 85 984 92.0% RELCOM-AS OOO "NPO Relcom" AS18881 1002 44 958 95.6% Global Village Telecom AS7552 1149 198 951 82.8% VIETEL-AS-AP Vietel Corporation AS36998 1237 301 936 75.7% SDN-MOBITEL AS1785 1993 1150 843 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1002 182 820 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1146 392 754 65.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1533 803 730 47.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 844 139 705 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS22561 1192 512 680 57.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS855 733 54 679 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1263 588 675 53.4% Uninet S.A. de C.V. AS6983 1141 478 663 58.1% ITCDELTA - ITC^Deltacom AS24560 1077 420 657 61.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 2019 1365 654 32.4% TPG-INTERNET-AP TPG Telecom Limited AS17676 735 112 623 84.8% GIGAINFRA Softbank BB Corp. AS6147 663 48 615 92.8% Telefonica del Peru S.A.A. AS31148 805 201 604 75.0% FREENET-AS Freenet Ltd. AS3549 1033 434 599 58.0% GBLX Global Crossing Ltd. AS4788 735 140 595 81.0% TMNET-AS-AP TM Net, Internet Service Provider Total 45493 12237 33256 73.1% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 115.31.64.0/20 AS17639 COMCLARK-AS ComClark Network & Technology Corp. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.50.176.0/24 AS38267 120.50.177.0/24 AS38267 120.50.178.0/24 AS38267 120.50.179.0/24 AS38267 120.50.180.0/24 AS38267 120.50.181.0/24 AS38267 120.50.182.0/24 AS38267 120.50.183.0/24 AS38267 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 179.107.160.0/19 AS28300 MMA ACESSORIOS E SERVICOS DE INFORMATICA LTDA. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 195.248.240.0/23 AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jun 21 22:00:03 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Jun 2013 22:00:03 GMT Subject: BGP Update Report Message-ID: <201306212200.r5LM03YJ065032@wattle.apnic.net> BGP Update Report Interval: 13-Jun-13 -to- 20-Jun-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 175465 8.0% 310.6 -- SDN-MOBITEL 2 - AS27947 123692 5.6% 180.6 -- Telconet S.A 3 - AS18403 42676 1.9% 78.6 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 4 - AS47331 34480 1.6% 16.4 -- TTNET TTNet A.S. 5 - AS60974 32953 1.5% 672.5 -- NAICOMS Naicoms EOOD 6 - AS14420 31318 1.4% 78.1 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 7 - AS8402 29694 1.4% 38.7 -- CORBINA-AS OJSC "Vimpelcom" 8 - AS9829 26166 1.2% 36.0 -- BSNL-NIB National Internet Backbone 9 - AS7552 18256 0.8% 16.7 -- VIETEL-AS-AP Vietel Corporation 10 - AS9416 16685 0.8% 1668.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - AS27738 15941 0.7% 27.8 -- Ecuadortelecom S.A. 12 - AS45899 15326 0.7% 41.0 -- VNPT-AS-VN VNPT Corp 13 - AS17974 15256 0.7% 6.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS8151 13724 0.6% 15.2 -- Uninet S.A. de C.V. 15 - AS4538 12369 0.6% 27.2 -- ERX-CERNET-BKB China Education and Research Network Center 16 - AS9854 11794 0.5% 5897.0 -- KTO-AS-KR KTO 17 - AS647 11391 0.5% 96.5 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 18 - AS52257 10975 0.5% 997.7 -- Telconet S.A 19 - AS53189 10651 0.5% 394.5 -- NS Telecomunica??es Ltda 20 - AS12880 10248 0.5% 64.9 -- DCI-AS Information Technology Company (ITC) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14733 6041 0.3% 6041.0 -- AS14733 - Barclays Capital Inc. 2 - AS9854 11794 0.5% 5897.0 -- KTO-AS-KR KTO 3 - AS19406 3990 0.2% 3990.0 -- TWRS-MA - Towerstream I, Inc. 4 - AS36225 3115 0.1% 3115.0 -- INFINITEIT-ASN-01 - Infinite IT Solutions Inc. 5 - AS6174 5846 0.3% 2923.0 -- SPRINTLINK8 - Sprint 6 - AS61141 2091 0.1% 2091.0 -- OST-AS OST CJSC 7 - AS48612 8786 0.4% 1757.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 8 - AS9416 16685 0.8% 1668.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 9 - AS28041 4896 0.2% 1632.0 -- PANCHONET S.A 10 - AS26124 9184 0.4% 1530.7 -- EOLNET-ECUADOR-ONLINE Grupo Coripar Corisat America 11 - AS37367 2904 0.1% 1452.0 -- CALLKEY 12 - AS22216 5340 0.2% 1335.0 -- SIEMENS-PLM - Siemens Corporation 13 - AS37402 1023 0.1% 1023.0 -- TELESURE 14 - AS28025 4089 0.2% 1022.2 -- CENTROSUR 15 - AS52257 10975 0.5% 997.7 -- Telconet S.A 16 - AS14453 7772 0.3% 971.5 -- AS-AKN - ADVANCED KNOWLEDGE NETWORKS 17 - AS22688 971 0.0% 971.0 -- DOLGENCORP - Dollar General Corporation 18 - AS12397 841 0.0% 841.0 -- OPTOCOM Optocom Ltd 19 - AS23295 838 0.0% 838.0 -- EA-01 - Extend America 20 - AS8137 4836 0.2% 806.0 -- DISNEYONLINE-AS - Disney Online TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 211.214.206.0/24 11790 0.5% AS9854 -- KTO-AS-KR KTO 2 - 92.246.207.0/24 8774 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 203.118.232.0/21 8358 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 203.118.224.0/21 8308 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 192.58.232.0/24 7448 0.3% AS6629 -- NOAA-AS - NOAA 6 - 202.41.70.0/24 6948 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 7 - 192.107.15.0/24 6041 0.3% AS14733 -- AS14733 - Barclays Capital Inc. 8 - 190.95.229.0/24 5797 0.2% AS27947 -- Telconet S.A 9 - 190.95.232.0/24 5780 0.2% AS27947 -- Telconet S.A 10 - 186.3.20.0/24 5780 0.2% AS27947 -- Telconet S.A 11 - 186.3.48.0/24 5768 0.2% AS27947 -- Telconet S.A 12 - 181.112.96.0/21 5746 0.2% AS14420 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 13 - 181.113.24.0/21 5508 0.2% AS14420 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 14 - 198.187.189.0/24 4826 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 15 - 173.232.234.0/24 4751 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 16 - 173.232.235.0/24 4750 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 17 - 64.26.208.0/24 4534 0.2% AS14453 -- AS-AKN - ADVANCED KNOWLEDGE NETWORKS 18 - 78.41.106.0/24 4526 0.2% AS34879 -- CCT-AS NGENIX 19 - 181.198.192.0/19 4493 0.2% AS52257 -- Telconet S.A 20 - 181.198.192.0/18 4476 0.2% AS27947 -- Telconet S.A Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From bzs at world.std.com Fri Jun 21 22:23:24 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 21 Jun 2013 18:23:24 -0400 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> Message-ID: <20932.53852.479125.175383@world.std.com> I think we need a better measure than number of domains (in this case .COM), particularly vs total domains. If it was 100 domains it might seem small, unless that list began with facebook.com, amazon.com, google.com and g*d forbid theworld.com. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jakob.heitz at ericsson.com Fri Jun 21 22:27:44 2013 From: jakob.heitz at ericsson.com (Jakob Heitz) Date: Fri, 21 Jun 2013 22:27:44 +0000 Subject: /25's prefixes announced into global routing table? In-Reply-To: References: Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> > Date: Fri, 21 Jun 2013 16:14:07 -0400 > From: "Majdi S. Abbas" > > On Fri, Jun 21, 2013 at 01:56:02PM -0600, Michael McConnell wrote: >> As the IPv4 space get smaller and smaller, does anyone think we'll >> see a time when /25's will be accepted for global BGP prefix >> announcement. The current smallest size is a /24 and generally ok >> for most people, but the crunch gets tighter, routers continue to >> have more and more ram will it always be /24 the smallest size? > > RAM != FIB. > > The forwarding hardware is generally going to be the limit, and > that's going to be painful enough as we approach a half million > prefixes. > > You couldn't even consider such a thing until after that pain > point. > > --msa There are techniques to fix that. For example, Simple Virtual Aggregation http://tools.ietf.org/html/rfc6769 -- Jakob Heitz. From owen at delong.com Fri Jun 21 22:23:59 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 00:23:59 +0200 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: References: <51B17ED8.2030604@invaluement.com> <20130607135030.GB8319@dan.olp.net> <51B1F810.7050706@invaluement.com> <20130607154207.GF8319@dan.olp.net> <20130609161033.GA16372@dan.olp.net> <20130621145618.GC7243@dan.olp.net> <8D3ACC12-DC67-492C-AE97-A0B134FF282F@delong.com> Message-ID: On Jun 21, 2013, at 8:31 PM, William Herrin wrote: > On Fri, Jun 21, 2013 at 11:19 AM, Owen DeLong wrote: >> On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: >>> I would think this is only an issue if they throw out the Fourth in that when >>> they use that data collected "inadvertantly" to build a case a against you >>> they use no other data collected under a proper warrant. >> >> That statement ignores a longstanding legal principle known as "fruit of the poison tree". > > Howdy, > > In spite of what you may have seen on TV, law enforcement is not > required to ignore evidence of a crime which turns up during a lawful > search merely because it's evidence of a different crime. Fruit of the > poisonous tree applies when the original search for whatever it was > they were originally looking for is unlawful. Supposedly the FISA > court found the NSA's troll for terrorists to be lawful. Once that's > true, evidence of any crime may be lawfully introduced in court. True? The question here, however, is whether these are really lawful searches. If we eliminate the need for any sort of check and balance and allow gross general permanent wiretapping, then there pretty much isn't a fourth amendment. I would argue that the FISA court has far overstepped its mandate (or at least failed to uphold its oversight role) and that the searches are, in fact, still unconstitutional. Owen From owen at delong.com Fri Jun 21 22:28:15 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 00:28:15 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Message-ID: <6B908B1F-0422-4129-8653-B2E27ACDAAD4@delong.com> Quite the opposite. As the technical limitations of the routing gear are reached, shorter and shorter prefixes will be tolerated until IPv4 is utterly unusable if we try to stay on IPv4 that long. Owen On Jun 21, 2013, at 9:56 PM, Michael McConnell wrote: > Hello all, > > As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size? > > Cheers, > Mike > > -- > > Michael McConnell > WINK Streaming; > email: michael at winkstreaming.com > phone: +1 312 281-5433 x 7400 > cell: +506 8706-2389 > skype: wink-michael > web: http://winkstreaming.com From joelja at bogus.com Fri Jun 21 23:01:51 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 21 Jun 2013 16:01:51 -0700 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C4C25C.50002@Janoszka.pl> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <51C4C25C.50002@Janoszka.pl> Message-ID: <51C4DB5F.50703@bogus.com> On 6/21/13 2:15 PM, Grzegorz Janoszka wrote: > On 21-06-13 21:56, Michael McConnell wrote: >> As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size? > As the fragmentation will progress and we will be closing to the magic > limit of 500.000, people will filter out /24 and then /23 and so on. > Back to static (default) routing! 500k is imho no different than 250k 128k 100k. Some devices are going to fall off the applecart. some folks will engage in heroic measures to police their fib size and the world will move on. million route and 2 million route fib platforms abound. if we cross the million mark in 10 years we're fine. if we cross it in 2 (which doesn't seem likely) then we have a problem. the v6 table imho is the one to watch. From bill at herrin.us Fri Jun 21 23:09:29 2013 From: bill at herrin.us (William Herrin) Date: Fri, 21 Jun 2013 19:09:29 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Message-ID: On Fri, Jun 21, 2013 at 3:56 PM, Michael McConnell wrote: > As the IPv4 space get smaller and smaller, does anyone think we'll > see a time when /25's will be accepted for global BGP prefix > announcement. The current smallest size is a /24 and generally > ok for most people, but the crunch gets tighter, routers continue > to have more and more ram will it always be /24 the smallest size? No. 1. Too many ASes whose operators are a part of too many cultures and speak too many languages apply a blind filter at /24. Too hard to change. 2. TCAM != RAM However.... It is possible for a tunnel provider to: 1. Draw a covering route in to a well chosen set of data centers, 2. Set up a nice redundant set of tunnels from each data center to each of its customers' Internet links, 3. Accept smaller-than-/24 routes at a higher priority than the tunnels from its peers where those routes originate from the customers to whom it assigned those addresses 4. Help the customers negotiate with the specific handful of ISPs that operate the paths between them so that they'll accept the sourced packets natively and propagate the smaller-than-/24 route within their system. It hasn't been done with any regularity, but it's technically feasible, can be implemented within a few percent of optimal routing and resilience and requires cooperation from few enough parties (all of them directly paid) that it could happen if the economics were right. On Fri, Jun 21, 2013 at 5:15 PM, Grzegorz Janoszka wrote: > As the fragmentation will progress and we will be closing to the magic > limit of 500.000, people will filter out /24 and then /23 and so on. > Back to static (default) routing! Don't bet heavy on that either. Many if not most of the Internet's critical resources (think: DNS roots) sit within /24 announcements. Incautious filtering shoots oneself in the foot. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Fri Jun 21 23:22:11 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 21 Jun 2013 18:22:11 -0500 Subject: /25's prefixes announced into global routing table? In-Reply-To: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Message-ID: On 6/21/13, Michael McConnell wrote: > Hello all, > As the IPv4 space get smaller and smaller, does anyone think we'll see a > time when /25's will be accepted for global BGP prefix announcement. The I am confident there are providers that will accept /25s from some of their customer(s) or peer(s); either due to negotiations with some of their customer(s); or as a result of ignorance or administrative error (failing to reject /25s, and not realizing it). > current smallest size is a /24 and generally ok for most people, but the Well, current smallest size intended to be accepted is /24 for many major providers. Some will be more restrictive. /24 is useful as a rule of thumb but not "an exact size" that every network allows. Further address fragmentation will eventually demand that networks become more restrictive, OR that the underlying protocol and hardware gets redesigned; which again, leads to netwroks becoming more restrictive, to avoid spending $$$ on hardware, software, and config upgrades. > crunch gets tighter, routers continue to have more and more ram will it > always be /24 the smallest size? > Cheers, > Mike -- -JH From johns at sstar.com Fri Jun 21 23:46:29 2013 From: johns at sstar.com (John Souvestre) Date: Fri, 21 Jun 2013 18:46:29 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: References: <20130621032524.2BA0B406060@ip-64-139-1-69.sjc.megapath.net> Message-ID: <009501ce6ed9$90d12fb0$b2738f10$@sstar.com> Hi Shawn. Or you could vote with your feet, and wish then a "fine" g'day. John John Souvestre - New Orleans LA - (504) 454-0899 -----Original Message----- From: shawn wilson [mailto:ag4ve.us at gmail.com] Sent: Thursday, June 20, 2013 10:42 pm To: Hal Murray Cc: North American Network Operators Group Subject: Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS) I think ICANN would have to add a delay in where a request was sent out to make sure everyone was on the same page and then what happens the couple thousand (more) times a day that someone isn't updated or is misconfigured? I think Netsol should be fined. Maybe even a class action suite filed against them for lost business. And that's it. On Jun 20, 2013 11:28 PM, "Hal Murray" wrote: From glen.kent at gmail.com Sat Jun 22 00:22:11 2013 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 22 Jun 2013 05:52:11 +0530 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Hi, Do we know which DNS server started leaking the poisoned entry? Being new to this, i still dont understand how could a hacker gain access to the DNS server and corrupt the entry there? Wouldnt it require special admin rights, etc. to log in? Glen On Thu, Jun 20, 2013 at 11:32 AM, Paul Ferguson wrote: > Hanlon's razor? Misconfiguration. Perhaps not done in malice, but I > have no idea where the poison leaked in, or why. :-) > > - ferg > > On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie > wrote: > > > Anyone have news/explanation about what's happening/happened? > > > > > > On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson >wrote: > > > >> Sure enough: > >> > >> > >> > >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > >> ; (1 server found) > >> ;; global options: +cmd > >> ;; Got answer: > >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > >> > >> ;; QUESTION SECTION: > >> ;yelp.com. IN A > >> > >> ;; ANSWER SECTION: > >> yelp.com. 300 IN A 204.11.56.20 > >> > >> ;; Query time: 143 msec > >> ;; SERVER: 127.0.0.1#53(127.0.0.1) > >> ;; WHEN: Thu Jun 20 07:33:13 2013 > >> ;; MSG SIZE rcvd: 42 > >> > >> > >> > >> > >> > >> NetRange: 204.11.56.0 - 204.11.59.255 > >> CIDR: 204.11.56.0/22 > >> OriginAS: AS40034 > >> NetName: CONFLUENCE-NETWORKS--TX3 > >> NetHandle: NET-204-11-56-0-1 > >> Parent: NET-204-0-0-0-0 > >> NetType: Direct Allocation > >> Comment: Hosted in Austin TX. > >> Comment: Abuse : > >> Comment: abuse at confluence-networks.com > >> Comment: +1-917-386-6118 > >> RegDate: 2012-09-24 > >> Updated: 2012-09-24 > >> Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 > >> > >> OrgName: Confluence Networks Inc > >> OrgId: CN > >> Address: 3rd Floor, Omar Hodge Building, Wickhams > >> Address: Cay I, P.O. Box 362 > >> City: Road Town > >> StateProv: Tortola > >> PostalCode: VG1110 > >> Country: VG > >> RegDate: 2011-04-07 > >> Updated: 2011-07-05 > >> Ref: http://whois.arin.net/rest/org/CN > >> > >> OrgAbuseHandle: ABUSE3065-ARIN > >> OrgAbuseName: Abuse Admin > >> OrgAbusePhone: +1-917-386-6118 > >> OrgAbuseEmail: abuse at confluence-networks.com > >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN > >> > >> OrgNOCHandle: NOCAD51-ARIN > >> OrgNOCName: NOC Admin > >> OrgNOCPhone: +1-415-462-7734 > >> OrgNOCEmail: noc at confluence-networks.com > >> OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN > >> > >> OrgTechHandle: TECHA29-ARIN > >> OrgTechName: Tech Admin > >> OrgTechPhone: +1-415-358-0858 > >> OrgTechEmail: ipadmin at confluence-networks.com > >> OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN > >> > >> > >> # > >> # ARIN WHOIS data and services are subject to the Terms of Use > >> # available at: https://www.arin.net/whois_tou.html > >> # > >> > >> - ferg > >> > >> > >> > >> On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder > > >> wrote: > >> > >> > Yelp is evidently also affected > >> > > >> > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: > >> > > >> >> >Reaching out to DNS operators around the globe. Linkedin.com has had > >> some > >> >> issues with DNS > >> >> >and would like DNS operators to flush their DNS. If you see > >> >> www.linkedin.com resolving NS to > >> >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > >> >> > > >> >> >Any other info please reach out to me off-list. > >> >> > >> >> While you're at it, www.usps.com, www.fidelity.com, and other well > >> >> known sites have had DNS poisoning problems. When I restarted my > >> >> cache, they look OK. > >> >> > >> >> > >> >> > >> > >> > >> > >> -- > >> "Fergie", a.k.a. Paul Ferguson > >> fergdawgster(at)gmail.com > >> > >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > From fergdawgster at gmail.com Sat Jun 22 00:29:40 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 21 Jun 2013 17:29:40 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: Not sure of some of the underlying details of the mechanics right now. http://news.softpedia.com/news/LinkedIn-Outage-Caused-by-DDOS-Attack-on-Network-Solutions-362473.shtml - ferg On Fri, Jun 21, 2013 at 5:22 PM, Glen Kent wrote: > Hi, > > Do we know which DNS server started leaking the poisoned entry? > > Being new to this, i still dont understand how could a hacker gain access to > the DNS server and corrupt the entry there? Wouldnt it require special admin > rights, etc. to log in? > > Glen > > > On Thu, Jun 20, 2013 at 11:32 AM, Paul Ferguson > wrote: >> >> Hanlon's razor? Misconfiguration. Perhaps not done in malice, but I >> have no idea where the poison leaked in, or why. :-) >> >> - ferg >> >> On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie >> wrote: >> >> > Anyone have news/explanation about what's happening/happened? >> > >> > >> > On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson >> > wrote: >> > >> >> Sure enough: >> >> >> >> >> >> >> >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A >> >> ; (1 server found) >> >> ;; global options: +cmd >> >> ;; Got answer: >> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 >> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> >> >> ;; QUESTION SECTION: >> >> ;yelp.com. IN A >> >> >> >> ;; ANSWER SECTION: >> >> yelp.com. 300 IN A 204.11.56.20 >> >> >> >> ;; Query time: 143 msec >> >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> >> ;; WHEN: Thu Jun 20 07:33:13 2013 >> >> ;; MSG SIZE rcvd: 42 >> >> >> >> >> >> >> >> >> >> >> >> NetRange: 204.11.56.0 - 204.11.59.255 >> >> CIDR: 204.11.56.0/22 >> >> OriginAS: AS40034 >> >> NetName: CONFLUENCE-NETWORKS--TX3 >> >> NetHandle: NET-204-11-56-0-1 >> >> Parent: NET-204-0-0-0-0 >> >> NetType: Direct Allocation >> >> Comment: Hosted in Austin TX. >> >> Comment: Abuse : >> >> Comment: abuse at confluence-networks.com >> >> Comment: +1-917-386-6118 >> >> RegDate: 2012-09-24 >> >> Updated: 2012-09-24 >> >> Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 >> >> >> >> OrgName: Confluence Networks Inc >> >> OrgId: CN >> >> Address: 3rd Floor, Omar Hodge Building, Wickhams >> >> Address: Cay I, P.O. Box 362 >> >> City: Road Town >> >> StateProv: Tortola >> >> PostalCode: VG1110 >> >> Country: VG >> >> RegDate: 2011-04-07 >> >> Updated: 2011-07-05 >> >> Ref: http://whois.arin.net/rest/org/CN >> >> >> >> OrgAbuseHandle: ABUSE3065-ARIN >> >> OrgAbuseName: Abuse Admin >> >> OrgAbusePhone: +1-917-386-6118 >> >> OrgAbuseEmail: abuse at confluence-networks.com >> >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN >> >> >> >> OrgNOCHandle: NOCAD51-ARIN >> >> OrgNOCName: NOC Admin >> >> OrgNOCPhone: +1-415-462-7734 >> >> OrgNOCEmail: noc at confluence-networks.com >> >> OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN >> >> >> >> OrgTechHandle: TECHA29-ARIN >> >> OrgTechName: Tech Admin >> >> OrgTechPhone: +1-415-358-0858 >> >> OrgTechEmail: ipadmin at confluence-networks.com >> >> OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN >> >> >> >> >> >> # >> >> # ARIN WHOIS data and services are subject to the Terms of Use >> >> # available at: https://www.arin.net/whois_tou.html >> >> # >> >> >> >> - ferg >> >> >> >> >> >> >> >> On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder >> >> >> >> wrote: >> >> >> >> > Yelp is evidently also affected >> >> > >> >> > On Wed, Jun 19, 2013 at 10:19 PM, John Levine wrote: >> >> > >> >> >> >Reaching out to DNS operators around the globe. Linkedin.com has >> >> >> > had >> >> some >> >> >> issues with DNS >> >> >> >and would like DNS operators to flush their DNS. If you see >> >> >> www.linkedin.com resolving NS to >> >> >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. >> >> >> > >> >> >> >Any other info please reach out to me off-list. >> >> >> >> >> >> While you're at it, www.usps.com, www.fidelity.com, and other well >> >> >> known sites have had DNS poisoning problems. When I restarted my >> >> >> cache, they look OK. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> "Fergie", a.k.a. Paul Ferguson >> >> fergdawgster(at)gmail.com >> >> >> >> >> >> >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> fergdawgster(at)gmail.com >> > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From george.herbert at gmail.com Sat Jun 22 00:29:40 2013 From: george.herbert at gmail.com (George Herbert) Date: Fri, 21 Jun 2013 17:29:40 -0700 Subject: Need help in flushing DNS In-Reply-To: References: <5931C2A5-436E-4D6B-9D0E-919EDA2CD3E6@zaidali.com> <20130620051912.51966.qmail@joyce.lan> Message-ID: The indications and claim are that the root cause was registrar internal goof, not hostile action against name servers. The story is not yet detailed enough to add up; getting from point A to point B requires steps that so far don't really make sense. A more detailed explanation is hopefully to be forthcoming... On Fri, Jun 21, 2013 at 5:22 PM, Glen Kent wrote: > Hi, > > Do we know which DNS server started leaking the poisoned entry? > > Being new to this, i still dont understand how could a hacker gain access > to the DNS server and corrupt the entry there? Wouldnt it require special > admin rights, etc. to log in? > > Glen > > > On Thu, Jun 20, 2013 at 11:32 AM, Paul Ferguson >wrote: > > > Hanlon's razor? Misconfiguration. Perhaps not done in malice, but I > > have no idea where the poison leaked in, or why. :-) > > > > - ferg > > > > On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie > > wrote: > > > > > Anyone have news/explanation about what's happening/happened? > > > > > > > > > On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson < > fergdawgster at gmail.com > > >wrote: > > > > > >> Sure enough: > > >> > > >> > > >> > > >> ; <<>> DiG 9.7.3 <<>> @localhost yelp.com A > > >> ; (1 server found) > > >> ;; global options: +cmd > > >> ;; Got answer: > > >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53267 > > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > >> > > >> ;; QUESTION SECTION: > > >> ;yelp.com. IN A > > >> > > >> ;; ANSWER SECTION: > > >> yelp.com. 300 IN A 204.11.56.20 > > >> > > >> ;; Query time: 143 msec > > >> ;; SERVER: 127.0.0.1#53(127.0.0.1) > > >> ;; WHEN: Thu Jun 20 07:33:13 2013 > > >> ;; MSG SIZE rcvd: 42 > > >> > > >> > > >> > > >> > > >> > > >> NetRange: 204.11.56.0 - 204.11.59.255 > > >> CIDR: 204.11.56.0/22 > > >> OriginAS: AS40034 > > >> NetName: CONFLUENCE-NETWORKS--TX3 > > >> NetHandle: NET-204-11-56-0-1 > > >> Parent: NET-204-0-0-0-0 > > >> NetType: Direct Allocation > > >> Comment: Hosted in Austin TX. > > >> Comment: Abuse : > > >> Comment: abuse at confluence-networks.com > > >> Comment: +1-917-386-6118 > > >> RegDate: 2012-09-24 > > >> Updated: 2012-09-24 > > >> Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 > > >> > > >> OrgName: Confluence Networks Inc > > >> OrgId: CN > > >> Address: 3rd Floor, Omar Hodge Building, Wickhams > > >> Address: Cay I, P.O. Box 362 > > >> City: Road Town > > >> StateProv: Tortola > > >> PostalCode: VG1110 > > >> Country: VG > > >> RegDate: 2011-04-07 > > >> Updated: 2011-07-05 > > >> Ref: http://whois.arin.net/rest/org/CN > > >> > > >> OrgAbuseHandle: ABUSE3065-ARIN > > >> OrgAbuseName: Abuse Admin > > >> OrgAbusePhone: +1-917-386-6118 > > >> OrgAbuseEmail: abuse at confluence-networks.com > > >> OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN > > >> > > >> OrgNOCHandle: NOCAD51-ARIN > > >> OrgNOCName: NOC Admin > > >> OrgNOCPhone: +1-415-462-7734 > > >> OrgNOCEmail: noc at confluence-networks.com > > >> OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN > > >> > > >> OrgTechHandle: TECHA29-ARIN > > >> OrgTechName: Tech Admin > > >> OrgTechPhone: +1-415-358-0858 > > >> OrgTechEmail: ipadmin at confluence-networks.com > > >> OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN > > >> > > >> > > >> # > > >> # ARIN WHOIS data and services are subject to the Terms of Use > > >> # available at: https://www.arin.net/whois_tou.html > > >> # > > >> > > >> - ferg > > >> > > >> > > >> > > >> On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder < > shortdudey123 at gmail.com > > > > > >> wrote: > > >> > > >> > Yelp is evidently also affected > > >> > > > >> > On Wed, Jun 19, 2013 at 10:19 PM, John Levine > wrote: > > >> > > > >> >> >Reaching out to DNS operators around the globe. Linkedin.com has > had > > >> some > > >> >> issues with DNS > > >> >> >and would like DNS operators to flush their DNS. If you see > > >> >> www.linkedin.com resolving NS to > > >> >> >ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. > > >> >> > > > >> >> >Any other info please reach out to me off-list. > > >> >> > > >> >> While you're at it, www.usps.com, www.fidelity.com, and other well > > >> >> known sites have had DNS poisoning problems. When I restarted my > > >> >> cache, they look OK. > > >> >> > > >> >> > > >> >> > > >> > > >> > > >> > > >> -- > > >> "Fergie", a.k.a. Paul Ferguson > > >> fergdawgster(at)gmail.com > > >> > > >> > > > > > > > > -- > > "Fergie", a.k.a. Paul Ferguson > > fergdawgster(at)gmail.com > > > > > -- -george william herbert george.herbert at gmail.com From globichen at gmail.com Fri Jun 21 21:21:03 2013 From: globichen at gmail.com (Andy B.) Date: Fri, 21 Jun 2013 23:21:03 +0200 Subject: Yahoo Postmaster Message-ID: If there is a YAHOO! Postmaster contact available, can you please contact me off list? I need to investigate a customer's "TS03" listing of a very large netblock (/16) and I'm afraid regular Yahoo! forms are leading me nowhere but frustration and no results. Thanks. From mohta at necom830.hpcl.titech.ac.jp Sat Jun 22 01:11:55 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 22 Jun 2013 10:11:55 +0900 Subject: /25's prefixes announced into global routing table? In-Reply-To: <20130621201407.GA4370@puck.nether.net> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> Message-ID: <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> Majdi S. Abbas wrote: > On Fri, Jun 21, 2013 at 01:56:02PM -0600, Michael McConnell wrote: >> As the IPv4 space get smaller and smaller, does anyone think we'll see >> a time when /25's will be accepted for global BGP prefix announcement. >> The current smallest size is a /24 and generally ok for most people, but >> the crunch gets tighter, routers continue to have more and more ram will >> it always be /24 the smallest size? > > RAM != FIB. For /24, cheap 16M entry SRAM == FIB > The forwarding hardware is generally going to be the limit, and > that's going to be painful enough as we approach a half million > prefixes. True. And that's why we must avoid IPv6. Masataka Ohta From bmeshier at amherst.com Sat Jun 22 03:06:04 2013 From: bmeshier at amherst.com (Meshier, Brent) Date: Sat, 22 Jun 2013 03:06:04 +0000 Subject: Need AT&T Contact Message-ID: <68C2CBC977F3E04799DF9C76E938E70918F81E@DFEXCH2.asglp.com> AT&T screwed up the porting of our DIDs and we?re completely down, account rep has left for the weekend. Anyone have a contact? Brent Meshier ? Director Information Technology ? Amherst Holdings LLC 7801 North Capital of Texas Hwy ? Suite 300 ? Austin, TX 78731 512.342.3010 ? Fax 512.342.3097? Cell 650-278-3137 www.amherst.com ? bmeshier at amherst.com **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst?s views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. From michael at winkstreaming.com Sat Jun 22 03:13:10 2013 From: michael at winkstreaming.com (Michael McConnell) Date: Fri, 21 Jun 2013 21:13:10 -0600 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> Message-ID: <86579CD5-A404-40DC-91BE-9E4190E960CD@winkstreaming.com> > >> The forwarding hardware is generally going to be the limit, and >> that's going to be painful enough as we approach a half million >> prefixes. > > True. And that's why we must avoid IPv6. > > Masataka Ohta > > Great comment. :D -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com From frnkblk at iname.com Sat Jun 22 03:36:57 2013 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 21 Jun 2013 22:36:57 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <20130621161534.GA14380@vectra.student.iastate.edu> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <20130621161534.GA14380@vectra.student.iastate.edu> Message-ID: <001a01ce6ef9$bf74d4a0$3e5e7de0$@iname.com> It's 120M if you add the .COM and the .NET's together, both of which NetSol is responsible for. http://www.verisigninc.com/en_US/products-and-services/domain-name-services/ registry-products/tld-zone-access/index.xhtml Frank -----Original Message----- From: Nicolai [mailto:nicolai-nanog at chocolatine.org] Sent: Friday, June 21, 2013 11:16 AM To: nanog at nanog.org Subject: Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS) On Thu, Jun 20, 2013 at 05:28:17PM -0400, Valdis.Kletnieks at vt.edu wrote: > It's relatively small when you consider there's something like 140M .com's Just FWIW, the current size of .com is roughly 109M domains. Someday it will reach 140M but not today. Nicolai From johnl at iecc.com Sat Jun 22 03:48:58 2013 From: johnl at iecc.com (John Levine) Date: 22 Jun 2013 03:48:58 -0000 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <001a01ce6ef9$bf74d4a0$3e5e7de0$@iname.com> Message-ID: <20130622034858.68558.qmail@joyce.lan> In article <001a01ce6ef9$bf74d4a0$3e5e7de0$@iname.com> you write: >It's 120M if you add the .COM and the .NET's together, both of which NetSol >is responsible for. >http://www.verisigninc.com/en_US/products-and-services/domain-name-services/ >registry-products/tld-zone-access/index.xhtml In late breaking news, Verisign spun off Network Solutions in 2003, and the two companies have been unrelated for the past decade. These days NetSol is just another registrar. Since 2011 it has been part of web hosting company web.com. R's, John From george.herbert at gmail.com Sat Jun 22 04:15:14 2013 From: george.herbert at gmail.com (George Herbert) Date: Fri, 21 Jun 2013 21:15:14 -0700 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <20130622034858.68558.qmail@joyce.lan> References: <20130622034858.68558.qmail@joyce.lan> Message-ID: <7AE0ABEC-8E95-4A5C-924C-1825368771BC@gmail.com> I know how we got here, but perhaps we can take corporate parentage and how big .com is now to -discuss? What happened with the registry data that caused the outage and what can / should be done about it / to prevent it happening again still seem to me to be operational topics. George William Herbert Sent from my iPhone From carlosm3011 at gmail.com Sat Jun 22 04:29:50 2013 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Sat, 22 Jun 2013 01:29:50 -0300 Subject: Network diagnostics for the end user In-Reply-To: References: Message-ID: <51C5283E.4020802@gmail.com> May sound silly, but in another life I faced a similar problem and by hosting local SpeedTest.net servers in our network we could fend off many of these calls. But I guess it will depend on your customers, whether they take it or not. cheers, ~Carlos On 6/20/13 9:45 PM, Jeffrey Ollie wrote: > Are there any tools out there that we could give to our end users to help > diagnose network problems? We get a lot of "the Internet is slow" support > calls and it would be helpful if we had something that would run on the end > user's computer and help characterize the problem. We have central > monitoring system of course but that doesn't always give a complete > picture, as the problem could always be on the end user's computer - slow > hard drive, not enough memory, wrong name servers, etc. > From owen at delong.com Sat Jun 22 04:44:56 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 06:44:56 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> Message-ID: <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> >> The forwarding hardware is generally going to be the limit, and >> that's going to be painful enough as we approach a half million >> prefixes. > > True. And that's why we must avoid IPv6. This is not only wrong, it makes no sense whatsoever. Owen From wbailey at satelliteintelligencegroup.com Sat Jun 22 05:10:08 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 22 Jun 2013 05:10:08 +0000 Subject: PRISM: NSA/FBI Internet data mining project In-Reply-To: Message-ID: http://www.guardian.co.uk/uk/2013/jun/21/gchq-cables-secret-world-communica tions-nsa I suppose they really are tapping all of the fiber.. Huh? On 6/21/13 11:42 AM, "Phil Fagan" wrote: >I guess the moral here is....don't do anything "wrong." > >:-D > > >On Fri, Jun 21, 2013 at 12:31 PM, William Herrin wrote: > >> On Fri, Jun 21, 2013 at 11:19 AM, Owen DeLong wrote: >> > On Jun 21, 2013, at 5:10 PM, Phil Fagan wrote: >> >> I would think this is only an issue if they throw out the Fourth in >> that when >> >> they use that data collected "inadvertantly" to build a case a >>against >> you >> >> they use no other data collected under a proper warrant. >> > >> > That statement ignores a longstanding legal principle known as "fruit >>of >> the poison tree". >> >> Howdy, >> >> In spite of what you may have seen on TV, law enforcement is not >> required to ignore evidence of a crime which turns up during a lawful >> search merely because it's evidence of a different crime. Fruit of the >> poisonous tree applies when the original search for whatever it was >> they were originally looking for is unlawful. Supposedly the FISA >> court found the NSA's troll for terrorists to be lawful. Once that's >> true, evidence of any crime may be lawfully introduced in court. >> >> >> For a fun read, check out the Ilustrated Guide to Criminal Law: >> http://lawcomic.net/guide/?p=18 >> >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> > > >-- >Phil Fagan >Denver, CO >970-480-7618 From johnl at iecc.com Sat Jun 22 05:14:31 2013 From: johnl at iecc.com (John Levine) Date: 22 Jun 2013 05:14:31 -0000 Subject: /25's prefixes announced into global routing table? In-Reply-To: <20130621201407.GA4370@puck.nether.net> Message-ID: <20130622051431.85077.qmail@joyce.lan> > The forwarding hardware is generally going to be the limit, and >that's going to be painful enough as we approach a half million >prefixes. I would expect that we might finally see some pushback against networks that announce lots of disaggregated prefixes. The current CIDR report notes that the 400K prefixes could be 260K if aggregated. I realize it's not quite that simple due to issues of longer prefixes taking precedence over shorter ones, but it is my impression that there's a lot of sloppiness. From lists.nanog at monmotha.net Sat Jun 22 05:19:49 2013 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 22 Jun 2013 01:19:49 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> Message-ID: <51C533F5.1080209@monmotha.net> On 06/22/2013 12:44 AM, Owen DeLong wrote: >>> The forwarding hardware is generally going to be the limit, and >>> that's going to be painful enough as we approach a half million >>> prefixes. >> >> True. And that's why we must avoid IPv6. > > This is not only wrong, it makes no sense whatsoever. > So here's a question: has anyone done any musings/reasearch on how big of a global IPv6 table we could expect given current policies if IPv6 were as widely deployed and used as IPv4 (or if IPv4 didn't exist)? -- Brandon Martin From owen at delong.com Sat Jun 22 05:45:21 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 07:45:21 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C533F5.1080209@monmotha.net> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> Message-ID: On Jun 22, 2013, at 7:19 AM, Brandon Martin wrote: > On 06/22/2013 12:44 AM, Owen DeLong wrote: >>>> The forwarding hardware is generally going to be the limit, and >>>> that's going to be painful enough as we approach a half million >>>> prefixes. >>> >>> True. And that's why we must avoid IPv6. >> >> This is not only wrong, it makes no sense whatsoever. >> > > > So here's a question: has anyone done any musings/reasearch on how big of a global IPv6 table we could expect given current policies if IPv6 were as widely deployed and used as IPv4 (or if IPv4 didn't exist)? > -- > Brandon Martin Yes? It will probably settle out somewhere around 100-125K routes. Owen From j at arpa.com Sat Jun 22 07:13:24 2013 From: j at arpa.com (jamie rishaw) Date: Sat, 22 Jun 2013 02:13:24 -0500 Subject: This is a coordinated hacking. (Was Re: Need help in flushing DNS) In-Reply-To: <20932.53852.479125.175383@world.std.com> References: <51C36F42.9060307@wvi.com> <32662.1371763697@turing-police.cc.vt.edu> <20932.53852.479125.175383@world.std.com> Message-ID: Data on June 20 : .COM. : 108,985,894 unique domains + the tld. -> 234,479 NSEC3/RRSIG records, -> 2,253,400 nameserver entries on 831,088 unique IP addresses. .. ish. -jamie On Fri, Jun 21, 2013 at 5:23 PM, Barry Shein wrote: > > I think we need a better measure than number of domains (in this case > .COM), particularly vs total domains. > > If it was 100 domains it might seem small, unless that list began with > facebook.com, amazon.com, google.com and g*d forbid theworld.com. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From jcurran at istaff.org Sat Jun 22 10:48:12 2013 From: jcurran at istaff.org (John Curran) Date: Sat, 22 Jun 2013 06:48:12 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> Message-ID: <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> On Jun 22, 2013, at 1:45 AM, Owen DeLong wrote: > Yes? It will probably settle out somewhere around 100-125K routes. Owen - Can you elaborate some on this estimate? (i.e. what approximations and/or assumptions are you using to reach this number?) Thanks! /John From ag4ve.us at gmail.com Sat Jun 22 11:26:37 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 22 Jun 2013 07:26:37 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> Message-ID: RFC 3587 - IPv6 Global Unicast Address Format On Jun 22, 2013 6:50 AM, "John Curran" wrote: > On Jun 22, 2013, at 1:45 AM, Owen DeLong wrote: > > > Yes? It will probably settle out somewhere around 100-125K routes. > > Owen - > > Can you elaborate some on this estimate? (i.e. what approximations > and/or assumptions are you using to reach this number?) > > Thanks! > /John > > > From bill at herrin.us Sat Jun 22 11:57:45 2013 From: bill at herrin.us (William Herrin) Date: Sat, 22 Jun 2013 07:57:45 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> Message-ID: On Sat, Jun 22, 2013 at 12:44 AM, Owen DeLong wrote: >>> The forwarding hardware is generally going to be the limit, and >>> that's going to be painful enough as we approach a half million >>> prefixes. >> >> True. And that's why we must avoid IPv6. > > This is not only wrong, it makes no sense whatsoever. Neither did the first part of his statement. Gigabit srams are neither particularly cheap nor particularly better suited to implementing a FIB than plain old dram. On Sat, Jun 22, 2013 at 1:19 AM, Brandon Martin wrote: > So here's a question: has anyone done any musings/reasearch on how big of a > global IPv6 table we could expect given current policies if IPv6 were as > widely deployed and used as IPv4 (or if IPv4 didn't exist)? Too soon to tell. On the one hand, we shouldn't have the registry-driven fragmentation. They're trying hard to allocate enough addresses for all foreseeable demand, not just near term, and they're leaving space to bump the netmask for the next request when it comes. They're also selecting policies which discourage multihomed end users from breaking up their ISP's block instead of getting their own. On the other side of the hump with IPv4 in decline, both of these should reduce the total number of announcements chosen by each organization. On the other hand, IPv6 addresses consume upwards of 4 times the bits in the FIB. On the fence, the tools for traffic engineering have not changed, the registries are making no attempt to allocate in a manner that facilitates TE filtering, and there's still no better way than a BGP announcement for an end-user to multihome. Number transfers for mergers, acquisitions and divestitures, and renumbering in general suffer from all the same ailments they do in IPv4. At 128 bits instead of 32 bits, all of these factors should impact IPv6 the in same manner they have impacted IPv4. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Sat Jun 22 12:06:12 2013 From: randy at psg.com (Randy Bush) Date: Sat, 22 Jun 2013 21:06:12 +0900 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> Message-ID: >> i have not been able to find it easily, but some years back rexford >> and others published on a crypto method for peers to negotiate >> traffic adjustment between multiple peering points with minimal >> disclosure. it was a cool paper. > I don't know Jen's work on this off the top of my head, but Ratul > Mahajan had some papers on this too (for his dissertation). One is > called Wiser. good stuff. but i thought the paper i had in mind was normal bgp and the exchanges were negotiations of prefix and med policies at mutual peering points using crypto to cloak one's internals. but i could easily be wrong. randy From mpetach at netflight.com Sat Jun 22 12:08:21 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 22 Jun 2013 05:08:21 -0700 Subject: net neutrality and peering wars continue In-Reply-To: <32722.1371763751@turing-police.cc.vt.edu> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> Message-ID: On Thu, Jun 20, 2013 at 2:29 PM, wrote: > On Thu, 20 Jun 2013 22:39:56 +0200, Niels Bakker said: > > > You're mistaken if you think that CDNs have equal number of packets > > going in and out. > > And even if the number of packets match, there's the whole "1500 bytes > of data, 64 bytes of ACK" thing to factor in... > That's easily solved by padding the ACK to 1500 bytes as well. Matt From danny at danysek.cz Sat Jun 22 13:11:30 2013 From: danny at danysek.cz (Daniel Suchy) Date: Sat, 22 Jun 2013 15:11:30 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> Message-ID: <51C5A282.4010207@danysek.cz> On 06/22/2013 12:27 AM, Jakob Heitz wrote: >> Date: Fri, 21 Jun 2013 16:14:07 -0400 >> From: "Majdi S. Abbas" >> The forwarding hardware is generally going to be the limit, and >> that's going to be painful enough as we approach a half million >> prefixes. > > There are techniques to fix that. For example, Simple Virtual Aggregation > http://tools.ietf.org/html/rfc6769 > I'm not sure, if hardware vendors will implement something like this. I expect they'll sell you router with larger hardware FIB instead. - Daniel From neil at tonal.clara.co.uk Sat Jun 22 13:19:18 2013 From: neil at tonal.clara.co.uk (Neil Harris) Date: Sat, 22 Jun 2013 14:19:18 +0100 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> Message-ID: <51C5A456.30901@tonal.clara.co.uk> On 22/06/13 13:08, Matthew Petach wrote: > On Thu, Jun 20, 2013 at 2:29 PM, wrote: > >> On Thu, 20 Jun 2013 22:39:56 +0200, Niels Bakker said: >> >>> You're mistaken if you think that CDNs have equal number of packets >>> going in and out. >> And even if the number of packets match, there's the whole "1500 bytes >> of data, 64 bytes of ACK" thing to factor in... >> > > That's easily solved by padding the ACK to 1500 bytes as well. > > Matt > Or indeed by the media player sending large amounts of traffic back to the CDN via auxiliary HTTP POST requests? Neil From symack at gmail.com Sat Jun 22 13:53:16 2013 From: symack at gmail.com (Nick Khamis) Date: Sat, 22 Jun 2013 09:53:16 -0400 Subject: Need AT&T Contact In-Reply-To: <68C2CBC977F3E04799DF9C76E938E70918F81E@DFEXCH2.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E70918F81E@DFEXCH2.asglp.com> Message-ID: Is this an ISDN trunk or their IP Flex product? I don't have a rep for the latter. N. From owen at delong.com Sat Jun 22 15:30:43 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 17:30:43 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> Message-ID: <722494DF-8253-4AEA-BDFF-2BB4D73AF7AD@delong.com> On Jun 22, 2013, at 12:48 PM, John Curran wrote: > On Jun 22, 2013, at 1:45 AM, Owen DeLong wrote: > >> Yes? It will probably settle out somewhere around 100-125K routes. > > Owen - > > Can you elaborate some on this estimate? (i.e. what approximations > and/or assumptions are you using to reach this number?) > > Thanks! > /John Looking at the number of autonomous systems in the IPv6 routing table and the total number of routes, it looks like it will shake out somewhere in the neighborhood of 3-5 prefixes/ASN. Since there are ~35,000 unique ASNs in the IPv4 table, I figured simple multiplication provided as good an estimate as any at this early time. Owen From owen at delong.com Sat Jun 22 15:34:59 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 17:34:59 +0200 Subject: net neutrality and peering wars continue In-Reply-To: <51C5A456.30901@tonal.clara.co.uk> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> <51C5A456.30901@tonal.clara.co.uk> Message-ID: <12C00316-E6F8-45A9-8B4A-081A39E6F20D@delong.com> >> >> That's easily solved by padding the ACK to 1500 bytes as well. >> >> Matt >> > > Or indeed by the media player sending large amounts of traffic back to the CDN via auxiliary HTTP POST requests? > > Neil > > > That would assume that the client has symmetrical upstream bandwidth over which to send such datagrams. At least in the US, that is the exception, not the rule. Owen From morrowc.lists at gmail.com Sat Jun 22 16:00:38 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 22 Jun 2013 12:00:38 -0400 Subject: net neutrality and peering wars continue In-Reply-To: <51C5A456.30901@tonal.clara.co.uk> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> <51C5A456.30901@tonal.clara.co.uk> Message-ID: On Sat, Jun 22, 2013 at 9:19 AM, Neil Harris wrote: > On 22/06/13 13:08, Matthew Petach wrote: >> That's easily solved by padding the ACK to 1500 bytes as well. >> >> Matt >> > > Or indeed by the media player sending large amounts of traffic back to the > CDN via auxiliary HTTP POST requests? ah... botnet... how I love thee? From deleskie at gmail.com Sat Jun 22 16:19:44 2013 From: deleskie at gmail.com (jim deleskie) Date: Sat, 22 Jun 2013 13:19:44 -0300 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> <51C5A456.30901@tonal.clara.co.uk> Message-ID: Botnets to help with peering ratio's could be a new business model? :) On Sat, Jun 22, 2013 at 1:00 PM, Christopher Morrow wrote: > On Sat, Jun 22, 2013 at 9:19 AM, Neil Harris > wrote: > > On 22/06/13 13:08, Matthew Petach wrote: > >> That's easily solved by padding the ACK to 1500 bytes as well. > >> > >> Matt > >> > > > > Or indeed by the media player sending large amounts of traffic back to > the > > CDN via auxiliary HTTP POST requests? > > ah... botnet... how I love thee? > > From owen at delong.com Sat Jun 22 16:38:41 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 18:38:41 +0200 Subject: net neutrality and peering wars continue In-Reply-To: References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> <51C5A456.30901@tonal.clara.co.uk> Message-ID: <95253FD8-545C-4D1D-A0E4-7EF9630D6AC0@delong.com> When you convert your botnet to a business model, you have to change the name. If it's a business, the politically correct term is "Elastic Cloud Computing" Owen On Jun 22, 2013, at 6:19 PM, jim deleskie wrote: > Botnets to help with peering ratio's could be a new business model? :) > > > On Sat, Jun 22, 2013 at 1:00 PM, Christopher Morrow > wrote: > >> On Sat, Jun 22, 2013 at 9:19 AM, Neil Harris >> wrote: >>> On 22/06/13 13:08, Matthew Petach wrote: >>>> That's easily solved by padding the ACK to 1500 bytes as well. >>>> >>>> Matt >>>> >>> >>> Or indeed by the media player sending large amounts of traffic back to >> the >>> CDN via auxiliary HTTP POST requests? >> >> ah... botnet... how I love thee? >> >> From bill at herrin.us Sat Jun 22 17:36:57 2013 From: bill at herrin.us (William Herrin) Date: Sat, 22 Jun 2013 13:36:57 -0400 Subject: net neutrality and peering wars continue In-Reply-To: <51C3869A.4080008@enger.us> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <715219D8-6501-4FBA-9CE9-35A98A05F4A1@level3.com> <-9038073839096182563@unknownmsgid> <970945E55BFD8C4EA4CAD74B647A9DC04868C5B7@USIDCWVEMBX10.corp.global.level3.com> <51C3869A.4080008@enger.us> Message-ID: On Thu, Jun 20, 2013 at 6:47 PM, Robert M. Enger wrote: > Perhaps last-mile operators should > A) advertise each of their metropolitan regional systems as a separate AS > B) establish an interconnection point in each region where they will accept > traffic destined for their in-region customers without charging any fee What would be the point of (A)? They can just set a BGP community based on where a route originates and then match by BGP community for the sufficiently-local routes when they peer. They don't do B because the complaint about "you're abusing my long haul bandwidth" is basically a lie. They want to get paid twice for each byte and if they think they can then they won't do settlement free peering with you. Period. On Thu, Jun 20, 2013 at 9:10 PM, Aaron C. de Bruyn wrote: > Maybe someone could enlighten my ignorance on this issue. > Why is there a variable charge for bandwidth anyways? Some equipment is used to connect to you. A cable. A port on a card in a router. Whatever. Also, that router can only have so many ports, so when you connect to it a fraction of that router's equipment, maintenance and management cost is attributable to your specific connection. That's the monthly port charge. Your packets are then multiplex with lots of other folks' packets an a variety of cables and through a variety of routers as they travel between you and the machines you're talking to. That infrastructure has a cost $X. It's used by all of their customers (packets cross it) at a total of Y gbps. Your consumption divided by Y is your fraction of that usage. That fraction times $X is the service provider's variable cost of moving your packets. Variable cost, variable charge. On Thu, Jun 20, 2013 at 11:42 PM, Jon Lewis wrote: > At this rate, if they do produce a PFC that takes the 6500 to several > million routes, it's probably going to be too late for those to be available > in any real quantity on the secondary market. Maybe that's the plan. "Maybe"? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From raymond at prolocation.net Sat Jun 22 18:40:19 2013 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sat, 22 Jun 2013 20:40:19 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C5A282.4010207@danysek.cz> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> <51C5A282.4010207@danysek.cz> Message-ID: <7B88331D-AE8A-47E7-B915-F7B15D416C01@prolocation.net> Hai! Extreme supports route compression since several years. I hope other vendors will also start doing this. Thanks, Raymond Dijkxhoorn, Prolocation Op 22 jun. 2013 om 15:11 heeft Daniel Suchy het volgende geschreven: > On 06/22/2013 12:27 AM, Jakob Heitz wrote: >>> Date: Fri, 21 Jun 2013 16:14:07 -0400 >>> From: "Majdi S. Abbas" >>> The forwarding hardware is generally going to be the limit, and >>> that's going to be painful enough as we approach a half million >>> prefixes. >> >> There are techniques to fix that. For example, Simple Virtual Aggregation >> http://tools.ietf.org/html/rfc6769 > > I'm not sure, if hardware vendors will implement something like this. I > expect they'll sell you router with larger hardware FIB instead. > > - Daniel From andre-nanog at tomt.net Sat Jun 22 18:45:44 2013 From: andre-nanog at tomt.net (Andre Tomt) Date: Sat, 22 Jun 2013 20:45:44 +0200 Subject: .biz DNSSEC borked Message-ID: <51C5F0D8.3050706@tomt.net> Seems the entire .biz tld is failing DNSSEC validation now. All of my DNSSEC validating resolvers are tossing all domains in .biz. The non-signed domains too of course because trust of the tld itself cannot be established. http://dnssec-debugger.verisignlabs.com/nic.biz From neil at tonal.clara.co.uk Sat Jun 22 19:06:25 2013 From: neil at tonal.clara.co.uk (Neil Harris) Date: Sat, 22 Jun 2013 20:06:25 +0100 Subject: net neutrality and peering wars continue In-Reply-To: <12C00316-E6F8-45A9-8B4A-081A39E6F20D@delong.com> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> <51C5A456.30901@tonal.clara.co.uk> <12C00316-E6F8-45A9-8B4A-081A39E6F20D@delong.com> Message-ID: <51C5F5B1.4050701@tonal.clara.co.uk> On 22/06/13 16:34, Owen DeLong wrote: >>> That's easily solved by padding the ACK to 1500 bytes as well. >>> >>> Matt >>> >> Or indeed by the media player sending large amounts of traffic back to the CDN via auxiliary HTTP POST requests? >> >> Neil >> >> >> > That would assume that the client has symmetrical upstream bandwidth over which to send such datagrams. At least in the US, that is the exception, not the rule. > > Owen > > Hi Owen, You only need to match the video stream bandwidth, not the full download speed of the link. Given that current multicore CPUs are now fast enough to decode HEVC in software, and with HEVC being roughly twice as efficient as H.264, that means you should be able to do quite decent full HDTV quality video with an average bandwdith of about 5 Mbps, given sufficient buffering to smooth out the traffic. Less, if you're willing to compromise on picture quality a bit, and go for, say, 720p. So, given an HEVC-capable decoder, this strategy should work for any connection with an upstream speed of better than about 4 to 5 Mbps, which is becoming more and more common on cable Internet service, as DOCSIS 3.0 is rolled out and faster links become more common, Neil From j at arpa.com Sat Jun 22 19:10:10 2013 From: j at arpa.com (jamie rishaw) Date: Sat, 22 Jun 2013 14:10:10 -0500 Subject: .biz DNSSEC borked In-Reply-To: <51C5F0D8.3050706@tomt.net> References: <51C5F0D8.3050706@tomt.net> Message-ID: confirmed None of the 5 DNSKEY records could be validated by any of the 2 DS records The DNSKEY RRset was not signed by any keys in the chain-of-trust biz has SOA record a.gtld.biz. hostmaster.neustar.biz. 12161960 900 900 604800 86400 (BOGUS (security failure)) validation failure : no keys have a DS from 156.154.127.65 for key BIZ. while building chain of trust tcp: biz has SOA record a.gtld.biz. hostmaster.neustar.biz. 12161960 900 900 604800 86400 (BOGUS (security failure)) validation failure : no keys have a DS from 156.154.127.65 for key BIZ. while building chain of trust On Sat, Jun 22, 2013 at 1:45 PM, Andre Tomt wrote: > > Seems the entire .biz tld is failing DNSSEC validation now. > All of my DNSSEC validating resolvers are tossing all domains in .biz. The non-signed domains too of course because trust of the tld itself cannot be established. > > http://dnssec-debugger.verisignlabs.com/nic.biz > From Grzegorz at Janoszka.pl Sat Jun 22 20:16:08 2013 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Sat, 22 Jun 2013 22:16:08 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <722494DF-8253-4AEA-BDFF-2BB4D73AF7AD@delong.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> <722494DF-8253-4AEA-BDFF-2BB4D73AF7AD@delong.com> Message-ID: <51C60608.4030301@Janoszka.pl> On 22-06-13 17:30, Owen DeLong wrote: > Looking at the number of autonomous systems in the IPv6 routing table and the total number of routes, it looks like it will shake out somewhere in the neighborhood of 3-5 prefixes/ASN. Since there are ~35,000 unique ASNs in the IPv4 table, I figured simple multiplication provided as good an estimate as any at this early time. Deaggregating of IPv4 announcements is done for traffic engineering and to fight ddoses (just the attacked /24 stops being announced to internet). I think some people will just copy their v4 habits into v6 and then we might have explosion of /48's. I wouldn't be so sure about just 3-5 prefixes/ASN. -- Grzegorz Janoszka From mpetach at netflight.com Sat Jun 22 21:03:15 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 22 Jun 2013 14:03:15 -0700 Subject: net neutrality and peering wars continue In-Reply-To: <51C5F5B1.4050701@tonal.clara.co.uk> References: <51C24D61.6000104@queuefull.net> <51C26745.6010003@queuefull.net> <58F93935-238F-48A0-9299-392A8AAF7BB3@pch.net> <-5367783170688464759@unknownmsgid> <20130620203956.GV55976@burnout.tpb.net> <32722.1371763751@turing-police.cc.vt.edu> <51C5A456.30901@tonal.clara.co.uk> <12C00316-E6F8-45A9-8B4A-081A39E6F20D@delong.com> <51C5F5B1.4050701@tonal.clara.co.uk> Message-ID: On Sat, Jun 22, 2013 at 12:06 PM, Neil Harris wrote: > On 22/06/13 16:34, Owen DeLong wrote: > >> That's easily solved by padding the ACK to 1500 bytes as well. >>>> >>>> Matt >>>> >>>> Or indeed by the media player sending large amounts of traffic back to >>> the CDN via auxiliary HTTP POST requests? >>> >>> Neil >>> >>> That would assume that the client has symmetrical upstream bandwidth >> over which to send such datagrams. At least in the US, that is the >> exception, not the rule. >> >> Owen >> >> > Hi Owen, > > You only need to match the video stream bandwidth, not the full download > speed of the link. > Nah. For peering purposes, you only need to match half the video stream bandwidth to be within compliance. Generating 2.5M back upstream in response to a 5M video stream would be more than sufficient to keep the ratio-watchers happy. Matt From owen at delong.com Sat Jun 22 21:08:40 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 22 Jun 2013 23:08:40 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C60608.4030301@Janoszka.pl> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> <722494DF-8253-4AEA-BDFF-2BB4D73AF7AD@delong.com> <51C60608.4030301@Janoszka.pl> Message-ID: On Jun 22, 2013, at 10:16 PM, Grzegorz Janoszka wrote: > On 22-06-13 17:30, Owen DeLong wrote: >> Looking at the number of autonomous systems in the IPv6 routing table and the total number of routes, it looks like it will shake out somewhere in the neighborhood of 3-5 prefixes/ASN. Since there are ~35,000 unique ASNs in the IPv4 table, I figured simple multiplication provided as good an estimate as any at this early time. > > Deaggregating of IPv4 announcements is done for traffic engineering and > to fight ddoses (just the attacked /24 stops being announced to > internet). I think some people will just copy their v4 habits into v6 > and then we might have explosion of /48's. > I wouldn't be so sure about just 3-5 prefixes/ASN. > Some ASNs will be more, some will be less. Since there's already some DDOS and such on IPv6, I would expect the current prefix table to include a reasonable example of all of the behaviors you describe. Owen From andre-nanog at tomt.net Sat Jun 22 21:15:15 2013 From: andre-nanog at tomt.net (Andre Tomt) Date: Sat, 22 Jun 2013 23:15:15 +0200 Subject: .biz DNSSEC borked In-Reply-To: <51C5F0D8.3050706@tomt.net> References: <51C5F0D8.3050706@tomt.net> Message-ID: <51C613E3.6010007@tomt.net> On 22. juni 2013 20:45, Andre Tomt wrote: > Seems the entire .biz tld is failing DNSSEC validation now. > All of my DNSSEC validating resolvers are tossing all domains in .biz. > The non-signed domains too of course because trust of the tld itself > cannot be established. > > http://dnssec-debugger.verisignlabs.com/nic.biz Looks like it is clearing up now. Flushing the caches of your resolvers might be wise. I wonder who made the boo-boo From mitch at basejp.com Sat Jun 22 22:50:54 2013 From: mitch at basejp.com (Mitchell Kuch) Date: Sat, 22 Jun 2013 18:50:54 -0400 Subject: Yahoo Postmaster In-Reply-To: References: Message-ID: <4252CE2B-4D40-4175-A8F8-FE97135E89C3@basejp.com> Hello - I also need to contact a YAHOO! Postmaster about a security related issue. Off-list contacts are appreciated. Mitchell [ CROSS POSTED TO MAILOP ] On Jun 21, 2013, at 5:21 PM, Andy B. wrote: > If there is a YAHOO! Postmaster contact available, can you please > contact me off list? > > I need to investigate a customer's "TS03" listing of a very large > netblock (/16) and I'm afraid regular Yahoo! forms are leading me > nowhere but frustration and no results. > > > Thanks. From william.allen.simpson at gmail.com Sun Jun 23 03:51:17 2013 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 22 Jun 2013 23:51:17 -0400 Subject: Security over SONET/SDH Message-ID: <51C670B5.7010001@gmail.com> What security protocols are folks using to protect SONET/SDH? At what speeds? From surfer at mauigateway.com Sun Jun 23 04:48:49 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 22 Jun 2013 21:48:49 -0700 Subject: Security over SONET/SDH Message-ID: <20130622214849.D48550B0@m0005296.ppops.net> --- william.allen.simpson at gmail.com wrote: From: William Allen Simpson What security protocols are folks using to protect SONET/SDH? At what speeds? ------------------------------------------------------ By security protocol do you mean encrypting the traffic? Like what a Fastlane does? http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf scott From william.allen.simpson at gmail.com Sun Jun 23 13:47:39 2013 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 23 Jun 2013 09:47:39 -0400 Subject: Security over SONET/SDH In-Reply-To: <20130622214849.D48550B0@m0005296.ppops.net> References: <20130622214849.D48550B0@m0005296.ppops.net> Message-ID: <51C6FC7B.20703@gmail.com> On 6/23/13 12:48 AM, Scott Weeks wrote: > By security protocol do you mean encrypting the traffic? > Like what a Fastlane does? > > http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf > That's rather a surprising choice (ATM product) for an IP network. Please describe what backbone you are running that uses a FASTLANE? Hopefully, other folks are securing their PPP or ethernet packets? From tpoder at cis.vutbr.cz Sun Jun 23 14:18:58 2013 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Sun, 23 Jun 2013 16:18:58 +0200 Subject: IPv6 adoption in the past few days Message-ID: <51C703D2.8080305@cis.vutbr.cz> Hi, according to Google IPv6 statistics (http://www.google.com/intl/en/ipv6/statistics.html) there is massive increase in IPv6 adoption (from 1.5% to 1.7%) in the past few days. I think it is the biggest increase ever. Does anyone have any idea what happened? T. From lord2y at gmail.com Sun Jun 23 14:48:42 2013 From: lord2y at gmail.com (Alessandro Ratti) Date: Sun, 23 Jun 2013 16:48:42 +0200 Subject: IPv6 adoption in the past few days In-Reply-To: <51C703D2.8080305@cis.vutbr.cz> References: <51C703D2.8080305@cis.vutbr.cz> Message-ID: Il giorno domenica 23 giugno 2013, Tomas Podermanski ha scritto: > Hi, > > according to Google IPv6 statistics > (http://www.google.com/intl/en/ipv6/statistics.html) there is massive > increase in IPv6 adoption (from 1.5% to 1.7%) in the past few days. I > think it is the biggest increase ever. Does anyone have any idea what > happened? > > Someone reports that yesterday, IPv6 was added to the ccTLD .BO (Bolivia) https://twitter.com/patrikhson/status/348688402507505665 -- Alessandro Ratti http://about.me/alessandroratti NOTICE This message is for the named person's use only and it's confidential. If you receive this message in error, please immediately delete it and and notify the sender. Thank you. From morrowc.lists at gmail.com Sun Jun 23 14:54:15 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 23 Jun 2013 10:54:15 -0400 Subject: Security over SONET/SDH In-Reply-To: <51C6FC7B.20703@gmail.com> References: <20130622214849.D48550B0@m0005296.ppops.net> <51C6FC7B.20703@gmail.com> Message-ID: On Sun, Jun 23, 2013 at 9:47 AM, William Allen Simpson wrote: > On 6/23/13 12:48 AM, Scott Weeks wrote: >> >> By security protocol do you mean encrypting the traffic? >> Like what a Fastlane does? >> >> >> http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf >> > That's rather a surprising choice (ATM product) for an IP network. > Please describe what backbone you are running that uses a FASTLANE? I'd be surprised if a civilian org could buy a fastlane device,.. maybe they moved out of the gov't only world though since the last time I saw one? It does claim to do oc-48 rate sonet though. > Hopefully, other folks are securing their PPP or ethernet packets? > > From morrowc.lists at gmail.com Sun Jun 23 14:57:47 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 23 Jun 2013 10:57:47 -0400 Subject: Security over SONET/SDH In-Reply-To: References: <20130622214849.D48550B0@m0005296.ppops.net> <51C6FC7B.20703@gmail.com> Message-ID: On Sun, Jun 23, 2013 at 10:54 AM, Christopher Morrow wrote: > On Sun, Jun 23, 2013 at 9:47 AM, William Allen Simpson > wrote: >> On 6/23/13 12:48 AM, Scott Weeks wrote: >>> >>> By security protocol do you mean encrypting the traffic? >>> Like what a Fastlane does? >>> >>> >>> http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf >>> >> That's rather a surprising choice (ATM product) for an IP network. >> Please describe what backbone you are running that uses a FASTLANE? > > I'd be surprised if a civilian org could buy a fastlane device,.. > maybe they moved out of the gov't only world though since the last > time I saw one? It does claim to do oc-48 rate sonet though. http://www.gdc4s.com/kg-530.html claims 40gbps... I don't know that a purely civilian org can purchase these though, nor the kg-75, despite these being on the GD site. >> Hopefully, other folks are securing their PPP or ethernet packets? >> >> From ag4ve.us at gmail.com Sun Jun 23 15:37:43 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 23 Jun 2013 11:37:43 -0400 Subject: PDU recommendations Message-ID: We currently use Triplite stuff but they've got an issue where after a few minutes, they stop accepting new tcp connections. We're adding a new 30A circuit and I'm thinking of going with APC (ran them in the past and never had any issues). However, I figured I'd see if there was a better brand / specific model recommendations for quality or bang / buck? Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From trelane at trelane.net Sun Jun 23 15:51:29 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 23 Jun 2013 11:51:29 -0400 Subject: PDU recommendations In-Reply-To: References: Message-ID: <51C71981.6040602@trelane.net> On 6/23/2013 11:37 AM, shawn wilson wrote: > We currently use Triplite stuff but they've got an issue where after a few > minutes, they stop accepting new tcp connections. We're adding a new 30A > circuit and I'm thinking of going with APC (ran them in the past and never > had any issues). However, I figured I'd see if there was a better brand / > specific model recommendations for quality or bang / buck? > > Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. Shawn, I'd go with APC it's quite monitorable and most NMS packages including Zenoss (where I work) have extensions to monitor it. There's a half dozen open source ZenPacks for APC including UPS's and PDU's. Andrew From mloftis at wgops.com Sun Jun 23 16:02:27 2013 From: mloftis at wgops.com (Michael Loftis) Date: Sun, 23 Jun 2013 09:02:27 -0700 Subject: PDU recommendations In-Reply-To: References: Message-ID: Personally have gotten sick of dealing with basically every other vendors PDU out there but APC. APC PDUs may not have every whiz-bang feature but they work. SNMP or SSH pretty solid. You still probably want them on a closed management network but problems even in the wild 'net with port 22 open in my experience have been rare. Management software upgrades are generally live, load left on/undisturbed. I still schedule them for downtime but (knock on wood) nothing in the last 6-7 years has caused an outage. From symack at gmail.com Sun Jun 23 16:13:09 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 23 Jun 2013 12:13:09 -0400 Subject: PDU recommendations In-Reply-To: References: Message-ID: Hello Michael, does that mean you do not employ PDUs in your network? I.e., found a UPS with sufficient number of outlets in the back. With that in mind, could you make a recommendation for such a UPS-direct for a VM environment. Kind Regards, Nick. From mloftis at wgops.com Sun Jun 23 16:40:24 2013 From: mloftis at wgops.com (Michael Loftis) Date: Sun, 23 Jun 2013 09:40:24 -0700 Subject: PDU recommendations In-Reply-To: References: Message-ID: No, I only use APC anymore for PDUs. It's the others I've dealt with I don't like. There's quite a few I've never used but after the painfully expensive experiences I've had with Tripp-Lite, Bay tech, MGE (though I think they're part of Schneider or APC now), Liebert (which at the time looked suspiciously the same as the Tripp-Lite's but with a bigger price tag), and a couple others I'm certainly forgetting. I'd heard there were some bad batches that were DOA from APC, but haven't personally experienced any myself. I've had a couple management cards in Symmetra LXes fail, and that same Symmetra chassis had a power/inverter/charger module fail around the same time. On Sun, Jun 23, 2013 at 9:13 AM, Nick Khamis wrote: > Hello Michael, does that mean you do not employ PDUs in your network? > I.e., found a UPS with sufficient number of outlets in the back. With > that in mind, could you make a recommendation for such a UPS-direct > for a VM environment. > > Kind Regards, > > Nick. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From tritran at cox.net Sun Jun 23 19:05:20 2013 From: tritran at cox.net (tritran at cox.net) Date: Sun, 23 Jun 2013 19:05:20 +0000 Subject: PDU recommendations Message-ID: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> APC is solid. Their newer line can provide outlet metering. WTI is also good...they support redundant circuits. I've seen Baytech died after just unplugging a server. ------Original Message------ From: shawn wilson To: North American Network Operators Group Subject: PDU recommendations Sent: Jun 23, 2013 8:37 AM We currently use Triplite stuff but they've got an issue where after a few minutes, they stop accepting new tcp connections. We're adding a new 30A circuit and I'm thinking of going with APC (ran them in the past and never had any issues). However, I figured I'd see if there was a better brand / specific model recommendations for quality or bang / buck? Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From nick at foobar.org Sun Jun 23 19:08:47 2013 From: nick at foobar.org (Nick Hilliard) Date: Sun, 23 Jun 2013 20:08:47 +0100 Subject: PDU recommendations In-Reply-To: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> References: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> Message-ID: <51C747BF.9050703@foobar.org> On 23/06/2013 20:05, tritran at cox.net wrote: > APC is solid. Their newer line can provide outlet metering. That's an improvement then. Raritan has had this feature for years, with visibility via SNMP. This was one of the reasons I dumped APC a couple of years ago. Nick From sethm at rollernet.us Sun Jun 23 19:31:57 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 23 Jun 2013 12:31:57 -0700 Subject: PDU recommendations In-Reply-To: <51C747BF.9050703@foobar.org> References: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> <51C747BF.9050703@foobar.org> Message-ID: <51C74D2D.2080807@rollernet.us> On 6/23/13 12:08 PM, Nick Hilliard wrote: > That's an improvement then. Raritan has had this feature for years, with > visibility via SNMP. This was one of the reasons I dumped APC a couple of > years ago. The APC metered-by-outlet series are relatively new. I figured it was inevitable when I was scrolling through the menus on a new genreation 2 PDU a while back and it listed outlet metering in the menu (although it didn't do anything). ~Seth From cabenth at gmail.com Sun Jun 23 19:30:26 2013 From: cabenth at gmail.com (Eric Clark) Date: Sun, 23 Jun 2013 12:30:26 -0700 Subject: PDU recommendations In-Reply-To: References: Message-ID: <9DFA49B7-0FED-470F-AD62-D88D57982185@gmail.com> Raritan has a good line, the usual features, we use a lot of 2U, 208v,30A units with 20xc13 which is a good config these days Their central management software, while not perfect, is excellent for pdu control On Jun 23, 2013, at 8:37 AM, shawn wilson wrote: > We currently use Triplite stuff but they've got an issue where after a few > minutes, they stop accepting new tcp connections. We're adding a new 30A > circuit and I'm thinking of going with APC (ran them in the past and never > had any issues). However, I figured I'd see if there was a better brand / > specific model recommendations for quality or bang / buck? > > Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From Petter.Bruland at allegiantair.com Sun Jun 23 19:41:35 2013 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Sun, 23 Jun 2013 19:41:35 +0000 Subject: PDU recommendations In-Reply-To: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> References: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> Message-ID: We're replacing TrippLite with APC. Had two TrippLite SNMP/Web cards stop working at random times, and need to be reset. Pain when the datacenter is far away. On a different note TrippLite support has been super awesome. The APC line we went with, model # escaping me at the moment, only had overall unit AMP load indicator. But their SNMP access is nice, for custom graphs in Cacti etc, and being able to remote bounce an outlet. We did have a few WTI, the really old ones, which did not store the config in flash, thus needed to be reconfigured via serial after power outage. Even with that annoyance, they had much faster response time from telnet (....I know, old) turning on/off outlets than either of APC or TrippLite. -Petter ________________________________________ From: tritran at cox.net [tritran at cox.net] Sent: Sunday, June 23, 2013 12:05 PM To: shawn wilson; North American Network Operators Group Subject: Re: PDU recommendations APC is solid. Their newer line can provide outlet metering. WTI is also good...they support redundant circuits. I've seen Baytech died after just unplugging a server. ------Original Message------ From: shawn wilson To: North American Network Operators Group Subject: PDU recommendations Sent: Jun 23, 2013 8:37 AM We currently use Triplite stuff but they've got an issue where after a few minutes, they stop accepting new tcp connections. We're adding a new 30A circuit and I'm thinking of going with APC (ran them in the past and never had any issues). However, I figured I'd see if there was a better brand / specific model recommendations for quality or bang / buck? Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From ag4ve.us at gmail.com Sun Jun 23 20:27:00 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 23 Jun 2013 16:27:00 -0400 Subject: PDU recommendations In-Reply-To: References: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> Message-ID: Thanks, I think the amount of love for the APC stuff confirmed my experience. I'll look at the Raritan PDUs as I like their KVMs but if I have to use their software or a WebUI to manage it (I use AddleLink for remote to the KVM because I don't like proprietary management) I won't use their PDU. AFAIK (I'll obviously confirm), the circuit is 208VAC and the plug is the dual phase NMEA type. On Jun 23, 2013 3:41 PM, "Petter Bruland" wrote: > We're replacing TrippLite with APC. Had two TrippLite SNMP/Web cards stop > working at random times, and need to be reset. Pain when the datacenter is > far away. On a different note TrippLite support has been super awesome. > > The APC line we went with, model # escaping me at the moment, only had > overall unit AMP load indicator. But their SNMP access is nice, for custom > graphs in Cacti etc, and being able to remote bounce an outlet. > > We did have a few WTI, the really old ones, which did not store the config > in flash, thus needed to be reconfigured via serial after power outage. > Even with that annoyance, they had much faster response time from telnet > (....I know, old) turning on/off outlets than either of APC or TrippLite. > > -Petter > > ________________________________________ > From: tritran at cox.net [tritran at cox.net] > Sent: Sunday, June 23, 2013 12:05 PM > To: shawn wilson; North American Network Operators Group > Subject: Re: PDU recommendations > > APC is solid. Their newer line can provide outlet metering. WTI is also > good...they support redundant circuits. I've seen Baytech died after just > unplugging a server. > ------Original Message------ > From: shawn wilson > To: North American Network Operators Group > Subject: PDU recommendations > Sent: Jun 23, 2013 8:37 AM > > We currently use Triplite stuff but they've got an issue where after a few > minutes, they stop accepting new tcp connections. We're adding a new 30A > circuit and I'm thinking of going with APC (ran them in the past and never > had any issues). However, I figured I'd see if there was a better brand / > specific model recommendations for quality or bang / buck? > > Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. > > > From fmartin at linkedin.com Sun Jun 23 20:58:35 2013 From: fmartin at linkedin.com (Franck Martin) Date: Sun, 23 Jun 2013 20:58:35 +0000 Subject: .biz DNSSEC borked In-Reply-To: <51C613E3.6010007@tomt.net> References: <51C5F0D8.3050706@tomt.net> <51C613E3.6010007@tomt.net> Message-ID: <77426B543150464AA3F30DF1A91365DE532FE3AF@ESV4-MBX01.linkedin.biz> Another Internet reboot? Can we find something better? On Jun 22, 2013, at 2:15 PM, Andre Tomt wrote: > On 22. juni 2013 20:45, Andre Tomt wrote: >> Seems the entire .biz tld is failing DNSSEC validation now. >> All of my DNSSEC validating resolvers are tossing all domains in .biz. >> The non-signed domains too of course because trust of the tld itself >> cannot be established. >> >> http://dnssec-debugger.verisignlabs.com/nic.biz > > Looks like it is clearing up now. Flushing the caches of your resolvers might be wise. > > I wonder who made the boo-boo > From william.allen.simpson at gmail.com Sun Jun 23 21:03:49 2013 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 23 Jun 2013 17:03:49 -0400 Subject: Security over SONET/SDH In-Reply-To: References: <20130622214849.D48550B0@m0005296.ppops.net> <51C6FC7B.20703@gmail.com> Message-ID: <51C762B5.40307@gmail.com> On 6/23/13 10:57 AM, Christopher Morrow wrote: > On Sun, Jun 23, 2013 at 10:54 AM, Christopher Morrow > wrote: >> On Sun, Jun 23, 2013 at 9:47 AM, William Allen Simpson >> wrote: >>> On 6/23/13 12:48 AM, Scott Weeks wrote: >>>> http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf >>>> >>> That's rather a surprising choice (ATM product) for an IP network. >>> Please describe what backbone you are running that uses a FASTLANE? >> >> I'd be surprised if a civilian org could buy a fastlane device,.. >> maybe they moved out of the gov't only world though since the last >> time I saw one? It does claim to do oc-48 rate sonet though. > > http://www.gdc4s.com/kg-530.html > > claims 40gbps... I don't know that a purely civilian org can purchase > these though, nor the kg-75, despite these being on the GD site. > And at $189,950 MSRP, obviously every ISP is dashing out the door for a pair for each and every long haul fiber link. ;-) Hard to see the IETF multi-vendor interoperability specifications. It does mention SNMPv3, unlike all their other products which use a proprietary management scheme. Also HTTP, although no mention of its purpose. At least the FASTLANE mentioned above specifies FIREFLY -- the mere rumor of which was our basis for naming Photuris [RFC2522]. >>> Hopefully, other folks are securing their PPP or ethernet packets? >>> >>> > But I don't see where you mention that Google is actually using these to secure your fiber? From chrisdunn1 at gmail.com Sun Jun 23 22:22:13 2013 From: chrisdunn1 at gmail.com (Chris Dunn) Date: Sun, 23 Jun 2013 17:22:13 -0500 Subject: PDU recommendations In-Reply-To: References: Message-ID: <04a201ce7060$1d768140$586383c0$@gmail.com> Been at a place where they have hundreds of APC's in production, all monitored and reporting back. Hardly a lick of trouble. Love the fact you can reboot the management interface in the rare case there is a hang and it does not affect the status of the outlets. -ChrisD. -----Original Message----- From: shawn wilson [mailto:ag4ve.us at gmail.com] Sent: Sunday, June 23, 2013 10:38 AM To: North American Network Operators Group Subject: PDU recommendations We currently use Triplite stuff but they've got an issue where after a few minutes, they stop accepting new tcp connections. We're adding a new 30A circuit and I'm thinking of going with APC (ran them in the past and never had any issues). However, I figured I'd see if there was a better brand / specific model recommendations for quality or bang / buck? Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From surfer at mauigateway.com Sun Jun 23 23:24:47 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 23 Jun 2013 16:24:47 -0700 Subject: Security over SONET/SDH Message-ID: <20130623162447.D485376D@m0005296.ppops.net> --- william.allen.simpson at gmail.com wrote: From: William Allen Simpson On 6/23/13 12:48 AM, Scott Weeks wrote: > By security protocol do you mean encrypting the traffic? > Like what a Fastlane does? > > http://www.gdc4s.com/Documents/Products/SecureVoiceData/NetworkEncryption/GD-FASTLANE-w.pdf > That's rather a surprising choice (ATM product) for an IP network. Please describe what backbone you are running that uses a FASTLANE? Hopefully, other folks are securing their PPP or ethernet packets? --------------------------------------------------------------- A network that's going to change very soon. :-) What I meant is that what you mean by security protocols. I didn't follow completely. scott From symack at gmail.com Sun Jun 23 23:40:10 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 23 Jun 2013 19:40:10 -0400 Subject: PDU recommendations In-Reply-To: <04a201ce7060$1d768140$586383c0$@gmail.com> References: <04a201ce7060$1d768140$586383c0$@gmail.com> Message-ID: And now for the stupid question. Is there an APC UPS in a U form factor with sufficient outlets that can act kind of like a PDU, only better? PS If it has stonith capabilities ever better!!! Kind Regards, Nick. From t at trey.net Sun Jun 23 23:48:18 2013 From: t at trey.net (Trey Valenta) Date: Sun, 23 Jun 2013 16:48:18 -0700 Subject: PDU recommendations In-Reply-To: <04a201ce7060$1d768140$586383c0$@gmail.com> References: <04a201ce7060$1d768140$586383c0$@gmail.com> Message-ID: <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> I'll also throw out recommendations for ServTech PDUs. They have an affordable line of PDUs with static transfer switches that are particularly attractive for all your single-power-supply devices. Chris Dunn wrote: >Been at a place where they have hundreds of APC's in production, all >monitored and reporting back. Hardly a lick of trouble. >Love the fact you can reboot the management interface in the rare case >there is a hang and it does not affect the status of the outlets. >-ChrisD. > > >-----Original Message----- >From: shawn wilson [mailto:ag4ve.us at gmail.com] >Sent: Sunday, June 23, 2013 10:38 AM >To: North American Network Operators Group >Subject: PDU recommendations > >We currently use Triplite stuff but they've got an issue where after a >few minutes, they stop accepting new tcp connections. We're adding a >new 30A circuit and I'm thinking of going with APC (ran them in the >past and never had any issues). However, I figured I'd see if there was >a better brand / specific model recommendations for quality or bang / >buck? > >Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From Valdis.Kletnieks at vt.edu Sun Jun 23 23:49:14 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 23 Jun 2013 19:49:14 -0400 Subject: .biz DNSSEC borked In-Reply-To: Your message of "Sat, 22 Jun 2013 20:45:44 +0200." <51C5F0D8.3050706@tomt.net> References: <51C5F0D8.3050706@tomt.net> Message-ID: <94912.1372031354@turing-police.cc.vt.edu> On Sat, 22 Jun 2013 20:45:44 +0200, Andre Tomt said: > Seems the entire .biz tld is failing DNSSEC validation now. > All of my DNSSEC validating resolvers are tossing all domains in .biz. > The non-signed domains too of course because trust of the tld itself > cannot be established. > > http://dnssec-debugger.verisignlabs.com/nic.biz So which event caused more disruption? 50K .com's in a failed DDoS mitigation, or every single .biz lookup by something that actually does dnssec? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sun Jun 23 23:50:19 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 23 Jun 2013 19:50:19 -0400 Subject: Security over SONET/SDH In-Reply-To: Your message of "Sun, 23 Jun 2013 17:03:49 -0400." <51C762B5.40307@gmail.com> References: <20130622214849.D48550B0@m0005296.ppops.net> <51C6FC7B.20703@gmail.com> <51C762B5.40307@gmail.com> Message-ID: <94961.1372031419@turing-police.cc.vt.edu> On Sun, 23 Jun 2013 17:03:49 -0400, William Allen Simpson said: > Hard to see the IETF multi-vendor interoperability specifications. It > does mention SNMPv3, unlike all their other products which use a > proprietary management scheme. Also HTTP, Not HTTPS? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ikiris at gmail.com Mon Jun 24 00:26:01 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Sun, 23 Jun 2013 19:26:01 -0500 Subject: PDU recommendations In-Reply-To: References: <04a201ce7060$1d768140$586383c0$@gmail.com> Message-ID: Nick, he meant he was using APC PDUs, not APC UPSs with PDU functionality... APC is also the PDU vendor I would recommend. On Sun, Jun 23, 2013 at 6:40 PM, Nick Khamis wrote: > And now for the stupid question. Is there an APC UPS in a U form factor > with sufficient > outlets that can act kind of like a PDU, only better? > > PS If it has stonith capabilities ever better!!! > > Kind Regards, > > Nick. > > From jared at puck.Nether.net Mon Jun 24 00:31:02 2013 From: jared at puck.Nether.net (Jared Mauch) Date: Sun, 23 Jun 2013 20:31:02 -0400 Subject: .biz DNSSEC borked In-Reply-To: <94912.1372031354@turing-police.cc.vt.edu> References: <51C5F0D8.3050706@tomt.net> <94912.1372031354@turing-police.cc.vt.edu> Message-ID: <20130624003102.GA12610@puck.nether.net> On Sun, Jun 23, 2013 at 07:49:14PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Sat, 22 Jun 2013 20:45:44 +0200, Andre Tomt said: > > Seems the entire .biz tld is failing DNSSEC validation now. > > All of my DNSSEC validating resolvers are tossing all domains in .biz. > > The non-signed domains too of course because trust of the tld itself > > cannot be established. > > > > http://dnssec-debugger.verisignlabs.com/nic.biz > > So which event caused more disruption? 50K .com's in a failed DDoS > mitigation, or every single .biz lookup by something that actually does > dnssec? I think two different things happened here: 1) biz breakage reinforces the fact that validation can cause disruption. if it were .com and not fixed for a few hours, every major ISP would likely turn off validation for a year or more. 2) com issue shows some major "brands" they need to be more demanding from their providers. some really interesting data here, i ran a few domains through some dns server lists i have lying around, and saw stuff like this: 8.23.128.129/53/www.usps.com^IN^CNAME^www.usps.com.edgekey.net|www.usps.com.edgekey.net^IN^CNAME^usps.georedirector.usps.com.akadns.net|usps.georedirector.usps.com.akadns.net^IN^CNAME^e7154.dscb.akamaiedge.net|e7154.dscb.akamaiedge.net^IN^A^23.35.198.219//usps.com^IN^NS^ns1621.ztomy.com|usps.com^IN^NS^ns2621.ztomy.com so, you see www.usps.com points at edgekey, but the authority for usps.com was still held as ztomy for some time. (I don't have it printing the TTLs, but could add that...) This excludes DNS servers that are *very* broken, such as will replace existing authority/delegation w/ stuff returned in an unrelated query (as seen above) or other unsolicited data. (i get many servers that tell me stuff I *really* didn't ask for) (i queried for openresolverproject and got back something about betterbricks.com) 190.51.146.2/21528/betterbricks.com^IN^MX^30 betterbricks.com.s10b1.psmtp.com|betterbricks.com^IN^MX^40 betterbricks.com.s10b2.psmtp.com|betterbricks.com^IN^MX^10 betterbricks.com.s10a1.psmtp.com|betterbricks.com^IN^MX^20 betterbricks.com.s10a2.psmtp.com// or this that seems to delegate root to some nipr.mil host. 214.4.226.2/53//con2.nipr.mil^IN^A^199.252.162.234|con1.nipr.mil^IN^A^207.132.116.25/.^IN^NS^con2.nipr.mil|.^IN^NS^con1.nipr.mil - 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 acaruso at mre-consulting.com Mon Jun 24 00:39:20 2013 From: acaruso at mre-consulting.com (Caruso, Anthony) Date: Mon, 24 Jun 2013 00:39:20 +0000 Subject: PDU recommendations In-Reply-To: References: <04a201ce7060$1d768140$586383c0$@gmail.com> , Message-ID: <5DA9A041-B1B1-4550-AE05-008D0F48A405@mre-consulting.com> I used an APC (I think) 1U PDU at a client a few years back. The bugger was it wasn't deep, so after the cabinet started getting really populated, the back outlets were a PITA. We started using the full-height back of the cabinet PDU strips (one on each side for A & B power respectively) after that SNAFU. -T On Jun 23, 2013, at 7:27 PM, "Blake Dunlap" wrote: > Nick, he meant he was using APC PDUs, not APC UPSs with PDU functionality... > > > APC is also the PDU vendor I would recommend. > > > On Sun, Jun 23, 2013 at 6:40 PM, Nick Khamis wrote: > >> And now for the stupid question. Is there an APC UPS in a U form factor >> with sufficient >> outlets that can act kind of like a PDU, only better? >> >> PS If it has stonith capabilities ever better!!! >> >> Kind Regards, >> >> Nick. >> >> ________________________________ This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. From tritran at cox.net Mon Jun 24 00:16:16 2013 From: tritran at cox.net (tritran at cox.net) Date: Mon, 24 Jun 2013 00:16:16 +0000 Subject: PDU recommendations Message-ID: <1840224138-1372034704-cardhu_decombobulator_blackberry.rim.net-841145959-@b25.c19.bise6.blackberry> Eaton have 1U UPS that provide the same runtime as a 2U APC. Are they any good? ------Original Message------ From: Nick Khamis To: Chris Dunn Cc: North American Network Operators Group Subject: Re: PDU recommendations Sent: Jun 23, 2013 4:40 PM And now for the stupid question. Is there an APC UPS in a U form factor with sufficient outlets that can act kind of like a PDU, only better? PS If it has stonith capabilities ever better!!! Kind Regards, Nick. From lsc at prgmr.com Mon Jun 24 00:57:47 2013 From: lsc at prgmr.com (Luke S. Crawford) Date: Sun, 23 Jun 2013 17:57:47 -0700 Subject: PDU recommendations In-Reply-To: <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> Message-ID: <51C7998B.50500@prgmr.com> I also have had good experience with (used) servertech/century/power tower (I think all the same brand) - very inexpensive; if you are in santa clara I have some spare 2u 16 port 208v (20a/c19) units. Here is something a buddy wrote up when we were wiring them to the user-accessable power on/off menu: http://blog.prgmr.com/xenophobia/2012/02/notes-on-setting-up-a-sentry-p.html My new rack is all avocent PM3001-401 units. Used, of course; but the feature I was after was per-port power monitoring. I haven't quite gotten 'em all the way figured out yet. One thing I see as a negative (but might be positive?) is that they have fuses, not breakers. I don't know if this provides better protection; I do know that when my buddy overloaded one of them in testing, I had to replace fuses, rather than just switching a breaker back. (also, when a different buddy plugged a ancient desktop (so old the PSU wasn't auto-switch) with the power input switch set to 110 in, it blew some of the fuses in the PDU (and took out the rack) - it didn't damage any of the other servers on the pdu (other than taking out the PDU; but everything came back up when I swapped it with my spare.) Also note, uh, the servertech and the avocent and I think all the other PDUs I've seen can reboot the management interface without flipping the outlets. I did it a bunch when I was getting familiar with the avocent. Yeah. I think I need to give fewer buddies access to production. Nobody takes hardware seriously enough. I can find people I trust with root, and that trust doesn't seem misplaced. But I let them touch the hardware? and they fuck it up. So I end up doing almost all the hardware stuff myself. On 06/23/2013 04:48 PM, Trey Valenta wrote: > I'll also throw out recommendations for ServTech PDUs. They have an affordable line of PDUs with static transfer switches that are particularly attractive for all your single-power-supply devices. From bill at ellipticalmobilesolutions.com Sun Jun 23 21:52:05 2013 From: bill at ellipticalmobilesolutions.com (Bill Breckenridge) Date: Sun, 23 Jun 2013 21:52:05 +0000 Subject: PDU recommendations In-Reply-To: References: <2116639343-1372014321-cardhu_decombobulator_blackberry.rim.net-1062653634-@b25.c19.bise6.blackberry> Message-ID: <93345de468354fcaae722420fddadabf@BY2PR04MB192.namprd04.prod.outlook.com> We have switched to Chatsworth products PDU line - robust and dependable in over 100 redundant installs - all outlet/environmental/SNMP and other options well behaved with plug-ins as well tech support is easier to access/escalate Bill -----Original Message----- From: Petter Bruland [mailto:Petter.Bruland at allegiantair.com] Sent: Sunday, June 23, 2013 3:42 PM To: tritran at cox.net; shawn wilson; North American Network Operators Group Subject: RE: PDU recommendations We're replacing TrippLite with APC. Had two TrippLite SNMP/Web cards stop working at random times, and need to be reset. Pain when the datacenter is far away. On a different note TrippLite support has been super awesome. The APC line we went with, model # escaping me at the moment, only had overall unit AMP load indicator. But their SNMP access is nice, for custom graphs in Cacti etc, and being able to remote bounce an outlet. We did have a few WTI, the really old ones, which did not store the config in flash, thus needed to be reconfigured via serial after power outage. Even with that annoyance, they had much faster response time from telnet (....I know, old) turning on/off outlets than either of APC or TrippLite. -Petter ________________________________________ From: tritran at cox.net [tritran at cox.net] Sent: Sunday, June 23, 2013 12:05 PM To: shawn wilson; North American Network Operators Group Subject: Re: PDU recommendations APC is solid. Their newer line can provide outlet metering. WTI is also good...they support redundant circuits. I've seen Baytech died after just unplugging a server. ------Original Message------ From: shawn wilson To: North American Network Operators Group Subject: PDU recommendations Sent: Jun 23, 2013 8:37 AM We currently use Triplite stuff but they've got an issue where after a few minutes, they stop accepting new tcp connections. We're adding a new 30A circuit and I'm thinking of going with APC (ran them in the past and never had any issues). However, I figured I'd see if there was a better brand / specific model recommendations for quality or bang / buck? Specs: 30A 24+ port 0U, managed (with ssh), lcd use display. From ag4ve.us at gmail.com Mon Jun 24 01:32:00 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 23 Jun 2013 21:32:00 -0400 Subject: PDU recommendations In-Reply-To: <51C7998B.50500@prgmr.com> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> Message-ID: So, that's not a very good endorsement :) Idk why you'd use a fuse in a PDU. The management interface can be rebooted without taking anything down on the TrippLite but it's at a colo and it *shouldn't* time out like it does. I think of this like a vehicle computer - if it goes down, you might still drive for a little but get ready for a crash. On Jun 23, 2013 9:00 PM, "Luke S. Crawford" wrote: > I also have had good experience with (used) servertech/century/power tower > (I think all the same brand) - very inexpensive; if you are in santa > clara I have some spare 2u 16 port 208v (20a/c19) units. > > Here is something a buddy wrote up when we were wiring them to the > user-accessable power on/off menu: > > http://blog.prgmr.com/**xenophobia/2012/02/notes-on-** > setting-up-a-sentry-p.html > > > My new rack is all avocent PM3001-401 units. Used, of course; but the > feature I was after was per-port power monitoring. > > I haven't quite gotten 'em all the way figured out yet. One thing I see > as a negative (but might be positive?) is that they have fuses, not > breakers. I don't know if this provides better protection; I do know > that when my buddy overloaded one of them in testing, I had to replace > fuses, rather than just switching a breaker back. (also, when a different > buddy plugged a ancient desktop (so old the PSU wasn't auto-switch) with > the power input switch set to 110 in, it blew some of the fuses in the PDU > (and took out the rack) - it didn't damage any of the other servers on the > pdu (other than taking out the PDU; but everything came back up when I > swapped it with my spare.) > > Also note, uh, the servertech and the avocent and I think all the other > PDUs I've seen can reboot the management interface without flipping the > outlets. I did it a bunch when I was getting familiar with the avocent. > > Yeah. I think I need to give fewer buddies access to production. > > > Nobody takes hardware seriously enough. I can find people I trust with > root, and that trust doesn't seem misplaced. But I let them touch the > hardware? and they fuck it up. So I end up doing almost all the > hardware stuff myself. > > > > On 06/23/2013 04:48 PM, Trey Valenta wrote: > >> I'll also throw out recommendations for ServTech PDUs. They have an >> affordable line of PDUs with static transfer switches that are particularly >> attractive for all your single-power-supply devices. >> > > > From gdt at gdt.id.au Mon Jun 24 02:18:30 2013 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 24 Jun 2013 11:48:30 +0930 Subject: Security over SONET/SDH In-Reply-To: <51C670B5.7010001@gmail.com> References: <51C670B5.7010001@gmail.com> Message-ID: On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: > What security protocols are folks using to protect SONET/SDH? > At what speeds? "Excuse me NSA, can I have export approval for one KG-530 SDH encryptor?" What are the odds :-) And how would we know that the "export model" isn't simply providing a more convenient backdoor for the NSA? -glen From fmartin at linkedin.com Mon Jun 24 02:50:32 2013 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 24 Jun 2013 02:50:32 +0000 Subject: .biz DNSSEC borked In-Reply-To: <94912.1372031354@turing-police.cc.vt.edu> References: <51C5F0D8.3050706@tomt.net> <94912.1372031354@turing-police.cc.vt.edu> Message-ID: <77426B543150464AA3F30DF1A91365DE53301070@ESV4-MBX01.linkedin.biz> On Jun 23, 2013, at 4:49 PM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 22 Jun 2013 20:45:44 +0200, Andre Tomt said: >> Seems the entire .biz tld is failing DNSSEC validation now. >> All of my DNSSEC validating resolvers are tossing all domains in .biz. >> The non-signed domains too of course because trust of the tld itself >> cannot be established. >> >> http://dnssec-debugger.verisignlabs.com/nic.biz > > So which event caused more disruption? 50K .com's in a failed DDoS > mitigation, or every single .biz lookup by something that actually does > dnssec? > I don't think we are trying to quantify which one was worst or point fingers at, but how do we remediate these type of issues in the future? I think these events will happen more and more often... a TTL of 2 days seems rather long for NS and do I see 6 days TTL for DNSSEC records for .biz ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From LarrySheldon at cox.net Mon Jun 24 02:37:20 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 23 Jun 2013 21:37:20 -0500 Subject: Security over SONET/SDH In-Reply-To: References: <51C670B5.7010001@gmail.com> Message-ID: <51C7B0E0.1060305@cox.net> On 6/23/2013 9:18 PM, Glen Turner wrote: > > On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: > >> What security protocols are folks using to protect SONET/SDH? At >> what speeds? > > > "Excuse me NSA, can I have export approval for one KG-530 SDH > encryptor?" What are the odds :-) > > And how would we know that the "export model" isn't simply providing > a more convenient backdoor for the NSA? I assumed that the latter is what "NSA Approved" means. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From morrowc.lists at gmail.com Mon Jun 24 05:26:50 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Jun 2013 01:26:50 -0400 Subject: Security over SONET/SDH In-Reply-To: References: <51C670B5.7010001@gmail.com> Message-ID: On Sun, Jun 23, 2013 at 10:18 PM, Glen Turner wrote: > > On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: > >> What security protocols are folks using to protect SONET/SDH? >> At what speeds? > > > "Excuse me NSA, can I have export approval for one KG-530 SDH encryptor?" What are the odds :-) > > And how would we know that the "export model" isn't simply providing a more convenient backdoor for the NSA? crypto-ag anyone? From morrowc.lists at gmail.com Mon Jun 24 05:27:34 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Jun 2013 01:27:34 -0400 Subject: Security over SONET/SDH In-Reply-To: <51C762B5.40307@gmail.com> References: <20130622214849.D48550B0@m0005296.ppops.net> <51C6FC7B.20703@gmail.com> <51C762B5.40307@gmail.com> Message-ID: On Sun, Jun 23, 2013 at 5:03 PM, William Allen Simpson wrote: > And at $189,950 MSRP, obviously every ISP is dashing out the door > for a pair for each and every long haul fiber link. ;-) cheaper by the dozen? From wbailey at satelliteintelligencegroup.com Mon Jun 24 06:46:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 24 Jun 2013 06:46:21 +0000 Subject: Google news down Message-ID: Does anyone happen to know what's going on with Google news? Getting an xml parse error for all responses (not well formed) to anything google news related. NSA taking down google news or something? Sent from my Mobile Device. From shortdudey123 at gmail.com Mon Jun 24 06:50:21 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 23 Jun 2013 23:50:21 -0700 Subject: Google news down In-Reply-To: References: Message-ID: Main page is accessible fine from a comcast circuit in Mountain View, CA 3 13 ms 11 ms 10 ms te-0-0-0-12-ur05.santaclara.ca.sfba.comcast.net [2001:558:82:87::1] 4 14 ms 35 ms 14 ms te-1-1-0-11-ar01.sfsutro.ca.sfba.comcast.net[2001:558:80:40::1] 5 50 ms 14 ms 43 ms he-3-7-0-0-cr01.sanjose.ca.ibone.comcast.net[2001:558:0:f775::1] 6 16 ms 14 ms 13 ms pos-0-5-0-0-pe01.529bryant.ca.ibone.comcast.net [2001:558:0:f600::2] 7 12 ms 13 ms 13 ms 2001:559::386 8 13 ms 13 ms 14 ms 2001:4860::1:0:7ea 9 17 ms 13 ms 15 ms 2001:4860:0:1::693 10 15 ms 41 ms 14 ms nuq05s02-in-x00.1e100.net[2607:f8b0:4005:802::1000] Trace complete. On Sun, Jun 23, 2013 at 11:46 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Does anyone happen to know what's going on with Google news? Getting an > xml parse error for all responses (not well formed) to anything google news > related. > > NSA taking down google news or something? > > > Sent from my Mobile Device. > From wbailey at satelliteintelligencegroup.com Mon Jun 24 06:54:52 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 24 Jun 2013 06:54:52 +0000 Subject: Google news down In-Reply-To: References: Message-ID: <3rcegxat81d6gnma26oubsfm.1372056887802@email.android.com> Seems to be isolated to the mobile site, if anyone finds it of interest. Sent from my Mobile Device. -------- Original message -------- From: Warren Bailey Date: 06/23/2013 11:48 PM (GMT-08:00) To: nanog at nanog.org Subject: Google news down Does anyone happen to know what's going on with Google news? Getting an xml parse error for all responses (not well formed) to anything google news related. NSA taking down google news or something? Sent from my Mobile Device. From joly at punkcast.com Mon Jun 24 07:37:50 2013 From: joly at punkcast.com (Joly MacFie) Date: Mon, 24 Jun 2013 03:37:50 -0400 Subject: Google news down In-Reply-To: <3rcegxat81d6gnma26oubsfm.1372056887802@email.android.com> References: <3rcegxat81d6gnma26oubsfm.1372056887802@email.android.com> Message-ID: Maybe they are adjusting in preparation for Aug 1. http://techcrunch.com/2013/06/21/google-makes-google-news-in-germany-opt-in-only-to-avoid-paying-fees-under-new-copyright-law/ On Mon, Jun 24, 2013 at 2:54 AM, Warren Bailey wrote: > Seems to be isolated to the mobile site, if anyone finds it of interest. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Warren Bailey > Date: 06/23/2013 11:48 PM (GMT-08:00) > To: nanog at nanog.org > Subject: Google news down > > > Does anyone happen to know what's going on with Google news? Getting an xml parse error for all responses (not well formed) to anything google news related. > > NSA taking down google news or something? > > > Sent from my Mobile Device. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From andra.lutu at imdea.org Mon Jun 24 08:07:01 2013 From: andra.lutu at imdea.org (Andra Lutu) Date: Mon, 24 Jun 2013 10:07:01 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: References: Message-ID: <51C7FE25.3050109@imdea.org> Hi, From public routing data we can see a total of 2,419 /25s prefixes announced from at least one of the monitors active in RIPE RIS and RouteViews. None of the /25s are actually advertised by all these monitors i.e. the /25s reach some but not all the ASes which take part in these projects. The actual distribution of how many unique routing tables sampled contain the /25s is the following: http://visibility.it.uc3m.es/len25_distro.html (out of the approx. 140 collectors that have a "full" routing table). The top 5 ASes that are originating the most /25s are: AS 11427: 462 /25s AS 4766: 273 /25s AS 45400: 109 /25s AS 14065: 82 /25s AS 3549: 57 /25s If you are interested in limited visibility prefixes, i.e., prefixes that are distributed to some but not all the "full" routing tables at the interdomain level, you can find more at http://visibility.it.uc3m.es/ and https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner Best regards, Andra On 06/22/2013 12:00 AM, nanog-request at nanog.org wrote: > Date: Fri, 21 Jun 2013 13:56:02 -0600 > From: Michael McConnell > To: North American Network Operators Group > Subject: /25's prefixes announced into global routing table? > > Hello all, > > As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size? > > Cheers, > Mike From shortdudey123 at gmail.com Mon Jun 24 08:13:48 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Mon, 24 Jun 2013 01:13:48 -0700 Subject: Google news down In-Reply-To: References: <3rcegxat81d6gnma26oubsfm.1372056887802@email.android.com> Message-ID: Mobile page works fine via the same comcast circuit as previously mentioned On Mon, Jun 24, 2013 at 12:37 AM, Joly MacFie wrote: > Maybe they are adjusting in preparation for Aug 1. > > > http://techcrunch.com/2013/06/21/google-makes-google-news-in-germany-opt-in-only-to-avoid-paying-fees-under-new-copyright-law/ > > On Mon, Jun 24, 2013 at 2:54 AM, Warren Bailey > wrote: > > Seems to be isolated to the mobile site, if anyone finds it of interest. > > > > > > Sent from my Mobile Device. > > > > > > -------- Original message -------- > > From: Warren Bailey > > Date: 06/23/2013 11:48 PM (GMT-08:00) > > To: nanog at nanog.org > > Subject: Google news down > > > > > > Does anyone happen to know what's going on with Google news? Getting an > xml parse error for all responses (not well formed) to anything google news > related. > > > > NSA taking down google news or something? > > > > > > Sent from my Mobile Device. > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - > > From mansaxel at besserwisser.org Mon Jun 24 10:10:08 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 24 Jun 2013 12:10:08 +0200 Subject: PDU recommendations In-Reply-To: References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> Message-ID: <20130624101008.GA9807@besserwisser.org> Subject: Re: PDU recommendations Date: Sun, Jun 23, 2013 at 09:32:00PM -0400 Quoting shawn wilson (ag4ve.us at gmail.com): > So, that's not a very good endorsement :) > > Idk why you'd use a fuse in a PDU. MCB units age. Especially with vibration. A 10A MCB becomes a 9A MCB after some miles. Fuses don't. MCB units are good at protecting people since they trip quickly and aggressively. Fuses tend to linger before blowing, and thus are comparatively bad at protecting people (longer shock) but better at protecting infrastructure (surge and switch-on-transient resistance). -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS in a $200,000 MALIBU BEACH HOUSE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Mon Jun 24 11:04:23 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 24 Jun 2013 20:04:23 +0900 Subject: /25's prefixes announced into global routing table? In-Reply-To: <20130622051431.85077.qmail@joyce.lan> References: <20130622051431.85077.qmail@joyce.lan> Message-ID: <51C827B7.9080402@necom830.hpcl.titech.ac.jp> John Levine wrote: > I realize it's not quite that simple due to issues of longer prefixes > taking precedence over shorter ones, but it is my impression that > there's a lot of sloppiness. 16M /24 is just a cheap 16M entry SRAM. However, 16M /32 means 4G entry SRAM or 16M entry CAM. 16M entry with /40 or /48 prefix means 16M entry CAM, which is hard, which is why IPv6 is hard. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Mon Jun 24 12:16:51 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 24 Jun 2013 21:16:51 +0900 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C5A282.4010207@danysek.cz> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> <51C5A282.4010207@danysek.cz> Message-ID: <51C838B3.2030503@necom830.hpcl.titech.ac.jp> Daniel Suchy wrote: >> There are techniques to fix that. For example, Simple Virtual Aggregation >> http://tools.ietf.org/html/rfc6769 > I'm not sure, if hardware vendors will implement something like this. I > expect they'll sell you router with larger hardware FIB instead. As the RFC says: Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. it assumes some routers in the AS have unaggregated routing table entries. Thus, even within the AS, the RFC is not very effective. The RFC, either, does not help to reduce the number of routing table entries exchanged between adjacent ASes. Masataka Ohta From adam.vitkovsky at swan.sk Mon Jun 24 12:21:01 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 24 Jun 2013 14:21:01 +0200 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: References: Message-ID: <035701ce70d5$4a4f2990$deed7cb0$@swan.sk> > route reflectors should be in the data plane, ... I believe in modern networks data-plane and control-plane(s) should be separated as it provides for great scalability and versatility the drawback of course is a more complex system to manage. adam From randy at psg.com Mon Jun 24 12:31:59 2013 From: randy at psg.com (Randy Bush) Date: Mon, 24 Jun 2013 21:31:59 +0900 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: <035701ce70d5$4a4f2990$deed7cb0$@swan.sk> References: <035701ce70d5$4a4f2990$deed7cb0$@swan.sk> Message-ID: >> route reflectors should be in the data plane, ... > I believe in modern networks data-plane and control-plane(s) should be > separated as it provides for great scalability and versatility the > drawback of course is a more complex system to manage. more complex systems scale poorly, break easily, and are hard to debug. oops! all my competitors should have such 'modern networks.' randy From randy at psg.com Mon Jun 24 12:39:11 2013 From: randy at psg.com (Randy Bush) Date: Mon, 24 Jun 2013 21:39:11 +0900 Subject: IPv6 adoption in the past few days In-Reply-To: <51C703D2.8080305@cis.vutbr.cz> References: <51C703D2.8080305@cis.vutbr.cz> Message-ID: > there is massive increase in IPv6 adoption (from 1.5% to 1.7%) in the > past few days. luckily i had my seatbelt fastened randy From eric at roxanne.org Mon Jun 24 13:13:34 2013 From: eric at roxanne.org (Eric) Date: Mon, 24 Jun 2013 09:13:34 -0400 Subject: Network diagnostics for the end user In-Reply-To: <51C5283E.4020802@gmail.com> References: <51C5283E.4020802@gmail.com> Message-ID: <750E59F9-B8B8-4519-93F6-5D061C3EE6C4@roxanne.org> +1. It's especially helpful for wireless troubleshooting in a campus environment. You can get a lot of info from the AP, but tend not to know what the client is seeing and it's great for catching transient events (oh, whenever the elevator goes by...) Eric On Jun 22, 2013, at 12:29 AM, "Carlos M. Martinez" wrote: > May sound silly, but in another life I faced a similar problem and by > hosting local SpeedTest.net servers in our network we could fend off > many of these calls. > > But I guess it will depend on your customers, whether they take it or not. > > cheers, > > ~Carlos > > On 6/20/13 9:45 PM, Jeffrey Ollie wrote: >> Are there any tools out there that we could give to our end users to help >> diagnose network problems? We get a lot of "the Internet is slow" support >> calls and it would be helpful if we had something that would run on the end >> user's computer and help characterize the problem. We have central >> monitoring system of course but that doesn't always give a complete >> picture, as the problem could always be on the end user's computer - slow >> hard drive, not enough memory, wrong name servers, etc. > From jerome at ceriz.fr Mon Jun 24 13:22:39 2013 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Mon, 24 Jun 2013 15:22:39 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E25D9CF@eusaamb109.ericsson.se> Message-ID: <51C8481F.3050209@ceriz.fr> Le 22/06/2013 00:27, Jakob Heitz a ?crit : > There are techniques to fix that. For example, Simple Virtual Aggregation > http://tools.ietf.org/html/rfc6769 The principle behind this RFC is that RAM (RIB) is cheap, CAM (FIB) is not. But it's mostly intended for SDN developpments. You need a full RIB on every (current - non SDN) BGP speakers in only one scenario : beeing a transit provider. If you're not, there's no point in keeping (and least to install) all routes. But let's say you have enough RAM to store a very large de-aggregated RIB, and a smaller TCAM. The best path selection takes place in RIB, and selected best path can be installed as long as you have free space in CAM. Let's compress (agregate) the table prior to installation, by creating agregates over adjacent prefixes having only the same next-hop and origin AS, and you may fit a virtual-full-view, perfectly matching your routing policy, with far less physical routes to install. This will probably not be backported to "obsolete" routers, but it would be natural to operate in such manners for an SDN control plane. It *could* be deployed on older hardware using some customized BGP speakers : use a software BGP speaker as a route-server / route-reflector, get all your eBGP peers to hook to this speaker instead of your ASBRs, and have the controller apply dynamic compression to the route table (dynamic meaning it has to be a localy optimized agregate different for every routers in your network) and feed it to your ASBRs through iBGP. There would be different levels of agregation : destructive or not, matching the exact policy or cutting some slack to fit in smaller TCAMs. For instance, having AS paths in the local RIB in your ASBRs is required for netflow/ipfix AS agregates. You may not care about AS beeing too far from your network, thus generating agregates over multiple adjacent prefixes originating form different AS is not an issue : if you agregate every prefixes matching the same 3-4 (deduplicated) AS in the path, let's use the last as origin, and agregate all the adjacent blocks in a signle prefix, as long as your best-path selection concluded in using the same next-hop for all of them. If you want a more agressive compression, then you may decide not to fully respect the routing policy, and agregate over a minor block (let's say a few /24 have a different next hop than their common less-specific /12), discard the specificity and enjoy shooting /24s off your CAM. If such a software existed (it's not yet available AFAIK, I wrote some code to try the concept but it's still far from beeing usable), you may actually run a real network with less than 30k route entries in your CAM... -- J?r?me Nicolle +33 6 19 31 27 14 From adam.vitkovsky at swan.sk Mon Jun 24 13:53:06 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 24 Jun 2013 15:53:06 +0200 Subject: Multihop eBGP peering or VPN based eBGP peering In-Reply-To: References: <035701ce70d5$4a4f2990$deed7cb0$@swan.sk> Message-ID: <036501ce70e2$279c2f30$76d48d90$@swan.sk> -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, June 24, 2013 2:32 PM To: Adam Vitkovsky Cc: 'John van Oppen'; nanog at nanog.org Subject: Re: Multihop eBGP peering or VPN based eBGP peering >>> route reflectors should be in the data plane, ... >> I believe in modern networks data-plane and control-plane(s) should be >> separated as it provides for great scalability and versatility the >> drawback of course is a more complex system to manage. >more complex systems scale poorly, break easily, and are hard to debug. >oops! all my competitors should have such 'modern networks.' >randy Well in the context of RRs complex systems have virtually endless scalability, they are built with redundancy in mind so they don't break or don't break easily and well as far as the debug goes, I think it's a matter of how well are the Operations educated by the architects. adam From patrick at ianai.net Mon Jun 24 14:27:19 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 24 Jun 2013 10:27:19 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <51C60608.4030301@Janoszka.pl> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> <722494DF-8253-4AEA-BDFF-2BB4D73AF7AD@delong.com> <51C60608.4030301@Janoszka.pl> Message-ID: <6037C600-3DCB-4C99-86C0-553C4E0B7E1D@ianai.net> On Jun 22, 2013, at 16:16 , Grzegorz Janoszka wrote: > On 22-06-13 17:30, Owen DeLong wrote: >> Looking at the number of autonomous systems in the IPv6 routing table and the total number of routes, it looks like it will shake out somewhere in the neighborhood of 3-5 prefixes/ASN. Since there are ~35,000 unique ASNs in the IPv4 table, I figured simple multiplication provided as good an estimate as any at this early time. > > Deaggregating of IPv4 announcements is done for traffic engineering and > to fight ddoses (just the attacked /24 stops being announced to > internet). I think some people will just copy their v4 habits into v6 > and then we might have explosion of /48's. > I wouldn't be so sure about just 3-5 prefixes/ASN. Not that many people are de-aggregating in anticipation of the DDoS. Temporary de-agg during DDoS is not relevant to discussions on global table sizes. -- TTFN, patrick From standalone.sysadmin at gmail.com Mon Jun 24 15:30:00 2013 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Mon, 24 Jun 2013 11:30:00 -0400 Subject: Contact at GoGo Internet? Message-ID: For a reason that I'm unable to ascertain, GoGo In-Flight Internet can route to my university's network blog, but not to my specific college's. Does anyone have a contact there that I could reach out to and work to figure this out with? Thanks! --Matt Simmons -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From standalone.sysadmin at gmail.com Mon Jun 24 15:30:54 2013 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Mon, 24 Jun 2013 11:30:54 -0400 Subject: Contact at GoGo Internet? In-Reply-To: References: Message-ID: And by "blog", of course I meant "block". Sorry! On Mon, Jun 24, 2013 at 11:30 AM, Matt Simmons < standalone.sysadmin at gmail.com> wrote: > For a reason that I'm unable to ascertain, GoGo In-Flight Internet can > route to my university's network blog, but not to my specific college's. > > Does anyone have a contact there that I could reach out to and work to > figure this out with? > > Thanks! > > --Matt Simmons > > > -- > LITTLE GIRL: But which cookie will you eat FIRST? > COOKIE MONSTER: Me think you have misconception of cookie-eating process. > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From mpetach at netflight.com Mon Jun 24 15:32:19 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 24 Jun 2013 08:32:19 -0700 Subject: Yahoo Postmaster In-Reply-To: References: Message-ID: On Fri, Jun 21, 2013 at 2:21 PM, Andy B. wrote: > If there is a YAHOO! Postmaster contact available, can you please > contact me off list? > > I need to investigate a customer's "TS03" listing of a very large > netblock (/16) and I'm afraid regular Yahoo! forms are leading me > nowhere but frustration and no results. > > > Thanks. > > Hi Andy, I'm not a postmaster, but I can probably put you in touch with an appropriate person, Thanks! Matt From rol at witbe.net Mon Jun 24 17:29:59 2013 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Mon, 24 Jun 2013 19:29:59 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> Message-ID: <20130624192959.0a0c844f@tux.DEF.witbe.net> Hello, On Fri, 21 Jun 2013 13:56:02 -0600 Michael McConnell wrote: > As the IPv4 space get smaller and smaller, does anyone think we'll see a > time when /25's will be accepted for global BGP prefix announcement. The > current smallest size is a /24 and generally ok for most people, but the > crunch gets tighter, routers continue to have more and more ram will it > always be /24 the smallest size? Well, /25 are already in the routing table. I can even find a few /26 !! rtr-01.PAR#sh ip b | i /26 *>i193.41.227.128/26 *>i193.41.227.192/26 *>i194.149.243.64/26 Paul -- TelcoTV Awards 2011 - Witbe winner in "Innovation in Test & Measurement" Paul Rolland E-Mail : rol(at)witbe.net CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La Defense RIPE : PR12-RIPE LinkedIn : http://www.linkedin.com/in/paulrolland Skype : rollandpaul "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From deleskie at gmail.com Mon Jun 24 17:42:27 2013 From: deleskie at gmail.com (jim deleskie) Date: Mon, 24 Jun 2013 14:42:27 -0300 Subject: /25's prefixes announced into global routing table? In-Reply-To: <20130624192959.0a0c844f@tux.DEF.witbe.net> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130624192959.0a0c844f@tux.DEF.witbe.net> Message-ID: I'm not going to even ask or look at who is accepting /26's -jim On Mon, Jun 24, 2013 at 2:29 PM, Paul Rolland wrote: > Hello, > > On Fri, 21 Jun 2013 13:56:02 -0600 > Michael McConnell wrote: > > > As the IPv4 space get smaller and smaller, does anyone think we'll see a > > time when /25's will be accepted for global BGP prefix announcement. The > > current smallest size is a /24 and generally ok for most people, but the > > crunch gets tighter, routers continue to have more and more ram will it > > always be /24 the smallest size? > > Well, /25 are already in the routing table. I can even find a few /26 !! > > rtr-01.PAR#sh ip b | i /26 > *>i193.41.227.128/26 > *>i193.41.227.192/26 > *>i194.149.243.64/26 > > Paul > > -- > TelcoTV Awards 2011 - Witbe winner in "Innovation in Test & Measurement" > > Paul Rolland E-Mail : rol(at)witbe.net > CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 > Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 > F-92057 Paris La Defense RIPE : PR12-RIPE > > LinkedIn : http://www.linkedin.com/in/paulrolland > Skype : rollandpaul > > "I worry about my child and the Internet all the time, even though she's > too young to have logged on yet. Here's what I worry about. I worry that 10 > or 15 years from now, she will come to me and say 'Daddy, where were you > when they took freedom of the press away from the Internet?'" > --Mike Godwin, Electronic Frontier Foundation > > > From rlambert.lists at gmail.com Mon Jun 24 18:41:44 2013 From: rlambert.lists at gmail.com (Ryan - Lists) Date: Mon, 24 Jun 2013 14:41:44 -0400 Subject: PDU recommendations In-Reply-To: <20130624101008.GA9807@besserwisser.org> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> <20130624101008.GA9807@besserwisser.org> Message-ID: <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> Does anyone on list have experience with the APC AP7920 switched rack PDU, or any of the horizontal rack mountables with management? We're looking at these for our remote sites. Sent from my iPhone On Jun 24, 2013, at 6:10 AM, M?ns Nilsson wrote: > Subject: Re: PDU recommendations Date: Sun, Jun 23, 2013 at 09:32:00PM -0400 Quoting shawn wilson (ag4ve.us at gmail.com): >> So, that's not a very good endorsement :) >> >> Idk why you'd use a fuse in a PDU. > > MCB units age. Especially with vibration. A 10A MCB becomes a 9A MCB after some miles. > > Fuses don't. > > MCB units are good at protecting people since they trip quickly and aggressively. > > Fuses tend to linger before blowing, and thus are comparatively bad at protecting > people (longer shock) but better at protecting infrastructure (surge > and switch-on-transient resistance). > > -- > M?ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS > in a $200,000 MALIBU BEACH HOUSE!! From wbailey at satelliteintelligencegroup.com Mon Jun 24 18:51:40 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 24 Jun 2013 18:51:40 +0000 Subject: PDU recommendations In-Reply-To: <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> <20130624101008.GA9807@besserwisser.org>, <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> Message-ID: <9cawb9rn89s7w4noup7kkvg4.1372099897732@email.android.com> We seem to always get calls from uplogix.. Check them out if you are considering managing pdu's etc. Their gear is pretty stout, and they have good to great support. Sent from my Mobile Device. -------- Original message -------- From: Ryan - Lists Date: 06/24/2013 11:43 AM (GMT-08:00) To: M?ns Nilsson Cc: North American Network Operators Group Subject: Re: PDU recommendations Does anyone on list have experience with the APC AP7920 switched rack PDU, or any of the horizontal rack mountables with management? We're looking at these for our remote sites. Sent from my iPhone On Jun 24, 2013, at 6:10 AM, M?ns Nilsson wrote: > Subject: Re: PDU recommendations Date: Sun, Jun 23, 2013 at 09:32:00PM -0400 Quoting shawn wilson (ag4ve.us at gmail.com): >> So, that's not a very good endorsement :) >> >> Idk why you'd use a fuse in a PDU. > > MCB units age. Especially with vibration. A 10A MCB becomes a 9A MCB after some miles. > > Fuses don't. > > MCB units are good at protecting people since they trip quickly and aggressively. > > Fuses tend to linger before blowing, and thus are comparatively bad at protecting > people (longer shock) but better at protecting infrastructure (surge > and switch-on-transient resistance). > > -- > M?ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS > in a $200,000 MALIBU BEACH HOUSE!! From patrick at ianai.net Mon Jun 24 18:53:08 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 24 Jun 2013 14:53:08 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: <20130624192959.0a0c844f@tux.DEF.witbe.net> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130624192959.0a0c844f@tux.DEF.witbe.net> Message-ID: <66F47611-8350-4A94-8FC9-1C73639CBDCC@ianai.net> On Jun 24, 2013, at 13:29 , Paul Rolland (???????) wrote: > On Fri, 21 Jun 2013 13:56:02 -0600 Michael McConnell wrote: >> As the IPv4 space get smaller and smaller, does anyone think we'll see a >> time when /25's will be accepted for global BGP prefix announcement. The >> current smallest size is a /24 and generally ok for most people, but the >> crunch gets tighter, routers continue to have more and more ram will it >> always be /24 the smallest size? > > Well, /25 are already in the routing table. I can even find a few /26 !! > > rtr-01.PAR#sh ip b | i /26 > *>i193.41.227.128/26 > *>i193.41.227.192/26 > *>i194.149.243.64/26 The question was when will we see /25s in the GLOBAL routing table. Despite the very un-well defined definition for "global routing table", I'm going to assuming something similar to the DFZ, or the set of prefixes which is seen in all (most of?) the transit-free networks[*]. Given that definition, there are exactly zero /25s in the GRT (DFZ). And unlikely to be for a while. Whether "a while" is "next 12 months" or "several years" is something I am very specifically choosing not to answer. -- TTFN, patrick [*] Don't you hate the term "tier one" these days? It doesn't mean what it used to mean (i.e. _settlement free_ peering with all other tier one networks). And given that there are non-transit-free networks with more [traffic|revenue|customers|$WHATEVER] than some transit free networks, I prefer to not use the term. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ahebert at pubnix.net Mon Jun 24 19:01:25 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 24 Jun 2013 15:01:25 -0400 Subject: PDU recommendations In-Reply-To: <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> <20130624101008.GA9807@besserwisser.org> <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> Message-ID: <51C89785.6070807@pubnix.net> Hi, Yes. They are good. Nothing I would deploy in a large data center but for a few racks they are perfect. Beware that they are not built to be connected straight to the internet =D. The management module can reset depending on packet payload and overall traffic. They should always be behind some sort of firewall with rules limiting its access. PS: Ours are a few years old, I'm sure APC added some sort of security since then, you may want to look 'em up. Happy 24th to all. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 06/24/13 14:41, Ryan - Lists wrote: > Does anyone on list have experience with the APC AP7920 switched rack PDU, or any of the horizontal rack mountables with management? We're looking at these for our remote sites. > > Sent from my iPhone > > On Jun 24, 2013, at 6:10 AM, M?ns Nilsson wrote: > >> Subject: Re: PDU recommendations Date: Sun, Jun 23, 2013 at 09:32:00PM -0400 Quoting shawn wilson (ag4ve.us at gmail.com): >>> So, that's not a very good endorsement :) >>> >>> Idk why you'd use a fuse in a PDU. >> MCB units age. Especially with vibration. A 10A MCB becomes a 9A MCB after some miles. >> >> Fuses don't. >> >> MCB units are good at protecting people since they trip quickly and aggressively. >> >> Fuses tend to linger before blowing, and thus are comparatively bad at protecting >> people (longer shock) but better at protecting infrastructure (surge >> and switch-on-transient resistance). >> >> -- >> M?ns Nilsson primary/secondary/besserwisser/machina >> MN-1334-RIPE +46 705 989668 >> There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS >> in a $200,000 MALIBU BEACH HOUSE!! > > From ag4ve.us at gmail.com Mon Jun 24 19:10:00 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 24 Jun 2013 15:10:00 -0400 Subject: PDU recommendations In-Reply-To: <51C89785.6070807@pubnix.net> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> <20130624101008.GA9807@besserwisser.org> <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> <51C89785.6070807@pubnix.net> Message-ID: Heh, I wouldn't dream of putting this type of device on the net - nothing good can come from that. On Jun 24, 2013 3:04 PM, "Alain Hebert" wrote: > Hi, > > Yes. > > They are good. > > Nothing I would deploy in a large data center but for a few racks > they are perfect. > > Beware that they are not built to be connected straight to the > internet =D. > > The management module can reset depending on packet payload and > overall traffic. They should always be behind some sort of firewall > with rules limiting its access. > > PS: Ours are a few years old, I'm sure APC added some sort of > security since then, you may want to look 'em up. > > Happy 24th to all. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 06/24/13 14:41, Ryan - Lists wrote: > > Does anyone on list have experience with the APC AP7920 switched rack > PDU, or any of the horizontal rack mountables with management? We're > looking at these for our remote sites. > > > > Sent from my iPhone > > > > On Jun 24, 2013, at 6:10 AM, M?ns Nilsson > wrote: > > > >> Subject: Re: PDU recommendations Date: Sun, Jun 23, 2013 at 09:32:00PM > -0400 Quoting shawn wilson (ag4ve.us at gmail.com): > >>> So, that's not a very good endorsement :) > >>> > >>> Idk why you'd use a fuse in a PDU. > >> MCB units age. Especially with vibration. A 10A MCB becomes a 9A MCB > after some miles. > >> > >> Fuses don't. > >> > >> MCB units are good at protecting people since they trip quickly and > aggressively. > >> > >> Fuses tend to linger before blowing, and thus are comparatively bad at > protecting > >> people (longer shock) but better at protecting infrastructure (surge > >> and switch-on-transient resistance). > >> > >> -- > >> M?ns Nilsson primary/secondary/besserwisser/machina > >> MN-1334-RIPE +46 705 989668 > >> There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS > >> in a $200,000 MALIBU BEACH HOUSE!! > > > > > > > From rlambert.lists at gmail.com Mon Jun 24 19:21:26 2013 From: rlambert.lists at gmail.com (Ryan - Lists) Date: Mon, 24 Jun 2013 15:21:26 -0400 Subject: PDU recommendations In-Reply-To: <51C89785.6070807@pubnix.net> References: <04a201ce7060$1d768140$586383c0$@gmail.com> <46c24a43-6bd8-44d7-8d2b-d10b47bb105d@email.android.com> <51C7998B.50500@prgmr.com> <20130624101008.GA9807@besserwisser.org> <601172DB-AB2D-456C-B929-8EE751551F85@gmail.com> <51C89785.6070807@pubnix.net> Message-ID: <4404D3D3-8D73-4249-8177-D4EFA3CF29A1@gmail.com> Oh, absolutely. These would be secured on a separate, private network with very specific access controls. These remote sites are more "branch" than data center. Looking at a very limited amount of equipment (1-2 open telco racks/site). Sent from my iPhone On Jun 24, 2013, at 3:01 PM, Alain Hebert wrote: > Hi, > > Yes. > > They are good. > > Nothing I would deploy in a large data center but for a few racks > they are perfect. > > Beware that they are not built to be connected straight to the > internet =D. > > The management module can reset depending on packet payload and > overall traffic. They should always be behind some sort of firewall > with rules limiting its access. > > PS: Ours are a few years old, I'm sure APC added some sort of > security since then, you may want to look 'em up. > > Happy 24th to all. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 06/24/13 14:41, Ryan - Lists wrote: >> Does anyone on list have experience with the APC AP7920 switched rack PDU, or any of the horizontal rack mountables with management? We're looking at these for our remote sites. >> >> Sent from my iPhone >> >> On Jun 24, 2013, at 6:10 AM, M?ns Nilsson wrote: >> >>> Subject: Re: PDU recommendations Date: Sun, Jun 23, 2013 at 09:32:00PM -0400 Quoting shawn wilson (ag4ve.us at gmail.com): >>>> So, that's not a very good endorsement :) >>>> >>>> Idk why you'd use a fuse in a PDU. >>> MCB units age. Especially with vibration. A 10A MCB becomes a 9A MCB after some miles. >>> >>> Fuses don't. >>> >>> MCB units are good at protecting people since they trip quickly and aggressively. >>> >>> Fuses tend to linger before blowing, and thus are comparatively bad at protecting >>> people (longer shock) but better at protecting infrastructure (surge >>> and switch-on-transient resistance). >>> >>> -- >>> M?ns Nilsson primary/secondary/besserwisser/machina >>> MN-1334-RIPE +46 705 989668 >>> There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS >>> in a $200,000 MALIBU BEACH HOUSE!! > > From surfer at mauigateway.com Mon Jun 24 19:55:56 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 24 Jun 2013 12:55:56 -0700 Subject: Security over SONET/SDH Message-ID: <20130624125556.D485E358@m0005296.ppops.net> ----- william.allen.simpson wrote: ----- And at $189,950 MSRP, obviously every ISP is dashing out the door for a pair for each and every long haul fiber link. ;-) ---------------------------------------- It's the same as buying, say, .nanog... >;-) --- gdt at gdt.id.au wrote: From: Glen Turner On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: > What security protocols are folks using to protect SONET/SDH? > At what speeds? "Excuse me NSA, can I have export approval for one KG-530 SDH encryptor?" What are the odds :-) And how would we know that the "export model" isn't simply providing a more convenient backdoor for the NSA? -------------------------------------------------- That's why I'm trying to follow up on the original question. Is there something similar the global public can use to secure their connections that is not government designed. This is even more important on microwave shots when security is desired. scott From joelja at bogus.com Mon Jun 24 20:04:11 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 24 Jun 2013 13:04:11 -0700 Subject: Security over SONET/SDH In-Reply-To: <20130624125556.D485E358@m0005296.ppops.net> References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: <51C8A63B.3010308@bogus.com> On 6/24/13 12:55 PM, Scott Weeks wrote: > > ----- william.allen.simpson wrote: ----- > And at $189,950 MSRP, obviously every ISP is dashing out the door > for a pair for each and every long haul fiber link. ;-) > ---------------------------------------- > > It's the same as buying, say, .nanog... >;-) > > > > > --- gdt at gdt.id.au wrote: > From: Glen Turner > On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: > >> What security protocols are folks using to protect SONET/SDH? >> At what speeds? > "Excuse me NSA, can I have export approval for one KG-530 SDH > encryptor?" What are the odds :-) > > And how would we know that the "export model" isn't simply > providing a more convenient backdoor for the NSA? > -------------------------------------------------- > > That's why I'm trying to follow up on the original question. Is > there something similar the global public can use to secure their > connections that is not government designed. This is even more > important on microwave shots when security is desired. plenty of standardized RF link-layers support strong encryption. > scott > > > > From jfbeam at gmail.com Mon Jun 24 20:09:05 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 24 Jun 2013 16:09:05 -0400 Subject: PDU recommendations In-Reply-To: References: Message-ID: On Sun, 23 Jun 2013 11:37:43 -0400, shawn wilson wrote: > However, I figured I'd see if there was a better brand / > specific model recommendations for quality or bang / buck? On Sun, 23 Jun 2013 12:02:27 -0400, Michael Loftis wrote: > (knock on wood) nothing in the > last 6-7 years has caused an outage. APC's are what I've grown to love... mostly because they're cheap and plentiful (eBay!) The only issue I've had with them is "flash corruption"; sometimes they have to be reprogrammed after a power outage. I'm using metered PDUs so it never effects the servers. But I also have a set of ServerTech dual-feed units. The full monty of DC features. (in fact, what a number of colo providers use.) I've not used them in years, 'tho -- lack of facilities to power them. (the electrician got a little happy cutting out old wiring in the current office and killed the two existing L6-30 drops. everything else is L21-20.) From surfer at mauigateway.com Mon Jun 24 20:19:03 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 24 Jun 2013 13:19:03 -0700 Subject: Security over SONET/SDH Message-ID: <20130624131903.D485E06D@m0005296.ppops.net> ------------ joelja at bogus.com wrote: ------------ From: joel jaeggli > That's why I'm trying to follow up on the original question. Is > there something similar the global public can use to secure their > connections that is not government designed. This is even more > important on microwave shots when security is desired. :: plenty of standardized RF link-layers support strong encryption. ---------------------------------------------------- Ah, thanks. That comment gave me the the search terms I needed, but I keep seeing sentences like this "Due to the encryption employed in these products, they are export controlled items and are regulated by the Bureau of Industry and Security (BIS) of the U.S. Department of Commerce. They may not be exported or shipped for re-export to restricted countries..." wheee! :-) scott From mark at viviotech.net Mon Jun 24 20:28:18 2013 From: mark at viviotech.net (Mark Keymer) Date: Mon, 24 Jun 2013 13:28:18 -0700 Subject: PDU recommendations In-Reply-To: References: Message-ID: <51C8ABE2.2040901@viviotech.net> I was wondering if anyone had experience with Geist's outlet monitoring product? I recently started using there basic PDU's and so far so good. But am wondering if anyone has feed back on Geist's outlet monitoring product. Mark Keymer From jerome at ceriz.fr Mon Jun 24 20:54:19 2013 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Mon, 24 Jun 2013 22:54:19 +0200 Subject: /25's prefixes announced into global routing table? In-Reply-To: <20130624192959.0a0c844f@tux.DEF.witbe.net> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130624192959.0a0c844f@tux.DEF.witbe.net> Message-ID: <51C8B1FB.8070204@ceriz.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 24/06/2013 19:29, Paul Rolland (???????) a ?crit : > Well, /25 are already in the routing table. I can even find a few > /26 !! So did I : http://lg.ring.nlnog.net/adv/lg02+lg01/ipv4?q=where%20net.len=26 But guess what ? They didn't stop there ! http://lg.ring.nlnog.net/adv/lg02+lg01/ipv4?q=where%20net.len=27 Want some more ? Hey, take some /28 ! http://lg.ring.nlnog.net/adv/lg02+lg01/ipv4?q=where%20net.len=28 And the list goes on... Up to /32 !! http://lg.ring.nlnog.net/adv/lg02+lg01/ipv4?q=where%20net.len=32 Guess you could actually multi-home a /32 now... - -- J?r?me Nicolle +33 6 19 31 27 14 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHIsfsACgkQbt+nwQamihvQ8gCdFBEmNiK6XJvLy770bFG/nPa0 IwYAn3cWI4rul5eNvW2t944vOgkLhof1 =NCMg -----END PGP SIGNATURE----- From jamie at photon.com Mon Jun 24 21:37:49 2013 From: jamie at photon.com (Jamie Bowden) Date: Mon, 24 Jun 2013 21:37:49 +0000 Subject: Security over SONET/SDH In-Reply-To: <20130624131903.D485E06D@m0005296.ppops.net> References: <20130624131903.D485E06D@m0005296.ppops.net> Message-ID: <465966A5F5B867419F604CD3E604C1E54D5C9DA9@PRA-DCA-MAIL.pra.ray.com> > -----Original Message----- > From: Scott Weeks [mailto:surfer at mauigateway.com] > ------------ joelja at bogus.com wrote: ------------ > From: joel jaeggli > > > That's why I'm trying to follow up on the original question. Is > > there something similar the global public can use to secure their > > connections that is not government designed. This is even more > > important on microwave shots when security is desired. > > :: plenty of standardized RF link-layers support strong encryption. > ---------------------------------------------------- > > > Ah, thanks. That comment gave me the the search terms I needed, > but I keep seeing sentences like this "Due to the encryption > employed in these products, they are export controlled items and > are regulated by the Bureau of Industry and Security (BIS) of the > U.S. Department of Commerce. They may not be exported or shipped > for re-export to restricted countries..." wheee! :-) Actually, you CAN do that, but you have to apply for ITAR exceptions. EXIM is complex and you really want a good legal team who are familiar with it hand holding you through it (and on extended retainer going forward...). Jamie From gary.buhrmaster at gmail.com Mon Jun 24 22:14:19 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 24 Jun 2013 22:14:19 +0000 Subject: Security over SONET/SDH In-Reply-To: <465966A5F5B867419F604CD3E604C1E54D5C9DA9@PRA-DCA-MAIL.pra.ray.com> References: <20130624131903.D485E06D@m0005296.ppops.net> <465966A5F5B867419F604CD3E604C1E54D5C9DA9@PRA-DCA-MAIL.pra.ray.com> Message-ID: On Mon, Jun 24, 2013 at 9:37 PM, Jamie Bowden wrote: .... > Actually, you CAN do that, but you have to apply for ITAR exceptions. EXIM is complex and you really want a good legal team who are familiar with it hand holding you through it (and on extended retainer going forward...). We used to joke that our export control officer was the "designated felon" (in the case that the process/decision was wrong, that person was the one going to go to prison (and note the US Govt takes ITAR controls very very seriously; do not guess, do not even think about guessing; do not even think that the words in the regs mean what you think they mean)). Gary From mikea at mikea.ath.cx Mon Jun 24 23:17:06 2013 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 24 Jun 2013 18:17:06 -0500 Subject: Security over SONET/SDH In-Reply-To: References: <20130624131903.D485E06D@m0005296.ppops.net> <465966A5F5B867419F604CD3E604C1E54D5C9DA9@PRA-DCA-MAIL.pra.ray.com> Message-ID: <20130624231706.GC46025@mikea.ath.cx> On Mon, Jun 24, 2013 at 10:14:19PM +0000, Gary Buhrmaster wrote: > On Mon, Jun 24, 2013 at 9:37 PM, Jamie Bowden wrote: > .... > > Actually, you CAN do that, but you have to apply for ITAR exceptions. EXIM is complex and you really want a good legal team who are familiar with it hand holding you through it (and on extended retainer going forward...). > > We used to joke that our export control officer was the "designated felon" > (in the case that the process/decision was wrong, that person was the > one going to go to prison (and note the US Govt takes ITAR controls very > very seriously; do not guess, do not even think about guessing; do not > even think that the words in the regs mean what you think they mean)). This is especially true in the case of even civilian crypto gear. Have lawyer(s) with experience in this stuff to bird-dog everything you do. It may seem like a lot of money, until you look at the fines and jail time you may wind up with if you drop a stitch somewhere. Then it all becomes quite reasonable. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From dedelman at iname.com Tue Jun 25 00:49:51 2013 From: dedelman at iname.com (David Edelman) Date: Mon, 24 Jun 2013 20:49:51 -0400 Subject: IANA Reference to hopopt as a protocol Message-ID: <02e901ce713d$e6ec6980$b4c53c80$@iname.com> Does anyone have an explanation for the IPv6 hopopt appearing as protocol value 0 in http://www.iana.org/assignments/protocol-numbers? --Dave From tore at fud.no Tue Jun 25 00:56:53 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 25 Jun 2013 02:56:53 +0200 Subject: IANA Reference to hopopt as a protocol In-Reply-To: <02e901ce713d$e6ec6980$b4c53c80$@iname.com> References: <02e901ce713d$e6ec6980$b4c53c80$@iname.com> Message-ID: <51C8EAD5.4010409@fud.no> * David Edelman > Does anyone have an explanation for the IPv6 hopopt appearing as protocol > value 0 in http://www.iana.org/assignments/protocol-numbers? It's defined in RFC 2460, section 4.3. Which is linked to from the reference column of the page you linked to... Tore From joelja at bogus.com Tue Jun 25 02:25:52 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 24 Jun 2013 19:25:52 -0700 Subject: Security over SONET/SDH In-Reply-To: <20130624131903.D485E06D@m0005296.ppops.net> References: <20130624131903.D485E06D@m0005296.ppops.net> Message-ID: <51C8FFB0.1010805@bogus.com> On 6/24/13 1:19 PM, Scott Weeks wrote: > > ------------ joelja at bogus.com wrote: ------------ > From: joel jaeggli > >> That's why I'm trying to follow up on the original question. Is >> there something similar the global public can use to secure their >> connections that is not government designed. This is even more >> important on microwave shots when security is desired. > :: plenty of standardized RF link-layers support strong encryption. > ---------------------------------------------------- > > > Ah, thanks. That comment gave me the the search terms I needed, > but I keep seeing sentences like this "Due to the encryption > employed in these products, they are export controlled items and > are regulated by the Bureau of Industry and Security (BIS) of the > U.S. Department of Commerce. They may not be exported or shipped > for re-export to restricted countries..." wheee! :-) Yes, however note that the actual number of embargoed countries at this point is pretty small, and that if you are in a(n) (US) embargoed country and so inclined you can likely buy such products manufactured in China by Chinese companies. Securing the link layer however is not a replacement for an end to end solution so just because it's protecting the air interface(s) doesn't really mean somebody not looking at the traffic elsewhere. > scott > From michael at winkstreaming.com Tue Jun 25 02:32:21 2013 From: michael at winkstreaming.com (Michael McConnell) Date: Mon, 24 Jun 2013 20:32:21 -0600 Subject: /25's prefixes announced into global routing table? In-Reply-To: <66F47611-8350-4A94-8FC9-1C73639CBDCC@ianai.net> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130624192959.0a0c844f@tux.DEF.witbe.net> <66F47611-8350-4A94-8FC9-1C73639CBDCC@ianai.net> Message-ID: How do I convince my peers to accept /25's ?? :D -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com On Jun 24, 2013, at 12:53 PM, Patrick W. Gilmore wrote: > On Jun 24, 2013, at 13:29 , Paul Rolland (???????) wrote: >> On Fri, 21 Jun 2013 13:56:02 -0600 Michael McConnell wrote: > >>> As the IPv4 space get smaller and smaller, does anyone think we'll see a >>> time when /25's will be accepted for global BGP prefix announcement. The >>> current smallest size is a /24 and generally ok for most people, but the >>> crunch gets tighter, routers continue to have more and more ram will it >>> always be /24 the smallest size? >> >> Well, /25 are already in the routing table. I can even find a few /26 !! >> >> rtr-01.PAR#sh ip b | i /26 >> *>i193.41.227.128/26 >> *>i193.41.227.192/26 >> *>i194.149.243.64/26 > > The question was when will we see /25s in the GLOBAL routing table. Despite the very un-well defined definition for "global routing table", I'm going to assuming something similar to the DFZ, or the set of prefixes which is seen in all (most of?) the transit-free networks[*]. > > Given that definition, there are exactly zero /25s in the GRT (DFZ). And unlikely to be for a while. Whether "a while" is "next 12 months" or "several years" is something I am very specifically choosing not to answer. > > -- > TTFN, > patrick > > [*] Don't you hate the term "tier one" these days? It doesn't mean what it used to mean (i.e. _settlement free_ peering with all other tier one networks). And given that there are non-transit-free networks with more [traffic|revenue|customers|$WHATEVER] than some transit free networks, I prefer to not use the term. > From morrowc.lists at gmail.com Tue Jun 25 02:59:02 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Jun 2013 22:59:02 -0400 Subject: Security over SONET/SDH In-Reply-To: <51C8FFB0.1010805@bogus.com> References: <20130624131903.D485E06D@m0005296.ppops.net> <51C8FFB0.1010805@bogus.com> Message-ID: On Mon, Jun 24, 2013 at 10:25 PM, joel jaeggli wrote: > Securing the link layer however is not a replacement for an end to end > solution so just because it's protecting the air interface(s) doesn't really > mean somebody not looking at the traffic elsewhere. it's fair to say, I think, that if you want to say something on the network it's best that you consider: 1) is the communication something private between you and another party(s) 2) is the communication going to be seen by other than you + the-right-other-party(s) and probably assume 2 is always going to be the case... So, if 1) is true then make some way to keep it private: ssl + checking certs 'properly' (where is dane?) gpg + good key material security private-key/shared-key - don't do this, everyone screws this up. -chris From tagno25 at gmail.com Tue Jun 25 04:19:52 2013 From: tagno25 at gmail.com (Philip Dorr) Date: Mon, 24 Jun 2013 23:19:52 -0500 Subject: Security over SONET/SDH In-Reply-To: References: <20130624131903.D485E06D@m0005296.ppops.net> <51C8FFB0.1010805@bogus.com> Message-ID: On Mon, Jun 24, 2013 at 9:59 PM, Christopher Morrow wrote: > it's fair to say, I think, that if you want to say something on the > network it's best that you consider: > 1) is the communication something private between you and another party(s) > 2) is the communication going to be seen by other than you + > the-right-other-party(s) > > and probably assume 2 is always going to be the case... So, if 1) is > true then make some way to keep it private: > ssl + checking certs 'properly' (where is dane?) > gpg + good key material security > private-key/shared-key - don't do this, everyone screws this up. SSH + SSHFP + DNSSEC does public/private key pretty well From surfer at mauigateway.com Tue Jun 25 07:55:04 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 25 Jun 2013 00:55:04 -0700 Subject: Security over SONET/SDH Message-ID: <20130625005504.D485B6B0@m0005296.ppops.net> I hope I've gotten the quotations correct... --- joelja at bogus.com wrote: From: joel jaeggli On 6/24/13 1:19 PM, Scott Weeks wrote: > ------------ joelja at bogus.com wrote: ------------ >> That's why I'm trying to follow up on the original question. Is >> there something similar the global public can use to secure their >> connections that is not government designed. This is even more >> important on microwave shots when security is desired. > :: plenty of standardized RF link-layers support strong encryption. > ---------------------------------------------------- > > Ah, thanks. That comment gave me the the search terms I needed, > but I keep seeing sentences like this "Due to the encryption > employed in these products, they are export controlled items and > are regulated by the Bureau of Industry and Security (BIS) of the > U.S. Department of Commerce. They may not be exported or shipped > for re-export to restricted countries..." wheee! :-) Yes, however note that the actual number of embargoed countries at this point is pretty small, and that if you are in a(n) (US) embargoed country and so inclined you can likely buy such products manufactured in China by Chinese companies. Securing the link layer however is not a replacement for an end to end solution so just because it's protecting the air interface(s) doesn't really mean somebody not looking at the traffic elsewhere. -------------------------------------------------- Yeah, but I was just thinking through what the original question asked. After reading his emails over the years, I am assuming he meant in addition to everything else "What security protocols are folks using to protect SONET/SDH? At what speeds?" I now see it quickly devolves into what various governments will allow its citizenry to do on the internet. :-( scott From mysidia at gmail.com Tue Jun 25 08:48:26 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 25 Jun 2013 03:48:26 -0500 Subject: /25's prefixes announced into global routing table? In-Reply-To: References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130624192959.0a0c844f@tux.DEF.witbe.net> <66F47611-8350-4A94-8FC9-1C73639CBDCC@ianai.net> Message-ID: On 6/24/13, Michael McConnell wrote: > How do I convince my peers to accept /25's ?? :D 1. Ask. As in support requests; report as connectivity defect that your /25s are not propagated. 2. Contract negotiation. 3. More cash. 4. Replace peers/upstreams with competing providers as necessary, until you find one where one or more of the above will suffice. > -- > Michael McConnell -- -JH From arturo.servin at gmail.com Tue Jun 25 09:43:11 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 25 Jun 2013 10:43:11 +0100 Subject: /25's prefixes announced into global routing table? In-Reply-To: <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130621201407.GA4370@puck.nether.net> <51C4F9DB.6010305@necom830.hpcl.titech.ac.jp> <5FE82F90-900F-4CAA-8704-70E30D7E50D2@delong.com> <51C533F5.1080209@monmotha.net> <25F67B54-EE13-4959-8C3A-1C8AC2D19D50@istaff.org> Message-ID: <51C9662F.9000106@gmail.com> And this presentation by Geoff Huston: http://iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf Regards, as On 6/22/13 11:48 AM, John Curran wrote: > On Jun 22, 2013, at 1:45 AM, Owen DeLong wrote: > >> Yes? It will probably settle out somewhere around 100-125K routes. > Owen - > > Can you elaborate some on this estimate? (i.e. what approximations > and/or assumptions are you using to reach this number?) > > Thanks! > /John > From gdt at gdt.id.au Tue Jun 25 10:33:19 2013 From: gdt at gdt.id.au (Glen Turner) Date: Tue, 25 Jun 2013 20:03:19 +0930 (CST) Subject: Security over SONET/SDH In-Reply-To: <20130625005504.D485B6B0@m0005296.ppops.net> References: <20130625005504.D485B6B0@m0005296.ppops.net> Message-ID: Link encryption isn't to protect the contents of the user's communication. There is no reason for users to trust their ISP more than a national institution full of people vetted to the highest level. What link encryption gets the user is protection from traffic analysis from parties other than the ISP. You've seen in the NSA documents how highly they regard this traffic analysis. I'd fully expect the NSA to collect it by other means. -glen -- Glen Turner From gall at switch.ch Tue Jun 25 10:33:52 2013 From: gall at switch.ch (gall at switch.ch) Date: Tue, 25 Jun 2013 12:33:52 +0200 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] Message-ID: <20937.29200.175222.251485@switch.ch> I'm forwarding this heads-up for the shutdown of the well-known NTP server swisstime.ethz.ch on behalf of the ETH Zurich. -- Alex SWITCH NOC AS559 -------------- next part -------------- An embedded message was scrubbed... From: "Wittmann Armin" Subject: Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013 Date: Tue, 25 Jun 2013 07:12:54 +0000 Size: 3453 URL: From sam at wwcandt.com Tue Jun 25 11:56:38 2013 From: sam at wwcandt.com (sam at wwcandt.com) Date: Tue, 25 Jun 2013 07:56:38 -0400 (EDT) Subject: Security over SONET/SDH In-Reply-To: References: <20130625005504.D485B6B0@m0005296.ppops.net> Message-ID: <44909.130.76.96.146.1372161398.squirrel@www.systemetrixs.com> Even if your crypto is good enough end to end CALEA will require you to hand over the keys and/or put in a backdoor if you have a US nexus. >From Wikipedia http://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act USA telecommunications providers must install new hardware or software, as well as modify old equipment, so that it doesn't interfere with the ability of a law enforcement agency (LEA) to perform real-time surveillance of any telephone or Internet traffic. Modern voice switches now have this capability built in, yet Internet equipment almost always requires some kind of intelligent Deep Packet Inspection probe to get the job done. In both cases, the intercept-function must single out a subscriber named in a warrant for intercept and then immediately send some (headers-only) or all (full content) of the intercepted data to an LEA. The LEA will then process this data with analysis software that is specialized towards criminal investigations. All traditional voice switches on the U.S. market today have the CALEA intercept feature built in. The IP-based "soft switches" typically do not contain a built-in CALEA intercept feature; and other IP-transport elements (routers, switches, access multiplexers) almost always delegate the CALEA function to elements dedicated to inspecting and intercepting traffic. In such cases, hardware taps or switch/router mirror-ports are employed to deliver copies of all of a network's data to dedicated IP probes. Probes can either send directly to the LEA according to the industry standard delivery formats (c.f. ATIS T1.IAS, T1.678v2, et al.); or they can deliver to an intermediate element called a mediation device, where the mediation device does the formatting and communication of the data to the LEA. A probe that can send the correctly formatted data to the LEA is called a "self-contained" probe. In order to be compliant, IP-based service providers (Broadband, Cable, VoIP) must choose either a self-contained probe (such as made by IPFabrics), or a "dumb" probe component plus a mediation device (such as made by Verint, or they must implement the delivery of correctly formatted for a named subscriber's data on their own. > > Link encryption isn't to protect the contents of the user's > communication. There is no reason for users to trust their > ISP more than a national institution full of people vetted > to the highest level. > > What link encryption gets the user is protection from traffic > analysis from parties other than the ISP. > > You've seen in the NSA documents how highly they regard this > traffic analysis. I'd fully expect the NSA to collect it by > other means. > > -glen > > -- > Glen Turner > From philfagan at gmail.com Tue Jun 25 12:38:23 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 25 Jun 2013 06:38:23 -0600 Subject: Security over SONET/SDH In-Reply-To: <20130624125556.D485E358@m0005296.ppops.net> References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: Are these private links or customer links? Why encrypt at that layer? I'm looking for the niche usecase. On Jun 24, 2013 1:57 PM, "Scott Weeks" wrote: > > > ----- william.allen.simpson wrote: ----- > And at $189,950 MSRP, obviously every ISP is dashing out the door > for a pair for each and every long haul fiber link. ;-) > ---------------------------------------- > > It's the same as buying, say, .nanog... >;-) > > > > > --- gdt at gdt.id.au wrote: > From: Glen Turner > On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: > > > What security protocols are folks using to protect SONET/SDH? > > At what speeds? > > "Excuse me NSA, can I have export approval for one KG-530 SDH > encryptor?" What are the odds :-) > > And how would we know that the "export model" isn't simply > providing a more convenient backdoor for the NSA? > -------------------------------------------------- > > That's why I'm trying to follow up on the original question. Is > there something similar the global public can use to secure their > connections that is not government designed. This is even more > important on microwave shots when security is desired. > > scott > > > > > From straterra at fuhell.com Tue Jun 25 12:51:42 2013 From: straterra at fuhell.com (Thomas York) Date: Tue, 25 Jun 2013 08:51:42 -0400 Subject: 86th Street TWTC outage Message-ID: Just in case anyone has equipment in the 86th Street TWTC Colo, both of their AC units are dead and the fire department is here. I'll try to update as soon as I know something. From bicknell at ufp.org Tue Jun 25 13:15:14 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 25 Jun 2013 08:15:14 -0500 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: On Jun 25, 2013, at 7:38 AM, Phil Fagan wrote: > Are these private links or customer links? Why encrypt at that layer? I'm > looking for the niche usecase. I was reading an article about the UK tapping undersea cables (http://www.guardian.co.uk/uk/2013/jun/21/gchq-cables-secret-world-communications-nsa) and thought back to my time at AboveNet and dealing with undersea cables. My initial reaction was doubt, there are thousands of users on the cables, ISP's and non-ISP's, and working with all of them to split off the data would be insanely complicated. Then I read some more articles that included quotes like: Interceptors have been placed on around 200 fibre optic cables where they come ashore. This appears to have been done with the secret co-operation (http://www.wired.co.uk/news/archive/2013-06/24/gchq-tempora-101) Which made me immediately realize it would be far simpler to strong arm the cable operators to split off all channels before connecting them to the customer. If done early enough they could all be split off as 10G channels, even if they are later muxed down to lower speeds reducing the number of handoffs to the spy apparatus. Very few ISP's ever go to the landing stations, typically the cable operators provide cross connects to a small number of backhaul providers. That makes a much smaller number of people who might ever notice the splitters and taps, and makes it totally transparent to the ISP. But the big question is, does this happen? I'm sure some people on this list have been to cable landing stations and looked around. I'm not sure if any of them will comment. If it does, it answers Phil's question. An ISP encrypting such a link end to end foils the spy apparatus for their customers, protecting their privacy. The US for example has laws that provide greater authority to tap "foreign" communications than domestic, so even though the domestic links may not be encrypted that may still pose a decent roadblock to siphoning off traffic. Who's going to be the first ISP that advertises they encrypt their links that leave the country? :) -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From symack at gmail.com Tue Jun 25 14:16:56 2013 From: symack at gmail.com (Nick Khamis) Date: Tue, 25 Jun 2013 10:16:56 -0400 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: Screw the pyramids. Look at that building!!!! Yeah we though about this.... and currently in the process of training pigeons to carry messages. Will keep everyone posted. :) Nick. From philfagan at gmail.com Tue Jun 25 14:19:25 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 25 Jun 2013 08:19:25 -0600 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: Transnational seems like a good place to start. It seems like a tough space to break into ( no PUN intended). On Tue, Jun 25, 2013 at 7:15 AM, Leo Bicknell wrote: > > On Jun 25, 2013, at 7:38 AM, Phil Fagan wrote: > > > Are these private links or customer links? Why encrypt at that layer? I'm > > looking for the niche usecase. > > I was reading an article about the UK tapping undersea cables ( > http://www.guardian.co.uk/uk/2013/jun/21/gchq-cables-secret-world-communications-nsa) > and thought back to my time at AboveNet and dealing with undersea cables. > My initial reaction was doubt, there are thousands of users on the cables, > ISP's and non-ISP's, and working with all of them to split off the data > would be insanely complicated. Then I read some more articles that > included quotes like: > > Interceptors have been placed on around 200 fibre optic cables where > they come ashore. This appears to have been done with the secret > co-operation ( > http://www.wired.co.uk/news/archive/2013-06/24/gchq-tempora-101) > > Which made me immediately realize it would be far simpler to strong arm > the cable operators to split off all channels before connecting them to the > customer. If done early enough they could all be split off as 10G > channels, even if they are later muxed down to lower speeds reducing the > number of handoffs to the spy apparatus. > > Very few ISP's ever go to the landing stations, typically the cable > operators provide cross connects to a small number of backhaul providers. > That makes a much smaller number of people who might ever notice the > splitters and taps, and makes it totally transparent to the ISP. But the > big question is, does this happen? I'm sure some people on this list have > been to cable landing stations and looked around. I'm not sure if any of > them will comment. > > If it does, it answers Phil's question. An ISP encrypting such a link end > to end foils the spy apparatus for their customers, protecting their > privacy. The US for example has laws that provide greater authority to tap > "foreign" communications than domestic, so even though the domestic links > may not be encrypted that may still pose a decent roadblock to siphoning > off traffic. > > Who's going to be the first ISP that advertises they encrypt their links > that leave the country? :) > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From rdobbins at arbor.net Tue Jun 25 14:23:43 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 25 Jun 2013 14:23:43 +0000 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> On Jun 25, 2013, at 8:15 PM, Leo Bicknell wrote: > Which made me immediately realize it would be far simpler to strong arm the cable operators to split off all channels before connecting them to the customer. It's potentially a lot simpler than that: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From morrowc.lists at gmail.com Tue Jun 25 14:38:30 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Jun 2013 10:38:30 -0400 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> References: <20130624125556.D485E358@m0005296.ppops.net> <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> Message-ID: On Tue, Jun 25, 2013 at 10:23 AM, Dobbins, Roland wrote: > > On Jun 25, 2013, at 8:15 PM, Leo Bicknell wrote: > >> Which made me immediately realize it would be far simpler to strong arm the cable operators to split off all channels before connecting them to the customer. > > It's potentially a lot simpler than that: > > this involved, I think, just intuiting signals from the nearfield effects of the cable, no? 'drop a large sensor ontop-of/next-to the cable, win!' > this I thought included the capabilities to drag the fiber/line into the hull for 'work' to be done... I'd note that introducing signal loss on the longhaul fiber seems 'risky', you'd have to know (and this isn't hard I bet) the tolerances of the link in question and have a way to stay inside those tolerances and not introduce new splice-points/junctions/etc and be careful for the undersea cable power (electric) requirements as well. fun stuff! and yea, why not just work with the landindstation operators to use the existing monitoring ports they use? (or get a copy of the monitor ports) -chris From mansaxel at besserwisser.org Tue Jun 25 14:53:32 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 25 Jun 2013 16:53:32 +0200 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> Message-ID: <20130625145332.GG9807@besserwisser.org> Subject: Re: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] Date: Tue, Jun 25, 2013 at 10:38:30AM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): > > It's potentially a lot simpler than that: > > > > > > this involved, I think, just intuiting signals from the nearfield > effects of the cable, no? 'drop a large sensor ontop-of/next-to the > cable, win!' IVY BELLS (USN is / was an ALL-CAPS org, right?) was a copper era project, and it did use EMI tapping (TEMPEST) to get to the traffic without tampering with the cable. Having gotten that cleared, I'd argue that if you're on speaking terms with the cable operator, it is much easier to use a full-spectrum monitor port on the WDM system. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From rdobbins at arbor.net Tue Jun 25 14:55:23 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 25 Jun 2013 14:55:23 +0000 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> Message-ID: <2E82A4DC-E126-4F0D-A774-F4C93F3B14D7@arbor.net> On Jun 25, 2013, at 9:38 PM, Christopher Morrow wrote: > this I thought included the capabilities to drag the fiber/line into the hull for 'work' to be done... I'd note that introducing signal > loss on the longhaul fiber seems 'risky', you'd have to know (and this isn't hard I bet) the tolerances of the link in question and have a > way to stay inside those tolerances and not introduce new splice-points/junctions/etc and be careful for the undersea cable > power (electric) requirements as well. Kind of makes one think about the spate of high-profile submarine cable breaks over the past couple of years in a different light, doesn't it? ;> > and yea, why not just work with the landindstation operators to use the existing monitoring ports they use? (or get a copy of the monitor ports) Operational security in the original meaning of the term (i.e., what people don't know about, they can't talk to reporters from the Guardian about). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Jun 25 14:58:28 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 25 Jun 2013 14:58:28 +0000 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: <20130625145332.GG9807@besserwisser.org> References: <20130624125556.D485E358@m0005296.ppops.net> <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> <20130625145332.GG9807@besserwisser.org> Message-ID: <8E1C6C26-B5F8-44B2-98DA-609996D68E9A@arbor.net> On Jun 25, 2013, at 9:53 PM, M?ns Nilsson wrote: > IVY BELLS (USN is / was an ALL-CAPS org, right?) was a copper era project, and it did use EMI tapping (TEMPEST) to get to the traffic > without tampering with the cable. Fiber can be tapped, too, though it's not as easy as EMI. Heck, it can even be potentially 'pre-tapped' prior to deployment. > Having gotten that cleared, I'd argue that if you're on speaking terms with the cable operator, it is much easier to use a full-spectrum monitor port on the WDM system. The issue is that the cable operator may be on speaking terms with reporters at the Guardian. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From javier at kjsl.org Tue Jun 25 15:46:13 2013 From: javier at kjsl.org (Javier Henderson) Date: Tue, 25 Jun 2013 11:46:13 -0400 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: RFC 1149 addresses the practice of avian carriers. -jav On Tue, Jun 25, 2013 at 10:16 AM, Nick Khamis wrote: > Screw the pyramids. Look at that building!!!! Yeah we though about this.... > and currently in the process of training pigeons to carry > messages. Will keep everyone posted. :) > > Nick. > > > > From wbailey at satelliteintelligencegroup.com Tue Jun 25 16:09:15 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 25 Jun 2013 16:09:15 +0000 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> , Message-ID: Is there a realistic way to deal with dropped packets in that situation? I would think packet loss could get really messy.. ;) Sent from my Mobile Device. -------- Original message -------- From: Javier Henderson Date: 06/25/2013 8:47 AM (GMT-08:00) To: Nick Khamis Cc: NANOG Subject: Re: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] RFC 1149 addresses the practice of avian carriers. -jav On Tue, Jun 25, 2013 at 10:16 AM, Nick Khamis wrote: > Screw the pyramids. Look at that building!!!! Yeah we though about this.... > and currently in the process of training pigeons to carry > messages. Will keep everyone posted. :) > > Nick. > > > > From kamtha at ak-labs.net Tue Jun 25 16:10:04 2013 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Tue, 25 Jun 2013 12:10:04 -0400 Subject: content streaming providers? Message-ID: <20130625161004.GH75462@ak-labs.net> Hello, I was wondering if anyone could possibly recommend and/or share thier experience(s) with any online ondemand content streaming service, primarily for video.. Our objective is to provide content on the roku's and appletvs of the world. Any feedback is greatly appreciated. Cheers, Carlos. From alby.williams at verizon.com Tue Jun 25 14:52:37 2013 From: alby.williams at verizon.com (Anthony Williams) Date: Tue, 25 Jun 2013 10:52:37 -0400 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <20937.29200.175222.251485@switch.ch> References: <20937.29200.175222.251485@switch.ch> Message-ID: <51C9AEB5.60407@one.verizon.com> Alex: You should also get this posted to the NTP.ORG community. http://www.pool.ntp.org Also a Usenet posting (who still uses that, right?) to comp.protocols.time.ntp will also help get the word out. On 6/25/2013 6:33 AM, gall at switch.ch wrote: > I'm forwarding this heads-up for the shutdown of the well-known NTP > server swisstime.ethz.ch on behalf of the ETH Zurich. > -Alby From Valdis.Kletnieks at vt.edu Tue Jun 25 17:04:04 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Jun 2013 13:04:04 -0400 Subject: /25's prefixes announced into global routing table? In-Reply-To: Your message of "Mon, 24 Jun 2013 20:32:21 -0600." References: <8A50075E-018D-41C1-BDFD-61C3874EEDA9@winkstreaming.com> <20130624192959.0a0c844f@tux.DEF.witbe.net> <66F47611-8350-4A94-8FC9-1C73639CBDCC@ianai.net> Message-ID: <205527.1372179844@turing-police.cc.vt.edu> On Mon, 24 Jun 2013 20:32:21 -0600, Michael McConnell said: > How do I convince my peers to accept /25's ?? :D This will usually require either writing a check or baking a cake... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From hank at efes.iucc.ac.il Tue Jun 25 17:14:05 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 25 Jun 2013 20:14:05 +0300 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> <20130624125556.D485E358@m0005296.ppops.net> <9CCDA15C-8322-4323-8ABA-9A9362CE8004@arbor.net> Message-ID: <5.1.1.6.2.20130625200956.003ed668@efes.iucc.ac.il> At 10:38 25/06/2013 -0400, Christopher Morrow wrote: >this involved, I think, just intuiting signals from the nearfield >effects of the cable, no? 'drop a large sensor ontop-of/next-to the >cable, win!' > > > > >this I thought included the capabilities to drag the fiber/line into >the hull for 'work' to be done... I'd note that introducing signal >loss on the longhaul fiber seems 'risky', you'd have to know (and this >isn't hard I bet) the tolerances of the link in question and have a >way to stay inside those tolerances and not introduce new >splice-points/junctions/etc and be careful for the undersea cable >power (electric) requirements as well. > >fun stuff! Fun stuff indeed...sell to one org or the other: http://www.glimmerglass.com/solutions/submarine-cable-landing-stations/ http://www.glimmerglass.com/solutions/cyber-security-and-lawful-interception/ -Hank From me at staticsafe.ca Tue Jun 25 17:31:47 2013 From: me at staticsafe.ca (staticsafe) Date: Tue, 25 Jun 2013 13:31:47 -0400 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <51C9AEB5.60407@one.verizon.com> References: <20937.29200.175222.251485@switch.ch> <51C9AEB5.60407@one.verizon.com> Message-ID: <51C9D403.60008@staticsafe.ca> On Tue, Jun 25, 2013 at 10:52:37AM -0400, Anthony Williams wrote: > > Alex: > > You should also get this posted to the NTP.ORG community. > > http://www.pool.ntp.org > > > Also a Usenet posting (who still uses that, right?) to > comp.protocols.time.ntp will also help get the word out. Forwarded it to the ntp-pool list. -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. Please don't CC! I'm subscribed to whatever list I just posted on. From Valdis.Kletnieks at vt.edu Tue Jun 25 17:37:58 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Jun 2013 13:37:58 -0400 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: Your message of "Tue, 25 Jun 2013 12:33:52 +0200." <20937.29200.175222.251485@switch.ch> References: <20937.29200.175222.251485@switch.ch> Message-ID: <207234.1372181878@turing-police.cc.vt.edu> On Tue, 25 Jun 2013 12:33:52 +0200, gall at switch.ch said: > I'm forwarding this heads-up for the shutdown of the well-known NTP > server swisstime.ethz.ch on behalf of the ETH Zurich. I wonder how long it will take before anybody actually updates their config. I once pulled a stratum-2 out of the clocks.txt file - and was still seeing several hundred unique hosts per hour poking the IP address for time - like over a decade later. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From william.allen.simpson at gmail.com Tue Jun 25 18:02:23 2013 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 25 Jun 2013 14:02:23 -0400 Subject: Security over SONET/SDH In-Reply-To: <20130625005504.D485B6B0@m0005296.ppops.net> References: <20130625005504.D485B6B0@m0005296.ppops.net> Message-ID: <51C9DB2F.8050407@gmail.com> On 6/25/13 3:55 AM, Scott Weeks wrote: > Yeah, but I was just thinking through what the original question asked. > After reading his emails over the years, I am assuming he meant in > addition to everything else "What security protocols are folks using to > protect SONET/SDH? At what speeds?" > Correct. But the answer appears to be: none. Not Google. Not any public N/ISP. > I now see it quickly devolves into what various governments will allow > its citizenry to do on the internet. :-( > With a lot of dithering by folks who have no operational or security responsibilities at any providers. :-( From wbailey at satelliteintelligencegroup.com Tue Jun 25 18:20:19 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 25 Jun 2013 18:20:19 +0000 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: <5.1.1.6.2.20130625200956.003ed668@efes.iucc.ac.il> Message-ID: >From the site: Problem - federal integrator with a government customer needed to connect geographically dispersed antenna sites to a central pool of monitoring equipment. Our Solution - With Glimmerglass managing the reconfiguration of optical signals, the integrator was able to create an RF-over-fiber solution that performed better and cost less than traditional implementations. .. I would be *REALLY* interested in seeing how they did this. We've been doing this (it's called Fiber IFL) for a long time, but the range with nearly everything has been sub 40km for the most part. Getting geographically diverse sites all linked up via rf to fiber would be a nightmare unless you were planning on demodulating the signals and sending them via IP, which wouldn't surprise me. On 6/25/13 10:14 AM, "Hank Nussbacher" wrote: >At 10:38 25/06/2013 -0400, Christopher Morrow wrote: > >>this involved, I think, just intuiting signals from the nearfield >>effects of the cable, no? 'drop a large sensor ontop-of/next-to the >>cable, win!' >> >> > >> >>this I thought included the capabilities to drag the fiber/line into >>the hull for 'work' to be done... I'd note that introducing signal >>loss on the longhaul fiber seems 'risky', you'd have to know (and this >>isn't hard I bet) the tolerances of the link in question and have a >>way to stay inside those tolerances and not introduce new >>splice-points/junctions/etc and be careful for the undersea cable >>power (electric) requirements as well. >> >>fun stuff! > >Fun stuff indeed...sell to one org or the other: >http://www.glimmerglass.com/solutions/submarine-cable-landing-stations/ >http://www.glimmerglass.com/solutions/cyber-security-and-lawful-intercepti >on/ > >-Hank > > From symack at gmail.com Tue Jun 25 19:18:28 2013 From: symack at gmail.com (Nick Khamis) Date: Tue, 25 Jun 2013 15:18:28 -0400 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: On 6/25/13, Javier Henderson wrote: > RFC 1149 addresses the practice of avian carriers. > > -jav Jav, this one takes the trump!!! You sir are a man of few words! :) N. From mikea at mikea.ath.cx Tue Jun 25 19:22:25 2013 From: mikea at mikea.ath.cx (Mike A) Date: Tue, 25 Jun 2013 14:22:25 -0500 Subject: Security over SONET/SDH In-Reply-To: References: <20130624131903.D485E06D@m0005296.ppops.net> <51C8FFB0.1010805@bogus.com> Message-ID: <20130625192225.GA90104@mikea.ath.cx> On Mon, Jun 24, 2013 at 11:19:52PM -0500, Philip Dorr wrote: > On Mon, Jun 24, 2013 at 9:59 PM, Christopher Morrow > wrote: > > it's fair to say, I think, that if you want to say something on the > > network it's best that you consider: > > 1) is the communication something private between you and another party(s) > > 2) is the communication going to be seen by other than you + > > the-right-other-party(s) > > > > and probably assume 2 is always going to be the case... So, if 1) is > > true then make some way to keep it private: > > ssl + checking certs 'properly' (where is dane?) > > gpg + good key material security > > private-key/shared-key - don't do this, everyone screws this up. > > SSH + SSHFP + DNSSEC does public/private key pretty well If one or another of the TLAs hasn't solved, say, the BIGNUM_factoring problem. If they have, then elliptic curve crypto looks interesting. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From symack at gmail.com Tue Jun 25 19:24:50 2013 From: symack at gmail.com (Nick Khamis) Date: Tue, 25 Jun 2013 15:24:50 -0400 Subject: Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH] In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: On 6/25/13, Warren Bailey wrote: > Is there a realistic way to deal with dropped packets in that situation? I > would think packet loss could get really messy.. ;) > > As you know this is not such a problem for UDP streams however, we have not worked out all the bugs for services that run on TCP. Oh yeah it's messy!!! You know it brings a different set of challenges (i.e., PITA, Pamela Anderson). It's a tuff world out there guys.... We are however trying to conform to RFC standards as pointed out by Jev. You guys really need to look at this. It's easily implementable: http://tools.ietf.org/html/rfc1149 N. From morrowc.lists at gmail.com Tue Jun 25 19:35:16 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 25 Jun 2013 15:35:16 -0400 Subject: Security over SONET/SDH In-Reply-To: <51C9DB2F.8050407@gmail.com> References: <20130625005504.D485B6B0@m0005296.ppops.net> <51C9DB2F.8050407@gmail.com> Message-ID: On Tue, Jun 25, 2013 at 2:02 PM, William Allen Simpson wrote: > But the answer appears to be: none. Not Google. Not any public N/ISP. would they say if they had? From surfer at mauigateway.com Tue Jun 25 20:35:36 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 25 Jun 2013 13:35:36 -0700 Subject: Security over SONET/SDH Message-ID: <20130625133536.D4846B79@m0005296.ppops.net> --- morrowc.lists at gmail.com wrote: From: Christopher Morrow On Tue, Jun 25, 2013 at 2:02 PM, William Allen Simpson wrote: :: ...in addition to everything else "What security protocols :: are folks using to protect SONET/SDH? At what speeds?" : Correct. : But the answer appears to be: none. Not Google. Not any : public N/ISP. > would they say if they had? ------------------------------------------- Yes, especially in light of the current news regarding internet privacy. Could you imagine the advertising they'd be able to do to prospective customers? scott From sam at wwcandt.com Tue Jun 25 23:34:17 2013 From: sam at wwcandt.com (sam at wwcandt.com) Date: Tue, 25 Jun 2013 19:34:17 -0400 (EDT) Subject: Security over SONET/SDH In-Reply-To: <20130625133536.D4846B79@m0005296.ppops.net> References: <20130625133536.D4846B79@m0005296.ppops.net> Message-ID: <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> The sticky problem remains for any communications carrier, we are looking for a technical solution to a legal problem. I believe that if you encrypted your links sufficiently that it was impossible to siphon the wanted data from your upstream the response would be for the tapping to move down into your data center before the crypto. With CALEA requirements and the Patriot Act they could easily compel you to give them a span port prior to the crypto. Regardless of how well built our networks are internally and externally we still must obey a court order. Sam > > > --- morrowc.lists at gmail.com wrote: > From: Christopher Morrow > On Tue, Jun 25, 2013 at 2:02 PM, William Allen Simpson > wrote: > > :: ...in addition to everything else "What security protocols > :: are folks using to protect SONET/SDH? At what speeds?" > > : Correct. > > : But the answer appears to be: none. Not Google. Not any > : public N/ISP. > > >> would they say if they had? > ------------------------------------------- > > > Yes, especially in light of the current news regarding > internet privacy. Could you imagine the advertising > they'd be able to do to prospective customers? > > scott > From philfagan at gmail.com Tue Jun 25 23:00:08 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 25 Jun 2013 17:00:08 -0600 Subject: Security over SONET/SDH In-Reply-To: <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> References: <20130625133536.D4846B79@m0005296.ppops.net> <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> Message-ID: Since we're no longer trying to dodge the NSA....why would one want to encrypt transport? I think protected links are a great business model. L3VPN encryption? Whats the best offering? From LarrySheldon at cox.net Tue Jun 25 23:38:05 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 25 Jun 2013 18:38:05 -0500 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: References: <20937.29200.175222.251485@switch.ch> Message-ID: <51CA29DD.8010904@cox.net> On 6/25/2013 9:52 AM, Anthony Williams wrote: > Also a Usenet posting (who still uses that, right?) to > comp.protocols.time.ntp will also help get the word out. There is a fair amount of on-topic traffic of recent vintage on that froup. What is it about people that makes them free-load on services like NTP chimes and DNSBLS but refuse to stay in contact with(or at least contactable by) the providers when important stuff is pending? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From surfer at mauigateway.com Tue Jun 25 23:43:22 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 25 Jun 2013 16:43:22 -0700 Subject: Security over SONET/SDH Message-ID: <20130625164322.D4845600@m0005296.ppops.net> > --- morrowc.lists at gmail.com wrote: > From: Christopher Morrow > On Tue, Jun 25, 2013 at 2:02 PM, William Allen Simpson > wrote: > > :: ...in addition to everything else "What security protocols > :: are folks using to protect SONET/SDH? At what speeds?" > > : Correct. > > : But the answer appears to be: none. Not Google. Not any > : public N/ISP. > > >> would they say if they had? > ------------------------------------------- > > > Yes, especially in light of the current news regarding > internet privacy. Could you imagine the advertising > they'd be able to do to prospective customers? --- sam at wwcandt.com wrote: The sticky problem remains for any communications carrier, we are looking for a technical solution to a legal problem. I believe that if you encrypted your links sufficiently that it was impossible to siphon the wanted data from your upstream the response would be for the tapping to move down into your data center before the crypto. With CALEA requirements and the Patriot Act they could easily compel you to give them a span port prior to the crypto. Regardless of how well built our networks are internally and externally we still must obey a court order. ------------------------------------------------------------------ I'm speaking about blocking non-court ordered (in whatever country the circuits cross) sniffing of traffic in the middle by anyone. There is no legal problem there. They do not follow the laws in this country, or in others, and we need to protect ourselves. scott From bicknell at ufp.org Wed Jun 26 00:56:24 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 25 Jun 2013 19:56:24 -0500 Subject: Security over SONET/SDH In-Reply-To: <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> References: <20130625133536.D4846B79@m0005296.ppops.net> <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> Message-ID: <868DE324-E510-4E4D-81F7-9F105A7C8429@ufp.org> On Jun 25, 2013, at 6:34 PM, sam at wwcandt.com wrote: > I believe that if you encrypted your links sufficiently that it was > impossible to siphon the wanted data from your upstream the response would > be for the tapping to move down into your data center before the crypto. > > With CALEA requirements and the Patriot Act they could easily compel you > to give them a span port prior to the crypto. The value here isn't preventing from getting the data, as you point out there are multiple tools at their disposal, and they will likely compel data at some other point in the stack. The value here is increasing the visibility of the tapping, making more people aware of how much is going on. Forcing the tapping out of the shadows and into the light. For instance if my theory that some cables are being tapped at the landing station is correct, there are likely ISP's on this list right now that have transatlantic links /and do not know that they are being tapped/. If the links were encrypted and they had to serve the ISP directly to get the unencrypted data or make them stop encrypting, that ISP would know their data was being tapped. It also has the potential to shift the legal proceedings to other courts. The FISA court can approve tapping a foreign cable as it enters the country in near perfect, unchallengeable secrecy. If encryption moved that to be a regular federal warrant under CALEA there would be a few more avenues for challenging the order legally. People can't challenge what they don't know about. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From george.herbert at gmail.com Wed Jun 26 01:12:27 2013 From: george.herbert at gmail.com (George Herbert) Date: Tue, 25 Jun 2013 18:12:27 -0700 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <51CA29DD.8010904@cox.net> References: <20937.29200.175222.251485@switch.ch> <51CA29DD.8010904@cox.net> Message-ID: On Tue, Jun 25, 2013 at 4:38 PM, Larry Sheldon wrote: > > What is it about people that makes them free-load on services like NTP > chimes and DNSBLS but refuse to stay in contact with(or at least > contactable by) the providers when important stuff is pending? > Several generations of employees past the ones who made the settings to use them, and nobody realizes or audits where they are pointed or what they depend on. -- -george william herbert george.herbert at gmail.com From philfagan at gmail.com Wed Jun 26 01:20:28 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 25 Jun 2013 19:20:28 -0600 Subject: Security over SONET/SDH In-Reply-To: <868DE324-E510-4E4D-81F7-9F105A7C8429@ufp.org> References: <20130625133536.D4846B79@m0005296.ppops.net> <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> <868DE324-E510-4E4D-81F7-9F105A7C8429@ufp.org> Message-ID: Well put Leo; defense-in-depth. On Jun 25, 2013 6:57 PM, "Leo Bicknell" wrote: > > On Jun 25, 2013, at 6:34 PM, sam at wwcandt.com wrote: > > > I believe that if you encrypted your links sufficiently that it was > > impossible to siphon the wanted data from your upstream the response > would > > be for the tapping to move down into your data center before the crypto. > > > > With CALEA requirements and the Patriot Act they could easily compel you > > to give them a span port prior to the crypto. > > The value here isn't preventing from getting the > data, as you point out there are multiple tools at their disposal, and they > will likely compel data at some other point in the stack. The value here > is increasing the visibility of the tapping, making more people aware of > how much is going on. Forcing the tapping out of the shadows and into the > light. > > For instance if my theory that some cables are being tapped at the landing > station is correct, there are likely ISP's on this list right now that have > transatlantic links /and do not know that they are being tapped/. If the > links were encrypted and they had to serve the ISP directly to get the > unencrypted data or make them stop encrypting, that ISP would know their > data was being tapped. > > It also has the potential to shift the legal proceedings to other courts. > The FISA court can approve tapping a foreign cable as it enters the > country in near perfect, unchallengeable secrecy. If encryption moved that > to be a regular federal warrant under CALEA there would be a few more > avenues for challenging the order legally. > > People can't challenge what they don't know about. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From mpalmer at hezmatt.org Wed Jun 26 02:28:55 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 26 Jun 2013 12:28:55 +1000 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <51CA29DD.8010904@cox.net> References: <20937.29200.175222.251485@switch.ch> <51CA29DD.8010904@cox.net> Message-ID: <20130626022855.GL25984@hezmatt.org> On Tue, Jun 25, 2013 at 06:38:05PM -0500, Larry Sheldon wrote: > What is it about people that makes them free-load on services like > NTP chimes and DNSBLS but refuse to stay in contact with(or at least > contactable by) the providers when important stuff is pending? It's on the Internet. Therefore it must be free. (See also: TV programs who broadcast youtube videos) - Matt -- A few minutes ago I attempted to give a flying fsck, but the best I could do was to watch it skitter across the floor. -- Anthony de Boer, ASR From sean at donelan.com Wed Jun 26 02:58:20 2013 From: sean at donelan.com (Sean Donelan) Date: Tue, 25 Jun 2013 22:58:20 -0400 (EDT) Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: On Tue, 25 Jun 2013, Nick Khamis wrote: > We are however trying to conform to RFC standards as pointed out by > Jev. You guys really need to look at this. It's easily implementable: > > http://tools.ietf.org/html/rfc1149 That remind me I need to finish my April 1 submission to the RFC editor for next year..... This has been sitting in my todo pile for several years. RFCxxxx for publication on April 1, xxxx Assistance for Eavesdropping Legally on Avian Carriers (AELAC) Abstract The memo provides an overview and principles regarding Lawful Intercept(LI) of networks using RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers." National requirements are not addressed. Overview and Rational Avian Carriers have not provided law enforcement with advanced capabilities to conduct covert surveillance of a subject's communications. When approached by law enforcement, Avian Carriers take flight leaving behind difficult to decode droppings of their activities. Identifying a specific packet stream within a large flock of carriers is difficult. Due to the 3D ether space available to carriers and their intrinsic collision avoidance systems, although sometimes poorly implemented with windows, performing full content communications interceptions can be hit or miss. This memo does not address specific national requirements for eavesdropping. Nevertheless, it may be important to public safety that carriers never use any communication technology which could hinder law enforcement.s access to the communications of a subject of a lawful order authorizing surveillance. Avian Carriers have a long and distinguished history in communications. For thousands of years they have been used to carry important messages to military and business leaders. However, they have also been used for nefarious purposes ranging from possible financial market manipulation after Napoleo's defeat at Waterloo to reports of enemy pigeons operating in England during World War II. From rdobbins at arbor.net Wed Jun 26 03:10:34 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 26 Jun 2013 03:10:34 +0000 Subject: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <207234.1372181878@turing-police.cc.vt.edu> References: <20937.29200.175222.251485@switch.ch> <207234.1372181878@turing-police.cc.vt.edu> Message-ID: <613E34A1-72A4-45A3-BD4D-66B3455E2282@arbor.net> On Jun 26, 2013, at 12:37 AM, wrote: > I wonder how long it will take before anybody actually updates their config. I once pulled a stratum-2 out of the clocks.txt file - and was still seeing > several hundred unique hosts per hour poking the IP address for time - like over a decade later. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From lyndon at orthanc.ca Wed Jun 26 03:20:17 2013 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 25 Jun 2013 20:20:17 -0700 Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: <8BF2E5E0-BD14-4EFC-8867-77876F42D55E@orthanc.ca> On 2013-06-25, at 7:58 PM, Sean Donelan wrote: > The memo provides an overview and principles regarding Lawful Intercept(LI) of networks using RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers." National requirements are not addressed. Is scooping pigeon shit off my front lawn considered meta-data collection? --lyndon From lyndon at orthanc.ca Wed Jun 26 03:32:35 2013 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 25 Jun 2013 20:32:35 -0700 Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> , <8BF2E5E0-BD14-4EFC-8867-77876F42D55E@orthanc.ca> Message-ID: On 2013-06-25, at 8:24 PM, "Caruso, Anthony" wrote: > Yes, if you can identify the source of the grains, you know origin and flight path prior to your lawn. NSA approach's is getting the pigeon shit off of everyone's lawn... Then I am in favour of PRISM. NSA: come vacuum all the pigeon shit off my boat! Please!!! From ilan at jobvite.com Wed Jun 26 03:28:43 2013 From: ilan at jobvite.com (Ilan Erenstein) Date: Wed, 26 Jun 2013 03:28:43 +0000 Subject: DNS caching issues with AT&T, Verizon (UUNET) DNS Servers Message-ID: Hello all, I'm writing to all of you in hopes that you're able to help me. The web site for the company I work for jobvite.com was hosted by GoDaddy. They dropped our record and it was able to propagate to all ISPs DNS servers. I was able to move our record on OpenSRS but not before empty records were able to propagate to several DNS servers. Now our customers aren't able to pull up our website. This is also causing rejected/deferred emails into our candidate system. This is what I'm seeing: http://www.digwebinterface.com/?hostnames=jobvite.com&type=SOA&colorize=on&useresolver=8.8.4.4&ns=all&nameservers= I need help with clearing the cache for AT&T and Verizon (UUNET) DNS servers to make sure they pick up the new record for our domain. Here are some of the DNS servers from the above link: 165.87.13.129 (AT&T (US)) 158.43.240.3 (UUNET (UK)) 198.6.100.25 (UUNET (US)) Any help in getting this problem resolved from the network folks in AT&T and Verizon (UUNET) would be greatly appreciated. Thanks, Ilan Erenstein Jobvite Inc. ilan at jobvite.com (415) 866-8738 From jhellenthal at dataix.net Wed Jun 26 03:52:45 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 25 Jun 2013 23:52:45 -0400 Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: <1A39E01E-F170-4FDB-8C07-2436E07CB98D@dataix.net> Wow I can't believe this is still going around. All you apparently need for this is a .gov spook possessed by evil entity X and all these avians will come crashing right into their federal widows like a DDoS. Scary head spinning fun ;-) -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 25, 2013, at 22:58, Sean Donelan wrote: > > On Tue, 25 Jun 2013, Nick Khamis wrote: >> We are however trying to conform to RFC standards as pointed out by >> Jev. You guys really need to look at this. It's easily implementable: >> >> http://tools.ietf.org/html/rfc1149 > > That remind me I need to finish my April 1 submission to the RFC editor > for next year..... This has been sitting in my todo pile for several > years. > > > RFCxxxx for publication on April 1, xxxx > > Assistance for Eavesdropping Legally on Avian Carriers (AELAC) > > Abstract > > The memo provides an overview and principles regarding Lawful Intercept(LI) of networks using RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers." National requirements are not addressed. > > Overview and Rational > > Avian Carriers have not provided law enforcement with advanced capabilities to conduct covert surveillance of a subject's communications. When approached by law enforcement, Avian Carriers take flight leaving behind difficult to decode droppings of their activities. Identifying a specific packet stream within a large flock of carriers is difficult. Due to the 3D ether space available to carriers and their intrinsic collision avoidance systems, although sometimes poorly implemented with windows, performing full content communications interceptions can be hit or miss. > > This memo does not address specific national requirements for eavesdropping. Nevertheless, it may be important to public safety that carriers never use any communication technology which could hinder law enforcement.s access to the communications of a subject of a lawful order authorizing surveillance. > > Avian Carriers have a long and distinguished history in communications. For thousands of years they have been used to carry important messages to military and business leaders. However, they have also been used for nefarious purposes ranging from possible financial market manipulation after Napoleo's defeat at Waterloo to reports of enemy pigeons operating in England during World War II. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2529 bytes Desc: not available URL: From jhellenthal at dataix.net Wed Jun 26 03:54:16 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 25 Jun 2013 23:54:16 -0400 Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: <3D981E1A-4E0B-413D-9922-113DA9E18FF0@dataix.net> Matter of fact the sky is full of lightening right now... Anyone got a pentagram packet and a weje board ? -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 25, 2013, at 22:58, Sean Donelan wrote: > > On Tue, 25 Jun 2013, Nick Khamis wrote: >> We are however trying to conform to RFC standards as pointed out by >> Jev. You guys really need to look at this. It's easily implementable: >> >> http://tools.ietf.org/html/rfc1149 > > That remind me I need to finish my April 1 submission to the RFC editor > for next year..... This has been sitting in my todo pile for several > years. > > > RFCxxxx for publication on April 1, xxxx > > Assistance for Eavesdropping Legally on Avian Carriers (AELAC) > > Abstract > > The memo provides an overview and principles regarding Lawful Intercept(LI) of networks using RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers." National requirements are not addressed. > > Overview and Rational > > Avian Carriers have not provided law enforcement with advanced capabilities to conduct covert surveillance of a subject's communications. When approached by law enforcement, Avian Carriers take flight leaving behind difficult to decode droppings of their activities. Identifying a specific packet stream within a large flock of carriers is difficult. Due to the 3D ether space available to carriers and their intrinsic collision avoidance systems, although sometimes poorly implemented with windows, performing full content communications interceptions can be hit or miss. > > This memo does not address specific national requirements for eavesdropping. Nevertheless, it may be important to public safety that carriers never use any communication technology which could hinder law enforcement.s access to the communications of a subject of a lawful order authorizing surveillance. > > Avian Carriers have a long and distinguished history in communications. For thousands of years they have been used to carry important messages to military and business leaders. However, they have also been used for nefarious purposes ranging from possible financial market manipulation after Napoleo's defeat at Waterloo to reports of enemy pigeons operating in England during World War II. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2529 bytes Desc: not available URL: From lyndon at orthanc.ca Wed Jun 26 04:04:25 2013 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 25 Jun 2013 21:04:25 -0700 Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: <3D981E1A-4E0B-413D-9922-113DA9E18FF0@dataix.net> References: <20130624125556.D485E358@m0005296.ppops.net> <3D981E1A-4E0B-413D-9922-113DA9E18FF0@dataix.net> Message-ID: <538C7FDF-2A98-48BB-BE02-678D63B343B8@orthanc.ca> On 2013-06-25, at 8:54 PM, Jason Hellenthal wrote: > Anyone got a pentagram packet and a weje board ? Be careful, when you pull out the chalk to draw a pentaGRAM around your data centre, that you don't ? accidentally ? draw a pentaGONE. From jhellenthal at dataix.net Wed Jun 26 04:24:09 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 26 Jun 2013 00:24:09 -0400 Subject: Assistance for Eavesdropping Legally on Avian Carriers (AELAC) In-Reply-To: <538C7FDF-2A98-48BB-BE02-678D63B343B8@orthanc.ca> References: <20130624125556.D485E358@m0005296.ppops.net> <3D981E1A-4E0B-413D-9922-113DA9E18FF0@dataix.net> <538C7FDF-2A98-48BB-BE02-678D63B343B8@orthanc.ca> Message-ID: <019B73F1-1837-465E-B617-A2401FE48CAE@dataix.net> Lol -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 26, 2013, at 0:04, Lyndon Nerenberg wrote: > > On 2013-06-25, at 8:54 PM, Jason Hellenthal wrote: > >> Anyone got a pentagram packet and a weje board ? > > Be careful, when you pull out the chalk to draw a pentaGRAM around your data centre, that you don't ? accidentally ? draw a pentaGONE. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2529 bytes Desc: not available URL: From sam at wwcandt.com Wed Jun 26 08:19:42 2013 From: sam at wwcandt.com (sam at wwcandt.com) Date: Wed, 26 Jun 2013 04:19:42 -0400 (EDT) Subject: Security over SONET/SDH In-Reply-To: <868DE324-E510-4E4D-81F7-9F105A7C8429@ufp.org> References: <20130625133536.D4846B79@m0005296.ppops.net> <54596.71.62.150.38.1372203257.squirrel@www.systemetrixs.com> <868DE324-E510-4E4D-81F7-9F105A7C8429@ufp.org> Message-ID: <55926.71.62.150.38.1372234782.squirrel@www.systemetrixs.com> Well put, and point taken :-). Sam > > On Jun 25, 2013, at 6:34 PM, sam at wwcandt.com wrote: > >> I believe that if you encrypted your links sufficiently that it was >> impossible to siphon the wanted data from your upstream the response >> would >> be for the tapping to move down into your data center before the crypto. >> >> With CALEA requirements and the Patriot Act they could easily compel you >> to give them a span port prior to the crypto. > > The value here isn't preventing from getting the > data, as you point out there are multiple tools at their disposal, and > they will likely compel data at some other point in the stack. The value > here is increasing the visibility of the tapping, making more people aware > of how much is going on. Forcing the tapping out of the shadows and into > the light. > > For instance if my theory that some cables are being tapped at the landing > station is correct, there are likely ISP's on this list right now that > have transatlantic links /and do not know that they are being tapped/. If > the links were encrypted and they had to serve the ISP directly to get the > unencrypted data or make them stop encrypting, that ISP would know their > data was being tapped. > > It also has the potential to shift the legal proceedings to other courts. > The FISA court can approve tapping a foreign cable as it enters the > country in near perfect, unchallengeable secrecy. If encryption moved > that to be a regular federal warrant under CALEA there would be a few more > avenues for challenging the order legally. > > People can't challenge what they don't know about. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From gall at switch.ch Wed Jun 26 07:38:05 2013 From: gall at switch.ch (gall at switch.ch) Date: Wed, 26 Jun 2013 09:38:05 +0200 Subject: Fwd: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <51C9AEB5.60407@one.verizon.com> References: <20937.29200.175222.251485@switch.ch> <51C9AEB5.60407@one.verizon.com> Message-ID: <20938.39517.77240.446775@switch.ch> On Tue, 25 Jun 2013 10:52:37 -0400, Anthony Williams said: > Alex: > You should also get this posted to the NTP.ORG community. > http://www.pool.ntp.org It's been marked as inactive since the end of last year (http://support.ntp.org/bin/view/Servers/InactiveTimeServers). I don't know if it was in the NTP pool, but I'm sure the ETH folks have removed it from there as well if it was. > Also a Usenet posting (who still uses that, right?) to > comp.protocols.time.ntp will also help get the word out. > On 6/25/2013 6:33 AM, gall at switch.ch wrote: >> I'm forwarding this heads-up for the shutdown of the well-known NTP >> server swisstime.ethz.ch on behalf of the ETH Zurich. >> > -Alby -- Alex From mike at smashing.net Wed Jun 26 11:25:29 2013 From: mike at smashing.net (Mike Hughes) Date: Wed, 26 Jun 2013 12:25:29 +0100 Subject: [Filtering of NTP-access to swisstime.ethz.ch as of July 1st, 2013] In-Reply-To: <613E34A1-72A4-45A3-BD4D-66B3455E2282@arbor.net> References: <20937.29200.175222.251485@switch.ch> <207234.1372181878@turing-police.cc.vt.edu> <613E34A1-72A4-45A3-BD4D-66B3455E2282@arbor.net> Message-ID: On 26 June 2013 04:10, Dobbins, Roland wrote: > > On Jun 26, 2013, at 12:37 AM, < > Valdis.Kletnieks at vt.edu> wrote: > > > I wonder how long it will take before anybody actually updates their > config. I once pulled a stratum-2 out of the clocks.txt file - and was > still seeing > > several hundred unique hosts per hour poking the IP address for time - > like over a decade later. > > > Would actually be interesting to get a brief update on how many of these SNTP requests the Madison NTP server still gets. At the time, Dave hypothesized that the affected devices would have a half-life of about 5 years - so 10 years on, you would expect this to have subsided to around 25% of the initially report rate. I wonder if that held true? Mike From alby.williams at verizon.com Wed Jun 26 13:12:41 2013 From: alby.williams at verizon.com (Anthony Williams) Date: Wed, 26 Jun 2013 09:12:41 -0400 Subject: DNS caching issues with AT&T, Verizon (UUNET) DNS Servers In-Reply-To: References: Message-ID: <51CAE8C9.9050708@one.verizon.com> Ilan: I passed along your request on the UUNET end and the cache has now been flushed on the US side. I might have to do some POC digging on the UK side. jobvite.com at 198.6.100.25 (UUNET (US)): jobvite.com. 300 IN SOA ns-1989.awsdns-56.co.uk. awsdns-hostmaster.amazon.com. ( 2013062506 ; serial 7200 ; refresh (2 hours) 900 ; retry (15 minutes) 86400 ; expire (1 day) 300 ; minimum (5 minutes) ) -Alby On 6/25/2013 11:28 PM, Ilan Erenstein wrote: > Hello all, > > I'm writing to all of you in hopes that you're able to help me. The web site for the company I work for jobvite.com was hosted by GoDaddy. They dropped our record and it was able to propagate to all ISPs DNS servers. I was able to move our record on OpenSRS but not before empty records were able to propagate to several DNS servers. Now our customers aren't able to pull up our website. This is also causing rejected/deferred emails into our candidate system. > > This is what I'm seeing: http://www.digwebinterface.com/?hostnames=jobvite.com&type=SOA&colorize=on&useresolver=8.8.4.4&ns=all&nameservers= > > I need help with clearing the cache for AT&T and Verizon (UUNET) DNS servers to make sure they pick up the new record for our domain. Here are some of the DNS servers from the above link: > > 165.87.13.129 (AT&T (US)) > 158.43.240.3 (UUNET (UK)) > 198.6.100.25 (UUNET (US)) > > Any help in getting this problem resolved from the network folks in AT&T and Verizon (UUNET) would be greatly appreciated. > > Thanks, > > Ilan Erenstein > Jobvite Inc. > ilan at jobvite.com > (415) 866-8738 > From ilan at jobvite.com Wed Jun 26 13:44:07 2013 From: ilan at jobvite.com (Ilan Erenstein) Date: Wed, 26 Jun 2013 13:44:07 +0000 Subject: DNS caching issues with AT&T, Verizon (UUNET) DNS Servers In-Reply-To: <51CAE8C9.9050708@one.verizon.com> References: <51CAE8C9.9050708@one.verizon.com> Message-ID: <87EABF09-4C16-418E-8639-C04B339DEF4D@jobvite.com> Thank you very much good sir. We appreciate it. -Ilan On Jun 26, 2013, at 6:12 AM, Anthony Williams wrote: > > Ilan: > > I passed along your request on the UUNET end and the cache has now > been flushed on the US side. I might have to do some POC digging on the > UK side. > > > jobvite.com at 198.6.100.25 (UUNET (US)): > > jobvite.com. 300 IN SOA ns-1989.awsdns-56.co.uk. > awsdns-hostmaster.amazon.com. ( > 2013062506 ; serial > 7200 ; refresh (2 hours) > 900 ; retry (15 minutes) > 86400 ; expire (1 day) > 300 ; minimum (5 minutes) > ) > > > -Alby > > > > > > > > On 6/25/2013 11:28 PM, Ilan Erenstein wrote: >> Hello all, >> >> I'm writing to all of you in hopes that you're able to help me. The web site for the company I work for jobvite.com was hosted by GoDaddy. They dropped our record and it was able to propagate to all ISPs DNS servers. I was able to move our record on OpenSRS but not before empty records were able to propagate to several DNS servers. Now our customers aren't able to pull up our website. This is also causing rejected/deferred emails into our candidate system. >> >> This is what I'm seeing: http://www.digwebinterface.com/?hostnames=jobvite.com&type=SOA&colorize=on&useresolver=8.8.4.4&ns=all&nameservers= >> >> I need help with clearing the cache for AT&T and Verizon (UUNET) DNS servers to make sure they pick up the new record for our domain. Here are some of the DNS servers from the above link: >> >> 165.87.13.129 (AT&T (US)) >> 158.43.240.3 (UUNET (UK)) >> 198.6.100.25 (UUNET (US)) >> >> Any help in getting this problem resolved from the network folks in AT&T and Verizon (UUNET) would be greatly appreciated. >> >> Thanks, >> >> Ilan Erenstein >> Jobvite Inc. >> ilan at jobvite.com >> (415) 866-8738 >> > > From atif_abbasi at hotmail.com Wed Jun 26 13:47:05 2013 From: atif_abbasi at hotmail.com (Atif Abbasi) Date: Wed, 26 Jun 2013 09:47:05 -0400 Subject: Bell Aliant Contact Message-ID: Please contact off line Thank you, Atif 416.986.6207 From Marcus.Josephson at Level3.com Wed Jun 26 14:55:57 2013 From: Marcus.Josephson at Level3.com (Josephson, Marcus) Date: Wed, 26 Jun 2013 14:55:57 +0000 Subject: Looking for a Twitter Engineer Message-ID: Can someone from Twitter contact me off list. Thanks. From jlewis at lewis.org Wed Jun 26 15:32:26 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 26 Jun 2013 11:32:26 -0400 (EDT) Subject: Telehouse Seoul OOB exchange Message-ID: I wonder if anyone has gear in TELEHOUSE Seoul Seoul Financial Center Taepyeongno 1-ga 84 Jung-gu, Seoul, Korea 100-170 and would be interested in exchanging a low bandwidth/utilization ethernet cross connect strictly for OOB management purposes to aid in troubleshooting and monitoring during international transit failures. Please contact me off-list if you're interested. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jharper at well.com Wed Jun 26 15:56:41 2013 From: jharper at well.com (Jeff Harper) Date: Wed, 26 Jun 2013 08:56:41 -0700 (PDT) Subject: Google's Geo IP Solution In-Reply-To: Message-ID: <1322399227.87522.1372262201134.JavaMail.root@well.com> Hello, If anyone on the list is from Google and involved with their GeoIP service, could you please contact me off list? ?I've been trying to get one IP address modified from Canada to the US. ?Every other main GeoIP has the location correctly, except Google. ?I've filled out their correction form multiple times over the last 4 months, but perhaps the form isn't reaching them? Thanks very much! -- Jeff Harper | ?www.well.com ip access-list extended jeff permit tcp any any eq intelligence deny tcp any any eq stupid-people From maillist at webjogger.net Wed Jun 26 17:52:33 2013 From: maillist at webjogger.net (Adam Greene) Date: Wed, 26 Jun 2013 13:52:33 -0400 Subject: Paetec PI space? Message-ID: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Hi, We have a customer who was assigned some PI IPv4 space by Paetec back in mid-90's and who has continued to announce the blocks, even though their relationship with Paetec ended a long time ago. Is this a common situation? Does the customer risk having that space reclaimed by Paetec at some point, or is it safe to assume they will continue to be able to route trouble-free for years to come? Thanks, Adam From james.cutler at consultant.com Wed Jun 26 18:04:50 2013 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 26 Jun 2013 14:04:50 -0400 Subject: Paetec PI space? In-Reply-To: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: <9BBB98EF-65D0-4279-BD3E-D578E70F6114@consultant.com> On Jun 26, 2013, at 1:52 PM, "Adam Greene" wrote: > Hi, > > > > We have a customer who was assigned some PI IPv4 space by Paetec back in > mid-90's and who has continued to announce the blocks, even though their > relationship with Paetec ended a long time ago. > > > > Is this a common situation? No data either way. > Does the customer risk having that space > reclaimed by Paetec at some point What does the contract say? > , or is it safe to assume they will > continue to be able to route trouble-free for years to come? It is never save to assume anything, but especially not save to assume "trouble-free for years to come". > > > > Thanks, > > Adam > From streiner at cluebyfour.org Wed Jun 26 18:06:10 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 26 Jun 2013 14:06:10 -0400 (EDT) Subject: Paetec PI space? In-Reply-To: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: > We have a customer who was assigned some PI IPv4 space by Paetec back in > mid-90's and who has continued to announce the blocks, even though their > relationship with Paetec ended a long time ago. > > Is this a common situation? Does the customer risk having that space > reclaimed by Paetec at some point, or is it safe to assume they will > continue to be able to route trouble-free for years to come? They should plan to renumber out of that space in the very near future. Even with some sort of formally documented agreement between Paetec and the customer that explicitly allows the customer to continue using the space after the end of their business relationship, I would guess that ARIN's policies take a rather dim view of 'off the books' transfers of address space. This sounds like an administrative oversight on Paetec's part - one that Paetec could choose to correct at any time. It's also not impossible that if Paetec forgot about this space, that they could try to assign it to another customer, effectively double-booking it, and causing major headaches for your customer and whatever customer gets the space. It's also possible that a post about this to a widely-read mailing list could prompt someone from Paetec to look into this more closely ;) jms From jabley at hopcount.ca Wed Jun 26 18:18:54 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 26 Jun 2013 14:18:54 -0400 Subject: Paetec PI space? In-Reply-To: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> On 2013-06-26, at 13:52, "Adam Greene" wrote: > We have a customer who was assigned some PI IPv4 space by Paetec back in > mid-90's I think it's correct to say that the only entities that can assign PI IPv4 space are RIRs and the IANA. If I'm right, what you're talking about is PA space, regardless of claims made by your customer or Paetec. Joe From blair.trosper at updraftnetworks.com Wed Jun 26 18:57:10 2013 From: blair.trosper at updraftnetworks.com (Blair Trosper) Date: Wed, 26 Jun 2013 13:57:10 -0500 Subject: google mail problems? Message-ID: Our entire organization and three of my other accounts are getting this pop-up when sending a message: Oops... a server error occurred and your email was not sent. (#793) But, as usual, everything is "totally fine" according to the GApps status page: http://www.google.com/appsstatus#hl=en&v=status&ts=1372272841152 -- Blair Trosper Weather Data / Updraft Networks blair.trosper at updraftnetworks.com NOC: 512-666-0536 From drc at virtualized.org Wed Jun 26 18:57:46 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 26 Jun 2013 11:57:46 -0700 Subject: Paetec PI space? In-Reply-To: <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> Message-ID: Joe, On Jun 26, 2013, at 11:18 AM, Joe Abley wrote: >> We have a customer who was assigned some PI IPv4 space by Paetec back in mid-90's > I think it's correct to say that the only entities that can assign PI IPv4 space are RIRs and the IANA. Nope. Historically, there was no distinction and people could (and did) sub-allocate address space with no terms of service indicating the address space should ever be returned. After the establishment of the RIRs and the creation of the PI/PA distinction (encouraged with much controversy in the CIDR/ALE working group days), there was a concerted effort by the RIRs to move towards a "lease" model. I believe that effort may have been reflected in RSAs at the RIRs, but am too lazy to look it up. Regards, -drc From bill at herrin.us Wed Jun 26 18:58:04 2013 From: bill at herrin.us (William Herrin) Date: Wed, 26 Jun 2013 14:58:04 -0400 Subject: Paetec PI space? In-Reply-To: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: On Wed, Jun 26, 2013 at 1:52 PM, Adam Greene wrote: > We have a customer who was assigned some PI IPv4 space by Paetec back in > mid-90's and who has continued to announce the blocks, even though their > relationship with Paetec ended a long time ago. > > Is this a common situation? It was back in the day. It isn't any more. Most folks doing that have since renumbered. > Does the customer risk having that space > reclaimed by Paetec at some point, That depends what Paetec has to say about it. Unless the customer has paperwork to the effect that the assignment outlives the business relationship (and for how long) then it's entirely up to Paetec staff today and tomorrow. > or is it safe to assume they will > continue to be able to route trouble-free for years to come? Like all registrants, Paetec is under increasing pressure from ARIN to justify its ongoing assignments. It is not required to provide Internet services to your customer, but lack of ongoing contact with your customer is likely to become an administrative problem for them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Wed Jun 26 19:17:30 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 26 Jun 2013 15:17:30 -0400 (EDT) Subject: Paetec PI space? In-Reply-To: References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: On Wed, 26 Jun 2013, Justin M. Streiner wrote: >> We have a customer who was assigned some PI IPv4 space by Paetec back in >> mid-90's and who has continued to announce the blocks, even though their >> relationship with Paetec ended a long time ago. >> >> Is this a common situation? Does the customer risk having that space >> reclaimed by Paetec at some point, or is it safe to assume they will >> continue to be able to route trouble-free for years to come? > > They should plan to renumber out of that space in the very near future. > > Even with some sort of formally documented agreement between Paetec and the > customer that explicitly allows the customer to continue using the space > after the end of their business relationship, I would guess that ARIN's > policies take a rather dim view of 'off the books' transfers of address > space. It's got to be PA space. Paetec isn't in a position to assign PI space. I used to think similarly, that ARIN members could only assign PA space to connectivity customers, but last time I consulted with ARIN about it, I was informed this is not the case. AFAIK, there is nothing stopping any provider from acting like an LIR and "renting" IP space to customers whether the customers get connectivity from the provider or not. Maybe they have Paetec's permission to use the space indefinitely. Maybe it's an oversight in Paetec's turn-down process that the space was never reclaimed. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Wed Jun 26 19:29:27 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 26 Jun 2013 15:29:27 -0400 Subject: Google's Geo IP Solution In-Reply-To: <1322399227.87522.1372262201134.JavaMail.root@well.com> References: <1322399227.87522.1372262201134.JavaMail.root@well.com> Message-ID: yes? On Wed, Jun 26, 2013 at 11:56 AM, Jeff Harper wrote: > Hello, > > If anyone on the list is from Google and involved with their GeoIP service, could you please contact me off list? I've been trying to get one IP address modified from Canada to the US. Every other main GeoIP has the location correctly, except Google. I've filled out their correction form multiple times over the last 4 months, but perhaps the form isn't reaching them? > > Thanks very much! > > -- > Jeff Harper | www.well.com > ip access-list extended jeff > permit tcp any any eq intelligence > deny tcp any any eq stupid-people > From drc at virtualized.org Wed Jun 26 19:32:40 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 26 Jun 2013 12:32:40 -0700 Subject: Paetec PI space? In-Reply-To: References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: <5F9247E9-5FA6-4F03-B4EE-CC89A7E94BF0@virtualized.org> Jon, On Jun 26, 2013, at 12:17 PM, Jon Lewis wrote: >>> We have a customer who was assigned some PI IPv4 space by Paetec back in mid-90's >> They should plan to renumber out of that space in the very near future. It'd be nice for routing system hygiene, but there probably is no requirement (unless there was some contractual language with Paetec). > I used to think similarly, that ARIN members could only assign PA space to connectivity customers, but last time I consulted with ARIN about it, I was informed this is not the case. "mid-90's" suggests "before ARIN". Regards, -drc From bill at herrin.us Wed Jun 26 19:33:13 2013 From: bill at herrin.us (William Herrin) Date: Wed, 26 Jun 2013 15:33:13 -0400 Subject: Paetec PI space? In-Reply-To: References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: On Wed, Jun 26, 2013 at 3:17 PM, Jon Lewis wrote: > It's got to be PA space. Paetec isn't in a position to assign PI space. No distinction is drawn between PA and PI for ARIN-region address space assigned prior to ARIN's inception in 1997. That's "legacy" address space. Since the end of filtering on prefixes shorter than /24, PA and PI have lost most of ther distinction anyway. There's RIR-assigned and there's LIR assigned. The RIR assignes addresses to LIRs and end users. The LIR assigns addresses to LIRs and end users. Unless its IPv6 in which LIRs are strongly discouraged from assigning addresses to other LIRs and multihomed end users. Short version: drop PI and PA from the conversation. It makes absolutely no difference whether the customer thought Paetec assigned them PI space. The customer's addresses are either directly from ARIN or they're from Paetec. That's it. If the latter, it's up to Paetec what the customer can and can't continue to do with them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgwatkin at magmic.com Wed Jun 26 19:13:46 2013 From: jgwatkin at magmic.com (Jamie Gwatkin) Date: Wed, 26 Jun 2013 15:13:46 -0400 Subject: google mail problems? In-Reply-To: References: Message-ID: We're also seeing the same, twitter users are also reporting a lot of problem. https://twitter.com/search/realtime?q=google%20apps&src=typd On Wed, Jun 26, 2013 at 2:57 PM, Blair Trosper < blair.trosper at updraftnetworks.com> wrote: > Our entire organization and three of my other accounts are getting this > pop-up when sending a message: > > Oops... a server error occurred and your email was not sent. (#793) > > > But, as usual, everything is "totally fine" according to the GApps status > page: > http://www.google.com/appsstatus#hl=en&v=status&ts=1372272841152 > > -- > Blair Trosper > Weather Data / Updraft Networks > blair.trosper at updraftnetworks.com > NOC: 512-666-0536 > From savage at savage.za.org Wed Jun 26 19:41:19 2013 From: savage at savage.za.org (Chris Knipe) Date: Wed, 26 Jun 2013 21:41:19 +0200 Subject: google mail problems? In-Reply-To: References: Message-ID: been getting it for a few days (weeks?) already now... On Wed, Jun 26, 2013 at 9:13 PM, Jamie Gwatkin wrote: > We're also seeing the same, twitter users are also reporting a lot of > problem. > > https://twitter.com/search/realtime?q=google%20apps&src=typd > > > On Wed, Jun 26, 2013 at 2:57 PM, Blair Trosper < > blair.trosper at updraftnetworks.com> wrote: > >> Our entire organization and three of my other accounts are getting this >> pop-up when sending a message: >> >> Oops... a server error occurred and your email was not sent. (#793) >> >> >> But, as usual, everything is "totally fine" according to the GApps status >> page: >> http://www.google.com/appsstatus#hl=en&v=status&ts=1372272841152 >> >> -- >> Blair Trosper >> Weather Data / Updraft Networks >> blair.trosper at updraftnetworks.com >> NOC: 512-666-0536 >> -- Regards, Chris Knipe From bmanning at vacation.karoshi.com Wed Jun 26 19:45:15 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 26 Jun 2013 19:45:15 +0000 Subject: Paetec PI space? In-Reply-To: <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> Message-ID: <20130626194515.GA21660@vacation.karoshi.com.> f the assignment predated ARIN, then its not clear if current ARIN policy is applicable. On Wed, Jun 26, 2013 at 02:18:54PM -0400, Joe Abley wrote: > > On 2013-06-26, at 13:52, "Adam Greene" wrote: > > > We have a customer who was assigned some PI IPv4 space by Paetec back in > > mid-90's > > I think it's correct to say that the only entities that can assign PI IPv4 space are RIRs and the IANA. If I'm right, what you're talking about is PA space, regardless of claims made by your customer or Paetec. > > > Joe > > From alexb at ripe.net Wed Jun 26 20:08:27 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 26 Jun 2013 22:08:27 +0200 Subject: RPKI Validator 2.11 with RESTful API Message-ID: We just released a new version of the RIPE NCC RPKI Validator with some major new functionality. The application has always been able to determine the RPKI validity state of a BGP announcement, but it was only visible in the UI. Many users have asked us to expose this functionality through an API, so it can be used for scripting and alerting. In addition, operators have expressed that they would like to know the reason of an 'Invalid' BGP announcement: whether it is an origination from unauthorised AS or if it is a more specific announcement than is allowed by the Maximum Length of the ROA. All of this is now available in version 2.11. When you supply a combination of AS and IP prefix, they will be matched against all the Validated ROA Prefixes (VRPs) that are in the cache of the RPKI Validator. The result is returned in JSON format and contains the following information: - The RPKI validity state - The VRPs that caused the state - In case of an 'Invalid' state, the reason So for example, when running this: $ curl http://localhost:8080/api/v1/validity/AS12654/93.175.147.0/24 The response will be: { "validated_route":{ "route":{ "origin_asn":"AS12654", "prefix":"93.175.147.0/24" }, "validity":{ "state":"Invalid", "reason":"as", "description":"At least one VRP Covers the Route Prefix, but no VRP ASN matches the route origin ASN", "VRPs":{ "matched":[], "unmatched_as":[{ "asn":"AS196615", "prefix":"93.175.147.0/24", "max_length":24 }], "unmatched_length":[] } } } Full documentation is available here: https://www.ripe.net/developers/rpki-validator-api You can download the application here: http://www.ripe.net/certification/tools-and-resources Kaia Global Networks offers a testbed where you can try out the functionality on a public instance of the RPKI Validator: http://195.13.63.18:8080/export We look forward to your feedback, to hear how we can improve on this functionality. Kind regards, Alex Band Product Manager RIPE NCC From maillist at webjogger.net Wed Jun 26 21:11:28 2013 From: maillist at webjogger.net (Adam Greene) Date: Wed, 26 Jun 2013 17:11:28 -0400 Subject: Paetec PI space? In-Reply-To: <20130626194515.GA21660@vacation.karoshi.com.> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> <20130626194515.GA21660@vacation.karoshi.com.> Message-ID: <01c001ce72b1$b975dc50$2c6194f0$@webjogger.net> Thanks everyone. It sounds like (a) customer needs to clarify contract terms with Paetec, and (b) unless they have an ongoing relationship, the best long-term plan is to renumber. I did check reg dates on the blocks, and it is much more recent than the customer led me to believe (or than I interpreted) ... so I suspect this is less something which simply dropped off the map and more of an above-board and possibly ongoing relationship than I suspected. The customer does provide voice service, so there may be something going on behind the scenes which makes sense from an authoritative routing perspective. Thanks for your help. This customer seems to be responsible so I suspect I may not have all the details and overstated the issue. -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Wednesday, June 26, 2013 3:45 PM To: Joe Abley Cc: Adam Greene; nanog at nanog.org Subject: Re: Paetec PI space? f the assignment predated ARIN, then its not clear if current ARIN policy is applicable. On Wed, Jun 26, 2013 at 02:18:54PM -0400, Joe Abley wrote: > > On 2013-06-26, at 13:52, "Adam Greene" wrote: > > > We have a customer who was assigned some PI IPv4 space by Paetec back in > > mid-90's > > I think it's correct to say that the only entities that can assign PI IPv4 space are RIRs and the IANA. If I'm right, what you're talking about is PA space, regardless of claims made by your customer or Paetec. > > > Joe > > From jlewis at lewis.org Wed Jun 26 21:23:52 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 26 Jun 2013 17:23:52 -0400 (EDT) Subject: Paetec PI space? In-Reply-To: References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: On Wed, 26 Jun 2013, William Herrin wrote: > On Wed, Jun 26, 2013 at 3:17 PM, Jon Lewis wrote: >> It's got to be PA space. Paetec isn't in a position to assign PI space. > > No distinction is drawn between PA and PI for ARIN-region address > space assigned prior to ARIN's inception in 1997. That's "legacy" > address space. > > Since the end of filtering on prefixes shorter than /24, PA and PI > have lost most of ther distinction anyway. There's RIR-assigned and The distinction to me is that PA space is provider owned space assigned to a customer. PI space is "your space", whether assigned by ARIN or "legacy" space handed out by Internic or whoever was handing out space at the given pre-RIR time. It's yours to use with whatever provider you want. PA space generally can't be taken with you if you leave the provider...though it's not unusual to be given some amount of time to renumber. IME, it would be unusual, even for pre-RIR space, for a provider to assign space to a customer and not expect to reclaim that space when the customer terminates service. At the same time, it wouldn't be unusual, particularly for very large or very people/clue deficient providers to just never bother reclaiming space. In such a case, I'd say it still is their space...they just haven't done the housekeeping to realize that the space should be back in their pool of assignable blocks. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Valdis.Kletnieks at vt.edu Wed Jun 26 21:40:26 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Jun 2013 17:40:26 -0400 Subject: Paetec PI space? In-Reply-To: Your message of "Wed, 26 Jun 2013 14:06:10 -0400." References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: <57726.1372282826@turing-police.cc.vt.edu> On Wed, 26 Jun 2013 14:06:10 -0400, "Justin M. Streiner" said: > > We have a customer who was assigned some PI IPv4 space by Paetec back in > > mid-90's and who has continued to announce the blocks, even though their > > relationship with Paetec ended a long time ago. > > > > Is this a common situation? Does the customer risk having that space > > reclaimed by Paetec at some point, or is it safe to assume they will > > continue to be able to route trouble-free for years to come? > > They should plan to renumber out of that space in the very near future. This is an excellent time to plan to renumber into 2001:: if they haven't such plans already. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Wed Jun 26 22:00:57 2013 From: bill at herrin.us (William Herrin) Date: Wed, 26 Jun 2013 18:00:57 -0400 Subject: Paetec PI space? In-Reply-To: References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> Message-ID: On Wed, Jun 26, 2013 at 5:23 PM, Jon Lewis wrote: > On Wed, 26 Jun 2013, William Herrin wrote: > >> On Wed, Jun 26, 2013 at 3:17 PM, Jon Lewis wrote: >>> >>> It's got to be PA space. Paetec isn't in a position to assign PI space. >> >> >> No distinction is drawn between PA and PI for ARIN-region address >> space assigned prior to ARIN's inception in 1997. That's "legacy" >> address space. >> >> Since the end of filtering on prefixes shorter than /24, PA and PI >> have lost most of ther distinction anyway. There's RIR-assigned and > > The distinction to me is that PA space is provider owned space assigned to a > customer. Hi Jon, If the space was assigned after ARIN's inception then it's no more owned by the service provider than by the end user. If the ARIN contract you signed was clear on nothing else, it was clear about that. You are correct, however, that the Local Internet Registry (LIR, aka ISP) may set additional rules for the address' use beyond those rules ARIN sets. In the ARIN region (this is less clear cut in other regions) one of the common rules the LIR sets is that you can't keep the addresses when you cease to buy a compatible product from the LIR. However, and this is important, the LIR has complete discretion in adding that rule. ARIN in no way requires it. So it isn't PA or PI... it's just a heirarchy of registries, each of which adds rules. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpalmer at hezmatt.org Wed Jun 26 22:35:12 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Thu, 27 Jun 2013 08:35:12 +1000 Subject: google mail problems? In-Reply-To: References: Message-ID: <20130626223512.GY25984@hezmatt.org> On Wed, Jun 26, 2013 at 01:57:10PM -0500, Blair Trosper wrote: > But, as usual, everything is "totally fine" according to the GApps status > page: > http://www.google.com/appsstatus#hl=en&v=status&ts=1372272841152 Status pages, at least for any service big enough to matter, are nothing more than a barometer for how scathing the news reports are about the outage. I'm convinced they're managed by the PR department. - Matt -- (And don't even mention the Army Of Cultists that pop up every time you claim that it might be less than absolutely perfect for every purpose ever conceived.) -- Dave Brown, ASR, on MacOS X From bjorn at leffler.org Thu Jun 27 01:24:59 2013 From: bjorn at leffler.org (Bjorn Leffler) Date: Thu, 27 Jun 2013 11:24:59 +1000 Subject: google mail problems? In-Reply-To: <20130626223512.GY25984@hezmatt.org> References: <20130626223512.GY25984@hezmatt.org> Message-ID: This was resolved 8 min after the initial email. http://www.google.com/appsstatus#hl=en&v=issue&ts=1372341599000&sid=1&iid=3ec67925039e152c4ab58a809c97ee24 On Thu, Jun 27, 2013 at 8:35 AM, Matt Palmer wrote: > On Wed, Jun 26, 2013 at 01:57:10PM -0500, Blair Trosper wrote: > > But, as usual, everything is "totally fine" according to the GApps status > > page: > > http://www.google.com/appsstatus#hl=en&v=status&ts=1372272841152 > > Status pages, at least for any service big enough to matter, are nothing > more than a barometer for how scathing the news reports are about the > outage. I'm convinced they're managed by the PR department. > > - Matt > > -- > (And don't even mention the Army Of Cultists that pop up every time you > claim that it might be less than absolutely perfect for every purpose ever > conceived.) > -- Dave Brown, ASR, on MacOS X > > > From tpoder at cis.vutbr.cz Thu Jun 27 12:38:26 2013 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Thu, 27 Jun 2013 14:38:26 +0200 Subject: IPv6 adoption in the past few days In-Reply-To: References: <51C703D2.8080305@cis.vutbr.cz> Message-ID: <51CC3242.3030501@cis.vutbr.cz> False alarm. Sorry for vain hope (if there was any). IPv6 is back in normal. Seatbelts can be unfasten. T. On 6/24/13 2:39 PM, Randy Bush wrote: >> there is massive increase in IPv6 adoption (from 1.5% to 1.7%) in the >> past few days. > luckily i had my seatbelt fastened > > randy From dsparro at gmail.com Thu Jun 27 13:51:11 2013 From: dsparro at gmail.com (Dave Sparro) Date: Thu, 27 Jun 2013 09:51:11 -0400 Subject: Paetec PI space? In-Reply-To: <01c001ce72b1$b975dc50$2c6194f0$@webjogger.net> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> <64E23E75-7C4F-4817-A626-C46EBC91C917@hopcount.ca> <20130626194515.GA21660@vacation.karoshi.com.> <01c001ce72b1$b975dc50$2c6194f0$@webjogger.net> Message-ID: <51CC434F.8060202@gmail.com> On 6/26/2013 5:11 PM, Adam Greene wrote: > Thanks everyone. > > It sounds like (a) customer needs to clarify contract terms with Paetec, and > (b) unless they have an ongoing relationship, the best long-term plan is to > renumber. > > I did check reg dates on the blocks, and it is much more recent than the > customer led me to believe (or than I interpreted) ... so I suspect this is > less something which simply dropped off the map and more of an above-board > and possibly ongoing relationship than I suspected. The customer does > provide voice service, so there may be something going on behind the scenes > which makes sense from an authoritative routing perspective. > > Thanks for your help. This customer seems to be responsible so I suspect I > may not have all the details and overstated the issue. And just one more note to complicate things a little more for you. Paetec was acquired by Windstream last year. I hope that doesn't make it even harder for you to find answers to your questions from the service provider, but I suspect that it will. -- Dave Sparro From morrowc.lists at gmail.com Thu Jun 27 14:12:19 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Jun 2013 10:12:19 -0400 Subject: Google's Geo IP Solution In-Reply-To: References: <1322399227.87522.1372262201134.JavaMail.root@well.com> Message-ID: perhaps more verbosely: "Jeffrey, how can I be of assistance? Or did you already get worked out via another avenue?" On Wed, Jun 26, 2013 at 3:29 PM, Christopher Morrow wrote: > yes? > > On Wed, Jun 26, 2013 at 11:56 AM, Jeff Harper wrote: >> Hello, >> >> If anyone on the list is from Google and involved with their GeoIP service, could you please contact me off list? I've been trying to get one IP address modified from Canada to the US. Every other main GeoIP has the location correctly, except Google. I've filled out their correction form multiple times over the last 4 months, but perhaps the form isn't reaching them? >> >> Thanks very much! >> >> -- >> Jeff Harper | www.well.com >> ip access-list extended jeff >> permit tcp any any eq intelligence >> deny tcp any any eq stupid-people >> From kmp.lists+nanog at gmail.com Thu Jun 27 14:17:12 2013 From: kmp.lists+nanog at gmail.com (K. M. Peterson) Date: Thu, 27 Jun 2013 10:17:12 -0400 Subject: SixXS Contact Message-ID: Are there any SixXS admins who read this list? I seem to have committed a faux pas with respect to requesting an account, and I'm not getting any responses to my attempts (to info at sixxs.net) to clear up the issue. I appreciate the response, and apologize for this intrusion... _KMP From alby.williams at verizon.com Thu Jun 27 14:47:51 2013 From: alby.williams at verizon.com (Anthony Williams) Date: Thu, 27 Jun 2013 10:47:51 -0400 Subject: SixXS Contact In-Reply-To: References: Message-ID: <51CC5097.8030504@one.verizon.com> Can I piggy back on that inquiry and request a reset of my ISK points after committing a faux pas with respect to going negative from down v6 tunnels and deleting. Now to create a new tunnel I need positive ISK points and I'm stilling at -10 with no way to boost my numbers. :( Reset Points: AWJ11-SIXXS Oh Pretty please w/sugar on top. :) -Alby On 6/27/2013 10:17 AM, K. M. Peterson wrote: > Are there any SixXS admins who read this list? I seem to have committed a > faux pas with respect to requesting an account, and I'm not getting any > responses to my attempts (to info at sixxs.net) to clear up the issue. > > I appreciate the response, and apologize for this intrusion... > > _KMP > > From mansaxel at besserwisser.org Thu Jun 27 19:43:19 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 27 Jun 2013 21:43:19 +0200 Subject: SixXS Contact In-Reply-To: <51CC5097.8030504@one.verizon.com> References: <51CC5097.8030504@one.verizon.com> Message-ID: <20130627194319.GN9807@besserwisser.org> Subject: Re: SixXS Contact Date: Thu, Jun 27, 2013 at 10:47:51AM -0400 Quoting Anthony Williams (alby.williams at verizon.com): > > > > Can I piggy back on that inquiry and request a reset of my ISK points > after committing a faux pas with respect to going negative from down v6 > tunnels and deleting. Now to create a new tunnel I need positive ISK > points and I'm stilling at -10 with no way to boost my numbers. :( > > Reset Points: AWJ11-SIXXS Oh Pretty please w/sugar on top. :) Personally, even though I'm on the same IRC channel as one of the admins and could have all support I want, I went with HE. Zero trouble. Excellent service. I'm peering with them at work, as does my colo provider, s? have great connectivity. And, in v6, renumbering is easy (RIGHT? ;) so swapping providers is no pain. Now, Owen, where's my T-shirt? ;-) -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 If Robert Di Niro assassinates Walter Slezak, will Jodie Foster marry Bonzo?? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From trelane at trelane.net Thu Jun 27 20:00:21 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 27 Jun 2013 16:00:21 -0400 Subject: SixXS Contact In-Reply-To: <20130627194319.GN9807@besserwisser.org> References: <51CC5097.8030504@one.verizon.com> <20130627194319.GN9807@besserwisser.org> Message-ID: <51CC99D5.4020103@trelane.net> On 6/27/2013 3:43 PM, M?ns Nilsson wrote: > Subject: Re: SixXS Contact Date: Thu, Jun 27, 2013 at 10:47:51AM -0400 Quoting Anthony Williams (alby.williams at verizon.com): >> >> >> Can I piggy back on that inquiry and request a reset of my ISK points >> after committing a faux pas with respect to going negative from down v6 >> tunnels and deleting. Now to create a new tunnel I need positive ISK >> points and I'm stilling at -10 with no way to boost my numbers. :( >> >> Reset Points: AWJ11-SIXXS Oh Pretty please w/sugar on top. :) > Personally, even though I'm on the same IRC channel as one of the admins > and could have all support I want, I went with HE. Zero trouble. Excellent > service. I'm peering with them at work, as does my colo provider, s? > have great connectivity. > > And, in v6, renumbering is easy (RIGHT? ;) so swapping providers is > no pain. > > Now, Owen, where's my T-shirt? ;-) > Yes it's a private service, yes it's run by volunteers, BUT SIXXS is publicly putting themselves forward as ambassadors for IPv6. "The main target is to create a common portal to help company engineers find their way with IPv6 networks deploying IPv6 to their customers in a rapid and controllable fashion." (Sixxs website) and "For whom? For everybody. The average joe and jane can use AICCU so that they can use IPv6 very quick and easy." (SIXXS website "about us"). I'm neither Joe nor Jane, nor am I Tom, Dick, or Harry, and quite frankly SIXXS has been abrasive and abusive in my attempt to use their service. Their stewardship of IPv6 is quite frankly horrible. When people on NANOG are complaining about lack of response, SIXXS responds with silence or "we're a volunteer group". I was told to go screw myself because I'd had a work account years ago and tried to set up a personal one not even realizing the work account was still active (totally allowed by their TOS), my account was still canceled, and three weeks later Jeroen essentially told me I could go screw myself. I'm the community manager at Zenoss and I'd get fired for treating my users like that. I think it's _LONG_ past time we started asking "how severely has SIXXS's negative behavior slowed the adoption of IPv6?", and "is this behavior acceptable?" For me, their service is long past worse than no service at all. Andrew From owen at delong.com Fri Jun 28 01:26:35 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Jun 2013 20:26:35 -0500 Subject: Paetec PI space? In-Reply-To: <57726.1372282826@turing-police.cc.vt.edu> References: <009801ce7295$ef992dd0$cecb8970$@webjogger.net> <57726.1372282826@turing-police.cc.vt.edu> Message-ID: <78BBCCE6-5B14-482E-8817-B0FC87296637@delong.com> On Jun 26, 2013, at 4:40 PM, valdis.kletnieks at vt.edu wrote: > On Wed, 26 Jun 2013 14:06:10 -0400, "Justin M. Streiner" said: >>> We have a customer who was assigned some PI IPv4 space by Paetec back in >>> mid-90's and who has continued to announce the blocks, even though their >>> relationship with Paetec ended a long time ago. >>> >>> Is this a common situation? Does the customer risk having that space >>> reclaimed by Paetec at some point, or is it safe to assume they will >>> continue to be able to route trouble-free for years to come? >> >> They should plan to renumber out of that space in the very near future. > > This is an excellent time to plan to renumber into 2001:: if they haven't > such plans already. :) Well, somewhere in 2000::/3, anyway? It might be somewhere within any of the following blocks: 2001:400::/23, 2001:1800::/23, 2001:4800::/23, 2600::/12, or 2610::/23, 2620::/23. All of which have been delegated to ARIN by IANA. As to the PI/PA question? There were PI blocks issued by LIRs (ISPs) in the years after the initial implementation of CIDR and before (and possibly for some time after) the creation of ARIN. My blocks 192.159.10.0/24 and 192.124.40.0/23 are examples of such blocks which were originally issued to me by Netcom and PSI, respectively. They are now correctly documented as "Direct Assignments" in the ARIN database and covered by LRSA (which I now regret given the recent fee restructuring). Owen From markjr at easydns.com Fri Jun 28 03:00:31 2013 From: markjr at easydns.com (Mark Jeftovic) Date: Thu, 27 Jun 2013 23:00:31 -0400 Subject: DNSResolvers.com will be shutdown Message-ID: <51CCFC4F.5000508@easydns.com> As per our post: http://blog.easydns.org/2013/06/27/dnsresolvers-open-resolvers-will-be-shut-down/ The DNSResolvers.com free and open public resolvers will be shut down, imminently (like tonight, if we get DDoS-ed against them again). We'll keep them up for awhile if we can so everybody can migrate off, but if you or somebody you care about is using them, please make other arrangements as fast as possible. thankyouverymuch - mark -- Mark Jeftovic Founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com From LarrySheldon at cox.net Fri Jun 28 03:51:51 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 Jun 2013 22:51:51 -0500 Subject: DNSResolvers.com will be shutdown In-Reply-To: References: Message-ID: <51CD0857.6020806@cox.net> On 6/27/2013 10:00 PM, Mark Jeftovic wrote: > > As per our post: > > http://blog.easydns.org/2013/06/27/dnsresolvers-open-resolvers-will-be-shut-down/ > > The DNSResolvers.com free and open public resolvers will be shut down, > imminently (like tonight, if we get DDoS-ed against them again). > > We'll keep them up for awhile if we can so everybody can migrate off, > but if you or somebody you care about is using them, please make other > arrangements as fast as possible. It will be interesting to see how people "didn't know we were using them". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mike-nanog at tiedyenetworks.com Fri Jun 28 04:07:45 2013 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 27 Jun 2013 21:07:45 -0700 Subject: Service provider T1/PPP question Message-ID: <51CD0C11.8010204@tiedyenetworks.com> Hi Gang, This question isn't strictly operational, but I'm needing a little coaching. I am wanting to offer a broadband over T1 service and have the infrastructure in place for aggregation of many of these over channelized DS3. My desire is to simplify administration and require PPP / chap authentication, and allow ppp and ppp multilink with the minimum configuration on my side necessary, I'm thinking there could be a 'one size fits all' setup on my side. I'd love to connect with anyone providing a similar service in a cisco environment to compare notes and bounce ideas off of. Thanks. Mike- From mansaxel at besserwisser.org Fri Jun 28 11:48:46 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 28 Jun 2013 13:48:46 +0200 Subject: SixXS Contact In-Reply-To: <20130627194319.GN9807@besserwisser.org> References: <51CC5097.8030504@one.verizon.com> <20130627194319.GN9807@besserwisser.org> Message-ID: <20130628114846.GP9807@besserwisser.org> Subject: Re: SixXS Contact Date: Thu, Jun 27, 2013 at 09:43:19PM +0200 Quoting M?ns Nilsson (mansaxel at besserwisser.org): > Personally, even though I'm on the same IRC channel as one of the admins > and could have all support I want, I went with HE. Zero trouble. Excellent > service. I'm peering with them at work, as does my colo provider, s? > have great connectivity. > > And, in v6, renumbering is easy (RIGHT? ;) so swapping providers is > no pain. > > Now, Owen, where's my T-shirt? ;-) Apparently I'm not on the same IRC channel as an admin anymore: "Just let me state that the day after I quit working with SIXXS I got myself a HE tunnel" -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cscora at apnic.net Fri Jun 28 18:33:24 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Jun 2013 04:33:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201306281833.r5SIXO8G009566@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Jun, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 456943 Prefixes after maximum aggregation: 186069 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 227072 Total ASes present in the Internet Routing Table: 44373 Prefixes per ASN: 10.30 Origin-only ASes present in the Internet Routing Table: 34730 Origin ASes announcing only one prefix: 16155 Transit ASes present in the Internet Routing Table: 5896 Transit-only ASes present in the Internet Routing Table: 144 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 1668 Unregistered ASNs in the Routing Table: 758 Number of 32-bit ASNs allocated by the RIRs: 4834 Number of 32-bit ASNs visible in the Routing Table: 3747 Prefixes from 32-bit ASNs in the Routing Table: 10990 Special use prefixes present in the Routing Table: 24 Prefixes being announced from unallocated address space: 215 Number of addresses announced to Internet: 2625956140 Equivalent to 156 /8s, 132 /16s and 233 /24s Percentage of available address space announced: 70.9 Percentage of allocated address space announced: 70.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.7 Total number of prefixes smaller than registry allocations: 160087 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109760 Total APNIC prefixes after maximum aggregation: 33678 APNIC Deaggregation factor: 3.26 Prefixes being announced from the APNIC address blocks: 111592 Unique aggregates announced from the APNIC address blocks: 45689 APNIC Region origin ASes present in the Internet Routing Table: 4852 APNIC Prefixes per ASN: 23.00 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 823 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 589 Number of APNIC addresses announced to Internet: 725314528 Equivalent to 43 /8s, 59 /16s and 107 /24s Percentage of available APNIC address space announced: 84.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 158854 Total ARIN prefixes after maximum aggregation: 80348 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 159485 Unique aggregates announced from the ARIN address blocks: 74154 ARIN Region origin ASes present in the Internet Routing Table: 15753 ARIN Prefixes per ASN: 10.12 ARIN Region origin ASes announcing only one prefix: 6003 ARIN Region transit ASes present in the Internet Routing Table: 1651 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1064983360 Equivalent to 63 /8s, 122 /16s and 91 /24s Percentage of available ARIN address space announced: 56.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 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 117660 Total RIPE prefixes after maximum aggregation: 60170 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 121071 Unique aggregates announced from the RIPE address blocks: 78453 RIPE Region origin ASes present in the Internet Routing Table: 17243 RIPE Prefixes per ASN: 7.02 RIPE Region origin ASes announcing only one prefix: 8167 RIPE Region transit ASes present in the Internet Routing Table: 2836 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2368 Number of RIPE addresses announced to Internet: 656543076 Equivalent to 39 /8s, 34 /16s and 13 /24s Percentage of available RIPE address space announced: 95.4 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-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 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, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 48506 Total LACNIC prefixes after maximum aggregation: 9325 LACNIC Deaggregation factor: 5.20 Prefixes being announced from the LACNIC address blocks: 52873 Unique aggregates announced from the LACNIC address blocks: 24612 LACNIC Region origin ASes present in the Internet Routing Table: 1966 LACNIC Prefixes per ASN: 26.89 LACNIC Region origin ASes announcing only one prefix: 584 LACNIC Region transit ASes present in the Internet Routing Table: 361 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 765 Number of LACNIC addresses announced to Internet: 132564904 Equivalent to 7 /8s, 230 /16s and 199 /24s Percentage of available LACNIC address space announced: 79.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11084 Total AfriNIC prefixes after maximum aggregation: 2507 AfriNIC Deaggregation factor: 4.42 Prefixes being announced from the AfriNIC address blocks: 11707 Unique aggregates announced from the AfriNIC address blocks: 3966 AfriNIC Region origin ASes present in the Internet Routing Table: 640 AfriNIC Prefixes per ASN: 18.29 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 135 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46262016 Equivalent to 2 /8s, 193 /16s and 231 /24s Percentage of available AfriNIC address space announced: 46.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2930 11561 922 Korea Telecom (KIX) 17974 2562 855 92 PT TELEKOMUNIKASI INDONESIA 7545 2016 320 109 TPG Internet Pty Ltd 4755 1750 391 192 TATA Communications formerly 9829 1519 1205 40 BSNL National Internet Backbo 9583 1291 98 536 Sify Limited 4808 1148 2124 335 CNCGROUP IP network: China169 9498 1144 309 71 BHARTI Airtel Ltd. 7552 1131 1080 13 Vietel Corporation 24560 1080 394 164 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2991 3691 70 bellsouth.net, inc. 18566 2064 382 184 Covad Communications 1785 1995 678 126 PaeTec Communications, Inc. 22773 1986 2927 123 Cox Communications, Inc. 20115 1665 1617 617 Charter Communications 4323 1622 1138 402 Time Warner Telecom 701 1533 11127 800 UUNET Technologies, Inc. 30036 1334 299 646 Mediacom Communications Corp 7018 1304 11040 827 AT&T WorldNet Services 11492 1221 217 360 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1661 544 16 Corbina telecom 34984 1284 244 221 BILISIM TELEKOM 2118 1085 97 13 EUnet/RELCOM Autonomous Syste 20940 911 320 713 Akamai Technologies European 13188 825 98 79 Educational Network 31148 806 40 25 FreeNet ISP 8551 776 370 44 Bezeq International 6830 766 2376 440 UPC Distribution Services 12479 673 789 57 Uni2 Autonomous System 34744 658 171 76 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2884 1570 105 NET Servicos de Comunicao S.A 10620 2676 420 200 TVCABLE BOGOTA 7303 1731 1155 220 Telecom Argentina Stet-France 8151 1263 2725 388 UniNet S.A. de C.V. 18881 1064 844 20 Global Village Telecom 6503 869 434 63 AVANTEL, S.A. 27947 818 94 93 Telconet S.A 3816 717 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 616 88 65 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1237 80 4 MOBITEL 24863 884 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 469 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 259 922 218 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 29571 215 17 12 Ci Telecom Autonomous system 37054 211 11 5 Data Telecom Service 36992 201 527 21 Etisalat MISR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2991 3691 70 bellsouth.net, inc. 4766 2930 11561 922 Korea Telecom (KIX) 28573 2884 1570 105 NET Servicos de Comunicao S.A 10620 2676 420 200 TVCABLE BOGOTA 17974 2562 855 92 PT TELEKOMUNIKASI INDONESIA 18566 2064 382 184 Covad Communications 7545 2016 320 109 TPG Internet Pty Ltd 1785 1995 678 126 PaeTec Communications, Inc. 22773 1986 2927 123 Cox Communications, Inc. 4755 1750 391 192 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2884 2779 NET Servicos de Comunicao S.A 10620 2676 2476 TVCABLE BOGOTA 17974 2562 2470 PT TELEKOMUNIKASI INDONESIA 4766 2930 2008 Korea Telecom (KIX) 7545 2016 1907 TPG Internet Pty Ltd 18566 2064 1880 Covad Communications 1785 1995 1869 PaeTec Communications, Inc. 22773 1986 1863 Cox Communications, Inc. 8402 1661 1645 Corbina telecom 4755 1750 1558 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.57.0/24 60993 Totalsoft SA 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:16 /9:11 /10:30 /11:91 /12:250 /13:483 /14:899 /15:1604 /16:12705 /17:6643 /18:11108 /19:22442 /20:32070 /21:34509 /22:48005 /23:42295 /24:239833 /25:1305 /26:1639 /27:861 /28:45 /29:65 /30:19 /31:0 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2015 2064 Covad Communications 6389 1717 2991 bellsouth.net, inc. 8402 1356 1661 Corbina telecom 22773 1293 1986 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1202 1334 Mediacom Communications Corp 11492 1183 1221 Cable One 1785 1063 1995 PaeTec Communications, Inc. 6983 1015 1145 ITC^Deltacom 10620 996 2676 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:838 2:808 3:3 4:19 5:813 6:16 8:563 12:1914 13:3 14:856 15:11 16:3 17:10 20:17 23:293 24:1769 27:1495 31:1249 32:43 33:2 34:5 36:47 37:1872 38:875 39:2 40:170 41:2829 42:203 44:8 46:1913 47:1 49:660 50:753 52:12 54:35 55:5 57:26 58:1159 59:576 60:323 61:1404 62:1120 63:2026 64:4334 65:2156 66:4179 67:2043 68:1079 69:3274 70:835 71:496 72:1925 74:2459 75:323 76:302 77:1113 78:1061 79:624 80:1271 81:1016 82:623 83:594 84:585 85:1181 86:457 87:1011 88:538 89:1767 90:148 91:5535 92:609 93:1744 94:1875 95:1644 96:524 97:345 98:1015 99:42 100:30 101:332 103:2872 105:519 106:142 107:207 108:510 109:1835 110:909 111:1062 112:545 113:819 114:698 115:968 116:962 117:800 118:1106 119:1319 120:389 121:733 122:1799 123:1222 124:1376 125:1384 128:637 129:225 130:308 131:662 132:359 133:155 134:268 135:68 136:223 137:242 138:341 139:190 140:209 141:328 142:538 143:380 144:500 145:94 146:504 147:384 148:664 149:348 150:157 151:518 152:420 153:189 154:24 155:417 156:270 157:399 158:279 159:717 160:345 161:455 162:463 163:222 164:604 165:498 166:251 167:596 168:1045 169:129 170:1054 171:178 172:21 173:1584 174:544 175:472 176:988 177:2101 178:1856 179:51 180:1456 181:478 182:1250 183:390 184:666 185:574 186:2230 187:1272 188:2055 189:1281 190:6716 192:6761 193:5678 194:4612 195:3457 196:1374 197:989 198:4499 199:5348 200:5998 201:2206 202:8789 203:8896 204:4505 205:2550 206:2797 207:2844 208:4036 209:3629 210:2918 211:1516 212:2165 213:1974 214:916 215:99 216:5234 217:1625 218:615 219:336 220:1282 221:557 222:325 223:447 End of report From jra at baylink.com Fri Jun 28 19:39:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Jun 2013 15:39:30 -0400 (EDT) Subject: We Are Watching You act to regulate consumer-watching devices. Message-ID: <15281159.260.1372448370525.JavaMail.root@benjamin.baylink.com> About 30 years ago, when I first got involved with the Net (Usenet; thanks to USF and Spaf for the link, and Larry Strickland at SPJC for servers), one of the topics that everyone loved to rant about were supposed plans from the Neilsen Companies to put cameras on set top boxes and use them to get better data about how many people were watching TV. There was the expected public meltdown, as the word got 'round -- even given how impractical it would have been to implement with that day's tech -- and I was, frankly surprised that it didn't recur when Microsoft started putting cameras atop videogame consoles, in our much better connected world. In light of the Snowden fracas, it has now, finally, recurred: http://broadcastengineering.com/regulation/we-are-watching-you-act-introduced-regulate-privacy-home This is another example, I think, of a thing that only a very small number of people have thought proactively about over the years, but that I think network engineering people ought to be at the forefront of that group: I call it capability creep, by analogy to scope creep; it's the situation where because of changes in technologies only peripherally related to your own, yours suddenly acquires previously unexpected capabilities, for either good or evil. Ours -- high speed, pervasive, networking -- is probably the most common enabling technology which has this effect, and while we can't exactly just shut the routers off and go home, and while people spend a whole lot of time ignoring us on such topics (I can't count the toldjaso's from the last 3 decades), I still think it's a topic we ought to focus purposeful thinking on as we go about our lives of planning and executing the next generation of networks. And the next. And the next. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfbeam at gmail.com Fri Jun 28 19:45:02 2013 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 28 Jun 2013 15:45:02 -0400 Subject: Service provider T1/PPP question In-Reply-To: <51CD0C11.8010204@tiedyenetworks.com> References: <51CD0C11.8010204@tiedyenetworks.com> Message-ID: On Fri, 28 Jun 2013 00:07:45 -0400, Mike wrote: > I am wanting to offer a broadband over T1 service and have the ... s/broadband/internet/ A T1 is miles away from "broadband" these days. Having done this with Cisco gear (*years* ago), you want to avoid MLPPP whenever possible. We did CEF per-packet when the CPE end was also Cisco; it worked perfectly with none of the restrictions or bugs. --Ricky From SNaslund at medline.com Fri Jun 28 19:56:57 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 28 Jun 2013 19:56:57 +0000 Subject: Service provider T1/PPP question In-Reply-To: References: <51CD0C11.8010204@tiedyenetworks.com> Message-ID: <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> -----Original Message----- From: Ricky Beam [mailto:jfbeam at gmail.com] Sent: Friday, June 28, 2013 2:45 PM To: NANOG list; Mike Subject: Re: Service provider T1/PPP question On Fri, 28 Jun 2013 00:07:45 -0400, Mike wrote: >> I am wanting to offer a broadband over T1 service and have the ... >s/broadband/internet/ >A T1 is miles away from "broadband" these days. >Having done this with Cisco gear (*years* ago), you want to avoid MLPPP whenever possible. We did CEF per-packet when the CPE end was also Cisco; it worked perfectly with none of the restrictions or bugs. >--Ricky I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? Steven Naslund From mike at mtcc.com Fri Jun 28 20:09:43 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 28 Jun 2013 13:09:43 -0700 Subject: Google's QUIC Message-ID: <51CDED87.6050503@mtcc.com> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. The second justification was TLS layering inefficiencies. That definitely has my sympathies as TLS (especially cert exchange) is bloated and the way that it was grafted onto TCP wasn't exactly the most elegant. Interestingly enough, their main justification wasn't a security concern so much as "helpful" middle boxen getting their filthy mitts on the traffic and screwing it up. The last thing that occurs to me reading their FAQ is that they are seemingly trying to send data with 0 round trips. That is, SYN, data, data, data... That really makes me wonder about security/dos considerations. As in, it sounds too good to be true. But maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. Other comments or clue? Mike From josh.hoppes at gmail.com Fri Jun 28 20:16:16 2013 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Fri, 28 Jun 2013 15:16:16 -0500 Subject: Google's QUIC In-Reply-To: <51CDED87.6050503@mtcc.com> References: <51CDED87.6050503@mtcc.com> Message-ID: My first question is, how are they going to keep themselves from congesting links? On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas wrote: > http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 > > Sorry if this is a little more on the dev side, and less on the ops side but > since > it's Google, it will almost certainly affect the ops side eventually. > > My first reaction to this was why not SCTP, but apparently they think that > middle > boxen/firewalls make it problematic. That may be, but UDP based port > filtering is > probably not far behind on the flaky front. > > The second justification was TLS layering inefficiencies. That definitely > has my > sympathies as TLS (especially cert exchange) is bloated and the way that it > was > grafted onto TCP wasn't exactly the most elegant. Interestingly enough, > their > main justification wasn't a security concern so much as "helpful" middle > boxen > getting their filthy mitts on the traffic and screwing it up. > > The last thing that occurs to me reading their FAQ is that they are > seemingly trying > to send data with 0 round trips. That is, SYN, data, data, data... That > really makes me > wonder about security/dos considerations. As in, it sounds too good to be > true. But > maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. > > Other comments or clue? > > Mike > From mike at mtcc.com Fri Jun 28 20:23:53 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 28 Jun 2013 13:23:53 -0700 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: <51CDF0D9.4060409@mtcc.com> On 06/28/2013 01:16 PM, Josh Hoppes wrote: > My first question is, how are they going to keep themselves from > congesting links? The FAQ claims they're paying attention to that, but I haven't read the details. I sure hope they grok that not understanding Van Jacobson dooms you to repeat it. https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#heading=h.h3jsxme7rovm Mike > > On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas wrote: >> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 >> >> Sorry if this is a little more on the dev side, and less on the ops side but >> since >> it's Google, it will almost certainly affect the ops side eventually. >> >> My first reaction to this was why not SCTP, but apparently they think that >> middle >> boxen/firewalls make it problematic. That may be, but UDP based port >> filtering is >> probably not far behind on the flaky front. >> >> The second justification was TLS layering inefficiencies. That definitely >> has my >> sympathies as TLS (especially cert exchange) is bloated and the way that it >> was >> grafted onto TCP wasn't exactly the most elegant. Interestingly enough, >> their >> main justification wasn't a security concern so much as "helpful" middle >> boxen >> getting their filthy mitts on the traffic and screwing it up. >> >> The last thing that occurs to me reading their FAQ is that they are >> seemingly trying >> to send data with 0 round trips. That is, SYN, data, data, data... That >> really makes me >> wonder about security/dos considerations. As in, it sounds too good to be >> true. But >> maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. >> >> Other comments or clue? >> >> Mike >> From alvarezp at alvarezp.ods.org Fri Jun 28 20:26:10 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 28 Jun 2013 13:26:10 -0700 Subject: Google's QUIC In-Reply-To: <51CDED87.6050503@mtcc.com> References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas wrote: > http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 > > Sorry if this is a little more on the dev side, and less on the ops side > but since > it's Google, it will almost certainly affect the ops side eventually. > > My first reaction to this was why not SCTP, but apparently they think > that middle > boxen/firewalls make it problematic. That may be, but UDP based port > filtering is > probably not far behind on the flaky front. Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. My reaction is: why, oh why, repeat the same mistake of merging everything on the transport layer and let the benefits be protocol-specific instead of separating the "transport" from "session". I mean, why not let redundancy and multipath stay on the transport layer through some kind of end-user transport (like the Host Identification Protocol, RFC 5201) and let a simpler TCP and UDP live on top of that, on the session layer. Streamline the protocols and separate their functionality. It's easier than it sounds. -- Octavio. From morrowc.lists at gmail.com Fri Jun 28 20:39:04 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jun 2013 16:39:04 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez wrote: > On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas wrote: > >> >> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 > > Sounds like a UDP replacement. If this is true, then OS-level support will > be needed. If they are on this, then it's the perfect opportunity to fix > some other problems with the Internet in general. I'm no genius, but doesn't the article say it's UDP? (in the name of the protocol even) -chris From alvarezp at alvarezp.ods.org Fri Jun 28 20:48:48 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 28 Jun 2013 13:48:48 -0700 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow wrote: > On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez > wrote: >> >> Sounds like a UDP replacement. If this is true, then OS-level support >> will >> be needed. If they are on this, then it's the perfect opportunity to fix >> some other problems with the Internet in general. > > I'm no genius, but doesn't the article say it's UDP? (in the name of > the protocol even) I was trying to emphasize "replacement", not UDP. This is, that works on the same layer, that requires OS-level modifications, as opposed to a protocol that could be similar to UDP but work on the application layer. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing table), and have streamlined TCP and UDP that takes advantage of the new protocol. Everyone's calling upon SCTP. Implementing similar techniques on multiple transport protocols calls for a transport-session separation. -- Octavio. From philfagan at gmail.com Fri Jun 28 20:49:08 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 28 Jun 2013 14:49:08 -0600 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: "In the presence of layer-3 load-balancers, a multiplexed transport has the potential to allow the different data flows, coming and going to a client, to be served on a single server." - Google I'll drink the juice On Fri, Jun 28, 2013 at 2:39 PM, Christopher Morrow wrote: > On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez > wrote: > > On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas > wrote: > > > >> > >> > http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 > > > > > Sounds like a UDP replacement. If this is true, then OS-level support > will > > be needed. If they are on this, then it's the perfect opportunity to fix > > some other problems with the Internet in general. > > I'm no genius, but doesn't the article say it's UDP? (in the name of > the protocol even) > > -chris > > -- Phil Fagan Denver, CO 970-480-7618 From achatz at forthnetgroup.gr Fri Jun 28 20:57:32 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Fri, 28 Jun 2013 23:57:32 +0300 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: <51CDF8BC.5010303@forthnetgroup.gr> The idea reminds me of uTP in terms of congestion handling. -- Tassos Josh Hoppes wrote on 28/6/2013 23:16: > My first question is, how are they going to keep themselves from > congesting links? > > On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas wrote: >> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 >> >> Sorry if this is a little more on the dev side, and less on the ops side but >> since >> it's Google, it will almost certainly affect the ops side eventually. >> >> My first reaction to this was why not SCTP, but apparently they think that >> middle >> boxen/firewalls make it problematic. That may be, but UDP based port >> filtering is >> probably not far behind on the flaky front. >> >> The second justification was TLS layering inefficiencies. That definitely >> has my >> sympathies as TLS (especially cert exchange) is bloated and the way that it >> was >> grafted onto TCP wasn't exactly the most elegant. Interestingly enough, >> their >> main justification wasn't a security concern so much as "helpful" middle >> boxen >> getting their filthy mitts on the traffic and screwing it up. >> >> The last thing that occurs to me reading their FAQ is that they are >> seemingly trying >> to send data with 0 round trips. That is, SYN, data, data, data... That >> really makes me >> wonder about security/dos considerations. As in, it sounds too good to be >> true. But >> maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm. >> >> Other comments or clue? >> >> Mike >> > From morrowc.lists at gmail.com Fri Jun 28 20:57:48 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jun 2013 16:57:48 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, Jun 28, 2013 at 4:48 PM, Octavio Alvarez wrote: > On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow > wrote: > >> On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez >> wrote: >>> >>> >>> Sounds like a UDP replacement. If this is true, then OS-level support >>> will >>> be needed. If they are on this, then it's the perfect opportunity to fix >>> some other problems with the Internet in general. >> >> >> I'm no genius, but doesn't the article say it's UDP? (in the name of >> the protocol even) > > > I was trying to emphasize "replacement", not UDP. This is, that works on > the same layer, that requires OS-level modifications, as opposed to a again... not a super smart on this stuff, but.. why does it require OS modifications? isn't this just going be 'chrome' (or 'other application') asking for a udp socket and spewing line-rate-foo out of that? isn't the application going to be doing all of the multiplexing and jankiness? > protocol that could be similar to UDP but work on the application layer. it's not 'similar to UDP', it is in fact UDP, from what I read in the article. > My point was that all that work could be focused on a *really* good > transport (even with end-user multihoming without bloating the routing how's that sctp going for you? lisp? sham6? > table), and have streamlined TCP and UDP that takes advantage of the new > protocol. sure, ilnp? > Everyone's calling upon SCTP. Implementing similar techniques on multiple > transport protocols calls for a transport-session separation. right, and the 1 application using sctp is so wide spread we've all heard of it even. possibly this will be a similar diversion into protocol/application testing even. -chris From morrowc.lists at gmail.com Fri Jun 28 21:00:08 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jun 2013 17:00:08 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan wrote: > "In the presence of layer-3 load-balancers, a multiplexed transport has the > potential to allow the different data flows, coming and going to a client, > to be served on a single server." - Google > > I'll drink the juice i don't think much juice is required... doesn't that just say that the same 'flow' will follow the same path through the network? and that most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at best)? so keeping things in a single flow/stream/5-tuple will drop packets from one host deterministicaly on a single other host at the far side? From philfagan at gmail.com Fri Jun 28 21:02:47 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 28 Jun 2013 15:02:47 -0600 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: I took that as path agnostic. On Fri, Jun 28, 2013 at 3:00 PM, Christopher Morrow wrote: > On Fri, Jun 28, 2013 at 4:49 PM, Phil Fagan wrote: > > "In the presence of layer-3 load-balancers, a multiplexed transport has > the > > potential to allow the different data flows, coming and going to a > client, > > to be served on a single server." - Google > > > > I'll drink the juice > > i don't think much juice is required... doesn't that just say that the > same 'flow' will follow the same path through the network? and that > most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at > best)? so keeping things in a single flow/stream/5-tuple will drop > packets from one host deterministicaly on a single other host at the > far side? > -- Phil Fagan Denver, CO 970-480-7618 From jra at baylink.com Fri Jun 28 21:07:28 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Jun 2013 17:07:28 -0400 (EDT) Subject: Google's QUIC In-Reply-To: <51CDED87.6050503@mtcc.com> Message-ID: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > My first reaction to this was why not SCTP, but apparently they think Simple Computer Telephony Protocol? Did anyone ever actually implement that? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mike at mtcc.com Fri Jun 28 21:15:33 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 28 Jun 2013 14:15:33 -0700 Subject: Google's QUIC In-Reply-To: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> References: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> Message-ID: <51CDFCF5.8000204@mtcc.com> On 06/28/2013 02:07 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Michael Thomas" >> My first reaction to this was why not SCTP, but apparently they think > Simple Computer Telephony Protocol? Did anyone ever actually implement that? No: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol *Mike* From surfer at mauigateway.com Fri Jun 28 21:19:17 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 28 Jun 2013 14:19:17 -0700 Subject: Google's QUIC Message-ID: <20130628141917.D48320B8@m0005296.ppops.net> --- mike at mtcc.com wrote: From: Michael Thomas On 06/28/2013 02:07 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Michael Thomas" >> My first reaction to this was why not SCTP, but apparently they think > Simple Computer Telephony Protocol? Did anyone ever actually implement that? No: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol --------------------------------------------------- C'mon Jay! Get with the plan! >;-) scott From joelja at bogus.com Fri Jun 28 21:28:39 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 28 Jun 2013 14:28:39 -0700 Subject: Google's QUIC In-Reply-To: <51CDFCF5.8000204@mtcc.com> References: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> <51CDFCF5.8000204@mtcc.com> Message-ID: <51CE0007.5050300@bogus.com> On 6/28/13 2:15 PM, Michael Thomas wrote: > On 06/28/2013 02:07 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Michael Thomas" >>> My first reaction to this was why not SCTP, but apparently they think >> Simple Computer Telephony Protocol? Did anyone ever actually >> implement that? > > No: > > > http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol > SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think. > > *Mike* > > From Valdis.Kletnieks at vt.edu Fri Jun 28 21:38:40 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 28 Jun 2013 17:38:40 -0400 Subject: Google's QUIC In-Reply-To: Your message of "Fri, 28 Jun 2013 14:28:39 -0700." <51CE0007.5050300@bogus.com> References: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> <51CDFCF5.8000204@mtcc.com> <51CE0007.5050300@bogus.com> Message-ID: <206144.1372455520@turing-police.cc.vt.edu> On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said: > SCTP is used successfully for the purpose for which it was intended, > which is connecting SS7 switches over IP. It's not as much a posterchild > for an application agnostic transport as some people would like to think. OK, I'll bite... does anything else notable actually use it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mike at mtcc.com Fri Jun 28 21:40:30 2013 From: mike at mtcc.com (Michael Thomas) Date: Fri, 28 Jun 2013 14:40:30 -0700 Subject: Google's QUIC In-Reply-To: <51CE0007.5050300@bogus.com> References: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> <51CDFCF5.8000204@mtcc.com> <51CE0007.5050300@bogus.com> Message-ID: <51CE02CE.3000208@mtcc.com> On 06/28/2013 02:28 PM, joel jaeggli wrote: > On 6/28/13 2:15 PM, Michael Thomas wrote: >> On 06/28/2013 02:07 PM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Michael Thomas" >>>> My first reaction to this was why not SCTP, but apparently they think >>> Simple Computer Telephony Protocol? Did anyone ever actually implement that? >> >> No: >> >> >> http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol >> > SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think. Well, I'm pretty sure that Randy Stewart has a more expansive take on SCTP than SS7oIP, but I get the impression that there just weren't enough other things that cared about head of line blocking. But now, 15 years later, it seems like maybe there is. In any case, if what you're worried about is head of line blocking, SCTP definitely does that, and there are kernel implementations so for an *experiment* it seems like you could get a long way by ignoring its warts. But I think the most provocative thing is the idea of sending data payloads prior to handshake. That sort of scares me because of the potential for an amplification attack. But I haven't actually read the protocol paper itself. Mike From cidr-report at potaroo.net Fri Jun 28 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jun 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201306282200.r5SM00xA041310@wattle.apnic.net> This report has been generated at Fri Jun 28 21:13:56 2013 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 21-06-13 457753 260974 22-06-13 458159 261160 23-06-13 458638 261324 24-06-13 458895 261148 25-06-13 458130 265776 26-06-13 466890 265811 27-06-13 467134 265159 28-06-13 467649 265318 AS Summary 44524 Number of ASes in routing system 18376 Number of ASes announcing only one prefix 4237 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 116932576 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 28Jun13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 467629 265381 202248 43.2% All ASes AS6389 2991 74 2917 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2902 105 2797 96.4% NET Servi?os de Comunica??o S.A. AS7029 4237 2108 2129 50.2% WINDSTREAM - Windstream Communications Inc AS17974 2561 525 2036 79.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2930 936 1994 68.1% KIXS-AS-KR Korea Telecom AS10620 2677 848 1829 68.3% Telmex Colombia S.A. AS22773 1986 170 1816 91.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2064 474 1590 77.0% COVAD - Covad Communications Co. AS4323 2979 1522 1457 48.9% TWTC - tw telecom holdings, inc. AS7303 1731 453 1278 73.8% Telecom Argentina S.A. AS7545 2021 750 1271 62.9% TPG-INTERNET-AP TPG Telecom Limited AS4755 1748 585 1163 66.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18881 1069 44 1025 95.9% Global Village Telecom AS7552 1159 142 1017 87.7% VIETEL-AS-AP Vietel Corporation AS2118 1085 86 999 92.1% RELCOM-AS OOO "NPO Relcom" AS36998 1237 301 936 75.7% SDN-MOBITEL AS1785 1995 1152 843 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 1002 182 820 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS33363 2021 1241 780 38.6% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS4808 1148 393 755 65.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1533 803 730 47.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 845 138 707 83.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS22561 1193 517 676 56.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS855 728 54 674 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1145 478 667 58.3% ITCDELTA - ITC^Deltacom AS8151 1266 602 664 52.4% Uninet S.A. de C.V. AS24560 1080 417 663 61.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 735 112 623 84.8% GIGAINFRA Softbank BB Corp. AS8402 1647 1051 596 36.2% CORBINA-AS OJSC "Vimpelcom" AS31148 803 208 595 74.1% FREENET-AS Freenet Ltd. Total 52518 16471 36047 68.6% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 115.31.64.0/20 AS17639 COMCLARK-AS ComClark Network & Technology Corp. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 194.169.237.0/24 AS12968 CDP Netia SA 195.248.240.0/23 AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jun 28 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Jun 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201306282200.r5SM01Vm041325@wattle.apnic.net> BGP Update Report Interval: 20-Jun-13 -to- 27-Jun-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35819 44046 2.2% 93.7 -- MOBILY-AS Etihad Etisalat Company (Mobily) 2 - AS47331 34189 1.7% 16.1 -- TTNET TTNet A.S. 3 - AS8402 31907 1.6% 25.4 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 30085 1.5% 31.9 -- BSNL-NIB National Internet Backbone 5 - AS27738 26279 1.3% 45.9 -- Ecuadortelecom S.A. 6 - AS7552 23804 1.2% 15.9 -- VIETEL-AS-AP Vietel Corporation 7 - AS4538 22791 1.1% 43.7 -- ERX-CERNET-BKB China Education and Research Network Center 8 - AS17974 22234 1.1% 8.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS9583 21563 1.1% 16.7 -- SIFY-AS-IN Sify Limited 10 - AS9416 17229 0.8% 297.1 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - AS6713 14767 0.7% 27.2 -- IAM-AS 12 - AS37004 13691 0.7% 652.0 -- SUBURBAN-AS 13 - AS60974 13041 0.7% 255.7 -- NAICOMS Naicoms EOOD 14 - AS12252 11023 0.6% 73.5 -- America Movil Peru S.A.C. 15 - AS27947 10791 0.5% 21.3 -- Telconet S.A 16 - AS29049 10705 0.5% 31.6 -- DELTA-TELECOM-AS Delta Telecom LTD. 17 - AS2697 10396 0.5% 110.6 -- ERX-ERNET-AS Education and Research Network 18 - AS28573 10382 0.5% 7.5 -- NET Servi?os de Comunica??o S.A. 19 - AS4755 10146 0.5% 7.7 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 20 - AS45899 9838 0.5% 26.3 -- VNPT-AS-VN VNPT Corp TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9854 6668 0.3% 6668.0 -- KTO-AS-KR KTO 2 - AS6174 6108 0.3% 3054.0 -- SPRINTLINK8 - Sprint 3 - AS36225 2953 0.1% 2953.0 -- INFINITEIT-ASN-01 - Infinite IT Solutions Inc. 4 - AS8137 4762 0.2% 2381.0 -- DISNEYONLINE-AS - Disney Online 5 - AS36976 2130 0.1% 2130.0 -- SONANGOL 6 - AS37367 3513 0.2% 1756.5 -- CALLKEY 7 - AS42334 3609 0.2% 1203.0 -- BBP-AS Broadband Plus s.a.l. 8 - AS35413 1124 0.1% 1124.0 -- SL-NETWORKS SL Networks SRL 9 - AS11017 2091 0.1% 1045.5 -- CSN - CSN Support Services 10 - AS61141 1032 0.1% 1032.0 -- OST-AS OST CJSC 11 - AS3 7551 0.4% 1502.0 -- CMED-AS Cmed Technology Ltd 12 - AS37004 13691 0.7% 652.0 -- SUBURBAN-AS 13 - AS22216 5632 0.3% 625.8 -- SIEMENS-PLM - Siemens Corporation 14 - AS48612 8636 0.4% 616.9 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 15 - AS10445 3922 0.2% 560.3 -- HTG - Huntleigh Telcom 16 - AS55150 555 0.0% 555.0 -- DST-01 - DST Resources 17 - AS34969 3840 0.2% 480.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 18 - AS50797 461 0.0% 461.0 -- ELIXE-AS Elixe Co. Ltd 19 - AS57851 439 0.0% 439.0 -- GENESIS-HOUSING-ASSOCIATION-LIMITED Genesis Housing Association Limited 20 - AS22688 829 0.0% 414.5 -- DOLGENCORP - Dollar General Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.118.224.0/21 8581 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 2 - 92.246.207.0/24 8572 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 203.118.232.0/21 8543 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 202.41.70.0/24 7890 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 5 - 192.58.232.0/24 7776 0.4% AS6629 -- NOAA-AS - NOAA 6 - 211.214.206.0/24 6668 0.3% AS9854 -- KTO-AS-KR KTO 7 - 192.107.15.0/24 5126 0.2% AS14733 -- AS14733 - Barclays Capital Inc. 8 - 198.187.189.0/24 4759 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 9 - 194.63.9.0/24 4589 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 10 - 64.187.64.0/23 4037 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 11 - 173.232.234.0/24 4020 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 12 - 173.232.235.0/24 4017 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 13 - 69.38.178.0/24 4016 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 62.84.76.0/24 3601 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 15 - 41.75.40.0/21 3510 0.2% AS37367 -- CALLKEY 16 - 64.187.64.0/24 3436 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 17 - 206.105.75.0/24 3054 0.1% AS6174 -- SPRINTLINK8 - Sprint 18 - 208.16.110.0/24 3054 0.1% AS6174 -- SPRINTLINK8 - Sprint 19 - 216.27.253.0/24 2998 0.1% AS22343 -- TELESPHERE-NETWORKS - Telesphere Networks Ltd. 20 - 24.116.3.0/24 2975 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From swhyte at gmail.com Fri Jun 28 22:05:14 2013 From: swhyte at gmail.com (Scott Whyte) Date: Fri, 28 Jun 2013 15:05:14 -0700 Subject: Google's QUIC In-Reply-To: <51CDF0D9.4060409@mtcc.com> References: <51CDED87.6050503@mtcc.com> <51CDF0D9.4060409@mtcc.com> Message-ID: On Fri, Jun 28, 2013 at 1:23 PM, Michael Thomas wrote: > On 06/28/2013 01:16 PM, Josh Hoppes wrote: > >> My first question is, how are they going to keep themselves from >> congesting links? >> > > The FAQ claims they're paying attention to that, but I haven't read the > details. I sure hope they grok that not understanding Van Jacobson dooms > you to repeat it. > Van is at Google. Much grokking is going on. -Scott > > https://docs.google.com/**document/d/**1lmL9EF6qKrk7gbazY8bIdvq3Pno2X** > j_l_YShP40GLQE/preview?sle=**true#heading=h.h3jsxme7rovm > > Mike > > > >> On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas wrote: >> >>> http://arstechnica.com/**information-technology/2013/** >>> 06/google-making-the-web-**faster-with-protocol-that-** >>> reduces-round-trips/?comments=**1 >>> >>> Sorry if this is a little more on the dev side, and less on the ops side >>> but >>> since >>> it's Google, it will almost certainly affect the ops side eventually. >>> >>> My first reaction to this was why not SCTP, but apparently they think >>> that >>> middle >>> boxen/firewalls make it problematic. That may be, but UDP based port >>> filtering is >>> probably not far behind on the flaky front. >>> >>> The second justification was TLS layering inefficiencies. That definitely >>> has my >>> sympathies as TLS (especially cert exchange) is bloated and the way that >>> it >>> was >>> grafted onto TCP wasn't exactly the most elegant. Interestingly enough, >>> their >>> main justification wasn't a security concern so much as "helpful" middle >>> boxen >>> getting their filthy mitts on the traffic and screwing it up. >>> >>> The last thing that occurs to me reading their FAQ is that they are >>> seemingly trying >>> to send data with 0 round trips. That is, SYN, data, data, data... That >>> really makes me >>> wonder about security/dos considerations. As in, it sounds too good to be >>> true. But >>> maybe that's just the security cruft? But what about SYN cookies/dos? >>> Hmmm. >>> >>> Other comments or clue? >>> >>> Mike >>> >>> > > From shopik at inblock.ru Fri Jun 28 22:12:33 2013 From: shopik at inblock.ru (Nikolay Shopik) Date: Sat, 29 Jun 2013 02:12:33 +0400 Subject: Google's QUIC In-Reply-To: <206144.1372455520@turing-police.cc.vt.edu> References: <23621670.274.1372453648746.JavaMail.root@benjamin.baylink.com> <51CDFCF5.8000204@mtcc.com> <51CE0007.5050300@bogus.com> <206144.1372455520@turing-police.cc.vt.edu> Message-ID: On 29.06.2013, at 1:38, Valdis.Kletnieks at vt.edu wrote: > On Fri, 28 Jun 2013 14:28:39 -0700, joel jaeggli said: > >> SCTP is used successfully for the purpose for which it was intended, >> which is connecting SS7 switches over IP. It's not as much a posterchild >> for an application agnostic transport as some people would like to think. > > OK, I'll bite... does anything else notable actually use it? > > Well it mostly non-user stuff, Netflow exporting, diameter, sip. Wait webrtc using it, firefox and chrome have sctp code, last time a checked From robertg at garlic.com Fri Jun 28 22:16:12 2013 From: robertg at garlic.com (Robert Glover) Date: Fri, 28 Jun 2013 15:16:12 -0700 Subject: Charter - IPv6 peering Message-ID: <51CE0B2C.2030805@garlic.com> Anyone from Charter have any information on when IPv6 peering will be available to Charter Business customers? My response from support was "Charter is not currently providing IPV6 customer peering" Looking back in the NANOG archives, I see back in May there was mention of a field trial for Charter Business customers. Did that become a "thing"? -Robert From robertg at garlic.com Fri Jun 28 22:22:12 2013 From: robertg at garlic.com (Robert Glover) Date: Fri, 28 Jun 2013 15:22:12 -0700 Subject: Charter - IPv6 peering In-Reply-To: <51CE0B2C.2030805@garlic.com> References: <51CE0B2C.2030805@garlic.com> Message-ID: <51CE0C94.4060609@garlic.com> > Looking back in the NANOG archives, I see back in May there was mention > of a field trial for Charter Business customers. Did that become a "thing"? Forgot to add, that is May of *2012* From alvarezp at alvarezp.ods.org Fri Jun 28 22:24:44 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 28 Jun 2013 15:24:44 -0700 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow wrote: > again... not a super smart on this stuff, but.. > why does it require OS modifications? isn't this just going be > 'chrome' (or 'other application') asking for a udp socket and spewing > line-rate-foo out of that? isn't the application going to be doing all > of the multiplexing and jankiness? I hope not. What would be the point of only letting one application take the benefit of all those improvements? "If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards." So yes, QUIC itself doesn't require OS-level modifications, but letting stay there is pointless. >> protocol that could be similar to UDP but work on the application layer. > > it's not 'similar to UDP', it is in fact UDP, from what I read in the > article. Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is needed just to work through NAT. >> My point was that all that work could be focused on a *really* good >> transport (even with end-user multihoming without bloating the routing > > how's that sctp going for you? > lisp? > sham6? That's the point exactly. Google has more power and popularity to influence adoption of a protocol, just like with SPDY and QUIC. Neither of the three are widely implemented. That said, neither of those enable full path resiliency. Path resiliency requires the end-point to be available through different paths and being able to detect those paths *before* the first connection is established. SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is IPv6-specific and can help you "recover" an already successful connection. LISP... I can't still grasp LISP, although it doesn't have anything to do with multihoming. :-) >> table), and have streamlined TCP and UDP that takes advantage of the new >> protocol. > > sure, ilnp? ILNP is new for me. Looks interesting, thanks. -- Octavio. From sethm at rollernet.us Fri Jun 28 22:27:44 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 28 Jun 2013 15:27:44 -0700 Subject: Charter - IPv6 peering In-Reply-To: <51CE0B2C.2030805@garlic.com> References: <51CE0B2C.2030805@garlic.com> Message-ID: <51CE0DE0.8070704@rollernet.us> On 6/28/13 3:16 PM, Robert Glover wrote: > Anyone from Charter have any information on when IPv6 peering will be > available to Charter Business customers? > > My response from support was "Charter is not currently providing IPV6 > customer peering" > > Looking back in the NANOG archives, I see back in May there was mention > of a field trial for Charter Business customers. Did that become a "thing"? > I've had native IPv6 from Charter since January 2013. ~Seth From robertg at garlic.com Fri Jun 28 22:36:26 2013 From: robertg at garlic.com (Robert Glover) Date: Fri, 28 Jun 2013 15:36:26 -0700 Subject: Charter - IPv6 peering In-Reply-To: <51CE0DE0.8070704@rollernet.us> References: <51CE0B2C.2030805@garlic.com> <51CE0DE0.8070704@rollernet.us> Message-ID: <51CE0FEA.6020501@garlic.com> On 6/28/2013 3:27 PM, Seth Mattinen wrote: > I've had native IPv6 from Charter since January 2013. > > ~Seth > Are you a Charter Business fiber customer doing BGP with IPv6 PI space? -Robert From sethm at rollernet.us Fri Jun 28 22:40:49 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 28 Jun 2013 15:40:49 -0700 Subject: Charter - IPv6 peering In-Reply-To: <51CE0FEA.6020501@garlic.com> References: <51CE0B2C.2030805@garlic.com> <51CE0DE0.8070704@rollernet.us> <51CE0FEA.6020501@garlic.com> Message-ID: <51CE10F1.2050204@rollernet.us> On 6/28/13 3:36 PM, Robert Glover wrote: > On 6/28/2013 3:27 PM, Seth Mattinen wrote: >> I've had native IPv6 from Charter since January 2013. >> >> ~Seth >> > Are you a Charter Business fiber customer doing BGP with IPv6 PI space? > Yes to all. They're one of the providers I multihome with. ~Seth From morrowc.lists at gmail.com Sat Jun 29 00:20:21 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 28 Jun 2013 20:20:21 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Jun 28, 2013 6:24 PM, "Octavio Alvarez" wrote: > > On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow > wrote: > >> again... not a super smart on this stuff, but.. >> >>> protocol that could be similar to UDP but work on the application layer. >> >> >> it's not 'similar to UDP', it is in fact UDP, from what I read in the article. > > > Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is > needed just to work through NAT. > > "Runs in top of UDP"... "Is not UDP"... If it has protocol set to 17 it is UDP. >>> My point was that all that work could be focused on a *really* good >>> transport (even with end-user multihoming without bloating the routing >> >> >> how's that sctp going for you? >> lisp? >> sham6? > > > That's the point exactly. Google has more power and popularity to > influence adoption of a protocol, just like with SPDY and QUIC. > > Neither of the three are widely implemented. That said, neither of those > enable full path resiliency. Path resiliency requires the end-point to be > available through different paths and being able to detect those paths > *before* the first connection is established. > > SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is > IPv6-specific and can help you "recover" an already successful connection. > LISP... I can't still grasp LISP, although it doesn't have anything to do > with multihoming. :-) > Lisp is actually very much about multihoming... In fact that was one of the key reasons it got started. It actually could make multihoming and mobility very much simpler at the applications if it were used. It is a bit complex though... At least for normal ivp4/6 routing minded folk. > >>> table), and have streamlined TCP and UDP that takes advantage of the new >>> protocol. >> >> >> sure, ilnp? > > > ILNP is new for me. Looks interesting, thanks. Mind that ilnp is v6only also requires stack changes... From mike-nanog at tiedyenetworks.com Sat Jun 29 00:26:18 2013 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 28 Jun 2013 17:26:18 -0700 Subject: Service provider T1/PPP question In-Reply-To: <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> References: <51CD0C11.8010204@tiedyenetworks.com> <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> Message-ID: <51CE29AA.6040908@tiedyenetworks.com> On 06/28/2013 12:56 PM, Naslund, Steve wrote: > > I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? > > I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. Thanks tho. Mike From EWieling at nyigc.com Sat Jun 29 01:21:09 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 28 Jun 2013 21:21:09 -0400 Subject: Service provider T1/PPP question In-Reply-To: <51CE29AA.6040908@tiedyenetworks.com> References: <51CD0C11.8010204@tiedyenetworks.com> <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> <51CE29AA.6040908@tiedyenetworks.com> Message-ID: <616B4ECE1290D441AD56124FEBB03D0817145E74FE@mailserver2007.nyigc.globe> -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Friday, June 28, 2013 8:26 PM To: nanog at nanog.org Subject: Re: Service provider T1/PPP question On 06/28/2013 12:56 PM, Naslund, Steve wrote: > > I think this post seems like a flashback. I would not consider a T-1 to really be broadband anymore and it is pretty much limited to a business environment the way tariffs work. As far as MLPPP, it seems to be pretty stable now where you need multiple bonded T-1s. We have a few sites running MLPPP with Sprint on Juniper and Cisco gear and have not had an issue with it. It is definitely not my preference for business connectivity anymore. We tend to look for Ethernet service which is way cheaper per mb than T-1 and requires less expensive terminal equipment in most cases. T-1s are the business solution where you need dedicated MPLS connectivity and fiber transport is not available. DSL or Internet VPN are OK but somewhat less stable for business class private network solutions. If it is internet connectivity they want you will get beaten up by the cable companies that can outrun and outprice you across the board. You will also have a heck of a time competing with incumbent and competitive telecoms in T-1s that have central offices or collocations in central offices. The economics just don't work if you don't have direct access to the cable plant. Maybe up until the telecom act but not now. How do you intend to get those T-1s back to you or are you a CLEC? > > I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. ======================================================================================== Most "T-1" service these days seems to be delivered over HDSL. You may also want to consider EoC. XO uses Adtran CPEs for their EoC service, anything from 1.5Mbps to 20Mbps service over 1 or more copper pairs with good distances between repeaters. From jackson.tim at gmail.com Sat Jun 29 01:42:48 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 28 Jun 2013 18:42:48 -0700 Subject: Service provider T1/PPP question In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0817145E74FE@mailserver2007.nyigc.globe> References: <51CD0C11.8010204@tiedyenetworks.com> <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> <51CE29AA.6040908@tiedyenetworks.com> <616B4ECE1290D441AD56124FEBB03D0817145E74FE@mailserver2007.nyigc.globe> Message-ID: The problem being a CLEC is getting access to repeater housings. Usually limits you to a few kft. At least you can get up to 15mbps/pair now. On Jun 28, 2013 6:23 PM, "Eric Wieling" wrote: > > > -----Original Message----- > From: Mike [mailto:mike-nanog at tiedyenetworks.com] > Sent: Friday, June 28, 2013 8:26 PM > To: nanog at nanog.org > Subject: Re: Service provider T1/PPP question > > On 06/28/2013 12:56 PM, Naslund, Steve wrote: > > > > I think this post seems like a flashback. I would not consider a T-1 to > really be broadband anymore and it is pretty much limited to a business > environment the way tariffs work. As far as MLPPP, it seems to be pretty > stable now where you need multiple bonded T-1s. We have a few sites > running MLPPP with Sprint on Juniper and Cisco gear and have not had an > issue with it. It is definitely not my preference for business > connectivity anymore. We tend to look for Ethernet service which is way > cheaper per mb than T-1 and requires less expensive terminal equipment in > most cases. T-1s are the business solution where you need dedicated MPLS > connectivity and fiber transport is not available. DSL or Internet VPN are > OK but somewhat less stable for business class private network solutions. > If it is internet connectivity they want you will get beaten up by the > cable companies that can outrun and outprice you across the board. You > will also have a heck of a time competing with incumbent and competitive > telecoms in T-1s that have central offices or collocations in central > offices. The economics just don't work if you don't have direct access to > the cable plant. Maybe up until the telecom act but not now. How do you > intend to get those T-1s back to you or are you a CLEC? > > > > > > I am a clec with colocated facilities, and my targets are rural unserved > areas where none of the factors above are considerations. I just want to > connect with anyone who's done this and has a qualified technical opinion > on optimal deployment strategies; the business considerations are already > done. > > > ======================================================================================== > > Most "T-1" service these days seems to be delivered over HDSL. You may > also want to consider EoC. XO uses Adtran CPEs for their EoC service, > anything from 1.5Mbps to 20Mbps service over 1 or more copper pairs with > good distances between repeaters. > > > > > From mike-nanog at tiedyenetworks.com Sat Jun 29 02:07:42 2013 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 28 Jun 2013 19:07:42 -0700 Subject: Service provider T1/PPP question In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0817145E74FE@mailserver2007.nyigc.globe> References: <51CD0C11.8010204@tiedyenetworks.com> <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> <51CE29AA.6040908@tiedyenetworks.com> <616B4ECE1290D441AD56124FEBB03D0817145E74FE@mailserver2007.nyigc.globe> Message-ID: <51CE416E.4040501@tiedyenetworks.com> On 06/28/2013 06:21 PM, Eric Wieling wrote: > I am a clec with colocated facilities, and my targets are rural > unserved areas where none of the factors above are considerations. I > just want to connect with anyone who's done this and has a qualified > technical opinion on optimal deployment strategies; the business > considerations are already done. > ======================================================================================== > Most "T-1" service these days seems to be delivered over HDSL. You may > also want to consider EoC. XO uses Adtran CPEs for their EoC service, > anything from 1.5Mbps to 20Mbps service over 1 or more copper pairs > with good distances between repeaters. Im already doing the above. Just need T1 for reach since EoC is only good on home runs from the CO out to some distance whereas T1 can get me into the hills beyond. Mike- From alvarezp at alvarezp.ods.org Sat Jun 29 02:12:24 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 28 Jun 2013 19:12:24 -0700 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow wrote: > > "Runs in top of UDP"... "Is not UDP"... > > If it has protocol set to 17 it is UDP. So QUIC is an algorithm instead of a protocol? >> SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is >> IPv6-specific and can help you "recover" an already successful >> connection. > >> LISP... I can't still grasp LISP, although it doesn't have anything to >> do with multihoming. :-) > > Lisp is actually very much about multihoming... In fact that was one of > the key reasons it got started. It actually could make >multihoming and > mobility very much simpler at the applications if it were used. Yeah, but LISP is as [in]accessible to end-users as BGP is and it will be like that forever. It requires ISPs to opt-in to provide this. LISP is not a universal option. LISP matters to the Internet core, it doesn't matter to the whole Internet. It is just not universal. >> ILNP is new for me. Looks interesting, thanks. > > Mind that ilnp is v6only also requires stack changes... I just read about ILNP. ILNP is nice if you want to multihome nodes, but virtualization (or spanning, for that matter, similar to anycasting) over multiple data-centers will reach the limitations of ILNP. It is a step ahead, but it is not an integral approach. I wish my Debian mirror would just be the "mirror.debian.net" *service* (not host), and the network could choose the best for me. -- Octavio. From bicknell at ufp.org Sat Jun 29 02:56:41 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 28 Jun 2013 21:56:41 -0500 Subject: Service provider T1/PPP question In-Reply-To: <51CE29AA.6040908@tiedyenetworks.com> References: <51CD0C11.8010204@tiedyenetworks.com> <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> <51CE29AA.6040908@tiedyenetworks.com> Message-ID: On Jun 28, 2013, at 7:26 PM, Mike wrote: > I am a clec with colocated facilities, and my targets are rural unserved areas where none of the factors above are considerations. I just want to connect with anyone who's done this and has a qualified technical opinion on optimal deployment strategies; the business considerations are already done. I find this fascinating, but here's the "scoop". When T1's were the bee's knees (why is that a saying, anyway?) they were sold to what today we would call a "business" customer. The concept of residential users as we know them know didn't really exist during T1's heyday. Also during this time period MLPPP for "high speed" (yes, T1's qualified" wasn't really a thing, rather external multiplexers and HSSI (remember those fun cables?) into a DS3 interface were a thing. Remember providers that did Frame Relay over NxT1 just so they could mux the multiple customers on to DS-3/OC-3 into routers? Fun times...not. Anyway, the customer would have a router, like a real router, well, a 25xx anyway, and know how to configure it. That doesn't seem to be the world you're describing though, which is why I think you're getting crickets on the mailing list. Here's my $0.02, this is going to work best if you go somewhat old school in the config. HDLC or PPP over a single T1 to any equipment that supports either should more or less work just fine. Static assignment will work just fine, PPP learned assignments should work more or less just fine. Any of the things that can channelize DS-3/OC-3/OC-12/OC-48 down to T1 should work just dandy, it's all a matter of how many you have and your particular economics. Bonded T1's is where it gets interesting. MLPPP should be possible with modern hardware, but honestly it got a workout on devices that did things like ISDN, not T1's. Still, if you choose carefully I don't see any reason why MLPPP shouldn't be reliable and work just fine in today's world. If you're willing to do without modern features, you should be able to pick up a ton of gear that does all this for dirt cheap. A 7513 with channelized DS-3 cards is still quite spiffy for terminating static routed T1's for instance, and people may even pay you take them at this point. :) The CPE will be more interesting, there are several vendors that still make CPE with T1 interfaces, but that's much more rare. -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bicknell at ufp.org Sat Jun 29 03:00:17 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 28 Jun 2013 22:00:17 -0500 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: <31C590AE-0018-40C4-B93D-BF7A7066585C@ufp.org> On Jun 28, 2013, at 5:24 PM, Octavio Alvarez wrote: > That's the point exactly. Google has more power and popularity to > influence adoption of a protocol, just like with SPDY and QUIC. This is the main reason why I'm very supportive of this effort. I'm a bit skeptical of what I have read so far, but I know that it's nearly impossible to tell how these things really work from theory and simulations. Live, real world testing is required competing with all sorts of other flows. Google with their hands in both things like www.google.com and Chrome is in an interesting position to implement server and client side of these implementations, and turn them on and off at will. They can do the real world tests, tweak, report on them, and advance the state of the art. So for now I'll reserve judgement on this particular protocol, while encouraging Google to do more of this sort of real world testing at the protocol level. Now, how about an SCTP test? :) -- 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jeff-kell at utc.edu Sat Jun 29 03:09:28 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 28 Jun 2013 23:09:28 -0400 Subject: Service provider T1/PPP question In-Reply-To: References: <51CD0C11.8010204@tiedyenetworks.com> <9578293AE169674F9A048B2BC9A081B403C841BB@MUNPRDMBXA1.medline.com> <51CE29AA.6040908@tiedyenetworks.com> Message-ID: <51CE4FE8.6060606@utc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/28/2013 10:56 PM, Leo Bicknell wrote: > If you're willing to do without modern features, you should be able to pick up a ton of gear that does all this for dirt cheap. A 7513 with channelized DS-3 cards is still quite spiffy for terminating static routed T1's for instance, and people may even pay you take them at this point. :) The CPE will be more interesting, there are several vendors that still make CPE with T1 interfaces, but that's much more rare. As someone else already mentioned, back in the 720x-VXR /3640 days of T1 terminations, we scaled up to 5 T1s before going to [fractional] DS3, and the old "cef per-packet" load balancing was wonderful provided you were talking to another Cisco endpoint (which for us, at the time, was Qwest, and yes it was). We were so sold on it that we even tried that on campus, but soon learned that Catalysts had no idea what "cef per-packet" meant :( So enter EIGRP / utilization load sharing... Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlHOT+gACgkQiwXJq373XhaozQCgiVGXOMIDccyONDRUQAk/M5GW 2OQAn2EfzwkvrgIl4eUsjIAGyXKq7z6s =u7Mw -----END PGP SIGNATURE----- From cb.list6 at gmail.com Sat Jun 29 03:55:35 2013 From: cb.list6 at gmail.com (cb.list6) Date: Fri, 28 Jun 2013 20:55:35 -0700 Subject: Google's QUIC In-Reply-To: <31C590AE-0018-40C4-B93D-BF7A7066585C@ufp.org> References: <51CDED87.6050503@mtcc.com> <31C590AE-0018-40C4-B93D-BF7A7066585C@ufp.org> Message-ID: On Fri, Jun 28, 2013 at 8:00 PM, Leo Bicknell wrote: > > On Jun 28, 2013, at 5:24 PM, Octavio Alvarez wrote: > >> That's the point exactly. Google has more power and popularity to >> influence adoption of a protocol, just like with SPDY and QUIC. > > This is the main reason why I'm very supportive of this effort. I'm a bit skeptical of what I have read so far, but I know that it's nearly impossible to tell how these things really work from theory and simulations. Live, real world testing is required competing with all sorts of other flows. > > Google with their hands in both things like www.google.com and Chrome is in an interesting position to implement server and client side of these implementations, and turn them on and off at will. They can do the real world tests, tweak, report on them, and advance the state of the art. > > So for now I'll reserve judgement on this particular protocol, while encouraging Google to do more of this sort of real world testing at the protocol level. > +1, Google is smart for doing this. It is important to push the boundaries on performance. QUIC is UDP, and UDP is the right step for now. And, hopefully this stuff gets rolled up into ILNP stack features. Yes ILNP needs stack changes, think big. Not all things can NOT be a simple incremental tweaks. ILNP will be a revolution. QUIC is simply a revolt on performance issues with TCP in today's low-loss, high latency (mobile), and middle box encumbered networks. CB > Now, how about an SCTP test? :) > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > From morrowc.lists at gmail.com Sat Jun 29 04:21:14 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 29 Jun 2013 00:21:14 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez wrote: > On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow > wrote: > >> >> "Runs in top of UDP"... "Is not UDP"... >> >> If it has protocol set to 17 it is UDP. > > > So QUIC is an algorithm instead of a protocol? it's as much a protocol as http is.. I suppose my point is that it's some protocol which uses udp as the transport. Because of this I don't see any (really) kernel/stack changes required, right? it's just something the application needs to work out with it's peer(s). No different from http vs smtp... -chris From ag4ve.us at gmail.com Sat Jun 29 04:54:22 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 29 Jun 2013 00:54:22 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Jun 29, 2013 12:23 AM, "Christopher Morrow" wrote: > > On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez > wrote: > > On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow > > wrote: > > > >> > >> "Runs in top of UDP"... "Is not UDP"... > >> > >> If it has protocol set to 17 it is UDP. > > > > > > So QUIC is an algorithm instead of a protocol? > > it's as much a protocol as http is.. I suppose my point is that it's > some protocol which uses udp as the transport. > > Because of this I don't see any (really) kernel/stack changes > required, right? it's just something the application needs to work out > with it's peer(s). No different from http vs smtp... > SCTP was layer 4, if QUIC is the same, than it will too. If QUIC is layer 5 up, it won't. That might be the difference (I haven't looked into QUIC). > -chris > From jimpop at gmail.com Sat Jun 29 02:31:35 2013 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 28 Jun 2013 22:31:35 -0400 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez wrote: > > I wish my Debian mirror would just be the "mirror.debian.net" *service* > (not host), and the network could choose the best for me. Try http.debian.net see: http://http.debian.net -Jim P. From mike at mtcc.com Sat Jun 29 10:22:39 2013 From: mike at mtcc.com (Michael Thomas) Date: Sat, 29 Jun 2013 03:22:39 -0700 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: <51CEB56F.7090201@mtcc.com> On 06/28/2013 09:54 PM, shawn wilson wrote: > On Jun 29, 2013 12:23 AM, "Christopher Morrow" > wrote: >> On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez >> wrote: >>> On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow >>> wrote: >>> >>>> "Runs in top of UDP"... "Is not UDP"... >>>> >>>> If it has protocol set to 17 it is UDP. >>> >>> So QUIC is an algorithm instead of a protocol? >> it's as much a protocol as http is.. I suppose my point is that it's >> some protocol which uses udp as the transport. >> >> Because of this I don't see any (really) kernel/stack changes >> required, right? it's just something the application needs to work out >> with it's peer(s). No different from http vs smtp... >> > SCTP was layer 4, if QUIC is the same, than it will too. If QUIC is layer 5 > up, it won't. That might be the difference (I haven't looked into QUIC). > From the FAQ, QUIC is an experiment that they're building on top of UDP to test out what a new layer 4 transport protocol built with modern http in mind ought to look like. They say that they eventually want to fold the results back into TCP (if possible, but given their goals it doesn't seem especially likely that the result would still be TCP). Mike From jpv at veldersjes.net Sat Jun 29 10:49:37 2013 From: jpv at veldersjes.net (JP Velders) Date: Sat, 29 Jun 2013 12:49:37 +0200 (CEST) Subject: Security over SONET/SDH In-Reply-To: References: <20130624125556.D485E358@m0005296.ppops.net> Message-ID: > Date: Tue, 25 Jun 2013 06:38:23 -0600 > From: Phil Fagan > Subject: Re: Security over SONET/SDH > Are these private links or customer links? Why encrypt at that > layer? I'm looking for the niche usecase. If I recall correctly the PCI stuff says an MPLS network is sufficiently safe. If I were a financial, I would mandate at the very least that all my communications extra-country be encrypted. Since we know how "young" some of the languages and protocols on which our financial infrastructure is built are, we can bet the house you need link-layer-level encryption to make that work. Now, whether the institution puts it in place, or requires the international transport carrier to do so (hey, howdy, SONET/SDH) is another thing. Nortel at one point had an OC192 AES256 encryption option: http://www.igrid2005.org/media/press_09.28.05_nortel.html In the end remember, a lot of trans/inter-national bandwidth is still SONET/SDH based and only slowly changing to Ethernet-like transports. Kind regards, JP Velders From Grzegorz at Janoszka.pl Sat Jun 29 11:53:49 2013 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Sat, 29 Jun 2013 13:53:49 +0200 Subject: Google's QUIC In-Reply-To: <51CEB56F.7090201@mtcc.com> References: <51CDED87.6050503@mtcc.com> <51CEB56F.7090201@mtcc.com> Message-ID: <51CECACD.3070206@Janoszka.pl> I am surprised nobody mentioned security issues. To minimize latency the following would be best: the client sends one UDP packet and receives stream of UDP packets with page code, styles, images and whatever else could be needed. The waiting time is just RTT plus browser processing. It is a great amplification tools, isn't it? There are pages which require loading megabytes of data just for one request, so definitely more than 1000 UDP packets (MTU 1500). Amplification factor 1:1000+ in packets, 1:10000+ in octets :) Of course you can add to the protocol some small initial response, key exchange, whatever, but then the page appears after N*RTT, which is already happening with TCP now. I am sure Google considered it, so I am really curious how they are going to solve it. -- Grzegorz Janoszka From djahandarie at gmail.com Sat Jun 29 14:27:48 2013 From: djahandarie at gmail.com (Darius Jahandarie) Date: Sat, 29 Jun 2013 10:27:48 -0400 Subject: Google's QUIC In-Reply-To: <51CECACD.3070206@Janoszka.pl> References: <51CDED87.6050503@mtcc.com> <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> Message-ID: On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka wrote: > I am surprised nobody mentioned security issues. To minimize latency the > following would be best: the client sends one UDP packet and receives > stream of UDP packets with page code, styles, images and whatever else > could be needed. The waiting time is just RTT plus browser processing. > > I am sure Google considered it, so I am really curious how they are > going to solve it. Of course they consider this. Read the "CONNECTION ESTABLISHMENT and RESUMPTION" section of their design document [1]. If you're familiar with TCP Fast Open, many of its techniques are reused. [1] https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit -- Darius Jahandarie From saku at ytti.fi Sat Jun 29 18:07:10 2013 From: saku at ytti.fi (Saku Ytti) Date: Sat, 29 Jun 2013 21:07:10 +0300 Subject: Google's QUIC In-Reply-To: References: <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> Message-ID: <20130629180710.GA1822@pob.ytti.fi> On (2013-06-29 10:27 -0400), Darius Jahandarie wrote: > On Sat, Jun 29, 2013 at 7:53 AM, Grzegorz Janoszka wrote: > > I am surprised nobody mentioned security issues. To minimize latency the > > following would be best: the client sends one UDP packet and receives > > stream of UDP packets with page code, styles, images and whatever else > > could be needed. The waiting time is just RTT plus browser processing. > > > Of course they consider this. Read the "CONNECTION ESTABLISHMENT and > RESUMPTION" section of their design document [1]. If you're familiar > with TCP Fast Open, many of its techniques are reused. > > [1] https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit tl;dr Initial connection is not 0 RTT, 0 RTT only works if you already knew public key of server (and may require additional degree of proof of ownership of SourceIP, SourcePort, which may be fuzzy, so you might accept 192.0.2.42 as being 192.0.42.66) Considering the terribly demanding restrictions of being deployable today, QUIC looks pretty good to me. But I hope some 'ngl4' will eventually replace TCP and UDP. As far as I know SCTP fails in comparatively common scenario where your IP changes unannounced without overlapping time using both IP addresses. Seems like one major reasons for QUIC is same problem that affects SPDY and ssh session multiplexing, TCP guarantees order and all sessions will be penalized when one session has loss, this is huge huge cost. How I suffer from this is I QoS at home small packets, so that my interactive ssh works great even though I congest link with 'scp', but with session multiplexing, I'll still suffer lag, as kernel won't give the reordered interactive ssh packet to application until the large scp packet has been received. Other takeaways I took from the document - tries to be terse/compact, use flags to have dynamic set of headers, e.g. we don't need to always tell what version of QUIC we use - handles addresses changes, port changes (it's non-trivial problem, so leaves some corner cases) - copes with NAT boxes regularly ditching your session - 0 RTT (send hello + send data packets immediately after), assumes you've already cached the private key - 64b GUID used as discriminator address/port not really. Could we leverage IPv6 host portion in future for this? Finally giving actual benefit to the huge LANs we have. Making IPv6 location/service. - Reflected amplifications heavily considered, benefit mitigated by forcing padding of packets when trust has not been established - bandwidth estimation used, packet loss not key/only metric, increased latency observed and considered as reduced bandwidth. Packet pacing used as way to reduce packets (this has problematic implications a) quic might be prone to starvation if buffer-bloat and b) operator might not know their network is performing as sub-par way, as you could have 0 packet loss, while clients could be forced to reduce transmit rates, you'd need to monitor queue sizes) - raid5 style simple error correction, read-solomon was considered but deemed too high overhead. Especially useful in comparison to TCP when last packet is lost - 90-95% of end users can use UDP/quic, implementation will race with TCP to decide which one to use - uses UDP 80/443, capability announced in HTTP headers (how the heck does GOOG multiplex UDP port, I'd really love it for mosh) - sometimes will resend without observed packet loss, when packet loss would have very high cost (crypto rekey etc) - no packet level resend, resend is data-level - session-tear down has code _and_ phrase to help troubleshooting - as address can change, how to handle malicious middle-box forging address, potential reflection attack by middle-box. Should address change observe RTT penalty to avoid it? -- ++ytti From alvarezp at alvarezp.ods.org Sat Jun 29 21:58:50 2013 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Sat, 29 Jun 2013 14:58:50 -0700 Subject: Google's QUIC In-Reply-To: References: <51CDED87.6050503@mtcc.com> Message-ID: On Fri, 28 Jun 2013 19:31:35 -0700, Jim Popovitch wrote: > On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez > wrote: >> >> I wish my Debian mirror would just be the "mirror.debian.net" *service* >> (not host), and the network could choose the best for me. > > Try http.debian.net see: http://http.debian.net Interesting! Didn't know of that. However, http.debian.net is still a host that redirects me every time. If 46.4.205.43 goes down, I have no way to connect anymore. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp From dot at dotat.at Sat Jun 29 22:36:36 2013 From: dot at dotat.at (Tony Finch) Date: Sat, 29 Jun 2013 23:36:36 +0100 Subject: Google's QUIC In-Reply-To: <20130629180710.GA1822@pob.ytti.fi> References: <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> <20130629180710.GA1822@pob.ytti.fi> Message-ID: <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf Tony. -- f.anthony.n.finch http://dotat.at/ From saku at ytti.fi Sun Jun 30 08:15:14 2013 From: saku at ytti.fi (Saku Ytti) Date: Sun, 30 Jun 2013 11:15:14 +0300 Subject: Google's QUIC In-Reply-To: <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> References: <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> <20130629180710.GA1822@pob.ytti.fi> <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> Message-ID: <20130630081514.GA26427@pob.ytti.fi> On (2013-06-29 23:36 +0100), Tony Finch wrote: > Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf ACK. Any cryptobased 0 RTT will necessarily have many things similar, and indeed crypto is the key for low latency without major attack vectors. But MinimaLT does not support multiplexing, which seems to be critical design goal for QUIC. I wonder how many years until this work materializes in practical NGL4, 10? I'd really hate the final solution to be something riding on top of UDP, because changing stuff is too hard. Or should L4 be just 32b (16b SPORT, 16b DPORT) and L5 headers where magic should live? -- ++ytti From saku at ytti.fi Sun Jun 30 08:44:01 2013 From: saku at ytti.fi (Saku Ytti) Date: Sun, 30 Jun 2013 11:44:01 +0300 Subject: Google's QUIC In-Reply-To: <20130630081514.GA26427@pob.ytti.fi> References: <51CEB56F.7090201@mtcc.com> <51CECACD.3070206@Janoszka.pl> <20130629180710.GA1822@pob.ytti.fi> <870ED262-E77A-4FCF-9F31-B3716A416388@dotat.at> <20130630081514.GA26427@pob.ytti.fi> Message-ID: <20130630084401.GA1746@pob.ytti.fi> On (2013-06-30 11:15 +0300), Saku Ytti wrote: > But MinimaLT does not support multiplexing, which seems to be critical > design goal for QUIC. Mea culpa, it does support multiplexing. -- ++ytti From glen.kent at gmail.com Sun Jun 30 16:34:01 2013 From: glen.kent at gmail.com (Glen Kent) Date: Sun, 30 Jun 2013 22:04:01 +0530 Subject: Egress filters dropping traffic Message-ID: Hi, Under what scenarios do providers install egress ACLs which could say for eg. 1. Allow all IP traffic out on an interface foo if its coming from source IP x.x.x.x/y 2. Drop all other IP traffic out on this interface. Glen From peterehiwe at gmail.com Sun Jun 30 17:08:57 2013 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Sun, 30 Jun 2013 18:08:57 +0100 Subject: Egress filters dropping traffic In-Reply-To: References: Message-ID: I usually do ingress acl on CE facing PE interfaces , that way I can provide one level of anti spoofing on IPs "I control" . I've not had the need for an egress ACL yet but then again I think it depends on network design and habits from Day 1. One use case though may be to mitigate DDOS attack on a customer facing link. Sent from my iPhone On Jun 30, 2013, at 5:34 PM, Glen Kent wrote: > Hi, > > Under what scenarios do providers install egress ACLs which could say for > eg. > > 1. Allow all IP traffic out on an interface foo if its coming from source > IP x.x.x.x/y > 2. Drop all other IP traffic out on this interface. > > Glen From jeff-kell at utc.edu Sun Jun 30 19:08:16 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 30 Jun 2013 15:08:16 -0400 Subject: Egress filters dropping traffic In-Reply-To: References: Message-ID: <51D08220.4000100@utc.edu> On 6/30/2013 12:34 PM, Glen Kent wrote: > Under what scenarios do providers install egress ACLs which could say for > eg. > > 1. Allow all IP traffic out on an interface foo if its coming from source > IP x.x.x.x/y > 2. Drop all other IP traffic out on this interface. If you're an end node, it's BCP to block ingress from your own IP space, and block egress NOT from your IP space. If you're doing transit, it gets more complicated. Jeff From alejandroacostaalamo at gmail.com Sun Jun 30 21:08:13 2013 From: alejandroacostaalamo at gmail.com (alejandroacostaalamo at gmail.com) Date: Sun, 30 Jun 2013 21:08:13 +0000 Subject: Egress filters dropping traffic Message-ID: <1059158291-1372626491-cardhu_decombobulator_blackberry.rim.net-375062493-@b17.c3.bise6.blackberry> I guess maybe you want to be sure a certain process occurred in the router (ej NAT). ------Original Message------ From: Glen Kent To: nanog at nanog.org Subject: Egress filters dropping traffic Sent: Jun 30, 2013 12:04 PM Hi, Under what scenarios do providers install egress ACLs which could say for eg. 1. Allow all IP traffic out on an interface foo if its coming from source IP x.x.x.x/y 2. Drop all other IP traffic out on this interface. Glen Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet