[vpn] Review of 13 VPN products
Dana J. Dawson
djdawso at qwest.com
Thu Oct 4 19:36:10 EDT 2001
I think at least part of the issue here is with semantics rather than technology
(specifically with the word "policy"), but I stand by my initial comments.
Here's why:
This is the statement from the article that triggered my response:
> To keep VPN configuration manageable within the command line environment, Cisco
> allows for only a single Internet Key Exchange (IKE) policy per system.
Here's a quote from the online Cisco IOS documentation for version 12.0 IOS,
which is the most recent version of IOS that has any releases that are GD. The
same text appears in subsequent versions of IOS documentation:
> IKE negotiations must be protected, so each IKE negotiation begins by each
> peer agreeing on a common (shared) IKE policy. This policy states which
> security parameters will be used to protect subsequent IKE negotiations.
>
> After the two peers agree upon a policy, the security parameters of the
> policy are identified by a security association established at each peer,
> and these security associations apply to all subsequent IKE traffic during
> the negotiation.
>
> You can create multiple, prioritized policies at each peer to ensure that
> at least one policy will match a remote peer's policy.
The above quote can be found at this URL:
<http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt4/scike.htm#xtocid100628>
So, given that the original (and rather general) statement from the article and
Cisco's documentation are directly at odds, it hardly seems "arrogant" to
question the statement from the article, especially when one can, indeed,
configure multiple isakmp policies (using Cisco's use of the term) in a router,
just as Mr. Raymakers did. I would expect it to be possible to create a
configuration similar to Raymakers' that would behave the way Mr. Snyder
describes below, though I admit that I have not done so. My understanding of
the intent behind multiple isakmp policies in IOS (or policy clauses, or
whatever you want to call them) suggests to me that it should work, however. If
the testers were not able to do so, perhaps it was due to a bug in the level of
software they were using, especially if they restricted themselves to using only
General Deployment software. VPN technology is still new enough that one must
be willing to use the latest available software. The article didn't specify
what software was used. It's certainly possible that they did use the latest
software and that it still didn't work. In any event, I do not see the
justification for the description in the article that the reason was "to keep
VPN configuration manageable within the command line environment." To me, that
appears to be an assumption on the part of the author that is not supported by
Cisco's documentation.
While I did not include the specific reference above in my initial message, I
also stand by my statement that it's easy to find the above referenced
documentation. Was it appropriate for me to question the testers' credibility?
I'll let the individuals who subscribe to this list decide that for themselves.
Personally, I expect anyone who publishes results of tests of this sort,
especially in a widely respected technical publication, to do a thorough job of
researching the subject and presenting their results. On this particular
technical point, and I'll grant that it's perhaps a small one, I don't think an
adequate job was done. Describe that how you like. Given one such discrepancy
in an article of such scope, is it unreasonable to question the rest of the
article? Perhaps, perhaps not, but I did.
These are the justifications I had for stating my opinions, which is all they
were - opinions. Others should read the article for themselves and form their
own opinions. Based on the discussions that followed my original message, I've
also formed additional opinions, but I'll keep them to myself.
Please feel free to direct any additional comments you may have on this topic to
me directly.
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."
Joel M Snyder wrote:
>
> It's easy to make arrogant and unsupported statements like that, but it would
> be more useful to everyone --- including the un-credible author of the
> article --- if you would offer some proof.
>
> In the version of IOS and of PIX which was tested, I claim that you can have
> only a single IKE policy, which is an ordered list of IKE transforms and
> proposals which are acceptable. That policy may have multiple transforms, but
> you cannot express a policy such as, for example:
>
> When initiating an SA to 1.2.3.4, I would like to use certificates.
> When initiating an SA to 2.3.4.5, I would like to use PSS.
> When initiating an SA to 3.4.5.6, I would like to use certificates,
> but I would fall back to PSS.
> When initiating an SA to 4.5.6.7, I would like to use certificates,
> but I would fall back to encrypted nonces.
> When initiating an SA to 5.6.7.8, I would like to use PSS, but I
> would also be willing to use certificates.
>
> If you can offer a working Cisco config on a GD release, I'll happily
> apologize and offer a correction.
>
> jms
>
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
> jms at Opus1.COM http://www.opus1.com/jms Opus One
>
> >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
More information about the VPN
mailing list