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