Hi Eric, thank you for the review and your thoughtful comments. Please find my answers in-line tagged GIM>>.
Regards, Greg 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 > GIM>> Indeed, thank you. Accepted and applyed to the working version. > > > 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. > 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. > > > 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? > 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. > > > 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. > 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.
