[3369] in cryptography@c2.net mail archive
Re: Key setup time a real issue for IPSEC? Or not?
daemon@ATHENA.MIT.EDU (Steve Bellovin)
Thu Sep 24 16:32:23 1998
To: Ron Rivest <rivest@theory.lcs.mit.edu>
cc: cryptography@c2.net
Date: Thu, 24 Sep 1998 15:56:29 -0400
From: Steve Bellovin <smb@research.att.com>
In message <199809241744.NAA02344@swan>, Ron Rivest writes:
>
> John Kelsey says about the AES criteria:
> "There are some applications for which key agility is really
> important. IPSec is one example."
>
> I'm not convinced that this is accurate.
>
> What is the distribution of IPSEC packet sizes that one can expect?
>
> I asked Jim Gettys this question. (Jim works with the World Wide
> Web Consortium down the hall from me here at the Lab for Computer Science,
> and is the lead designer of the HTTP 1.1 web protocol.)
>
> Jim said that it is reasonable to take 512 bytes as a plausible average
> packet size today, and that this average should be going up over time
> as people move from HTTP 1.0 to HTTP 1.1.
>
> With a packet size of 512 bytes (32 AES blocks), the overhead for key
> setup is only 12.5%, assuming that a key setup takes as much time as
> four encryptions (typical for RC6 and some other candidates).
The problem is considerably more complex than that, even for
back-of-the-envelope calculations. The distribution of packet sizes is
quite skewed; last time I looked, about 40% of all packets were ~40
bytes long (http://www.nlanr.net/NA/Learn/packetsizes.html). In an
environment with many conversations with different peers, there will be
a lot of tinygrams, and hence a lot of key-switching. Nor am I
convinced that HTTP 1.1 will change that all that much; while we won't
see as many short packets for circuit open and teardown, we'll still
see lots of ACK packets.
As is often the case, the situation is very different for clients than
for servers. The former tend to have few peers at a time; the latter
tend to have very many. If we are ever to have ubiquitous IPSEC, we
need to accomodate the servers, too.
(As an aside, it's quite ironic to use packet size data to engineer our
cryptosystems, since the folks who collect that data have complained --
with some justice -- that IPSEC will destroy their ability to do so in
the future.)
