Inter-domain Routing security Problems Solutions

Inter-domain Routing security • Problems • Solutions

BGP • Routers that belong to AS originate path UPDATEs for routes they can reach • These propagate throughout the system • Policy can constrain this propagation – Selective export – Selective import • It is sensitive to the usual problems – Bugs, mis-configurations – Do. S attacks, TCP hijack attacks – Break ins in the routers – Stolen passwords

Many other things can go wrong • • A router can pretend to speak on behalf of some other AS An AS can advertise paths for routes it can not reach An AS can send paths to neighbor AS that it should not An AS can modify path information – Shorten a path to attract more traffic • An AS can silently drop path information • An AS can withdraw routes it did not advertise • It may hard to see if something is wrong – Policies in the AS may change its behavior – E. g. an AS does not advertise certain routes • This is not because it is malicious, it is because this is its local policy

Common problems • An AS announces an address that is not allocated or belongs to another AS – Prefix hijacking • Many flavors – Multiple Origin AS (MOAS) • Two ASes originating the same prefixes • Sometimes can be cause by multi-homing though – De-aggregation • Advertise longer prefixes • Routers will prefer these stealing address space from the rightful owner – Contradicting advertisements • All these could be caused by misconfiguration too – Important to avoid false positives

And things do go wrong • Prefix hijacking has been observed many times – Google incident in 2005 • One of its prefixes was hijacked for few hours – “Spectrum agility” and spamming • Prefixes appear, spam is sent from them and then they disappear • Impossible to trace the real location of the spammer – It shows up all over the network • Spammers use large prefixes (e. g. /8) – Use an address in the prefix only once – Hard to filter, need to filter on a prefix base • One study found that 10% of the spam observed was generating using this method

BGP routers do get compromised • In the inter-domain case provider’s routers where well protected – Perimeter defenses • In BGP it is harder – Providers and customers talk BGP – Customers have BGP routers • That may be unsecured and can be easily broken into • There is evidence that this is happening – Or simply a malicious customer • Sign up with an ISP and inject bogus information into the system • Still, provider can aggressively filter what it receives from the customers

Approaches • Proactive – Attempt to secure the protocol • Cryptography • Other techniques (route filtering, TTL hack) • Reactive – Detect a problem • Practical aspects – Message, CPU and storage scaling – Ease of deployment

S-BGP • Attempt to a full blown solution. Ensure that: – A router is authorized to speak for an AS – An AS is authorized to originate a route – An AS is authorized (by the owner of the router) to propagate an UPDATE – An AS can only withdraw routes it originated

Components • IPSec between the BGP routers – Avoid TCP problems • Attestations: – Cryptographic construct that declares that prove that A authorizes B to perform operation O. • Address attestation (AA): owner of route A authorizes as B to originate path for route O – Quite static • Route attestation (RA): AS A authorizes neighbor AS B to advertise prefix O – Very dynamic • PKI for disseminating keys

PKI • Manages the public keys for entities • Certification – Need to ensure that a given key is indeed the one bound to the entity – Need a trusted third party • Certification authority (CA) • Signs the public key records • User of the certificate can verify the signature • Hierarchy – One level can certify keys for the lower level(s) • Chain of trust – Matches well the internet address allocation model • Revocation – Key or certificate may not be valid after a while • Hard to “take back” the certificate – Certificate revocation list (CRL) • All members of the system must know it, not easy – Unless each certificate is time-stamped and they are refreshed every day

Validating an UPDATE • Check the AA of the originator of the route (first AS in the AS_PATH) • Check the RA of all the intermediate hops in the AS_PATH – Each RA covers the path until the router that creates it • To check the attestations we need (certified) keys of the entities involved (all the AS in the AS_PATH) and maybe routers – How to get all these?

Security information distribution • The RA data vary very fast and have to be sent in-band – Part of the UPDATE messages • AA, keys and certificates vary infrequently – AA changes when ISP are allocated new address ranges • They are exchanged outside BGP through repositories

Repositories • Large ISPs maintain repositories with all this information – Keys, AA records – And certificate revocation lists (CRLs) • Client ISPs subscribe to these repositories and add their information • Repositories are loosely synchronized • ISPs get all this information for all other ISPs • Process it so that is more compact • And download this to each s. BGP router • All above transfers are over SSL connections

Overheads • RA information in the UPDATES – 800% increase in amount of information sent! • But overall UPDATE traffic is not that much – It has to be stored in the BGP routers • For each peer • About 35 Mbytes/peer • This is a problem! • Repository information could be around 75 Mbytes – Has to be transferred between ISPs once a day or so – Not a big deal • CPU costs for verifying the attestations – About 18 ops/second, many more in unstable periods – This is a problem too, too much for software processing – Could cache information to reduce this cost • But then I would need more storage – Or verify only routes that will result in routing changes • New best routes

Other problems • Administrative overheads – It is quite an effort to add a new prefix in an AS • Sensitive to a replay attack – Router can re-advertise a recently withdrawn route

Is it practical? • Not with the currently deployed routers – Not enough memory – Not enough non-volatile storage • There are implementations and small demonstration testbeds • Right now (2006) there is a initial implementation/trial of the repository infrastructure – Resource certificates bind resources with an AS – Hierarchical allocations • Follows the address allocation with the 5 RRs – “Chain of trust”

Secure origin BGP • Proposed by Cisco - More limited scope – Verify that originator of the path has the rights to advertise it – Verify that a router that advertises a destination has a route to the prefix • Resources are tied to ASes through authorization certificates • Routers also originate AS policy certificates that describe their connectivity – All routers use these to build a topology map (!) – That can be used to verify existence of path • These certificates are exchanged through a new SECURITY BGP message – Use routing for securing routing?

Overall • There is a fundamental trade-off – Security vs. overhead – Solutions fall at some point in the design space • Moore’s law will make feasible what is not possible today • But there are other issues – Deployment • We can not change all routers at once • We can not change BGP in all routers at once • Would be nice to have a solution that is incrementally deployable – We can not come up with “another” BGP • Current BGP took about 10 years to understand stabilize – And we are not there yet

Other approaches • Router filtering – – – Bogons: list of well known bad addresses List of the dark space – unallocated addresses Routers know these lists and use them to drop malicious routes But it is difficult to keep these lists up to date Also, only accept routes from customers that correspond to the address space that it assigned to it • But what about multi-homing? • Non-BGP solution: IRV – Each AS has an IRV server – When an AS receives a route from another AS it contacts the IRV server of the source AS to verify the information it received – This will happen recursively for the whole path • And the “TTL hack” – Securing the TCP sessions only – Accept packets only from a router that is 1 hop away – All the packets sent have TTL=1

Detection • MOAS detection – Monitor the BGP traffic for detection – The trick is to tell when the conflicts are legitimate • E. g. Multi-homing • Prefix hijack detection system – ASes register with route monitors – And are notified when their prefixes appear to change – How do I contact an AS that its prefix is hijacked? • Routes to it may be down! • Reputation systems – Compare information learned from multiple places and assign it a score