Routing Security Security Solutions

Transcription

1 Routing Security Security Solutions CSE598K/CSE545 - Advanced Network Security Prof. McDaniel - Spring 2008 Page 1 Solving BGP Security Reality: most attempts at securing BGP have been at the local level Filtering Securing BGP peering Future: a number of complex protocols have been proposed to solve some or all BGP security issue S-BGP sobgp IRV SPV We will be looking at these solutions over the next couple of lectures Page 2

2 Filtering Filtering just drops BGP message (typically advertisements) as they are passed between ASes Ingress filtering (as it is received) Egress filtering (as it is sent) Types of filtering By prefix (e.g., bogon/martian list) By path (e.g., customer advertisement of provider routes) By policy (e.g., some community strings that represent paths/policies that an AS does not want to support) ISP ASes aggressively filter (the security mechanism) Page 3 Protecting Peer Communication Two routers exchanging BGP messages (in a BGP session) need to secure communication. Integrity Confidentiality? Authenticity Non-repudability? Note: This is often defined as a transport security issue, where just secure point-to-point communication is necessary. Page 4

3 MD5 A simple solution (RFC 2385) Share a private secret (e.g., password) Compute an keyed message authentication code on each TCP packet passed between the two routers Check MAC upon receipt of each packet You get Integrity Authenticity Problem: this is manual configuration, which neither scales to many routers or supports key maintenance Page 5 Generalized TTL Security Mechanism TCP time-to-live (RFC 3682) At a packets origination, the TTL is set to the maximum number of hops that the packet can traverse TTL decremented at each hop Packets are dropped when TTL goes to 0 This ensures that packets stuck in transient routing loops do not congest the network Idea: can we use the TTL to ensure that every packet received can from peer (assuming one hop)? Set TTL = 255 (Q: how about TTL=1?) Receiver checks TTL on all packets, if not 254, then forged Issue: how much does this really tell you? Page 6

4 HOP Integrity HOP integrity protocols implement peering secure communication that provides integrity/authentication Diffie-Hellman style key negotiation, data integrity, data authentication Idea: provide public key based per hop security, the simple constructions to enforce integrity constraints Two protocols Weak - just per hop integrity (MAC) Strong - adds replay protection (sequence numbers) Note: used to secure communication between a range of peers via a per-hop security (limitation?) Page 7 Smith/Garcia-Luna-Aceves A (ad hoc?) suite of countermeasures 1. Encrypt all messages between peers 2. Add a message sequence number to all BGP messages Protects against replayed or deleted messages 3. Add a sequence number (or time-stamps) to UPDATES 4. Add a PREDECESSOR path attribute 5. Digitally sign all the UPDATEs Note: this gets beyond the basic peer security, and bleeds into the more general BGP security issues. Page 8

5 Question? What attacks do these measures prevent? If yes, how? Message replay Route replay Path forgery Path modification Forged route withdrawal Prefix hijacking Page 9 IPsec IPsec provides all of the basic guarantees needed to implement router-to-router BGP security Independent of intermediate connectivity IKE/ISAKMP used to establish transient keys Avoids cryptanalysis of long running keys ESP/AH provide confidentiality, integrity, replay protection... Problems: this is just a start Overheads can be expensive if not managed correctly Backward compatibility Key management Page 10

6 Peering Summary Integrity Confidentiality Replay Prevention DOS Prevention IPsec (ESP) yes yes yes yes IPsec (AH) yes no yes yes MD5 Integrity yes no yes no HOP Protocol yes no yes no GTSM no no no no Smith.et al. yes yes yes no Reality: most of these schemes were hacks or stop-gap measures until IPsec became widely available Where secured at all, IPsec is generally used AH/ESP w/out confidentiality is popular Singly-homed customer/isp peering is often not secured at all Question: why is this reasonable? Page 11 Assignment #2 Each of you is to implement a client/server file transfer application on OpenSSL in C. The client will send files. The server will receive files (on port 5005). The client will send an initial transfer request, followed by blocks of the file. Startup:./assignment2 [server] [filename] [block length] Part 1: run over unsecured connection Part 2: run over secured connection Use your own certificates for client and server Page 12

7 Assignment #2 (cont.) Transfer request: Field Data Type Length (bytes) Request Type (1) integer 1 Filename char 128 Filesize (bytes) unsigned long 4 Block length unsigned short 2 Transfer block: Field Data Type Length (bytes) Request Type (2) integer 1 Block number unsigned long 4 Block length char variable Page 13 BGP Security Protocols The big two, plus one (self-serving) sbgp (Secure Border Gateway Protocol) [Kent et al. 99] sobgp (Secure Origin BGP) [White et al. 03] IRV (Internet Routing Validation) [Goodell et al. 03] Page 14

8 sbgp sbgp was the first leading candidate for routing security, and highlighted much of IR security issues Still under consideration, but somewhat limited Model: Routing and origination announcements are signed signatures are validated based on shared trust associations (CAs) It all begins with the keys (really two parallel PKIs) 1. Binding routers and organizations to ASes. 2. Origin authentication PKI Page 15 Organization PKI Keys for routers, AS numbers Route attestations - attestations to the transient state of the network, e.g., the advertisements/routes Keys used to create these advertisements Router certificates need to ascertain validity of instantaneous advertisements. You need to prove association between the network elements making statements and AS/organizations Page 16

