360 likes | 538 Views
Mobile Networking - Part II (Network Layer: Cellular). EE206A (Spring 2004): Lecture #3. Reading List for This Lecture.
E N D
Mobile Networking - Part II(Network Layer: Cellular) EE206A (Spring 2004): Lecture #3
Reading List for This Lecture • P. Bhagwat, C. Perkins, and S. Tripathi, “Network layer mobility: an architecture and survey,” IEEE Personal Communications, June 1996, vol.3, (no.3):54-64.http://citeseer.ist.psu.edu/bhagwat96network.html • Alex C. Snoeren and Hari Balakrishnan, “An end-to-end approach to host mobility,” Proc. of the Sixth Annual ACM/IEEE International Conference on Mobile Computing and Networking, August 2000. http://nms.lcs.mit.edu/papers/e2emobility.pdf
Mobility and Link/Network Layers • Mobility has two possible link and network layer implications • Change in address • Address is often a function of location • Change in route costs and availability • Due to changes in topology and link status • Handled differently in different categories of mobile networks • Infrastructure based (single hop to a basestation) • Infrastructure-less (no basestation) • Hybrid (multiple hops to a basestation) • Mobile infrastructure (mobile basestations) • We’ll focus only on packet networks • Similar mobility issues in connection-oriented cellular phone networks
Mobility in Wireless LANs • Access points are bridges (layer 2) - i.e. they relay MAC frames • Smart bridges avoid wasted bandwidth and loops • Connectivity not a problem in a broadcast LAN with mobility • But mobility causes connectivity failure across network boundaries and in switched LANs
Mobility in Internet • Collection of networks connected by routers • Big problem arises because of addressing! • Each network interface on every internet host has two identifiers • IP address (32 bit in IPv4) • Host name (string) • DNS maps host names to IP address • Reverse DNS does the reverse • Applications refer to hosts by name • Use DNS to get the IP address • Assume static name-address binding, and therefore do DNS lookup only once • Transport protocols assume this static binding • E.g. TCP connection identified by <src IP, src port, dest IP, dest port> • IP packets carry source and destination IP address • Routers use routing tables to forward packets to destination address • Packets sent directly to destination within a network/LAN.
Address in IP Routing • Routers maintain network topology in routing tables • Flat IP address space will make routing tables huge • IP address space is therefore hierarchical • IP address is a tuple: (network id, host id) • E.g. consider 192.11.35.53 • Internet routers maintain network topology only at the level of individual networks • i.e. they only use the network id part of the address
Key Observation: IP addresses server two purposes • Endpoint identifier for application and transport layers • Mobile’s IP address must be preserved • applications and TCP connections will fail otherwise • Routing directive for network layer • Mobile’s IP address must change for hierarchical routing to work, and the DNS entry updated • packets will go to the old network otherwise What should one do? This has been the key problem in supporting mobility in the Internet.
So, what should one do? • Don’t support applications and TCP sessions across changes in network location (cell change) • Many useful applications are transaction-oriented and use application level identifiers • E.g. HTTP with cookies, IMAP • User just retries the transaction in case of failure if movement happened in the midst of a transaction (rare) • Fix common applications and transport layers (TCP) to be mobility aware • Okay for new applications • But changing TCP ubiquitously is impossible! • “Migrate” option in TCP • Make the network (IP) layer mobility-aware so that all applications and transport layers can survive cell changes • Led to Mobile-IP
The Mobile IP Problem How to direct IP packets to MH that travels to a Foreign Network away from MH’s Home Network? • MH is assigned a home address as its IP address • home network is the network containing the home address • DNS queries for MH return the home address • Mobile-IP only concerned with moves across networks • moves within home network (e.g. ethernet) handled by link-layer bridging
Key to Mobile IP: Two Tier Addressing • MH has two IP addresses associated with it • does not mean two IP address are assigned! • First component of the address serves as the routing directive • reflects MH’s point of attachment to the Internet • derived from the foreign network • changes whenever MH moves to a new network • internet routers use this address to route to MH’s point of attachment • Second component of the address servers as the end-point identifier • this is the home address • remains static throughout the lifetime of MH • only this address used for protocol processing above network layer • MH remains virtually connected to the home network • Two-tier addressing is only a logical concept • IP packet headers can’t actually carry two addresses! • MH to Stationary Host (SH) packets do not need special handling
Components of Mobile Network Layer Architecture • Forwarding Agent (FA) • Forwarding component of the two-tier address is the address of the FA entity • Issues: • where can FA be located? • MH, BS, somewhere else • how does MH find the FA in a foreign network? (and, vice versa) • route advertisement and registration protocol • FA periodically advertises its presence (beacons) • Location Directory (LD) • Records association between home and forwarding addresses • contains most up to date mapping of MH to its FA • MH sends updates to LD on moving • Issues • Centralized vs. distribute? How to distribute? • Common policy: owner-maintains • some agent in home network, to which the home network router forwards the query • Address Translation Agent (ATA) • Involves querying the LD • Issues: • Where to locate ATA? If at CH, then need to change software at millions of hosts) • How to make querying LD efficient? Cache? How to maintain consistency with LD? • FA, LD, and ATA are functions and not machines!
Location Update Protocol • LUP is the reliable mechanism for • keeping LD up to date • keeping cached LD entries consistent with master LD • Choice of LUP depends on caching policy • together they determine scalability and routing characteristics • What if no LD caching? • ATA must be collocated with LD to avoid per-packet queries • packets from CH will first travel to home network before being sent to FA • non optimal paths! • What if there is caching? • routing efficiency is improved • no more travel to home network • but, vulnerable to security attacks • cache updates must be authenticated • otherwise, traffic to MH may be redirected away!
Address Translation Mechanisms • Encapsulation approach • IP-in-IP tunnel • Loose source routing approach (an option in IP) • CH replies back along path recorded when MH sent packet to CH
Various Mobile-IPs • Many Mobile-IP systems were proposed (and some implemented) in early 90s • Now there is a “standard” mobile-IP • IETF’s Mobile-IP for IPv4 (RFC2002) • IETF’s Mobile-IP for IPv6 • All are special cases of the canonical mobile-IP architecture, and make different choices of • FA location • ATA location • choice of LUP • address translation mechanism
Mobile IP for IPv4 • “Soft” requirements: • no weakening of IP security • multicast capable • location privacy • Approach: MH has a home address and a care-of address (COA) • COA may be the address of a foreign agent • Or, may be assigned directly to MH via DHCP (collocated MH & FA) • MH registers COA with a home agent • shared secret may be used for authentication • packets from CH intercepted by home agent which tunnels them to COA • home agent acts as LD + ATA • no LD caching allowed... no secure way to distribute LD cache entries • any entity in internet can fake as home agent & redirect traffic • Canonical architecture mapped to IETF Mobile-IP • ATA function f is collocated with the home agent • FA function g is either with foreign agent or with MH (if DHCP or PPP) • LUP is simple: MH notifies the home agent on moving • LD entries are never cached: no consistency problem
Key Mechanisms • Discovering the COA • Build on top of existing router advertisement protocol • HA & FA advertise periodically ~ O(sec) • MH can broadcast or multicast a solicitation • Registering the COA • Four-step process updates (MH, COA, lifetime) binding • It is a remote redirect - need authentication! • Registration requests signed by a shared MH-HA key • Unique time varying field to prevent replay attacks • Tunneling to COA • IP-within-IP, Minimal Encapsulation, Generic Record Encapsulation • Automatic HA discovery • Directed broadcast to home network results in a reject notification from HAs and their addresses • Detecting mobility • Lazy cell switching: seek new agent at the end of lifetime in agent advertisement • Eager cell switching: switch to any new COA available • Prefix matching: assume moved if new advertisement from different network • Link layer notification • No good solution if FA collocated on MH! • Detect lack of activity, ping router, promiscuous mode etc.
Home Networks • HA as a separate system on a physical home network • HA included with router to a physical home network • A virtual home network
Various Problems • Routing inefficiencies • Triangular routing • Hand-off performance • Disruption to user, micro-mobility • Interaction with firewalls • Blocking of certain incoming and outgoing packets
Triangular Routing Problem • Approach: collocate ATA at CH • Problem: securely & efficiently create valid HA to FA binding at arbitrary CH • No a priori shared secret possible • No clean binding update mechanism unless Internet gets key distribution • Also problems of location privacy, routing loops, packet loss after handoff
Smooth Handoffs • Smooth handoffs use binding updates • Mobile uses Previous Foreign Agent Notification Extension to ask the new foreign agent to relay its binding update to its previous foreign agent
Hierarchical Foreign Agents • Idea: make Registration Requests go only as far as needed up a hierarchy of Foreign Agents
Interaction with Firewalls • Firewalls discriminate againsts IP datagrams transiting an enterprise’s border routers • filter datagrams not meeting some strict criteria • discard datagrams to/from specific addresses and ports • A common firewall filtering is to discard incoming datagrams that seem to emanate from internal computers • prevent external internet from spoofing internal computers • not really valuable (spoofer can’t get response back) but still widely used • makes it impossible for a MH to send datagrams to hosts in home network • Ingress filtering in ISP routers eliminate outgoing datagrams with source address that doesn’t belong to that administrative domain • prevent attacks using datagrams with fictitious source addresses • makes it impossible for MH to send to a CH directly using home address as the source address • No clean solution! • Reverse tunneling is a simple solution (MH to CH is tunneled via HA so that packets seem to come from home network) • But causes dog-leg routing in both directions! • Determining whether reverse tunneling is needed is also hard
Mobility Support in IPv6 • New protocol fixes problems with no need to worry about backward compatibility • FA collocated with MH • Optimized route • ATA collocated with CH • MH can easily determine if CH doesn’t have the right COA, and sends binding updates • Source routing • Smooth handoff • MH continues to listen to old COA if the physical layer permits it • Security support
Macro vs. Micro Mobility • Mobile-IP works well for macro-mobility, but not so well for micro-mobility • frequent notifications to HA and QoS reservations • disruption to user traffic during hand-off • Various approaches • Mobile-IP Route Optimization with support for micro-mobility • packets forwarded from old FA to new FA reducing disruption • but, care-of-address changes so that HA needs to be informed • acquiring new COA results in new QoS reservations • Multicasting, Predictive Multicasting • join latency + group management issues result in wasted b/w & scalability probs • Multicast within a domain FA, and tunnel to it • relaibility, QoS issues • Co-located FA • IP address changes, requiring new QoS mappings • Hierarchy of FA • solves scalability, but multiple tunnels cause QoS and efficiency problems • Cellular IP, HAWAII • specialized domain routers with host-based entries for local mobility (CIP) • hierarchy of domains with path setup schemes within domains (HAWAII) • heavy influence of mobile-ATM schemes
End-to-end Approach to Mobility: MIT’s Migrate Architecture • Migrate TCP connections to new IP address • In effect IP addresses no longer used by TCP as identifiers • Only current CHs are notified • Secure dynamic DNS update
Implementation Approach • Provide special Migrate option • Sent on SYN packets of new connection • Indicates new connection should be joined to a previous one • Use previous sequence space • Works with new TCP features such SACK, FACK, Snoop… • Preserve three-way SYN handshake • Works with statefull firewalls
Securing the Migration • Problem: Increased vulnerability to hijacking • Ingress filtering doesn’t help • Attacker only needs token and sequence space • Solution: Keep the token secret • Negotiate it using Diffie-Hellman exchange • Use sequence numbers to prevent replay • Resulting connections are as secure as standard TCP (not very) • Use IPsec or SSH for real security • Problem: Denial of service attacks • Migrate SYNs are heavy weight” and require real computation • thus Migrate SYN floods are even more dangerous than regular SYN floods • Solution: Pre-computable token to guard against frivolous computation • Refreshing tokens after each successful migration makes replay window very small
Summary of the End-to-end Migration Approach • Exposes address changes to end hosts • Agile applications can adapt to changing conditions for better performance • Mobility per connection, not just per host • Preserves IP addressing semantics • No changes to the routing infrastructure • Minimal penalty for mobility support • Obtain optimal unicast packet routing • End hosts can’t move “simultaneously” • Relatively rare in non ad-hoc environments?