Download document 8757953

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Deep packet inspection wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Distributed firewall wikipedia , lookup

Internet protocol suite wikipedia , lookup

Computer network wikipedia , lookup

Network tap wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

IEEE 1355 wikipedia , lookup

Airborne Networking wikipedia , lookup

Zero-configuration networking wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Transcript
ECCP A Formally-­‐Verified Migra5on Protocol For Mobile, Mul5-­‐Homed Hosts Matvey Arye Joint work with: Erik Nordström, Robert Kiefer Jennifer Rexford, Michael J. Freedman 1 Original Internet Architecture Hosts did not move and had a single connec5on to the Internet 2 Fast Forward •  Mobile devices have new capabili5es –  Devices move –  Mul5ple points-­‐of-­‐aQachment •  Servers have changed –  VM migra5on –  Mul5ple network aQachments (NICs) –  Data-­‐center mul5homing 3 Extending Network Capabili5es •  Host mobility, VM Migra5on –  Connec5on shouldn’t break when hosts move •  Switching seamlessly between WiFi and 4G –  Ability to switch between network interfaces •  Load balancing between network paths across interfaces –  Ability to move individual flows between interfaces •  Having backup routes on alterna5ve interfaces –  Maintaining a list of alt. interfaces for connec5ons 4 Problems Arise From Current Abstrac5ons Applica5on Transport Network Applica5on Data Delivery TCP in “ESTABLISHED” state Connec5on Control Network •  No network changes •  Independent of data delivery seman5cs 5 The Flow Abstrac5on Applica5on PID Connec5on PID Data Delivery Data Delivery Connec5on Control Network Applica5on FlowID1 Flow1 FlowID1 FlowID2 Flow2 FlowID2 IP1 Flow1 IP2 IP3 Flow2 IP4 Connec5on Control Network 6 Our Approach For Handling Device Mobility Connec5on Control FlowID1 Flow1 FlowID1 Connec5on Control Network IP1 Flow1 IP5 P2 Network My Address has changed Alice Bob:IP2 Bob:IP5 7 Contribu5on 1: ECCP End-­‐to-­‐End Connec:on Control Protocol •  Host mobility through end-­‐to-­‐end signaling •  Transport-­‐layer independence •  Mul5path through new flow abstrac5on 8 Contribu5on 2: Formal Verifica5on •  Connec5on control protocols hard to get right –  We show that TCP-­‐Migrate and HIP are incorrect •  Non-­‐Determinism makes it hard to verify –  Unreliable network, changing network iden5fiers –  Non-­‐determinism leads to state-­‐space explosion •  We show new techniques to enable verifica5on –  Verified ECCP in SPIN 9 Other End-­‐to-­‐End Protocols ECCP Formally Verified TCP-­‐
Migrate Incorrect MPTCP HIP Incorrect Transport Independent Rapid Migra:on Mul:path Capable Per-­‐Flow Migra:on 10 Protocols •  Establishing connec:ons •  Moving flows to new addresses •  Adding flows to connec5on •  Handling NATs •  Simultaneous migra5ons 11 Connec5on Establishment •  Three-­‐way handshakes to establish states •  Each peer communicates flowID to other peer –  Unlike IP addr., doesn’t change during migra5on –  Packets demul5plexed on local flowID •  Op5onally sends alterna5ve addresses to peer for fail-­‐over and addi5onal flows 12 The Protocol – Ini5al Flow Client SYN (Service S) Flow ID-­‐C Server Demux on: S SYN-­‐ACK Flow ID-­‐C Flow ID-­‐S Demux on: Flowd ID-­‐C ACK Flow ID-­‐C Flow ID-­‐S Demux on: Flowd ID-­‐S 13 The Protocol – Changing Addresses Mobile Sta:onary RSYN Version #-­‐M Flow ID-­‐M Flow ID-­‐S SRC=IP5 Demux on: Flow ID-­‐S Record addresses IP5 New Address IP5 Demux on: Flow ID-­‐M ACK Version #-­‐M Flow ID-­‐M Flow ID-­‐S RSYN-­‐ACK Version #-­‐M Flow ID-­‐M Flow ID-­‐S Demux on: Flow ID-­‐S Change address to IP5 14 Version #s •  Need to use versioning on migra5on messages •  HIP, TCP-­‐Migrate use TCP-­‐like sequence #s –  Ties connec5on control to data delivery –  Creates problems -­‐-­‐ need different seman5cs Seman5cs when genng packet N: “Sequence” Received 0 to N-­‐1 Cannot skip ahead “Version” All previous #s < N Can skip ahead 15 Sequence # Seman5cs are Dangerous Mobile New Address IP5 RSYN Sequence #n Sta:onary RSYN-­‐ACK Sequence #n New Address IP6 RSYN Sequence #n+1 Can’t process sequence #n+1 because didn’t finish #n 16 Formal Verifica5on 17 Formal Verifica5on -­‐ Overview •  Modeled in SPIN •  Checks for deadlocks –  Neither party can send or receive messages •  Checks for livelocks –  Neither party can do anything useful –  Each host can ping the other host 18 Goals of Connec5on Control •  Robust connec5vity across mobility events –  Maintain up-­‐to-­‐date mapping between flows & IPs –  Correct if each host can ping its peer •  What connec5on control is NOT –  Reliable delivery –  Bit-­‐correctness of data (i.e. checksums) –  Ordering of data 19 Model Checking 101: Explore All Interleavings Process 1 Process 2 20 Model Checking 101: Explore All Interleavings Process 1 Process 2 21 Model Checking 101: Build Global State-­‐Space State 1 State 2 State 3 State 5 State 2 State 4 State 4 22 Verifica5on Challenges •  Most protocols verified in SPIN sit on top of a reliable data-­‐delivery layer –  But for ECCP, the network is unreliable: loss, duplica:on, and reordering of packets are possible but can cause state-­‐space explosion •  State-­‐space explosion due to random FlowIDs •  No no5on of 5me in SPIN – 5meouts are tricky –  But are needed to recover from packet loss 23 Modeling an Unreliable Network Process 1 Network Sim Process 2 Network simulator can drop, reorder or duplicate packets 24 Creates Unnecessary States Process 1 Network Sim Process 2 1
2
25 Creates Unnecessary States Process 1 Network Sim Process 2 1
2
26 Creates Unnecessary States Process 1 Network Sim Process 2 1
2
Rela5ve order does not maQer For protocol execu5on 27 More Efficient Implementa5on Process 1 Process 2 Network simulator runs as part of the sending process 28 Formal Verifica5on -­‐ Completeness •  Each version # creates new state-­‐space tree #1 #2 #3 •  So, verifica5on does not reach a fixed point –  But, verifies up to 6 migra5ons for base protocol –  4 migra5ons for full protocol 29 Implementa5on •  ECCP part of larger Serval project –  Next-­‐genera5on service-­‐oriented network stack –  hQp://www.serval-­‐arch.org/ •  Loadable kernel module –  Runs on Linux, Android,… •  Adapts “ESTABLISHED” state of TCP 30 Evalua5on – Client Interface Changes Saves > 2GB cellular data per month WIFI 4G WIFI 4G One of the authors walks through campus, playing music through Google Play Music. No loss in playback quality. 31 Conclusion •  New abstrac5ons –  Decoupling data delivery and connec5on control –  Flows as path-­‐dependent parts of connec5ons •  Design of demul5plexing keys is important –  Independent of network iden5fiers •  Ordering seman5cs are tricky to get right •  Formal verifica5on is important and possible 32 Formal Models hQp://www.serval-­‐arch.org/eccp/ Implementa5on hQp://www.serval-­‐arch.org/ 33