Subject: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01

From: Tero Kivinen <[email-masked]>
Date: Thu, 6 Mar 2014 01:07:46 +0200

In section 2 it says:

   Note that IKEv2 and IPsec session do not need to be on the same node
   as IKEv2 and IPsec context are different.

This is not so easy. The RFC5996 says:

----------------------------------------------------------------------
2.4.  State Synchronization and Connection Timeouts
...
	An implementation needs to stop sending over any SA if
   some failure prevents it from receiving on all of the associated SAs.
   If a system creates Child SAs that can fail independently from one
   another without the associated IKE SA being able to send a delete
   message, then the system MUST negotiate such Child SAs using separate
   IKE SAs.
----------------------------------------------------------------------

I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using
same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA
are on separate nodes, that do set up new kind of requirements for
those nodes. I.e. if one node having IPsec SAs fails, the node having
IKE SA needs to detect this, and send delete notification for each
IPsec SA that were in that node. Also if the node having the IKE SA
will fail, then all the IPsec SAs associated with that IKE SA, must
stop sending, i.e. they needs to be destroyed.	          
-- 
[email-masked]

---

From: Daniel Palomares <[email-masked]>
Date: Thu, 6 Mar 2014 19:23:53 +0100

Hi Tero,
Thank you for the comment.
In fact, I agree that is not so easy. Actually [ARORA] addressed these kind
of scenarios on his draft already. For example, one of the usage scenarios
described is: the IKEv2 signaling and the IPsec tunnel mode traffic on
different addresses for load balancing purposes.

So, would you think it is a good idea to add this information to the draft
(I mean the new requirements when IKE_SAs and IPsec_SAs are on separated
nodes)? ... Or instead, would you think it would be good to ignore how
applications are managing their IPsec_SAs and IKE_SAs and  just delete the
sentence " Note that IKEv2 and IPsec session do not need to be on the same
node as IKEv2 and IPsec context are different".

We could also just mention that we wish to make clear that there are
parameters related to the IKE_SA and others for the IPsec_SA.

KR
Daniel Palomares

2014-03-06 0:07 GMT+01:00 Tero Kivinen <[email-masked]>:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 6 Mar 2014 20:51:43 +0200

Daniel Palomares writes:
> So, would you think it is a good idea to add this information to the draft (I
> mean the new requirements when IKE_SAs and IPsec_SAs are on separated nodes)?
> ... Or instead, would you think it would be good to ignore how applications
> are managing their IPsec_SAs and IKE_SAs and  just delete the sentence " Note
> that IKEv2 and IPsec session do not need to be on the same node as IKEv2 and
> IPsec context are different".

We definately need to add text explaining the situation, as it is
important that implementors understand the RFC5996 requirement. 

-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Mar 2014 10:47:56 +0000

> This is not so easy. The RFC5996 says:

Tero's comment nails the concern I had when reading the document. IKEv2 ties Child SAs to their parent SA, and using the context of one without the other seems dangerous.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Tue, 11 Mar 2014 16:03:40 +0100

Hi Paul and Tero,

Thanks for the comments we will clarify these points for the next
version, and explicitly describe the dependance between these context.
Thanks
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58