- NANOG - lists.nanog.org

Re: af.mil contact
by Jerry Dixon 22 Jun '06

22 Jun '06

We're notifying them via JTF-GNO (DOD-CERT). As it relates to .mil's you can get to their site here: http://www.jtfgno.mil/ On government or .gov's you can reach us at www.us-cert.gov Jerry -----Original Message----- From: Geo. [mailto:geoincidents@nls.net] Sent: Thursday, June 22, 2006 08:42 AM To: 'nanog list' Subject: af.mil contact If anyone has a contact for the dns folks over at af.mil could you please inform them that their authorative DNS servers have no A records so their zone is failing to resolve for many people who have enabled anti-dnscache poisoning features. George Roettger Netlink Services

1 0

voip calea interfaces
by Eric A. Hall 22 Jun '06

22 Jun '06

I'm looking into the FCC ruling to require CALEA support for certain classes of VoIP providers, as upheld by the DC circuit court a couple of weeks ago [1]. The portion of VoIP that is covered by this order is pretty narrow (ie, you provide telephony-like voip services for $$ [read the specs for the real definition]), and the FCC is looking at narrowing it down further but has not done so yet. Meanwhile, the deadline for implementation -- May 14, 2007 -- is starting to get pretty close. The operational part of this subject, and the reason for this mail, is the implementation of the wiretap interface. Obviously there are going to be a range of implementation approaches, given that there are a wide variety of providers. I mean, big-switch users probably just enable a feature, but small providers that rely on IP PBX gear with FXO cards will have to do something specific. Are vendors stepping up to the plate? Did you even know about this? Off-list is fine, and I'll summarize if there's interest. Thanks [1] http://pacer.cadc.uscourts.gov/docs/common/opinions/200606/05-1404a.pdf -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

4 6

Re: Tor and network security/administration
by Jeremy Chadwick 22 Jun '06

22 Jun '06

On Wed, Jun 21, 2006 at 08:27:18PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > So if you get a copyright takedown notice regarding infringing material found > on your network, as per 17 USC 512, you intend to actually take responsibility > and liability for your user's infringing material? Or do you intend to take the > ISP Safe Harbor examption, disclaim liability for the material, and nuke the > user? FWIW, I've received such notices in the past, for content my users hosted. Most organisations sending take-down notices give you a 48 hour window to remove the offending content before legal action is taken. I'm thankful for those windows, since I do tend to sleep 10 hours a day... :-) In the two instances where it happened, the users were removed from the system immediately (within about 30 minutes) with all of their data backed up (so they could be given it later, plus in the case there was any involvement with law enforcement). Nothing became of either situation. In both scenarios, I was prepared to take full responsibility since technically speaking the facilities (co-location and bandwidth) I pay for are under my name. It's my rear on the line, and my users content can possibly get my co-location network + cage access removed and my account with my co-location provider terminated (extreme circumstances, but I have to assume the worst). That makes the issue my responsibility, whether I like it or not -- what goes out from my network is my responsibility. In regards to Tor, I'm not referring to "infringing material found on my network" -- I'm referring to shady individuals using machines on the Tor network (which are run by willing members of the network) to do things such as bust root on .gov or .mil boxes and raise all sorts-of hell. Since Tor server administrators don't appear to have any idea of who's using their box for what or when ("I know nothing! I'm innocent! I just installed this Tor daemon and partook in the whole thing willingly!"), who is going to end up paying fines and serving jail time for an individual doing nasty things through aforementioned Tor server? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |

1 0

Global Crossing/Ashburn - Anyone have RFO or ETA insight?
by John Curran 22 Jun '06

22 Jun '06

Folks - Since sometime early this morning, some traffic through Global Crossing in Ashburn has been experiencing packet loss and varying latency consistent with congestion. Global crossing's NOC confirms there is an multiple customer issue, but can't/won't/doesn't-know anything with respect to reason for outage or time to repair... Is anyone working on the other end of the problem who can share some insight? Thanks in advance; sorry to bother the list with operational matters... :-) /John

2 3

Internet 2010 - Predictions for 2010 from a Content Forum and NANOG 37 in San Jose
by William B. Norton 22 Jun '06

22 Jun '06

