rfc.bib

@techreport{rfc1579,
  title = {{Firewall-Friendly FTP}},
  year = 1994,
  month = {February},
  date = {1994-02},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1579,
  rfckey = {RFC1579},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc1579},
  doi = {10.17487/RFC1579},
  abstract = { This memo describes a suggested change to the behavior of
		  FTP client programs. This document provides information for
		  the Internet community. This memo provides information for
		  the Internet community. This memo does not specify an
		  Internet standard of any kind. }
}

@techreport{rfc1675,
  title = {{Security Concerns for IPng}},
  year = 1994,
  month = {August},
  date = {1994-08},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1675,
  rfckey = {RFC1675},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc1675},
  doi = {10.17487/RFC1675},
  abstract = { A number of the candidates for IPng have some features
		  that are somewhat worrisome from a security perspective.
		  While it is not necessary that IPng be an improvement over
		  IPv4, it is mandatory that it not make things worse. This
		  memo provides information for the Internet community. This
		  memo does not specify an Internet standard of any kind. }
}

@techreport{rfc1681,
  title = {{On Many Addresses per Host}},
  year = 1994,
  month = {August},
  date = {1994-08},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1681,
  rfckey = {RFC1681},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc1681},
  doi = {10.17487/RFC1681},
  abstract = { This document was submitted to the IETF IPng area in
		  response to RFC 1550.This memo provides information for the
		  Internet community. This memo does not specify an Internet
		  standard of any kind. }
}

@techreport{rfc1948,
  title = {{Defending Against Sequence Number Attacks}},
  year = 1996,
  month = {May},
  date = {1996-05},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1948,
  rfckey = {RFC1948},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc1948},
  doi = {10.17487/RFC1948},
  abstract = { IP spoofing attacks based on sequence number spoofing
		  have become a serious threat on the Internet (CERT Advisory
		  CA-95:01). While ubiquitous crypgraphic authentication is
		  the right answer, we propose a simple modification to TCP
		  implementations that should be a very substantial block to
		  the current wave of attacks. This memo provides information
		  for the Internet community. This memo does not specify an
		  Internet standard of any kind. }
}

@techreport{rfc2316,
  title = {{Report of the IAB Security Architecture Workshop}},
  year = 1998,
  month = {April},
  date = {1998-04},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 2316,
  rfckey = {RFC2316},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc2316},
  doi = {10.17487/RFC2316},
  abstract = { On 3-5 March 1997, the IAB held a security architecture
		  workshop at Bell Labs in Murray Hill, NJ. We identified the
		  core security components of the architecture, and specified
		  several documents that need to be written. Most
		  importantly, we agreed that security was not optional, and
		  that it needed to be designed in from the beginning. This
		  memo provides information for the Internet community. It
		  does not specify an Internet standard of any kind. }
}

@techreport{rfc2458,
  title = {{Toward the PSTN/Internet Inter-Networking--Pre-PINT
		  Implementations}},
  year = 1998,
  month = {November},
  date = {1998-11},
  author = {H. Lu and M. Krishnaswamy and L. Conroy and Steven M.
		  Bellovin and F. Burg and A. DeSimone and K. Tewani and P.
		  Davidson and H. Schulzrinne and K. Vishwanathan},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 2458,
  rfckey = {RFC2458},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc2458},
  doi = {10.17487/RFC2458},
  abstract = { This document contains the information relevant to the
		  development of the inter-networking interfaces underway in
		  the Public Switched Telephone Network (PSTN)/Internet
		  Inter- Networking (PINT) Working Group. This memo provides
		  information for the Internet community. }
}

@techreport{rfc3514,
  title = {{The Security Flag in the IPv4 Header}},
  year = 2003,
  month = {April 01,},
  date = {2003-04-01},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 3514,
  rfckey = {RFC3514},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc3514},
  doi = {10.17487/RFC3514},
  abstract = { Firewalls, packet filters, intrusion detection systems,
		  and the like often have difficulty distinguishing between
		  packets that have malicious intent and those that are
		  merely unusual. We define a security flag in the IPv4
		  header as a means of distinguishing the two cases. This
		  memo provides information for the Internet community. }
}

@techreport{rfc3554,
  title = {{On the Use of Stream Control Transmission Protocol (SCTP)
		  with IPsec}},
  year = 2003,
  month = {July},
  date = {2003-07},
  author = {Steven M. Bellovin and J. Ioannidis and A. Keromytis and
		  R. Stewart},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 3554,
  rfckey = {RFC3554},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc3554},
  doi = {10.17487/RFC3554},
  abstract = { This document describes functional requirements for IPsec
		  (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to
		  facilitate their use in securing SCTP (RFC 2960) traffic.
		  }
}

@techreport{rfc3631,
  title = {{Security Mechanisms for the Internet}},
  year = 2003,
  month = {December},
  date = {2003-12},
  editor = {Steven M. Bellovin and Jeffrey I. Schiller and Charlie
		  Kaufman},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 3631,
  rfckey = {RFC3631},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc3631},
  doi = {10.17487/RFC3631},
  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. }
}

