rfc.bib

@techreport{rfc1579,
  title = {{Firewall-Friendly FTP}},
  year = 1994,
  month = {February},
  author = {S. Bellovin},
  pages = {1--4},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1579,
  key = {RFC1579},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc1579.txt},
  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},
  author = {S. Bellovin},
  pages = {1--4},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1675,
  key = {RFC1675},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc1675.txt},
  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},
  author = {S. Bellovin},
  pages = {1--5},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1681,
  key = {RFC1681},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc1681.txt},
  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},
  author = {S. Bellovin},
  pages = {1--6},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 1948,
  key = {RFC1948},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc1948.txt},
  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},
  author = {S. Bellovin},
  pages = {1--9},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 2316,
  key = {RFC2316},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc2316.txt},
  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},
  author = {H. Lu and M. Krishnaswamy and L. Conroy and S. Bellovin
		  and F. Burg and A. DeSimone and K. Tewani and P. Davidson
		  and H. Schulzrinne and K. Vishwanathan},
  pages = {1--60},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 2458,
  key = {RFC2458},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc2458.txt},
  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 1,},
  author = {S. Bellovin},
  pages = {1--6},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 3514,
  key = {RFC3514},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc3514.txt},
  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},
  author = {S. Bellovin and J. Ioannidis and A. Keromytis and R.
		  Stewart},
  pages = {1--9},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 3554,
  key = {RFC3554},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc3554.txt},
  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},
  editor = {S. Bellovin and J. Schiller and C. Kaufman},
  pages = {1--20},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 3631,
  key = {RFC3631},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc3631.txt},
  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},
  author = {S. Bellovin and R. Housley},
  pages = {1--7},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 4107,
  key = {RFC4107},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc4107.txt},
  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},
  author = {S. Bellovin and A. Zinin},
  pages = {1--7},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 4278,
  key = {RFC4278},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc4278.txt},
  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},
  author = {S. Bellovin},
  pages = {1--8},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 4808,
  key = {RFC4808},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc4808.txt},
  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},
  author = {S. Bellovin},
  pages = {1--13},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 5406,
  key = {RFC5406},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc5406.txt},
  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},
  author = {F. Gont and S. Bellovin},
  pages = {1--12},
  howpublished = {Internet Requests for Comments},
  type = {RFC},
  number = 6528,
  key = {RFC6528},
  publisher = {RFC Editor},
  institution = {RFC Editor},
  issn = {2070-1721},
  url = {http://www.rfc-editor.org/rfc/rfc6528.txt},
  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. }
}