Presentation is loading. Please wait.

Presentation is loading. Please wait.

Improving Internet Availability Network Accountability Architectural foundations for defense against spoofing, route hijacking, etc. Architecture for Market.

Similar presentations

Presentation on theme: "Improving Internet Availability Network Accountability Architectural foundations for defense against spoofing, route hijacking, etc. Architecture for Market."— Presentation transcript:

1 Improving Internet Availability Network Accountability Architectural foundations for defense against spoofing, route hijacking, etc. Architecture for Market Efficiency New architecture for facilitating a market for Internet transit

2 Accountable Internet Protocol David Andersen, Hari Balakrishnan, Nick Feamster, Teemu Koponen, Daekyeong Moon, Scott Shenker http://www.aip-arch.net

3 3 Many Security Problems/Point Solutions For each problem, point solutions Fundamental problem: accountability is not intrinsic to current Internet architecture

4 IP Addresses/Names Lack Secure Bindings Three kinds of IP layer names: IP address, IP prefix, AS number No secure binding of host to its IP addresses No secure binding of AS number to its IP prefixes

5 5 Accountability Many problems easier to solve with network-layer accountability: Ability to associate a principal with a message Theres a way to make accountability intrinsic 5 AIP

6 How? Key idea: New addressing scheme for networks and hosts Addresses are self-certifying Simple protocols that use properties of addressing scheme as foundation Anti-spoofing, secure routing, DDoS shut-off, etc.

7 AIP Addressing Autonomous domains, each with unique ID AD1 AD2 AD3 Address = AD1:EID If multihomed, has multiple addresses AD1:EID,AD2:EID,AD3:EID Each host has a global EID [HIP, DOA, etc.] Key Idea: AD and EID are self-certifying flat names AD = hash( public_key_of_AD ) Self-certification binds name to named entity Key Idea: AD and EID are self-certifying flat names AD = hash( public_key_of_AD ) Self-certification binds name to named entity

8 AIP Forwarding and Routing Y:EID AD R AD G AD B AD Y Source Inter-AD routing & forwarding: AD #s only. Intra-AD routing disseminates EIDs. Many routing protocols possible - derive security from AIP self-certification ADEID Destination

9 Secure Routing with AIP (for BGP) Origin authentication: prefix originated by AS X actually belongs to X Path authentication: accuracy of AS path S-BGP requires external infrastructures In past, registries notoriously inaccurate With AIP: ADs exchange pub keys via BGP messages Origin auth automatic: ADs are keys! Path auth: Just like S-BGP, but no PKI Routing Registry PrefixPub Key AS PKI ASPub Key

10 10 Detecting & Preventing Spoofing P Sent P? {nonce} A Yes! { hash(P), nonce } K -1 A

11 AIP Enables Secure Shut-Off Problem: Compromised zombie sending stream of unwanted traffic to victim Zombie is well-intentioned, owner benign [ Shaw ] Shut-off packet { key = K victim, TTL, hash=H( P ) } Shut-off scheme implemented in NIC (NIC firmware update requires physical access) Hardware requirements practical Bloom filter for replay prevention (8MB SRAM) ZombieVictim P K -1 victim

12 Other Concerns Scaling Still need DNS Traffic engineering Detecting and recovering from key compromise Key management Hierarchical AIP addresses

13 Conclusion Q: How to achieve network-layer accountability in an internetwork? A: Self-certifying internetwork addresses AD:EID (AIP) Each field derived from public keys Accountability intrinsic - has many uses We believe AIP will scale AIP composes well with mechanisms for mobility, DoS mitigation, availability, etc.

14 MINT: Market for Internet Transit Nick Feamster, Ramesh Johari, Vytautas Valancius, Vijay Vazirani

15 Market Inefficiency Pair of ASes may decide to terminate connectivity arrangement Even if end nodes would pay for the path to be there! 31 Jul 2005: Level 3 Notifies Cogent of intent to disconnect. 16 Aug 2005: Cogent begins massive sales effort and mentions a 15 Sept. expected depeering date. 31 Aug 2005: Level 3 Notifies Cogent again of intent to disconnect (according to Level 3) 5 Oct 2005 9:50 UTC: Level 3 disconnects Cogent. Mass hysteria ensues up to, and including policymakers in Washington, D.C. 7 Oct 2005: Level 3 reconnects Cogent During the outage, Level 3 and Cogents singly homed customers could not reach each other. (~ 4% of the Internets prefixes were isolated from each other) October 2005April 2007

16 Depeerings Continue

17 Connectivity Inefficiency Paths become longer (or nonexistent) simply because two ASes decide not to interconnect Comcast Abilene AT&T Cogent $$ Peering points in Atlanta Peering point in Washington, D.C.

18 Idea Separate path setup from maintenance of connectivity on individual networks Enable customers who value end-to-end paths to actually pay for those paths Establish a market for the exchange of segments Interdomain RCP facilitates this market

19 MINT: Market for Internet Transit New types of contracts – ISPs advertise path segments – Edge networks bid for end-to-end paths – Mediator assembles segments into paths Exchanges as waypoints between segments Mediator collects information about path segments and sells end-to- end paths to edge networks M

20 Protocol Operation Provider advertises, per ingress/egress pair Segment properties A price for that segment Mediator(s) compile the pairs of endpoints to be bought and sold Edge networks request end-to-end connectivity Mediators solve an optimization problem and allocate resources to edge networks

