$EPARTMENTOF#OMPUTER3CIENCEAND%NGINEERING …pdm12/cse545/slides/cse545-interdomain... ·...

CSE598K/CSE545 - Advanced Network Security - McDaniel Page

Routing Security Security Solutions

CSE598K/CSE545 - Advanced Network SecurityProf. McDaniel - Spring 2008

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

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)

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.

4


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

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


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?)

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.

8


Question?• What attacks do these measures prevent?

• If yes, how?

‣ Message replay

‣ Route replay

‣ Path forgery

‣ Path modification

‣ Forged route withdrawal

‣ Prefix hijacking

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

10


Peering Summary

• 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?

11

Integrity Confidentiality Replay Prevention DOS PreventionIPsec (ESP) yes yes yes yesIPsec (AH) yes no yes yesMD5 Integrity yes no yes noHOP Protocol yes no yes noGTSM no no no noSmith .et al. yes yes yes no


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 server12


Assignment #2 (cont.)• Transfer request:

• Transfer block:

13

Field Data Type Length (bytes)Request Type (2) integer 1

Block number unsigned long 4Block length char variable

Field Data Type Length (bytes)Request Type (1) integer 1

Filename char 128Filesize (bytes) unsigned long 4Block length unsigned short 2


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]

14


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

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

16


Route Attestations

• Signing recursively: each advertisement signs everything it receives, plus the last hop.

17

AS3AS 1 AS

5AS

2AS

4

(4, (3, (2, 1)kAS2)kAS3

)kAS4


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:

• 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 ICANN18

(p, B)kA


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

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.

20


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.

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

22


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)

23

*CISCO text in black, my text in red.


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.

24


PolicyCerts

• Pairwise signing: the topology database contains peering attestations.

25

(4, (3, (2, 1)kAS2)kAS3

)kAS4

AS3AS 1 AS

5AS

2AS

4


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)

26


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):

‣ Q1: Is Path Lengthening in soBGP but not sBGP?

‣ Q2: Is Path Shortening possible in sBGP but not soBGP?27

AS3AS 1 AS

5AS

2AS

4

(4, (3, (2, 1)kAS2)kAS3

)kAS4(4, (3, (2, 1)kAS2

)kAS3)kAS4


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

28


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)

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

30

AS2

AS3

AS1

BGP Router

IRV

IRV

IRV I R V Q u e r y


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

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.

32

$EPARTMENTOF#OMPUTER3CIENCEAND%NGINEERING …pdm12/cse545/slides/cse545-interdomain... ·...

Documents

Transcript of $EPARTMENTOF#OMPUTER3CIENCEAND%NGINEERING …pdm12/cse545/slides/cse545-interdomain... ·...