- Test - lists.nanog.org

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

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