Are RSA opertaions cheap? (was Re: Suggestion for SOI wrt PFS)

[Jan Vilhuber <vilhuber@cisco.com>]

On Sun, 31 Mar 2002, Angelos D. Keromytis wrote:

>
> In message <Pine.LNX.4.33.0203311507080.21949-100000@janpc-home.cisco.com>, Jan
>  Vilhuber writes:
> >
> >In other words they are NOT cheap, but the cost is bearable, when you
> >have to do only a small/limited number of them.
> >
> >"RSA operations are cheap, except when they are not". Bogus.
>
> Cost is always measured in comparison to the task at hand (and the derived
> benefit).
>
> >Not everything has hardware support and not every device has a P6 1GHz...
>
> I never said that everything has hardware support (so why do you keep
> repeating it ?); and the numbers I posted a few weeks ago were from a
> more moderate box than a P6 1GHz...
>
> My home IPsec gateway is a 450Mhz Pentium (a low-power SBC), but has no
> problem establishing a few tunnels every 20 minutes --- despite in fact
> doing full certificate verification and RSA signature (oh, and PFS). I'm
> giving you some facts -- something I haven't seen from you yet.
>

OK.. numbers: My ipsec gateway here at home is a cisco 806, with a MPC
855T RISC, 50Mhz. When I'm on a voice call (goes over the ipsec
tunnel), and I log into the router using SSH (2 RSA operations, if I
recall that protocol), the voice quality is severely impacted for the
duration (about 1 second).

Now you could with some justification argue that this is not a great
ipsec gateway. I've long argued that we (cisco) need stronger
processors and a bunch of other stuff I won't get into here. The folks
that build and sell the hardware have their own priorities, and I have
to work with what I get. We're not talking PC's here, afterall. We're
talking smallish devices.

You'd probably see the same symptoms (substitute voice traffic for
simple data traffic) on your other example from a few weeks ago: The
palm pilot. I know there are ipsec clients for palm pilots (why you'd
want to is a bit beyond me, but it seems some people have a legitimate
use). I'd be willing to bet money that if you did an rsa operation,
that traffic would effectively stop flowing for the duration of the
rsa operation. Or the operation would take forever, meaning you'd have
to tweak the implementation with nice long timeouts.

But as I said earlier: The end-stations REALLY aren't the issue at
all. It's the concentrators that have to terminate a large number of
connections. RSA is not cheap. It's merely acceptable when you have
plenty of CPU and don't do them often.

The question you must ask yourself is: Do you want ipsec to be
ubiquitous, i.e. useful on as many devices as we can make it work for?
Or do you only want it to be used in situations where people have
450MHz pentiums available? As you may or may not have noticed, many
groups in and outside the IETF are having to come up with their own
keying schemes because IKE won't work for them. I've heard "Oh
please... not IKE" so many times its ridiculous. Protocol complexity
has something to do with it, but as Mike Thomas pointed out in another
posting, there were cases (packetcable just one of them) where the
computations necessary were simply unreasonable.

This will always happen, of course. There'll always be applications
for which IKE (of JFK or IKEv2) won't be suitable. It's our job to
make the protocol as useful as possible, though. Throwing RSA
operations around like candy at a Mardi Gras parade simply won't do.

I'm all for simplifying the protocol, where appropriate, i.e. where it
doesn't impact usability.

> >> of hundred, even on a moderate box. And I've seen no argument (let alone a
> >> convincing one) why you'd need massive amounts of tunnels/sec (your IPsec
> >> gateway likely won't be able to handle traffic for them anyway).
> >
> >Certainly not if we have to constantly do rsa operations for every
> >transaction, that's true.
>
> So you're saying that you *do* have a business need for a box that can
> support a sustained SA setup rate of 1000 tunnels/second ? Could you
> expand on it ?

Sure. You do the math: How many ipsec peers would it take, rekeying at
(your example) every 20 minutes, to give me a sustained rate of 1000
tunnels per second?

The more I reduce the number of heavy operations (RSA, DH, etc..), the
greater the number of IPsec peers I can support on a given
hardware.

Agreed? No number needed. This is common sense.

Why would I NOT want to maximize the number of IPsec peers I can
handle? Doesn't everyone have a business need to maximize the use of
their hardware? If I have one keying scheme where the number of peers
I can support is 1 million, and there's another scheme where (all
things being equal) the number of peers I could handle is 3 million,
which do you think I should pick? Which do you think I should work
towards?

jan
 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847