Skip to main content

Telechat Review of draft-ietf-bfd-multipoint-18

Request Review of draft-ietf-bfd-multipoint
Requested revision No specific revision (document currently at 19)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2018-07-03
Requested 2018-06-19
Authors Dave Katz , David Ward , Santosh Pallagatti , Greg Mirsky
I-D last updated 2018-07-03
Completed reviews Rtgdir Last Call review of -16 by Michael Richardson (diff)
Tsvart Last Call review of -16 by Bob Briscoe (diff)
Genart Last Call review of -16 by Francis Dupont (diff)
Genart Telechat review of -18 by Francis Dupont (diff)
Tsvart Telechat review of -18 by Bob Briscoe (diff)
Assignment Reviewer Bob Briscoe
State Completed
Review review-ietf-bfd-multipoint-18-tsvart-telechat-briscoe-2018-07-03
Reviewed revision 18 (document currently at 19)
Result Ready w/issues
Completed 2018-07-03
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?
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

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

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

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/