[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: suites vs. a la carte and IPcomp in IKEv2-05
>>>>> "Eric" == Eric Rescorla <ekr@rtfm.com> writes:
Eric> Paul Koning <pkoning@equallogic.com> writes:
>> >>>>> "Eric" == Eric Rescorla <ekr@rtfm.com> writes:
>>
Eric> Paul Koning <pkoning@equallogic.com> writes:
>> >> I wonder: is this still a real issue today? It would be good
>> not >> to add messes to the protocol to support strange hardware
>> >> architectures that are long obsolete. Certainly this issue >>
>> doesn't appear in any hardware I have ever seen. (Come to think
>> >> of it, if I saw this when doing device selection, I'd be very
>> >> tempted to exclude such a device.)
>>
Eric> It's generally not an issue of individual pieces of hardware
Eric> but of what happens when you have an implementation based on
Eric> multiple CSP-like modules.
>>
Eric> Say, for the sake of argument that you have a piece of hardware
Eric> that processes single IPsec records and supports 3DES and SHA.
Eric> You then add another CSP that supports AES and MD5. You can't
Eric> necessarily mix and match here, so you need to provide
Eric> profiles.
>> Sure, you can suppose such things, but are they real? That's my
>> point. I can't think of real hardware that matches your
>> supposition.
Eric> What, you can't think of real hardware that doesn't support
Eric> AES? How about the HiFn 7811?
Sure I know about that hardware, but that wasn't your example. You
said "3DES and SHA" vs. "AES and MD5". 7811 supports 3DES with either
SHA or MD5; later chips support AES with either SHA or MD5. So the
choice for authentication function does not affect whether you are
able to perform a given encryption algorithm.
paul