Download
1 / 14
140 likes | 281 Vues
This document discusses the problem of TCP socket migration, which lacks standard mechanisms for moving one end of a socket connection. It highlights the motivation behind the need for migration in scenarios like load balancing and mobile computing. The proposed solution offers transparent primitives to facilitate TCP socket migration on Linux while being minimally intrusive. By extending the standard socket API, the solution aims to minimize the learning curve for developers while avoiding kernel modifications. The approach utilizes Netfilter to manage socket migration effectively.
E N D
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 • 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
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
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.
Netfilter Primer • “Minimally Intrusive” means no direct kernel modifications. • Modifying the TCP state machine seems to require kernel hacking. • Netfilter to the rescue!
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.
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.
Netfilter Hooks in IPv4 3 1 Routing Engine 4 Out In 2 5 Local Sockets Application Application Application Application
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
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.
Migration Flow S1 C S2
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.
Fini Questions?
