June 2006 - NANOG - lists.nanog.org

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

Re: VoIP calea interfaces
by Eric A. Hall 20 Jun '06

20 Jun '06

On 6/20/2006 2:57 PM, Hoffpauir, Dusty wrote: > The FCC/FBI have left it up the industry to define a standard, they are > not defining it themselves. Right. But they do have veto power, and they do not appear to have given approval yet. Meanwhile the deadline continues to close. This is an awkward situation. > There are 2 "standards" being discuss/worked on for packet delivery of > intercepted voice and call data. One is being done by ATIS and is t1.678 > which is still in draft. The other is packetcable by cable labs and > that's been in use and on going for a couple of years now Yeah those are mentioned in FCC-05-06 as near completion. It looks like t1.678 is most applicable to the area I'm primarily interested in, since it describes voice-over-packet interfaces in general, and mappings for SIP and H.323 in particular (although it seems that the LEA interface is undefined, and also seems to assume some kind of circuit- or local delivery, all of which is quite curious--this is what the IETF guys call out as hand-waving). > Cisco is packet cable compliant today. For the DOCSIS equipment you mean? That's a whole 'nother world from the RFC3924 stuff. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

1 0

Anyone from Akamai on the list?
by Amar 20 Jun '06

20 Jun '06

Please contact med off list. tia -- amar

2 1

RoadRunner security
by Chris Horry 20 Jun '06

20 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A general question to the list about RoadRunner security... I've been receiving a DNS flood from either a malicious, or badly configured IP in Taiwan since last Thursday. I've contacted the ISP responsible, but if the owner of 140.116.23.19 would mind shutting the damn thing down I'd be really grateful. :) I'm filtering it at my firewall but the router the RoadRunner controls is happily sending the packets to me still and causing slowdown. After 3 days of convincing them that it wasn't actually my network generatign the traffic, RoadRunner's front line loonies have told me basically, nothing we can do to filter that, sorry. Does anyone have a contact at RoadRunner who has a clue? Chris - -- Chris Horry KG4TSM "A conservative is a man with two perfectly zerbey(a)wibble.co.uk good legs who, however, has never learned how http://www.wibble.co.uk to walk forward". -- Franklin D. Roosevelt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmAQOnAAeGCtMZU4RAnqJAKCOvS1JYnzwYA0v8kVparE4v37HygCgiEgi 5SSItbjyu2bfYXRBFILjy7w= =RCnB -----END PGP SIGNATURE-----

2 1

key change for TCP-MD5
by Steven M. Bellovin 19 Jun '06

19 Jun '06

I just submitted an I-D on TCP-MD5 key change. Until it shows up in the official repository, see http://www.cs.columbia.edu/~smb/papers/draft-bellovin-keyroll2385-00.txt Here's the abstract: The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. Comments welcome. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

6 11

Interesting new spam technique - getting a lot more popular.
by Suresh Ramasubramanian 19 Jun '06

19 Jun '06

http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used… Does seem to have potential, because at least one large webhost says they got bit hard by this (when they asked me to unblock one of their /24s) - and I've been seeing the same type of spam for quite some time [pizzabox cpanel servers running exim, but emitting porn spam with completely different hostnames and qmail headers] <quote> So this brings us today to a new technique reported by Stephen Satchell of satchell.net last Thursday. It reads almost like a mystery novel, involving cloaking, promiscuous interfaces, stolen IP addresses, and tunneling. It gets a little tricky, so follow the bouncing ball: * The spammer obtains a dedicated server at the victim service provider. The server shares a subnet with other customers. * A spamware daemon is installed on the dedicated server, to keep the network interface in promiscuous mode * The daemon determines which IP addresses on the local subnet are not in use. It also determines the addresses of the network routers. One or more unused IP addresses are commandeered for use by the spammer. * The perp server sends unrequested ARP responses to only the gateway routers, so that the routers never have to ask for a layer-3 to layer-2 association -- it's alway in the ARP cache of the routers. Nobody else sees this traffic in an EtherSwitch fabric, so ARPWATCH and its kin are defeated. Pings and traceroutes also fail with "host unreachable.". The daemon then only has to watch on the NIC, in promiscuous mode, for TCP packets to the hijacked address on port 80, and pass them down the tunnel to the remote Web server. * Finally, GRE and IPIP tunneling is used to connect the stolen IP addresses to the spammer's real servers hosted elsewhere. The end result is that the spammer has created a server at an IP address which not even the owners of the network are aware of. There are a number of ways you can protect your own network from from this exploit: * Give each customer their own subnet. * Null-route unused IP addresses in your network space, or otherwise make sure that there's a legitimate server somewhere that will claim them. * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. </quote> -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

20 30

Possible IAB workshop on routing and addressing participants?
by David Meyer 19 Jun '06

19 Jun '06

