[Tsv-art] Tsvart telechat review of draft-ietf-bfd-multipoint-18

[Bob Briscoe <[e-mail]>]

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/