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
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
Sigh. As I mentioned to Jan separately after seeing his post, the comments from Tero were based on an older version of RIPE-501bis and I (and Jan) pointed him to the newer version. I think Jan got a bit eager to distribute Tero's comments and I fear they could cause some confusion since we DID take out all reference to IKEv1 and updated to all the updated RFCs. Also, as per the last ditch at consensus on IPsec, it was all moved to optional. - merike On Mar 20, 2012, at 12:27 PM, Ivan Pepelnjak wrote:
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
On 3/20/12 11:35 PM, Merike Kaeo wrote:
Sigh. As I mentioned to Jan separately after seeing his post, the comments from Tero were based on an older version of RIPE-501bis and I (and Jan) pointed him to the newer version. I think Jan got a bit eager to distribute Tero's comments and I fear they could cause some confusion since we DID take out all reference to IKEv1 and updated to all the updated RFCs.
Hi, I copy/pasted comments from Tero's latest email, after redirect to newest draft of intended replacement doc. Let's find out relevant parts and see what we can use. Cheers, Jan
On Mar 20, 2012, at 11:27 PM, Jan Zorz @ go6.si wrote:
On 3/20/12 11:35 PM, Merike Kaeo wrote:
Sigh. As I mentioned to Jan separately after seeing his post, the comments from Tero were based on an older version of RIPE-501bis and I (and Jan) pointed him to the newer version. I think Jan got a bit eager to distribute Tero's comments and I fear they could cause some confusion since we DID take out all reference to IKEv1 and updated to all the updated RFCs.
Hi,
I copy/pasted comments from Tero's latest email, after redirect to newest draft of intended replacement doc.
You are right!! Mea culpa. Too much multi-tasking.
Let's find out relevant parts and see what we can use.
All of what Tero sais is relevant - the one aspect I would like input from community is whether they still want IKEv1 in recommendations, even optional. The ISAKMP references should be taken out if IKEv2 is the only requirement the RIPE community wants to make for tender input. For rest of community - Tero initially sent me his comments when he saw the document in a Finnish IPv6 Forum meeting a few weeks ago - I've known him through IPsec wg in IETF for years. He is an implementor and primary standards contributor so he is well aware of what folks are actively deploying wrt IPsec. He has implemented IPsec in IPv6 environments for well over 6 years (if not longer). - merike
participants (3)
-
Ivan Pepelnjak -
Jan Zorz ＠ go6.si -
Merike Kaeo