What does it take to define an architecture? (Part 2)

1. What does it take to define an architecture? (Part 2) David D. Clark July, 2012

2. Describing an architecture • IETF has published over 6630 RFCs. • Too much, for sure. • A CCR paper proposed a minimalist answer in 6 pages*. • Enough? * Koponen, T., S. Shenker, et al. (2011). "Architecting for innovation." SIGCOMM Comput. Commun. Rev. 41(3): 24-36.

3. What needs to be specified? • Primary specifications: • Those things about which we all have to agree on the same answer. • Secondary specifications: • Those things about which it is convenient/necessary to have a common agreement, but there can be more than one answer.

4. The current Internet as example • TCP: secondary • DNS: secondary • IP: primary, but • Global address space: we thought so, but no. • TTL semantics: primary, but not important. • What actually matters?

5. Look at the IP address • We thought it had to represent a global address space. • Then we got NATs, intranets, etc. • We thought it addressed a port on a host. • Then we did multicast, anycast, etc. • What is the persistent constraint? • It is 32 bits long.

6. The actual semantics of IP • The IP address field, at each end of the connection, must remain constant for a given connection. • But the TCP pseudo-header was a bad idea. • But see discussion of security. • The IP address field can be rewritten anywhere in the network, so long as: • The rewriting complies with rule 1. • There is matching routing state in the region routers. • That is the core of the Internet: the primary specification. • A painful discovery.

7. Packet forwarding • In some respects, this is “all” that a network does. • What else actually matters? • Go back to that CCR paper.

8. Framework for Internet Innovation (FII) • Define the service provided • They propose an API with version number. • Version number primary, API secondary. • Warning: IP has a version number. Not enough… • Support inter-domain routing • They propose pathlets*. • Support security/availability • They conclude DDoS is the only issue. • Availability may imply other requirements. * P. B. Godfrey, I. Ganichev, S. Shenker, and I. Stoica. Pathlet Routing. In Proc. SIGCOMM, 2009.

9. What is missing? • Packet format and how forwarding works. • Their claim: packets can look different in different parts of the network. • How forwarding/addressing state is managed is a regional matter. • (Too optimistic: does not really solve migration.) • Resource management. • They say multiplexing and QoS is a regional matter. • (I do not agree: need inter-region interface.)

10. Summary of minimalist view • Agreement on the service model. • Inter-region interface specifications • Routing • Resource allocation • Tools to support availability • Tools to support anti-availability (DDoS)

11. Courtesy of Pamela Zave, AT&T

12. What might we conclude • The minimalist approach was about the base set of primary specifications to allow evolution. • Has nothing to say about what we actually build at any one time. • Begs the question: what aspects of what networks actually do should be recognized in their core design.

13. Generalize/formalize • Generalize what a “router” does: • Per-hop behavior (PHB). • Simple forwarding • Authorization (indirection, capabilities) • Encryption • Overlay/tunnel (e.g. TOR) • Inspection/blocking (e.g. firewall) • Resource management • Redirection (e.g. mobility) • Successful operation (but what does that mean?) occurs when the forwarding mechanisms have connected the intended set of PHBs in the right order.

14. Tussle • Network delivery is a adversarial game. • Sender, receiver, ISPs, third parties all have preferred outcomes. • Sender and receiver may be aligned (normal) or not (attack). • ISPs may be aligned with users (normal) or not (blocking content, etc.) • Third parties (e.g. governments, rights-holders, employers) may attempt to intervene.

15. Composing PHBs • Each PHB: • Executes its internal operation • Compute the correct forwarding to the next PHB. • If a PHB can compute “anything”, is this some sort of generalized processor? • Perhaps, but composed out of steps that are adversarial. • Ross Anderson: “Programming Satan’s computer”.

16. How to use forwarding tools • Sender picks the PHBs • Source routing, TOR, etc. • The PHB (the network) picks the next PHB • Normal IP routing (explicit L2 addresses) • MPLS (explicit labels) • The topology picks the next PHB • Firewall (representing the interests of the receiver). • The receiver coerces the sender to pick • Indirection, capabilities.

17. And my conclusion? • If “forwarding” is all a network does, forwarding is a complex process. • Many goals, many actors. • We have a choice of incorporating this complexity inside the design, or having the design be only part of the larger outcome that addresses the complexity. • Zave again…

18. Security—the recurring theme • Security (however we choose to define it) is one of the things we did not understand in the 1970’s. • Any proposal to improve the Internet must have better security as a key objective. • But note earlier comments that we still don’t understand the topic. • It would be easy to design an Internet if all the parts could be trusted to do the right thing.