accountable internet protocol

49
1 Accountable Internet Protocol David Andersen, Hari Balakrishnan, Nick Feamster, Teemu Koponen, Daekyeong Moon, Scott Shenker Carnegie Mellon University, MIT, Georgia Tech, ICSI & HIIT, University of California, Berkeley Presented by Young-Rae Kim and PierreElie Fauche April 30, 2009 CS540, KAIST

Upload: sauda

Post on 27-Jan-2016

20 views

Category:

Documents


1 download

DESCRIPTION

CS540, KAIST. April 30, 2009. Accountable Internet Protocol. David Andersen, Hari Balakrishnan, Nick Feamster, Teemu Koponen, Daekyeong Moon, Scott Shenker Carnegie Mellon University, MIT, Georgia Tech, ICSI & HIIT, University of California, Berkeley. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Accountable Internet Protocol

1

Accountable Internet Protocol

David Andersen, Hari Balakrishnan, Nick Feamster,Teemu Koponen, Daekyeong Moon, Scott Shenker

Carnegie Mellon University, MIT, Georgia Tech, ICSI & HIIT, University of California, Berkeley

Presented by Young-Rae Kim and PierreElie Fauche

April 30, 2009CS540, KAIST

Page 2: Accountable Internet Protocol

2

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 3: Accountable Internet Protocol

3

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 4: Accountable Internet Protocol

4

Vulnerabilities of IP• Hijacked routes• Untraceable spam• Denial-of-service attacks• Source address spoofing• Malicious or compromised

hosts

Fundamental problemaccountability is not intrinsic to current Internet architecture

• For each problem, point solutions

• Complicated mechanisms• External source of trust• Operator vigilance

Page 5: Accountable Internet Protocol

5

Introduction• What changes to the architecture would provide a firmer foundation for IP-layer security?

• Many of the vulnerabilities are due to lack of accountability

• Internet has no fundamental ability to associate an action with the responsible entity

Solutionreplace IP with AIP

Page 6: Accountable Internet Protocol

6

Accountability• “Real-world security depends on accountability…”

• Same for the Internet

• Accountable Internet Protocol (AIP)

• Clean slate replacement of IP

• Self-certifying addresses for domains and hosts

• Independent of global trusted authority

Page 7: Accountable Internet Protocol

7

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 8: Accountable Internet Protocol

8

Structure of an Address

• Addressing structure: 2 or more levels of flat addressing within AD

• Closer to Internet’s original incarnation than CIDR–based

• Carefree attitude toward scaling

• Self-certifying addresses for domains and hosts

• Includes imposter detection mechanisms to deal with key compromises

• Consider long-term technology trends

Page 9: Accountable Internet Protocol

9

ADa

ADe

‣ Address structure:‣ Accountability domains

(AD)‣ End-point identifier (EID)

‣ AD corresponds to BGP prefix

‣ Allows hierarchical organization

ADb ADc

ADa:ADb:EID1ADa:ADc:EID2

ADe:EID9

Structure of an Address

Page 10: Accountable Internet Protocol

10

SELF-CERTIFYING ADDRESSES

• Name of object is public key (or hash) of object

• AD is hash of public key of domain• EID is hash of public key of host

AD EID

(Domain Data, )Public

(Host Data, )Public

Hash Function(SHA-1)

Hash Function(SHA-1)

Page 11: Accountable Internet Protocol

11

SELF-CERTIFYING ADDRESS:

AN EXAMPLE

/sfs/sfs.lcs.mit.edu:vefvsv5wd4hz9isc3rb2x648ish742hy/pub/links/sfscvs

LocationHostID (specifies public key)Path on remote server

- In [MAZ99]No one controls the global namespaceHostID =

SHA-1(“HostInfo, Location, Public Key, “HostInfo, Location, Public Key)

[MAZ99]: Mazieres, D., et al. Separating key management from file system security. SOSP, 1999.

Page 12: Accountable Internet Protocol

12

AIP PACKET HEADERVers(4)

... standard IP headers ...

random pkt id(32)

#dests(4)

next-dest(4)

#srcs(4)

Source EID (160 bits)

Source AD (top-level) (160 bits)

Dest EID (160 bits)

Dest AD (next hop) (160 bits)

Dest AD stack (N*160 bits)

Source AD stack (M*160 bits)

Page 13: Accountable Internet Protocol

13

ROUTING

vers

... standard IP headers ...

random packet id 2 1

EID9

ADe

EID1

ADa

ADb

ADe

ADe

ADa

ADb

ADa:ADb:EID1

ADe:EID9

ADy

ADx

ADa

10

ADb

Source EID

Source AD

Dest EID

Next Hop AD

Dest stack: 0

Dest stack: 1

Source stack: 0

• Until packet reaches destination AD, intermediate routers use only destination AD to forward packet

• Upon reaching destination AD, forward based on EID

#dests

next-dest

#srcs

