Re: [Stackevo-discuss] [5gangip] [gaia] 5G: It's the Network, Stupid

AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> Thu, 17 December 2015 19:39 UTC

Return-Path: <Peter.AshwoodSmith@huawei.com>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478911A889C; Thu, 17 Dec 2015 11:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level:
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=unavailable
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 YaeJfwOithnF; Thu, 17 Dec 2015 11:39:52 -0800 (PST)
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8676D1A889A; Thu, 17 Dec 2015 11:39:48 -0800 (PST)
Received: from 172.24.1.49 (EHLO szxeml431-hub.china.huawei.com) ([172.24.1.49]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYF72763; Fri, 18 Dec 2015 03:39:18 +0800 (CST)
Received: from szxeml559-mbs.china.huawei.com ([169.254.2.89]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 03:39:04 +0800
From: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
To: Nishanth Sastry <nishanth.sastry@kcl.ac.uk>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Thread-Topic: [5gangip] [gaia] 5G: It's the Network, Stupid
Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAALUVSAAAn56QAAHza00A==
Date: Thu, 17 Dec 2015 19:39:03 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF366BB@szxeml559-mbs.china.huawei.com>
References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <CAEeTej+pHehyX7+qteogQcAkCcJKYhZoQKStuXGmAzWRj1_rXQ@mail.gmail.com> <F8355406-91C7-4B96-995C-1AD9D7997DC1@kcl.ac.uk>
In-Reply-To: <F8355406-91C7-4B96-995C-1AD9D7997DC1@kcl.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.60.67]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56730F68.0023, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.89, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 00848a8b86cf5b6a52bf185d28311680
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/n5y4_uuluvxO37JohPiVXoAQhXA>
X-Mailman-Approved-At: Thu, 17 Dec 2015 11:44:54 -0800
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, gaia <gaia@irtf.org>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>, "marnew@iab.org" <marnew@iab.org>, "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [Stackevo-discuss] [5gangip] [gaia] 5G: It's the Network, Stupid
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 19:39:54 -0000

That is only true if stat mux transport is not used for backhaul/midhaul. If OTN or DWDM is used for isolation of slices then of course no interference is possible however with a packet mix there is the possibility of DOS or at the least Denial of QOS (DOQ?) but in general you are right that properly sliced there should be minimal security impacts between slices.

Peter

-----Original Message-----
From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Nishanth Sastry
Sent: Thursday, December 17, 2015 7:43 AM
To: Jon Crowcroft
Cc: icnrg@irtf.org; gaia; stackevo-discuss@iab.org; Dirk Kutscher; marnew@iab.org; 5gangip@ietf.org; dtn-interest@irtf.org
Subject: Re: [5gangip] [gaia] 5G: It's the Network, Stupid

E2E security in 5G can be addressed through network slicing, another concept which seems to be included in many 5G proposals. If each application has its own slice, it can screw up but wont be able to affect other applications. Within each slice, E2E security can be enforced in an application specific manner. Even better would be if we can make each flow be its own slice. This may seem to be overly heavyweight, but is along the lines of what Bromium  is trying to do for desktops, isolating processes and data from each other using
"microvisors": http://www.bromium.com/why-bromium/how-we-do-it.html We just need to do it for networks :)

nishanth
—
CD-GAIN: http://bit.ly/cd-gain
S4S: http://www.space4sharingstudy.org/
REACH: http://www.eu-india.net

5G Norma: https://5g-ppp.eu/5g-norma
VirtuWind: https://5g-ppp.eu/virtuwind/

On 17 Dec 2015, at 7:56, Jon Crowcroft wrote:

> Great article...one thing about the 4g..5g evolution is increasing
> cooperation in forwarding and relaying signal, bits, packets (shared 
> cell
> tower/base station/antennae across provider). So direct,mesh,adhoc 
> stop
> just being edge notions, but are all first class part of the 
> architecture
> ("don't fear the edge"). There is huge tension between this trend, and 
> e2e
> security....I have not seen anyone address how to resolve that 
> tension...
> On 16 Dec 2015 6:42 pm, "Dirk Kutscher" <Dirk.Kutscher@neclab.eu> 
> wrote:
>
>> [apologies for cross-posting]
>>
>>
>>
>> Hi,
>>
>>
>>
>> I have written up a few thoughts on current discussions around 5G and
>> network evolution. I might publish this as paper later, but wanted to 
>> get
>> it out early and ask for comments – so would be grateful for any 
>> feedback.
>> It’s not very polished and slightly long, but hopefully 
>> understandable
>> enough. Take it as a “position paper” for now.
>>
>>
>>
>> Abstract:
>>
>> Current 5G network discussion are often focusing on providing more
>> comprehensive and integrated orchestration and management functions 
>> in
>> order to improve “end-to-end” managebility and programmability, 
>> derived
>> from NGMN and similar requirements. While these are important 
>> challenges,
>> this memo takes the perspective that in order to arrive at a more 
>> powerful
>> network, it is important to understand the pain points and the 
>> reasons for
>> certain design choices of today’s networks. Understanding the 
>> drivers for
>> traffic management systems, middleboxes, CDNs and other 
>> application-layer
>> overlays should be taken as a basis for analyzing 5G uses cases and 
>> their
>> requirements. In this memo, I am making the point that many of 
>> today’s
>> business needs and the ambitious 5G use cases do call for a more 
>> powerful
>> data forwarding plane, taking ICN as an example. Features of such a
>> forwarding plane would include better support for heterogeneous 
>> networks
>> (access networks and whole network deployments), multi-path 
>> communication,
>> in-network storage and implementation of operator policies. This 
>> would help
>> to avoid overlay silos and finally simplify network management.
>>
>>
>>
>> http://dirk-kutscher.info/posts/5g-its-the-network-stupid/
>>
>>
>>
>> Thanks,
>>
>> Dirk
>>
>>
>>
>> _______________________________________________
>> gaia mailing list
>> gaia@irtf.org
>> https://www.irtf.org/mailman/listinfo/gaia
>>
>>
> _______________________________________________
> gaia mailing list
> gaia@irtf.org
> https://www.irtf.org/mailman/listinfo/gaia

_______________________________________________
5gangip mailing list
5gangip@ietf.org
https://www.ietf.org/mailman/listinfo/5gangip