The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2002-Dec> msg00200



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: MPLS VPN

  • From: Wulf Losee <qx49@attbi.com>
  • Date: Mon, 30 Dec 2002 22:28:23 -0800
  • Resent-Date: Tue, 31 Dec 2002 02:56:44 -0500
  • To: "aleezah khan" <aleezahkhan2k@hotmail.com>, mpls-ops@mplsrc.com
  • X-MIME-Autoconverted: from quoted-printable to 8bit by host.secure4-hosting.net id gBV6Shj24751
  • X-Sender: qx49@attbi.com@mail.attbi.com

Aleezah:
I suggest you should check out the IETF website for the current MPLS drafts 
-- I seem to recall there was talk about developing an RFC for encrypting 
the payload in an MPLS VPN. I don't know if anything ever came of it.

But your PE-to-PE encryption scenario really doesn't provide the customer 
with the maximum security. You've still got the traffic from the CE to the 
PE that's running un-encrypted across a link -- and that would be a natural 
place to try to snoop the traffic.

IPsec VPNs, on the other hand, need to implemented from CPE-to-CPE (where 
an IPsec CPE router is the equivalent to a CE router). This is for both 
technical and security reasons.

Do you work for a service provider? Or are you working for a customer who 
wants their MPLS VPN traffic encrypted?

If you work for the former, you aren't really offering your customers any 
greater amount of security by the PE-to-PE encryption scenario.

If you work for the latter, you'll need to start managing your customers' 
CPEs if you want to offer IPsec encryption. Most customers really don't 
like that scenario -- which is one of the reasons that I don't think IPsec 
has taken off as a managed service offering by SPs -- especially when 
corporations can implement it themselves fairly cheaply.

Sorry I can't be of more help,
--Wulf


At 05:02 AM 12/31/02 +0000, you wrote:


>I know MPLS VPN are implemented by Service Providers for the purpose of 
>TE, But what if I want to provide both TE and security in MPLS VPNs…
>MPLS VPNS certainly is no less secure than a Frame Relay PVC or an ATM PVC 
>they only thing which  really is lacking is that MPLS VPN seeks to ensure 
>data confidentiality by defining a single path between physical sites on a 
>service provider network. This prevents attackers from accessing 
>transmitted data unless they place sniffers on the service provider 
>network. MPLS itself also does not provide encryption.
>Can anyone suggest me a way to implement encryption also on PE…
>What will be the counter measures of implementing encryption at PE.
>Cant we make MPLS VPN an IPSec alternative by providing both secure LSP 
>and encryption..
>
>
>
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 3 months FREE*. 
>http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= 
>http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


  • References:
    • MPLS VPN
      • From: "aleezah khan" <aleezahkhan2k@hotmail.com>