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 <[email protected]> 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. > > >
