[ipv6-wg] RIPE-501bis: Some additional IPsec comments from Tero Kivinen

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 at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf
>> Of Jan Zorz @ go6.si
>> Sent: Tuesday, March 20, 2012 7:19 PM
>> To: ipv6-wg at 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
> 
> 
>