Internet routing cos 598a today routing protocol security
Download
1 / 31

Internet Routing (COS 598A) Today: Routing Protocol Security - PowerPoint PPT Presentation


  • 152 Views
  • Uploaded on

Internet Routing (COS 598A) Today: Routing Protocol Security. Jennifer Rexford http://www.cs.princeton.edu/~jrex/teaching/spring2005 Tuesdays/Thursdays 11:00am-12:20pm. Course Projects. Report (May 10, end of day) Ten pages (11pt, double-spaced, single column)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Internet Routing (COS 598A) Today: Routing Protocol Security' - freja


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Internet routing cos 598a today routing protocol security l.jpg

Internet Routing (COS 598A)Today: Routing Protocol Security

Jennifer Rexford

http://www.cs.princeton.edu/~jrex/teaching/spring2005

Tuesdays/Thursdays 11:00am-12:20pm


Course projects l.jpg
Course Projects

  • Report (May 10, end of day)

    • Ten pages (11pt, double-spaced, single column)

    • Like the 6-pagers (two-column) we’ve read

    • Include discussion of related work and evaluation results (or plan for how to do an evaluation)

  • Presentation (May 16, 1:30pm, room 302)

    • 15 minutes (20 minutes for two-person projects)

    • Allow a few minutes at the end for questions

    • Consider giving a practice talk to someone

  • Advice is free

    • See Web site for guidelines on papers and talks

    • Feel free to bounce a draft or outline by me


Outline l.jpg
Outline

  • Security goals for BGP

  • Security limitations of BGP, and protection

    • IP address blocks

    • TCP sessions

    • BGP route attributes

  • Proposed enhancements to BGP

    • A three-slide introduction to PKI

    • Secure origin BGP (So-BGP)

    • Secure BGP (S-BGP)

    • Research proposals (e.g., SPV, Whisper, and IRV)


Security goals for bgp l.jpg
Security Goals for BGP

  • Secure message exchange between neighbors

    • Confidential BGP message exchange

      • Can two ASes exchange messages without someone watching?

    • No denial of service

      • Prevent CPU overload, session reset, and tampered BGP messages?

  • Validity of the routing information

    • Origin authentication

      • Is the prefix owned by the AS announcing it?

    • AS path authentication

      • Is the AS path the sequence of ASes the BGP update traversed?

    • AS path policy

      • Does the AS path adhere to the routing policies of each AS?

  • Correspondence to the data path

    • Does the traffic follow the advertised AS path?


Ip address ownership l.jpg
IP Address Ownership

  • IP address block assignment

    • Regional Internet Registries (ARIN, RIPE, APNIC)

    • Internet Service Providers

  • Proper origination of a prefix into BGP

    • By the AS who owns the prefix

    • … or, by its upstream provider(s) in its behalf

  • However, what’s to stop someone else?

    • Prefix hijacking: another AS originates the prefix

    • BGP does not verify that the AS is authorized

    • Registries of prefix ownership are inaccurate


Address ownership prefix hijacking l.jpg

4

3

5

2

6

7

1

Address Ownership: Prefix Hijacking

  • Consequences for the affected ASes

    • Blackhole: data traffic is discarded

    • Snooping: data traffic is inspected, and then redirected

    • Impersonation: data traffic is sent to bogus destinations

12.34.0.0/16

12.34.0.0/16


Address ownership hijacking is hard to debug l.jpg
Address Ownership: Hijacking is Hard to Debug

  • Real origin AS doesn’t see the problem

    • Picks its own route

    • Might not even learn the bogus route

  • May not cause loss of connectivity

    • E.g., if the bogus AS snoops and redirects

    • … then may only cause performance degradation

  • Or, loss of connectivity is isolated

    • E.g., only for sources in parts of the Internet

  • Diagnosing prefix hijacking

    • Analyzing BGP updates from many vantage points

    • Launching traceroute from many vantage points


