Hi Ron, I have read quickly the document. I think the use case of having secure L3VPNs is valid and we already have all (or most of) the technology building blocks to do it. Now the draft takes a complete upside down approach comparing to our well known L3VPNs which are provider provisioned VPNs as you propose to build them at the CE side. This could be a valid approach but isn't it a niche use case ?
Customer sites connected over the Internet is for sure a use case to handle, and we already to it today by establishing an IPSec tunnel towards an SP-PE, the tunnel ends in the customer VRF. Customer data must not be exposed: also a valid use case. We have some customers doing IPSec transport within MPLS VPN for some specific traffic. On the other hand, from an SP point of view, when core links are not fully trusted, MACSEC or IPSec are also options. I'm less convinced by the routing that should not be exposed. I agree that this is a possibility and a valid use case but I do not think that this is a big deal for most of customers (even those requiring more security). The good thing of MPLS VPN is the routing complexity is almost pushed to the SP and the customer has few things to do and they are happy with that. The last case of the multitenancy on the customer side is also valid, but I also think that it is a niche use case. My point is that the draft is currently focusing on one scenario which in my opinion addresses a niche use case while there may be intermediate scenarios (like no multitenancy and/or no need of routing protection) that could be more widely applicable. Brgds, Stephane -----Original Message----- From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ron Bonica Sent: Monday, June 11, 2018 21:56 To: bess@ietf.org Subject: [bess] FW: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt Folks, Please review and comment on this draft. Ron -----Original Message----- From: internet-dra...@ietf.org <internet-dra...@ietf.org> Sent: Monday, June 11, 2018 3:49 PM To: Ron Bonica <rbon...@juniper.net>; Eric Rosen <ero...@juniper.net>; Eric Rosen <ero...@juniper.net> Subject: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt A new version of I-D, draft-rosen-bess-secure-l3vpn-00.txt has been successfully submitted by Eric C. Rosen and posted to the IETF repository. Name: draft-rosen-bess-secure-l3vpn Revision: 00 Title: Augmenting RFC 4364 Technology to Provide Secure Layer L3VPNs over Public Infrastructure Document date: 2018-06-11 Group: Individual Submission Pages: 19 URL: https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00 Status: https://datatracker.ietf.org/doc/draft-rosen-bess-secure-l3vpn/ Htmlized: https://tools.ietf.org/html/draft-rosen-bess-secure-l3vpn-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-rosen-bess-secure-l3vpn Abstract: The Layer 3 Virtual Private Network (VPN) technology described in RFC 4364 is focused on the scenario in which a network Service Provider (SP) maintains a secure backbone network and offers VPN service over that network to its customers. Customers access the SP's network by attaching "Customer Edge" (CE) routers to "Provider Edge" (PE) routers, and exchanging cleartext IP packets. PE routers generally serve multiple customers, and prevent unauthorized communication among customers. Customer data sent across the backbone (from one PE to another) is encapsulated in MPLS, using an MPLS label to associate a given packet with a given customer. The labeled packets are then sent across the backbone network in the clear, using MPLS transport. However, many customers want a VPN service that is secure enough to run over the public Internet, and which does not require them to send cleartext IP packets to a service provider. Often they want to connect directly to edge nodes of the public Internet, which does not provide MPLS support. Each customer may itself have multiple tenants who are not allowed to intercommunicate with each other freely. In this case, the customer many need to provide a VPN service for the tenants. This document describes a way in which this can be achieved using the technology of RFC 4364. The functionality assigned therein to a PE router can be placed instead in Customer Premises Equipment. This functionality can be augmented by transmitting MPLS packets through IPsec Security Associations. The BGP control plane sessions can also be protected by IPsec. This allows a customer to use RFC 4364 technology to provide VPN service to its internal departments, while sending only IPsec-protected packets to the Internet or other backbone network, and eliminating the need for MPLS transport in the backbone. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
