Dear PR Person:  

My name is Joel Snyder.  I'm a consultant and freelance writer. 
Network World has asked me to review remote access IPSEC VPN
products for their October 28, 2002 VPN Buyer's Guide package. If
you have a product which is designed to facilitate remote access
to corporate networks (either a dedicated VPN device or
router/vpn or firewall/vpn or a software package which includes
VPN capabilities), I would like to invite you to participate in
this review.   Please read on for information about deadlines and
timeframes.

The goal of the review is to educate network managers on the
state-of-the-art in remote access IPSEC VPN products, with
specific emphasis on the  deployment and management of such
products.  Our testing will have three main goals and evaluation
areas:  (1) manageability and suitability for enterprise
deployment, (2) flexibility to support various network
configurations and topologies and authentication methods, (3)
additional enterprise features (such as firewall features or
site-to-site support), and (4) client perception of performance
(which would include time-to-establish SA and single-stream
application thruput over an impaired/low-speed connection).  

I expect that the review will have mixed content, including both
tutorial information and product evaluation information.  We will
assume a basic  knowledge of the issues on the part of readers.

I know that this message is long, but please read at least up to
the FAQs; most of your questions are answered.  

Products will be evaluated using a variety of criteria including
(BUT NOT LIMITED TO !):

1) Manageability and Suitability for Enterprise Deployment

We believe that the technology to build and deploy a small remote
access VPN is fairly pedestrian, with a wide variety of products
available.  We want to stress the ability of these products to
support hundreds or thousands of users, on many different
platforms, with varying levels of expertise.  The goal here is
not to simply list every product which does remote access VPN,
but to identify those which differentiate themselves by being
ready to handle large numbers of users in an enterprise network
setting.


2) Flexibility

Most network managers are deploying VPNs, particularly remote
access VPNs, in existing network environments.  This means that
the VPN device must adapt to the network.  We will look at issues
such as physical topology (what limitations are there on location
of the device?  Interface type/count?), IP addressing (how are
end users assigned IP addresses when connected?), and
authentication technology (can we continue to use our existing
user/password databases, tokens, and smart cards?).  Products
which narrowly constrain implementation choice are not likely to
score as well in this area.


3) Additional Enterprise Features

Although the IPSEC device can be a standalone IPSEC box, there
are many vendors who are choosing to build additional features
into their VPN devices (or add VPN features to existing devices). 
We hope to document what these additional features are so that
network managers can see what the general feature set of the VPN
device is.  Some combinations, such as firewall, personal
firewall, and virus scan or software updates, are fairly obvious. 
If you have other features which you believe distinguish your
product as being more useful or complete,  we hope to identify
them.

We have not established rating criteria for this aspect of the
review.  It is possible that these features will be simply
discussed and not be part of the end rating of the system. 

4) Performance

