Hard Architectural Challenges and Initial Approaches Arun Venkataramani Univ. Massachusetts Amherst

MobilityFirst FIA Team Presentation Nov 15, 2010 Architecture: Design Goals 1.Host + network mobility 2.No global root of trust 3.Intentional data receipt 4.Byzantine robustness 5.Content addressability 6.Evolvable network None of the above goals G1-G6 are not met by today’s Internet.

Location Service

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

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

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

Name servers Design issues: 1. Ensuring proximate content retrieval 2. Leveraging traffic engg flexibility 3. Storage-aware routing using opportunistic caching/retrieval Function: Resolve Content  [NA 1 :HA 1, NA 2 :HA 2,…] API Location Service for Popular Content

Routing

DT Routing: Robustness to Diversity Well-connected (wired networks) WiFi, Cellular, WiMax, LTE Sparsely- connected (Mobile DTNs) Connectivity Replication (Highly unpredictable DTNs) Best-path forwarding (Low load) Multipath forwarding (High load) Goal: Protocol stack robust to diverse, changing network conditions 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

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

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

Security

MobilityFirst FIA Team Presentation Nov 15, 2010 Architecture: Design Goals 1.Host + network mobility 2.No global root of trust 3.Intentional data receipt 4.Byzantine robustness 5.Content addressability 6.Evolvable network None of the above goals G1-G6 are not met by today’s Internet.

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

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 1Name service 2Name service 3

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

MobilityFirst FIA Team Presentation Nov 15, 2010 Security: Intentional receipt for DDos nop Congestion policing feedback (1) mon HsHs HdHd RaRa Policing (2) (3) (4) RbRb congested Goal: Scalable fair resource allocation with intentional 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

Privacy Challenges Privacy Mechanisms AS 1 AS 2 Lookup Service NA:HA Lookup Service NA:HA Hospital Allow HA Pseudonyms HA swaps pseudonym Home Agent Home Agent Allow Home Agent Redirection Goal: Quantifiable privacy 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

Conclusions/Questions