Security Mechanisms for the Internet
RFC 3631

Document Type RFC - Informational (December 2003; No errata)
Last updated 2013-03-02
Stream IAB
Formats plain text pdf html bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
Network Working Group                                   S. Bellovin, Ed.
Request for Comments: 3631                              J. Schiller, Ed.
Category: Informational                                  C. Kaufman, Ed.
                                             Internet Architecture Board
                                                           December 2003

                  Security Mechanisms for the Internet

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Security must be built into Internet Protocols for those protocols to
   offer their services securely.  Many security problems can be traced
   to improper implementations.  However, even a proper implementation
   will have security problems if the fundamental protocol is itself
   exploitable.  Exactly how security should be implemented in a
   protocol will vary, because of the structure of the protocol itself.
   However, there are many protocols for which standard Internet
   security mechanisms, already developed, may be applicable.  The
   precise one that is appropriate in any given situation can vary.  We
   review a number of different choices, explaining the properties of
   each.

1.  Introduction

   Internet Security compromises can be divided into several classes,
   ranging from Denial of Service to Host Compromise.  Denial of Service
   attacks based on sheer volume of traffic are beyond the scope of this
   document, though they are the subject of much ongoing discussion and
   research.  It is important to note that many such attacks are made
   more difficult by good security practices.  Host Compromise (most
   commonly caused by undetected Buffer Overflows) represent flaws in
   individual implementations rather than flaws in protocols.
   Nevertheless, carefully designed protocols can make such flaws less
   likely to occur and harder to exploit.

Bellovin, et al.             Informational                      [Page 1]
RFC 3631          Security Mechanisms for the Internet     December 2003

   However, there are security compromises that are facilitated by the
   very protocols that are in use on the Internet.  If a security
   problem is inherent in a protocol, no manner of implementation will
   be able to prevent the problem.

   It is therefore vitally important that protocols developed for the
   Internet provide this fundamental security.

   Exactly how a protocol should be secured depends on the protocol
   itself as well as the security needs of the protocol.  However, we
   have developed a number of standard security mechanisms in the IETF.
   In many cases appropriate application of these mechanisms can provide
   the necessary security for a protocol.

   A number of possible mechanisms can be used to provide security on
   the Internet.  Which one should be selected depends on many different
   factors.  We attempt here to provide guidance, spelling out the
   factors and the currently-standardized (or about-to-be-standardized)
   solutions, as discussed at the IAB Security Architecture Workshop
   [RFC2316].

   Security, however, is an art, not a science.  Attempting to follow a
   recipe blindly can lead to disaster.  As always, good taste in
   protocol design should be exercised.

   Finally, security mechanisms are not magic pixie dust that can be
   sprinkled over completed protocols.  It is rare that security can be
   bolted on later.  Good designs -- that is, secure, clean, and
   efficient designs -- occur when the security mechanisms are crafted
   along with the protocol.  No conceivable exercise in cryptography can
   secure a protocol with flawed semantic assumptions.

2.  Decision Factors

2.1.  Threat Model

   The most important factor in choosing a security mechanism is the
   threat model.  That is, who may be expected to attack what resource,
   using what sorts of mechanisms?  A low-value target, such as a Web
   site that offers public information only, may not merit much
   protection.  Conversely, a resource that if compromised could expose
   significant parts of the Internet infrastructure, say, a major
   backbone router or high-level Domain Name Server, should be protected
   by very strong mechanisms.  The value of a target to an attacker
   depends on the purpose of the attack.  If the purpose is to access
   sensitive information, all systems that handle this information or
   mediate access to it are valuable.  If the purpose is to wreak havoc,
   systems on which large parts of the Internet depend are exceedingly

Bellovin, et al.             Informational                      [Page 2]
Show full document text