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

From: Thomas Hardjono <[email-masked]>
Date: Thu, 21 Mar 2002 10:43:25 -0500

Mark,

Just as a follow-up on your PIM WG presentation on the 6 possible options
to provide authentication (ie. group-authentication) to PIM control messages
that are multicasted within a domain/AS.

To recap, we assume there are N routers in a domain, each one of the
N routers could multicast a control message to the others.
The suggestion was for all of them to use a single SA and same group-key.

Option 5 (or 6 ?) was for PIM to introduce a sequence counter at
the PIM level, since the IPsec (AH or ESP) sequence counter would
not work (or would be ignored).  The PIM-level sequence counter
would make-up for the loss of replay-protection at the IPsec level.

Its worth mentioning that this approach also has the potential
for DoS attack at the IPsec level.  Any host in the network that
can capture one of these control messages would replay it (unmodified)
to the multicast address (resulting in the packet being received
by all N routers). A router would do IPsec parsing/processing
at the IPsec layer (which would ignore the IPsec counter) and would pass
the result up to the PIM level, only to find that the PIM packet
is a replay (and drop it).

Thus, the option of using IPsec as is but ignoring IPsec replay-protection
opens the possibility of the routers being bogged down in IPsec processing
of replayed control messages.

Hope this helps.

thomas
------

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 21 Mar 2002 14:46:31 -0500

At 3/21/2002||11:15 AM, Mark Handley wrote:

>Maybe I've being naive, but I don't think this is any better or worse
>that a regular DoS attack on IPsec AH.
>
>In our option 5, the router needs to check IPsec before it can check
>the PIM-level replay protection, so an attacker can replay packets and
>force IPsec to waste cycles checking the MAC.
>
>In regular IPsec AH, if I can watch the wire, I can see the sequence
>numbers.  Thus I can generate a spoofed packet that will pass the
>sequence number check, even though it will have a bad MAC because I
>don't know the key.  The router still needs to check the MAC to reject
>such packets.
>
>In either case, an attacker on the wire can force the router to check
>the MAC, so I don't see that there's any practical difference between
>the two.
>
>What did I miss?
>
>Cheers,
>         Mark

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.

cheers,

thomas
------

---

From: Mark Handley <[email-masked]>
Date: Thu, 21 Mar 2002 11:15:47 -0800

What did I miss?

Cheers,
	Mark

---

From: Beau Williamson <[email-masked]>
Date: Fri, 22 Mar 2002 10:02:23 -0600

>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 to 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 still seems to me that we need a "good enough" solution to avoid some other non-local wire DoS attack scenarios of PIM control messages.  OSPF uses MD5 , why wouldn't this (or something similar) be "good enough" to allow us to move forward?

Beau Williamson

---

From: Mark Handley <[email-masked]>
Date: Fri, 22 Mar 2002 09:57:34 -0800

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

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 22 Mar 2002 13:35:57 -0500

> 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

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

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 22 Mar 2002 13:44:29 -0500

On Fri, 22 Mar 2002 09:57:34 -0800
> the vendors already have the code to do it.

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

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

Marshall