Page 14: Accountable Internet Protocol

14

ROUTING- BGP advertisements are for Ads- AIP routing tables map AD numbers to “next

hop” locations- Routers should also use interior routing protocol to maintain routes to EIDs

- AIP supports notion of autonomous system- Organizations might not want to advertise

internal AD structure- BGP Path descriptors don’t have to include

EIDs, also are 160-bit self-certifying AIP addresses.

Page 15: Accountable Internet Protocol

15

DNS & MOBILITY

- DNS would include an AIP-record with AIP addresses for each hostname in domain

- AIP requires a secure DNS variant to prevent unauthorized DNS modifications

- Mobility support based on self-certifying EID- Mobility transport protocols can bind to EIDs

while hosts roam between Ads- Self-certificates allow for dynamic DNS update

Page 16: Accountable Internet Protocol

16

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 17: Accountable Internet Protocol

17

Source Accountability

• Source spoofing

• a host claim to be another host

• Address minting

• a host invents new identities

‣ AIP requires no configuration or interaction by operators or end-users

Page 18: Accountable Internet Protocol

18

Source Spoofing

• AIP extends uRPF (unicast Reverse Path Forwarding)

• Automatic filtering mechanism that accepts packets only if route to packet’s source address points to same interface on which packet arrived

• Aims to protect against

- host using a spoofed address at which it can’t receive packets

- malicious or compromised host using spoofed address at which it can receive packets

Page 19: Accountable Internet Protocol

19

General Mechanism

•A router verifies that the previous hop is valid

•If the verification is successful, next packets are forwarded

•Otherwise, next packets are droped

Page 20: Accountable Internet Protocol

20

EID verification

Drop packetsend V to

source

Receive packet

source AD:X

In acce

pt cache?

Forward packet

yes

no

in first hop router

Receive Vverify

?

Add source to accept cache

Ignore

yes

no

Page 21: Accountable Internet Protocol

21

AD verification

Receive packet

source AD:X

In accept cache?

Forward packet

Trust neighboring

AD?

Drop packetsend V to

sourcePass uRPF?

Page 22: Accountable Internet Protocol

22

Verification Packet• Router sends to Source a packet V containing:

- source & destination addresses of packet P

- hash of packet P- interface of Router

• Content is signed by R using a secret

• Source signs V with its private key and send it back

• R verifies if both keys match

• If they match, R add S to its cache

Page 23: Accountable Internet Protocol

23

Verification Packet• R drops unverified packets so S must re-send P

• Hosts must not sign a verification packet V for a packet P they did not send

‣ hosts keep the hashes of recently sent packets to compare with the hash contained in V

• Requires implementation in network switches for full protection

Page 24: Accountable Internet Protocol

24

Accept Cache• Accept cache only contains entries for ADs that do not pass uRPF checks or for sources coming from untrusted domains

• Routers bound size of accept cache by upgrading to an AD-wildcard “AD:*” if threshold T is reached for that particular AD

• Limited number of new announcements (address minting)

- EID limiting AD limiting

Page 25: Accountable Internet Protocol

25

Shut-off Protocol

• Defend against DoS attack

• Requires smart Network Interface Card (smart-NIC) to suppress the flood

‣ well-intentioned owner

• All hosts cache the hashes of recently sent packets

Page 26: Accountable Internet Protocol

26

Shut-off illustratedZombie Victim

TTL, H<P>

• Victim sends a Shut-Off Packet (SOP) to the zombie‣ SOP contains the hash of a recent flooding packet, a TTL (shut-

off duration), all signed by the victim

• Zombie checks that he has sent the packet P to the Victim and shuts off

Page 27: Accountable Internet Protocol

27

Securing BGP- AIP could simplify task of deploying mechanisms similar to SBGP

- No need for external trusted registries (public keys)

- Uses mechanisms similar to S-BGP- Operators configure a BGP peering session

- BGP routers sign their routing announcements

- Each router must be able to find public key to corresponding AD

Page 28: Accountable Internet Protocol

28

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 29: Accountable Internet Protocol

29

CRYPTOGRAPHY

• Cryptographic algorithm compromise

• Versioning address to support phasing new algorithms

• Two or three crypto versions will be present on network at any given time

• Key discoveryIndividual key compromise

As with any system relying on public key cryptography, AIP faces three general problems:

Page 30: Accountable Internet Protocol

30

KEY DISCOVERY

• Key is automatically obtained once the address is known

• Any(secure) lookup service could be used

• Peering ADs can identify each other out-of-band for initial setup

Page 31: Accountable Internet Protocol

31

KEY COMPROMISE

Protecting against compromise

Detecting compromise

Dealing with compromise

Page 32: Accountable Internet Protocol

32

KEY COMPROMISE

Protecting against compromise

Detecting compromise

Dealing with compromise

Protecting against compromise

Dealing with compromise

• Domains/hosts should follow establish policies

• Hardware solutions may assist

