Subject: Security of BGP Re: Status of the 16-bit AS Number space

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 May 2009 09:25:07 -0400

Looks to me that we have an obscurity based 'security' system going on there.

The security of the system depends on various net-ops using their
skill and judgment to discriminate between purported updates. Such
systems tend to fail catastrophically once there is an incentive to
attack them.

At RSA there was a presentation on security holes in IPSEC and SSH. In
the IPSEC case the response 'from the IETF' (i.e. from a well known
individual speaking on his own behalf) was that the security issues
with using IPSEC without authentication were well known and that this
is not new. To which the reply came, well why did you continue to make
support for encryption only mandatory?

I think we will have the exact same set of events here. The security
problems in BGP are well known but nothing will be done to actually
fix the running code until there is a disaster. At which point some
Kaminsky type will put together an attack that is dismissed by the PR
flacks as 'not new', which will hopefully then result in the question
'well why didn't you fix it then'.

Novelty is an important trick for the academy. We have to remember
that it is not an important objective for engineers. The original
objective of the IETF was research. Now we have an entirely different
mission - sustaining a network the is critical infrastructure. Yet our
design processes are unchanged and we still have no concept of
maintenance.

There is unfortunately a naive view that we can solve the BGP security
issue by simply sprinkling some IPSEC pixie dust on it. I think that
view is based on a profound misunderstanding of what is possible with
a packet layer security protocol. Key agreement and crypto-packaging
are trivial problems that can be solved by a moderately competent grad
student. The hard part is the problem that IPSEC never solved, how to
establish the trust context. And once you look at that problem you
soon realize that IPSEC is the wrong tool entirely as the routing
problem requires you to take an accountability approach which in turn
requires you to work at the message level.

It would be nice to think that we will deal with this problem in some
other way than waiting for it to break. But we wont.

On Wed, May 6, 2009 at 5:37 PM, john heasley <[email-masked]> wrote:
> Wed, May 06, 2009 at 08:49:42AM +0200, Mans Nilsson:
>> >     Is the 15ms moritorium excessive?
>>
>> No. Perhaps even short. A month should be appropriate. Those who update
>> their filters based on RIR data with some support system assistance do
>> so daily/weekly. Those who have manually updated filters are losing
>> this battle already, and those who accept any from any are utterly lost
>> (but in this particular instance in ignorant bliss).
>
> That is the "disservice" that I had in mind.
>
> ASNs I returned nearly 10 years ago have not been reassigned.  Surely
> sufficient is far fewer than 10 years.  16 bit exhaustion is magnified by
> policy.
>
>> Only clue helps these cases; no moratorium will ever save them.
>>
>> --
>>
>> _______________________________________________
>> Ietf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 12 May 2009 12:44:31 -0400

On Tue, 12 May 2009 09:25:07 -0400

> Looks to me that we have an obscurity based 'security' system going

Everyone in the business understands that there is a routing security
problem.  There is some disagreement about the magnitude of the threat,
and hence about how much one should spend on defense (as opposed to
cleaning up afterwards), but there is no disagreement that there is a
problem.

On the other hand, none of the previous proposals solves it properly;
all of the proposed solutions have their own serious flaws.

> support for encryption only mandatory?

Your writing here is unclear.  I assume you mean that current IPsec
standards support encryption-only without authentication.  I agree --
that was a bad decision by the WG.  It was not done blindly, or in
ignorance of the attacks.  The case was made that there are some
situations (video over IP with per-connection keying, for example), when
the attacks are inapplicable and the costs are high.  The WG was
persuaded that this need overrode the potential for misuse.  As I said,
I did and do disagree.

> issue by simply sprinkling some IPSEC pixie dust on it.

I've been working on routing security for >20 years.  I've never heard
*anyone* competent suggest IPsec for this problem.  Next straw man,
please?

> I think that
	`May the day not be too long delayed,' said Boromir. 'For
	though I do not ask for aid, we need it.  It would comfort us to
	know that others fought also with all the means that they
	have.'

	`Then be comforted,' said Elrond. `For there are other
	powers and realms that you know not, and they are hidden from
	you.  Anduin the Great flows past many shores, ere it comes to
	Argonath and the Gates of Gondor.'

			Tolkien, "Lord of the Rings"

There are many people still trying to figure out how to solve this
one.  It's a hard problem.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 12 May 2009 22:25:02 -0400

On Tue, 12 May 2009 15:42:26 -0400
Phillip Hallam-Baker <[email-masked]> wrote:

