Subject: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2

From: Martin Willi <[email-masked]>
Date: Fri, 2 Jun 2006 08:50:52 +0200

Dear subscribers,

It is not absolutely clear to me how to do the rekeying of a CHILD_SA, if its
traffic is protected by AH AND ESP. The use of both protocols may be
questionable, but it's possible in IKEv2 and therefore I want to support it.

I've done the following assumptions:
  - a CHILD_SA consists of a AH and/or ESP security assocation, this means
    it's just ONE CHILD_SA, even if there are two/four (kernel level)
    security associations involved. Correct?
  - If I set up AH and ESP in one CHILD_SA, those SAs may be identified by
    different SPIs. Correct? I haven't found a clear statement about this, but
    the inclusion of an SPI in every proposal substructure leads to this
    assumption.

Now what means "rekeing a CHILD_SA"? What's to do if one of those 
SAs (ESP or AH) expire? For me, two approaches are possible:
1. Rekey the full CHILD_SA (ESP and AH SA) at once. If so:
  - Which SPI should be included in the REKEY_SA notify? Or include two of
    them?
2. Rekey every SA seperately. If so:
  - What sould be included in the SA-payload? Only proposals for the specific 
    protocol?

I hope someone can give me clarity about this.

Thanks in advance
Martin Willi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 02 Jun 2006 09:04:24 +0200

Hi!

Some time ago I did the same question. You can read the discussion here

http://www1.ietf.org/mail-archive/web/ipsec/current/msg01781.html

At the end, we decide to eliminate all the SA bundles support from
OpenIKEv2, due it is not clear how to support them and it was not a very
important feature for us.

Best regards!
--
Alejandro Perez Mendez
OpenIKEv2 developer
http://openikev2.sf.net

---

From: <[email-masked]>
Date: Fri, 2 Jun 2006 12:30:34 +0300

Hi,

You probably want to check out Section 7.13 (Combining ESP and
AH) in draft-eronen-ipsec-ikev2-clarifications. 

Best regards,
Pasi

> -----Original Message-----
> From: ext Martin Willi [mailto:[email-masked]] 
> Sent: 02 June, 2006 09:51
> To: [email-masked]
> Subject: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2
> 
> Dear subscribers,
> 
> It is not absolutely clear to me how to do the rekeying of a 
> CHILD_SA, if its traffic is protected by AH AND ESP. The use of both 
> protocols may be questionable, but it's possible in IKEv2 and 
> therefore I want to support it.
> 
>   - a CHILD_SA consists of a AH and/or ESP security assocation, 
>     this means it's just ONE CHILD_SA, even if there are two/four 
>     (kernel level) security associations involved. Correct?
>   - If I set up AH and ESP in one CHILD_SA, those SAs may be 
>     identified by different SPIs. Correct? I haven't found a 
>     clear statement about this, but the inclusion of an SPI in 
>     every proposal substructure leads to this assumption.
> 
>   - Which SPI should be included in the REKEY_SA notify? Or 
>     include two of them?
>   - What sould be included in the SA-payload? Only proposals 
>     for the specific protocol?
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 2 Jun 2006 14:23:19 +0300

> questionable, but it's possible in IKEv2 and therefore I want to support it.

There is not really AH AND ESP in RFC4301 architecture. There is
TCP/UDP inside ESP and ESP inside AH. I.e. AH+ESP is generated by
first creating SA encrypting traffic with ESP and then creating
separate SA that will authenticate the ESP packets by adding AH around
them. Those two SAs are created as two separate IKE CREATE CHILD SA
exchanges. 

>     security associations involved. Correct?

Wrong. AH and ESP are separate SAs each having different traffic
selectors. The ESP have traffic selectors of the real traffic to be
protected, and the AH has traffic selectors matching the ESP traffic. 

>     the inclusion of an SPI in every proposal substructure leads to this

You create AH and ESP as two CREATE_CHILD_SAs, each having one SPI in
SA payload, and only one protocol in each proposal. Each of those
CREATE_CHILD_SAs also have different traffic selectors matching the
data to be protected, i.e. for the AH it is going to be protocol =
ESP etc. 

>   - Which SPI should be included in the REKEY_SA notify? Or include two of

As the ESP and AH SA are not bundled together, you cannot do that. 

> 2. Rekey every SA seperately. If so:

Yes, you do this, i.e. rekey them separately, just like you created
them too. 

>   - What sould be included in the SA-payload? Only proposals for the specific 

You use same data you used when you created them, i.e. only proposals
for the specific protocol, and including the traffic selectors set
properly.

> I hope someone can give me clarity about this.

In RFC4301 there is no more SA bundles, i.e. AH+ESP is not a special
case anymore, you create ESP and AH separately, and set the traffic
selectors so that after packets are encrypted by ESP, the packets
match selectors of the AH, and are reprocessed by the IPsec and
authenticated by using AH.

See the section 5.1 of the RFC4301, and notice that the SPD cache
returns you exactly one SA, which is used to process the pcaket with
either AH or ESP (but not both), and then the packets goes to the
Forwarding check, that will resend the packet to beginning again, now
with new selectors and then the SPD cache will return another SA and
you do the second process step for the packet.

Same thing is described in the section 5.2 for the inbound packets. 
-- 
[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Fri, 2 Jun 2006 14:53:43 +0300

> From: Tero Kivinen <[email-masked]>

> protected, and the AH has traffic selectors matching the ESP traffic. 

...

> you do the second process step for the packet.

I'm somewhat troubled by above description. I heartily support the
idea that AH and ESP are negotiated independently. This was my prime
objection for IKEv1 from the start.

But, your selector thing is a bit problematic. In IPv6, AH and ESP are
extension headers. Seems odd that after extension header processing,
the packet would go into "forwarding check" etc. This not the way our
stack works.

I believe the selectors should always be for "transport level". If you
protect TCP or UDP traffic with AH + ESP, I say the selectors for AH
and ESP should still be the TCP/UDP and ports.

This way the basic IPsec implementations (not including IKE) would be
compatible between RFC-2401 and 4301 implementations.

---

From: <[email-masked]>
Date: Fri, 2 Jun 2006 16:39:44 +0300

> the packet would go into "forwarding check" etc. This not the way our

Going back to forwarding check is required to handle nested IPsec
SAs between different endpoints.

E.g. suppose that I have an IPsec tunnel (ESP or AH) between my laptop 
at  home and the company VPN gateway. Inside that tunnel, there can be
another SA (ESP or AH) for protecting traffic between the laptop and 
some server X located inside the company intranet. So when a packet
arrives down from UDP/TCP, it's first processed using the latter SA
(laptop-server X), then goes to forwarding check, and then processed
using the former SA (laptop-gateway).

In RFC4301, AH+ESP between the same endpoints is basically handled
same way as two nested SAs with different endpoints (and there's
no difference between IPv4 and IPv6 here).

Best regards,
Pasi

---

From: Markku Savela <[email-masked]>
Date: Fri, 2 Jun 2006 17:36:43 +0300

> SAs between different endpoints.

That's ok, in this context the inner IP header provides the right
trigger. That is not the problem.