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

[Robert Raszuk <[e-mail]>]

Hi Stefan,

On the topic of multitenancy in customer sites I completely agree with You.

I pointed that to the authors already ;)

But observe that if they also are targeting DCs as the draft says there is
clear need for multi tenancy on compute nodes. I guess they are trying to
cook two meals on the same fire.

But then this is a bit of head on collision course with Contrail ....

Best,
R.

On Thu, Jun 14, 2018, 12:41 <[e-mail]> wrote:

> Hi Robert,
>
>
>
> Thanks for sharing your point of view. I think we just have a different
> reading/understanding of the goals.
>
> I do not disagree with what you say.
>
>
>
> I was not seeing this as an SD-WAN like solution. At least it is not
> presented this way.
>
> I understood the draft as how can I overcome some security concerns today
> with PPVPN.
>
>
>
> I’m fine to build automated VPNs over a public infra like Internet J
>
> If we want to make this solution more SDWAN like (I do not mean a full
> SDWAN solution), we need to involve more automation, especially setup of
> RRs and BGP sessions…
>
>
>
> Again, as I mentioned, the multitenancy is more a nice to have: most of
> customers do not need this.
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 14, 2018 11:13
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Ron Bonica; [e-mail]
> *Subject:* Re: [bess] New Version Notification for
> draft-rosen-bess-secure-l3vpn-00.txt
>
>
>
> Hello Stephane,
>
>
>
> I read the draft with deep interest. In my opinion I completely have
> opposite view to yours - "niche use case" - quite contrary connecting
> customer sites over open infrastructure have already started to happen in
> large scale globally.
>
>
>
> It is not about adding IPSec tunnel here and there - the crux is about
> automating it to accommodate very large scale deployments. Perhaps your
> comment is based on this specific point that IPSec today created manually
> is a niche and therefor automating it does not make sense. But this is not
> about it. It is about transition from SP operated L3VPNs into an
> alternative L3VPN paradigm.
>
>
>
> Yes I understand that the draft may not be very comfortable for SPs who's
> review comes from locking customer to MPLS-L3VPN backbone just like in the
> old days they were locking customer to Frame Relay or ATM backbones :).
>
>
>
> Maybe our definitions of niche is a bit different, but when I look at the
> market cap of SD-WAN vendors it seems like if you would call as niche an
> ant in the forest here we are watching an army of elephants entering the
> woods.
>
>
>
> Yes the draft is just first important step towards standards based open
> infra secure interconnects - it can not be treated as full SD-WAN spec as
> it is missing a lot of important functionalities today addressed in more or
> less proprietary way by any such vendor.
>
>
>
> The technology is not new too ...  since day one we had Carrier's Carrier
> solution when customers could exchange their routes directly. We also had
> tunnel encapsulation attribute in place where we could signal various
> parameters of given encap. However putting it all together as Eric did in
> this document is IMHO a very important step fwd especially coming under the
> umbrella of one specific affiliation :).
>
>
>
> I do support this work and I hope this is just one brick which we can
> start build on going forward standards based interoperable secure
> connectivity over open public IP infrastructure.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jun 14, 2018 at 8:17 AM, <[e-mail]> wrote:
>
> 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://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
> [e-mail]
> 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
> [e-mail]
> 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.
>
>