> We can all agree on the fact there is a problem. That does nothing.
> What matters to me is if we plan to do something about it before
> crunch time comes.
> 
> As for adding IPSEC to BGP, I would not want to comment on the
> competence of the person involved. I will merely note that maybe the
> proposal suffers from an over enthusiasm for a protocol they are
> heavily invested in and an under-appreciation of the issues involved.
> 
> 
> Before agreeing that the problem is 'hard', I would like to see
> someone set out the security requirements with respect to a credible
> operations model.
> 
> In particular I find it utterly unbelievable that large backbone
> corporation A is going to configure its border routers to simply
> accept routing information from large backboe corporation B. If I was
> responsible for large corporation A then every piece of external
> routing data would be funnelled into a control center and the edge
> routers would only respond to control instructions from the control
> center. No matter what specifications and standards might opine, that
> is how I would run my network.

When you do run an ISP, let me know how well that actually works.
> 
> We thus have two BGP security problems, an internal security problem
> that can be solve adequately with existing infrastructure and an
> inter-network BGP security problem that has some very difficult trust
> issues to manage but certainly does not need to involve the
> cryptographic capabilities of router hardware. I would not generate my
> routing tables on a router.
> 
> 
> The inter-network BGP security problem can then in turn be broken down
> into the problem of binding an IP address block to an AS number and
> securing the anouncement of routs for an AS number. The first is
> relatively straightforward as the bindings are global. They can be
> generated by the IP address block holder using a signature key
> advertised through reverse DNS. The second is hard as routing data
> requires us to consider a transitive trust problem.

Yes -- we all know that.  The devil is in the details.
> 
> I don't think we can prevent an attacker from inserting a bogus route.
> We can however deploy mechanisms that provide for accountability so
> that parties who do introduce bogus routes are detected and face
> consequences. And depending on the resources we are prepared to apply
> we can make the deployment window really short.
> 
I think the cost function goes up very rapidly as deployment time gets
shorter.  But let's do some arithmetic.

First -- there are no fully-specified protocols on the table today that
(in my opinion) are acceptable.  What we have are a variety of research
prototypes that are not adequate for production use on today's
Internet.  But let's suppose that someone has one in his or her back
pocket and will post the I-D tomorrow.  Then what?

Do we want the IETF's imprimatur?  Even if nothing is changed (and
experience suggests that that's unlikely), the process will take about
a year, if only to give people enough time to actually look at it in
Stockholm, Hiroshima, etc.

Next, Cisco and Juniper have to go off and design, code, and test.
Meanwhile, other parties -- ISPs, RIRs, perhaps IANA, perhaps end-sites
that speak BGP -- need to develop their own software and databases to
manage the certificates that are required.  Design of processes -- how
does an AS get a certificate?  What about sites with their own AS# but
who do not wish to generate a key pair? -- takes time as well.  Perhaps
that will overlap the router code development.  I don't know for sure
how long all this will take, but my guess is 1.5-2 years.  Remember
that this is touching BGP; major ISPs do *not* like to run
lightly-tested code trains, especially when BGP is involved.  

Only at this point can we get to deployment (and figuring out how to
pay for it).  Here, perhaps, more money can speed things up, though
it's rather unclear to me where this extra money will come from.  I
don't know how long it will take to get the new code deployed
throughout enough of the Internet to make a difference, but if hardware
accelerators are required (and some past proposals, such as SBGP, would
likely require them) it will take noticeably longer.  Throwing money at
this problem would help, but I don't know where that money would come
from.

Phil, I agree that securing routing is a big problem.  It's the issue
that got me interested in Internet security in the first place,  >20
years ago!  But simply asserting that people don't take it seriously
isn't going to solve it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 May 2009 15:42:26 -0400

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 May 2009 20:40:42 -0400

> When you do run an ISP, let me know how well that actually works.

Well one thing my approach would be a lot less good at would be
forcing upgrades to ludicrously expensive routers.

If I am reading an engineering document that proposes taking a $3/4
million piece of equipment that is highly specialized to one
particular function (routing) and it is claimed that the inability of
this specialized equipment to deal with an entirely different task
(routing data validation) is a barrier to deployment, then either the
document does not describe actual practice or there is some other
reason that actual practice is to do something so peculiar.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 23 May 2009 11:52:29 +0200

[belatedly]

On 12 mei 2009, at 21:42, Phillip Hallam-Baker wrote:

