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
 >