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
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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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 problemaccountability 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
Solutionreplace 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
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
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
• 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 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
21
AD verification
Receive packet
source AD:X
In accept cache?
Forward packet
Trust neighboring
AD?
Drop packetsend V to
sourcePass 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 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
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 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
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
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