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

Derek Atkins <derek@ihtfp.com> Mon, 16 October 2017 15:02 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 3F2F0132811; Mon, 16 Oct 2017 08:02:18 -0700 (PDT)
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 AE62QLAV1f2O; Mon, 16 Oct 2017 08:02:11 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874B0133020; Mon, 16 Oct 2017 08:02:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CBFE2E2063; Mon, 16 Oct 2017 11:01:46 -0400 (EDT)
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 14561-01; Mon, 16 Oct 2017 11:01:42 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:2601:c6:ca00:1173:228:f8ff:fe73:20ee]) (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 87595E2054; Mon, 16 Oct 2017 11:01:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1508166102; bh=A9S56toJS9/g0rTaRHzQlEk67G8gxq0NLtbpk6bXT7I=; h=From:To:Cc:Subject:Date; b=e9OrqLz5V9amxkXCs2PiWoiS+nXQlJDcgQhD37lUQKtrp56KxyXXnPdIf2nVjT3ZL vh719YySSInvhGUl3ufBfYZklUwKbw0l+6L5YpUpUdZbLMCI8OurGQqwbevaZHxqEJ Vl8nPeWhpSa4BxEtAG0CthgSVDAEHumNx2vQ+FJs=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id v9GF1RIM026769; Mon, 16 Oct 2017 11:01:27 -0400
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
Cc: bier-chairs@ietf.org, israel@broadcom.com, aldrin.ietf@gmail.com, jefftant.ietf@gmail.com, andrew.dolganow@nokia.com, erosen@juniper.net, ice@cisco.com
Date: Mon, 16 Oct 2017 11:01:23 -0400
Message-ID: <sjmbml72l30.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/w8qqQtzlEi00uToUGT0N8XVuHkI>
Subject: [secdir] sec-dir review of draft-ietf-bier-mpls-encapsulation-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: Mon, 16 Oct 2017 15:02:18 -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