Re: Crypto algorithms for IKEv2

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> This document is meant to be a companion to the *next* draft of 
    VPNC> IKEv2. In that draft, Charlie can cleanly excise from his section 
    VPNC> 3.3.2 the cryptographic tables labeled "For Transform Type 1", "For 
    VPNC> Transform Type 2", "For Transform Type 3", and "For Transform Type 
    VPNC> 4", leaving Transform Type 5, which is not cryptographic. He can also 
    VPNC> remove the MUST, SHOULD, and MAY statements in Appendix B.

  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.

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

This is perfectly fine with me. By naming the document to reflect this, you
open up the floor to having other users define their own needs. 

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

It might be that after doing this that Document 1 isn't worth removing from
IKEv2. I don't care one way or another.

One final question is that it might be there there should still be a MUST for
some IKEv2 transforms. This might permit a mobile VoIP phone to be able to
get far enough in negotiation with a VPN-only box to determine that they
share no common phase 2 protocols. I don't know if this is useful.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [



  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPq6Z6IqHRg3pndX9AQFL6wP/T6Xk6wMYpkNhLP8Kf0MsIOqoBhICBPSt
+GtDmrjebiQvfCD/s8I6lQbsc4gwQWHshCvQ/3085NpyNTNg6ZkMOjhE4XnZ783L
axHbDU3MHxWBlNR4UmFKRACJZDdnjH2JmvpgJRZgw9ZFM9MjkThCNKaTzi1Ofx6A
rsgg0RSY4/I=
=iZRb
-----END PGP SIGNATURE-----