Eric Rescorla's No Objection on draft-ietf-bfd-multipoint-18: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-bfd-multipoint-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3589


It's not entirely clear to me what the relationship is between this
document and RFC5880. Can you clarify?

How does this handle duplicate/reordered packets? If I am reading RFC
5880 correctly, you only get that if you have authentication?

COMMENTS
S 1.
>   
>      As multipoint transmissions are inherently unidirectional, this
>      mechanism purports only to verify this unidirectional connectivity.
>      Although this seems in conflict with the "Bidirectional" in BFD, the
>      protocol is capable of supporting this use case.  Use of BFD in
>      Demand mode enables a tail monitor availability of a multipoint path

enables a tail monitor -> allows a tail to monitor?

If not, I am confused


S 5.13.1.
>         If the Detect Mult field is zero, the packet MUST be discarded.
>   
>         If the My Discriminator field is zero, the packet MUST be
>         discarded.
>   
>         Demultiplex the packet to a session according to Section 5.13.2

This is a bit confusing because it applies to the section here and not
in 5880.


S 5.13.2.
>               PointToPoint MAY be created, or the packet MAY be discarded.
>               This choice MAY be controlled by a local policy and is
>               outside the scope of this specification.
>   
>            If the State field is Init and bfd.SessionType is not
>            PointToPoint, the packet MUST be discarded.

Is this material just duplicative of 5880?


S 6.
>      from the viewpoint of any other tail.  For this reason, using shared
>      keys to authenticate BFD Control packets in multipoint scenarios is a
>      significant security exposure unless all tails can be trusted not to
>      spoof the head.  Otherwise, asymmetric message authentication would
>      be needed, e.g., protocols that use Timed Efficient Stream Loss-
>      Tolerant Authentication (TESLA) as described in [RFC4082].

As Ben's review implies, digital signatures would be an appropriate
thing to use here.