Folks, The IAB is considering holding a routing and addressing workshop, perhaps in the fall 2006 time frame (see the draft invite below). We're in the process of collecting potential participants, so please pass along any the names of folks that that you think would be productive participants. Thanks, --dmm (for the IAB) ---- Greetings, The IAB is sponsoring a workshop on "Scalable Routing and Addressing Architectures for the Internet" in order to foster interchange between the operator, standards, vendor, and research communities on this important topic. You are being invited to participate in this effort. This workshop effort will consist of mailing list discussions in advance of, and after a face to face meeting. The technical goals of this effort are outlined below. We believe these are the critical elements to fostering a constructive discussion of important routing and addressing technical work going forward and are soliciting workshop participation to work towards those goals. Should you decide to join us in this workshop, you will be expected to attend the face to face meeting [0], contribute to (and possibly present at) that meeting, as well as follow and participate in the mailing list discussions. The most important objective of the workshop is to foster and encourage innovative thinking in an area where there has been little fundamental change for the last twelve years. As such, the primary goals of the workshop include the following two items: (i). Produce a concise problem statement that will serve as the input to future work on this topic. This problem statement will include, among other things, a list of the problems with the current routing and addressing architecture. These include (but are not limited to): - The difficulty in changing provider due to PA/CIDR addressing schemes - The lack of effective multi-homing support - Limited capability to protect against either the spoofing of individual host IP addresses or entire IP address blocks - The limited ability to secure the routing system itself, and (ii). Produce a prioritized list of requirements, all of which must be met by a next generation routing and addressing architecture. A sample list might include (in no particular order): - Retaining the connectionless datagram model of IP routing - Allow users (small and large) to freely switch between providers without substantial service interruption - Include survival of higher-layer connections and associations when connectivity to individual providers changes - Allow both users and ISPs to influence path selection according to traffic management and classification requirements - Provide better support for mobility and nomadicity - Provide architected instrumentation facilities - Allow at least one-to-many multicast - Prevent source address spoofing - Provide a rational economic basis for deployment - Secure the routing infrastructure, including the authentication of updates and the unauthorized injection of information into the routing system - Define scalability requirements for a next generation routing system - Have architected transition mechanisms and be incrementally deployable (where possible) During the workshop, scribes will be assigned to summarize the discussion. Post-workshop, scribes will be expected to participate in finalizing the workshop report. All participants will be expected to review the draft workshop report before publication. The workshop is <date, <logistics. Please reply within the next week indicating your willingness to participate in this workshop. Please indicate whether (and to what extent) you'd be able to participate (we'd like an explicit 'no' if you will not be able to), and what you feel is your area of expertise. If you can not participate, please suggest potential alternatives or substitutes. [0] Attendees will also need to arrange and pay for their own travel and accommodations.

1 0

RE: WSJ: Big tech firms seeking power
by John van Oppen 18 Jun '06

18 Jun '06

I can tell you that my home residential rate is just under 6 cents (after taxes) in eastern Washington and that you are in the ballpark with your large commercial customer numbers (irrigators get 2.5 cent rates). We work with another PUD in the area on data center type apps and find the pricing to be amazing when compared to other areas. There is also access to large amounts of water (for evaporative cooling as an example) in a lot of areas due to the ability to transfer water rights from agriculture to commercial use. If anybody really wants more info, email privately. John :) -------------------------------------------- John van Oppen PocketiNet Communications Technical Operations "Guter Rat ist teuer." --Unbekannt Main: + 1 (509) 526 - 5026 Direct: +1 (509) 593 - 4707 -------------------------------------------- -----Ursprüngliche Nachricht----- Von: chuck goolsbee [mailto:chucklist@forest.net] Gesendet: Friday, June 16, 2006 10:48 AM An: nanog(a)merit.edu Betreff: Re: WSJ: Big tech firms seeking power >I wonder just how much power it takes to cool 450,000 servers. I've heard mumbles that the per kWh rates from Bonneville in the locations along the Columbia are in the sub-4¢ range. Grant county is seeing a huge fiber building boom as a result. It will be more wired up than King county soon. Woody was here last night and remarked (feel free to correct me if I misquote you Bill) that it was funny that nowadays "network geeks were more interested in kilowatts than kilobits" --chuck (in Seattle)

1 0

WSJ: Big tech firms seeking power
by Sean Donelan 17 Jun '06

17 Jun '06

Since power consumption was a topic at the last NANOG meeting. subscription required, or buy a copy of the Wall Street Journal from a newstand http://online.wsj.com/article/SB115016534015978590.html Surge in Internet Use, Energy Costs Has Big Tech Firms Seeking Power By KEVIN J. DELANEY and REBECCA SMITH Wall Street Journal June 13, 2006; Page A1 With both Internet services and power costs soaring, big technology companies are scouring the nation to secure enough of the cheap electricity that is vital to their growth. The search is being led by companies including Microsoft Corp., Yahoo Inc. and IAC/InterActiveCorp. Big Internet firms have been adding thousands of computer servers to data centers to handle heavy customer use of their services, including ambitious new offerings such as online video. [...]

16 23

Re: WSJ: Big tech firms seeking power
by David Lesher 17 Jun '06

17 Jun '06

Speaking on Deep Background, the Press Secretary whispered: > > > > I wonder just how much power it takes to cool 450,000 servers. > ..... > KwH = $111,000 /month in cooling. I don't know the area; but gather it's hydro territory? How about water-source heat pumps? It's lots easier to cool 25C air into say 10-15C water than into 30C outside air. Open loop water source systems do have their issues [algae, etc] but can save a lot of power.... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

4 3