Re: VPN security vs SD-WAN security
"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 30 July 2018 15:04 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053591310EF; Mon, 30 Jul 2018 08:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rttIYwMi96Fw; Mon, 30 Jul 2018 08:04:48 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BFC1310E9; Mon, 30 Jul 2018 08:04:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CC36D740275; Mon, 30 Jul 2018 08:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1532963088; bh=6A0Tm05po20oxferruqwodbWqVVOhs3Myg99HgyfvnQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LPtzFbUgJC821Uz9r8sQlxiG+ijvmJizrSWyZMhqzUZATJ6q3beCKkto8SJkFK1kr Nc5PzXTCp6T2UiklbqoyLCEQEIh3DmM7oKUx0kc1pPfSXK3GwhWoGUqWWOP5ywhffR CC4UfCjt66eZlIQ9T9LqqE1pdPmlonGpGVeAgXmA=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7D945740245; Mon, 30 Jul 2018 08:04:47 -0700 (PDT)
Subject: Re: VPN security vs SD-WAN security
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: "TEAS WG (teas@ietf.org)" <teas@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
References: <CA+b+ERmfOaFMURD2eNPScs2SZ88rOEfGXZZJsqGDWX3M6bTY-g@mail.gmail.com> <0cb8f15b-7538-500c-dda3-915bf9814f94@gmail.com> <5D10C0C4-B93D-463F-A071-EEA6F35506CD@cisco.com> <CA+b+ERkqrr4Wr+Wy9q81SpyWi7H1s=z_RAvbc3Rbddvpgb7Xpg@mail.gmail.com> <76CD132C3ADEF848BD84D028D243C927A71506F6@NKGEML515-MBS.china.huawei.com> <CA+b+ERmWDhXf0ia8mQ25=QZw-h_ipkAQnttsirQb3kOk_fhUVA@mail.gmail.com> <CA+RyBmX1Wj-aH+rWhQ1LLVrBkEq12Hz-DT1gYBF0TRx1ewaEzg@mail.gmail.com> <CA+b+ERmOFwgv+_8KBUx_sQnxXxgua53j5d8QEm=C9ppObkgwVQ@mail.gmail.com> <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com>
Date: Mon, 30 Jul 2018 11:04:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927A72042AB@NKGEML515-MBS.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/VETVyzMp_vK9oqfnWTnqdezJ8w8>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 15:04:52 -0000
Actually, assuming I understand the statement properly, "deep integration with the underlay resource would be necessary" does not appear to be an accurate statement derivable from the requirements that I have seen. Yours, Joel On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote: > (Adding TEAS as it is where the VPN+ framework draft is discussed) > > Hi Robert and Greg, > > As discussed during the VPN+ presentation in TEAS at IETF 102, the scope > is not the internet, as we know it would quite difficult or even > impossible to achieve the required guarantee at the scope of internet. > > And clearly the VPN overlays cannot provide the required guarantee, deep > integration with the underlay resource would be necessary. > > Another aspect we may take into consideration is the factor of > overprovisioning. The current network only has one overprovisioning > factor, which may not meet the requirement of different > services/customers. With network slicing, it is possible to have > different overprovisioning policy and factor in different slices. > > Best regards, > > Jie > > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of > *Robert Raszuk > *Sent:* Sunday, July 29, 2018 6:11 AM > *To:* Greg Mirsky <gregimirsky@gmail.com> > *Cc:* Dongjie (Jimmy) <jie.dong@huawei.com>; rtgwg@ietf.org > *Subject:* Re: VPN security vs SD-WAN security > > Hey Greg, > >> > > would not require global transit and likely be contained within > access or, at most, metro domains. > > That's news to me, but perhaps on the positive side :) I always think > WAN .. really wide one ! > > The separation on "soft" vs "hard" guarantees is eventually all about > amount of network robustness and level of over provisioning. I > sincerely hope it will not be yet another EVPN overlay over IP network > just painted with different marketing colors. > > Besides if any customer is serious and actually counts on those > guarantees he better purchase two of such services coming from > independent operators. That means that to be attractive financially cost > of such premium service must not be higher then half of the p2p local > fiber or cost of local access to closest IX ports + port subscription in > a given MAN where non blocking IX fabric spans given geography. > > It seems to me that at the end of the day the space for those operators > wishing to offer hard network slicing is actually pretty narrow, but > time will tell ... > > Rgs, > > r. > > On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>> wrote: > > Hi Robert, > > very much agree with all you're saying and find us in violent > agreement on "C". Proactive performance monitoring, in my view as > well, is the reasonable path to provide "soft" SLA and, to a degree, > prevent oversubscription of the network. And that, as you've said, > is one way to "assured/guaranteed global IP transit". > > But I think that there will be demand for "hard" guarantees for > URLLC applications. But these, in my view, > > would not require global transit and likely be contained within > access or, at most, metro domains. Because of the limited size of > the domain, IntServ may work, though that may be not the most > efficient technique. We shall find out. > > Hence my view on slicing: > > * different applications will have different requirements and use > different degrees of isolation and guarantees; > * "soft" slices may not need much of additional standardization > and use available VPN technologies in combination with PM OAM > for SLA monitoring and assurance; > * "hard" slices would span within a single access and/or metro > domain. Networking solutions likely will be coupled with > architecture and interfaces developed in Multi-access Edge > Computing (MEC). > > Regards, > > Greg > > On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk <robert@raszuk.net > <mailto:robert@raszuk.net>> wrote: > > Hi Jie, > > > (network slicing) is to provide the demanding services with guaranteed performance in a converged network, > > Foundation of converged IP network is based on statistical > multiplexing of traffic demands. As such it is in its principle > quite contradictory to "guaranteed" characteristics > (performance, delays, jitter, drops -- you name it). > > Application layers usually deal very well with all of the above > I would state - normal characteristics of IP networks.. > > No doubt there will be those trying to offer some network > slicing with guarantees and even those who will buy it. Just > like today there are those who offer you L2 circuit between > endpoints except such L2 circuit is an emulated one with zero > OEM visibility to the IP infrastructure underneath. > > Now the network slicing is clearly aiming for even more > complexity under the hood. And that is not the only problem. The > issue is cost. When SP is building the IP network the goal is to > mux as many services on it as it simply results in given's SP > revenue. Network slicing is promising as potentially just by > configuration of few knobs they will be claiming guarantees as > RFC says - except RFC will not likely tell you to stop > over-provisioning. > > Unless the idea is to use strict policing with dedicated queuing > on active and back paths or do something like RSVP IntServ also > on active and backup paths per customer - I really don't think > you can really guarantee much. And if you do that the cost would > likely grow really steep. > > So what is IMO the solution for assured/guaranteed global IP > transit: > > *A* get diversely routed dark fiber paths between your POPs > (can be unprotected) which btw today do not cost that much anymore > > *B* get diversely routed optical channels alsol between your > POPs (can be unprotected) > > *C* use N disjoined by design (single AS Internet providers > between your end-points) + proper SD-WAN with active SLA monitoring > > Clearly I am big supporter of *C* model for reasons discussed on > this and few other recent threads. > > I assume network slicing will try to get into be something > between A/B & C but it is bounded up front with the cost of the > two. > > Many thx, > > Robert. > > On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) > <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote: > > Hi Robert, > > IMO the two approaches are targeting at different use cases > and customers. > > The former (network slicing) is to provide the demanding > services with guaranteed performance in a converged network, > while the latter (switching between multiple paralleled > networks) provides the customer with the best performance > that is available among those candidates. To me the latter > is still some kind of best effort, and as Toerless said, it > depends on the diversity you can have in the multiple networks. > > And I agree with Stewart on “you always pay a price for > better than best effort.” > > Best regards, > > Jie > > *From:*rtgwg [mailto:rtgwg-bounces@ietf.org > <mailto:rtgwg-bounces@ietf.org>] *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, July 25, 2018 8:24 PM > *To:* Acee Lindem (acee) <acee@cisco.com > <mailto:acee@cisco.com>> > *Cc:* rtgwg@ietf.org <mailto:rtgwg@ietf.org> > > > *Subject:* Re: VPN security vs SD-WAN security > > True network slicing for IP networks means either waist of > resources or very strict multi-level queuing at each hop and > 100% ingress traffic policing. Yet while this has a chance > to work during normal operation at the time of even regular > failures this all pretty much melts like cheese on a good > sandwich. > > It is going to be very interesting to compare how single > complex sliced network compares for any end to end robust > transport from N normal simple IP backbones and end to end > SLA based millisecond switch over between one and another on > a per flow basis. Also let's note then while the former is > still to the best of my knowledge a draft the latter is > already deployed globally in 100s of networks. > > Best, > R. > > On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) > <acee@cisco.com <mailto:acee@cisco.com>> wrote: > > *From: *rtgwg <rtgwg-bounces@ietf.org > <mailto:rtgwg-bounces@ietf.org>> on behalf of Stewart > Bryant <stewart.bryant@gmail.com > <mailto:stewart.bryant@gmail.com>> > *Date: *Wednesday, July 25, 2018 at 5:55 AM > *To: *Robert Raszuk <robert@raszuk.net > <mailto:robert@raszuk.net>> > *Cc: *Routing WG <rtgwg@ietf.org <mailto:rtgwg@ietf.org>> > *Subject: *Re: VPN security vs SD-WAN security > > On 25/07/2018 10:40, Robert Raszuk wrote: > > /* Adjusting the subject ... */ > > Hello > > Stewart, > > You have made the below comment in the other thread > we are having: > > Indeed, I would have expected this to be on a > secure network of some sort either purely > private or some form of VPN. However, I am sure > I read in your text that you were > considering using the Public Internet much in > the way of SD-WAN. > > Would you mind as extensively as you can expand on > the above statement ? > > Specifically on what basis do you treat say L2VPN or > L3VPN of naked unencrypted packets often traveling > on the very same links as this "bad" Internet > traffic to be even slightly more secure then IPSEC > or DTLS encrypted SD-WAN carried data with endpoints > being terminated in private systems ? > > Thx, > > Robert > > > Robert, I think that you have to take it as read that an > air traffic control SoF system is encrypting its > packets. If it is not, then it is clearly not fit for > purpose. > > What concerns me is that an air traffic system is one of > the most, if not the most, high profile targets in civil > society. You get reminded of this each time you travel > to IETF. > > The thing about safety of flight traffic is that a > sustained and effective DDoS attack has global impact in > a way that few other such attacks have. > > A VPN system ought to sustain resistance to such an > attack better than the proposed system which treats the > SoF traffic the same as regular traffic. > > I guess you are making a case for your network slicing > work 😉 > > Acee > > > > - Stewart > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org <mailto:rtgwg@ietf.org> > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >
- Re: 答复: VPN security vs SD-WAN security Joel M. Halpern
- 答复: VPN security vs SD-WAN security Dongjie (Jimmy)
- VPN security vs SD-WAN security Robert Raszuk
- Re: VPN security vs SD-WAN security Stewart Bryant
- Re: VPN security vs SD-WAN security Robert Raszuk
- Re: VPN security vs SD-WAN security Acee Lindem (acee)
- Re: VPN security vs SD-WAN security Robert Raszuk
- Re: VPN security vs SD-WAN security Stewart Bryant
- AW: VPN security vs SD-WAN security Ruediger.Geib
- Re: VPN security vs SD-WAN security Stewart Bryant
- Re: VPN security vs SD-WAN security Toerless Eckert
- Re: VPN security vs SD-WAN security Robert Raszuk
- Re: VPN security vs SD-WAN security Toerless Eckert
- Re: VPN security vs SD-WAN security Greg Mirsky
- Re: VPN security vs SD-WAN security Robert Raszuk
- RE: VPN security vs SD-WAN security Dongjie (Jimmy)
- Re: VPN security vs SD-WAN security Robert Raszuk
- Re: VPN security vs SD-WAN security Greg Mirsky
- Re: VPN security vs SD-WAN security Toerless Eckert
- Re: VPN security vs SD-WAN security Robert Raszuk
- Re: VPN security vs SD-WAN security Stewart Bryant
- Re: VPN security vs SD-WAN security Stewart Bryant
- Re: VPN security vs SD-WAN security Stewart Bryant
- RE: VPN security vs SD-WAN security Dongjie (Jimmy)
- RE: VPN security vs SD-WAN security Dongjie (Jimmy)
- Re: VPN security vs SD-WAN security Joel M. Halpern
- Re: [Teas] 答复: VPN security vs SD-WAN security Stewart Bryant
- AW: [Teas] 答复: VPN security vs SD-WAN security Ruediger.Geib
- Re: [Teas] 答复: VPN security vs SD-WAN security Robert Raszuk
- Re: AW: [Teas] 答复: VPN security vs SD-WAN security Stewart Bryant
- Re: [Teas] 答复: VPN security vs SD-WAN security Stewart Bryant