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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing

"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.

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.

-- 
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
Follow-Ups: References: