[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
On Mon, Jan 31, 2000 at 08:09:05AM +0200, Ari Huttunen wrote:
> "Michael H. Warfield" wrote:
> > On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote:
> > > Switching to TCP does nothing. If you naively implement ISAKMP on top
> > > of TCP, then you must include TCP SYN spoof protection, which is much more
> > > difficult to deploy and hard to provide different levels of protection for,
> > > say, HTTP servers vs ISAKMP daemons.
> > I believe the arguement was that the problem with creating state
> > due to spoofed packets could have been avoided. It has nothing to do with
> > tcp vs udp. I'm not at the bottom of it yet, but it appears that some
> > bad choices may have been made and some issues were not been given the
> > serious consideration they deserved.
> The problem of creating state, or 'cookie crumbs' can be successfully avoided
> in at least some of the cases. The basic idea is for the entity that normally
> would hold the state to encapsulate the state in a "state payload", and send
> that back to to the other entity. The "state payload" would be unforgeable by
> the peer, because it has been signed by the entity that created it (using
> private key crypto.) When the next protocol message is to be processed, the
> entity uses the state in the "state payload" and the other fields contained
> in the message to process the message. Only the information needed to verify
> the signing on the "state payload" needs to be retained, and that can be shared
> with all the connections.
This is good... We have a working DoS exploit, so now we need
a way to address the problem. This should be incorporated into the
standard, since there are vulnerable implimentations being fielded right
now. If we can avoid this one, lets do it and get it out of the way.
The things that disturb me are "can be successfully avoided in
at least some of the cases". If it could have been avoided it should have
been and I wonder why it wasn't in the first place. If you say "at least
in some of the cases", does that mean that there are some cases where it
can not be avoided. If so, then we haven't eliminated the problem, we've
merely made it more difficult to exploit. I'm not totally sure that's much
of a gain.
> The idea is from the paper:
> Tuomas Aura and Pekka Nikander, "Stateless connections", in proceedings of
> International Conference on Information and Communications Security
> ICICS'97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334,
> Springer Verlag 1997.
> http://www.tcm.hut.fi/~pnr/publications/index.html
> This "state payload" is about the same idea that I've written about in
> my previous postings about the DoS attack, but at that time I didn't use
> the same terminology or encapsulate the information in one place.
> The "state payload" can be used by only some of the entities in the
> Internet if we give it the following rule:
> - If a "state payload" is received in message N by entity A, entity
> A must include the "state payload" in message N+1 sent by entity A,
> without any modifications to its contents.
> This puts all of the responsibility for the security properties of
> the "state payload" to the entity that uses it. (And ultimately to
> IETF to specify safe usages for it.)
> If there's interest for the "state payload", I can write it in the
> form of a draft.
I would personally say so... I would like to see if this could
be implemented and effectively nullify this attack.
> --
> Ari Huttunen phone: +358 9 859 900
> Senior Software Engineer fax : +358 9 8599 0452
> F-Secure Corporation http://www.F-Secure.com
> F-Secure products: Integrated Solutions for Enterprise Security
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
References: