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

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 16 Jul 2012 13:30:53 -0600

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.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Jul 2012 00:29:58 +0200

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.

> quick routing restoration, load balancing, and churn reduction.

Correct.

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

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

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

I am not clear what spoofing risk you are referring to above.

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

---

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 19 Jul 2012 12:20:43 -0600

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 <[email-masked]>
>  MIME-Version: 1.0
>  To: Hilarie Orman <[email-masked]>
>  CC: [email-masked], [email-masked],
>	   [email-masked]
>  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

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

>  session between route reflector and it's client.

A nit --- "its".

>  case all clients would see all paths in the domain (assuming best 

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"?

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

>  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