August 2009 - Test - lists.nanog.org

Re: Dan Kaminsky
by Scott Weeks 05 Aug '09

05 Aug '09

--- jmamodio(a)gmail.com wrote: From: Jorge Amodio <jmamodio(a)gmail.com> Sooner or later, we or the new generation of ietfers and nanogers, will need to start thinking about a new naming paradigm and design the services and protocols associated with it. The key question is, when we start? ------------------------------------------------ Read "Patterns in Network Architecture" by John Day. scott

2 1

RE: DNS hardening, was Re: Dan Kaminsky
by Skywing 05 Aug '09

05 Aug '09

That is, of course, assuming that SCTP implementations someday clean up their act a bit. I'm not so sure I'd suggest that they're really ready for "prime time" at this point. - S -----Original Message----- From: Douglas Otis <dotis(a)mail-abuse.org> Sent: Wednesday, August 05, 2009 11:13 To: John Levine <johnl(a)iecc.com> Cc: nanog(a)nanog.org <nanog(a)nanog.org> Subject: Re: DNS hardening, was Re: Dan Kaminsky On 8/5/09 9:48 AM, John Levine wrote: > Other than DNSSEC, I'm aware of these relatively simple hacks to add > entropy to DNS queries. > > 1) Random query ID > > 2) Random source port > > 3) Random case in queries, e.g. GooGLe.CoM > > 4) Ask twice (with different values for the first three hacks) and > compare the answers DNSSEC introduces vulnerabilities, such as reflected attacks and fragmentation related exploits that might poison glue, where perhaps asking twice might still be needed. Modern implementations use random 16 bit transaction IDs. Interposed NATs may impair effectiveness of random source ports. Use of random query cases may not offer an entropy increase in some instances. Asking twice, although doubling resource consumption and latency, offers an increase in entropy that works best when queried serially. Establishing SCTP as a preferred DNS transport offers a safe harbor for major ISPs. SCTP protects against both spoofed and reflected attack. Use of persistent SCTP associations can provide lower latency than that found using TCP fallback, TCP only, or repeated queries. SCTP also better deals with attack related congestion. Once UDP is impaired by EDNS0 response sizes that exceed reassembly resources, or are preemptively dropped as a result, TCP must then dramatically scale up to offer the resilience achieved by UDP anycast. In this scenario, SCTP offers several benefits. SCTP retains initialization state within cryptographically secured cookies, which provides significant protection against spoofed source resource exhaustion. By first exchanging cookies, the network extends server state storage. SCTP also better ensures against cache poisoning whether DNSSEC is used or not. Having major providers support the SCTP option will mitigate disruptions caused by DNS DDoS attacks using less resources. SCTP will also encourage use of IPv6, and improve proper SOHO router support. When SCTP becomes used by HTTP, this further enhances DDoS resistance for even critical web related services as well. -Doug

2 1

RE: Sprint/Verizon BGP
by Edward Brookhouse 05 Aug '09

05 Aug '09

Thanks All - problem resolved. From: Bhavini Mehta [mailto:bhavinim@gmail.com] Sent: Wednesday, August 05, 2009 3:01 PM To: ebroo(a)setuidzero.org Subject: Re: Sprint/Verizon BGP Hello, Are you still seeing the problem?? I see the route changed in our routing table 30 mins back and now we are seeing the best route via Verizon. I just wanted to reach out and see if you still needed someone from Sprint to look at it. Thanks On Wed, Aug 5, 2009 at 11:35 AM, Edward Brookhouse <ebroo(a)setuidzero.org> wrote: Hi all, Any Sprint BGP admins on this list can offer any thoughts on why Sprint connected networks are preferring my Sprint connection when they should be preferring my Verizon? I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and 63.78.31.0/24, being announced by sprint and Verizon, preferred to Verizon(DS3) over Sprint 3MB. Verizon BGP admins think everything is ok, have not heard back from BGP4 at sprint. Any thoughts appreciated, off-list contact welcome. Edward ebroo(a)healthydirections.com

1 0

Sprint/Verizon BGP
by Edward Brookhouse 05 Aug '09

05 Aug '09

Hi all, Any Sprint BGP admins on this list can offer any thoughts on why Sprint connected networks are preferring my Sprint connection when they should be preferring my Verizon? I (Healthy Directions) am AS16387, two blocks 63.73.158.0/24 and 63.78.31.0/24, being announced by sprint and Verizon, preferred to Verizon(DS3) over Sprint 3MB. Verizon BGP admins think everything is ok, have not heard back from BGP4 at sprint. Any thoughts appreciated, off-list contact welcome. Edward ebroo(a)healthydirections.com

5 4

cisco.com
by R. Benjamin Kessler 04 Aug '09

04 Aug '09

Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com) any ideas on the cause and ETR? Thanks, Ben

34 38

IM based BGP route-server interface
by mkarir 04 Aug '09

04 Aug '09

All, We have been experimenting with Instant Messaging as an interface for providing easier access to a route-server. (no longer need to telnet xyz or use annoying web forms). We have essentially created a BGP chat bot. You can reach it by adding AIM: bgpbotz ( or Jabber: bgpbotz(a)jabber.merit.edu) to your buddy list. Just type 'help' or '?' to get started or 'examples'. Most normal route-server queries are supported. You should be able to view routes from Merit's perspective by querying bgpbotz. We would really appreciate any feedback on this project. The website is at: http://software.merit.edu/bgpbotz As bgpbotz is essentially just a query interface to an underlying route-server we would be happpy to add your BGP feeds to our installation and make them available as "views" for other people to query. Please feel free to contact us if you are interested in setting this up. Alternately you can download the chat bot code from the website and run it yourself. In that case please let us know so that we can add your bot to the project website. All comments are welcome. Thanks Eric Wustrow Manish Karir (Merit Network Inc.)

