Subject: RE: BGP security in practice

From: "Martin, Christian" <[email-masked]>
Date: Mon, 4 Nov 2002 09:38:21 -0500

Sandy,

The problem has nothing to do with clue as much as it has to do with shared
secret management across potentially hundreds of external connections.  I
would think that at a minimum, most providers use authentication on their
iBGP sessions.  But eBGP is different, especially when you have to negotiate
the secret with a peer, that which is different across most, if not all, of
your peers.  Some peers do not support MD5, as you suggest, so that opens
that one router up to attack.

I think many providers are ambivalent towards MD5 because they are (perhaps
wrongfully) confident that it is not easy to hijack a BGP session.  With
properly designed ISN pseudorandomization, drawing on highly entropic
external information, the likelihood of successfully launching a BGP attack
diminishes significantly.  

What is more likely is having your MD5 secrets stolen from your NOC through
social engineering methods.  This is probably why MD5 sees so little use in
practice because it requires the entire NOC staff to have access to the
secret database.  This is of concern - it is like giving the entire NOC
staff root access to your BIND or Sendmail systems.

In order for BGP Security to become a reality, we need:

1) a PKI based system
2) IPSEC based encryption of all data
3) Required use of an IRR for all routing

Until then, we are running around with Bandaids trying to stop hundreds of
leaks...

My .02
chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 04, 2002 8:40 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: BGP security in practice
> 
> 
> Lots of you folk probably read the rpsec list as well, but 
> for those who
> don't, there's a discussion going on of how many ISP's use 
> the MD5 shared
> secret form of authentication.  The response are, uh, disheartenting.
> I've attached one message that says that some ISP's are 
> ignorant of the
> existence of security problems.  That beggars the imagination.
> 
> In the judgement of those on this list, is the general ISP as clueless
> as this?  Mind you, I'm not asking if the common ISP uses the 
> MD5, just
> if they know that there's a security vulnerability if they don't.
> 
> And then the second question is how many ISP's do use the MD5 
> authentication
> and whether it varies by distance from the backbone.  (Please 
> tell me that
> the major backbone carriers use this!)
> 
> --Sandy
> 
> From [email-masked]  Mon Nov  4 05:40:04 2002
> Date: Mon, 4 Nov 2002 11:24:49 +0100
> From: Birger Toedtmann <[email-masked]>
> To: [email-masked]
> Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.3.28i
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.12
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
> 	<mailto:[email-masked]?subject=subscribe>
> X-MIME-Autoconverted: from 8bit to quoted-printable by 
> www1.ietf.org id gA4AQ5v16897
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by 
> raven.gw.tislabs.com id gA4Ae3328456
> 
> David G. Boney schrieb am Sun, Nov 03, 2002 at 02:12:00PM -0500:
> > Are there any implementations with MD5? Does anyone even 
> use it in practice?
> > 
> > I recently talked with the former founder of a small ISP. 
> His response 
> > was roughly, "Crypto?" They did not use it. Furthermore, 
> there was no 
> > encryption in the routing protocols with their upstream 
> providers, UUNET 
> > or Sprint.
> > 
> > I think a survey of who is actually using any of the 
> encryption features 
> > of any routing protocols would be informative.
> 
> Until recently I worked for a mid-size ISP in Northwestern Germany.  
> 
> A year ago I tried to put MD5 on both BGP uplinks it had.  The first
> uplink provider, Versatel, did not even know about security 
> issues with
> BGP, neither did they know anything about MD5 on 
> corresponding sessions.  
> Consequently, they denied the request.
> 
> The second one, ECRC (which had been bought by Cable&Wireless 
> in 2000),
> knew about it, but said: "Eh, well, if you wan't it, we will 
> do it with 
> you.  However, you'll be the first one out of 100 customers, and we'll
> have to configure it manually."
> 
> 
> Regards,
> 
> Birger Tödtmann
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 07:33:55 -0800

> 3) Required use of an IRR for all routing

that is not clear.  e.g. why do the data need privacy?  why do
all relationships need to be represented in routing registries?

for an example, think about a modified s-bgp where
  o the 'pki' is pgp-like or even real pgp
  o basic ownership of ip space is attested to by registries
  o sub-allocation of ip space is attested to by the basic owner,
    and so forth
  o the origination of the routing announcement is attested to by
    an address space owner
  o an announcement is signed contains
    - the normal attributes
    - an attribute saying to what ASn the route is being forwarded
      (prevents monkey in the middle attacks)
    - and all this is signed by the announcing AS

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2002 10:47:22 -0500

Randy,

> all relationships need to be represented in routing registries?

I'm going to skip over your other arguments since I haven't looked
at s-bgp in enough detail to make intelligent comments on it.

