[secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-09

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Tue, 04 July 2017 13:40 UTC

Return-Path: <rifaat.ietf@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 2A1B3132090; Tue, 4 Jul 2017 06:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 pE5yWMKzdmi6; Tue, 4 Jul 2017 06:40:07 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 8824113208F; Tue, 4 Jul 2017 06:40:07 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id r126so111240415vkg.0; Tue, 04 Jul 2017 06:40:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jjj9rVd9d0QbYxj6ZJaO9w7Tica8MLdUJa/R1ml6SmA=; b=uNiZy/8fQCQIeVpxvqBQdMlVZVMnlJ8PwxtdWAewoTYGw+8hakQFOH5XQqDXuubT8F /qhHEJAqGr9tUzCP9U32dLVpdwsYzB+9osyO/5FUVW/Zo4wVwQvM76TCpIeL3pMc3dPV cIQvifXTdkX5zaSjayR6j5VYxqieMpcusbX71f6ftGMOT768h9nCwetB6grzBLFKolHo DO+ElthLOoQSUvyNyoR0JERPV1xQfrhsBUvV0UpsA+KQ4M8p2ukWXL8cablarmNZ3hCN lcmWhzxeH2sY07cPnpsIJ1qg2QGN31/z7oYon9psMT7+ULZY5KN6tNpZW2ssBOGZHe61 JlgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jjj9rVd9d0QbYxj6ZJaO9w7Tica8MLdUJa/R1ml6SmA=; b=VWmiaa/Tk8N5/ZIJAAB21pW4PkCmQY/duf5mSd0bonCo1sYY1LQu4VRzglpDde/3hR 25HDZwuUNg5optUQTcObau7vkrI8zPkLv6OmZaJPUV9qWnRYeAdsL3paOVCn7R8bUsMX e3fVFduJpfTbV0LNQX2IhrwUSspohQ8ohmF06GrkpgsQ8T3X7OtyUnqvtQ2YHfQun16H lJdlEU0WukUsvCwvAW/Q61GsVldsagFmlG2ryg8QT2YKAt1TEknZqnqxxTNkwZ9RljJ1 HMLpfcQvYoC97DVsyi6IRCux7EIqnjX3n2weVbDYpGuiYJkvVmgjVc759zASHOjATutx QJ3g==
X-Gm-Message-State: AKS2vOywmfdWoy24kemv7tmimV94TYFNrZbVPQc3CiViu+75DXa61dBY zTpbwFvSVrQzTaJ9NYw0MhFjn3evNYTPdxY=
X-Received: by 10.31.218.196 with SMTP id r187mr21387371vkg.96.1499175146044; Tue, 04 Jul 2017 06:32:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.76.29 with HTTP; Tue, 4 Jul 2017 06:32:25 -0700 (PDT)
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Tue, 04 Jul 2017 09:32:25 -0400
Message-ID: <CAGL6epL36m-j_UHLZ7zK+rTVNdOOTpnww1Q0i5zowxLp=+V1RA@mail.gmail.com>
To: draft-ietf-teas-gmpls-lsp-fastreroute.all@ietf.org, secdir@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07c56209431305537deaa2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/onc4ndimt5yWxScT70eiDf38YAM>
Subject: [secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-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: Tue, 04 Jul 2017 13:40:17 -0000

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.

Summary: Ready with Nits


I did not have enough background on MLPS and GMPLS and their related RFCs,
so I had to do some reading to get some familiarity with this subject to be
able to provide some reasonable review of this document.

This document builds on an existing mechanism, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels" defined in RFC4090, which defines a mechanism to
establish a backup tunnels for local LSP tunnels. One limitation of the
existing mechanism is that in some situations it might assign different
uni-directional bypass tunnels for the forward and reverse directions.

This document extends the mechanism defined in RFC4090, by adding a new
BYPASS_ASSIGNMENT subobject to the existing RECORD_ROUTE Object (RRO) used
in PATH and RESV requests, to allow the establishment of a bi-directional
bypass tunnel.

The security of the existing mechanism still applies with the new mechanism,
and the security section discusses the implications of the new subobject and
the new error associated with that, which seems reasonable.

The document also points to an MPLS/GMPLS Security Framework (RFC5920)
document that has an extensive discussion of the security of MPLS/GMPLS
network in general that also applies to this document.


Nits

Because the document extends RFC4090, it should add "Updates: 4090" at the
top of the document.

Regards,
 Rifaat