• If host key is compromised, adopt new key and publish it into DNS record (might involve out-of-band mechanism)

• If domain key is compromised, revoke it through interdomain routing protocol and via public registries

• Key revocation must propagate down every path that carries route for AD

Relatively straightforward• How to detect when attacker is

impersonating a victim? (stolen private key)

• Answer: maintain a public registry of peers for each AD and ADs to which each EID bound

• Registry only stores self-certifying data

• No need for central authority to verify correctness of content

• Registry can be populated mechanistically by entities involved (no operator vigilance)

Detecting compromise

Page 33: Accountable Internet Protocol

33

COMPROMISE DETECTION- Public registry- No need of central authority- No need of human intervention- Global registries and per-domain registries- Stored in the per-domain registry:

- Peering AD’s- EID public key and hash- Routers used by the EID

- Stored in the global registry:- List of all AD’s an EID belongs to

Page 34: Accountable Internet Protocol

34

COMPROMISE DETECTION• Force domains to sign entries A:X before a DNS lookup

• Host:

• Check global and domain-specific registry periodically

• Domain:

• Check global registry periodically

Page 35: Accountable Internet Protocol

35

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 36: Accountable Internet Protocol

36

Growth vs Hardware• Semiconductor industry roadmap projects doubling in ~3 years

• AIP increases RIB and FIB entries from 32 bits to 160 bits

• For each AD entry, the router must store 512 bytes for its public key

• Diameter of the Internet:

- some large ASes may turn into several ADs

‣ we guess a 60% increase

Page 37: Accountable Internet Protocol

37

BGP Table Size Trends

• 17% annual growth

• 1.6M entries in 2020

Page 38: Accountable Internet Protocol

38

RIB Memory

• AIP-Diam: if AIP causes a 60% increase in the diameter of the Internet

• by 2020, memory needed by AIP will cost less than today’s IP

Page 39: Accountable Internet Protocol

39

What about speed?• Scariest challenge: Update processing

- load ~20 full tables on boot, fast

- ... and do S-BGP style crypto verification

• Limitations: Memory bandwidth, crypto CPU

- AIP memory requirements: 8.2GB; today’s memory can handle 1.7GB/s

- Without crypto, future routers could load in ~30 seconds

- With crypto, however...

Page 40: Accountable Internet Protocol

40

Crypto Overhead• Process update requires validating RSA signature

66 seconds to load the AIP table in 2020

‣ cryptographic acceleration may be necessary

Page 41: Accountable Internet Protocol

41

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 42: Accountable Internet Protocol

42

Traffic Engineering

• AD granularity: administered together, fail together

• ADs are good match for inbound TE techniques - granularity of campus/customer/reachable subnet

• Use interface bits for different routes in ADs

- 8 bits of interface space

- partition to up to 255 “paths” to a domain

• Load balancing DNS-based

- use interface bits to represent a cluster as a single “host” connected multiple times

Page 43: Accountable Internet Protocol

43

Table Of Contents

• Introduction

• AIP Design

• Uses of Accountability

• Key Management

• Routing Scalability

• Traffic Engineering

• Conclusion

Page 44: Accountable Internet Protocol

44

SUMMARY

• AIP attempts to solve accountability requirement in network layer

• Enables solutions to source spoofing, (certain kinds of )DoS attacks, and secure BGP

• Possible concerns (route scalability, traffic engineering, key compromise) don’t appear to be show-stoppers for AIP adoption

Page 45: Accountable Internet Protocol

45

THANKS

Page 46: Accountable Internet Protocol

46

STRUCTURE OF AIP ADDRESS

Crypto version

Public Key Hash (144 bits)Interface (8bits)

‣ Flat addressing within AD Hierarchical addressing AD1:AD2:...:ADk:EID Interface bits EIDif1, EIDif2, ... AD: Interface bits set to zero Self-certifying Address = public key hash

Page 47: Accountable Internet Protocol

47

CRYPTOGRAPHIC EVOLUTION

Crypto version

Public Key Hash (144 bits)Interface (8bits)

• Each crypto version: combination of algorithm and parameters

• To move to new one:‣ All support in all routers‣ Once reasonably global, start using‣ Begin phase out of old version

• ~5+ years cycle

• One alternate version must be pre-deployed

Page 48: Accountable Internet Protocol

48

URPF• Ensuring loop-free forwarding of multicast packets in multicast routing

• Help prevent IP address spoofing in unicast routing

- Packets are only forwarded if they come from router's best route to the source of a packet, ensuring that:Packets coming into an interface come from (potentially) valid hosts, as indicated by the corresponding entry in the routing table.Packets with source addresses that could not be reached via the input interface can be dropped without disruption to normal use, as they are probably from a misconfigured or malicious source.

Page 49: Accountable Internet Protocol

49

INSIDER ATTACK

• Remedies:• Require AD domain signature on V Router verification of interface on which V arrives