Part 1: Design Principles

1. Goals: identify, study common architectural components, protocol mechanisms what approaches do we find in network architectures? synthesis: big picture 7 design principles: separation of data, control hard state versus soft state randomization indirection network virtualization: overlays multiplexing design for scale Part 1: Design Principles

2. 4: Indirection Indirection: rather than reference an entity directly, reference it (“indirectly) via another entity, which in turn can or will access the original entity "Every problem in computer science can be solved by adding another level of indirection" -- Butler Lampson x A B

3. Multicast: act of sending datagram to multiple receivers with single “transmit” operation Question: how to achieve multicast Multicast: one sender to many receivers Network multicast • router actively participate in multicast, making copies of packets as needed and forwarding towards multicast receivers Multicast routers (red) duplicate and forward multicast datagrams

4. Internet Multicast Service Model 128.59.16.12 multicast group concept: use of indirection • hosts addresses IP datagram to multicast group • routers forward multicast datagrams to hosts that have “joined” that multicast group 128.119.40.186 multicast group 226.17.30.197 128.34.108.63 128.34.108.60

5. Multicast via Indirection: why?

6. How do you contact a mobilefriend? Mobility and Indirection • search all phone books? • call her parents? • expect her to let you know where he/she is? I wonder where Alice moved to? Consider friend frequently changing addresses, how do you find her?

7. Mobility and indirection: • mobile node moves from network to network • correspondents want to send packets to mobile node • two approaches: • indirect routing: communication from correspondent to mobile goes through home agent, then forwarded to remote • direct routing: correspondent gets foreign address of mobile, sends directly to mobile

8. Mobility: Vocabulary home network: permanent “home” of mobile (e.g., 128.119.40/24) home agent: entity that will perform mobility functions on behalf of mobile, when mobile is remote wide area network permanent address: address in home network, can always be used to reach mobile e.g., 128.119.40.186

9. Mobility: more vocabulary visited network: network in which mobile currently resides (e.g., 79.129.13/24) permanent address: remains constant (e.g., 128.119.40.186) care-of-address: address in visited network. (e.g., 79,129.13.2) wide area network foreign agent: entity in visited network that performs mobility functions on behalf of mobile. correspondent: wants to communicate with mobile

10. mobile contacts foreign agent on entering visited network foreign agent contacts home agent home: “this mobile is resident in my network” 1 2 Mobility: registration visited network home network End result: • foreign agent knows about mobile • home agent knows location of mobile wide area network

11. foreign agent receives packets, forwards to mobile home agent intercepts packets, forwards to foreign agent correspondent addresses packets using home address of mobile mobile replies directly to correspondent 3 2 4 1 Mobility via Indirect Routing visited network home network wide area network

12. Indirect Routing: comments • mobile uses two addresses: • permanent address: used by correspondent (hence mobile location is transparent to correspondent) • care-of-address: used by home agent to forward datagrams to mobile • foreign agent functions may be done by mobile itself • triangle routing: correspondent-home-network-mobile • inefficient when correspondent, mobile are in same network

13. Indirect Routing: moving between networks • suppose mobile user moves to another network • registers with new foreign agent • new foreign agent registers with home agent • home agent update care-of-address for mobile • packets continue to be forwarded to mobile (but with new care-of-address) • mobility, changing foreign networks transparent: ongoing connections can be maintained!

14. foreign agent receives packets, forwards to mobile mobile replies directly to correspondent 4 2 4 1 3 Mobility via Direct Routing correspondent forwards to foreign agent visited network home network wide area network correspondent requests, receives foreign address of mobile

15. Mobility via Direct Routing: comments • overcomes triangle routing problem • non-transparent to correspondent: correspondent must get care-of-address from home agent • what happens if mobile changes networks?

16. Mobile IP • RFC 3220 • has many features we’ve seen: • home agents, foreign agents, foreign-agent registration, care-of-addresses, encapsulation (packet-within-a-packet) • three components to standard: • agent discovery • registration with home agent • indirect routing of datagrams

17. Mobility via indirection: why indirection? • transparency to correspondent • “mostly” transparent to mobile (except mobile must register with foreign agent) • transparent to routers, rest of infrastructure • potential concerns if egress filtering is in place in oreign networks (since source IP address of mobile is its home address): spoofing?

18. Secure Overlay Service SoS:an overlay network, using indirection, randomization to provide legitimate users with denial-of-service free access to a server Overlay network: • network or distributed infrastructure with common network services (e.g., routing) built “on top” of other networks • example: distributed application in which application-layer nodes relay messages among themselves, using underlying IP routing to get from one site to another