Address ownership hijacking deaggregation l.jpg

4

3

5

2

6

7

1

Address Ownership: Hijacking & Deaggregation

  • Originating a more-specific prefix

    • Every AS picks the bogus route for that prefix

    • Traffic follows the longest matching prefix

12.34.0.0/16

12.34.158.0/24


Address ownership how to hijack a prefix l.jpg
Address Ownership: How to Hijack a Prefix

  • The hijacking AS has

    • Router with eBGP session(s)

    • Configured to originate the prefix

  • Getting access to the router

    • Network operator makes configuration mistake

    • Disgruntled operator launches an attack

    • Outsider breaks in to the router and reconfigures

  • Getting other ASes to believe the bogus route

    • Neighbor ASes not filtering the routes

    • … e.g., by allowing only expected prefixes

    • But, specifying filters on peering links is hard


Tcp connection underlying bgp session l.jpg
TCP Connection Underlying BGP Session

  • BGP session runs over TCP

    • TCP connection between neighboring routers

    • BGP messages sent over TCP connection

    • Makes BGP vulnerable to attacks on TCP

  • Main kinds of attacks

    • Against confidentiality: eavesdropping

    • Against integrity: tampering

    • Against performance: denial-of-service

  • Main defenses

    • Message authentication or encryption

    • Limiting access to physical path between routers

    • Defensive filtering to block unexpected packets


Tcp connection attacks against confidentiality l.jpg
TCP Connection: Attacks Against Confidentiality

  • Eavesdropping

    • Monitoring the messages on the BGP session

    • … by tapping the link(s) between the neighbors

  • Reveals sensitive information

    • Inference of business relationships

    • Analysis of network stability

  • Reasons why it may be hard

    • Challenging to tap the link

      • Often, eBGP session traverses just one link

      • … and may be hard to get access to tap it

    • Encryption may obscure message contents

      • BGP neighbors may run BGP over IPSec

BGP session

physical link


Tcp connection attacking message integrity l.jpg
TCP Connection: Attacking Message Integrity

  • Tampering

    • Man-in-the-middle tampers with the messages

    • Insert, delete, modify, or replay messages

  • Leads to incorrect BGP behavior

    • Delete: neighbor doesn’t learn the new route

    • Insert/modify/replay: neighbor learns bogus route

  • Reasons why it may be hard

    • Getting in-between the two routers is hard

    • Use of authentication (signatures) or encryption

    • Spoofing TCP packets the right way is hard

      • Getting past source-address packet filters

      • Generating the right TCP sequence number


Tcp connection denial of service attacks l.jpg
TCP Connection: Denial-of-Service Attacks

  • Third party sends bogus TCP packets

    • FIN/RST to close the session

    • SYN flooding to overload the router

  • Leads to disruptions in BGP

    • Session resets, causing transient routing changes

    • Route-flapping, which may trigger flap damping

  • Reasons why it may be hard

    • Spoofing TCP packets the right way is hard

      • Difficult to send FIN/RST with the right TCP header

    • Packet filters may block the SYN flooding

      • E.g., filter packets to BGP port from unexpected source

      • … or destined to router from unexpected source


Tcp connection exploiting the ip ttl field l.jpg
TCP Connection: Exploiting the IP TTL Field

  • BGP speakers are usually one hop apart

    • To thwart an attacker, can check that the packets carrying the BGP message have not traveled far

  • IP Time-to-Live (TTL) field

    • Decremented once per hop

    • Avoids packets staying in network forever

  • Generalized TTL Security Mechanism (RFC 3682)

    • Send BGP packets with initial TTL of 255

    • Receiving BGP speaker checks that TTL is 254

    • … and flags and/or discards the packet others

  • Hard for third-party to inject packets remotely


Bgp message attributes l.jpg
BGP Message Attributes

  • BGP route attributes

    • AS path (and the resulting AS path length)

    • MED, origin type, next-hop, communities, etc.

  • Main kinds of attacks

    • Bogus path: AS path that does not exist

    • Invalid path: AS path that violates routing policy

    • Missing/inconsistent routes: violating peering agreement

    • Bogus attributes: unexpected MED, origin, etc.

  • Main defenses

    • Route filtering based on ASes in AS path

    • Resetting attributes to default/expected values

    • Collecting and analyzing measurement data


Bgp attributes bogus paths l.jpg
BGP Attributes: Bogus Paths

  • AS tampers with AS path

    • Deletes ASes from the AS path

    • Prepends with a bogus AS number

  • Goal: influence the path-selection process

    • Attract data traffic to the route

      • E.g., by making AS path look shorter

      • E.g., delete AS that might trigger route filtering

    • Create blackholes for parts of the Internet

      • E.g., prepend bogus AS to trigger loop detection

  • Very hard to defend against these attacks

    • How can you tell that the route is bogus?


Bgp attributes invalid paths l.jpg
BGP Attributes: Invalid Paths

  • AS exports a route it shouldn’t

    • AS path is a valid sequence, but violated policy

  • Example: customer misconfiguration

    • Exports routes from one provider to another

  • … interacts with provider policy

    • Provider prefers routes learned from customers

    • … so provider picks these as the best route

  • … leading the dire consequences

    • E.g., directing all Internet traffic through customer

  • Main defense

    • Filtering routes based on prefixes and AS path

BGP

data


Bgp attributes missing inconsistent routes l.jpg
BGP Attributes: Missing/Inconsistent Routes

  • Peering agreements require consistent export

    • Prefix advertised at all peering points

    • Prefix advertised with same AS path length

  • Reasons for violating the policy

    • Trick neighbor into “cold potato”

    • Configuration mistake

  • Main defense

    • Analyzing BGP updates

    • … or data traffic

    • … for signs of inconsistency

dest

Bad AS

BGP

data

src

http://www.cs.princeton.edu/~jrex/papers/imc04.pdf


Bgp attributes bogus attributes l.jpg
BGP Attributes: Bogus Attributes

  • BGP neighbor (mis)assigning attributes

    • With the goal of misleading the neighbor

    • … to affect how data packets are forwarded

  • Examples

    • MED: trick neighbor to cold-potato routing

    • Origin type: trick neighbor to (dis)favor route

    • Next-hop: trick neighbor to forward wrong way

  • Main defense

    • Resetting attributes to default value

    • E.g., set MED to zero on all sessions

    • E.g., set next-hop to the peer’s IP address


Bgp security today l.jpg
BGP Security Today

  • Applying best common practices (BCPs)

    • Securing the session (authentication, encryption)

    • Filtering routes by prefix and AS path

    • Resetting attributes to default values

    • Packet filters to block unexpected control traffic

  • This is not good enough

    • Depends on vigilant application of BCPs

      • … and not making configuration mistakes!

    • Doesn’t address fundamental problems

      • Can’t tell who owns the IP address block

      • Can’t tell if the AS path is bogus or invalid

      • Can’t be sure the data packets follow the chosen route



Encrypting and decrypting with keys l.jpg
Encrypting and Decrypting With Keys

  • Encrypt to hide message contents

    • Transforming message contents with a key

    • Message cannot be read without the right key

  • Symmetric key cryptography

    • Same secret key for encrypting and decrypting

    • … makes it hard to distribute the secret key

  • Asymmetrical (or public key) cryptography

    • Sender uses public key to encrypt message

      • Can be distributed freely!

    • Receiver uses private key to decrypt message


Authenticating the sender and contents l.jpg
Authenticating the Sender and Contents

  • Digital signature for authentication

    • Data attached to the original message

      • … to identify sender and detect tampering

    • Sender encrypts message digest with private key

    • Receiver decrypts message digest with public key

      • … and compares with message digest it computes

  • Certificate

    • Collection of information about a person or thing

      • ... with a digital signature attached

    • A trusted third party attaches the signature


