I have reviewed draft-ietf-idr-bgp-bestpath-selection-criteria-13 as part of the Security Directorate's early review effort, at the request of the IDR chairs. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat them like any other early review comments. Summary The document adds two conditions to the Route Resolvability Condition of RFC 4271 Section 9.1.2.1: the next hop SHOULD be resolved in the forwarding database of the data plane chosen by policy, and a "path availability" check using a data-plane liveness mechanism MAY be applied. The mechanism is simple and the motivation in the appendix is convincing. The security considerations, however, do not describe the security change the document actually makes. Route selection now depends on two new inputs, a data-plane choice that a peer may signal and the output of an OAM liveness mechanism, and neither input is discussed as something an attacker can influence. I have one issue with the current Section 5 and four requests for text. The Routing Directorate (Donald Eastlake) and Operations Directorate (Venkata Chintha) early reviews cover much of the routing and operational ground. I note where a point below overlaps theirs. Issue 1. Section 5 overstates its benefit and omits the real change Section 5 says the draft "doesn't impose any additional security constraints" and "can help with mitigating one particular type of routing attack in which a BGP speaker could receive routes with an arbitrary next-hop. If the next-hop is not reachable, then those routes/paths would not get selected." As the Routing Directorate review notes, RFC 4271 already excludes routes whose next hop cannot be resolved, and Section 3 never says that a failed check makes a route unresolvable. I would remove the mitigation claim. What the document does change is that a data-plane signal now drives a control-plane decision, and that decision can change what the router advertises to its neighbors. The rest of this review is about that. Request 1. Liveness as an attack surface (Section 3, item 2, and Section 5) Item 2 lets a liveness mechanism such as BFD or LSP ping decide whether a path is a bestpath candidate. Anyone who can make a liveness session fail, by dropping or delaying its packets, or by spoofing it where it is unauthenticated, can now make the router stop using a path, and withdraw or replace it in what the router advertises. Because the check is made per next hop, one disrupted session disqualifies every route that uses that next hop under a policy that enables the check. That can turn a local data-plane disruption into a routing change that BGP carries beyond the point of attack, and repeating it can produce route flapping with the usual BGP propagation cost. In the dual-homed case in Section 8.1.1, an attacker who can disrupt the session to one next hop but not the other can steer traffic onto the other, so this is a traffic-steering primitive, not only denial of service. The reverse also holds. A spoofed liveness signal can keep a broken path selected, which is the blackhole this document sets out to prevent. RFC 5880 Section 9 says the same of BFD in general: an attack can falsely declare a path down or falsely declare it up. RFC 8029 Section 5 lists spoofing, replaying and tampering with LSP Ping messages as ways to obscure the state of the data plane. The Routing Directorate review raised the denial-of-service case and this reverse case, and both directorate reviews raise the non-malicious version, an OAM false negative that withdraws a good path. The security considerations should state all of these cases, and say that a liveness mechanism used for this purpose needs the protections its own specification provides. For BFD across multiple hops, that is the Authentication Section (RFC 5880, Section 6.7), which RFC 5880 Section 9 says SHOULD be used there and RFC 5883 strongly encourages. RFC 5884 applies the same guidance to BFD for MPLS LSPs when replies are routed. Even with authentication, an on-path attacker can drop the liveness packets or pass them while dropping the traffic (RFC 5880, Section 9). The document should also say whether a route stays eligible while the liveness result is unavailable, for example at startup, since failing open and failing closed have opposite security consequences. The check should also be dampened or a hold-down timer so that a flapping liveness result does not become a flapping route. The Routing Directorate review asks the operational version of both questions. Whether dampening belongs in this document or in the liveness mechanism is the working group's call, but the dependency should be named. Request 2. Trust in the signaled data plane (Section 3, item 1) Item 1 says the data plane is chosen by policy and that "a dynamic signaling such as BGP encapsulation SAFI (or tunnel encap attribute) [RFC5512] may be used to convey the data plane protocol chosen by the policy." As the Routing Directorate review notes, RFC 5512 is obsoleted by RFC 9012. The security point is that the attribute arrives from a BGP peer. To the extent that a received attribute drives the choice of data plane, a peer, or an attacker who can inject or modify that attribute, influences which forwarding database the resolvability check consults, and therefore whether the route is selected. The document should say that a received data-plane choice is acted on only as local policy permits. RFC 4272 notes that a legitimate peer can distribute unauthorized routing information, and RFC 9012 confines the Tunnel Encapsulation attribute to a well-defined scope, with filtering on by default for external BGP sessions (Section 11), and notes that it adds a new means of diverting traffic (Section 15). The document should inherit those limits, update the reference, and reconcile item 1 with the resolvability rule in RFC 9012 Section 7.1, which the Routing Directorate review also raises. Request 3. Inconsistent views and loops (Section 4) Section 4 says the amendments are not expected to "negatively impact BGP convergence, barring any implementation specifics." When routers in the same domain apply different resolvability criteria, or observe different liveness results for the same next hop, they can select different bestpaths for the same prefix, which in a hop-by-hop IP data plane can produce a forwarding loop. The Routing Directorate review made this point about correctness. From the security side, an attacker who can degrade liveness toward some routers and not others can induce that state deliberately. The convergence sentence should be removed or supported. Both the Routing and Operations Directorate reviews also challenge it. The loop case should appear in the security considerations, with a recommendation that the criteria be applied consistently within a routing domain and a note that consistent configuration still does not guarantee consistent liveness results. Request 4. References Section 5 should cite RFC 4272 (BGP security vulnerabilities analysis), as the Routing Directorate review also suggests, and RFC 7454 (BGP operations and security), as the baseline it is building on, so that a reader can see which of the known BGP attacks this document changes and which it leaves alone. Nits Section 3 item 2 requires the same data plane as "the one selected by the previous criterion (#1)", but item 1 is a SHOULD. Say which data plane applies when item 1 is not performed. The Routing Directorate review asks the same question. I agree with the Routing Directorate review's editorial points, including the typos, the PE2 that should be PE1 in Section 8.1.2, the 2019 dates and legal boilerplate, and the RFC 8174 boilerplate. I have not repeated the Routing Directorate's structural comments (moving the problem statement into the body, explicit OLD/NEW text against RFC 4271, applicability across address families) or the call in both reviews for an operational considerations section. I agree with both, and the security text above will be easier to write once the mechanism is stated precisely.