Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 07 November 2019 18:29 UTC

Return-Path: <padma.ietf@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 6D06C120961; Thu, 7 Nov 2019 10:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 a_HNIDvebtLD; Thu, 7 Nov 2019 10:29:33 -0800 (PST)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 43E2512095C; Thu, 7 Nov 2019 10:29:33 -0800 (PST)
Received: by mail-ua1-x92c.google.com with SMTP id c16so909397uan.0; Thu, 07 Nov 2019 10:29:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XQb67eVF8tlZpmE2U9QkCOdUQZBOjM7XzOXD88ISY4Q=; b=hh8hDl5PSuqeOLOWNdzdaksT2MM2gnkbCwC9ws4xRrRrBaB+7KNpLV5YV0hFrBZ3ly k56BrPfX4+t+lfVFhwx22AgXdcJcjLyqlyRbuKO92KyoBcJVlGamHfFo65ak+ZFgnpRH LXqHk2Y0lCeiVpjlJkCAPlKF3FXkov+9ZKYjZ/bWan07SwQxK/cp4iPUxFSvbhGsqKDV m8bpm21QRLXOJ6hKZx20K7T8fbb2wwF7UDht/j3ngglqZwj19ozRI8Ze4zrQp4FiiPio AbPaHWsmORqCMACqcM6tmrKCESx+MRy2VB2QSKJgIYlS+w41eMKIiVgdXNxfv0+6jLZ8 BMSA==
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=XQb67eVF8tlZpmE2U9QkCOdUQZBOjM7XzOXD88ISY4Q=; b=If1cwtHYDRDE0vBU9VI1ySTGbDyIyNlVIUvjEUcpmBokwpY7PhigKCmyWRnrEKPV0P vw8Nrp3N+ayYJYXuYmuGa56eBg3ZiuIGoUTfnGqbIKSyRgig+Ii9Rm5gcUV5zL4TrYG8 BjHQntitnbQNsn3rWf1nAnjpk9baRfk6vBOyjjyzrO1XXp/fBHYxwUIp92XXMGCRuo/b nAIIISs56Kri1y7o2nGrvLtUIyu61R5eWJbJkT+S++WZP2GSjH9FLr7Q/j6ltaE2XHgF 5E4wZUpvBYjse8E4irWQTzwSKJFUlBHP59bORlQS7g+Q1Odp40vAIvEI6wJ+K4r+9pJn rX7g==
X-Gm-Message-State: APjAAAVtKCfrHy/GQYJVdj5ljF1xR/ZTD2znsh8a/8MwZEwm4QdnNSE1 C+xBNuGsyZlmwxg9UqsbA24zyzlTHm68Af4f4+4=
X-Google-Smtp-Source: APXvYqyKJT0sEhR3z6hWw0h2N2Y5sJ+zJa4IroFwxi6j9m4FduKRUblYHWvINJvJGb58MNZsNGuFJqwSEa4x0IYt8aA=
X-Received: by 2002:ab0:230c:: with SMTP id a12mr3241228uao.83.1573151371206; Thu, 07 Nov 2019 10:29:31 -0800 (PST)
MIME-Version: 1.0
References: <157255845092.30400.10881471178799546764@ietfa.amsl.com> <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com> <20191103020302.GZ55993@kduck.mit.edu> <CAG-CQxouv9kguDb9Q-vVGRV603nnSSfNCLNLAsLGzTnRA8qMqg@mail.gmail.com> <CAMMESsycGJ9Xz_TYfHa673zxV+MM9kp-fHciYkgDJmvfRYtqeA@mail.gmail.com> <8FF8CF2F-8DF3-4E7C-AB48-DB1874962C82@cisco.com>
In-Reply-To: <8FF8CF2F-8DF3-4E7C-AB48-DB1874962C82@cisco.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Thu, 07 Nov 2019 10:29:19 -0800
Message-ID: <CAG-CQxrOWgLQFL0J2E3n2116ritbGG8MUf-3uWzs7Sg=uv4cFQ@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, Kyle Rose <krose@krose.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-ospf-ospfv2-hbit.all@ietf.org" <draft-ietf-ospf-ospfv2-hbit.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Padma Pillay-Esnault <padma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a8a3960596c5d83d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/duunyfhDvOAxptf-P_Lp6UQ1daQ>
Subject: Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10
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: Thu, 07 Nov 2019 18:29:36 -0000

Hi Alvaro, Acee

Ack, I will spin a new version with the review comments and will add the
new bullet.

Thanks everyone for your valuable feedback and comments!

Padma

On Thu, Nov 7, 2019 at 9:06 AM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Alvaro,
>
> On 11/7/19, 11:58 AM, "Alvaro Retana" <aretana.ietf@gmail.com> wrote:
>
>     On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:
>
>     Padma:
>
>     Hi!
>
>     See below...
>
>     > On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
>     > > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault
> wrote:
>     > > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
>     > > > wrote:
>     > > >
>     > > > > * I'm curious what happens if a router sets the H-bit when it
> is on the
>     > > > > only feasible transit path.
>     > > >
>     > > > PPE - The router with the H-bit set will not be "on the only
> feasible
>     > > > transit path" to other destinations. The H-bit functionality
> will exclude
>     > > > the host router from the path calculation in the SPF.
>     > >
>     > > I think you are talking about normal operation ("will not be on
> the only
>     > > feasible transit path") and Kyle is asking about misconfiguration
> or
>     > > similar edge cases.
>     >
>     > Thanks for this clarification.
>     > >
>     > > Having only read this email thread and not the document itself, I
> assume
>     > > that traffic will fail to flow if such a misconfiguration
> occurred, but it
>     > > would be good to confirm/refute that.
>     >
>     > Yes you are right ... for some cases.
>     >
>     > Assuming the router with the H-bit clear is on the only transit
> path. There
>     > are several cases see below.
>     >
>     > Normal case:
>     > The router has H-bit set
>     > (a) All routers in the area support the H-bit then the router is
> excluded in
>     > the SPF calculations and traffic will not flow.
>     > (b) At least one router in the area does not support H-bit then
> H-bit is not
>     > active in area. The traffic will flow as per normal OSPF operation.
>     >
>     > Misconfiguration case:
>     > The router has H-bit erroneously set (misconfig)
>     > (a) All routers in the areas support H-bit then the router is
> excluded in the
>     > SPF calculations and traffic will not flow.
>     > (b) At least one router in the area does not support H-bit then
> H-bit is not
>     > active in area. The traffic will flow as per normal OSPF operation.
>     >
>     > The Section 8 of the document has a discussion on this.
>
>     Yes, there is a discussion in §8, but I think we left out the case
>     where a rogue router, who is on the only transit path, may set the
>     H-bit (for no good/valid reason) and effectively partition the
>     network.  This case is indistinguishable from the normal case where
>     the operator (still on the only transit path) may consciously decide
>     to set the H-bit to perform maintenance, for example.
>
>     Please add a new bullet to cover this case.
>
> If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain
> (with or without cryptographic authentication), there are at least 3 or 4
> other ways in which it could partition the routing domain. This is just one
> more. However, I'm not opposed to adding the bullet as this is "what we do"
> during the security reviews.
>
> Thanks,
> Acee
>
>
>     Thanks!
>
>     Alvaro.
>
>
>