Re: SPD Policies - Backward compatibility

[Ravi <ravivsn@roc.co.in>]

        OK. Thank you for your and Tero's answers on this subject.
         In site-to-site scenario, I also feel that, it can be assumed that
         administrator need to know the capabilities of peer gateway.
         But this would be a problem in remote access scenario, where peers are
         unknown.
         Since, rfc2401 capabilities can be exchanged using both IKEv1/v2,
         as you indicated, policies can be configured with capabilities given in rfc2401.
         I think I can live with this, rather than creating multiple (could be very high) 
         SA tunnels for each remote user.

         Thanks
          Ravi


Stephen Kent wrote:

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