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

["Hilarie Orman" <[e-mail]>]

Thanks for explaining the GROW WG, I apologize for not reading its
charter before writing my review.  Other comments inline.

>  Date: Thu, 19 Jul 2012 00:29:58 +0200
>  From: Robert Raszuk <[e-mail]>
>  MIME-Version: 1.0
>  To: Hilarie Orman <[e-mail]>
>  CC: [e-mail], [e-mail],
>	   [e-mail]
>  Subject: Re: Security review of draft-ietf-grow-diverse-bgp-path-dist-07
>  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>  Content-Transfer-Encoding: 7bit

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

>From the draft, it was not apparent to me that RR communication was
specified in RFC4456.  I should have read the RFC, but shouldn't that
be a normative reference?  Also, as an editorial issue, it would help
to have some specific references to it in the descriptions of the
various routing plane scenarios.

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

A nit --- "its".

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

My only point is that the burden of this should be on the writers of
the drafts.  I gather that it is common practice to keep saying
"no additional security concerns" without looking at what the base
security concerns are.  Surely it is worth some "consideration"?

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

RFC4272 refers to several kinds of attacks that compromise the
authentication.  You might reference that in the security consideration
section.

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

All well and good.  I'd like to note that your text is much clearer
than anything in the draft; you might use it in the abstract.  You might
use that style (short, simple sentences) as a guide to revising the
draft.

Nonetheless, any new usage of a protocol may have security
implications, and it is worthwhile asking if known security issues
might lead to some new form of compromised functionality.

Hilarie