Hi - At a content forum and NANOG in June 2006 I led some discussions involving predictions for what the Internet might look like in 2010. What makes this so interesting is that so many perspectives highlighted so many potential futures that others had not considered. When you then discuss the implications of such varying futures, again with a diverse crowd, you end up with a lively discussion and, well, some potential futures you may not have considered. I've tried to list some of these predictions from the Content Provider crowd and the ISP NANOG crowd here. Content Provider Predictions for 2010 ------------------------------------------------------ Here is the question I put to a group of Content Providers at a content forum: "We are sitting around this table in 2010 and we are commenting how remarkable the last few years have been, specifically that:" 1. Video streaming volume has grown 100 fold 2. Last mile wireless replaced local loop 3. Botnets (DDOS attacks) are still an issue 4. Non-mechanical (i.e. Flash) Drives replaced internal hard drives on laptops 5. 10% of all cell phones are now video phones 6. We have cell phones that we actually like 7. The U.S. is insignificant traffic wise relative to the rest of the world 8. Most popular question discussed around the table: 'How do we operate business in China?' 9. No online privacy. And the gov't watches everything 10. 18-25 demographic is best reached w/ads on the Internet 11. Next Gen 3D on-line Social Networks are so successful 12. No physical network interfaces are needed 13. We will big brother ourselves (video cams 'who scraped my car?') 14. So many special purpose Internet apps – in car google maps, live traffic updates, etc. 15. So much of our personal information is on the net 16. Video IM emerged as a dominant app 17. P2P will emerge for non-pirated videos – DRM in place and embraced 18. Voice calls are free, bundled with other things [some additional notable predictions from this group, but did not receive simple majority validation] IPTV replaces cable TV IPv6 is adopted Massive Internet Collapse – Metcalfe regurgitates his column Flexible screen deployment SPAM is no longer a problem in 2010 Windows embraces distributed computing Net is not Neutral Powerline Broadband emerges FTTH massive deployment Internet Service Providers Predictions for 2010 ------------------------------------------------------------------ We didn't get to do this at the Peering BOF at NANOG, but I did some table discussions outside in the hallways. There there was no voting so I am listing a subset of the predictions that seemed to resonate among a couple dozen or so folks at the hallway tables where question was discussed: "We are sitting around this table in 2010 at NANOG and we are commenting how remarkable the last few years have been, specifically that:" 1. We have 10G network interface(s) on laptops (I assumed wired, but someone else might have been thinking wireless) 2. $5/mbps is the common/standard price of transit (other prediction was $30/mbps) 3. Internet traffic is now so heavily localized (as in 75% of telephone calls are across town type of thing but for the Internet) 4. Ad revenue will cover the cost/or subsidize significantly of DSL 5. 90% of Internet bits will be video traffic 6. VoIP traffic exceeds the PSTN traffic 7. Private networks predominantly migrate to overlays over the Internet 8. Wireless Internet Service Providers (WISPs) are serious competitive threat to DSL and Cable Internet 9. Sprint is bought by Time Warner 10. Cable companies form cabal & hookup with Sprint or Level 3 11. Government passes Net Neutrality Law of some flavor 12. Earthlink successfully reinvents themselves as Wireless Metro player in Response to ATT and Verizon 13. 40% paid or subscription as opposed to Content Click Ads. Like Cable Company channel packages, folks will flock to subscriptions for Internet Content packages. 14. RIAA proposes surcharge on network access (like Canada tax on blank CDs) 15. NetFlix conversion to Internet delivery of movies to Tivo or PC, or open source set top box 16. ISPs will be in pain 17. Last mile (fiber, wireless, …) in metro will be funded by municipal bonds 18. Death of TV ads, Death of broadcast TV, Tivo & Tivo like appliances all use the Internet with emergence of targeted ads based on demographic profiles of viewer 19. Google in charge of 20% of ALL ads (TV, Radio, Billboards, …) 20. Ubiquitous wifi in every metro with wifi roaming agreements 21. Congestion issues drive selective customer acceptance of partial transit offerings 22. IPTV fully embraced by cable cos – VOD – no need for VDR and ala carte video services replace analog frequency 23. Near simultaneous release of movies to the theaters, DVDs for the home, PPV, and Internet download to meet needs of different demographics. (Some get dressed up for theater, others have kids and can't leave home, others wantto watch on the flight to Tokyo – all watch the new release movie at about the same time) Video Peering -------------------- For what it is worth, some of this resonates with the Peering BOF Video Peering discussion. With YouTube pushing 20Gbps after only one year in existance, and with the 30+ companies that often chase a high profile market such as theirs, we have a potential additional Internet load approaching 600Gbps! YouTube at the BOF said that their traffic is growing at about 20% per month, so it may be reasonable to expect their traffic to double a couple times over the next year. Even if you discount the competitors traffic flows, video still appears as a *massive* traffic volume coming into the Peering Ecosystem over the next bunch of months. And yes, they are willing to peer the traffic for free so you eyeball networks and they (YouTube) don't have to pay transit fees on the traffic. Bill -- //------------------------------------------------ // William B. Norton <wbn(a)equinix.com> // Co-Founder and Chief Technical Liaison, Equinix // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton

2 2

insane over-regulation - what not to do
by Randy Bush 21 Jun '06

21 Jun '06

just so one can see how deep in a hole things can go if no grownups are present, look at what ghana is about to do to kill the goose that laid the golden egg http://rip.psg.com/~randy/ghana-insanity.pdf randy

6 7

Silicon-germanium routers?
by David W. Hankins 21 Jun '06

21 Jun '06

IBM and Georgia Institute of Technology are experimenting with silicon- germanium, it is said here: http://tinyurl.com/g26bu I find this interesting having just attended NANOG 37 where some manufacturers of network devices told us in a panel that network heat problems weren't going away unless there's a 'next big thing' in manufacturing process. Is this it? Corrolary: If our routers are made of silicon-germanium, would the CLI only operate in Deutsch? -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins

6 8

RE: key change for TCP-MD5
by Bora Akyol 20 Jun '06

20 Jun '06

Good comments, please see inline: > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net] > Sent: Tuesday, June 20, 2006 2:06 PM > To: Bora Akyol; nanog(a)merit.edu > Subject: RE: key change for TCP-MD5 > > At 12:12 PM 6/20/2006 -0700, Bora Akyol wrote: > > >The draft allows you to have a set of keys in your keychain and the > >implementation tries all of them before declaring the segment as > >invalid. > > DoS against routers is of course a major concern. Using > encryption has the potential of making DoS worse, in the > sense that the amount of processing that a bogus packet can > cause is increased by the amount of processing needed to > check the authentication. If the router needs to check > multiple keys in the keychain before declaring the segment as > invalid, then this multiplies the effect of the DOS by the > number of keys that need to be checked. Ross The DOS is a concern whether you have a valid key or not, correct? I can DOS the router with fake packets that it needs to verify as long as I want. All the multiple keys do is to decrease the cost of the DOS. For example, if we allow 4 keys at a time and the router dies at a 100 Mbps attack traffic, now it will die at 25 Mbps. While this may look like a big deal, I think the dark side has enough firepower that essentially 25 equals 100. For device vendors, they need to solve this problem regardless of the number of simultaneous key checks. For example, they can use a TCP-offload-engine for their CPU. The TOE engines are being used in servers for a long time now. If DOS is such a large concern, IPSEC to an extent can be used to mitigate against it. And IKEv1/v2 with IPSEC is not the horribly inefficient mechanism it is made out to be. In practice, it is quite easy to use. > >No time synchronization required. No BGP message required. > > > >The added cost for CPU-bound systems is that they have to try > >(potentially) multiple keys before getting the **right** key but in > >real life this can be easily mitigated by having a rating > system on the > >key based on the frequency of success. > > This mitigates the effect of authenticating valid packets. > However, this does not appear to help at all in terms of > minimizing the DOS effect of an intentional DoS attack that > uses authenticated packets (with the processing time required > to check the keys the intended damage of the attack). > > Ross Please see my comments above. Regards Bora

1 0

Contact info for MSN.com NOC?
by Reid Knuttila 20 Jun '06

20 Jun '06

NANOG Subscribers, I'm not sure if you've ever attempted to contact the MSN (Microsoft Network) NOCC, which would be AS 8075, or 207.68.160.0/19, but their ARIN WHOIS listed phone numbers are all going to a central receptionist - +1-425-882-8080, who won't help at all, and won't put you me in contact with the NOC. It appears that their ARIN WHOIS information a black hole. I've got a customer who's recently assigned network block (from ARIN) is being blocked from access to MSN.com, and they would sure love to have their Hotmail working again. Anyone know who to contact over there? Thanks, Reid Knuttila Senior Network Engineer Onvoy, Inc.

2 1

RE: key change for TCP-MD5
by Bora Akyol 20 Jun '06

20 Jun '06

The draft allows you to have a set of keys in your keychain and the implementation tries all of them before declaring the segment as invalid. No time synchronization required. No BGP message required. The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key but in real life this can be easily mitigated by having a rating system on the key based on the frequency of success. Regards Bora > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Iljitsch van Beijnum > Sent: Monday, June 19, 2006 10:22 AM > To: Randy Bush > Cc: NANOG list > Subject: Re: key change for TCP-MD5 > > > On 19-jun-2006, at 19:10, Randy Bush wrote: > > >>> try reading more carefully > > >> Didn't help... > > > how sad, as the whole document is about how to usefully be able to > > introduce and roll to new keys without agreeing on a narrow time. > > Well, as you can tell from my message just now, I don't think > going from agreeing on a narrow time to agreeing on a wider > time is worth the trouble, especially since by adding a BGP > message it would be possible to roll over if and as soon as > both sides are ready, removing the "wait for some time and > then see whether the other end really installed the new key" > part from the proceedings. > >

5 6