Subject: [Ipsec] Should IKEv2 negotiate new/old AH/ESP protocols?

From: Joy Latten <[email-masked]>
Date: Tue, 12 Jun 2007 17:35:58 -0500

I have just finished reading 4301, 4302 and 4303.
Reference is made in each that since AH and ESP do not contain
version numbers, concerns about backward compatibility
must be addressed through a signaling mechanism between
two IPSec peers, such as IKE.

I have begun reading IKEv2bis and noticed so far no mechanism
mentioned for this. I know that I may be misunderstanding something
or entirely missing the point, but should there be an attribute or
maybe protocol id(s) to distinguish the two versions of the protocols
for interoperability in IKEv2?

Regards,
Joy Latten

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

---

From: Dan McDonald <[email-masked]>
Date: Tue, 12 Jun 2007 19:17:53 -0400

> two IPSec peers, such as IKE.

Nit:  IPsec.  ;)

> for interoperability in IKEv2?

I'm under the distinct impression that IKEv2 (and bis) can only generate
430x-compliant SAs.  If they *happen* to work with 240x implementations
(which, modulo perhaps 64-bit replay numbers), no-one's the wiser.

I honestly don't think too much of the 430x is incompatible
w.r.t. on-the-wire.  It's mostly differences in processing, or in *some*
cases, SA properties (properties that can only be negotiated with IKEv2).

Dan

---

From: Joy Latten <[email-masked]>
Date: Tue, 12 Jun 2007 19:20:18 -0500

> cases, SA properties (properties that can only be negotiated with IKEv2).

Ok, that makes sense. 
IKEv2 states "... to efficiently  establish SAs for Encapsulating
Security Paylod (ESP) [RFC4303] and/or Authentication Header (AH)
[RFC4302] ..." in the Introduction. References to the rfcs were taken
out of IKEv2bis. IMHO, I think we should keep the reference to those
rfcs.

I guess I was thinking along the lines of someone implementing 4301, 
4302, and 4303, but not IKEv2. Instead, they make the required changes
in an already existing IKEv1 implementation. It seems an implementation
of this sort might not be very interoperable. Besides, it is not the
scope of IKEv2 anyway. 

Thanks! 

Regards,
Joy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jun 2007 15:43:44 -0400

Dan's right.  IKEv2 assumes use of the latest versions of AH and ESP. 
RFC 4301  requires IKEv2 because 4301 includes the ability to 
specific selectors that cannot be negotiated via IKEv1. There are a 
few other reasons for this matching, but I don't remember them right 
now.

Steve

---

From: Joy Latten <[email-masked]>
Date: Mon, 18 Jun 2007 10:33:36 -0500

> few other reasons for this matching, but I don't remember them right 

Yes, it makes sense. 

However, is it also applicable that IKEv1 assumes
use of older versions of AH and ESP (rfcs 2403 and 2403)?

Regards,
Joy

---

From: Dan McDonald <[email-masked]>
Date: Mon, 18 Jun 2007 11:38:18 -0400

> use of older versions of AH and ESP (rfcs 2403 and 2403)?

Modulo extensions outside of 240x that are now part-and-parcel of 430x
(e.g. 64-bit sequence numbers), that's probably correct.

Dan

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Jun 2007 14:23:34 -0400

>use of older versions of AH and ESP (rfcs 2403 and 2403)?

those were the only versions of AH and ESP extant when IKEv1 was 
developed, so to first order, yes. with the newer versions of ESP & 
AH the default is to use 64-bit sequence numbers and there is no way 
to negotiate use of 32-bit sequence numbers, if necessary. that makes 
it less attractive to try to use the new protocols with the old IKE.

Steve