However, the piece we are missing right now is a mapping of
address space ownership to AS space.  The IRR's have a way to
represent it - we need the RIR's to track this.

Without this, all the talk of "ownership" in the world wont help.

...

Has anyone actually checked to see what the relative computation loads
are on a certificate chain signing on routes (which is what I understand
s-bgp to largely be) versus an IRR cascading policy check?
(Yeah, that presumes correct policy.)

Intuitively, it seems like it'd take fewer cpu cycles to do this
at the cost of a pretty huge database.  But I don't have a good
feel for the size of the certificate db's that would need to be
passed around.

And intuitively doesn't mean squat.  Numbers do. :-)

I'll shut-up now since I don't have time to put-up.

-- 
Jeff Haas 
NextHop Technologies

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 07:55:33 -0800

> s-bgp to largely be) versus an IRR cascading policy check?

presume crypto hardware on routers

but as filters do not help at all against a mitm

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2002 11:02:26 -0500

> presume crypto hardware on routers

One could also presume some extra hardware for filters. :-)

> but as filters do not help at all against a mitm

True.  
Solving the long-term problem means securing against that threat model.

I think the threat model that is of biggest concern to operators today
(IMO) is just making sure people don't (re)announce stuff they're
not supposed to.  

Signing only keeps people from lying about something they did.
You still need to verify that the signed thing belongs to them.

In essence, I'm arguing that since both of these pieces are eventually
necessary, the filter piece gives us the most bang for the buck
in the shorter time.

-- 
Jeff Haas 
NextHop Technologies

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 08:41:39 -0800

> necessary, the filter piece gives us the most bang for the buck

operators might like *one* major deployment of change

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2002 11:44:12 -0500

> operators might like *one* major deployment of change

Thanks for the clue-by-four on the back of the head.  I need that
sometimes. :-)

I'd argue though that the filter model *may* be implementable
on current (bigger) hardware without the need for crypto
accelerators.  Thats where some analysis might be handy.

-- 
Jeff Haas 
NextHop Technologies

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 08:56:22 -0800

> accelerators.  Thats where some analysis might be handy.

it's the infrastructure deployment, not just the boxes.

randy

---

From: [email-masked]
Date: Mon, 4 Nov 2002 13:03:56 -0500 (EST)

>     - and all this is signed by the announcing AS

Very cute. I really trust Cisco and Juniper to do key management for me.
Not.

The prinipal is called KISS. Make routers route. Make them not break. Make
them not crash. Make them not melt. When we get a good track record on that,
we can talk about key management problems.

Alex

---

From: [email-masked]
Date: Mon, 4 Nov 2002 13:29:15 -0500 (EST)

> accelerators.  Thats where some analysis might be handy.

How are you going to manage the keys? Are you going to protect the keys with
encryption? if a router reboots, are  you going to have someone there to
type an unlock phrase to decrypt the key used for authentication? Are you
going to use the key in a non-encrypted so everyone who can do "show key
private" will be able to cut and paste that they into their Xterm logged
into a router in Bangladesh?

Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2002 13:30:02 -0500

Alex,

I think you meant to respond to Randy.

On Mon, Nov 04, 2002 at 01:29:15PM -0500, [email-masked] wrote:
> How are you going to manage the keys?

What keys?  They're just acl's.

-- 
Jeff Haas 
NextHop Technologies

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Nov 2002 10:36:37 -0800

> Don't we need to be hardening all the software for a longer-term
> solution, rather than just the current snapshot?

bingo!

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 5 Nov 2002 10:04:49 -0500

On Tue, Nov 05, 2002 at 12:03:11AM -0800, Alexei Roudnev wrote:
> As filters do not help against anything. I know  ISP who did not used AS filtering
> at all 3 years ago - you should filter prefixes anyway, so why bother about AS
> passes? We removed _all_ AS fileters and keep only prefix filters (for both
> inbound and outbound bgp) - of course, it allowed customer to announce ANY AS, but
> _so what?_

Prefix filters protect you against *what*.  I.e. *what* reachability
are you getting?
As path filters protect you against *who*.  I.e. is this person allowed
(or even expected) to propagate this route.

Protecting against bad prefixes provides general protection against
bad routes getting into the Internet.  Pair this with originating
AS correlation and you stop most of what our previous "oops"s have
been.

But you need to filter against the path in order to provide a full
policy check if you're more than one hop away from a given party.
If you're only one hop, you can do this with your prefix filters.

I'll admit that people will settle for sub-optimal routing due to
route leaks - you can notice and fix that.

People don't want to deal with bad prefixes.

> Alexei Roudnev.

-- 
Jeff Haas 
NextHop Technologies