[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay field size
> 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. / jim@smallworks.com
512 338 0619 phone / 512 338 0625 fax
HTML: The 3270 of the 90s
References: