Re: [bess] New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

[Ron Bonica <[e-mail]>]

Hi Stephane,

Yes, we are talking about a niche use case. We probably should have talked about the use case more in the draft.

Assume the following about an enterprise:

- It has many compartments (VPNs) that requires some degree of separation from one another
- It has many permanent sites
- It has a mission critical requirement for site mobility.

In response to some transient event (e.g., a natural disaster, a sporting event, a geopolitical event), the enterprise may have to add a new site. The site will be secured by the enterprise (hence, the C-PE) and will use whatever connectivity is available (e.g., hotel Wi-Fi).

The site is temporary. Once the transient event is over, the site goes away.

Yes, this is a niche use-case, but the market is large enough to warrant our attention.

                                                            Ron

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, June 14, 2018 2:17 AM
> To: Ron Bonica <[e-mail]>; [e-mail]
> Subject: RE: New Version Notification for draft-rosen-bess-secure-l3vpn-
> 00.txt
> 
> 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:[e-mail]] On Behalf Of Ron Bonica
> Sent: Monday, June 11, 2018 21:56
> To: [e-mail]
> 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: [e-mail] <[e-mail]>
> Sent: Monday, June 11, 2018 3:49 PM
> To: Ron Bonica <[e-mail]>; Eric Rosen <[e-mail]>;
> Eric Rosen <[e-mail]>
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Drosen-2Dbess-2Dsecure-2Dl3vpn-
> 2D00&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=ynt6xEw1IEsGTlD_UKas9ALkZzKN_qfQO9ccs-
> D_xmk&s=WZHJlo1WtiFkNoPygS1bcJe-TVSTCSu4YrVoGckSTgA&e=
> Status:     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Drosen-2Dbess-2Dsecure-
> 2Dl3vpn_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=ynt6xEw1IEsGTlD_UKas9ALkZzKN_qfQO9ccs-
> D_xmk&s=siUM7bajtgMwdB8RGQEqfGIskeMmvVgmJbueM2TQfmc&e=
> Htmlized:  https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Drosen-2Dbess-2Dsecure-2Dl3vpn-
> 2D00&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=ynt6xEw1IEsGTlD_UKas9ALkZzKN_qfQO9ccs-
> D_xmk&s=WZHJlo1WtiFkNoPygS1bcJe-TVSTCSu4YrVoGckSTgA&e=
> Htmlized:  https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Drosen-2Dbess-2Dsecure-
> 2Dl3vpn&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=ynt6xEw1IEsGTlD_UKas9ALkZzKN_qfQO9ccs-
> D_xmk&s=8qEoWVnhEGQT-Xvmq5C8eGsH0eQv7zAhXoKmz7eN2Cw&e=
> 
> 
> 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
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bess&d=DwIFAg&c=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=ynt6xEw1IEsGTlD_UKas9ALkZzKN_qfQO9ccs-
> D_xmk&s=qptmIVc7U_jc-kNnUXNcrnc9Gft_Utcc0-sn0jcMLJg&e=
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.