Design guidelines for robust Internet protocols

ABSTRACT

Robustness has long been a central design goal of the Internet. Much of the initial effort towards robustness focusedon the "fail-stop" model, where node failures are complete and easily detectable by other nodes. The Internet is quite robust against such failures, routinely surviving various catastrophes with only limited outages. This robustness is largely due to the widespread belief in a set of guidelines for critical design decisions such as where to initiate recovery and how to maintain state.However, the Internet remains extremely vulnerable to more arbitrary failures where, through either error or malice, a node issues syntactically correct responses that are not semantically correct. Such failures, some as simple as misconfigured routing state, can seriously undemnine the functioning of the Internet. With the Internet playing such a central role in the global telecommunications infrastructure, this level of vulnerability is no longer acceptable.In this paper we argue that to make the Internet more robust to these kinds of arbitrary failures, we need to change the way we design network protocols. To this end, we propose a set of six design guidelines for improving the network protocol design. These guidelines emerged from a study of past examples of failures, and determining what could have been done to prevent the problem from occurring in the first place. The unifying theme behind the various guidelines is that we need to design protocols more defensively, expecting malicious attack, misimplementation, and misconfiguration at every turn.

REFERENCES

• 1: Martín Abadi , Roger Needham, Prudent Engineering Practice for Cryptographic Protocols, IEEE Transactions on Software Engineering, v.22 n.1, p.6-15, January 1996 [doi>10.1109/32.481513 ]
• 2: T. Bates, R. Chandra, and E. Chen. BGP route reflection - an alternative to full mesh IBGP. RFC 2796, IETF, Apr. 2000.
• 3: D. J. Bernstein. SYN cookies. http://cr.yp.to/syncookies.html, 1996.
• 4: R. Braden. Requirements for Internet hosts -- communication layers. RFC 1122, IETF, Oct. 1989.
• 5: Michael Burrows , Martin Abadi , Roger Needham, A logic of authentication, ACM Transactions on Computer Systems (TOCS), v.8 n.1, p.18-36, Feb. 1990 [doi>10.1145/77648.77649]
• 6: Miguel Castro , Barbara Liskov, Practical Byzantine fault tolerance, Proceedings of the third symposium on Operating systems design and implementation, p.173-186, February 1999, New Orleans, Louisiana, United States
• 7: CERT advisory ca-1996-21 TCP SYN flooding and IP spoofing attacks. http://www.cert.org/advisories/CA-1996-21.html, Sep. 1996.
• 8: Cisco security advisory: Cisco ISO BGP attribute corruption vulnerability. http://www.cisco.com/warp/public/707/ios-bgp-attr-corruption-pub.shtml, May 2001.
• 9: D. Clark, The design philosophy of the DARPA internet protocols, Symposium proceedings on Communications architectures and protocols, p.106-114, August 16-18, 1988, Stanford, California, United States
• 10: Jim Cowie, Andy Ogielski, BJ Premore, and Yougu Yuan. Global routing instabilities during Code Red II and Nimda worm propagation. http://www.renesys.com/projects/bgp_instability, Oct. 2001.
• 11: Flavin Cristian, Understanding fault-tolerant distributed systems, Communications of the ACM, v.34 n.2, p.56-78, Feb. 1991 [doi>10.1145/102792.102801]
• 12: Ramesh Govindan Curtis Villamizar, Ravi Chandra. BGP route flap damping. RFC 2439, IETF, Nov. 1998.
• 13: Robust Congestion Signaling, Proceedings of the Ninth International Conference on Network Protocols, p.332, November 11-14, 2001
• 14: Jim Farrar. C&W routing instability. NANOG mail archives, Apr. 2001. http://www.merit.edu/mail.archives/nanog/2001-04/msg00209.html.
• 15: Gerard J. Holzmann, The Model Checker SPIN, IEEE Transactions on Software Engineering, v.23 n.5, p.279-295, May 1997 [doi>10.1109/32.588521 ]
• 16: Phil Karn and William Allen Simpson. Photuris: Session-key management protocol. RFC 2522, IETF, March 1999.
• 17: Leslie Lamport , Robert Shostak , Marshall Pease, The Byzantine Generals Problem, ACM Transactions on Programming Languages and Systems (TOPLAS), v.4 n.3, p.382-401, July 1982 [doi>10.1145/357172.357176]
• 18: Matt Levine. BGP noise tonight? NANOG mail archives, Oct. 2001. http://www.merit.edu/mail.archives/nanog/2001-10/msg00221.html.
• 19: Steve Maguire, Writing solid code: Microsoft's techniques for developing bug-free programs, Microsoft Press, Redmond, WA, 1993
• 20: Ratul Mahajan , David Wetherall , Tom Anderson, Understanding BGP misconfiguration, Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications, August 19-23, 2002, Pittsburgh, Pennsylvania, USA
• 21: M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP selective acknowledgement options. RFC 2018, IETF, April 1996.
• 22: Danny McPherson, Vijay Gill, Daniel Walton, and Alvaro Retana. BGP persistent route oscillation condition. Internet Draft draft-mcpherson-bgp-route-oscillation-01.txt, IETF, March 2001.
• 23: Stephen A Misel. Wow, AS7007! NANOG mail archives, Apr. 1997. http://www.merit.edu/mail.archives/nanog/1997-04/msg00340.html.
• 24: J. Postel. Internet Protocol (IP). RFC 791, IETF, Sept. 1981.
• 25: K. Ramakrishnan, Sally Floyd, and D. Black. The addition of explicit congestion notification (ECN) to IP. RFC 3168, IETF, Sep. 2001.
• 26: Peter Salus. The Internet under stress. Talk at NANOG 23, Oct. 2001.
• 27: Stefan Savage , Neal Cardwell , David Wetherall , Tom Anderson, TCP congestion control with a misbehaving receiver, ACM SIGCOMM Computer Communication Review, v.29 n.5, October 1999 [doi>10.1145/505696.505704]
• 28: Jonathan Stone and Craig Partridge. When the checksum and the data disagree. In ACM SIGCOMM, Aug. 2000.

INDEX TERMS

Primary Classification:
  C. Computer Systems Organization
  C.4 PERFORMANCE OF SYSTEMS
      Subjects: Reliability, availability, and serviceability

Additional Classification:
  C. Computer Systems Organization
  C.2 COMPUTER-COMMUNICATION NETWORKS
      C.2.5 Local and Wide-Area Networks
          Subjects: Internet (e.g., TCP/IP)
  C.4 PERFORMANCE OF SYSTEMS
      Subjects: Performance attributes

General Terms:
Documentation, Experimentation, Reliability