Security review of draft-ietf-grow-diverse-bgp-path-dist-07 Distribution of diverse BGP paths. Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document presents a mechanism for distributing redundant BGP paths based on the concept of parallel route reflector planes. It does not need any changes to the BGP protocol definition. The general notion is that different groups of route reflectors would be assigned find the "nth best route" where n varies from 1 to a small number. All n routes would be presented to devices connected to the route reflectors. This in turn would enable a multitude of benefits: quick routing restoration, load balancing, and churn reduction. The point of making this an IETF document is odd. Its fundamental message is "instead of using extensions to BGP for additional paths, you could use route reflectors configured for nth best path." And, as it turns out, Cisco makes such a product. The draft is sketchy on how route reflectors actually work, and the writing is a testament to the complexity and redundancy of English, a notoriously user unfriendly language. The text is very difficult to read, but eventually some non-ambiguous meaning emerges from each sentence, despite the irregular grammar and run-on sentences. Oddly enough, Cisco's documentation about its route reflectors is well-written. I would refer interested readers there. Still, we do not get to know if route reflectors put additional, proprietary, information on the wire, how a listener could inquire about their configuration, or what the stability and failure properties might be. All of this makes for difficulties in doing a security analysis. The document asserts that all security problems are subsumed by prior work in analyzing BGP security. This might be true, but BGP has a number of documented vulnerabilities, and the new paths might multiply them. Should BGP listeners trust the additional paths? Are opportunities for spoofing increased because listeners should expect more paths? What are the interactions between spoofed failures and switching to one of the diverse paths? Could route reflectors be tricked into permuting the path ordering so fast that paths never stabilize? I think that the security considerations should address potential problems in the context of the previous analyses of BGP security, if this is indeed a protocol document in the ordinary IETF sense. Perhaps it is not, maybe it is an infrastructure configuration guide or an argument against BGP add-paths extensions. I can't tell. Hilarie --------------------------- NB: "Hilarie Orman" is my actual name and not a pseudonym for any other person with similar knowledge or interests.