1 / 22

Network Architecture (R02) #4 Names, Places and Identity

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

triage
Download Presentation

Network Architecture (R02) #4 Names, Places and Identity

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) #4Names, Places and Identity Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22 http://www.cl.cam.ac.uk/teaching/1112/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. Old Name Spaces 1 • Hosts.txt • Update → send new entry to FTP.ISI.ARPA • Distribution → FTP to * (Broadcast) • How is this different from *.com? • The Main Name Service • Note risks of root → Verisign accidental deletion of entire database • Risk worse if TTL for Rrs set to 0 !

  16. Old Name Spaces 2 • X.500 Directory • Tree Structure (like DNS) • Distributed and Delegated • Content = (Attrib, Value)* • Can wildcard lookup attributes == SEARCH! • Update has secure per record locks

  17. Old Name Spaces 3 • DNS Hackery... • Rotaries • What is returned on each call varies • Load balancer • Hide mobility or failures • No interface for policy (backdoor hack) • Requires low(0?) to stop cacheing interfereing with LB

  18. Old Name Spaces 4 • DynDNS • Allow rapid update • Controlled more at leaves of system • Used by bad guys (e.g. botnets IRC controllers find bots via Dyn DNS) • Secure DNS • Update (not just edit named boot file and kill -restart:) Better be secure • Needs key distribution architecture • Better not have cyclic dependency between key and dyndns/update :-(

  19. INS + CCN • Binding • Design, Code, Compile, Link, Load/Run, Call • What, Where and When... • Semantics of thing returned • Dynamicity? • Use? Esp. Update rate/churn in map • INS looks like evolution • CCN looks like revolution • CCN does a lot of other things too...

  20. INS limits • Self org – why not use CAN, Chord etc? • Looks like directory too • Search efficiency? • Churn etc/ambiguity • See X.500/LDAP experiences... • See also Appletalk :-)

  21. CCN – What are people lookin for? • Many URLs (dynamic web page) name content • So make this first class thing • Most content is already replicated • “finding” replica is a DNS hack • e.g. LB or Akamaized URLs • => So make this hack part of architecture • Fix limits • (content not just@source or • fully replicated (akamai/youtube limited model) • See also Multicast and Pub/Sub • But promote “cache” and “router” to be same thing

  22. CCN problems? • Integrity (pollution proof) HH • Need to have hash/MIC on set of blocks • And not break if “bad” block inserted • Privacy of Subscription HC • Need to match interest to datum • Equiv. To tag matching in encrypted domain • Is x=y, when X and Y both crypted • Computationally expensive... • Some new results on homomorphic cryptography promising

More Related