MD5 for TCP/BGP Sessions

NANOG,

I'm currently writing a paper for submission, as part of a MSc in Data
Communications, and would appreciate if anyone could update me as to the
implementation of MD5 for TCP authentication in BGP.

Following the alerts last year:
http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml
http://www.us-cert.gov/cas/techalerts/TA04-111A.html
http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7
d9.shtml
http://www.foundrynet.com/solutions/security/TCP_Vulnerability_v1_3.pdf
http://www.kb.cert.org/vuls/id/415294
http://isc.sans.org/diary.php?date=2004-04-20

What has been the general effect in the ISP/Enterprise community following
the warnings?
- Have people applied MD5?
- If not what other technologies were implemented (IPSec AH transport mode
for BGP sessions/ACL/rate limiting etc)?
- Has there been any performance impacts seen since implementation?
- Has the support of the BGP environment been increased because of this
implementation (What policies regards changing the MD5 keys were
implemented)?
- Was this seen as a valid fix or a knee-jerk reaction (Having re-read the
exchanges on NANOG regards the actual mathematical probability of generating
this attack, what did the ISP community actually do (compared to what the
academic/vendor community were suggesting)?

Whilst I've had some response from bgp-info and bgp-security, it's not
really been sufficient to draw any real conclusions. From your knowledge and
experience are you aware, either internally or with customers the take up of
MD5 implementations and had anyone actually suffered an attack prior to
implementation

What has been the general effect in the ISP/Enterprise community following
the warnings?
- Have people applied MD5?

Without question more BGP sessions suddenly became 'MD5-enabled'
across the net. It has been debated whether this was a necessary
or even if it was a good thing. You should find some references,
including some on this list where BGP peer sessions were being
reconfigured with MD5 applied during the last TCP sequence number
scare.

- If not what other technologies were implemented (IPSec AH transport mode
for BGP sessions/ACL/rate limiting etc)?

I don't know of any widespread use of IPsec for BGP sessions even
after that last round of alerts, but I am sure some exists. I
would be interested in hearing from those that have implemented it
in production.

ACLs are often used, but vary widely depending on organization.
It can be difficult to manage ACLs on a box with a large number
of peers that uses many local BGP peering addresses. I'm sure
some organizations reviewed and updated their ACLs as a result
of the last scare, but that is a local, private decision and it
would probably be hard to get good sample of who and what changed.

- Has there been any performance impacts seen since implementation?

Not real world cases that I've heard, but I believe a number of
sites prefer not implement MD5 in part because of the potential
performance/DoS issues with it enabled.

- Has the support of the BGP environment been increased because of this
implementation (What policies regards changing the MD5 keys were
implemented)?

Not in my case. We use a simple algorithm to come up with the shared
secret, then document it in our peering contact database, which is in
a secure, internal location that we can reference if we ever need it.
In our case it is just relatively simple additional step when
configuring or reconfiguring a BGP session. Although I have seen some
compatibility issues between platforms. For example, relatively long
length passphrases were not properly supported.

In my experience, I haven't seen much practice of changing MD5 keys
on BGP sessions except when an organization makes major changes or
hasn't kept a record of the shared secret during changes. That is
probably the most common time it will get changed. I suppose some
organizations may change it when employees who knew it leave the
organization, but I've not seen much evidence of that.

- Was this seen as a valid fix or a knee-jerk reaction (Having re-read the
exchanges on NANOG regards the actual mathematical probability of generating
this attack, what did the ISP community actually do (compared to what the
academic/vendor community were suggesting)?

I think that has probably been discussed enough already and will
probably be again now so I'll leave it to others to re-hash that.

Do note that at least a two specific and related solutions have
appeared in the last few years. One is the Generalized TTL Security
Mechanism (GTSM) as defined in RFC 3682. It was originally written
with BGP in mind, but is also useful for things like MSDP peering.
See the RFC for details and why this might be used on BGP sessions.
Another is smooth transition between shared secret changes or when
applying authentication where none existed. I don't have references
handy, but I seem to recall this was still vendor-specific and not
fully implemented. Perhaps others will step in with updated info.

MD5 can mitigate a risk, but it can come with some operational
costs. Some operators prefer one side of the risk equation over
the other. Some place a higher weight on one side of the equation
than the other depending on the organization and the network. In
my experience most will do MD5 if asked and only a small number
would actually refuse.

Whilst I've had some response from bgp-info and bgp-security, it's not
really been sufficient to draw any real conclusions. From your knowledge and
experience are you aware, either internally or with customers the take up of
MD5 implementations and had anyone actually suffered an attack prior to
implementation

Not that I'm aware of, but I've almost always used it and other
knobs when I could so maybe I just didn't notice?

John

[on bgp/md5 and acl's]

ACLs are often used, but vary widely depending on organization.
It can be difficult to manage ACLs on a box with a large number
of peers that uses many local BGP peering addresses. I'm sure
some organizations reviewed and updated their ACLs as a result
of the last scare, but that is a local, private decision and it
would probably be hard to get good sample of who and what changed.

I would be double careful here, just to make sure everybody understands what you're protecting.

iBGP sessions? ACLs are trivial if you have your borders secured.

eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well.

What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain.

There are other attacks you can make against TCP sessions (protected by MD5 or not) using ICMP, though. (see draft-gont-tcpm-icmp-attacks-03.txt).

without wishing to repeat what can be googled for.. putting acls on your edge to
protect your ebgp sessions wont work for obvious reasons -- to spoof data and
disrupt a session you have to spoof the srcip which of course the acl will allow
in

Steve

Stephen J. Wilcox wrote:

without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in

This is why you either have a stateful firewall in your router that pushes a dynamic acl down to the linecard (or equivalent forwarding place where the for_us vs through_us decision is made), and filter it there. That makes guessing the correct 5 tuple a bit harder. Obviously GTSM is the closest we have yet to hardening (note I did not use securing) the session.

On average, the stateful filter will cause the attacker to to try 32000 times to find correct 4-tuple. Conversely, attacker resources will need to be on average 32000 times greater to adversely affect a router. The cost of attacking infrastructure has risen, but the cost to defender is minor.

Each configured BGP session already has all the state needed above to populate the filter.

/vijay

>
> [on bgp/md5 and acl's]
> > ACLs are often used, but vary widely depending on organization.

(and equipment in use)

> > It can be difficult to manage ACLs on a box with a large number
> > of peers that uses many local BGP peering addresses. I'm sure

provided your gear supports it an acl (this is one reason layered acls
would be nice on routers) per peer with:
permit /30 eq 179 /30
permit /30 /30 eq 179
deny all-network-gear-ip-space (some folks call it backbone ip space, Paul
Quinn at cisco says: "Infrastructure ip space")

no more traffic to the peer except BGP from the peer /30. No more ping, no
more traceroute of interface... (downsides perhaps?) and the 'customer'
can still DoS himself :frowning: (or his compromised machine can DoS him)

> > some organizations reviewed and updated their ACLs as a result
> > of the last scare, but that is a local, private decision and it
> > would probably be hard to get good sample of who and what changed.
>

some people still use 'cisco' for their password, even on non-cisco
platforms :frowning: this md5 discussion isn't the only security problem :frowning:

> I would be double careful here, just to make sure everybody
> understands what you're protecting.
>
> iBGP sessions? ACLs are trivial if you have your borders secured.
>

ibgp, provided your infrastructure space is seperate from 'customer' space
is simpler... but keep in mind the possible downsides (no ping, no
traceroute, harder troubleshooting for the customers, perhaps)

> eBGP sessions? GTSM is your friend (if supported). Practically, if
> you know your peer and you also protect your borders, ACLs are rather
> trivial as well.
>

borders, for some folks, are wide, varied and complex :frowning: So, for some
folks with limited border size/breadth making these things trivial is, of
course, easy.

> What you seem to be saying is using ACLs to enumerate the valid
> endpoints for eBGP sessions. That goes further than the above but
> indeed is also a pain to set up and maintain.
>

and impossible to implement on some hardware. Note: Some/all of that
hardware is going away as time makes it fade into the background...
sometimes not fast enough though.

-Chris

Christopher L. Morrow wrote:

provided your gear supports it an acl (this is one reason layered acls
would be nice on routers) per peer with:
permit /30 eq 179 /30
permit /30 /30 eq 179
deny all-network-gear-ip-space (some folks call it backbone ip space, Paul
Quinn at cisco says: "Infrastructure ip space")

no more traffic to the peer except BGP from the peer /30. No more ping, no
more traceroute of interface... (downsides perhaps?) and the 'customer'
can still DoS himself :frowning: (or his compromised machine can DoS him)

or forge the source ip on the neighbors /30 or /31 (why aren't you using /31s anyway) and call it done.

/vijay

curse you and your new-fangled /31's! :slight_smile: Yes, someone inside the customer
could dos the customer... if the customer cared, they could acl their side
as well though since they aren't doing egress filtering I'm betting they
aren't going to do this either ;(

-Chris

This is why this helps for eBGP sessions only the peer is also protecting its borders. I.e., if you know the peer's network has spoofing-prevention enabled, nobody is able to spoof the srcip the peer uses.

trusting a third party to protect your network is imho not best practice, in
addition many networks may have considerable customers inside them making
attacking from inside trivial

Steve

That is why GTSM is useful for hardening, in addition to protecting your borders.

When I say 'border protection', I also mean the border between an operator and its customers. I.e., strict uRPF -like prevention, so that nobody (neither a peer, upstream or customer) is able to spoof the infrastructure IP addresses.

That's what we're doing, and I'd hope more people would as well.

Dear Fellows,

a simple configuration that can help to improve security on BGP tcp sessions is to establish it using ip loopback address on both sides, even in situations with only one link between routers. By doing that the ip address used are hidden from traceroute tools discovery.

Also the ip address used can be no routeable outside both routers, which will naturally block ip traffic against the BGP tcp session from any other host.

Regards,

Eduardo Ascen´┐Żo Reis.