[vpn] Review of 13 VPN products

Joel M Snyder Joel.Snyder at Opus1.COM
Thu Oct 4 10:38:57 EDT 2001


>Pls, correct me if I'm wrong...

>Isn't so that only one Crypto map can be applied at one interface. This
>crypto map is really the collection of all IPSEC parameters for a given
>connections (one crypto map can have multiple instances). However to my
>knowledge, the IKE (ISAKMP) settings are not really matched with a crypto
>map. So if this is correct, this could imply that many IKE policies can be
>set for one crypto map and it's up to the IKE negotiation to pick the IKE
>policy that is matching.

You can only have one crypto map on an interface; this is what governs IPSEC
policies.  A crypto map specifies peer addresses, so you have the option of
saying something like "when I get to 10.0.0.0 via THIS interface, I want 3DES;
when I get to 10.0.0.0 via THAT interfaces, I want DES."  You have more
flexibility than most people need in terms of IPSEC policies, because you can
make them interface directional.  This is probably most useful in a highly
NAT-ed environment where different interfaces are really pointing to different
entities.

Be careful in your use of the word 'policy.'  A policy is an ordered set of
proposals and transforms.  Thus, a policy might be "3DES, with either SHA1
(preferred) or MD5."  That's a policy.  If you wanted to say "AES with MD5
(preferred) or SHA1, DHG5 (preferred) or DHG2,"
that's another policy.  You can express many IPSEC policies; you can express
only one IKE policy.

