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

[Tero Kivinen <kivinen@iki.fi>]

Charlie Kaufman writes:
> 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.

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

> I believe there are two distinct cases that RFC2401bis has to deal with,
> 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.

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

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. 

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

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 :-)
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec