TAG | bgp
I’ve been asked a couple of times today about the presentation given by Alex Pilosov and Tony Kapela at Defcon, entitled ‘Internet-Scale Man in the Middle Attack‘ – essentially along the lines of, ‘is the Internet broken now?’
The paper doesn’t really say anything that people who are familiar with BGP and its use on the Internet don’t already know. In terms of new content, all it presents is a nifty way of hiding the attacker from showing up in traceroutes by messing with TTL values. This means that to detect the attack requires looking at the AS path, something the average customer doesn’t have access to. The fact the majority of the paper isn’t new information doesn’t make it any less true, of course.
The basic problem is this – every BGP speaker, that is every hosting provider and ISP on the Internet, trusts everyone they directly communicate with. This isn’t actually strictly true, as I’ll come to later, but I suspect the number of those who configure their routers in a more optimal way are in a statistically insignificant minority. This means that I can tell your ISP that the best way to access the BBC News site, for example, is via my network. I can then alter the news stories you’re requesting before they reach you, making you believe that David Ike was right all along, and the Queen has been exposed as a baby-eating reptile. Or something along those lines, anyway…
Fortunately for our customers, their routers aren’t quite so vulnerable – which isn’t to say they are completely unaffected. The most likely source of such an attack is at a peering exchange point, such as LINX or MaNAP. Knowing this, we auto-generate prefix-list filters based on data we obtain from the RIPE database. This means that each peer is only allowed to advertise those IP ranges which we know belong to them or a customer of theirs, and any other advertisements are simply dropped. If they try to say they look after the BBC News range, that particular advertisement is simply ignored, whilst we continue to send them traffic they really are responsible for.
Unfortunately, the same filtering can’t be applied to upstream providers. Here there is no choice but to take what the provider says at face value. As the majority of providers are pretty good at checking the ranges advertised to them by each customer, this is generally OK, but inevitably there is always the possibility of misconfiguration, either by human error or a rogue member of staff. Whilst this is a realistic possibility, it’s on nothing like the scale suggested by the aforementioned paper.
Fundamentally, the message is this: if you have a competent provider, don’t panic. Ask your provider what kind of filtering they use with their peers. If all they do is check for ‘max prefixes’, ie, limit the number of prefixes a peer can send them, it’s time to start looking elsewhere.