However, the problem is that there is only a single IKE policy (one "crypto
isakmp" set of statements), which applies to the entire box.  Notice that while
it's an ordered list of proposals/transforms, it has no 'name' which means that
you can't refer to it---you can't apply it to an interface, etc.  That single
IKE policy applies to all negotiations with all peers. 

In the real world, it is actually IKE which is the problem in interoperability,
rather than IPSEC.  (See, for example, all of the discussions on the IETF IPSEC
list about "son of ike")  Thus, while it's nice to have really sophisticated
IPSEC knobs, most people are content with a single set of 3DES/SHA1/PFS-G2 kind
of parameters and don't want to fiddle with them beyond that.  The exception,
of course, is into export controlled environments, but you can generally solve
that with a single policy which has ordered transforms.  But there's no problem
here if Cisco gives you MORE flexibility than you want.

In the IKE policy, there is no analog to the extreme flexibility of the IPSEC
policy.  You can only create a single IKE "crypto map," and that map applies to
any negotiations with any peers.  A secondary issue is that Cisco's ability to
fine tune IKE/IPSEC parameters is fairly poor.  For example, you cannot specify
whether you want SA lifetime to be expressed as ONLY time, or as ONLY bytes;
you cannot specify that X.509 DNs be used with some peers and SubjectAltNames
with others.  (generally, certificate support is the bare minimum required to
say 'we support certs'; they could go a lot further in that direction.  See,
for example, the Contivity interface which is both powerful and easy to use.)

jms



>Ref the example :

>Is the router running the below config and set's up a tunnel to gateway
>A.B.C.D, then it will negotiate the correct ISAKMP policy, this could be PSS
>or RSA-ENCR, the same when it set's up a tunnel to gateway W.X.Y.Z. This
>means that there are more then one policy on the device, but only the first
>policy that matches with the remote policy will be used.

>crypto isakmp policy 21
> hash md5
> authentication pre-share
> group 2
> lifetime 57600
>!
>crypto isakmp policy 22
> hash md5
> authentication pre-share
> group 2
> lifetime 28800

>crypto isakmp policy 26
> encr 3des
> hash md5
> authentication rsa-encr
> group 2
> lifetime 28800

>crypto isakmp key psssecret1 address A.B.C.D
>crypto isakmp key psssecret2 address W.X.Y.Z

>!
>!
>crypto ipsec transform-set transformset-1 esp-des esp-md5-hmac
>crypto ipsec transform-set transformset-2 esp-3des esp-md5-hmac
>!
>crypto key pubkey-chain rsa
> addressed-key A.B.C.D
>  address A.B.C.D
>  key-string
>   30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00D03B5A
>   000AE463 32E9636E D3F822DE F520D31E BDBBCB00 6F0C47C5 B8F58D7E 5E25F4B9
>   0C9C2CEF 12F4C1A9 CD046732 4D3F12B2 D3355B70 0273D2A7 20D7EDAE E0D2F739
>   68807EF4 E7FAFE39 34C7B9BB CDF154A8 A9C4BD98 9A7BEEC0 B58B482D B436E43C
>   BD55E5BC B2E30886 D2427C5C C0B6332B 0DF2CB30 F742F737 EACC4088 5F020301
>0001
>  quit

> !
>crypto map cryptomap 1 ipsec-isakmp
> set peer A.B.C.D
> set security-association lifetime seconds 28800
> set transform-set transformset-1
> match address 100
>!
>crypto map cryptomap 2 ipsec-isakmp
> set peer W.X.Y.Z
> set transform-set transformset-2
> set pfs group2
> match address 101
>!
>interface Tunnel0
> ip address 172.25.1.161 255.255.255.224
> no ip unreachables
> tunnel source 10.16.23.28
> tunnel destination 10.162.144.21
> crypto map cryptomap
>!
>interface Tunnel1
> ip address 10.10.10.9 255.255.255.252
> no ip unreachables
> tunnel source 10.132.78.3
> tunnel destination 14.228.170.55
> crypto map cryptomap
>!
>interface FastEthernet0
> crypto map cryptomap



>However, if you run IPSEC and from one point to another and you wnat to have
>different policies for different combinations of destinations/sources, then
>you have no choice, but to use a single IKE policy between the VPN Routers,
>but you can create different IPSec policies (transforms) to protect some
>data streams in different ways.

>Sorry for the long mail .....

>cheers,
>Guy


>-----Original Message-----
>From: Tim Slighter [mailto:timslighter at home.com]
>Sent: Wednesday, October 03, 2001 10:33 PM
>To: vpn at securityfocus.com
>Subject: FW: [vpn] Review of 13 VPN products


>I believe what they may have been referring to is that only one ISAKMP can
>be matched against the outside interface at one single point in time.

>-----Original Message-----
>From: Dana J. Dawson [mailto:djdawso at qwest.com]
>Sent: Wednesday, October 03, 2001 12:04 PM
>To: Joel Snyder
>Cc: vpn at securityfocus.com
>Subject: Re: [vpn] Review of 13 VPN products


>Joel Snyder wrote:
>>
>> Folks:
>>
>> In case you hadn't seen it, Network World just published a review I did
>> of 13 different VPN products, focusing on site-to-site and enterprise
>applications:
>>
>> http://www.nwfusion.com/reviews/2001/1001rev.html
>>
>> --
>> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
>> +1 520 324 0494 x101 (voice)    +1 520 324 0495 (FAX)
>> jms at Opus1.COM    http://www.opus1.com/jms    Opus One
>> Electronic mail is always the best way to contact me.
>>
>> VPN is sponsored by SecurityFocus.com

>I disagree with the assertion in the article that the Cisco products only
>allow
>a single IKE policy to be configured.  Both IOS and the PIX allow multiple
>isakmp policy clauses, and it's not very hard to figure that out.  If the
>people
>doing the testing missed something this obvious when configuring the Cisco
>gear,
>it makes me wonder how much else they might have missed.  Because of this, I
>have serious doubts about the credibility of the testers and their results.

>Dana

>--
>Dana J. Dawson                     djdawso at qwest.com
>Senior Staff Engineer              CCIE #1937
>Qwest Global Services              (612) 664-3364
>Qwest Communications               (612) 664-4779 (FAX)
>600 Stinson Blvd., Suite 1S
>Minneapolis  MN  55413-2620

>"Hard is where the money is."

>VPN is sponsored by SecurityFocus.com


>VPN is sponsored by SecurityFocus.com

>VPN is sponsored by SecurityFocus.com


VPN is sponsored by SecurityFocus.com





More information about the VPN mailing list