Last Call Review of draft-ietf-grow-diverse-bgp-path-dist-
review-ietf-grow-diverse-bgp-path-dist-secdir-lc-orman-2012-07-19-00

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.