[secdir] Secdir last call review of draft-ietf-isis-reverse-metric-13

Barry Leiba <barryleiba@computer.org> Thu, 04 October 2018 17:36 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE7F130DCF; Thu, 4 Oct 2018 10:36:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: <secdir@ietf.org>
Cc: lsr@ietf.org, ietf@ietf.org, draft-ietf-isis-reverse-metric.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.85.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153867461977.4554.2419440769241572592@ietfa.amsl.com>
Date: Thu, 04 Oct 2018 10:36:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/EtsjkuvMT3J_sgtToTr7pd9ylHc>
Subject: [secdir] Secdir last call review of draft-ietf-isis-reverse-metric-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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, 04 Oct 2018 17:37:00 -0000

Reviewer: Barry Leiba
Review result: Ready

This document is well written and seems ready to go.  The only security issue I
thought of as I read through it (attacking by spoofing a reverse metric) is
covered in the Security Considerations section.

I found one sentence to be slightly ambiguous, but only very slightly.  In
Section 3.5:

   A router MUST advertise a Reverse Metric TLV toward a neighbor only
   for the operational maintenance window period during which it wants a
   neighbor to temporarily update its IS-IS metric or Traffic
   Engineering parameters towards it.

It begins to look like it's saying that a router MUST advertise this under
certain conditions, and it took me a moment to get that it's actually
*limiting* when it should be advertised (the "MUST" applies to the "only"
clause).  If you think my suggested replacement reads well, you might use it;
if not, no problem:

   A router MUST limit the period during which it advertises a Reverse Metric
   TLV toward a neighbor only to the operational maintenance window period
   during which it wants that neighbor to temporarily update its IS-IS metric
   or Traffic Engineering parameters towards it.