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

Re: Crypto algorithms for IKEv2



At 11:27 AM -0400 4/29/03, Michael Richardson wrote:
>   Paul, I think that this is a very good way to organize things. 
>   I have one additional suggestion, which you may or may not like.
>
>Split this document into two documents:
>Document 1 title: Security Algorithms for IKEv2
>	 sections 1, 1.3, 2.
>
>Document 2 title: A VPN profile for IKEv2
>	 section 3, plus all MANDATORY statements from other sections.

This is an interesting idea, but it kind of goes against what people 
had said they wanted, which was to have the MUSTs and SHOULDs with 
the algorithm specifiers.

>Rational for this:
>a)	 This makes Document 1 really the initial IANA registry.
>	 Very simple for IANA to grok.
>	 Very simple for implementors to reference as well.
>
>b)	 Document 2 now becomes readable to end-users, to
>	 system support people, and even to marketing.
>
>c)	 Your document claims it is for VPN use, so make it so.
>
>d)	 I do not believe that any statements about "MUST" can really
>	 be made in isolation of the application area. We have long
>	 endless debates about what is "best" because we have differing
>	goals, and therefore different risk/benefit tradeoffs.
>
>e)	 "Note that the suites listed here are for use of IPsec in virtual
>	 private networks. Other uses of IKEv2 and IPsec will probably want
>	 to define their own suites and give them different names."

All of these sound fine to me, if that's where the WG wants to go. On 
the other hand:

a) IANA can grok whatever we give them. Also, we don't want 
implementers referencing the RFC: we want them referencing the IANA 
registry. This is one of the big problems we have had with IKEv1.

b) We don't expect end users to read RFCs. If we want them to do 
that, someone (like VPNC) can create a "RFC xwyz in plain English" 
document.


>In the end, a customer will specify a device that is RFC-Document2 compliant
>for their VPN use, and things will work.

But they don't need to be able to read that RFC	in order to specify it. :-)

--Paul Hoffman, Director
--VPN Consortium