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

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

Return-Path: <barryleiba@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C99130DC7; Thu, 4 Oct 2018 21:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 Cu45oGDzGRnK; Thu, 4 Oct 2018 21:36:47 -0700 (PDT)
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 18248130DCD; Thu, 4 Oct 2018 21:36:47 -0700 (PDT)
Received: by mail-io1-f43.google.com with SMTP id p4-v6so9724086iom.3; Thu, 04 Oct 2018 21:36:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ru6h1yE13yry3gJgaakJ8DtT3HTIiJbZm1zX1OwwF/U=; b=IuW3/jWt9g7VusxtSS1RZVxPE64EUPes5Q2ZdN3kQfYKhJiQ7I1RfOBDuE/rvxlbap TRSW+mtY6GQcM+TRa7GvmYIPpF1W/byw0pQXbHLIFNjW30qoi1hC7Ad2BFFJiagZOSAn Sy3UV3LD9/k2Ur+VOffUeu74YqFMhH365VuxGwS1Ww+RDm1uARnOfk/pMjPsC+bu2iye 7A0BpD4ve0FM2yxQUoD1jFn1cwKpVf2K7w0jIriD6qu1RQBBWeeGYXMBwP3XqnyhtsP4 T7FhcnahTOU48WOyQeFIqnZfOXc254ZWrLcK6zEHNnUW+bR2GvolO7KSXssb35ijekXk eXOw==
X-Gm-Message-State: ABuFfojA0x1pygxlFLTqbMhl8lP5mlRolrxDx5FF1a9EVVVaigkYHQSM ITJtBSLwPUqft+wsrlNR5TJmz1CS/MPBVYihDzY=
X-Google-Smtp-Source: ACcGV63gGIcr1zCjNXondIQ2mKenVoY5iBi+wP7nzfURYi4/+zsl6w/+gQAoyLvN0Xvxwsi2/PCCrgnc3mdGs/6pdw8=
X-Received: by 2002:a6b:6209:: with SMTP id f9-v6mr6630458iog.11.1538714206137; Thu, 04 Oct 2018 21:36:46 -0700 (PDT)
MIME-Version: 1.0
References: <153867461977.4554.2419440769241572592@ietfa.amsl.com> <E82B9EDF-4ABC-4FF0-B0C3-587A44DAF282@cisco.com>
In-Reply-To: <E82B9EDF-4ABC-4FF0-B0C3-587A44DAF282@cisco.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 5 Oct 2018 00:36:35 -0400
Message-ID: <CALaySJLH9O888YJ6cRe7LnaPip4kvBatU=a8+4fdV_WnBF-LHQ@mail.gmail.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
Cc: "draft-ietf-isis-reverse-metric.all@ietf.org" <draft-ietf-isis-reverse-metric.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aaf8fe057773d14a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/2nKCZMaIkt7mn8GDjbfmVrJWSEU>
Subject: Re: [Lsr] Secdir last call review of draft-ietf-isis-reverse-metric-13
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 04:36:49 -0000

Perfect; thanks.

Barry

On Fri, Oct 5, 2018 at 12:33 AM Naiming Shen (naiming) <naiming@cisco.com>;
wrote:

>
> 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.
> >
>
> --
Barry
--
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/