It is fairly difficult, if not impossible, to stress-test VPN
concentrators.  However, it is fairly easy to test the perceived
performance by any end user of their VPN connection.  We will
test time to establish the security association (i.e., "first
packet" response time) as well as actual SA performance in an
environment where packets must be fragmented and where line rate
is very low.

Please do not take this as an invitation to send your biggest and
studliest box for this test.  We will be testing at typical
"dialin" speeds of 256K or less.


DEVICES WE DON'T WANT TO LOOK AT:

The VPN market is fairly wide and we need to constrain this
review to ensure that the products are fairly compared.  Two
particular classes of devices which we don't want to look at are
(1) non-layer 3 VPN systems and (2) non-IPSEC systems.  

We plan to discuss the concept of alternative VPN technologies,
both in the review and in the accompanying technology brief, but
will not be looking at products.

Network World may also want to include these products in their
on-line Buyer's Guide chart.  If you are interested in pursuing
that opportunity, please contact editor Christine Burns at
cburns@nww.com.  

ACTION ITEMS FOR YOU:

If you would like to participate in the user-to-site review, we
will need the following from you:

0 - an RSVP.  Please let us know if you plan to participate at
the earliest  opportunity.  If we don't hear from you before
August 1st, we'll assume  you're not coming.

It would also be nice at this point in time to know what kind of
product you have (e.g., "we have software which runs on NT" or
"we have a  dedicated hardware solution" or whatever is
appropriate).  

1 - product.  If your product requires dedicated proprietary
hardware, send one.  You should configure the hardware for either
100BASET (preferred) or 10BASET.   If you choose to send a test
system, send the minimum equipment possible; do not send VGA/SVGA
monitors, PS/2 keyboards, PS/2 or serial mice, power cords, patch
cables, or terminals.  

If your product is software-only, please contact me directly to
see how it will fit into the review.   We have adequate stocks of
Intel-based PIII systems here, but not every Unix-flavored
operating system which might go on them.  

For your client, please send whatever client tools which are
available.  If you have Windows, Macintosh, and Linux, send all
three.  We may not be able to test them all, but we'll decide
that after we see what people have to offer.

If you have a deployment tool which could either run on a
dedicated 8-way Sun running Oracle with a secondary LDAP server 
or a Microsoft Access database, please do not send the larger
configuration.  We will trust you if you say that your product
scales up, and we won't give you demerits for not having a
top-of-the-line database to test against.  Our goal is to look at
as many products as possible, and if we have to set up four
separate systems just to deploy the first client for you, then
that's really a waste of time. 

If you have a broad product line, send a product which is in the
$1,000 to $10,000 range.  I would like to compare similar
systems, and a $100,000 system from one vendor is not going to
match up well with a $1,000 system from another.  

If you already have suitable product on-site at Opus One's labs,
then simply tell us to use that.  We'll check in to be sure that
we have the latest software revision, but otherwise you're all
set.

2 - pricing and ordering information.  For reasons which are
never clear, people often forget to tell us how much it costs and
where to buy it.   Please help us out by remembering to include
this.  At a minimum, an 800-number, a non-800 number (for non-US
callers), a URL, and a FAX number would be helpful.

3 - contact information for you.  We need to know the following: 
Who the PR contact is, along with voice and FAX numbers and email
address.   Who a technical contact is, along with voice, FAX, and
email.

4 - Screen shots/product shots.  Don't send those unless we
specifically ask for them.  Network World does not run these very
often, so it's better not to waste time and effort mailing them
around.  

DATES: Our target date to begin testing is August 15.  This means
it would be awfully nice if your equipment and/or software
arrived before then.  If you want any hardware back, send along
appropriate shipping instructions and airbill numbers.  Anything
without this information will be treated as a loan (not a gift)
to our labs. 

The publication date for the review is October 28, 2002.  This is
a "Buyer's Guide" date, which means that it cannot be changed.


INSTALLATION: No, we do not want you to send someone out to
install the software/hardware, unless you always do that for all
buyers.  However, we would like to be able to call technical
support for questions so that we appear as an ordinary customer. 
We would prefer to not call your PR or Marketing people to get
technical support.

If you do send someone, please be sure that they understand the
difference between Phase 1 and Phase 2 negotiations and where PFS
comes into play.  Otherwise, you're wasting airfare.

CONTACTS: I will be doing all of the testing and writing here in
Tucson, under the close supervision of Christine Burns,
Test/Reviews Editor, Network World.  You can contact her at
cburns@nww.com.   My email is jms@Opus1.COM, my phone is +1 520
324 0494 x101 and my FAX is +1 520 324 0495.

SHIPPING ADDRESS: The shipping address for everything is:

		1404 East Lind Road
		Tucson, Arizona, 85719


FAQs:

After writing a lot of reviews on this topic, I thought I'd save
some time and share some common questions and answers with you.

Q1:  Our software will require you to call some support line
which is only open from 9AM to noon, Eastern time, to get a
serial number to unlock it to make it work.  Is this OK?

A1:  No.  Because of the nature of testing, we do a lot of it at
odd hours and on weekends.  If we get your product out of the box
and suddenly discover that it won't work without some magic key
which takes 12 to 48 hours to get, this can throw things off. 
Please make sure that anything needed to make your product work
is in the box you send us. 


Q2:  We think that you're incompetent and want to send one of our
engineers  to configure the software so that you can understand
its cosmic wonderfulness and harmonic goodness.  Is this OK?

A2:  Yes.  Have your engineer send me email and we'll work out a
mutually acceptable day.  Remember that it will be approximately
105 degrees in Tucson before you volunteer someone to come out.


Q3:  We have a new version of the product coming out and want to
send you beta stuff.  Can you ignore any crashing-and-burning
behavior?

A3:  No.  What you send us will get reviewed as if it is a
released and supported product.  We will be happy to review late
betas if the product will be released by the time the review is
printed.  We will only look at one version of your product.


Q4:  Our software is on the Web!  All you have to do is click on
...

A4:  No.  Send us a shrink-wrap version of your stuff.  This is
important because then everyone knows that we're reviewing the
correct version of the product.  


Q5:  Our documentation is online!  All you have to do is click on
...

A5:  No.  If you can't be bothered to print it, I can't be
bothered to read it. 


Q6:  I don't want to tell you how much it costs.  Is this OK?

A6:  Sure, so long as you don't mind us telling people it costs
$92,000 per client.


Q7:  We only want to be reviewed if we get the blue ribbon.  Can
we call you and have 9 people crowded around a speakerphone quiz
you for a couple of hours about your methodology so we can
predict whether or not we're going to win before we send the
stuff?

A7:  No.  Your feedback on proper testing methodology is always
welcome, and any ideas you have on how to fairly compare products
with disparate design goals is very useful.  However, the test
methodology generally changes form as we look at products.  In
most cases, products are tested 3 times: once with a first pass,
once again after we learn what the bugs are in our testing, and a
third time just to make sure that we have all the facts right.  I
don't believe that I can design a perfect test before ever
looking at the products, and I don't believe that it's in your
best interest for me to lock down the test before seeing the
nifty new features which you've added since I last looked at
them. 


Q8:  Should I send you <x>?  (<x> is usually a white paper,
competitive review, or explanation of why everyone else's product
loses big)

A8:  Yes.  


Q9:  I have this marketing manager who wants to chat you up for a
couple of hours on his car phone while driving home.  This will
make you like us better and be less likely to tell people our
product sucks.  Can I have him call you?

A9:  Please don't.  The deadlines on this test are very tight and
such conversations, while often interesting, generally are a
waste of time.


Q10:  Will you tell us who else is in the review?

A10:  "The usual suspects."  


Q11:  I cannot possibly make your deadlines.  Can you completely
rearrange your print schedule because some dweeb in our company
lost the invitation and didn't get it to the right person (or: we
didn't think it was important so I didn't read this until too
late)?  

