Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download document 8757953
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
Airborne Networking 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