1 0

RE: cisco.com
by Matthew Huff 04 Aug '09

04 Aug '09

Disregard. This was from 2 years ago. Copied the link and verbage without verifying it. My bad. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// <http://www.otaotr.com/> www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Matthew Huff Sent: Tuesday, August 04, 2009 11:19 AM To: 'Myke Lyons' Cc: 'nanog(a)nanog.org' Subject: RE: cisco.com http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to Cisco.com <http://www.cisco.com> has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused Cisco.com <http://www.cisco.com> and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by <http://blogs.cisco.com/authors/bio/46> Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http:// <http://www.otaotr.com/> www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 From: Myke Lyons [mailto:Myke.Lyons@cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog(a)nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 Disregard. This was from 2 years ago. Copied the link and verbage without verifying it. My bad. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[1]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg@01CA14F5.A289E6D0] From: Matthew Huff Sent: Tuesday, August 04, 2009 11:19 AM To: 'Myke Lyons' Cc: 'nanog(a)nanog.org' Subject: RE: cisco.com [2]http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ FINAL UPDATE: Cisco.com Outage Service to [3]Cisco.com has been restored and all applications are now fully operational. The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused [4]Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. Again, we thank our customers and our partners for their patience during the resolution of this issue. Posted by [5]Cisco PR at 12:00AM PST ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://[6]www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 [cid:image001.jpg@01CA14F5.A289E6D0] From: Myke Lyons [mailto:Myke.Lyons@cmtww.com] Sent: Tuesday, August 04, 2009 10:47 AM To: Matthew Huff Cc: 'nanog(a)nanog.org' Subject: Re: cisco.com On Aug 4, 2009, at 10:14 AM, Matthew Huff wrote: Looks like it's back. rtr-inet1#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 4296794 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 6128 7132 109, (received & used) 69.74.151.237 from 69.74.151.237 (65.19.127.20) Origin IGP, localpref 100, valid, external, best rtr-inet2#show ip bgp 198.133.219.0/24 BGP routing table entry for 198.133.219.0/24, version 11588586 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 6128 7132 109, (received & used) 129.77.19.1 from 129.77.19.1 (129.77.9.252) Origin IGP, metric 0, localpref 100, valid, internal, best 6395 3356 7018 109, (received & used) 67.96.160.189 from 67.96.160.189 (216.140.10.58) Origin IGP, metric 6, localpref 100, valid, external Community: 6395:1 6395:1006 Work from here as well sl-gw39-nyc-12-0-0-si28.sprintlink.net (144.228.178.109) AS/21986 References 1. http://www.otaotr.com/ 2. http://blogs.cisco.com/news/comments/final_update_ciscocom_outage/ 3. http://www.cisco.com/ 4. http://www.cisco.com/ 5. http://blogs.cisco.com/authors/bio/46 6. http://www.otaotr.com/

1 0

Re: cisco.com
by deleskie＠gmail.com 04 Aug '09

04 Aug '09

So cisco has no BGP is that what I'm hearing... Oh the irony :) ------Original Message------ From: Aaron Millisor To: R. Benjamin Kessler Cc: nanog(a)nanog.org Subject: Re: cisco.com Sent: Aug 4, 2009 10:45 AM Not sure the ETA but the network that the address for cisco.com resolves to (198.133.219.0/24) is no longer in BGP. -- ----------------------------------------------------- Aaron Millisor R. Benjamin Kessler wrote: > Hey Gang - > > I'm unable to get to cisco.com from multiple places on the 'net > (including downforeveryoneorjustme.com) any ideas on the cause and ETR? > > Thanks, > > Ben > > Sent from my BlackBerry device on the Rogers Wireless Network

9 8

Re: cisco.com
by deleskie＠gmail.com 04 Aug '09

04 Aug '09

Facebook up. Cisco down. From eastern canada ------Original Message------ From: Alex Nderitu To: R. Benjamin Kessler Cc: nanog(a)nanog.org Subject: Re: cisco.com Sent: Aug 4, 2009 10:42 AM Facebook seems to also be affected. -----Original Message----- From: R. Benjamin Kessler <rbk(a)mnsginc.com> To: nanog(a)nanog.org Subject: cisco.com Date: Tue, 4 Aug 2009 09:34:46 -0400 Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com) any ideas on the cause and ETR? Thanks, Ben -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Sent from my BlackBerry device on the Rogers Wireless Network

3 2

Smart hands in NYC area
by Elmar K. Bins 04 Aug '09

04 Aug '09

Hello friendly NANOGers, we'll have to move out of a colo in the NYC area (Verizon DC Elmsford) soon and I need two guys to disassemble half a rack full of equipment, pack the stuff securely and send it away in two batches (one within the US, one to Germany). Packing material needs to be brought, I suppose. The setup has been there for a while - unlikely Verizon kept the material. Can anyone refer me to a company that can help me there, or offer their own services? Thanks for your help, Elmar.

1 0