@techreport{rfc4107,
  title = {{Guidelines for Cryptographic Key Management}},
  year = 2005,
  month = {June},
  date = {2005-06},
  author = {Steven M. Bellovin and Russ Housley},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 4107,
  rfckey = {RFC4107},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc4107},
  doi = {10.17487/RFC4107},
  abstract = { The question often arises of whether a given security
		  system requires some form of automated key management, or
		  whether manual keying is sufficient. This memo provides
		  guidelines for making such decisions. When symmetric
		  cryptographic mechanisms are used in a protocol, the
		  presumption is that automated key management is generally
		  but not always needed. If manual keying is proposed, the
		  burden of proving that automated key management is not
		  required falls to the proposer. This document specifies an
		  Internet Best Current Practices for the Internet Community,
		  and requests discussion and suggestions for improvements.
		  }
}

@techreport{rfc4278,
  title = {{Standards Maturity Variance Regarding the TCP MD5
		  Signature Option (RFC 2385) and the BGP-4 Specification}},
  year = 2006,
  month = {January},
  date = {2006-01},
  author = {Steven M. Bellovin and A. Zinin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 4278,
  rfckey = {RFC4278},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc4278},
  doi = {10.17487/RFC4278},
  abstract = { The IETF Standards Process requires that all normative
		  references for a document be at the same or higher level of
		  standardization. RFC 2026 section 9.1 allows the IESG to
		  grant a variance to the standard practices of the IETF.
		  This document explains why the IESG is considering doing so
		  for the revised version of the BGP-4 specification, which
		  refers normatively to RFC 2385, "Protection of BGP Sessions
		  via the TCP MD5 Signature Option". RFC 2385 will remain at
		  the Proposed Standard level. This memo provides information
		  for the Internet community. }
}

@techreport{rfc4808,
  title = {{Key Change Strategies for TCP-MD5}},
  year = 2007,
  month = {March},
  date = {2007-03},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 4808,
  rfckey = {RFC4808},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc4808},
  doi = {10.17487/RFC4808},
  abstract = { The TCP-MD5 option is most commonly used to secure BGP
		  sessions between routers. However, changing the long-term
		  key is difficult, since the change needs to be synchronized
		  between different organizations. We describe single-ended
		  strategies that will permit (mostly) unsynchronized key
		  changes. This memo provides information for the Internet
		  community. }
}

@techreport{rfc5406,
  title = {{Guidelines for Specifying the Use of IPsec Version 2}},
  year = 2009,
  month = {February},
  date = {2009-02},
  author = {Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 5406,
  rfckey = {RFC5406},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc5406},
  doi = {10.17487/RFC5406},
  abstract = { The Security Considerations sections of many Internet
		  Drafts say, in effect, "just use IPsec". While this is
		  sometimes correct, more often it will leave users without
		  real, interoperable security mechanisms. This memo offers
		  some guidance on when IPsec Version 2 should and should not
		  be specified. This document specifies an Internet Best
		  Current Practices for the Internet Community, and requests
		  discussion and suggestions for improvements. }
}

@techreport{rfc6528,
  title = {{Defending against Sequence Number Attacks}},
  year = 2012,
  month = {February},
  date = {2012-02},
  author = {F. Gont and Steven M. Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 6528,
  rfckey = {RFC6528},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc6528},
  doi = {10.17487/RFC6528},
  abstract = { This document specifies an algorithm for the generation
		  of TCP Initial Sequence Numbers (ISNs), such that the
		  chances of an off-path attacker guessing the sequence
		  numbers in use by a target connection are reduced. This
		  document revises (and formally obsoletes) RFC 1948, and
		  takes the ISN generation algorithm originally proposed in
		  that document to Standards Track, formally updating RFC
		  793. }
}

@techreport{rfc7353,
  title = {{Security Requirements for BGP Path Validation}},
  year = 2014,
  month = {August},
  date = {2014-08},
  author = {Steven M. Bellovin and R. Bush and D. Ward},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 7353,
  rfckey = {RFC7353},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc7353},
  doi = {10.17487/RFC7353},
  abstract = { This document describes requirements for a BGP security
		  protocol design to provide cryptographic assurance that the
		  origin Autonomous System (AS) has the right to announce the
		  prefix and to provide assurance of the AS Path of the
		  announcement. }
}

@techreport{rfc9446,
  title = {{Reflections on Ten Years Past the Snowden Revelations}},
  year = 2023,
  month = {July},
  date = {2023-07},
  author = {S. Farrell and F. Badii and B. Schneier and S. M.
		  Bellovin},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 9446,
  rfckey = {RFC9446},
  institution = {IETF},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/info/rfc9446},
  doi = {10.17487/RFC9446},
  abstract = { This memo contains the thoughts and recountings of events
		  that transpired during and after the release of information
		  about the United States National Security Agency (NSA) by
		  Edward Snowden in 2013. There are four perspectives: that
		  of someone who was involved with sifting through the
		  information to responsibly inform the public, that of a
		  security area director of the IETF, that of a human rights
		  expert, and that of a computer science and affiliate law
		  professor. The purpose of this memo is to provide some
		  historical perspective, while at the same time offering a
		  view as to what security and privacy challenges the
		  technical community should consider. These essays do not
		  represent a consensus view, but that of the individual
		  authors. }
}