1 / 19

Hard Architectural Challenges and Initial Approaches

Hard Architectural Challenges and Initial Approaches. Arun Venkataramani Univ. Massachusetts Amherst arun@cs.umass.edu. Architecture: Design Goals. Host + network mobility No global root of trust Intentional data receipt Byzantine robustness Content addressability Evolvable network .

diep
Download Presentation

Hard Architectural Challenges and Initial Approaches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hard Architectural Challenges and Initial Approaches ArunVenkataramani Univ. Massachusetts Amherst arun@cs.umass.edu

  2. Architecture: Design Goals • Host + network mobility • No global root of trust • Intentional data receipt • Byzantine robustness • Content addressability • Evolvable network None of the above goals G1-G6 are not met by today’sInternet.

  3. Location Service

  4. Location Service: Scalability to billions of mobiles • Function: Resolve Host  [NA1, NA2,…] • Scale: 10B devices, 100 networks/day 10M/sec Locate(Host) Data Name servers Host[NA:NA1] Host[NA:NA2] NA2 NA1 NA

  5. Location Service: Scalability to billions of mobiles • Function: Resolve Host  [NA1, NA2,…] • Scale: 10B devices, 100 networks/day 10M/sec • Metrics: • Query/Update delay (<50ms) • Response staleness (<500ms) • Load balance • Fault tolerance Name servers

  6. Location Service: Scalability to billions of mobiles • Function: Resolve Host  [NA1, NA2,…] • Scale: 10B devices, 100 networks/day 10M/sec • Design issues: • In-situ routing deflection (?) • Structured local scope IDs (?) • Authoritative name servers (?) • Network anycast to name servers Name servers API

  7. Location Service for Popular Content • Function: Resolve Content  [NA1:HA1, NA2:HA2,…] • Design issues: • Ensuring proximate content retrieval • Leveraging traffic enggflexibility • Storage-aware routing using opportunistic caching/retrieval Name servers API

  8. Routing

  9. DT Routing: Robustness to Diversity • Goal: Protocol stack robust to diverse, changing network conditions Connectivity • Approach: • Hop-by-hop transport with in-network storage when needed • Gracefully degrades with challenging network conditions • Uncertainty-driven routing algorithms unifying storage & transmission capabilities of the network

  10. E2E Routing: Enabling Path Diversity • Goal: Path diversity for • Optimizing performance, cost, power, security in multi-technologymobile connectivity • Approach: Multipath routing mechanisms • Multi-homing support • Detour routers • Randomized path “unchoking” • Coordinated path rate controller Management Plane ISP1 ISP2 path1, path2, path3 req_paths(…) ISP3

  11. E2E Routing: Design Challenges R2 R3 R1 R5 R4 R6 • Store and update loose source routes, eg (NA:NA1:NA2) in a scalable manner • Supporting multiple interfaces • Each interface has an address. • Need to handle cases when interfaces change (e.g., the 3G unavailable). Bob Alice

  12. Security

  13. Architecture: Design Goals • Host + network mobility • No global root of trust • Intentional data receipt • Byzantine robustness • Content addressability • Evolvable network None of the above goals G1-G6 are not met by today’sInternet.

  14. Security: Hijack/Spoof tolerance • Alice wants to talk to Bob Name certification + location service Bob’s human readable name 2. Bob’s ID & address Routing Service 3. Send Alice’s handshake data signed by Alice’s ID To Bob’s address Alice Bob 6. Verify using Bob’s self-certifying ID 5. Send Bob’s handshake data signed by Bob’s ID To Alice’s address

  15. Security: Decentralizing Trust in Naming • Goal: No single root of trust in name certification • Approach: • Multiple name service providers (NSP) • Many-to-many mapping from namespaces to NSPs • Quorum-based certification Name service 1 Name service 2 Name service 3

  16. Security: No single point of subversion Goal: Scalably tolerating Byzantine faults for naming, routing Approach: • Naming: • BFT throughput scalability wrt faults and number of servers • Geographic scaling support • BFT within and across name service providers • Routing • Securable protocol design, eg, consensus interdomain routing, by identifying safety and liveness properties • Multipath + management plane for data plane security • Integration with naming, management plane, and intradomain routing

  17. Security: Intentional receipt for DDos Congestion policing feedback (2) (1) Ra Rb Hd Hs congested mon mon mon nop (3) (4) Policing • Goal: Scalable fair resource allocationwithintentional data receipt • Approach: • Packets carry unspoofable congestion policing feedback • Congested routers use pair-wise keys for congestion policing feedback that receivers use as capability tokens • Access routers police senders’ traffic to guarantee per-sender fairness without per-sender queues

  18. Privacy Challenges Goal: Quantifiable privacy Privacy Mechanisms Lookup Service NA:HA NA:HA Allow Home Agent Redirection Approach:Identifying privacy concerns: • Host identifiers allows linking traffic to specific devices • Self-certifying addresses reduce plausible deniability • Lookup service could enable geo-tracking by third parties Allow HA Pseudonyms Home Agent AS 1 AS 2 Hospital HA swaps pseudonym

  19. Conclusions/Questions

More Related