Re: VPN security vs SD-WAN security

Stewart Bryant <stewart.bryant@gmail.com> Wed, 25 July 2018 13:01 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 99D80130DC8 for <rtgwg@ietfa.amsl.com>; Wed, 25 Jul 2018 06:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 prcPwV7S2b_b for <rtgwg@ietfa.amsl.com>; Wed, 25 Jul 2018 06:01:54 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 C78221292AD for <rtgwg@ietf.org>; Wed, 25 Jul 2018 06:01:53 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id l2-v6so14822395wme.1 for <rtgwg@ietf.org>; Wed, 25 Jul 2018 06:01:53 -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=ZyOVac5SQTeLRBy3HgIFiHAaWoM7ZY5h4HnFKDBwwY0=; b=vMEyshzMKwRS6NKQc2t9wccv/CyygtS3kKRAkUR6JNT8FOm00/Bb7sKflwwdIpFYjE vOQJAQqqVEpKrIws1txtulQAREw1K0HUCJiznTRKxzHDa5R75uZ9jCyRHMhwdnggFUlU tJS4WhkI5dkwfpJ2LJI70GlE4mNiI8xUQx2ZlfVSvgiyvbLv5nrW/rZN4KBsGrKdQg6z 6LL+MhmgYOW1VuxT5Dcd2SboFBjO232CL+jEWRhmoMmZDvugJ1oZMlnI/G/h4zuiYqH9 jlzrrOuvGZ2uQtrGEtMCWHn/lgisCh0R3N0oUUlQmRzsx/tIzSE7rRVznrwaCDyqN7M9 FnPQ==
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=ZyOVac5SQTeLRBy3HgIFiHAaWoM7ZY5h4HnFKDBwwY0=; b=eJR+FlGEa71k77rt+qqsQ4+d/aKSnejRsCIlyNSMRa5RIpxberlyTKc3NsT13DmAdd wkiHI/s9kJ2F2XC/TvTogrYdzxkQECEPvEtKmPlpmArIGjsC1lnBoOdHNwgHILuEyNUc Lf2GK47U8jLP8Eu3UGQxQP3y6nmVxpXC6In8HZc+L6puiGm1TJoZ8c/RR/YMzr+ZY4nw gE4VHPa87VR8aDpYT6qyWhXUHcK97dmcWkIlr9bXJ7dd9lmPA9bOavaZGtelO6Q5/j4i Q5kn/e7jKk/ofqktu8Qs09h+99JWq4oVJsF0l/WGrDfIQQYzucsg5AfYUuCVdn72bmaL BuRQ==
X-Gm-Message-State: AOUpUlF1Ycgp1ERI/YKJKLGopqsLUadkNZ21VwORdk7cUm6pC6DqFphK Af3y5q+TA1iQuWydtHJGwOWVy7xeN7M=
X-Google-Smtp-Source: AAOMgpdkA6v2w2Y3MKNp2jeer9NJltXY0aNYszFDUzzdZVv4DsliNttj5ZzgJS3FhBAhXOhqq/j83Q==
X-Received: by 2002:a1c:a8f:: with SMTP id 137-v6mr4475639wmk.119.1532523712070; Wed, 25 Jul 2018 06:01:52 -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 w9-v6sm21996569wrk.28.2018.07.25.06.01.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 06:01:51 -0700 (PDT)
Subject: Re: VPN security vs SD-WAN security
To: Robert Raszuk <robert@raszuk.net>, "Acee Lindem (acee)" <acee@cisco.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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <df64be17-7230-7dce-f4d1-2c69ce3cc0aa@gmail.com>
Date: Wed, 25 Jul 2018 14:01:49 +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+ERkqrr4Wr+Wy9q81SpyWi7H1s=z_RAvbc3Rbddvpgb7Xpg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------910C194DA76A1FB50C22E0D6"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/uFj4Hcsq2V1BGf-iUsgqn-vmyTw>
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, 25 Jul 2018 13:01:58 -0000


On 25/07/2018 13:24, Robert Raszuk wrote:
>
> 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.

A lot depends on the steps you take. For example we could take a leaf 
from the deterministic networks playbook and send duplicate packets on 
diverse paths, and reconcile them from time to
time to reign back the worst of the congestion.

At the end of the day, however you always pay a price for better than 
best effort.

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

If the simple approach delivers what the customer needs then clearly it 
should be deployed.

- Stewart

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