Subject: Re: [RPSEC] draft-convery-bgpattack-00

From: Damir Rajnovic <[email-masked]>
Date: Sun, 03 Nov 2002 17:41:02 +0000

At 15:43 01/11/2002 -0800, Sean Convery wrote:
>  OR  1. Use social engineering to obtain MD5 password

Does anybody knows how often ISPs are changing the 'secret key'
on a single link between two peers? Also, how diverse keys are
between multiple links (towards the same ISP and across all peering
points)?

If the answers to the above questions are not positive we may think
about replacing the whole secret key scheme with another one where
the secret key is a master key and we have separate session keys
which are expired and changed after some period of time.

Gaus
==============
Damir Rajnovic <[email-masked]>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There is no insolvable problems. 
The question is can you accept the solution? 

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: "David G. Boney" <[email-masked]>
Date: Sun, 03 Nov 2002 14:12:00 -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.

Sincerely,
David G. Boney

Department of Electrical and Computer Engineering
The George Washington University
Phillips Hall, Suite 607
801 22nd Street, N.W.
Washington, DC 20052

http://student.seas.gwu.edu/~dboney
mailto:[email-masked]
Department Phone (202) 994-6083
Department Fax (202) 994-0227

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 Nov 2002 20:49:17 +0100 (CET)

> Are there any implementations with MD5? Does anyone even use it in practice?

I know from personal experience Cisco implements it and Zebra doesn't.
I'm also pretty sure the major vendors implement it.

However, not many people actually use it.

> of any routing protocols would be informative.

I recently set up peering over the AMS-IX for a customer. They now have
103 peering sessions (note: some peers use two sessions) of which 4 are
protected with an MD5 password. So about 4% of the peers requested
password protection.

I have never seen Password protection on ISP<->customer links.

---

From: Christopher Lonvick <[email-masked]>
Date: Sun, 3 Nov 2002 12:24:14 -0800 (PST)

Hi Gaus,

I believe that Marcus Leech has some discussion
around this in draft-ietf-idr-md5-keys-00.txt

Later,
Chris

---

From: Birger Toedtmann <[email-masked]>
Date: Mon, 4 Nov 2002 11:24:49 +0100

> 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

---

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

> However, not many people actually use it.

nope.  just the bigger smarter providers.  some won't peer with you
without it.

randy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2002 12:42:31 -0500

-----BEGIN PGP SIGNED MESSAGE-----

I don't find draft-convery-bgpattack-00 on the ietf site.
(I have a nightly rsync of it...)

My understanding of MD5, is that this secures the TCP session used by BGP. 

While I think that this can have value, particularly for multihop
arrangements, I thought that BGP was supposed to have a TTL=1, such
that its packets couldn't get routed. (I know that zebra does not do this)

So, it protects the session, which given that they typically cross
a single link, are not that vulnerable. (Sure, they can be attacked, but
it involves some amount of physical access. I realize that in ATM/SONET, that
this might still be trivial to get)

I am more concerned about the semantics of what is announced, than how
it is communicated from AS to AS.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Birger Toedtmann <[email-masked]>
Date: Mon, 4 Nov 2002 18:59:42 +0100

> this might still be trivial to get)

Far from it.  In todays peering associations, it is quite common to use
"ebgp multihop" arrangements because the next speaker (sometimes a powerful 
machine is needed to hold the tables) is several hops away.  In addition
to that:  Any attacker can craft a packet that *looks like* it travelled
just one hop, but did not - so you need to watch for those packets.  But 
if you (or your peering partner) *do* packet filtering, you don't need the 
TTL=1 mechanism at all....   So this is a noop, concerning security.  

AFAIK, the feature of TTL=1 was invented to have some weak assurance that 
the BGP session is established over the correct network path.

Just my .02c,

Birger

---

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

> the BGP session is established over the correct network path.

As proposed by a recent draft, draft-gill-btsh-00.txt, a TTL of
255 is more secure.

-- 
Jeff Haas 
NextHop Technologies

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2002 15:28:38 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Birger" == Birger Toedtmann <[email-masked]> writes:

    Birger> Far from it.  In todays peering associations, it is quite common to use
    Birger> "ebgp multihop" arrangements because the next speaker (sometimes a powerful 
    Birger> machine is needed to hold the tables) is several hops away.  In

  Fair enough.

  I have had severe difficulty with a number of ISPs to convince them make
this kind of arrangement - the last mile is now more frequently xDSL (vs T1)
of some kind, and the DSLAMs definitely do not run BGP. I had assumed that it
was still "too new" for them to cope with. (I live in the "backwaters" here
in Ottawa...)

    Birger> to that:  Any attacker can craft a packet that *looks like* it travelled
    Birger> just one hop, but did not - so you need to watch for those

  Sure, I can buy that. They need to do all the sequence number guesses to
make a useful attack, and it results in a DoS more than anything else.

    Birger> AFAIK, the feature of TTL=1 was invented to have some weak assurance that 
    Birger> the BGP session is established over the correct network path.

  No kidding.
  I'd be happiest with IPsec, using raw RSA keys (no PK*I*, just PK) to
authenticate. This is as easy as exchanging MD5, and potentially better
documented in many products. 

  This arrangement is peer-to-peer, so we can make recommendations, and
