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

2 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

3 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

4 Vulnerabilities of IP Hijacked routes Untraceable spam Denial-of-service attacks Source address spoofing Malicious or compromised hosts Fundamental problem accountability is not intrinsic to current Internet architecture For each problem, point solutions Complicated mechanisms External source of trust Operator vigilance

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 Solution replace IP with AIP

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

7 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

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

9 AD a AD e ‣ Address structure: ‣ Accountability domains (AD) ‣ End-point identifier (EID) ‣ AD corresponds to BGP prefix ‣ Allows hierarchical organization AD b AD c AD a :AD b :EID 1 AD a :AD c :EID 2 AD e :EID 9 Structure of an Address

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 ADEID (Domain Data, ) Public (Host Data, ) Public Hash Function (SHA-1) Hash Function (SHA-1)

11 SELF-CERTIFYING ADDRESS: AN EXAMPLE /sfs/sfs.lcs.mit.edu:vefvsv5wd4hz9isc3rb2x648ish742hy/pub/links/sfscvs Location HostID (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.

12 AIP PACKET HEADER Vers (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)

13 ROUTING vers... standard IP headers... random packet id 21 EID 9 AD e EID 1 AD a AD b AD e AD a AD b AD a :AD b :EID 1 AD e :EID 9 AD y AD x AD a 10 AD b 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

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.

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

16 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

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

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

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

20 EID verification Drop packet send V to source Receive packet source AD:X In accep t cache ? Forward packet yes no in first hop router Receive V verify ? Add source to accept cache Ignore yes no

21 AD verification Receive packet source AD:X In accept cache? Forward packet Trust neighboring AD? Drop packet send V to source Pass uRPF?

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

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

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

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

26 Shut-off illustrated ZombieVictim TTL, H SOP 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

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

28 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

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:

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

31 KEY COMPROMISE Protecting against compromise Detecting compromise Dealing with compromise

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

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

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

35 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

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

37 BGP Table Size Trends 17% annual growth 1.6M entries in 2020

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

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

40 Crypto Overhead Process update requires validating RSA signature ➡ 66 seconds to load the AIP table in 2020 ‣ cryptographic acceleration may be necessary

41 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

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

43 Table Of Contents Introduction AIP Design Uses of Accountability Key Management Routing Scalability Traffic Engineering Conclusion

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

45 THANKS

46 STRUCTURE OF AIP ADDRESS Crypto versionPublic 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

47 CRYPTOGRAPHIC EVOLUTION Crypto versionPublic 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

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.

49 INSIDER ATTACK Remedies: Require AD domain signature on V Router verification of interface on which V arrives