Re: [Ideas] [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Rex Buddenberg <buddenbergr@gmail.com> Thu, 11 May 2017 03:07 UTC

Return-Path: <buddenbergr@gmail.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFD012EB2E; Wed, 10 May 2017 20:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 IoKp1xeAfRdr; Wed, 10 May 2017 20:07:20 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 57FA6129C13; Wed, 10 May 2017 20:07:20 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id e193so6857445pfh.0; Wed, 10 May 2017 20:07:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=pr5lO2noj+1M/vTyFRDgZYFlYWrGTPcivOTFiMBB0xs=; b=MvG26I6Ow5Win1FvbMokeqD2VaJwXqlqgWCzxRJ51qlnAvCBAJj2F0/9Ip3WsT/Q4m 607feDTUvbopx9FtxYmCxS69bcPS5LXLKfHD2yEJuPMvFsJpATa8P31l3me9LI4FEK7S L9gygMpHU+cl6HgXlelmme0IGe7loTkIs9Kw65D0m8PqGNDeGfuLFLorUm6Fi+sldw32 kSm+Ekq740aX+MFY7R4eIYwN6Fbnb9coSkpqPd+oZhYrqNXayuZVRpYnjUOuTXpwUX8B qOBO2xJ+iVQeH6mpeiG4ucyiNptrUNiVAyMxDJPLO09xCuxi/yQWV+UW9rb0GbMC9W2g qpnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=pr5lO2noj+1M/vTyFRDgZYFlYWrGTPcivOTFiMBB0xs=; b=ctHz4CED1IYNXhWWs4Mk2wBF/q6ASEbA7/XM7yXJgIBJEyZ1mXsLLEHFaA0ea6JaDS C5nTG0BNPitqgVcca08ULSVbEBL6MHOiJCeVKhhkAS2RqOAV2NfhXh4kmEixh9BlsILr W2/oRW3VjGXSpEvRA7j+KRHNqEOvtCXoB8QkFZwq4J2rCodj5CjTiA1se38E+buuKF7U 3d0/DscBqxxkIhgF/kjAznqeVh1m/tiOCfT3npS24do5h6lsGJGPUc6IRVr6sIw2z+fb K8XyCfGYWP5DU1r/CnJO0Kd8VtViirCwBwZjAwm+Hv2zhxfBLPrQocfsKYHI34dDF3It hnhQ==
X-Gm-Message-State: AODbwcBEmus6mVPWMO1/6IM4eCR+mCKH1tA6UlGG9b//J5mn6n2ks6zF ld5oVV5ffjSXKg==
X-Received: by 10.99.127.26 with SMTP id a26mr9907261pgd.75.1494472039929; Wed, 10 May 2017 20:07:19 -0700 (PDT)
Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id s3sm454952pgn.29.2017.05.10.20.07.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 20:07:18 -0700 (PDT)
Message-ID: <1494472037.2357.312.camel@gmail.com>
From: Rex Buddenberg <buddenbergr@gmail.com>
To: Axel.Nennker@telekom.de, padma@huawei.com, 5gangip@ietf.org, ideas@ietf.org
Date: Wed, 10 May 2017 20:07:17 -0700
In-Reply-To: <5c50ba3a60224c38ae1db6aab688c7a3@HE101654.emea1.cds.t-internal.com>
References: <149376035152.21552.16267155218438524059.idtracker@ietfa.amsl.com> <CAC8QAcfXDAQsv1MsCu7RAtBF6LC7Y_v8zutz1hOYkcbbRKT_cw@mail.gmail.com> <340a9b7fbfe5408bbc2f6d56e839009f@HE105831.emea1.cds.t-internal.com> <CAKD1Yr3qd=KRTNbNMY8OEwMbV_t4-MQd3bQHKcbeuGhRb-dH5A@mail.gmail.com> <CAD6AjGQTBeMt6WjwE4FvOjMBBLv0EYysk+Dc3uXpmpux9FpVvg@mail.gmail.com> <CAC8QAcctwk19Q6MRxrZfXtQqbM85qNr3bAcP2XfDP02M28o+Ow@mail.gmail.com> <69756203DDDDE64E987BC4F70B71A26DAF12A32C@PALLENE.office.hd> <8f36755fd8c946478d723395754e8746@HE105831.emea1.cds.t-internal.com> <EC7A99B9A59C1B4695037EEB5036666B025737C4@SJCEML702-CHM.china.huawei.com> <5c50ba3a60224c38ae1db6aab688c7a3@HE101654.emea1.cds.t-internal.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/Yd-mRyI7lw0SSmiZGeCf7Qj7izM>
Subject: Re: [Ideas] [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2017 03:07:22 -0000

Herewith a suggested substitute for existing section 8.  Rationale
below:



<start>
8 Security considerations.

At the problem statement level of abstraction it's important to
identify the issues within scope.  And equally important to identify
those outside scope.  

5g represents infrastructure at layers 1, 2, and 3 of the ISO model.
Each of those layers contains security issues.  

But 5G does not include issues at layers 4 and up.  Therefore the
security issues here are outside scope:
  - authenticity, integrity and confidentiality of content data (aka
payload) is outside scope.  These are layer 6 and 7 issues, almost
always end-to-end (meaning beyond reach of 5g).  
  - connection integrity encompasses two issues: identity of the end
system that a subscriber is connecting to and reliable delivery of all
packets.  The former has been handled, with greater or lesser security
with DNS and the connection setup protocols in TCP (as an example of a
transport protocol).  Scope (see if I'm reading this right): these
requirements and features are not changed and they are outside 5g
scope. That said, the volatility of the infrastructure (rapid address
changes) makes the problem harder and cascading requirements may
emerge.
  - layer 3 security concerns include authenticity of infrastructure
nodes (is this router bogus or true?).  This is where the VPN language
belongs (Tom Herbert's comments from Friday, for example).  These are
within scope.
  - layer 2 security issues include a host of possibilities.  But frame
address integrity is clearly in scope, and suitable for
standardization.
  - layer 1 security issues are outside scope, largely because they are
1) single vendor issues and 2) volatile technological issues not
suitable for standardization.

<end>


Rationale.  First, security should not be bolted on after we thrash
everything else; needs to be built in.  The existing rather boilerplate
is not, IMHO, very appropriate to get this started.
   Secondly, even before considering requirements, some scoping (or, if
it suits you, a sorting model) is necessary to organize things.  In my
experience the ISO Reference Model is made to order.
   Pick at whether this or that is in scope or out, but we need to
thrash that early, like now, before we progress to requirements and
from there to proposed solutions.

Help?