Re: [IPsec] Questions about RFC 5723

["Valery Smyslov" <[e-mail]>]

Hi Paul,

speaking as someone who implemented the IKE resumption.

> Hi,
> 
> I'm a little confused about some parts in RFC 5723
> 
> The first is about which SA's can be resumed. The introduction leaves
> this ambiuous:
> 
>  	To re-establish security associations (SAs) upon a failure recovery
>  	condition is time-consuming,
> 
> It does not say IKE SA or IPsec SA. And I have a feeling it depends a
> bit on what you call "resumption".

Only IKE SA is meant.

> It then talks about resuming the IKE SAs.... Reading more, it seems
> IPsec SA's are not "resumed" but "created from scratch"?

Yes.

> I also see:
> 
>  	If a client temporarily loses network connectivity (and the IKE SA
>  	times out through the liveness test facility, a.k.a. "dead peer
>  	detection")
> 
> This is also a little confusing for IKE and IPsec states, because the
> liveness test is for an IPsec SA, not an IKE SA. But it is send via an
> IKE SA. That is, if an IPsec SA has no outgoing traffic, there would
> never be a check using IKE for this. So it is kind of misusing the fact
> that the IKE SA is used for liveness tests to check on the status of
> the IKE SA.

I believe the authors meant that liveness check was triggered by traffic over IPsec SA,
but resulted in timeout of IKE SA and thus deletion of IKE SA and all its children.

> In 4.3.4 I see:
> 
>  	Following the IKE_AUTH exchange, a new IKE SA is created by both
>  	parties, see Section 5, and a Child SA is derived, per Section 2.17
>  	of [RFC4306].
> 
> Which Child SA? If the peers had more then one IPsec SA, how does one
> determine which IPsec SA to generate key material for first? Because
> this paragraph does not talk about a new CREATE_CHILD_SA, it looks as if
> the child sa derivation would not need another Exchange, but I can find
> no information on how this would be done, unless we just pull KEYMAT
> from the new SKEYSEED, but then child SA and ordering is completely
> unspecified and this could only work when there is a single IPsec SA for
> the IKE SA?

A single (pair of ) IPsec SA is created as result of IKE_AUTH following
IKE_SA_RESUME, as if it follows IKE_SA_INIT instead of IKE_SA_RESUME.
If more IPsec SAs are needed they are created via CREATE_CHILD_SA,
as usual.

> And this is the really confusing part in section 5:
> 
>  	IKE and IPsec State after Resumption
> 
>  	During the resumption process, both peers create IKE and IPsec state
>  	for the resumed IKE SA.  Although the SA is only completed following
>  	a successful IKE_AUTH exchange, many of its components are created
>  	earlier, notably the SA's crypto material
> 
> So here too it says "create IKE and IPsec state". Which IPsec state
> first? Then it talks about "the SA" and "the SA's" ?

The IPsec SA you want to encrypt traffic with.

Usually you have an outgoing traffic that triggers IPsec SA creation.
If you don't have IKE SA at the moment, you create one with IKE_SA_INIT
and then create IPsec SA for the traffic in the IKE_AUTH. 

With IKE resumption the only difference is that the initiator
somehow determines that it has a ready to use ticket from the responder
and instead of initiating IKE_SA_INIT it initiates IKE_SESSION_RESUME.
The IPsec SA related stuff in the IKE_AUTH (traffic selectors, algorithms 
negotiation, cfg payload etc) is not affected by resumption.

> My guess is that we first pull key material for the IKE SA, and then for
> one of the IPsec SA's (perhaps this document assumes there is only 1
> IPsec SA for any IKE SA that can be resumed?). Or based on Note 6:
> 
>  	Note 6:  Since information about Child SAs and configuration payloads
>  		is not resumed, IKEv2 features related to Child SA
>  		negotiation (such as IPCOMP_SUPPORTED,
>  		ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec [ROHCoIPsec]
>  		and configuration) aren't usually affected by session
>  		resumption.
> 
> Perhaps what is meant is that a session resumption only resumed a
> childless IKE SA, and now the initiator must do CREATE_CHILD_SA's for
> each IPsec SA it wants to have again (not really "resumption", as these
> are created "from scratch" like regular CREATE_CHILD_SA?

No, one IPsec SA can be created in the IKE_AUTH (usually the IPsec SA
you are in immediate need to protect the outgoing traffic).
Other IPsec SAs can be later created via CREATE_CHILD_SA.

> Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at
> which point one wonders why to do resumption at all if you have more
> than one IPsec SA, as you would be doing DH's anyway for all children,
> you might as well do one more for a regular IKE_SA_INIT ?

In any case you save on authentication (this may involve signature
computing/verification and probably human intervention in case of EAP).

> So the essense of my question is: Am I correct that an IKE session
> resumption only resumes the IKE SA, and that all IPsec SA's need to be
> re-negotiated using CREATE_CHILD_SA ?

You are correct that IKE session resumption only resumes IKE SA.
However, one IPsec SA can be created in the IKE_AUTH as part
of session resumption, the others must be created via CREATE_CHILD_SA.

> Secondary question: When using pfs=yes, what is the envisioned behaviour
> of CREATE_CHILD_SA? Do a new DH? Or is it assumed that resumption would
> be an incompatible policy with pfs=yes ?

With resumption you essentially re-use DH from the old (already deleted)
IKE SA for the IPsec SA that is created during resumption in the IKE_AUTH.
If it is not appropriate, then resume IKE SA as childless and create
all IPsec SAs via CREATE_CHILD_SA with DH.

Regards,
Valery.

> Paul
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec