Re: VPN security vs SD-WAN security

Stewart Bryant <stewart.bryant@gmail.com> Mon, 30 July 2018 10:22 UTC

Return-Path: <stewart.bryant@gmail.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 0F926130FFB for <rtgwg@ietfa.amsl.com>; Mon, 30 Jul 2018 03:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 63xy4dAB5sTT for <rtgwg@ietfa.amsl.com>; Mon, 30 Jul 2018 03:22:39 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1DE131001 for <rtgwg@ietf.org>; Mon, 30 Jul 2018 03:22:38 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id a3-v6so12246693wrt.2 for <rtgwg@ietf.org>; Mon, 30 Jul 2018 03:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=y/pm8z6+nI1wmNqNgLfnx8ONi7UQApc4oZMENxE1qf0=; b=t4mBPoDNfW2IeWYwZeUDwy5gf5i15oKpTXMaMRy5dYg6QkRIS6+VCV4f1wwN7Y3uNY 0+CJEElnxPgjzXLFec7Z3JsksEGraBg9MesJNoZJ7P1pre/MzXfUOAtzNV+Zta62/wI4 2Igj8K8BZQzLxvIfa6UfGUV4WWa6ndtKdGOrdmqGYVDz6xKuw8rTh1ytjUe7kWRyRyps 3nYOZQspLsKVSWZ2fVA7quc2Ny8LUzXU5RxADXa5pnFgMsJY/TU+54Pi0NoNbag9F5te f+DovqUerYtor3Jisb25N/Tx7C7CHUMQVbxWy4jt9wpxFe+pNP3YHR8WegmiHPgPGusz M0+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=y/pm8z6+nI1wmNqNgLfnx8ONi7UQApc4oZMENxE1qf0=; b=FkakJs44nJCV9CSHEi6jodrQ6scH97vVTaHAglQS0eqkgy33YPSZXHYV6LIFG/61zk g/B3Gijjg69F2vWXvVcMwUGD/3FZxKmZLapXnXh6xOn7+XsNi/hgsZ5cihpFF3xFd/5e r9FFNWveOFFNo8HuJ7aC19ZCB/1UiO2h096YVc4p8PePFJ3jwZmNo5X/q4I3nzgNxBis zlznbYJT7r8iCMlwwMQsjRdrTISLlwVnDf2YLX3fXlhRCDnGrOQywSUk7vXYtoezI2vx 8vF7lS2sS6/MCavRIlXkRbMFY+aKBa9WzAw8Jv0o5BTS6uwWfxixd94XnZ5vom2074s/ dCNA==
X-Gm-Message-State: AOUpUlE/LhXwkuLdbqPRIkMtLhpKJlHaS1CSsuOz6wE+ebrNAWw2bkIb ozLVuYkPRJa5F5JfN1k1OgDPjmwNtXk=
X-Google-Smtp-Source: AAOMgpePkFEbHH/Mg/5vjIBoedTn988KuPXJuy9q1CDnJNc9LcZat9kTeAH1rLGfAk+s3zBJK+SznA==
X-Received: by 2002:a5d:4e92:: with SMTP id e18-v6mr17800713wru.32.1532946157035; Mon, 30 Jul 2018 03:22:37 -0700 (PDT)
Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id w4-v6sm8587423wrl.46.2018.07.30.03.22.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 03:22:36 -0700 (PDT)
Subject: Re: VPN security vs SD-WAN security
To: Robert Raszuk <robert@raszuk.net>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: "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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <dc0d232a-8eaf-80a4-0878-1d82382c2490@gmail.com>
Date: Mon, 30 Jul 2018 11:22:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CA+b+ERmWDhXf0ia8mQ25=QZw-h_ipkAQnttsirQb3kOk_fhUVA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------21605A367C30782643F31848"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/rGcPljAVZAcrwO4MR7OqPydLrrg>
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 10:22:43 -0000


On 28/07/2018 14:02, Robert Raszuk 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.

We are not aiming for complexity

We are aiming to satisfy a need, and unfortunately with than comes a 
measure of complexity.

> 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.

Well that depends on how you do the over provisioning.

If I buy a dedicated network I pay the fully loaded costs.

The goal here is to provide dedicated resources, but sell them  to lower 
priority services
when they are unused. That  is more complex than simple best effort, but 
the high priority
service is a premium service.

The question for the SP is whether they can make money on selling the 
underusage, or
whether the commercial reality is that they need to build a number of 
networks.

>
> 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:

I am not yet sure how much of the market will be global as opposed to 
regional or sub-regional.

>
> *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.

C will clearly satisfy some parts of the market. There is no question 
about that.

>
> 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.

I think we need to build a network that operates as A/B for premium 
customers and provides C
for cost conscious customers.

- Stewart

>
> 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
> https://www.ietf.org/mailman/listinfo/rtgwg