[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: weakness in IKE/DOI specs
>>>>> "Heyman," == Heyman, Michael <Michael_Heyman@nai.com> writes:
>> From: John Shriver [mailto:jas@shiva.com]
>>
>> [SNIP] I think it is perfectly appropriate to limit these to 32
>> bits, with the range being 0 to (2^32)-1. I don't think there is
>> any sensible justification to allow 64 bit values, that's just too
>> long a lifetime.
>>
Heyman,> Hmmm,
Heyman,> Imagine in the near future (even now?) we have terabit
Heyman,> networks. That is 2^40 bits/second. Protecting 2^32KBytes
Heyman,> (=2^45 bits) gives me 32 seconds of coverage before a rekey
Heyman,> is needed.
Heyman,> In my opinion, 2^32, while more then adequate for today and
Heyman,> probably :-) adequate for time based rekeying, is a bit
Heyman,> small for the foreseeable future with respect to KByte
Heyman,> lifetimes.
I don't agree with this argument. The fact that links are getting
faster is NOT a reason to increase the byte count life limits on
keys. The appropriate value for the byte limit depends on the cipher
used, and is independent of the link speed.
By the way, while backbone links may scale that high, it's not clear
to me that edge to edge or end system to end system paths will run
anywhere near that fast anytime soon. SAs typically terminate near
the network edge, not right in the core.
Finally, if your security gateway is so fast that it can handle a Tb/s
of ESP/AH, it is likely to be plenty fast enough to rekey at a measly
twice per minute.
paul
References: