Re: Tsvart telechat review of draft-ietf-bfd-multipoint-18

Greg Mirsky <gregimirsky@gmail.com> Thu, 05 July 2018 23:42 UTC

Return-Path: <gregimirsky@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 C4C52130E21; Thu, 5 Jul 2018 16:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_PASS=-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 FaXsVgDhZDZ4; Thu, 5 Jul 2018 16:42:43 -0700 (PDT)
Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 1EE41130E13; Thu, 5 Jul 2018 16:42:43 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id c11-v6so7853404lja.4; Thu, 05 Jul 2018 16:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i7Kcbw/lkAtd7ayDWsdYfhIIoTCZtMU5sP0xzxTyhcM=; b=Dsj084uAOz9bLszW72mZ4EL/6yBru1flPMijFJ1iQXmrsGdKuQK3CcMo/By8dFmxqd fqF93ibr0Zz6+VXSYHerT72AHo8u8z/20Xhfahx3F6b2rGXyXJjhZ9MnMgGui87c9+yq kIwFaj/uJiJBISP6wOHZwvjvcON/xuWh7+UN+YfYXHrHcjptaHeFX8ytwxMEIxLjNlM/ keuTRzYzgRViUTcwPErO9f3/emctrRZrC+hrTb4T4OCBlWGG7yYrAsv8BKffmLf1Nb3m rOcxoIj8JzRJ3wVU1XSoDCn/2dtzSjBc/C+r+njWHutpsri//8Yl0ofeq8S+yGKggNPc XEag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i7Kcbw/lkAtd7ayDWsdYfhIIoTCZtMU5sP0xzxTyhcM=; b=mwzOtcdgTI6pN+bSKcu+aaRVq4A76TPg0+djIWeFhBVBuwamLdviuIIxn8nj3IzTj1 W3WKvmFo1JeJ7h9JakLByNa3mKGF59MPuhIVzI3AczKLoK0oBq+Kau4wIo2N7ZYVGpKd +MO232+Kd50T1CTD889IH9BJhjIiiEDaz/A7jQdi/XLDfR7SNWnWYiRRsFCMU65shRtV kHE9VVbYzVhvYGn/8v8cbxlj+sfTxO7hR6tzNZIs7JefZG/zLfoMspBTwU3JxCam6z4b Mn5NWPywFdOAiqURuKknh0rQoPxQ/IJYRYsRymSIBE7wKzQyeVh/Hlk5zkexSofRr3RF XWaA==
X-Gm-Message-State: APt69E3Ky2iOiFed5Z54vAU6naLNQHjEFx6Mn/xGcpi05qGXnsHioovZ 9IXYbNsAX0pn0oVRSdNqN4jLxamO6YdxazTv3jVF0w==
X-Google-Smtp-Source: AAOMgpevllT6X0qEHn/VS7oUYz79QKYplFnuI8WowUdFe4mm0z8E3OU4SIrVfRpV20McYsz3XNvLK6grZKkOy5RPK7g=
X-Received: by 2002:a2e:590e:: with SMTP id n14-v6mr5038167ljb.128.1530834161225; Thu, 05 Jul 2018 16:42:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:709:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 16:42:40 -0700 (PDT)
In-Reply-To: <153065234730.4917.5465043909084726358@ietfa.amsl.com>
References: <153065234730.4917.5465043909084726358@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 05 Jul 2018 16:42:40 -0700
Message-ID: <CA+RyBmXOwAj9ciAFa7ecRRHE2XCG-S_t5uRiWhHZ6ywoNZytrw@mail.gmail.com>
Subject: Re: Tsvart telechat review of draft-ietf-bfd-multipoint-18
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tsv-art@ietf.org, draft-ietf-bfd-multipoint.all@ietf.org, rtg-bfd@ietf.org, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000063d66b0570491ab7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ul6SF4d5bCOGn8QnmvCzohlGKUc>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 23:42:48 -0000

Hi Bob,
thank you for the continued discussion and the most specific comments.
Please find my answers in-line tagged GIM>>.

Regards,
Greg

On Tue, Jul 3, 2018 at 2:12 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:

> Reviewer: Bob Briscoe
> Review result: Ready with Issues
>
> This is a TSV ART review, but it only brings up one transport issue
> (interval
> adaptation). It is an update to my review of draft-16 in the light of
> changes
> intended to address my comments (and those of others).
>
> The headings of my original review are reused, to identify whether each
> issue
> is resolved. One of the 2 security issues highlighted in my original review
> remains undocumented.
>
> 1/ Mandatory return path?
> [RESOLVED]: The intro to the draft now gives an example of a case where
> multipoint BFD with no return path would be useful.
>
> 2/ Mechanism for verifying connectivity, or not?
> [UNRESOLVED]
> Two sentences in the introduction still seems to contradict each other
> (neither
> have been changed): "   As multipoint transmissions are inherently
> unidirectional, this mechanism purports only to verify this unidirectional
> connectivity." "   Term "connectivity" in this document is not being used
> in
> the context of connectivity verification in transport network but as an
> alternative to "continuity", i.e. existence of a forwarding path between
> the
> sender and the receiver."
>
> How can this mechanism verify connectivity, but not be used in the context
> of
> connectivity verification in the transport network?
>
> The email response from Greg Mirsky (coauthor) was:
> >>This draft defines the base specification for multipoint BFD. In order
> for
> multipoint BFD to support the transport-like connectivity verification we
> need
> to do work similar to described in RFC 6428.
>
> I think this may miss the point of my comment, which was simply that the
> introduction contradicts itself on this point. Or am I missing something?
>
GIM>> Terms "connectivity" and "continuity" are neing used interchangably
throughout our documents. For example, RFC 5880 13 times refers to "path
connectivity" and "connectivity verification" and no mention of continuity.
Would s/connectivity/continuity/ throughout the document and removal of the
reference to transport network environment address your concern? Though
misuse of the terminology (and I wholeheartedly agree that is very
confusing) will continue.

>
> 3/ Use case
> [RESOLVED] see #1/
>
> 4/ Interval adaptation
> [RESOLVED - non-solution though]
> My original comment: "Text is needed to describe why it is not an issue
> for the
> head to be unaware whether it needs to adapt its transmit interval." This
> was
> addressed by adding the following: (paraphrasing) "if a tail can't cope
> with
> the head's Tx Interval, it can always leave the session." Specifically,
>                            If the value of Desired Min TX Interval in the
>                            BFD Control packet received by MultipointTail
> is too
>                            high (that determination may change in time
> based on
>                            the current environment) it must be handled by
> the
>                            implementation and may be controlled by local
>                            policy, e.g., close the MultipointTail session.
>
> Not communicating solves any problem in communications, but it's never a
> useful
> solution.
>
> 5/ Inability to authenticate the sender with symmetric keys
> [RESOLVED, but a nit remains...]
> The 2 paras about this issue are in a section on their own headed
> "Assumptions"
> but they no longer contain any assumptions. They would be better placed
> within
> Security Considerations (immediately below their current position).
>
> 6/ Source address spoofing
> [NOT RESOLVED]
> I think Greg (on behalf of the authors) hasn't grocked my point. In
> response to
> my point, Greg repeated the procedure in Section 5.13.2 used to demux a BFD
> control packet. It uses the source address and other info in the packet.
> However, it cannot know if the source address is spoofed. So I'll repeat my
> comment:
>
> A 3-way handshake makes a protocol robust against simple source address
> spoofing. Without a 3WHS, surely the spec. needs to highlight this
> vulnerability or discuss ways to address it or why it is not an issue.
>
GIM>> I believe that Jeff Haas provided details on multicast implementations
<https://www.ietf.org/mail-archive/web/rtg-bfd/current/msg03944.html> in
explanation why this specification does not introduce any new threats.

>
> 7/ Scope
> [ALL RESOLVED]
>
> 8/ Incremental deployment
> [UNRESOLVED] The text remains unchanged.
> There seems to be a misunderstanding about this comment. Carlos Pignataro
> has
> explained on the list, but people seem to keep misunderstanding him too.
> The
> text in 5.4.1 simply needs to clarify that implementations that do not
> support
> the multipoint-BFD specification are not required to use the PointToPoint
> value
> of bfd.SessionType  (such non-multipoint implementations are
> point-to-point but
> they don't have to say they are).
>
GIM>>  I disagree. PointToPoint is the new value for the bfd.SessionType
variable added in this specification with scope of bfd.SessionType being
RFC 5880 and mpBFD. bfd.SessionType variable was added in RFC 7880 with
scope of S-BFD only, excluding RFC 5880. If this specification updates RFC
7880 in regard to the scope of bfd.SessionType, then the statement in
section 6.1 RFC 7880:
   The bfd.SessionType variable MUST be initialized to the appropriate
   type when an S-BFD session is created.
is replaced by the one from section 5.4.1 of this specification:
         This variable MUST be initialized to the appropriate type when
         the session is created.


> ==New Nits==
>
> 1. Intro:
> s/enables a tail monitor availability/
>  /enables a tail to monitor availability/
>
GIM>> Thank you. Should it become, including suggestion by Eric:

... allows a tail to monitor the availability ...