The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: off net access to 2547 PE
Mike, Ideally you would be able to find one box to handle both IPsec and MPLS. Cisco provides some direction on trying to do this by co-locating a VPN5000 with a PE: http://www.cisco.com/warp/public/732/Tech/mpls/docs/ipsec_mpls_vpn.ppt my sense is that this kind of merging of off-Net IPsec with on-Net is still at the early stages. I am not aware of any service provider who is doing this today. my 2 cents chris -----Original Message----- From: Mike Duckett [mailto:mduckett@bellsouth.net] Sent: Sunday, February 24, 2002 9:26 AM To: mpls-ops@mplsrc.com Subject: RE: off net access to 2547 PE -----Original Message----- From: Mike Duckett [mailto:mduckett@bellsouth.net] Sent: Sunday, February 24, 2002 8:05 AM To: mpls-ops@mplsrc.com Subject: off net access to 2547 PE Cisco, Juniper, ... and operators... I noticed a recent thread on what you called "various media/protocols accessing a MPLS VPN". Basically, you have a problem where customer sites or mobile workers are not directly connected (via circuit nor ATM/FR/..) and require access to the VPN. One approach is to mix and match overlay VPNs (e.g, IPSec) with 2547 VPNs. Certainly there are religious and non-religious views on how to address a non-directly connected CE. I'm particularly interested in the view of Cisco and Juniper as well as service providers as to how they can support a large scale 2547 service in conjunction with off-net users. I'm interested in two "virtual" interface options including: (1) PPP/L2TP (could be used for cable, dsl, ..) access into a VPN. In this case, the network between the PE and the customer is a "broadband" aggregator functioning below the IP layer as far as the customer is concerned. (2) IPSec into a VPN. In this case, I have customers with off-net sites that need access to the VPN, both mobile workers and dedicated sites, and are not directly connected to my network. > Are folks looking at X.509v3 extensions to carry service attributes (e.g., access lists, ip addresses) or is PPP used inside the IPSec tunnel? Again, trying to develop a scalable architecture and deal with (1) VRF/VPN identification, (2) IP security profile, (3) service attributes such as IP address, access lists, QoS policy. Seems like either (a) X.509 certificate to address IPSec component along with PPP/IPsec using Radius/LDAP, or (b) X.509 with extensions addressing service attributes would be the basic options. What are vendors implementing? Overarching: Can this be done? If so, can you point me to a detailed architecture? How to you manage AAA (authentication and authorization attributes) for users? Can this be supported in Radius or LDAP? What models do you support for key management as well as things like issuing session attributes (e.g., traffic filters, diff serve)? Can this be integrated into Radius as well? How do you see building a large off net PE connection scheme (e.g., using IPsec and PPP/L2TP)? You have problems like scaling VRFs, scaling encryption, load sharing, distributed PEs, etc... ------- 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 ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|