21 Questions Contract setup Protocols for tracking available capacity of segments Scalability of mediator architecture Efficiency of resulting contracts Contract enforcement How can edge networks determine that they are receiving a certain level of service? Performance under churn Containing churn within an ISP when links fail Limiting recomputation of end-to-end paths

22 22

23 23 Spoofing vs. Minting AIP guarantee: Nobody but X can claim to be X However: X could invent a new identity (minting) 23

24 24 Mitigating Minting Peering ADs: Today: List which ASes/Prefixes A can use (painful for clients and ISPs) AIP: Configure reasonable limit on number of ADs can announce Edge ADs can limit EIDs similarly 24

25 Cryptographic Evolution Each crypto version: 1 combination of algorithm and parameters To move to new one: Add support in all routers Once reasonably global, start using Begin phase-out of old version We anticipate ~5+ year cycle for this (Must pre-deploy one alternate version) Crypto Version Public Key Hash (144 bits) Interface (8 bits)

26 26 What is an AD? Group of addresses that Are administered together Would fail together under common failures Examples: A campus, a local organization Non-examples: CMU Pittsburgh / CMU Qatar (Each would be different AD) 26

27 Traffic Engineering ADs are good match for inbound TE techniques - granularity of campus/customer/reachable subnet If need finer-grained: Note ECMP unchanged; Note DNS load-balancing unchanged; AIP address interface bits to sub-divide AD 8 bits of interface space partition to up to 255 paths to a domain

28 Handling Key Compromise Preventing: Two-level key hierarchy (master signs offline; routers have temporary key) Detecting: Registry of addresses used e.g., AD registers EID X is connecting through me Registries simple: entirely self-certifying Recovering: Renumber + (self-certifying) revocation registry

29 29 Shut-Off Replay Prevention SOP Sent Before? Receive SOP: Xmit Packet: key, TTL, hash P Hash (SHA-384) Bloom Filter: k=12, size=64 Mbits... ?? Signature OK? Install filter to V signed, V Dest Filters Dest Allowed? ? Sending rate <= 50kpps False Positives < 1 in 35M: Replay 100Mbit/s for > 5 min to trigger (Only if V previously sent SOP to S)

30 30 Mutual Shut-Off Attack: Zombie Z wants to flood victim V First, Z pings V. Gets response back. Z sends Shut-Off packet to V. Z floods V. Resolution: Smart-NIC allows V to send SOPs at very low rate (1 per 30 seconds) even though filtered Hosts can mutually shut-off... 30

31 Crypto Version Public Key Hash (144 bits) Interface (8 bits) VersNormal IP headers...Random ID# dests next-dest # srcs Source EID Source AD Dest EID Dest AD (next hop) Dest AD Stack... Source AD Stack... AIP Address AIP Header

32 AIP Verification Protocol Receive pkt w/ src A:E Drop pkt Send nonce to A or E Nonce response must be signed w/ As (or Es) priv key Receive nonce resp Verify signature Add A (or E):iface to accept cache Local AD? N Y N Trust nbr AD? N Y Accept & forward Y In accept cache? SLA, uRPF, …

33 Protecting Those who Protect Themselves To bound size of accept cache, if too many entries of AD:x, AD:x2,... Upgrade to wildcard: AD:* If many compromised hots in AD, they can allow others to spoof AD If AD secure, nobody can spoof it

34 Table Size Projections 17% growth and predictions from Fuller & Huston; rough agreement for 2020 Year17% GrowthFuller/Husto n 2008Observed: 247K 2011396K600K-1M 20201.6M1.3-2.3M

35 35 BGP Table Size Trends 17% annual growth 2020: 1.6M entries

36 With AIP... Number of entries? O(# of prefixes) Path length? Some large ASes -> Several ADs Lets guess <= 60% increase AIP AD and EID (160 bits) IP (32 bits) AS (16) More mem per entry:

37 Growth vs. Hardware Semiconductor industry roadmap projects doubling in ~3 years 50% >> 17%. But lets look at some #s... In 2020, can we build a cost-effective router for AIP traffic?

38 RIB Memory (20 full-table peers, core) By 2020... FIB: Will grow 5-9x DRAM, SRAM, TCAM: 16x growth per $ 200720112020 IP0.4 ($30) 0.7 ($14) 2.9 ($7) AIP1.3 ($103) 2.0 ($40) 8.2 ($21) Gigabytes (2007 Dollars) Without counting benefit from AIP flat lookups IBM claims 22nm SRAM success EETimes, Aug 18, 2008 I/O Data Rates on commodity DRAM devices will increase to over 8 GB/s by 2022 ITRS 2007 roadmap

39 39 But 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 Memory bandwidth: 8.2GB of memory; todays memory can handle 1.7GB/sec. Without AIP/S-BGP future router could load in ~30 seconds. With crypto, however... 39

40 40 Crypto overhead still hurts Process update: Validate RSA signature Trivially parallelized Worst-case result - crypto acceleration or clever BGP tricks reduce time 2008 (2.8Ghz quad-core) 2020 RSA Validate35k/sec480k/sec AIP/S-BGP Table Load ~141 seconds~66 seconds

Download ppt "Improving Internet Availability Network Accountability Architectural foundations for defense against spoofing, route hijacking, etc. Architecture for Market."

Similar presentations

Ads by Google