[secdir] sec-dir review of draft-ietf-bier-mvpn-09

Derek Atkins <derek@ihtfp.com> Thu, 22 February 2018 21:12 UTC

Return-Path: <derek@ihtfp.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 AEE5F12DA27; Thu, 22 Feb 2018 13:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 419XJ6a42Xst; Thu, 22 Feb 2018 13:12:30 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A068212DA24; Thu, 22 Feb 2018 13:12:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 13B33E207F; Thu, 22 Feb 2018 16:12:29 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24559-07; Thu, 22 Feb 2018 16:12:28 -0500 (EST)
Received: from securerf.ihtfp.org (IHTFP-DHCP-250.IHTFP.ORG [192.168.248.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 09D89E2053; Thu, 22 Feb 2018 16:12:28 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1519333948; bh=A9S56toJS9/g0rTaRHzQlEk67G8gxq0NLtbpk6bXT7I=; h=From:To:Cc:Subject:Date; b=eXTPs5sOjLU2P62hdUi+bA9sd6Bai/SrP7Nn5Nk/QPWpzYtTs3TrVcKHAN2e8iLMt EA3oheUYSyp+hQqbVtjxbOt1pzNOBT4FhwMn2mfIfudYuRfjxtmBa51bPztJOsv16k OjN4kmscP0DNPGGXH/FCUHgnUJj0YJ3fBFv3s6vY=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id w1MLCROA007440; Thu, 22 Feb 2018 16:12:27 -0500
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
Cc: bier-chairs@ietf.org, prz@juniper.net, andrew.dolganow@nokia.com, aldrin.ietf@gmail.com, masivaku@cisco.com, erosen@juniper.net
Date: Thu, 22 Feb 2018 16:12:27 -0500
Message-ID: <sjm371sk9tw.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9cavo5yrz6FcViciVcdW_t7FdGg>
Subject: [secdir] sec-dir review of draft-ietf-bier-mvpn-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Feb 2018 21:12:33 -0000

Hi,

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 with the intent of improving
security requirements and considerations in IETF drafts.  Comments
not addressed in last call may be included in AD reviews during the
IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

Summary:

Ready to publish.

Details:

Obviously the security of this solution is based on the full trust of
the complete end-to-end BIER network.  There is no cryptography to
ensure that a packet is not manipulated enroute which would change the
bit-fields.  The good news is that it's probably hard to inject a
BIER-headed packet into the network from the outside (once it hits an
external router it would be re-encapsulated).  On the other hand there
is nothing to stop a bad-actor internal router from creating a bogus
BIER header or modifying an existing BIER header.  I suspect this is
already handled in the MPLS and IGP Security Considerations, but I
wanted to ensure that the IESG was aware of this restriction (which is
not explicitly stated here).

-derek
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant