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

From: Eric Rescorla <[email-masked]>
Date: Tue, 03 Jul 2018 16:58:42 -0700

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jul 2018 17:04:02 -0700

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

-Ekr

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jul 2018 15:35:36 -0700

Hi Eric,
thank you for the review and your thoughtful comments. Please find my
answers in-line tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
GIM>> Indeed, thank you. Accepted and applyed to the working version.

> This is a bit confusing because it applies to the section here and not
GIM>> Section 5.13.1 replaces the entire section 6.8.6 of RFC 5880 and,
thus, some text from RFC 5880 that is common to p2p BFD and mp BFD is in
the section.

> Is this material just duplicative of 5880?
GIM>> This text does apply to p2p BFD that is defined in RFC 5880. Section
5.13.2 is the replacement of the part of section 6.8.6 of RFC 5880 and,
thus, processing for all BFD session types documented.

> As Ben's review implies, digital signatures would be an appropriate
GIM>> In response to Ben's question regarding applicability of assymetric
message authentication I've proposed the following addition to the Security
Considerations section:
   Applicability of the assymetric message authentication to BFD for
   multipoint networks is ouside the scope of this specification and is
   for further study.