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

"Andrew G. Malis" <agmalis@gmail.com> Thu, 28 February 2019 15:44 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6876130EC5; Thu, 28 Feb 2019 07:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 17ZmGblNJzlm; Thu, 28 Feb 2019 07:44:01 -0800 (PST)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 4BEF7130E27; Thu, 28 Feb 2019 07:44:01 -0800 (PST)
Received: by mail-ua1-x934.google.com with SMTP id d4so8172515uap.5; Thu, 28 Feb 2019 07:44:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uu/B/q2aEwr0Vy1lnT3nB3gfU8wevGGVCWKY3Z/pmxk=; b=nNa3YMNm/XlkeJ+94oBgRN/di2RrT4l4Vt7kp2zMnPjzx+Ya1EBC3iNLNIf2tQC20n H0sRFoeGguCwDJrdbO2Qaz1hE7Ndhh1EJ6PcveZhy+xQzRarbYJij4hVEneWffyILfye MGUcMIvh9Y+1GXueghtJERNaQBoBjEePzZsmz29Xq6UQey9PZ9EpXg2LcqCMVhLfm0wy KbnngUwqqlcey3EKjj7MFZQ+I3JCy7Rh/UmsocnDrXzBjoxHsVNI0VOhtLBWNA74BYPA n/TAD45IX+cNg3vks2wdbFfF4VnMJxJWE45W4v1POn7m8gLQlLJ7MVgBCBPPLWoyLvUy QnWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uu/B/q2aEwr0Vy1lnT3nB3gfU8wevGGVCWKY3Z/pmxk=; b=GnH9WM7mKFnIiKgfj4gEuXPnDYQVkuPA/qsTcAtFJ8D+hl0QxWJjCzX/bRgN+nV3Jf SJZQk/DxVt+vo/YGFF7/3JGa2W3+vhg88bj66ND+RbENObHNv4ub2bj7Bw2vhAOYkhbi K1JI3ndVWp5eLOicxL4MKH7A/f2r77588EUkDBY5fP0skCQ0IJ7eJdt6FMTJLaqkbjr+ v5RYslcJu/98URLVrh7QfjIuBXh/iivxpBvQ/P2W5GV5yCiT3L5Dsk0Pz4svbRCxZWwJ B1iZ+bu5tm6CuO1JzDzr9ddruVZCynoWxXlr7irncB/ER3O5zq7Z4aMeZgxp7q5Z7SkJ 1hDA==
X-Gm-Message-State: AHQUAuYrsFGEIv2TAKsJZHmqrRfFWr+5JLpsCU2cImkYojXvTKVDXrlh 8tbPgcdTWP8OsQtmS7q6sRlyFj6wcWTL2v6Ssun2PQHcs30=
X-Google-Smtp-Source: AHgI3IY840oUo+bJcP64rwSC4XrQmRFyXaztMnNkgza/JB4Il6ZvZKZK+b2FXnZWeCAGefQpyGXRiqtXQaTAB6q+cB4=
X-Received: by 2002:a67:db89:: with SMTP id f9mr5169374vsk.143.1551368640143; Thu, 28 Feb 2019 07:44:00 -0800 (PST)
MIME-Version: 1.0
References: <155044786665.4047.16182077722084116649@ietfa.amsl.com> <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk>
In-Reply-To: <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Thu, 28 Feb 2019 10:43:48 -0500
Message-ID: <CAA=duU1mf=Dk3NSurkusmfknq8p5K_vqx-LvwovG2WQMiPySTA@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Paul Wouters <paul@nohats.ca>, secdir@ietf.org, mpls <mpls@ietf.org>, draft-ietf-mpls-sfc-encapsulation.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b626b60582f628b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/81k-blazSYdyuteW-J2eRRzOgtw>
Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 15:44:04 -0000

Paul,

Thanks for your review!

Adrian,

I don't think I agree with your statement that the MPLS forwarding plane
doesn't offer any security features. As I discuss in the last paragraph in
the security considerations in the draft, it's resistant to some classes of
attacks such as injecting unexpected packets unless the attacker was an
insider or had specific inside knowledge, such as valid SFF labels that
would be accepted by a receiving node. But then, it's difficult to defend
against any sort of attack on a router by an insider, starting with having
access to the physical box and the CLI.

While there are no specific NSH security mechanisms, I don't think this
draft is the place to have that discussion, as it's an MPLS WG draft. The
draft does say that this encapsulation is no more or less secure than
carrying the NSH in any other encapsulation. It's up to the SFC WG to
figure out NSH security elsewhere.

Cheers,
Andy



On Sun, Feb 17, 2019 at 7:08 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

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