[IPsec] Questions about RFC 5723

[Paul Wouters <[e-mail]>]

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".

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

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.


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?

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" ?

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?

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 ?


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 ?

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 ?

Paul