Public key infrastructure pki l.jpg
Public Key Infrastructure (PKI)

  • Problem: getting the right key

    • How do you find out someone’s public key?

    • How do you know it isn’t someone else’s key?

  • Certificate Authority (CA)

    • Bob takes public key and identifies himself to CA

    • CA signs Bob’s public key with digital signature to create a certificate

    • Alice can get Bob’s key and verify the certificate with the CA

  • Register once, communicate everywhere

    • Each user only has the CA certify his key

    • Each user only needs to know the CA’s public key


Secure origin bgp sobgp l.jpg
Secure Origin BGP (soBGP)

  • Design requirements

    • Incrementally deployable

    • Distributed Web of trust

    • Scalability by advertising security info only once

    • Trade-off level of security vs. convergence speed

  • Verify the AS path is not bogus

    • Verify the origin AS is authorized to originate

    • Verify the AS path is a valid path to origin AS

  • BGP Security message

    • Security information carried inside the protocol

    • New message; no changes to existing messages


Certificates in secure origin bgp sobgp l.jpg
Certificates in Secure Origin BGP (soBGP)

  • Entity: establish identity of the AS

    • Public key for the AS, and the AS number itself

    • Signature created using the AS’s private key

  • Authentication: assign/delegate address space

    • Address ranges an AS can advertise, and the AS number

    • AS validating that the AS can advertise

      • E.g., AS owning 10.0.0.0/8 can validate another for 10.1.1.0/24

    • Signature created by the validating AS’s private key

  • Policy: define policies and connectivity

    • A list of ASes that an AS attaches to

    • Routing policies applied by the AS

    • Signature created using the AS’s private key


Using sobgp l.jpg
Using soBGP

  • Upon receiving a BGP advertisement

    • Can validate information in the BGP updates

    • … using information in PolicyCerts and AuthCerts

  • Obtaining the certificates

    • From new BGP Security message type

    • Gathered from well-known Web site

      • Though you have to be able to route to the Web site!

  • Flexible processing order

    • Fast convergence: route handling 1st, security 2nd

    • High security: security 1st, during route handling


Pros and cons of sobgp l.jpg
Pros and Cons of soBGP

  • Advantages

    • Provides origin authentication

    • Incrementally deployable

    • Doesn’t interfere with BGP message processing

  • Disadvantages

    • Path authentication requires a topology database

    • Policy checking requires a policy database

    • Doesn’t ensure the data path follows the BGP path

      • Though, in fairness, this is true for all of the proposals


Secure bgp s bgp l.jpg
Secure BGP (S-BGP)

  • Address attestations

    • Claim the right to originate a prefix

    • Signed and distributed out-of-band

    • Checked through delegation chain from ICANN

  • Route attestations

    • Distributed as an attribute in BGP update message

    • Signed by each AS as route traverses the network

    • Signature signs previously attached signatures

  • S-BGP can validate

    • AS path indicates the order ASes were traversed

    • No intermediate ASes were added or removed

  • But, the cryptography is very heavy-weight

    • … and sBGP is less incrementally deployable than soBGP


Current status l.jpg
Current Status

  • IETF proposals

    • soBGP: relatively new, in the last couple of years

    • sBGP: worked on for much longer

  • Active research area

    • Secure Path Vector: lower crypto complexity

    • Whisper: detect (and hopefully diagnose) inconsistencies without using a PKI

    • Interdomain Route Validation: separate server per AS for validating BGP information

    • … <your proposal here>


Next time overlay services l.jpg
Next Time: Overlay Services

  • Two papers

    • “Resilient Overlay Networks”

    • “On Selfish Routing in Internet-Like Environments”

  • Review just of second paper

    • Summary

    • Why accept

    • Why reject

    • Avenues for future work

  • Optional

    • “A System for Authenticated Policy-Compliant Routing” (Bonus points: Why is it called Platypus?)