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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing

Hi,
I also think IKE should be more DoS resistant.
At least, we have three problems:
(1) Cookie-related state
(2) other state
(3) computational load (as heavy as modular exponentiation).

Regarding statelessness, Pekka's idea is excellent and
referred in
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt
with a corrected use of ISAKMP Cookies.
The draft also presents how to save computational power
against DoS.
This works better if combined with the stateless connection
as described in the draft.
Any comments welcome.

Unfortunately I couldn't be at the coming IETF meeting.
I do not mind anyone else's introducing my draft
into the discussion in IKE modification.

Thanks,

"Michael H. Warfield" <mhw@wittsend.com> wrote:
>>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.

---- **** ----
 Kanta MATSUURA, Ph.D.
  Lecturer
  3rd Department,
  Institute of Industrial Science, University of Tokyo,
  Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN
    Tel: +81-3-3402-6231 (ext. 2325)
    Fax: +81-3-3479-1736
    E-Mail: kanta@iis.u-tokyo.ac.jp