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

From: Bob Briscoe <[email-masked]>
Date: Tue, 03 Jul 2018 14:12:27 -0700

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?

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.

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).

==New Nits==

1. Intro:
s/enables a tail monitor availability/
 /enables a tail to monitor availability/

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jul 2018 16:42:40 -0700

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

Regards,
Greg

> 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.

> 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.

> 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.

>  /enables a tail to monitor availability/
GIM>> Thank you. Should it become, including suggestion by Eric:

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Jul 2018 21:56:22 -0500

> On Tue, Jul 3, 2018 at 2:12 PM, Bob Briscoe <[email-masked]> wrote:
[...]
>          This variable MUST be initialized to the appropriate type when

Would this necessitate adding an Updates: 7880 header?

-Benjamin

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