19. Performing a DoS Attack • select target to attack break into accounts around network have accounts send packets to target

20. Goal of Secure Overlay Service (SoS) • pre-approved legitimate users communicate with target • legit users may be mobile (IP addresses change) • un-approved (attackers’) packets don’t reach target attackers legit user target

21. Filter Step 1 - Filtering routers “near” target filter packets based on IP addr • IP addresses from legitimate user allowed through • IP addresses from illegitimate users are not Concerns: • bad users have same IP address as good user? • bad users know good user’s IP address: spoofing? • good IP address changes frequently (mobility)?

22. Filter w.x.y.z Step 2 – indirection via a proxy Use proxy, outside filtered region • proxy, being a computer (rather than router) can perfom heavy-weight authentication, access control • only packets from proxy permitted through filter • proxy only forwards verified packets from legitimate sources through filter

23. I’m w.x.y.z I’m w.x.y.z I’m w.x.y.z Filter Problems with a known Proxy Proxies introduce other problems • attacker can breach filter by attacking with spoofed proxy address • attacker can DoS attack proxy, again preventing legitimate user communication w.x.y.z

24. Step 3 – Multiple proxies with secret forwarding • create many proxies (too many to attack) • target specifies small set of proxies as secret forwarders • only secret-forwarder packets pass through filter • only secret forwarders know they are secret forwarders (other proxies unaware) • to get host packet to target • host contacts any proxy (which checks legitimacy) • proxy randomly routes packet to another proxy • if destination proxy is secret forwarder, packet forwarded to target, otherwise packet randomly routed to another proxy Note: use of randomization 

25. secret forwarder Filter proxy SOS with “Random” routing ? With filters, multiple proxies, and secret forwarder(s), attacker cannot “focus” attack

26. SoS Why indirection? • ultimate destination address is unknown (hackers can not attack target, only attack proxies (?) • address of target only known to small number of secret forwarders, which rotate and can change Issues: • why can’t hacker just try all addresses of all proxies to get through?

27. An Internet Indirection Infrastructure Motivation: • today’s Internet is built around point-to-point communication abstraction: • send packet “p” from host “A” to host “B” • one sender, one receiver, at fixed and well-known locations • … not appropriate for applications that require other communications primitives: • multicast (one to many) • mobility (one to anywhere) • anycast (one to any) • we’ve seen indirection used to provide these services • idea: make indirection a “first-class object”

28. send(R, data) send(ID, data) trigger ID R Internet Indirection Infrastructure (i3) • change communication abstraction: instead of point-to-point, exchange packets by name • each packet has an identifier ID • to receive packet with identifier ID, receiver R stores trigger (ID, R) into network • triggers stored in network overlay nodes Sender Receiver (R)

29. Note: use of soft-state. Why? Service Model • API • sendPacket(p); • insertTrigger(t); • removeTrigger(t); // optional • best-effort service model (like IP) • triggers periodically refreshed by end-hosts • reliability, congestion control, flow-control implemented at end hosts, and trigger-storing overlay nodes

30. Discussion • trigger is similar to routing table entry • essentially: application layer publish-subscribe infrastructure • application-level overlay infrastructure • unlike IP, end hosts control triggers, i.e., end hosts responsible for setting and maintaining “routing tables” • provide support for • mobility • multicast • anycast • composable services

31. send(R1, data) send(ID,data) Mobility • receiver updates its trigger as it moves from one subnet to another • mobility transparent to sender • location privacy Receiver (R1) Sender trigger ID R1

32. send(ID,data) send(R2, data) (new) trigger Mobility • receiver updates its trigger as it moves from one subnet to another • mobility transparent to sender • location privacy Sender ID R2 Receiver (R2)

33. Multicast • unifies multicast and unicast abstractions • multicast: receivers insert triggers with same ID • application naturally moves between multicast and unicast, as needed • “impossible” in current IP model send(R1, data) send(ID,data) ID R1 Receiver (R1) Sender ID R2 send(R2, data) Receiver (R2)

34. Anycast (cont’d) • route to any one in set of receivers • receiver i in anycast group inserts same ID, with anycast qualifications • route to receiver with best match between a and si send(R1,data) Receiver (R1) ID|s1 R1 send(ID|a,data) ID|s2 R2 Sender Receiver (R2) ID|s3 R3 Receiver (R3)

35. send((ID_MPEG/JPEG,ID), data) send(R, data) send(ID, data) Composable Services • use stack of IDs to encode successive operations to be performed on data (e.g., transcoding) • don’t need to configure path between services S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) ID R S_MPEG/JPEG ID_MPEG/JPEG

