1 / 14

ITINERANT: TCP Socket Migration

ITINERANT: TCP Socket Migration. Titus Winters <titus@cs.ucr.edu> Dan Berger <dberger@cs.ucr.edu> CS 202: Spring ‘03. Overview. Problem Description & Motivation Proposed Solution Netfilter Primer Solution Architecture Conclusion. Problem & Motivation.

bin
Download Presentation

ITINERANT: TCP Socket Migration

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. ITINERANT: TCP Socket Migration Titus Winters <titus@cs.ucr.edu> Dan Berger <dberger@cs.ucr.edu> CS 202: Spring ‘03

  2. Overview • Problem Description & Motivation • Proposed Solution • Netfilter Primer • Solution Architecture • Conclusion

  3. Problem & Motivation • TCP Sockets are identified by (saddr, sport, daddr, dport) • + seqno and ackno state • No standard mechanism exists to move one end of a socket connection. • This could often be quite useful – examples include: • Web “spray”/load balancing • Mobile & ubiquitous computing

  4. Proposed Solution • We set out to provide primitives to facilitate TCP socket migration on Linux. • Goals: • Transparent to client application • Minimally Intrusive @ OS level • Extend standard socket API – minimize learning curve for server developers

  5. Proposed Solution (cont.) • Non-goals: • Do not address “application state” migration. • Provide no more (or less) security than TCP. • Higher level security ramifications considered, but not addressed.

  6. Netfilter Primer • “Minimally Intrusive” means no direct kernel modifications. • Modifying the TCP state machine seems to require kernel hacking. • Netfilter to the rescue!

  7. What’s Netfilter? • Netfilter is a series of callback functions within the network stack. The API is non-portable and appeared in linux 2.3.x • Initial design and implementation by Paul “Rusty” Russell • Each protocol has it’s own set of callback points. We care about IPv4.

  8. Netfilter Concepts • A module expresses interest in being invoked at an arbitrary subset of the available callback points – specifying the function and the (global) priority in which it should be called. • That function is passed (among other things) a handle to the packet being processed.

  9. Netfilter Hooks in IPv4 3 1 Routing Engine 4 Out In 2 5 Local Sockets Application Application Application Application

  10. 3 1 In 4 Out Routing Engine Say Again? 2 5 Local Sockets • 1: NF_IP_PREROUTING • any received packet which checksums OK. • 2: NF_IP_LOCAL_IN • packets destined for local sockets • 3: NF_IP_FORWARD • foreign packets being forwarded • 4: NF_IP_POST_ROUTING • any outbound packet • 5: NF_IP_LOCAL_OUT • packets originating from local sockets

  11. Solution Description • A new setsockopt(2) option to initiate migration. • A netfilter module that registers for PREROUTING and LOCAL_OUT • Handles migration process. • Completes socket shutdown on intermediate host (FIN/ACK) • Nicely symmetric – so the host initiating the migration just “steps out” of the middle.

  12. Migration Flow S1 C S2

  13. Conclusion • A working proof of concept was built. • It consists of O(1000) lines of code • No kernel modifications needed • Some details were skipped to make the schedule but could be fixed within the current implementation: • Migration isn’t a three way handshake. • TCP/Socket options aren’t handled.

  14. Fini Questions?

More Related