> competence of the person involved.

We need to replace the MD5 hack with IPsec, because MD5 doesn't have  
any DoS potection, crypto algorithm agility or key rollover  
mechanisms. But of course that only protects your BGP sessions, not  
the content of the information in those sessions.

> is how I would run my network.

Sounds like a plan. Now explain to us how your control center knows  
which routing information is valid and which isn't? You have in the  
order of 30 seconds to decide for every update before your customers  
start to complain that "the internet" is broken.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 26 May 2009 16:11:14 +0200

On 25 mei 2009, at 19:34, Phillip Hallam-Baker wrote:

> But I think we need to restate the problem. We don't need to prove
> that the information is valid so much as determine whether it is
> likely to break things or not.

Not simple. One approach that seems attractive is to still allow  
routes that don't pass the authentication steps, but prefer ones that  
do by giving them a higher local preference. Ideally, we would reject  
routes that don't authenticate, but the problem with that is that  
today, none do, so at the very least there needs to be a transition  
period. But we all know what happens to transition periods... If we  
can get around that there's the issue of different kinds of failures  
in the authentication chain. People forgetting to install new  
certificates before the old ones expire is rather common. If that  
breaks your network, good luck getting that new certificate. But the  
"prefer authentic over unprovable" mechanism still has the issue that  
an attacker can inject false information and then do a DoS against the  
authentic information so eventually, the false information is used.

> This looks much more like a spam filtering type problem to me than
> pure access control.

I really don't want false positives in my route filtering...

> So a first cut we might make on the data is to identify route
> advertisements that are within previously established 'normal' bounds.

But how do you accommodate for normal failure conditions that routing  
should solve in that case?

> Having reduced the volume of routes to those that represent
> 'surprises' we have a problem that cannot be solved for the individual
> route announcement in isolation. Like the spam problem we can only
> evaluate routes by bringing in additional information to bear.

Today, RFC 4271 tells us:

    The function that calculates the degree of preference for a given
    route SHALL NOT use any of the following as its inputs: the  
existence
    of other routes, the non-existence of other routes, or the path
    attributes of other routes

> So in summary, I think that to solve the BGP issue we need to look up
> the stack as well and work out methods that allow for reliable
> reporting of attack conditions.

I don't have all the answers, but it seems to me like the model that  
would be most appropriate for BGP would be more like SSH (everyone  
manages their own trust) and a PGP web of trust than a root-anchored  
PKI.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 May 2009 13:34:42 -0400

On Sat, May 23, 2009 at 5:52 AM, Iljitsch van Beijnum
<[email-masked]> wrote:
> We need to replace the MD5 hack with IPsec, because MD5 doesn't have any DoS
> potection, crypto algorithm agility or key rollover mechanisms. But of
> course that only protects your BGP sessions, not the content of the
> information in those sessions.

We should replace the MD5 hack with something that makes for easier
management. It is somewhat disturbing to be reading specs that only
support one algorithm with a reference to a paper describing how that
algorithm was broken.

> Sounds like a plan. Now explain to us how your control center knows which
> routing information is valid and which isn't? You have in the order of 30
> seconds to decide for every update before your customers start to complain
> that "the internet" is broken.

30 seconds sounds a reasonable response time to aim for. Central
control need not be a single centralized control room. In fact much
better it is not. Rather what you want is to have centralized policy
development and localized enforcement.

So a first cut we might make on the data is to identify route
advertisements that are within previously established 'normal' bounds.
We do not need to vet every route advertisement, we only need to look
at those that are 'surprising'. Something of this sort must be taking
place already since each network has to decide whether to (1) use the
new route itself and (2) send out updated advertisements itself.

Having reduced the volume of routes to those that represent
'surprises' we have a problem that cannot be solved for the individual
route announcement in isolation. Like the spam problem we can only
evaluate routes by bringing in additional information to bear. In
particular we need to know if the routes that we are attempting to use
are connecting to the valid endpoints or not. We do not need to do
that for every route advertisement, just as we do not need to content
analyze every potential spam. We can also use reputation. But we do
need a source of grounding data if we are going to use reputation.

Traditional route analysis has to work with the IP level data that is
exposed in the current day Internet. That is fine provided that you
are not under attack from an intelligent adversary. Simply sending out
a bogus BGP announcement is not going to allow you to perform a long
term DDoS attack. The route is going to be quickly discarded if there
is nothing there to connect to.