The MPLS-OPS Archive

["Alfred Denzler" <alfred.denzler@netsurfer.ch>]

Title: RE: IPSec and MPLS

Francois,

 

I personally like the VRF based option as not all customers want to encrypt their traffic. And it would be definitely more scalable. But their's a legal side to it as banks have to do end-to-end encryption as due to our laws they shouldn't expose their data traffic anywhere in the network. Your solution 2 would do this.

What about a two box strategy?

I see this as a more scalable solution, as a CE doesn't have to deal with encryption (performance issue) and at the same time we as a provider would be able to leave key management to the customer and still have full control over the CE!

 

In case of a one box strategy, how can we solve key management? Are there approved and in the industry accepted tools (IPSec Management Software) to offer customers a trusted way to do key management? Any hints?

 

Thanks

 

Fredi

-----Ursprüngliche Nachricht-----
Von: Francois Lemarchand [mailto:Francois.Lemarchand@cosinecom.com]
Gesendet am: Mittwoch, 20. Februar 2002 14:35
An: 'alfred.denzler@netsurfer.ch'; mpls-ops@mplsrc.com
Betreff: RE: IPSec and MPLS

Alfred,

I see three options to provide IPSec in the core,
where the option 3) is option of the 2547bis.

1) IPSec tunnel mesh CPE (site) based.
   Full mesh beween the sites :
    - scalability issue for the CPEs
    - difficult to manage
    - need to provision <number-of-existing-cpe>
      ipsec tunnels each time you add a site
    
2) IPSec tunnel mesh VR (VRF) based :
    Full mesh between the VR/VRF of the same VPN
    + routing and ipsec scalability has been reduced
    + network based services
    + need to provision <number-of-existing-pe>
      tunnels only when you add a vpn

3) IPSec tunnels mesh PE based
    Full IPSec mesh between PE, the tunnel is used
    as an LSP between the PEs
    + scalable route distribution mechanism (2547)
    + network based services
    + no need to provision new ipsec tunnels when
      adding sites or vpns.

You also have a 4) option where the CPE has a single
tunnel that terminate into the VRF, and where 2) or 3)
is used in the core. This is a tradeof between true end-to-end
encryption and a scalable network.

What do you think ?

Francois

-----Original Message-----
From: Alfred Denzler [mailto:alfred.denzler@netsurfer.ch]
Sent: mardi 19 février 2002 20:18
To: mpls-ops@mplsrc.com
Subject: IPSec and MPLS

Hi there,

I'm planning to introduce an IP encrytion service on our MPLS network, and
would like to here your opinion of how IPSec and MPLS are matching. They are
both used to build VPN's over a public network and it seems pointless to use
them in combination! Except when we want to encrypt VPN traffic over an MPLS
network.
I have a few specific questions which I believe are worth thinking about.(We
are using hardware from THE vendor)

- What is the impact on performance when turning on IPSec on a CE? (not
directly related to MPLS)

- Is IPsec really scalabel in VPN's with 100-200 sites?

- As a consequence of using IPSec in an MPLS network, can I still offer CoS
or
are there any restrictions? (queuing,traffic classification, DSCP in IPSec
header)

- How is key management solved if encryption happens on a managed CE and key
management has to be done by the customer?

- Is IPSec on the CE the right solution or is a two box strategy the better
option? (e.g. clear interface between provider and customer)

- Are there any better solutions for encryption over an MPLS network?

Thanks a million for your answers!

Fredi

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
###################################################################################################### This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above.  If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ######################################################################################################