[VPN] Service Provider based IPSec VPN services

[Kent Dallas]

Siddhartha,

I, like Chris, have experience with this problem.  I architected a service
provider solution using (hybrid network-based) IPsec (along with PKI and
comulsory L2TP remote access).

Technically, I agree with everything Chris has mentioned, but I would like
to go a little deeper on a couple of the issues.

1. Same Link Internet/VPN services:

In the "split-tunneling" case, while some customers perceive the benefit of
not backhauling traffic (as Chris mentions), other customers will prefer the
control and security of having all corporate traffic pass through their hub
site firewall/content filtering/network IDS/network Anti-Virus systems for
Internet access. This has a number of administration and policy enforcement
benefits.

"Split-tunneling" is usually mentioned in relation to VPN clients, not
concentrators/gateways.  Often, the gateways are also firewalls, and the
security issues are quite different.  But, split tunneling presumes that the
VPN device is on the customer premises, which seems to violate your second
point.  Without a VPN device on the prem, you will at least need some
(non-VPN) tunneling mechanism to deliver the private network traffic to your
network based gateway across the public Internet link, which may defeat the
savings from not having to administer the VPN CPE.  Either that, or extend
the private network all the way to the service provider's POP. And it may
not satisfy the customer's security concerns that led them to want IPsec in
the first place.

Besides solving the problems above, there are other benefits from using a
separate link, which may justify the additional cost.  Certainly,
eliminating bandwidth contention between general Internet usage and
corporate network traffic is one benefit.  Also, eliminating the risk of a
single Denial of Service attack taking out both public and private data
communications is another.

2. Network-based VPN vs. CPE

As Chris mentions, and you appear to assume, managing VPN CPE is a pain.  As
a service provider, if you chose to do this, in order to scale, you will
have to automate the vast majority of this configuration work.  Once you've
done that, I see little difference, except perhaps cost of equipment,
whether the VPN lives in a separate device or is integrated into the CPE
router.

Unfortunately, the question probably isn't "What is easiest for the service
provider?" but instead "What delivers the best value for the customer?" or
"What architecture appeals to the widest segment of the market?".  Ignoring
these questions is the biggest failing of service provider VPN
implementations, IMO.  More on this below.

3. IP addressing issues

Chris is right, you will run into plenty of issues here.  If you don't use a
"virtual router" type device, such as the vendor list in Chris' response,
you will have scaling issues with dedicated devices, which lead to
management issues similar to CPE (what have you accomplished?).  If you use
a "virtual router" device, you may be eliminating many of the reasons that
customers wanted a VPN in the first place.  If you only support IPsec
between devices on your backbone, you've taken away a major benefit of IPsec
to the customer - the ability to connect securely with anyone on the
Internet.  It also requires the customer to trust the service provider
(which, as I can attest from previous exchanges on this list, many will not
do).  It also leaves the VPN traffic "exposed" across the access link, which
is probably of higher concern than the backbone links (within the service
provider network only) that would be encrypted!  It is quite a quandary for
the service provider.

* IPsec vs. MPLS

For all the reasons that Chris mentions, it is wholly understandable that
service providers lean towards MPLS solutions.  But again, solving the
service provider problems doesn't necessary address the customer's needs!
>From a customer's perspective, MPLS services look very similar to Frame
Relay or ATM.  They may be offered at lower prices, which certainly benefits
customers, but it may fail to address the need that created the interest in
VPN in the first place.  How do you address customer sites that are not on
the service provider's backbone?  How do you integrate remote access VPN?
What about authentication and encryption?  To accomplish these objectives,
you could certainly implement a hybrid solution, integrating both IPsec and
MPLS.  But then you've lost most of the benefits that drove you to MPLS in
the first place!

Since service providers, normally telcos, are so used to supporting layer 1
and 2 services, they are much more comfortable (and likely better) in
supporting new services with these characteristics.  I summarize this
predisposition as, "when you are a hammer, everything looks like a nail".
In this analogy, the fact that IPsec is a "screw" seems to be easily
forgotten.

*****

