[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RESEND: Thoughts on identity attacks



Phill,

Have you read the JFK draft?


The idea of a generalized cookie mechanism for IP/TCP is something I've
toyed with. For applications where you don't necessarily want to do IPsec,
but DoS attacks are very important (e.g. wireless, specifically IP paging),
it would be nice if your access router could generate an
ICMP_ROUTABILITY_TEST message which would force the initiator to retry with
a nonce/cookie.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of
> Hallam-Baker, Phillip
> Sent: Wednesday, February 13, 2002 3:05 PM
> To: 'Derek Atkins'; 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
>
>
>
> 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
> >
>
>