S. Farrell, F. Badii, B. Schneier, and S. M. Bellovin. Reflections on Ten Years Past the Snowden Revelations. RFC 9446, IETF, July 2023. [ bib | DOI | http ]

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.

Steven M. Bellovin, R. Bush, and D. Ward. Security Requirements for BGP Path Validation. RFC 7353, IETF, August 2014. [ bib | DOI | http ]

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.

F. Gont and Steven M. Bellovin. Defending against Sequence Number Attacks. RFC 6528, IETF, February 2012. [ bib | DOI | http ]

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.

Steven M. Bellovin. Guidelines for Specifying the Use of IPsec Version 2. RFC 5406, IETF, February 2009. [ bib | DOI | http ]

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.

Steven M. Bellovin. Key Change Strategies for TCP-MD5. RFC 4808, IETF, March 2007. [ bib | DOI | http ]

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.

Steven M. Bellovin and A. Zinin. Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification. RFC 4278, IETF, January 2006. [ bib | DOI | http ]

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.

Steven M. Bellovin and Russ Housley. Guidelines for Cryptographic Key Management. RFC 4107, IETF, June 2005. [ bib | DOI | http ]

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.

Security Mechanisms for the Internet. RFC 3631, IETF, December 2003. [ bib | DOI | http ]

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.

Steven M. Bellovin, J. Ioannidis, A. Keromytis, and R. Stewart. On the Use of Stream Control Transmission Protocol (SCTP) with IPsec. RFC 3554, IETF, July 2003. [ bib | DOI | http ]

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.

Steven M. Bellovin. The Security Flag in the IPv4 Header. RFC 3514, IETF, April 01, 2003. [ bib | DOI | http ]

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.

H. Lu, M. Krishnaswamy, L. Conroy, Steven M. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, and K. Vishwanathan. Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations. RFC 2458, IETF, November 1998. [ bib | DOI | http ]

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.

Steven M. Bellovin. Report of the IAB Security Architecture Workshop. RFC 2316, IETF, April 1998. [ bib | DOI | http ]

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.

Steven M. Bellovin. Defending Against Sequence Number Attacks. RFC 1948, IETF, May 1996. [ bib | DOI | http ]

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.

Steven M. Bellovin. On Many Addresses per Host. RFC 1681, IETF, August 1994. [ bib | DOI | http ]

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.

Steven M. Bellovin. Security Concerns for IPng. RFC 1675, IETF, August 1994. [ bib | DOI | http ]

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.

Steven M. Bellovin. Firewall-Friendly FTP. RFC 1579, IETF, February 1994. [ bib | DOI | http ]

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.