I'm absolutely in agreement with IPsec-v3+IKEv2 being preferred over IPsec-v2+IKEv1 and both being explicitly spelled out. I honestly don't know what IPsec, ISAKMP and IKE are doing in the "Load balancer" section (which is a total embarrassment because I contributed some text to that section ;). IPsec/VPN functions are usually handled by other devices, not by load balancers. If someone thinks IPsec suite should be listed in that section, then please make it OPTIONAL and use the same set of protocols/RFCs as everywhere else (for example, in "Routers and switches" section). I can't imagine why load balancers would have other IPsec/IKE requirements than other networking devices (but then I'm often ignorant and like to be corrected ;). Would that make sense? Ivan
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Tuesday, March 20, 2012 7:19 PM To: ipv6-wg@ripe.net Cc: Tero Kivinen Subject: [ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen
Dear IPv6 WG...
We received some additional comments from Tero Kivinen. Tero is one of THE experts in IPsec and a long-time implementer. He is part of IETF IPsec wg and a key contributor. As he's not on RIPE IPv6 WG mailinglist, I'm adding him to cc: and at the same time encouraging him to subscribe in order to follow and contribute to the discussion:
http://www.ripe.net/mailman/listinfo/ipv6-wg
So, his comments are listed below. We would like to "measure the heat" in working group and hear some comments, what you think should be implemented and what not.
I explained, that we have certification/testing profiles (NIST, USGv6, IPv6 Ready, etc...) and we have RIPE-501 (soon replaced), that is procurement profile, intended solely as a help to procurement people (usually IPv6-clueless) to order equipment, that makes sense.
Tero's comments: --------
In section IPsec: mandatory or optional, I would format the end as following:
---------------------------------------------------------------------- Organizations that use IPsec or expect to use it in the future should include the follwoing in the mandatory section when initiating the tender:
* IPsec-v3 [RFC4301, RFC4303, RFC4302] * IKE version 2 (IKEv2) [RFC5996 (obsoletes RFC4306 and RFC4718)]
and if support for old IPsec is required add following:
* IPsec-v2 [RFC2401, RFC2406, RFC2402] * IKE version 1 (IKEv1, ISAKMP) [RFC2407, RFC2408, RFC2409]
---------------------------------------------------------------------- I.e. prefer IKEv2, and move IKEv1 as separate case. Also note that IKEv1 is tied to IPsec-v2 and IKEv2 is tied to IPsec-v3 and you cannot really mix them that well.
Note, also that RFC5996 obsoletged both RFC4306 and RFC4718. This same change should also be done for other places.
Also I would rather use IKEv1 than ISAKMP for the old obsoleted key management protocol. ISAKMP is the name of framework on which the IKEv1 protocol is based on (and IKEv2 is also based mostly on the same framework, but everything from that framework document got incorporated to the IKEv2 RFC, so thats why it is not referenced anymore).
It seems you do not have IPsec-v2 anywhere, even when you do have IKEv1. What is the reason behind that? IKEv1 works with IPsec-v2, and IPsec-v3 do require IKEv2, so am not sure why IKEv1 is included at all...
There are multiple cases where you have "if xxx is requested the equipment must support yyy", where that yyy do require IPsec. Should those be spelled out too.
For the Requirements for Mobile Devices the optional support list should probably include RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE), as it is something that is really useful in the mobile nodes.
Requirements for Load Balancers:
Now the mandatory support has only IKEv1 (ISAKMP), and no IPsec-v2/v3 at all. There isn't really that much that can be done using IKEv1 only.
IKEv2 + RFC5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2).) would make some sense even without IPsec-v3, but IKEv1 does not even have any such uses.
The optional support list should probably have RFC5685 (Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2).) and perhaps RFC6311 (Protocol Support for High Availability of IKEv2/IPsec).
The optional list has IKEv1 (ISAKMP) again. ----------- (end of Tero's comments)
I think we still are in review phase, so we can implement some changes. I hear that Last Call is planned for after RIPE64 meeting, so we still have time for last changes.
As usual, comments and suggestions very warmly welcome.
Cheers, Jan Zorz (writing for all co-authors) Go6 Institute Slovenia