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

"Naiming Shen (naiming)" <naiming@cisco.com> Fri, 05 October 2018 04:33 UTC

Return-Path: <naiming@cisco.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 78AC0130DD2; Thu, 4 Oct 2018 21:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uaEGKXTWK_w2; Thu, 4 Oct 2018 21:33:18 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978F21292F1; Thu, 4 Oct 2018 21:33:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2104; q=dns/txt; s=iport; t=1538713998; x=1539923598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4xnRPKKroOw9r38sa7SReSaBQyWgZLQRwqaq1CNlP1A=; b=c4FAOfNPIYxCRJ8yztunYEBk+Q7juD+hwdWQN7vCMRYBE1LRLh1UGUAO LLB5XT6uHb2osKQiLnn/lMGcubD8cJy3xCW4Vm2cCqljeZDxHO/6uWzLX A+kEMYhMszF5iJxWePPJXryRa5FC2qH5d92yK74dGiChpi5aRv/UWoDz3 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAACd6LZb/4sNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVYvgWUoCot/ji+WXoF6CwEBhGwChCU?= =?us-ascii?q?hNA0NAQMBAQIBAQJtKIU5AQEBAQIBOj8FCwIBCBgeEDIlAgQOBYMhgXoIpWS?= =?us-ascii?q?KEostF4IAgREBJx+CTIRYJoMygiYCnV0JApA/EQaBTIdwhjWJBYw4AhEUgSU?= =?us-ascii?q?dOIFVcBVlAYJBkFVvjD8BJQSBBIEfAQE?=
X-IronPort-AV: E=Sophos;i="5.54,342,1534809600"; d="scan'208";a="458639047"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2018 04:33:17 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w954XHiN020627 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Oct 2018 04:33:17 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 23:33:16 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 23:33:17 -0500
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: Barry Leiba <barryleiba@computer.org>
CC: "secdir@ietf.org" <secdir@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-isis-reverse-metric.all@ietf.org" <draft-ietf-isis-reverse-metric.all@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-isis-reverse-metric-13
Thread-Index: AQHUXAje+bWdrZY7u0Scu2oV4YzO7KUQZNCA
Date: Fri, 5 Oct 2018 04:33:17 +0000
Message-ID: <E82B9EDF-4ABC-4FF0-B0C3-587A44DAF282@cisco.com>
References: <153867461977.4554.2419440769241572592@ietfa.amsl.com>
In-Reply-To: <153867461977.4554.2419440769241572592@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.26.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <43912066BFEA9B43B3A7AB4ABEE8CB29@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/XjezoHjCEWI5mQj64OrJVkAisDo>
Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-reverse-metric-13
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: Fri, 05 Oct 2018 04:33:20 -0000

Hi Barry,

Thanks for the review and your suggestion makes sense. The original wording
is confusing. Also, as Tony has pointed out in the same thread, this sentence
was the original intention when start of the draft, but it has been extended for
other use cases described in section 1. How about this on top of your suggestions:

   For the use case in section 1.1, Node and Link Isolation, 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.

Best Regards,
- Naiming

> On Oct 4, 2018, at 10:36 AM, Barry Leiba <barryleiba@computer.org>; wrote:
> 
> 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.
>