Derek, I agree that the stateless cookie is very important. However there is no value in the stateless cookie unless you also have the ability to filter out DoS attacks from fixed IP addresses. This being the case I would rather unpack the stateless cookie and make it a part of a DoS package. I much prefer the following scheme: 1) All Initiators (aka clients) MUST be capable of repeating a request with a stateless cookie if required 2) Responders MAY respond to a cookie-less request by requesting a cookie. This allows the 2 round trip JFK scheme to be reduced to 1 required and 1 optional round trip. A responder that is not going to do anything more sophisticated can require cookies on every request. It is not much more work to only require cookies on an 'as necessary' basis. A responder that has code to deal with the DoS from fixed IP address problem would not be impacted in a major way. Remember that if we do cookie protection well it becomes unnecessary because there is no point in an attacker trying that approach. So 1 mandatory + 1 optional round trip becomes on average 1 round trip. There is a major performance difference between 1 round trip and 2 on many of the wireless applications. Certainly when it comes for Web services I will be pushing for a generic DoS protection mechanism for Web services generally (i.e. at the SOAP layer) rather than a mechanism that is limited to one specific protocol such as XKMS or XKASS. As for the rest of Charlie's list. I would very much like to define an IPSEC subset that is as streamlined as possible and does go to the trouble of removing unnecessary junk. I do not believe that the current set of specifications built arround the capabilities of engineering workstations is viable when applied to low cost embedded devices. As to Charlie's point about 'the cost of argument'. It is notable that most of the advances in computer science come from throwing junk out rather than adding more. Java is only interesting because it chucked out the junk in C++. C was interesting because it chucked out the junk of CPL. It is very easy to develop an ADA in committee. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Wednesday, February 13, 2002 2:04 PM > To: Charlie_Kaufman@notesdev.ibm.com > Cc: Khaja E. Ahmed; Dan Harkins; Paul Hoffman / VPNC; > ipsec@lists.tislabs.com > Subject: Re: RESEND: Thoughts on identity attacks > > > Charlie_Kaufman@notesdev.ibm.com writes: > > > I believe many features in IKE are in the category of > "seemed almost free" > > at the time, and so are included without any demonstrated > need. Identity > > hiding is one. Stateless cookies is another. The ability to craft > > incredibly > > complex combinations of crypto algorithms and ESP/AH/IPCOMP > combinations > > is a third. Having a phase I and a phase II is a fourth. > > I think stateless cookies are extremely important to protect against > resource starvation attacks (ala the TCP SYN attack). If I can cause > your IKE daemon to store a lot of state by sending it a single > (forged) UDP packet, I can effectively starve your system. With > stateless cookies you at least have reachability to gain a better idea > who is trying to attack you -- the attacker must be somewhere on the > path between you and the IP address being used to attack you. > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available >
Phillip Hallam-Baker (E-mail).vcf