[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 10 Mar 2003, Derek Atkins wrote:

> Paul Hoffman / VPNC <paul.hoffman@vpnc.org> writes:
>
> > At 2:08 PM -0500 3/10/03, Derek Atkins wrote:
> > >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).
> > >
> > >While I agree with everything else you said about 02 vs 05 (cut from
> > >this reply), I do need to add that the one argument I heard that
> > >implies AND and OR are necessary in an a la carte system is for
> > >hardware deployments that support multiple algorithms but NOT in
> > >arbitrary combinations.  For example, a hardware implementation that
> > >ONLY supports 3DES with MD5, or AES with SHA-1...
> >
> > One of the early goals for IKEv2 was simplicity. Doing AND and OR
> > moves sharply away from that. Dan's proposal above would be much
> > simpler to implement.
>
> That's fine.  I have no specific, personal objection to leaving out
> the AND and OR functionality.  I was just pointing out that there
> were reasonable reasons to have such functionality.

I agree with this approach as well...

> If we DO decide to leave it out in the name of simplicity we should at
> least add some text that shows that we thought about this issue.  I
> would propose something like:
>
>   Certain hardware architectural implementations may only support
>   limited combinations of algorithms.  For example, a piece of
>   hardware may only support 3DES+MD5 or AES+SHA1, but there is no way
>   to actually negotiate for one or the other combinations.  The
>   working group acknowledges this limitation, but decided in favor of
>   the simplicity of ruling out such architectures.

Or perhaps add text which states that the limitation exists, and is up to
such implementation to work within the rules of the protocol.  Such a
device can still interoperate, it will just be harder for the
implementation.  For example, they can attempt to negotiate an AES+SHA1 SA
first... failing that, attempt a new SA negotiation for 3DES+MD5.  Granted,
this is not pretty, but neither is the hardware implementation that they
are trying to support.

> > --Paul Hoffman, Director
> > --VPN Consortium
>
> -derek
>
> --
>        Derek Atkins
>        Computer and Internet Security Consultant
>        derek@ihtfp.com             www.ihtfp.com

=====================================================================
= Tylor Allison         Secure Computing Corporation        =========
=====================================================================