Re: VPN security vs SD-WAN security

Robert Raszuk <robert@raszuk.net> Wed, 25 July 2018 19:49 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 1BBC8130E22 for <rtgwg@ietfa.amsl.com>; Wed, 25 Jul 2018 12:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, SPF_PASS=-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 L-0PW5NmWL-x for <rtgwg@ietfa.amsl.com>; Wed, 25 Jul 2018 12:49:42 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 5A5D312E039 for <rtgwg@ietf.org>; Wed, 25 Jul 2018 12:49:42 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id k21-v6so2040499pff.11 for <rtgwg@ietf.org>; Wed, 25 Jul 2018 12:49: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=y6JkSceH6BsdEpeLs447dziZDyAyKU8kFW4RbHg7720=; b=MafOd4qwo3gjBjGReSszoFIqnAykflqwrFQLzRbNscSgUgeKMYWLBW++uE6nPxxMdx j6pFwDILBuaAXshg+vrGVDGxXTLFPUjbYi9qqvOeFcRTyreZP7e3GE5wbsZEen48HUta lLgPxpXquipB2JjwYUgfzg3TJAdU7xi95qF42FivaoHopC/7xuuOuUynNtIId9ACNOKW I3aiys6NTNhVS4B58+0ytlWSzGrskgb/ppZXdgSlxz8W+XagYiVBPjXOPh3xVuyXgPCl xqW60Ow2GWbXbrLZ4b+3lb46nNmoTeYYJoSJ057fzVAPYIclFBJ7qJcj6J/5m0jidl5x muuQ==
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=y6JkSceH6BsdEpeLs447dziZDyAyKU8kFW4RbHg7720=; b=PBLHAQO+o46w2ku/mHc84H+ZPFB4VpR5YzL1XXwvAAVrd7+qbGtphKNOn/KRicI+SG 8JO8aLJbLYMWBUHxHvWyDAcHzvky3j+FrK317+lhIhba6Nf6lmDHZY5WKPf7cuVtFpd4 fJwuRgm4r5+zTBLcvTvQ7RnZboRI6ZjLCcLXCeQ3fJwWYJsEjEOX1NkmvmeA54aUAJuM 7J6c+4eYax9p2Cj1uoXIyPLlRfwGBuz9zP23EU1Tr/H94tiXyH8zS3949EupO1ZGs4Cb 9CbAF/Pw3Hq+ZIU7wzhUGwc3vOTP4kjjF5A8wUgm1JQCNKXREUnFZoT0LUGQ48ksf4jC qa7Q==
X-Gm-Message-State: AOUpUlGdGC/hdJNznLMBrBxJfUIhnvb5aEH6P+rkuyOaCo6V3quiiJgA sB3lLpdx4MKvuIGty0DFqzYtGnfVRw5hgWZKxuK4tG9j
X-Google-Smtp-Source: AAOMgpfu9zOQKNSYySamy62aac40WYcD0T8060DLZ5tf1iE2v01jPp9vb1jlbwrFUUfXb0sUueQFrDg9MbhS0Q70GbE=
X-Received: by 2002:a62:e0d5:: with SMTP id d82-v6mr23487755pfm.59.1532548181578; Wed, 25 Jul 2018 12:49:41 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 2002:a17:90a:228e:0:0:0:0 with HTTP; Wed, 25 Jul 2018 12:49:40 -0700 (PDT)
In-Reply-To: <CA+RyBmWn7kAVSE2aRiqePz8sOHtf=9XDFpMho_xbeGcLR+X1OA@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> <44F647C7-BF88-469D-82C6-1509A57EAD31@gmail.com> <20180725155008.4yg4jkud6hsfdboh@faui48f.informatik.uni-erlangen.de> <CA+b+ERmLpWdzJT+qhgVVni9gruGyY33pkUa0nCrxh8aAU9cN+A@mail.gmail.com> <CA+RyBmWn7kAVSE2aRiqePz8sOHtf=9XDFpMho_xbeGcLR+X1OA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 25 Jul 2018 21:49:40 +0200
X-Google-Sender-Auth: led42Eqczl2XnAZ6MHcwSmmd0Yk
Message-ID: <CA+b+ERmcEb6+ujqOm=bB+H1mhPxy61oA_QpOhUfEq+76pcWUVw@mail.gmail.com>
Subject: Re: VPN security vs SD-WAN security
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Toerless Eckert <tte@cs.fau.de>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f6d7840571d82de5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/PwBEt_LIRxxDx1bhvJO__fU7lo8>
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 19:49:44 -0000

> different technologies, e.g., packet replication and duplicate
elimination, could be used.

As long as the packet split and reassemble (dup removal) is in my own hands
and control and not something I would need to trust service provider to do
for me for x time the normal IP transport cost - it will be fine.

On Wed, Jul 25, 2018 at 9:31 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:

> Hi Robert,
> great discussion, thank you.
> I'd expect that the level of resource isolation and protection, guaranteed
> or assured performance metrics will be applied as constraints and,
> potentially, limit the use of the common infrastructure in favor of TE'd
> and more controlled networks. For these premium services, as
> Stewart suggested, different technologies, e.g., packet replication and
> duplicate elimination, could be used.
>
> Regards,
> Greg
>
> On Wed, Jul 25, 2018 at 9:34 AM, Robert Raszuk <robert@raszuk.net>; wrote:
>
>> Agreed.
>>
>> And very honestly I am not sure if accomplishing high service robustness
>> is best done via complicating any particular network or rather freedom to
>> dynamically choose your end to end path among many cadidate and globally
>> independent transports.
>>
>> That was what I meant by *wise* use of Internet in the former message.
>>
>> Vendor locking is as bad as operator's lock.
>>
>> Cheers,
>> R.
>>
>> On Wed, Jul 25, 2018, 17:50 Toerless Eckert <tte@cs.fau.de>; wrote:
>>
>>> IMHO the main issue is that virtualization of networks and
>>> any expectation of resource guarantees in the face of attacks opens
>>> up a whole new slew of issues (attacks against shared infra)
>>> which is today outside the scope of IETF focus because it does
>>> not relate to our outdated definition of what qualifies for
>>> IETF standardization.
>>>
>>> If we want to help create secure virtualized network services we
>>> need to have a lot more opinions about box internal behaviors
>>> even to the extent of defining standards about them. Vendors
>>> will suck at this if left unsupervised.
>>>
>>>
>>> On Wed, Jul 25, 2018 at 01:32:25PM +0100, Stewart Bryant wrote:
>>> > Robert,
>>> >
>>> > Perhaps the right thing here is for you to propose text to Fred on how
>>> to make sure his traffic is safe from the types of state-sponsored attack
>>> that an air traffic system might need to withstand?
>>> >
>>> > Stewart
>>> >
>>> > > On 25 Jul 2018, at 13:24, Robert Raszuk <robert@raszuk.net>; 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.
>>> > >
>>> > > 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
>>>
>>>
>>> --
>>> ---
>>> tte@cs.fau.de
>>>
>>
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>>
>