Re: SPD Policies - Backward compatibility

[Stephen Kent <kent@bbn.com>]

At 9:33 AM +0530 4/7/04, Ravi wrote:
>     Hi,
>        Based on one of the emails, I got an impression that 
>rfc2401-bis is mainly
>        intended for IKEv2. This got me thinking on the compatibility issues.
>
>        I would assume that, security appliances would be providing 
>both IKEv1/v2
>        and rfc2401/2401bis implementations. In rfc2401bis and IKEv2, there is
>        provision for providing multiple ranges for source and 
>destination selectors.
>        But, rfc2401/ikev1 does not support this combination. Does 
>this mean that, the
>        administrator configuring security policies should have prior 
>(out-of-band)
>        knowledge on remote security gateway capabilities? This does not seem
>        right and I am wondering how do we achieve the backward 
>compatibility where
>        some devices are IKEv2/2401bis capable and some are not.
>
>     Thanks
>     Ravi

Ignoring the ugly issue of manual keying, you will certainly know 
whether a peer is IKEv2 capable when you try to negotiate the IKE SA. 
So, presumably your question is how does a user/admin set up SPD 
entries that take advantage of the new capabilities present in 
24001bis and IKEv2, prior to knowing the capabilities of a peer? Good 
question.

Knowing the capabilities of the peers for which you have authorized 
communication in the SPD is not out of the question, although I admit 
it is not ideal. Presumably you can start off living with the old 
restrictions, since they represent the status quo, and move to the 
new features as you become more confident that peers have upgraded as 
well. One might adopt a fallback approach, i.e., try to negotiate 
IKEv2 and if it fails, use v1, and map SPD entries into v1 
equivalents, which will result in more SAs.

Steve