SPD Policies - Backward compatibility

[Tero Kivinen <kivinen@iki.fi>]

Ravi writes:
> 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.

You can simply expand all list of ranges to single ranges for
IP-addresses, i.e. instead of creating 1 SA which will carry packets
from source ip-ranges 10.0.0.0-10.0.0.255, 10.0.2.128-10.0.2.222 you
will create two SAs, one for each range.

This will work fine with IP-address ranges, but it will not work well
on port ranges (it would be little bit annoying to create 65534 SAs to
expand the port range 1-24, 26-65535 :-). On the other hand you can
there create SAs per port basis, i.e. when the port is first time used
you create new SA for that (per port pair SAs).

This is again quite a lot more expensive than IKEv2 case, but it will
still work even if the other end only supports IKEv1. 

> Does this mean that, the administrator configuring security policies
> should have prior (out-of-band) knowledge on remote security gateway
> capabilities?

In most of the cases the administrator already have the prior
knowledge about the remote security gateway capabilities, as he also
configures that end :-)

If he knows that the remote end only supports IKEv1 he should try to
avoid expensive constructs (i.e. port holes etc), or the IKEv2
implementation can also disallow talking with IKEv1 implementations
when such constructs is used. It is mostly implementation issue. 

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

As I said the IKEv2 implementations can expand their policies to the
IKEv1 compatible format, but it might be very expensive in some cases
(port holes, port ranges, multiple source and destination ranges etc).

Whether the implementations will support that is another matter, and
whether adminstrators configure systems and use those features is yet
another matter. 
-- 
kivinen@safenet-inc.com