A11:  No.  Someone decided months ago that there would be a
review of this product in August and not May.  I'm not allowed to
revisit that decision.  I understand that this can mean that
significant lacunae will be present in the product lineup, but
that's the way the presses run.  If you want to avoid this kind
of problem in the future, you can always call your top-10 trade
magazines each October and ask them to send you their editorial
calendars for next year.  They will be happy to do this and
you'll be prepared for what's coming up.  I hear you can also
find this on the web; if you don't know what the web is, call
1-900-GET-AOL and the nice man will explain it to you.


Q12:  Can I call you every few days to see how things are going?

A12:  Yes.  In fact, this is not a supremely bad idea.  However,
you should not be insulted if no one takes your calls or calls
you back.  Generally, this means that things are going fine. 
Your success rate for status reports will increase approximately
1000% if you use email instead of the phone.  


Q13:  Can you be bribed?  

A13:  Unfortunately, no.  You are welcome, however, to put me on
your Christmas gift list for chocolate chip cookies.  


Q14:  If I leave my <hardware>/<software> in your lab after the
review, will that positively affect the outcome of the review? 
(alternatively: if I insist that you return the
<hardware>/<software>, will that negatively affect the outcome?)

A14:  No.  


Q15:  Our product doesn't fit in the review, but we'd love to
have you write a sidebar just about us.  Should we call you a lot
to discuss this idea?

<or> We are the industry leading SSH/SSL/SOCKS/MPLS/L2TP/PPTP vendor
and this is definitely a security VPN product.  You are making a
big mistake by not including our product in comparison to those
silly IPSEC boxes.  Don't you want to reconsider?

A15: No.  Call the editor and talk her into it.  Hint: she
probably won't call you back. 


Q16:  Our product doesn't do IPSEC, but we have a proprietary
security model which is actually better than IPSEC and more
secure.  They are using this at the <insert 3-letter agency
here>.  Don't you think it's a disservice to your readers to only
include standards-based technology which has been through
extensive peer review and is widely accepted, especially when our
stuff is so much better?

A16:  No.  Peddle that snake oil somewhere else.  


Q17: You know, our product was named "New fangled gadget of the year" by
the editors of <x> Magazine (alternatively: at the <x> trade
show), so ...

A17: I don't mean to interrupt, but, <x> Magazine is a miserable
trash-stuffed rag of a magazine through which the pathetic blitherings of an
army of knuckle-dragging toadies are shepherded to prominence by the
unprincipled back-room machinations of a pea-brained lackwit of an editor whose
fawning subservience to the power clique that controls the advertising
department is matched only by his (her) contempt for civilized standards when
dealing with the work of those whose integrity prevents them from prostituting
their work by kowtowing to the self-ordained guardians of a baseless
pseudo-theoretical hegemony.   (apologies to Pullum)