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

From: Ron Bonica <[email-masked]>
Date: Mon, 11 Jun 2018 19:55:31 +0000

Folks,

Please review and comment on this draft.

                                          Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, June 11, 2018 3:49 PM
To: Ron Bonica <[email-masked]>; Eric Rosen <[email-masked]>; Eric Rosen <[email-masked]>
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

---

From: <[email-masked]>
Date: Thu, 14 Jun 2018 06:17:23 +0000

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-masked]] On Behalf Of Ron Bonica
Sent: Monday, June 11, 2018 21:56
To: [email-masked]
Subject: [bess] FW: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

Folks,

                                          Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, June 11, 2018 3:49 PM
To: Ron Bonica <[email-masked]>; Eric Rosen <[email-masked]>; Eric Rosen <[email-masked]>
Subject: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
BESS mailing list
[email-masked]
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.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Jun 2018 11:13:09 +0200

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, <[email-masked]> wrote:

> 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.
> 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
>
>
> 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
>
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Thu, 14 Jun 2018 10:39:08 +0000

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 ☺
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: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, June 14, 2018 11:13
To: LITKOWSKI Stephane OBS/OINIS
Cc: Ron Bonica; [email-masked]
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, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

Brgds,

Stephane

-----Original Message-----
From: BESS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ron Bonica
Sent: Monday, June 11, 2018 21:56
To: [email-masked]<mailto:[email-masked]>
Subject: [bess] FW: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

Folks,

                                          Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 11, 2018 3:49 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess
_________________________________________________________________________________________________________________________

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Jun 2018 13:01:08 +0200

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 <[email-masked]> wrote:

> 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…
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 14, 2018 11:13
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* Ron Bonica; [email-masked]
> *Subject:* Re: [bess] New Version Notification for
> draft-rosen-bess-secure-l3vpn-00.txt
>
>
>
> Hello Stephane,
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Status:
> https://datatracker.ietf.org/doc/draft-rosen-bess-secure-l3vpn/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-rosen-bess-secure-l3vpn
>
>
> Abstract:

---

From: Ron Bonica <[email-masked]>
Date: Thu, 14 Jun 2018 14:53:14 +0000

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

> From: [email-masked] <[email-masked]>
> Sent: Thursday, June 14, 2018 2:17 AM
> To: Ron Bonica <[email-masked]>; [email-masked]
> Subject: RE: New Version Notification for draft-rosen-bess-secure-l3vpn-
> 00.txt
> 
> Hi Ron,
> 
> 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.
> 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.
> 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.
> 
> 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
> 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:
> 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
> 
> 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=
> 
> __________________________________________________________
> __________________________________________________________
> _____
>

---

From: <[email-masked]>
Date: Fri, 15 Jun 2018 07:52:32 +0000

Hi Ron,

I fully understand the case you are describing and I support this work (speaking as individual).
I think it would be worth to clarify the goals/use cases and if you plan to address the use case that Robert has mentioned.

Brgds,

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]] 
Sent: Thursday, June 14, 2018 16:53
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: New Version Notification for draft-rosen-bess-secure-l3vpn-00.txt

Hi Stephane,

                                                            Ron