Re: suites vs. a la carte and IPcomp in IKEv2-05

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Derek" == Derek Atkins <derek@ihtfp.com> writes:

 Derek> Dan Harkins <dharkins@tibernian.com> writes:
 >> already seeing. IKEv2-02 also had the complex ANDing and ORing
 >> that I think we should get rid of. Why not just have a single SA
 >> payload that contains TLVs for each of the necessary attributes? 
 >> Multiple occurances of an attribute mean "I'll do either" (as it
 >> was in IKEv2-02 even though I doubt that would be used much if
 >> ever).

 Derek> While I agree with everything else you said about 02 vs 05
 Derek> (cut from this reply), I do need to add that the one argument
 Derek> I heard that implies AND and OR are necessary in an a la carte
 Derek> system is for hardware deployments that support multiple
 Derek> algorithms but NOT in arbitrary combinations.  For example, a
 Derek> hardware implementation that ONLY supports 3DES with MD5, or
 Derek> AES with SHA-1...

 Derek> Granted, this is probably a rare occurance, but I've heard
 Derek> this argument from a few people over the years so I have no
 Derek> reason to ignore it. 

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.)

      paul