答复: VPN security vs SD-WAN security

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 01 August 2018 15:22 UTC

Return-Path: <jie.dong@huawei.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 C8A0A130FE8; Wed, 1 Aug 2018 08:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 UcoWoZy_3_7A; Wed, 1 Aug 2018 08:22:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8C299130E37; Wed, 1 Aug 2018 08:22:14 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5D607C042B058; Wed, 1 Aug 2018 16:22:08 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 1 Aug 2018 16:22:09 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.206]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Wed, 1 Aug 2018 23:22:02 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "TEAS WG (teas@ietf.org)" <teas@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: =?utf-8?B?562U5aSNOiBWUE4gc2VjdXJpdHkgdnMgU0QtV0FOIHNlY3VyaXR5?=
Thread-Topic: VPN security vs SD-WAN security
Thread-Index: AQHUI/wIJ6g4duQ3X0aNCgBtJqhDKKSfLQmAgAAYIgCAABGYAIAE6NWA///YuoCAAG2tgIAAK5GAgAJ2aLCAADdCAIADlRmw
Date: Wed, 1 Aug 2018 15:22:01 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927A72B1EF7@NKGEML515-MBS.china.huawei.com>
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> <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com>
In-Reply-To: <89653c55-90e0-c52d-bdef-38b312b7feda@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.189.142]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/Ngpi55TlmzwZcnZiwQsPEVSmsA0>
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: Wed, 01 Aug 2018 15:22:24 -0000

This statement is based on the comparison between overlay VPNs and network slices. The resource here refers to various data plane resources that can be allocated to a particular slice (queues, buffer, etc.). Some level of resource isolation is necessary to ensure that service in one slice never interferes with service in another slice. 

May I know what are the requirements you've got? 

Best regards, 
Jie

> -----邮件原件-----
> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> 发送时间: 2018年7月30日 23:05
> 收件人: Dongjie (Jimmy) <jie.dong@huawei.com>;
> 抄送: TEAS WG (teas@ietf.org) <teas@ietf.org>;; rtgwg@ietf.org
> 主题: Re: VPN security vs SD-WAN security
> 
> 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
> >