Security in inter-domain routing

Size: px

Start display at page:

Download "Security in inter-domain routing"

Miranda Stewart
5 years ago
Views:

1 DD2491 p Security in inter-domain routing Olof Hagsand KTH CSC 1

2 Literature Practical BGP pages Chapter 9 See reading instructions Beware of BGP Attacks (Nordström, Dovrolis) Examples of attacks and effects of attacks when routers have been compromised 2

3 Overview Why would anyone attack BGP? What effects would an attack on the infra-structure have? Compare to single hosts or DNS attacks Attacks against customers DoS attacks directed at customers do not usually affect the operators, but many operators try to identify them and stop them Indirect attacks: traffic overload / congestion / denial of service Attacks on a BGP router Protecting peering relationships Attacks by routers already compromised Securing routing information within BGP Check validity of routes: origin of prefix, path attributes 3

4 Routing failures by mistake AS7007 incident (1997) One router in AS7007 defragmented all Internet routes into /24 and announced all routes with itself as origin AS9121 incident (2004) > /24 routes announced upstreams Youtube incident (2008) Instead of blocking, announce all youtube prefixes to the Internet DOS attacks SQL Slammer Nimda 4

5 TCP attacks Since BGP uses TCP for peering, BGP is sensitive to TCP attacks. RST injection causes peering to terminate SYN floods may cause denial-of service due to overload TCP sequence prediction attack Guessing next sequence can be used to inject false data 5

6 Protecting peering relationships Attack a peering relation by bringing it down or adding false information. Bringing down a peering causes all prefixes of that peering to be withdrawn - and then re-announced when peering comes up Filtering (verify remote peer addresses) Reverse path filtering Dont announce core prefixes (bad for diagnostics) MD5 authentication (For underlying TCP) See earlier lecture BGP over IPsec (including encryption) General solid method for IP-layer security Generalized TTL security mechanism Practical BGP: pages

7 Generalized TTL security mechanism BGP peering is via TCP/IP Limit the range from where peerings can be made Set TTL to 255 Only accept IP packets with TTL 255/254. Attacks from several hops away cannot be made Problem: multi-hop peering 7

8 Indirect attacks Since the BGP peering runs on the same link as the data, an overloaded link may bring the BGP peering down. Examples where this has happened: SQL Slammer Nimda Large-scale DOS attacks One can also send large number of packets to the controlplane (see next slide) Packets directed at the route processor eg terminating traffic (destined to router) Packets of novel functionality handled by RP only (eg IPv6) You need to filter traffic to the RP rate-limit and identify which traffic the router requires e.g.: ssh/bgp/is-is Set firewall-filters for terminating traffic 8

9 Fast path, slow path (revisited) Control Processor CPU Memory Routing Table Slow path Line Card Line Card Fast path Line Card Line Card Fast path If line cards can determine outgoing port Slow path Control processor must determine outgoing port 9

10 Protection by route filtering Typically at the edges Never run your internal routing protocol on interfaces where there may be external nodes So that the IGP may not be compromised by false routes Egress filtering Do not give transit by mistake Ingress filtering Check validity of received routes Check with registries (eg RIPE) (But these are not always updated) Combine with traffic filters (ACLs) Only accept packets with source addresses matching the announced prefixes 10

11 Preventing spoofing at the edges Attacker spoofs source address to stage DoS attack Can be prevented by RPF check sources must match announced networks Problem: dual homed networks ebgp announces: / Attacker spoofs source to ebgp announces: / Practical BGP: pages

12 Securing routing information within BGP But suppose a BGP router has been taken over by an attacker How do you protect against falsified BGP information? BGP relies on mutual and 'transitive' trust Attack forms: Blackholing (malicious) Announce prefix to attack traffic and then drop it Redirection Traffic to a destination is redirected to another (incorrect) destination Subversion Force the traffic to pass through a specific link to eavesdrop or modify data, but reaches the original destination Instability Successive adverisement, withdrawals => trigger route flap damping Practical BGP: pages Beware of BGP attacks 12

13 Attack method: prefix hijacking Announce false updates Claim reachability of a prefix it does not have Claim it owns (originates) a prefix it does not own Multiple Origin AS (MOAS) Prefix hijacking is limited by the connectivity and locality of the compromised router 13

14 Example: prefix hijacking A claims reachability to AS6 and ownership of prefixes of AS6, but cannot affect routers in AS4 and AS6 (and AS5 and AS3 to a certain degree) AS1 AS2 A AS3 AS4 AS5 AS6 14

15 Other attack methods De-aggregation Spread false updates more effectively since more specific prefixes can be announced which over-rule the original prefix Contradictory advertisement AS-path prepending is a valid variant of this But an attacker may force traffic to go backup paths, for example Update modifications General changes to updates passing through the compromised router Link flapping and instability 15

16 What do you need to protect? Original data: Address blocks AS numbers Path data: (Transitive) path attributes Originating addresses Who owns the original address block? It has been allocated by registries according to IANA/RIR hierarchy Route announcements Uses transitive trust - even though you trust your neighbour, do you trust your neighbour's neighbour? Policies Higher level relations between AS:s: Transit/customer/stub relations? 16

17 Proposals? There are several proposals to make certain that the data in BGP announcements are correct Many proposals Secure BGP (S-BGP) Secure Origin BGP (sobgp) Interdomain Routing Validation(IRV) The truth is nothing is in place IETF has started a new working group SIDR (Secure InterDomain Routing) to try and vitilize the effort. 17

18 Fundamentals Fundamental research problems How do you use the infra-structure for infra-structure security? How do you deploy a new solution? Current approaches identify 'good' routes, everything else is 'bad' But in a partial deployment (BGP relies on partial deployments), you need to discrimante between 'bad' from 'unknown' otherwise 'unknown' will be dropped / 'bad' routes accepted valid unknown invalid 18

19 RPKI and ROAs Resource Public Key Infrastructure (RPKI) IANA->RIRs->LIRs->ISPs Resource Certificates (RC) X.509 generic certificate extended with List of address blocks List of AS numbers Route Origin Authorization (ROA) is a standardized signed object that binds an ASN with a specific set of IP address blocks. A LIR creates a ROA for the AS and blocks it owns A ROA can be validated by BGP speakers thus validating origin information But not policies, path attributes, etc. A ROA has a prefix length so that more specific blocks can not be hijacked Valid prefix matches a valid ROA Invalid prefix match a ROA but ASN does not match. Or less specific ROA match with prefix-length set Unknown prefix does not match any ROA, or matches a less specific ROA with no prefix-length set 19

20 Securing route propagation Even if the origin information is verified, the path attributes and announcements may be modified in trabnsit, or falsely announced. The path attributes are 'chained', each AS makes successive adjustments, primarily to the AS-PATH How do you secure this 'chain' of object manipulations? Example: Are all AS:s in the path valid? Are all AS adjacencies in the path valid? Does the AS-PATH represent the actual propagation of the route object? Each BGP speaker needs to sign their updates RPKI/ROA origin AS... AS invalid 20

21 BGP security Attacks on BGP are attacks against infra-structure Attacks against single customers Indirect attacks using DOS Protection of BGP peering relationship MD5/IPsec Attacks by routers already compromised Prefix hijacking, black-holing Securing the BGP information BGPsec is coming 21

Routing and router security in an operator environment

DD2495 p4 2011 Routing and router security in an operator environment Olof Hagsand KTH CSC 1 Router lab objectives A network operator (eg ISP) needs to secure itself, its customers and its neighbors from