1 / 15

Navigating Location and Identity in Network Architecture

This document explores the complexities of location and identity in network architecture, particularly addressing how IP addresses and TCP connections are affected when devices move. It discusses concepts such as Mobile IP and the geographical separation of service providers. The implications of network mobility on TCP state management and DNS updates are analyzed, alongside strategies for maintaining connectivity during movement. The potential for scaling and complexity in network architecture is also discussed, with a focus on enhancing network resilience and performance while navigating inherent security concerns.

eliot
Télécharger la présentation

Navigating Location and Identity in Network Architecture

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. Network Architecture (R02) #4Location and Identity Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22 http://www.cl.cam.ac.uk/teaching/1011/R02

  2. IP addr v. Id+Loc • IP Addr == Interface + Route Hints. • TCP state = 5 tuple • Src+Dst port Src+Dst Addr, IP Proto • Can’t change during session • If we move, have to get new addr to be reachable • Need to advertise (DNS) for new people • Need to tell old people to reconnect • Or tunnel, or rewrite to maintain TCP • Mobile IP has agents to do tunnels • Mobile IPv6 can cut the triangle case out

  3. Why not just leave as mobile ip • Don’t like triangles for ipv4 • Don’t like tunnel overhead • So what about new addr trick • Map/encap service or • IPv6 trick (8+8, for example)

  4. Re-write v. map/encap • As all said, re-write has potential security problems, but low overhead/scales in router terms • But map/encap has deployment simplicity, but o/h problems - both for encap and for binding service

  5. -ve security for re-write? • Not clear there really is a security problem • Re-writer == NAT, we trust NATs now! • E2D TCP/IP 5 tuple assumes • IPv4 I/f+route is some sort of secure thing • Never true! • Correct model is TCP state should be bound to EID, and not care about last hop of path/route at all! • Syn-cookie/nonce to secure state • Or TSL/SSL or other

  6. -ve overheads for map/encap • As currently formulated… • Fast moving device would cause a lot of re-binding • But why not try to localize this? • Movement geographically often doesn’t change provider or even topology much • Separate geo/topo/provider cases and deal with seperately?

  7. Alternative 1 - just ignore • Today, clients move; servers fixed • Move- get new IP via DHCP • Break TCP connection • HTTP recover • Cross layer optimise recovery • RTP/UDP don’t care… • Or use Multipath TCP and just add subpath transparently (make before break, though)

  8. What about both ends move? • In a way, unusual! • But if routers are also part of movement, then very “ad hoc” world - so • Make hosts routers • Believe their route updates… • Use App level recovery, or MPTCP make before break • What about new clients of re-moved servers?

  9. Alt 2 - change TCP • TCP shares state with routers today in Compressed header case • So why not cache this info • When you move, send a “SYN” packet from new addr with compressed state reset to other end (if it hasn’t moved) • And copy to router where we _were_(*) • If it has moved, then the router there • Which should have state(*) to forward it • Could generalise for all bi-dir protocols (most transport protocols have roughly symmetric packet counts)

  10. DNS • DNS update with TTL 0 is • not that big a deal! • Even the whole DNS Update rate on one large site isn’t that big a deal • www.tjd.phlegethon.org/words/thesis.pdf • Experimental results (see • Naming for Networking byAtkinson&Bhatti • http://www.cs.st-andrews.ac.uk/~saleem/publications.html • http://portal.acm.org/citation.cfm?id=1298105

  11. DNS Update rate • Locality? • In london, 10M people move over 1 hour in commute • 10^7/60*60 <10000 updates per second • This is trivial to run a transaction (secure DynDNS) for on a single machine…

  12. New topic: Scaling == Complexity? • When we ask if an architecture, system or protocol scales, what do we mean? • Computer Science defines complexity • In terms of incremental cost of algorithm in terms of input scale - e.g. • Dijkstra is O(n^2) cpu in number of routers • Link state is O(E) msgs in number of edges • A FIB might be O(ln(n)) memory re: routers

  13. Other types of complexity? • Yes - emergent properties • Synchronisation effects • Routng update-resonance • Phase shifts • Most long flow or most short (tcp congestion control regimes) • Different operating regimes • Most web data cacheable, verus most dynamic • Interactions - • Scanning worm versus routing updates • Epidemic, Pandemic, no spread • Susceptibility, Infectious, Recover, Mortality? • Other?

  14. Complex versus Complicated? • Some stuff is complicated • E.g. network configuration (CLI/IOS) • Important, but not really amenable to much CS • But could undermine safety • C.f. BGP misconfigs locally disrupt global system. • Other eg.??

  15. Next talk for 2/11/10 Naming in the Internet has been unchanged since Original DNS design, largely Look at Intential Names and Content Centric Names And discuss what new benefits they bring beyond The DNS!

More Related