Subject: RE: [Ipsec] Is AH + ESP required or needed in IKEv2

From: "Charlie Kaufman" <[email-masked]>
Date: Wed, 25 Aug 2004 10:52:55 -0700

I expect using ESP and AH together as you describe will be an obscure
case, and if we could have ruled them out early in the design of IKEv2
it could have simplified things. I hope that it's too late to remove the
option in this revision of IKE - perhaps if we can agree that no one
would ever want to do it, it could be removed from the next one. This
configuration used to have some vocal adherents, though that was long
ago.

I believe there are two distinct cases that RFC2401bis has to deal with,
but IKE only has to deal with one of them.

An endpoint could have an IPsec SA to a firewall and within that tunnel
have an IPsec SA to an endpoint beyond the firewall. One could imagine
cases where there are an unbounded number such nested tunnels all
terminating at the same endpoint. RFC2401bis has to deal with that.

IKE is more oblivious because the recursion is not built in. In the
example above, one instance of IKE could negotiate the tunnel to the
firewall and then a second instance of IKE would run through the tunnel
to negotiate the IPsec SA with the other endpoint. Timeouts would occur
independently, and one could imagine the inner tunnel getting rerouted
though a different outer tunnel if configurations changed. The
authenticated identities would be different on the different tunnels.
They might even be different at the common endpoint. The outer tunnel
might authenticate as the computer while the inner tunnel might
authenticate as the user.

This is entirely different from the case where ESP and AH are negotiated
together. It would be artificial and awkward to first establish the AH
tunnel and to then tunnel a second IKE exchange inside the AH tunnel to
negotiate ESP. The double authentication would be wasteful and
confusing. So I believe it's appropriate that IKE understand this double
protocol case.

As I reread this note, I apologize for how confusing it is. I hope that
the few people into this esoteric stuff will be able to parse it.

	--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tero Kivinen
Sent: Wednesday, August 25, 2004 3:55 AM
To: [email-masked]
Cc: Charlie Kaufman; [email-masked]
Subject: [Ipsec] Is AH + ESP required or needed in IKEv2

The current IKEv2 draft still has this feature that we can negotiate
two protocols at the same time, i.e we can negotiate AH with SHA-1 and
ESP with AES using one IKE exchange (between same endpoints, i.e
traffic selectors are proto=any, IPi=A, IPr=B).

For my understanding the RFC2401bis does not require this feature
anymore, but it assumes that such constructs are negotiated so that we
first negotiate the AH with SHA-1 where its traffic selectors are set
to proto=ESP, IPi=A, IPr=B and then we do second IKE exchange and
negotiate ESP SA between the nodes having traffic selectors proto=ANY,
IPi=A, IPr=B.

Is my understanding correct?

So this means that all IKE security association payloads always have
list of proposals which all only have one protocol inside.
-- 
[email-masked]

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

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Aug 2004 12:10:10 +0300

> configuration used to have some vocal adherents, though that was long

Yes, I do not want to change IKEv2 to remove the constructs needed to
negotiate that, as I think we might need to have that feature in the
future (i.e. for future expansion path). 

> but IKE only has to deal with one of them.

I was more a less asking whether RFC2401bis still allows such
constructs or not. If it does not allows such constructs, but says
that AH + ESP needs to be configured in as two SPD entries, which
would mean that we do two IKE exchanges to create the AH + ESP
construct, then I do not need to implement support for more than one
protocol per proposal in my IKE library.

If RFC2401bis says that we can have SPD entry where we say PROTECT
with ESP first and then AH, then we would only use one IKE exchange to
negotiate them, which would mean that I would need to implement
support for that.

> terminating at the same endpoint. RFC2401bis has to deal with that.

But as endpoints are different, we do need to run multiple IKE
exchanges to create SAs, this is not the case I am talking about. 

> confusing. So I believe it's appropriate that IKE understand this double

You do not need second authentication, as the end nodes are same. You
need second CREATE_CHILD exchange to create the SA used inside the
tunnel.

I.e. create IKE SA between nodes A and B, and create first child AH SA
so that TSi = (ESP, A), TSr = (ESP, B), and transform = AH. Then you
run CREATE_CHILD exchange to create ESP SA where TSi = (any, A), TSr =
(any, B), and transform = ESP.

You do not do extra authentication, but you do extra create child SA,
i.e extra round trip.

This construct also solves couple of problems we had in the IKEv1.

1) Which order must be used when proposing the AH + ESP construct (in
   IKEv1 there was this confusion about this, i.e. whether you needed
   to propose the AH + ESP in the specific order, or not. Current
   concensus is that no specific order is needed, the AH + ESP will
   always be in same order regardless whatever order was used in
   IKEv1). I.e the packet will look like IP1 AH ESP PACKET or IP1 AH
   IP2 ESP PACKET.

2) If we propose tunnel mode AH + ESP, are both AH and ESP in tunnel
   mode, or only one of them, i.e are the packets in tunnel mode IP1
   AH IP2 ESP IP3 PACKET, or IP1 AH IP2 ESP PACKET. Also note that in
   IKEv1 we did propose tunnel/transport mode for each protocol
   separately, but I think the agreement was that all proposal must
   have identical mode in the IKEv1 proposals. In IKEv2 we do not have
   this problem as we only negotiate common mode for all protocols,
   but the final packet format is still an issue. 

Anyways, I do not think this is really an IKEv2 issue, the document in
such phase, that we are not going to modify it, and there is no need
to modify it. IKEv2 document is currently silent about this issue, it
does not say it is forbidden, and it does not say it is allowed. 

The question is more to the RFC2401bis, i.e. can we have multiple
IPsec protocols in the PROTECT processing info.

The current draft uses "IPsec protocol(s) -- AH, ESP" in section
4.4.1.2, which would say yes, multiple protocols are allowed.

On the other hand section 5.1 says in 3a "... or PROTECT using AH or
ESP.", which would indicate that only one of them is allowed.

Also appendix D ASN.1 for SPD entry says that "aH IntegrityAlgs" and
"eSP SEQUENCE { IntegrityAlgs, ConfidentialityAlgs }" are inside the
CHOICE, thus only one of them can be selected. 

So my concusion is that by votes 2-1 the only one of the protocols can
be in one SPD entry, thus AH + ESP cannot be expressed as one SPD
entry, and so that feature of IKEv2 is not needed when implementing
baseline rfc2401bis.

Perhaps we should remove that "(s)" from the section 4.4.1.2 so it
would be even more explicit :-)
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Aug 2004 08:05:07 -0400

Tero,

Sorry for the confusion. The intent in 2401bis was to simplify, and 
thus to remove the special case of creating two SAs based on one SPD 
entry.  We missed the text in 4.4.1 that still accommodated the 
AH+ESP case.  We will remove it. This also avoids the confusion of 
whether both SAs are tunnel or transport mode when we had one SPD 
entry that called for negotiating a pair of SAs, but only one 
indication of modality, as you noted.

Steve