With all that said, I would urge you to keep your focus on solving CUSTOMER
problems, and not just service provider headaches.  Otherwise, you end up
with an elegent architecture that is easy to manage and administer, but few
will buy.  There are solutions to all of these problems, but no magic
bullet.  To meet the needs of the broad market, you will need to design
FLEXIBILITY into the customer architectures you intend to support.  And,
like Chris, I get paid to architect these solutions for service providers.

(Disclaimer:  If you are a service provider with PTT-type monopoly market
power, you can ignore customer needs much more successfully, at least in the
short term.)

Regards,
Kent Dallas

-----Original Message-----
From: vpn-admin at lists.shmoo.com [mailto:vpn-admin at lists.shmoo.com]On
Behalf Of Chris Carlson
Sent: Wednesday, September 04, 2002 11:42 AM
To: Siddhartha Jain; vpn at lists.shmoo.com
Subject: Re: [VPN] Service Provider based IPSec VPN services


Hi Siddhartha,

All good questions!  I ran the security products group
at a number of ISPs (as well as security consulting
for enterprises) so I can help you here.


> 1. Can I provide the service over the same link on
> which I am providing internet services to the
> customer?

Yes, you can depending on what vendor's VPN equipment
you use.  Most VPN devices support "split-tunneling"
which means that they can encrypt data that is
destined for other locations on the VPN, but allow
unencrypted traffic to the general Internet.

While some consider split-tunnelling to be a security
threat (attackers from the Internet might infect
internal machines and "ride" the VPN back to the
headquarters or other locations), there is often a
networking/business driver that forces
split-tunneling: all traffic destined for the Internet
doesn't have to be backhauled through the VPN to the
HQ location to go out to the Internet, which relieves
congestion on the HQ's links.


> 2. I am aiming at installing no specialized VPN
> equipment at the client location.

Good thought, since it's often difficult to maintain
equipment at customer locations that you don't
directly control.  Plus it gets really expensive to
roll out a dedicated VPN device for each customer.
BUT, this creates a new set of issues, i.e. how do you
effectively do network-based VPNs with some of the
issues you highlight below.

Also, be aware that most every Internet connection
requires a router (to terminate the T-1/E-1, DSL,
Frame, etc.) and most routers nowadays have some type
of IPSec-VPN software available.  So it is possible to
offer a managed CPE-based VPN with an extra VPN
device, just manage the VPN configurations on the
customer router!


> 3. The IP addressing of the client network is
> obviously not under my control.

Correct.  With not many public IP addresses available,
this means the the customer will be doing NAT at their
border router.  And oftentimes, either the VPN devices
is also doing NAT or the VPN devices is inside the NAT
device.

And it's very difficult to terminate VPN sessions
outside the NAT device because then you have to create
a whole set of NAT mappings to access internal
resources, a huge pain I urge you to NOT undertake!

If you wish to support IPSec VPNs in the service
provider network, you need to do IPSec and NAT
services on the same device, and there's only few
system that can do this with multiple customers on one
device: CoSine, Lucent Spring Tide, Nortel Shasta,
NetScreen has a virtual router option, but these guys
are very expensive.  And it's very expensive to put
dedicated VPN devices in your POP just to do
network-based IPSec VPNs.

Which leads us to...


> Do you think, given these constraints, I can deploy
> IPSec VPN? Or do you think in such a case, MPLS is
> the best solution?

Ta-da!  Most service providers are looking at MPLS to
do network-based (unencrypted) VPNs.  No specialized
equipment is necessary at the customer premise, their
existing network infrastructure can support MPLS-VPNs
usually with a code update, the MPLS implemenetation
of most vendors (notably Cisco VRF and Redback
contexts) supports overlapping private IP address
spaces and can do NAT.  The Cisco VRF feature can even
map a Layer 2 VRF to an IPSec tunnel.


If you have more detailed information on what you're
trying to do, I can be more specific.

Also, I'm available for consulting, too, with
reasonable rates!  :-)

Good luck to you!

Chris


> TIA,
>
> Siddhartha
>


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
_______________________________________________
VPN mailing list
VPN at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn