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
>