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

[Eric Rescorla <[e-mail]>]

BTW, I am also not thrilled by the authentication design, but this doesn't
seem like the draft to fix it.

-Ekr


On Tue, Jul 3, 2018 at 4:58 PM, Eric Rescorla <[e-mail]> wrote:

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