Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle.

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 26 Jul 2002 10:16:02 -0700

-----Original Message-----
From: Michel Py [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 10:53 PM
To: Charles Lynn
Cc: [email-masked]
Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle.

--snip--

My feeble understanding is that IPSEC, as I know it, and specifically
the establishment of the SA, will require several back-and-forth packets
that will introduce an unacceptable latency (I'm happy to provide any
detail you wish about it, but I think they would be o/t for here).

[Gregory] The back-and-forth packets are not actually from the IPsec, but
from the IKE, the negotiation of the IPsec SA/keyes. Today, that negotiation
is 6 packets, three in each direction. And yes, we have seen that in the
wild it can take up to 4 seconds using Pre-Shared Secrets, and quite a bit
longer, up to 10 seconds or more, if using Certificates are used (especially
long when a Revocation List must be retrieved to check peer's certificate
status is not revoked) to complete the full IKE/IPsec negotiation.

[Gregory] IPsec itself actually requires no in-band negotiation. The sa and
keys can be manually entered on both sides. But we have found this
completely unscalable and difficult to manage. In addition, it ultimately
leads to poorer security, because operators set the SA parameters and keys
once and then forget about them; key freshness becomes an issue.

[Gregory] I don't believe this info is o/t. I provide this info for others
(sounds like you already know it) for this reason: if RPsec is going to
sooner or later require some crypto mechanism for auth/privacy/data
integrity/non-repudiation/anti-replay, then we are going to need to consider
the key negotiation overhead of the system, and how that will affect
adjacency establishment, timeouts, etc.

Also, there have been extensive concerns on the ipv6mh mailing list
about "crypto DoS", which is that it is easier to DoS a router that uses
crypto by feeding it encrypted packets full of foo (the rationale being
that most routers can't handle decrypting packets at line speed), vs. a
brute-force bandwidth based DoS.

[Gregory] In the case of IPsec (if I understand that stuff correctly), this
type of DoS attack would necessitate the packets be spoofed in two ways -
(1) the SPI would have to match an existing SA, and (2) the correct source
address for that SPI would have to be injected. If those two look correct,
the receiver would first do a authentication check on the HMAC signed
portion of the packet for that SA. Assuming the attacker did not crack the
auth key, that would fail, no further decrypt would be done. So the question
is whether the router would keel over on the auth checks, assuming (1) and
(2) were learned and done successfully.

To push it to the extreme, what I need is a one-way,
connectionless IPSEC ;-) 

Hopes this makes sense; if it does not please state it.
Michel.

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: [email-masked]
Date: Fri, 26 Jul 2002 15:25:59 -0500 (CDT)

> once and then forget about them; key freshness becomes an issue.

Correct. IKE is where the extensive negotiation occurs and the potential 
latency as well as the most obvious and easy to exploit DoS issues. See 
below.

> (2) were learned and done successfully.

While this might be possible depending on the AH/ESP implementation, the
real DoS problem with IPSEC is with IKE. Because it relies on UDP, many
implementations are vulnerable to complete CPU exhaustion (even remote
blind) usng only a small number of Message 1's (a fraction for non-crypto
based DoS's) because they start doing the RSA stuff immediately. This is
even the case with hardware accelaration.  However, I believe there are
various proposals in the works (such as JFK) to fix the DoS problem.

The following link provides a good discussion and source code (although 
the attack is possible with 2-3 lines of Python/Perl code).

http://alternic.net/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html

- mdf

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2002 18:12:04 -0400

-----BEGIN PGP SIGNED MESSAGE-----

{Gregory, your quoting style renders your posts nearly unparseable.
 Usenet style quoting is decade plus technology, and evolved for a good
 reason. Use it.}

>>>>> "Gregory" == Gregory Lebovitz <[email-masked]> writes:
    Gregory> [Gregory] In the case of IPsec (if I understand that stuff correctly), this
    Gregory> type of DoS attack would necessitate the packets be spoofed in two ways -
    Gregory> (1) the SPI would have to match an existing SA, and (2) the correct source
    Gregory> address for that SPI would have to be injected. If those two look correct,

  The replay counter is checked even before the HMAC is checked. It has to be
within a window, usually 64 packets, or the packet is discarded without any
crypto or hashing being done.

  That means that the attack has to observe actual traffic in real time, and
be able to inject DoS traffic in a timely manner. Operators have pointed out
that is it trivial for an employee of an ISP to have all the required access
as part of their regular job. 

  On the other hand, such an employee likely also has access to the router
configurations and could simply redirect all packets to another location.

  For regular BGP-type routing, I do not believe that there is any threat
that crypto can prevent - there are more trivial and more effective ways for
rogue employees (or crackers with enable access to core equipment) to mount a
denial of service attack. 

  IMHO, The major need to authenticate who may speak for which networks is
more of a protection against mis-configuraiton than against maliciousness.

  MHAP, on the other hand, is a potential route signaling protocol between border
routers of end-user networks to accomplish multihoming. The intermediary ISPs
are not necessarily friendly here, but I do not believe we can do better than
IPsec anyway.

]    Internet Security. Have encryption, will travel           |1 Fish/2 Fish [
]  Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F [
][email-masked] http://www.sandelman.ottawa.on.ca/ |strong crypto [
]    At the far end of some dark fiber - wait that's dirt!     |for everyone  [

---

From: Alex Zinin <[email-masked]>
Date: Fri, 26 Jul 2002 22:42:41 -0700

Friday, July 26, 2002, 10:16:02 AM, Gregory Lebovitz wrote:
...
> [Gregory] I don't believe this info is o/t.

Correct. Discussing applicability of existing security mechanisms
to RPs definitely belongs here... provided, of course, that we
don't spend till Atlanta discussing this instead of vulnerabilities :)

> (2) were learned and done successfully.

Besides, I've heard what people do is rate limit some stuff
that goes up to the control plane to make sure the CPU does
not go crazy even if an attack is mounted :)

Alex

---

From: Charles Lynn <[email-masked]>
Date: Sat, 27 Jul 2002 13:08:11 -0400 (EDT)

> > [Gregory] In the case of IPsec (if I understand that stuff
> > correctly), this type of DoS attack would necessitate the packets
> > be spoofed in two ways -
> > (1) the SPI would have to match an existing SA, and
> > (2) the correct source address for that SPI would have to be
> >     injected.

In a router, might not other packet characteristics, e.g., TTL and
incoming interface, be added to the list of pre-crypto checks that must
be satisfied?

> > If those two look correct, the receiver would first do a
> > authentication check on the HMAC signed portion of the packet for
> > that SA. Assuming the attacker did not crack the auth key, that
> > would fail, no further decrypt would be done.

Correct.

> > So the question is whether the router would keel over on the auth
> > checks, assuming (1) and (2) were learned and done successfully.

Yes.

> [Alex] Besides, I've heard what people do is rate limit some stuff
> that goes up to the control plane to make sure the CPU does not go
> crazy even if an attack is mounted :)

This can be broken into two parts: the functions that need CPU cycles
and the functions handled by the crypto hardware that the box would
likely have, at least if it was labeled "high performance".  Based on
what I've heard about modern crypto chips and the pre-crypto checks,
I do not think that this type of DoS is a particularly hard to solve
problem, at least if the router design criteria includes routing
protocol DoS prevention.

Charlie