Re: VPN security vs SD-WAN security

Robert Raszuk <robert@raszuk.net> Sat, 28 July 2018 22:10 UTC

Return-Path: <rraszuk@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 728BC131138 for <rtgwg@ietfa.amsl.com>; Sat, 28 Jul 2018 15:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1W8V6XQ1unCo for <rtgwg@ietfa.amsl.com>; Sat, 28 Jul 2018 15:10:43 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 DBD44130E61 for <rtgwg@ietf.org>; Sat, 28 Jul 2018 15:10:42 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id p23-v6so5159911pgv.13 for <rtgwg@ietf.org>; Sat, 28 Jul 2018 15:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/+UT2HwHBsA5dsqRY1DoJUatmuXGl3uPgaCVmohQG2I=; b=li12/rZjso2xCVdSx9NbtavOvBIhQUbx03Vo3DU9HqkrItcEzUevngNss8XJ4K+Y3E lkmgABWvrlIo6O/hGwDZo4fC7Gr5YUv7WWZORevQlcwazsDDMqV5a1BGHjXQY1ISNmzr bc00zOFSfXBih/dRdL1BwzZYVSRuuEVM8wkDsxDJW1+Q9are3KF9uaBN5eIdXh7ZpaNk lLzuwiwN5mwrUAwLRudXeh1aZ/RQ/O6UsDqpBQIGifzqvA8kVULXr7LTxmz/gXrLPHoI c4ueW+P+vzIuzHE7TvuJT7nVKabngVzoEcm/PQBsEmEa4VssQKKdS8e2bob6o9dDi2iA eD4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/+UT2HwHBsA5dsqRY1DoJUatmuXGl3uPgaCVmohQG2I=; b=W+WqQC2w5cK5IM9UQVoVl0W4p9HX56JxTDZe6W44A3WEjsHWrmIXKiUmHvEacrZiTr SQrS/mRHtVExCF14B479t3Rh0abgO/4Qeqdkg/TdLRrUE4jrpl+RiXF0wXVeSU6BhtHN EHi/OTxAifglCo27x7n1w+b+j4kOQXipCKnp8ZhvHkZiN3T3fdmIfC36a8wa0W5mNK3B mU4zudbmRdOwecP0CGvWcABpJXq7nHrkXrfuAqfNodT/ox5oum4tx7wi133CWsisjf6U OOK2mwK3UFTIv8l9Mxq5X8MTBKZ7qiDL7+NiiuNDMfkKqCFtXticw6mDsFyBcG0Chbce U5hw==
X-Gm-Message-State: AOUpUlHXxp/KBBsqB+xzfFb/TeP8kBmPm2rAk/Azp6PE2dm02sngqJzK pz7ArZwrRclDyCsRc+yu587/5UYw8WAA4WngYqE=
X-Google-Smtp-Source: AAOMgpf/SOEaY8TvWHmQUXu75rki1LI09Z+IL4xfce7puJdBMEd7uCktEy93ptYfDGOQizLHWz/XQ1wOOdlVepvWYPg=
X-Received: by 2002:a62:4704:: with SMTP id u4-v6mr12035537pfa.76.1532815842136; Sat, 28 Jul 2018 15:10:42 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 2002:a17:90a:228e:0:0:0:0 with HTTP; Sat, 28 Jul 2018 15:10:41 -0700 (PDT)
In-Reply-To: <CA+RyBmX1Wj-aH+rWhQ1LLVrBkEq12Hz-DT1gYBF0TRx1ewaEzg@mail.gmail.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>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 29 Jul 2018 00:10:41 +0200
X-Google-Sender-Auth: RTkxulvlzSu2uFw_AQzm92ngjXY
Message-ID: <CA+b+ERmOFwgv+_8KBUx_sQnxXxgua53j5d8QEm=C9ppObkgwVQ@mail.gmail.com>
Subject: Re: VPN security vs SD-WAN security
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c6d58f0572167f66"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/749y4tAGddn1jfVztnQw1SpNsUc>
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: Sat, 28 Jul 2018 22:10:47 -0000

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>; 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>; 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>;
>> 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] *On Behalf Of *Robert
>>> Raszuk
>>> *Sent:* Wednesday, July 25, 2018 8:24 PM
>>> *To:* Acee Lindem (acee) <acee@cisco.com>;
>>> *Cc:* 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>;
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> *From: *rtgwg <rtgwg-bounces@ietf.org>; on behalf of Stewart Bryant <
>>> stewart.bryant@gmail.com>;
>>> *Date: *Wednesday, July 25, 2018 at 5:55 AM
>>> *To: *Robert Raszuk <robert@raszuk.net>;
>>> *Cc: *Routing WG <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
>>
>>
>