Re: Choosing between IKEv2 and JFK

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 7 Mar 2002, Angelos D. Keromytis wrote:

>
> In message <Pine.LNX.4.33.0203071018040.27097-100000@janpc-home.cisco.com>, Jan
>  Vilhuber writes:
> >
> >In a pure peer-to-peer scenario, even 64 or so SA's won't present much
> >difficulty. But if a machine is an aggregator or a gateway terminating
> >the SA's, then you have to multiply the small to medium number of Sa's
> >per peer by the number of peers. That's not cheap.
>
> If you're using the same certificates/keys, then the caching I mentioned
> will help you.
>
> >You still need to go throught the rsa checks, even if you cache the
> >certificates, which, when you think orders of magnitude larger than PC
> >to PC communications becomes very expensive.
>
> You don't cache the certificates, you cache the result of the verification of
> the certificates. If you received the same set of certificates as an hour ago
> (when you established the SA last), and you verified all the signatures then,
> you don't need to re-check the signatures. You need to verify the RSA signature
> on the message itself.
>

That's what I meant.


> >Some people claim that rsa is 'cheap'. I tend to disagree (symmetric
> >cryptography is cheap). Yes, there's new hardware that can do it
> >fast. There's also old hardware that will want to run ikev2. The cost
> >of an rsa operation is not trivial, and when multiplied by large
> >numbers of peers becomes decidedly non-trivial.
>
> On an 850Mhz P3 IBM laptop running two network interfaces, doing bridging over
> IPsec (yes, really), playing MP3s, and running X (I'm sending this email from
> it), I get the following:
>
> nyarlathotep_JFK_38_$_openssl speed rsa
> To get the most accurate results, try to run this
> program when this computer is idle.
> Doing 512 bit private rsa's for 10s: 3102 512 bit private RSA's in 9.59s
> Doing 512 bit public rsa's for 10s: 35182 512 bit public RSA's in 9.56s
> Doing 1024 bit private rsa's for 10s: 554 1024 bit private RSA's in 9.62s
> Doing 1024 bit public rsa's for 10s: 11088 1024 bit public RSA's in 9.59s
> Doing 2048 bit private rsa's for 10s: 91 2048 bit private RSA's in 9.68s
> Doing 2048 bit public rsa's for 10s: 3297 2048 bit public RSA's in 9.60s
> Doing 4096 bit private rsa's for 10s: 14 4096 bit private RSA's in 9.70s
> Doing 4096 bit public rsa's for 10s: 957 4096 bit public RSA's in 9.65s
> OpenSSL 0.9.6b [engine] 9 Jul 2001
> built on: date not available
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx)
> compiler: information not available
>                   sign    verify    sign/s verify/s
> rsa  512 bits   0.0031s   0.0003s    323.3   3679.2
> rsa 1024 bits   0.0174s   0.0009s     57.6   1156.7
> rsa 2048 bits   0.1064s   0.0029s      9.4    343.4
> rsa 4096 bits   0.6931s   0.0101s      1.4     99.2
>
> Your concentrator is likely to be somewhat faster than this laptop.

Actually, no. Some maybe. Some won't be. Also, the speed of the
processor doesn't really matter, does it? If the speed of the
processor increases, the numberof tunnels per processor will likely go
up to, and customers generally want as many as possible.

If you give me a faster box, I'll just want more tunnels per
second. If I need 3 SA's per peer, I've just tripled the number of RSA
operations I need to do on an aggregator with a single-phase protocol.

Is there anyone that disagrees that for reasons of the replay
counter/window, you need multiple SA's per peer (for the same user!)
for QoS?  If so, let's discuss that, since that's more or less my
premise.


> I think
> that, even in software, it can deal with a few hundred RSA
> operations/sec.

Maybe. I still don't think rsa operations are cheap enough that we can
throw them around like candy and ignore the costs completely. If I can
cut the number of public key (rsa) operations down by half or down by
a factor of 3, I'm all for that. No need to be wasteful. No doubt'
it's one of those engineering trade-offs Radia talked about in an
email a few months ago.

Why not amortize that cost, while at the same time getting a "tunnel
management tunnel" for free, i.e. a phase 2, as long as it doesn't
overcomplicate the protocol? I'm willing to pay some complexity if it
buys me a better protocol (I realize that sentence has a lot of
subjective words in it, like 'complexity', 'better', and
'overcomplicate' ;), i.e. one with built-in keepalives/DPD,
informational exchanges, etc.

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