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: [email protected] <[email protected]>
> Sent: Thursday, June 14, 2018 2:17 AM
> To: Ron Bonica <[email protected]>; [email protected]
> 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:[email protected]] On Behalf Of Ron Bonica
> Sent: Monday, June 11, 2018 21:56
> To: [email protected]
> 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: [email protected] <[email protected]>
> Sent: Monday, June 11, 2018 3:49 PM
> To: Ron Bonica <[email protected]>; Eric Rosen <[email protected]>;
> Eric Rosen <[email protected]>
> 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
> [email protected]
> 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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
