1 / 20

Inter-domain Routing security

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

hmyers
Download Presentation

Inter-domain Routing security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Inter-domain Routing security • Problems • Solutions

  2. 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 • DoS attacks, TCP hijack attacks • Break ins in the routers • Stolen passwords

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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?

  12. 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

  13. 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 sBGP router • All above transfers are over SSL connections

  14. 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

  15. 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

  16. 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”

  17. 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?

  18. 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 and stabilize • And we are not there yet

  19. 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

  20. 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

More Related