Hi Steve (Bellovin) --

Good to see you again at AES3.

I want to respond to your comments about key agility that you made at
AES3, and also in your note posted here at "[EMAIL PROTECTED]".

While key agility may be very important for some applications
(e.g. ATM networks), and while more key agility is clearly better than
less key agility, I must say that I don't quite buy the argument you
made at AES3 regarding its importance for IP traffic.

If we are talking IP traffic (as for VPN's---your example), then what
we care about is the distribution of packet sizes.  You mention that
many packets are very small (40--64 bytes), which is true, and then
"conclude" from this that key agility is particularly important for
such IP traffic.

I did a little research into Internet packet size distributions.  The
common folk theorem is that
        "more than half the `packets' are mice, but
         more than half the `payload' are elephants"
It is indeed the case that are many small packets, but the average packet
size is nonetheless quite large.

The most authoritative reference I could find is
        "Wide-Area Internet Traffic Patterns and Characteristics"
        (Extended version)
        http://www.vbns.net/presentations/papers/MCItraffic.ps
        (shorter version in Nov/Dec 1997 issue of IEEE Network)

The authors conclude (section 6) that
        -- "About 40% of all packets are 40 bytes."
but
        -- "Average packet sizes vary from 175 bytes to more than 400 bytes."
Their figure 4a suggest that the average packet size they observed may be
around 300 bytes.  

Suppose we accept this figure of 300 bytes as an average packet size.  This
amounts to about 19 AES blocks.  

If an AES key setup (subkey generation) takes as much time as k
encryptions, then key setup incurs a relative overhead overall of only
        k/(19+k)
For example, the Weaver et al. AES3 paper (on FPGA implementations), gives a latency
for RC6 of 102 cycles for encryption and 264 cycles for subkey generation.  An 
average packet of 19 blocks would take
        264 + 19*102 = 2202
cycles.  The additional overhead for subkey generation is only 264/1938 = 13.6%
While this is nonzero, it is certainly not a killer, and no cause for alarm.
(Moore's Law currently gives us about 1% a *week*...)  This argument gets
more complicated if you consider various pipelining modes, but I think the
point is made.  

* Conclusion: even though most packets are small, the fact that the    *
* average packet size for Internet traffic is nonetheless relatively   *
* large means that the average computational overhead for subkey       *
* generation need not be terribly large, even if subkey generation is  *
* relatively slow compared to encryption/decryption.                   *

I also note that the other statistics I could find seem to indicate
that the average IP packet size is *increasing* with time.   

Comments?  Have I overlooked something?

        Cheers,
        Ron Rivest

        
        

Reply via email to