[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