Re: [mpls] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 18 February 2019 00:08 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69996124D68; Sun, 17 Feb 2019 16:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
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 prBpk-qasiFN; Sun, 17 Feb 2019 16:08:42 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BFA1286D8; Sun, 17 Feb 2019 16:08:38 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1I08a48022598; Mon, 18 Feb 2019 00:08:36 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93E9B2203D; Mon, 18 Feb 2019 00:08:36 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 7D38C2203C; Mon, 18 Feb 2019 00:08:36 +0000 (GMT)
Received: from LAPTOPK7AS653V ([59.37.21.226]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1I08WRo007527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Feb 2019 00:08:34 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Paul Wouters' <paul@nohats.ca>, secdir@ietf.org
Cc: mpls@ietf.org, draft-ietf-mpls-sfc-encapsulation.all@ietf.org, ietf@ietf.org
References: <155044786665.4047.16182077722084116649@ietfa.amsl.com>
In-Reply-To: <155044786665.4047.16182077722084116649@ietfa.amsl.com>
Date: Mon, 18 Feb 2019 00:08:30 -0000
Organization: Old Dog Consulting
Message-ID: <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQF5B8APV/6zAJCJLq3MOjIgukEp0qacKyZg
Content-Language: en-gb
X-Originating-IP: 59.37.21.226
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24434.007
X-TM-AS-Result: No--8.253-10.0-31-10
X-imss-scan-details: No--8.253-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24434.007
X-TMASE-Result: 10--8.252600-10.000000
X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbKlXXrpOy3q0JPNIV6GF8mvOxDyJFXIPjuV0 5r5vXH4sv8qe8eDZGElC65348+oZgVdI3z1FMme36Zzj+kMRBrZR3sGN+j7mNMz1fqX318VP0u5 faGP8ztRV/mZWautsNz95I71UPSkOzsxad8fKloYF8rFt9xmDKTIaJpKzSfrsUCgEErrUGFwHn+ RaCrVBs4SaYXP5EhtmCOtlGomeL41qxgfCZhqtfAI0yP/uoH+DfS0Ip2eEHnwa2S8rkvtFcbDsz p3K5gqDjoczmuoPCq22oIhiAsKJgJS5x7cNmK0Fjy77szn26nqiQGmmwblmDsUufy2PLnHz
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/l6u_5G1DZS6hkPXyaKBohPcd04g>
Subject: Re: [mpls] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 00:08:44 -0000

Hi Paul,

Should we make the observation that, since the MPLS forwarding plane does not offer any security features, if security is required it must be provided by the SFC layer using some mechanisms inherent in the NSH. We could/should probably also observe that, as yet, no NSH security mechanisms have been defined.

Cheers,
Adrian

-----Original Message-----
From: ietf <ietf-bounces@ietf.org> On Behalf Of Paul Wouters
Sent: 17 February 2019 23:58
To: secdir@ietf.org
Cc: mpls@ietf.org; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; ietf@ietf.org
Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02

Reviewer: Paul Wouters
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready

While I'm not familiar with the Service Function Chaining (SFC) architecture
and the Network Service Header (NSH), the Security Considerations in this
document seem to be correct in pointing out that:

  This document simply
   defines one additional transport encapsulation.  The NSH was
   specially constructed to be agnostic to its transport encapsulation.
   As as result, in general this additional encapsulation is no more or
   less secure than carrying the NSH in any other encapsulation.