Subject: Fwd: [pim] Re: [GSEC] DoS attack possibilities with PIM counter (and no IPsec replay-protect)

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 22 Mar 2002 14:56:09 -0500

Sorry - this keeps bouncing...

--- the forwarded message follows ---

Subject: Re: [pim] Re: [GSEC] DoS attack possibilities with PIM counter (and no IPsec replay-protect)
From: Marshall Eubanks <[email-masked]>
To: Mark Handley <[email-masked]>
Cc: Beau Williamson <[email-masked]>, Thomas Hardjono <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 22 Mar 2002 13:35:57 -0500

Mark Handley wrote:

>>At 01:46 PM 3/21/2002, Thomas Hardjono wrote:
>>
>>>I was thinking that option 5 required IPsec to be modified
>>>to pass MAC checking over all the usual fields except the sequence number.
>>>
>>>Thus, this is the case where all the IPsec and crypto checking
>>>works out (since the IPsec seq# is ignored), but the packet fails
>>>the (new) PIM counter at the PIM level.
>>>
>>>But you're right: wasting CPU through sucessfull MAC (then dropped packet) or
>>>failed MACs has the same DoS effect.
>>>
>>Thomas, Mark, et al,
>>
>>Isn't this sort of attack only possible with a node on the local wire?  If so,
>>do we really think that this scenario carries such a high risk that we have t
>>o implement a lot of complex crypto based techniques to avoid it?
>>
>>I'm not security expert (by any means) nor am I an IPsec guru. However, it sti
>>ll seems to me that we need a "good enough" solution to avoid some other non-l
>>ocal wire DoS attack scenarios of PIM control messages.  OSPF uses MD5 , why w
>>ouldn't this (or something similar) be "good enough" to allow us to move forwa
>>rd?
>>
> 
> Actually IPsec AH can use MD5 (amonst other algorithms of similar
> complexity).  Thus this isn't really complex crypto.  All IPsec buys
> us over doing our own MD5 authentication is that security people have

MD5 (as opposed to HMAC MD5 _with a secret key_) is no longer secure and 
should not be used.

I have been told that the IESG will no longer approve MD5 based
security solutions, which IMHO is the correct course.

Marshall

> already thought the issues (or at least most of the issues), and all
> the vendors already have the code to do it.
> 
> We're definitely not talking about doing public-key operations on PIM
> Join messages.
> 
> Cheers,
> 	Mark
> 

-- 
                                  Regards
                                  Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html