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

["Scott G. Kelly" <scott@airespace.com>]

I agree with Paul - I've evaluated and used a number of crypto
processors in the last few years, and I don't think any of them had this
limitation, and I think Paul is  right that spec'ing around such
behavior is probably not required (or a good idea).

Scott

Paul Koning wrote:
> 
> >>>>> "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