Re: VPN security vs SD-WAN security

Stewart Bryant <stewart.bryant@gmail.com> Mon, 30 July 2018 10:29 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 B64E013101C for <rtgwg@ietfa.amsl.com>; Mon, 30 Jul 2018 03:29:51 -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 PHoFmnplVjeW for <rtgwg@ietfa.amsl.com>; Mon, 30 Jul 2018 03:29:48 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 63F70131010 for <rtgwg@ietf.org>; Mon, 30 Jul 2018 03:29:47 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id t25-v6so13106484wmi.3 for <rtgwg@ietf.org>; Mon, 30 Jul 2018 03:29:47 -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=vF4z+SIAaOYmG4ngR8dN6614Zr2CVaacgDsG656q3TU=; b=Xyf2SxZLqYREBtPEP9O1ly7lopzgQU4AGYmIP+9dZy4T/bvLdllWa3SqRUT3aLSb6X bHsCEKD9EHP8i84YDLciNK/N5+UlWewWut6MZGMsME62Ph9SdD7olfvqgmEA+DuEQ0yf e7mcqLxjgn8RQaeaRDM2N97tsen9XyoW9i1POfIvbwVelPDlfoJ9nGWwZ5zeMgK9szaW 7HULK7ZBPzs0HTM6MUOcOMwgvGiTJnM6AdLDSu8+tYrKhbFA+KJ91WZ4W7oMv5vs4I5w bWdbHflWT/vyad/ob9RR21MmFSPOOoh2JXo+iZSSTerZCYYTtCJ5nO5lISWeWNUMo4id 0Z9g==
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=vF4z+SIAaOYmG4ngR8dN6614Zr2CVaacgDsG656q3TU=; b=Djmo46dahYKmWHf6CiT2xSBEUCtzwZwc0aimBPFU9XMCEteG8wbUIi52XzKlzplAUA eY889LE9+e2K16cwji+q5vKX1G5w8Y80R423iQDseYUbMbwfR4LijPAKgGeXBBWPP8g2 rKNtqejay9Y+znwNL7fZ0rmhNMhuTB9HgqV3Eurg4rrlqH3YmRmhpB8sUFOkSF+TOW7B Z3c3Dovbt+Fa+jFm6p7jPZ6d6nNf5uDy+/hICGwlLmqa6lqQwZbH314LlzM44NAdBouG Qi+jGHJILDdSZzKn+row9etctjJ7gpdtof3FCHYscgI8VmyD534JV7cTvyGvP4jnfeSK nAXA==
X-Gm-Message-State: AOUpUlFgJSl+p9LU4QvajwUPOClSO3ZNnDxY+UaCmCL8cSdR4yUtJzqx 8zACbHYegKAUBLtzc0Ar4pOZ4ciON5E=
X-Google-Smtp-Source: AAOMgpff62DQTn9TWDEqqZjytXt4dM4sDOk1N6eGScIOu4r5JGMtmvdN9TAgnBX8hslpcpezW8o7wg==
X-Received: by 2002:a1c:5dd4:: with SMTP id r203-v6mr15083869wmb.29.1532946585527; Mon, 30 Jul 2018 03:29:45 -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 y191-v6sm12737441wmy.4.2018.07.30.03.29.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 03:29:44 -0700 (PDT)
Subject: Re: VPN security vs SD-WAN security
To: Greg Mirsky <gregimirsky@gmail.com>, Robert Raszuk <robert@raszuk.net>
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> <CA+RyBmX1Wj-aH+rWhQ1LLVrBkEq12Hz-DT1gYBF0TRx1ewaEzg@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <fe728ea1-5b93-243c-aac6-1a9e3757a532@gmail.com>
Date: Mon, 30 Jul 2018 11:29:42 +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+RyBmX1Wj-aH+rWhQ1LLVrBkEq12Hz-DT1gYBF0TRx1ewaEzg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------AE80E27D008F640EC3D1A628"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/HZLWZYUOYUhlFmB9kGb_46t6MDE>
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:29:52 -0000


On 28/07/2018 20:34, Greg Mirsky 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;
>
I agree up to here.


>   * "hard" slices would span within a single access and/or metro domain.
>
I agree that this is likely to be the majority case, but would not rule 
out a larger network
for some applications.

>   * Networking solutions likely will be coupled with architecture and
>     interfaces developed in Multi-access Edge Computing (MEC).
>
That is true, but may not be exclusively true.

- Stewart



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