Accountable Internet Protocol

1. 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 Presented by Young-Rae Kim and PierreElie Fauche

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 • For each problem, point solutions • Complicated mechanisms • External source of trust • Operator vigilance Fundamental problem accountability is not intrinsic to current Internet architecture

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. ADb ADe ADc ADa Structure of an Address • Address structure: • Accountability domains (AD) • End-point identifier (EID) • AD corresponds to BGP prefix • Allows hierarchical organization ADe:EID9 ADa:ADc:EID2 ADa:ADb:EID1

10. (Domain Data, ) (Host Data, ) Public Public Hash Function (SHA-1) Hash Function (SHA-1) AD EID 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

11. Path on remote server Location HostID (specifies public key) /sfs/sfs.lcs.mit.edu:vefvsv5wd4hz9isc3rb2x648ish742hy/pub/links/sfscvs SELF-CERTIFYING ADDRESS: AN EXAMPLE • 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

13. ADb ADy ADa ADx ADe:EID9 ADa:ADb:EID1 ROUTING #dests ADe next-dest 1 0 Source EID #srcs Source AD Dest EID ADa ADb 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

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. Forward packet Add source to accept cache yes yes In accept cache? verify? Receive packet source AD:X Receive V Ignore no no EID verification in first hop router Drop packet send V to source

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

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. P TTL, H<P> SOP Shut-off illustrated Zombie Victim • 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 As with any system relying on public key cryptography, AIP faces three general problems: • 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

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. Protecting against compromise Dealing with compromise KEY COMPROMISE 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) Protecting against 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 Detecting compromise Detecting compromise Dealing with 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 • 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 • 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