IETF Logo Mail Archive

Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 29 May 2018 17:06 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A9A12EBE6; Tue, 29 May 2018 10:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, 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 nPMDO1pRLSrI; Tue, 29 May 2018 10:06:11 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 19B8112EBE9; Tue, 29 May 2018 10:06:11 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id s201-v6so3689176ywg.8; Tue, 29 May 2018 10:06:11 -0700 (PDT)
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=yswP5Ht3y0wpwbHH9s5sL0fKz8whSukB5e64qDqW5UA=; b=mHFsgG+QwXFqxBkVnBSW1F4dBBjECw5s8Q4h6DFHGF/LTOUORHzmBasvWKnwx31jeB GCXxP6o8NGDYryOA0IbKBU+icIU+nsiBqvQUYnvdZPnGn8eC3Yrh9F+M+Pot3hde6GV7 z2bpcWyh1eQm/CYNfmwPYpiBOZYr42kH7V5DUBWPEgSlmD6MWKrTWWCTuEQdsblDA0bH /HqAD6kp/fOXQEQZbXBuah8gk5SQwgTZDHx68jh82so8d1bIMuuHOjpxCTLESxKIO2or +le7loF5rmB+P9wlRLO98upZVODwH9tZ4gqz+CY0cK/mbYkX1Z1rNC4F5ulinQHOTFZs V6yA==
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=yswP5Ht3y0wpwbHH9s5sL0fKz8whSukB5e64qDqW5UA=; b=m7xxOzAxx9O5hSHerWfOKLDkGyLdb/Qgo1LSDMqOfqmpI+dRZT1J//i+gykpnCy1tM 8NooxOrn1RVAQQOBAGJmOM6YlOLTKkPQdV6J22/ACF0WG+fOuBCrdsXIr1gVW56N9bdq h04ky770zlFc/OgVAFmh2lXE0R+S6sr3GFyxXB7xdQB1o2auo2OJ3sffFbVquuKuNmlj 33NgwrLX1sqBzQW149ZXkSiJaEGm3nDPXZMCJSeR+ATGijTW52n+6azmyk7x5gjrVXwo VQ2or6Ja6BlmHBcEVMbTew2YpaqZJrGga727AHBaWLPSedIomeG5+C01Knqsn5GP5q2V qKgA==
X-Gm-Message-State: ALKqPwcGaUSIvIrcsHOYSHsA50hDYheHQe2+vwapSSlw1XlqB6eN3OJK hSAyC9x+VIE+sh9AXK2viUgYpsVx+FemIMfeR/3DwA==
X-Google-Smtp-Source: AB8JxZoBh5qX7htCadBlRCHN3GNW8YgkOV8WW7IvYeFBWEEEi30uPD2i+GgAgDMNG2V2ambqrEhq+P9RMFgvrwwXrD8=
X-Received: by 2002:a0d:fc02:: with SMTP id m2-v6mr9904630ywf.52.1527613570076; Tue, 29 May 2018 10:06:10 -0700 (PDT)
MIME-Version: 1.0
References: <152694840016.8083.12174100605609215107@ietfa.amsl.com> <CA+RyBmVmsFxmiDTLLS5Jz+q_Fgb3O7QcsbMJwFUxbh-+9XxYWQ@mail.gmail.com> <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net>
In-Reply-To: <1afa9af2-9fce-1588-ca09-cd39f1122688@bobbriscoe.net>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 29 May 2018 12:05:57 -0500
Message-ID: <CAKKJt-dpbeyw=0LvY_btG0bavAV1eq3DKJbuGoSX4u5dHLe0vw@mail.gmail.com>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-bfd-multipoint-16
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Greg Mirsky <gregimirsky@gmail.com>, draft-ietf-bfd-multipoint.all@ietf.org, tsv-art@ietf.org, rtg-bfd@ietf.org, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000032d5aa056d5b40df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/WgLAfvypso9VZCTjz4rU8Ghz8c0>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 17:06:13 -0000

Mirja and I do read these reviews, but don't usually comment on them while
the authors and reviewers are still chatting. But, on one point ...

On Tue, May 29, 2018 at 5:23 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> Greg,
>
> On 26/05/18 20:49, Greg Mirsky wrote:
>

[snip]

> NEW TEXT:
>
>    Use of shared keys to authenticate BFD Control packet in multipoint
>    scenarios is limited because tail can spoof the head from the
>    viewpoint of the other tails.  Thus, if shared keys are used, all
>    tails MUST be trusted not to spoof the head.
>
> [BB]: Normally a MUST is applied to implementations. It would be rather
> odd to require users/operators to satisfy a spec requirement, particularly
> requiring them to trust each other. I think this should be written as an
> applicability statement not a normative requirement.
>

Bob is formally correct here, but it may be useful for me to say that I do
see "requirements" language used to provide guidance about security and
about operational considerations (as here).

If I understand Bob's suggestion to be something like

NEW

   Shared keys in multipath scenarios allow any tail to spoof
   the head from the viewpoint of any other tail. For this reason,
   using shared keys to authenticate BFD Control packets in multipoint
   scenarios is a significant security exposure unless all tails can
   be trusted not to spoof the head.

that would also work.

"Do the right thing", of course.

Spencer

v2.23.0 | Report a Bug | By Email