36. send(R, data) send(ID, data) send((ID_MPEG/JPEG, R), data) Composable Services (cont’d) • both receivers and senders can specify operations to be performed on data S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) S_MPEG/JPEG ID_MPEG/JPEG ID (ID_MPEG/JPEG, R)

37. Discussion of I3 • how would receiver signal ACK to sender? what is needed? • does many-to-one fit well in this paradigm? • security, snooping, information gathering: what are the issues?

38. Indirection: Summary We’ve seen indirection used in many ways: • multicast • mobility • SoS • Internet indirection The uses of indirection: • sender does not need to know receiver id - do not want sender to know intermediary identities • beauty, grace, elegance • transparency of indirection is important • performance: is it more efficient? • security: important issue for I3

39. 5. Virtualization of networks Virtualization of resources: powerful abstraction in systems engineering: • computing examples: virtual memory, virtual devices • virtual machines: e.g., java • IBM VM os from 1960’s/70’s • layering of abstractions: don’t sweat the details of the lower layer, only deal with lower layers abstractly

40. The Internet: virtualizing local networks 1974: multiple unconnected networks • ARPAnet • data-over-cable networks • packet satellite network (Aloha) • packet radio network .. differing in: • addressing conventions • packet formats • error recovery • routing

41. Cerf & Kahn: Interconnecting two networks • “…interconnection must preserve intact the internal operation of each network.” • “ ..the interface between networks must play a central role in the development of any network interconnection strategy. We give a special name to this interface that performs these functions and call it a GATEWAY.” • “.. prefer that the interface be as simple and reliable as possible, and deal primarily with passing data between networks that use different packet-switching strategies • “…address formats is a problem between networks because the local network addresses of TCP's may vary substantially in format and size. A uniform internetwork TCP address space, understood by each GATEWAY and TCP, is essential to routing and delivery of internetwork packets.” satellite net ARPAnet

42. Internetwork layer: • addressing: internetwork appears as a single, uniform entity, despite underlying local network heterogeneity • network of networks Cerf & Kahn: Interconnecting two networks Gateway: • “embed internetwork packets in local packet format or extract them” • route (at internetwork level) to next gateway gateway satellite net ARPAnet

43. source address local header dest. address flag field byte count text checksum seq. # TCP identifier network 8 16 Historical Aside: Proposed Internetwork packet in 1974:

44. Cerf & Kahn’s Internetwork Architecture What is virtualized? • two layers of addressing: internetwork and local network • new layer makes everything homogeneous at internetwork layer • underlying local network technology (cable, satellite, 56K modem) is “invisible” at internetwork layer

45. IP-Over-ATM IP over ATM • replace “network” (e.g., LAN segment) with ATM network • ATM addresses, IP addresses Classic IP only • 3 “networks” (e.g., LAN segments) • MAC (802.3) and IP addresses ATM network Ethernet LANs Ethernet LANs

46. app transport IP AAL ATM phy app transport IP Eth phy ATM phy ATM phy IP AAL ATM phy Eth phy IP-Over-ATM

47. IP View of the world IP network ATM network

48. Classical IP-over ATM [RFC 1577] LIS: logical IP subnet • end systems in same LIS have same IP network addr • LIS looks like a LAN • ATM net divided into multiple LIS • Intra-LIS communication via direct ATM connections • How to go from IP addr to ATM addr: ATMARP resolves IP addr to ATM addr (similar to ARP) C D B E A LIS2 LIS1 LIS3 R2 R1

49. Classical IP-over ATM [RFC 1577] Inter-LIS communication: • source, dest. in different LIS • each LIS looks like a LAN • hop-by hop forwarding: • A-R1-R2-B C D B E A LIS2 LIS1 LIS3 R2 R1

50. C D B E A LIS2 LIS1 LIS3 NHRP server, S1 NHRP server, S3 NHRP server, S2 NHRP (next hop resolution protocol) [RFC 2332] • source/dest. not in same LIS: ATMARP can not provide ATM dest. address • NHRP: resolve IP-to-ATM address of remote dest. • client queries local NHRP server • NHRP server routes NHRP request to next NHRP server • destination NHRP returns dest ATM address back through NHRP server chain (like routed DNS) • source can send directly to dest. using provided ATM address “ARP over multiple hops”