9 Route Attestations AS 1 AS 2 AS 3 AS 4 AS 5 Signing recursively: each advertisement signs everything it receives, plus the last hop. (4, (3, (2, 1) kas2 ) kas3 ) kas4 Page 17 Address Attestations Attestations of ownership and delegation very similar to that observed in origin authentication These are the simple attestations For example, assume that organization A delegates prefix p to organization B: (p, B) ka Note: (surprisingly) sbgp distributes with address attestations out-of-band Thus everyone is required to obtain and validate their own copies of origin/ownership proving certificates. As in OA, validate path to ICANN Page 18

10 sbgp Issues Single point of trust: is an authority that everyone will trust to provide address/path certification? Chinese Military vs. NSA? Cost: validating signatures is very computationally expensive Can a router sustain the load? Incremental deployability: requires changes to BGP message formats All implementations must change Page 19 sobgp CISCO s entry in the securing Internet routing rodeo Viewed as the manufacturer approach to implementing security within BGP Released as a kind of refutation of sbgp, which was seen as too expensive and unwieldy to be practical. A more open model that allows providers to implement security much more flexibly, i.e., within the confines of existing policy and infrastructure Basic approach: network providers themselves act as a joint authority, and issue certificates for all relevant routing data, e.g., policy, address management, paths. Page 20

11 sobgp Design Requirements System should take advantage of operational experience and existing Internet Architecture. Implicit trust built into the Internet IP address assignment and delegation system Minimize impact to current implementations of the BGP protocol Minimum changes to existing protocol formats. Optimize memory and processing requirements. Page 21 sobgp Design Requirements Must not rely on a central authority of any type. Distributed processing and trust Must be incrementally deployable (it must provide some level of security without the participation of every AS). Page 22

12 Solution* Verifies originator of a route is authorized to do so. Verifies that the advertised AS_PATH represents a valid path to the originator. (plausible path?) BGP Security Message (extension to BGP) New BGP Message used to carry security information No changes to existing messages for backwards compatibility and incremental deployment. (removal of messages?) Leverages existing protocol and security mechanisms Fixed additional scalability requirements Per-AS information and route policies advertised once. (caching) No additional information in UPDATES, resulting in low processing impact. (well, sort of) *CISCO text in black, my text in red. Page 23 Certificates Databases of certificates that advertise and correlate AS identity, prefix ownership and route policy. Certificate types: Entity Certificate = Used to establish (AS) identity Authorization Certificate = Assigns/delegates IP addresses Policy Certificate = Used to define per-as or pre-prefix policies and propagate AS interconnectivity topology map Certificate exchanges/trust relations are not defined Prior to or within routing exchanges Uses Web-of-Trust model to validate certificates. Page 24

13 PolicyCerts AS 1 AS 2 AS 3 AS 4 AS 5 Pairwise signing: the topology database contains peering attestations. (4, (3, (2, 1) kas2 ) kas3 ) kas4 Page 25 AuthCert and EntityCert AuthCerts define the delegation of address space Operates in essentially the same way as sbgp/oa Some looked at OA in sobgp and looked to learn the correct address assignment by viewing history Kinda intrusion detection for address usage (open problem) EntityCerts identifies who/what router is associated with which AS. Again note: which of these certs you believe is up to you (its a web of trust, caveat emptor) Page 26

14 Path Authentication vs. Path Plausibility Is Path Authentication stronger than Path Plausibility? Since each AS in sbgp is authentication a relationship between itself and its predecessor and successor ASes, the set of acceptable AS paths in sbgp is a subset of the set paths acceptable under SoBGP Argue for (and explain why or why not): AS 1 AS 2 AS 3 AS 4 AS 5 (4, (3, (2, 1) kas2 ) kas3 ) kas4 (4, (3, (2, 1) kas2 ) kas3 ) kas4 Q1: Is Path Lengthening in sobgp but not sbgp? Q2: Is Path Shortening possible in sbgp but not sobgp? Page 27 sobgp Issues Soft security: the guarantees provided are limited E.g., plausible, not actual secure paths Nebulus trust: not clear under what conditions or trust model a certificate was created Signatures in web of trust have unclear semantics Assumes transitive trust Page 28

15 IRV Intended to solve BGP without changing any of existing routing infrastructure [Goodell et al. 2003] Idea: validate all information by actively querying databases of policy, address, and path information provided by Post-facto verification - receive and optimistically accept routing information AS-centralized verification - an IRV service exists outside the domain of the AS, provides validation information in real time to all routers (win--no per router cost) Page 29 IRV Operation ASes provide a well-known IRV server from which any external party can query for the validity of information Authenticated responses provide assurance that advertisements are correct BGP Router IRV AS1 IRV I R V Q u e r y IRV AS2 AS3 Page 30

16 IRV Issues DOS opportunities - IRV can get flooded with requests by malicious party Under normal operation following, for example, a table reset. Offline operation - when the network fails, little ability to return system to stable state Possible solutions: Peering repositories Shadow control network Page 31 BGP Security Now: After a decade of work, we are not much closer to a global security solution that we started with Problems are often not technical... Cost of building routers Backward compatibility Incremental deployment Future: we will move from a border filtering to more and more cryptographically aided solutions. Mining past advertisements and understanding expected routing advertisements will also be key where crypto is not appropriate or feasible. Page 32