Re: replay field size

[Jim Thompson <[e-mail]>]

>   For the case where the algorithm is something new that appears in
> future that might be significantly stronger, then the limit of 2^^32
> might well be a significant issue.  With negotiable counter sizes or
> per-algorithm counter sizes, this would not be an issue.  With a fixed
> size counter, using 2^^32 for all time is an issue IMHO.  However,
> a 2^^64 counter space would not have that issue and would still be
> a fixed size counter.

If the application is (bulk) data xfer, then I most of the packets
will be MTU-sized (or PMTU, anyway, but for high-speed, these had
better match), and that for non data-xfer applications, (which
generate the majority of 'small' packets, it will take quite some time
to consume a 32 bit counter, when the count is packets.  (e.g. 2G of
these 'smaller' packets.)

Since most applications of ipsec will care enough about security to
re-key every couple hours as a matter of course, the 'smaller packets'
shouldn't present a problem.  Consider how long it would take to
consume 2^32 packets with 'telnet' or a chat client.

For bulk data, even at ethernet MTUs, the issue becomes:  is
	2^32 * 1500 bytes enough data to expose almost any algorithm?

32 bits should suffice.

>   As to the 64-bit math, [...]  This was NOT a problem on an Intel Pentium.

Not all the world is Intel. In addition, a large percentage of the
world will run IPv4 for a long time to come.

-- 
Jim Thompson / Smallworks, Inc. / [e-mail]  
      512 338 0619 phone / 512 338 0625 fax
HTML:  The 3270 of the 90s