people can implement this without any broad arrangements.

  Again, I think that we need to deal with higher level requirements.

  I wonder if we are in agreement 
    1) that there should be some kind of way to authenticate prefix->AS.

  If so, then there is two possibilities

    2a) that this should be communicated online, within the BGP4 protocol.

    2b) that this information should be in a standard database, with
    well known proceedures for generating filtering rules from this database.
    (I consider this "offline", because you may have to go through a router
    reconfig to get new entries, etc..)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2002 15:52:15 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jeffrey" == Jeffrey Haas <[email-masked]> writes:

    Jeffrey> As proposed by a recent draft, draft-gill-btsh-00.txt, a TTL of
    Jeffrey> 255 is more secure.

  yes, a nice hack.

  As section 3.1 points out, this can be done for multihop as well.
  In particular, I'll bet that 95% of multihop scenarioes have the route
server extra one hop away. (potentially, it each direction)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Nov 2002 21:58:51 +0100 (CET)

> My understanding of MD5, is that this secures the TCP session used by BGP.

Yes. It basically signs every TCP segment so you're protected against
any kind of TCP trickery (such as false RSTs). But simple anti-spoofing
filters will do that too.

> that its packets couldn't get routed. (I know that zebra does not do this)

It does have a command to turn off this non-implemented feature, though...

> this might still be trivial to get)

The TCP MD5 password option protects against sniffing and man in the
middle attacks too. Someone who doesn't have access to the password
can't successfully engage in a BGP session if this option is used.

> it is communicated from AS to AS.

Between ISPs and customers this isn't a problem as the ISP filters. The
only thing a customer can do is flap a lot (which can be dampened
explicitly or because updates are delayed somewhat by default).

Between ISPs filtering is problematic because of the large numbers of
routes exchanged. Also, an ISP could attach meaningless but large
attributes to routes to exhaust another ISP's router memory, and since
the number of routes is larger flapping does more harm.

However, I think it is unnecessary to protect against "evil" ISPs since
they only get to do this once before they're disconnected and an ISP in
their right mind wouldn't do this. People with this level of paranoia
should go to the local super market and test the food there for poison.
After all, if ISPs can't trust each other, why would grocers? And
poisoning some oranges gives you much more bang for your buck than
injecting some false routing info.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2002 16:25:35 -0500

On Mon, Nov 04, 2002 at 09:58:51PM +0100, Iljitsch van Beijnum wrote:
> their right mind wouldn't do this.

One would like this to be true.

The initial goal of securing BGP, IMO, whether it be all at once, or
incrementally, is to prevent stupidity or misconfiguration from
harming the Internet.  For the most part, it has been fat-fingering
that has caused most of the recent harm to the network.  Bugs
and interop issues account for much of the rest.

However, we have more reason today to worry about this.  The world
is a less friendly place than it used to be.  Trust your neighbors,
but still lock your doors.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Nov 2002 22:32:45 +0100 (CET)

> and interop issues account for much of the rest.

Yes. This is why we need better information to build filters from, and
better ways to install them in our boxes. However, this has nothing to
do with BGP itself.

> is a less friendly place than it used to be.

Not true. The world is still the same, human nature is still the same.
Only the toys get bigger and better.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Nov 2002 17:54:15 -0500

>filters will do that too.

Just a nit. The MD5 keyed hash is not a "signature" function. it is a 
message authentication code (MAC). it is also a poor one, relative to 
modern crypto design principles, which would call for use of the HMAC 
construct for this purpose.

>can't successfully engage in a BGP session if this option is used.

the first statement is not correct, since "sniffing" is a passive 
wiretapping attack. the MD5 option does not provide encryption and 
thus does not protect against such attacks. your second sentence is 
true, but this is a spoofing attack, not a sniffing attack.

>injecting some false routing info.

This last observation is not borne out by experience.  DARPA-funded 
research reported in 2002 observed that about 1% of all advertised 
routes are in error at any time.  Given current routing table sizes, 
this amounts to about 1,000 routes.  Thus some number of ISPs do make 
mistakes and their neighbors do propagate these errors to the rest of 
the Internet. Mechanisms that detect and reject advertisements that 
are in error do seem to be needed for BGP.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2002 21:34:19 -0500

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    Iljitsch> Between ISPs filtering is problematic because of the large numbers of
    Iljitsch> routes exchanged. Also, an ISP could attach meaningless but large
    Iljitsch> attributes to routes to exhaust another ISP's router memory, and since
    Iljitsch> the number of routes is larger flapping does more harm.

    Iljitsch> However, I think it is unnecessary to protect against "evil" ISPs since
    Iljitsch> they only get to do this once before they're disconnected and an ISP in

  Overt anti-social behaviour is easy to notice and deal with.
  It is more subtle problems that are harder. They may be the result of
subtle misconfiguration, software errors, etc. It may also be the result of a
very targetted attack.  This is a concern for both white hats and spooks.

---

From: Sean Convery <[email-masked]>
Date: Mon, 4 Nov 2002 19:59:15 -0800

Michael,

We didn't finish in time to make the cutoff, you can find them here:

http://trinux.sourceforge.net/draft-convery-bgpattack-00.txt
http://trinux.sourceforge.net/draft-convery-bgpattack-00.html

Thanks,

Sean

>(I have a nightly rsync of it...)
SNIP