Re: [secdir] Security review of draft-ietf-grow-diverse-bgp-path-dist-07

[Robert Raszuk <[e-mail]>]

Dear Hilarie,

Many thx for your comments and apologies for delayed reply. Let me 
attempt to clarify some of the points you raised hoping that they may 
shed some more light on the topic.

> 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.

Correct.

> 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.

I am perhaps missing the background of the above comment, but please 
keep in mind that this document is worked on in GROW WG. This working 
group is not tasked to define new protocol extensions, but to document 
operational solutions to existing problems. GROW WG also provides best 
common practices documentation. IMHO the more solutions GROW or any 
other working group in IETF defines which do not require new protocol 
extension the faster velocity of improvement to Internet and other IP 
based services can be accomplished.


> The draft is sketchy on how route reflectors actually work,

True. But this is very well documented in RFC4456 and this draft does 
not intend to update that RFC. In fact the draft does not changes any 
route reflection protocol assumptions.

> Still, we do not get to know if route reflectors put additional,
> proprietary, information on the wire,

They do not otherwise the specification would be a protocol extension 
which you correctly already observed it is not.

> how a listener could inquire about their configuration,

I am not sure what do you mean by that in the light of regular IBGP 
session between route reflector and it's client.

> or what the stability and failure properties might be.

The stability and failure property is identical to any other iBGP 
session today.

> 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.

While I understand your point it is extremely broad. One way of possible 
comparison would be to compare it with full mesh IBGP peering as in this 
case all clients would see all paths in the domain (assuming best 
external is enabled).

> Should BGP listeners trust the additional paths?

Yes. Remember those are intra-domain paths. Would BGP speaker trust any 
other iBGP peer ?

> 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 am not clear what spoofing risk you are referring to above.

> 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.

This document is to provide very easy solution for BGP speaker to 
receive more then best path. In most applications two paths is sufficient.

So the main objective of this document is to observe that by simply 
adding new session between RR and it's client RR can be instructed to 
send a 2nd best/backup path on such session.

Both above described functions are already very commonly available in 
number of BGP implementations. Authors just combine both to achieve easy 
deployable solution which does not require massive network wide upgrades 
which as I am sure we all realize may take years.

Best regards,
R.

> Hilarie
>
> ---------------------------
> NB: "Hilarie Orman" is my actual name and not a pseudonym for any
> other person with similar knowledge or interests.