RFC 3631: Security Mechanisms for the Internet
In plain English — editorial summary, not part of the RFC
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.
Document record
- Document ID
- RFC3631
- Published
- December 2003
- Authors
- S. Bellovin; J. Schiller; C. Kaufman
- Status
- INFORMATIONAL
- Stream
- IAB
- Area
- —
- Pages
- 20
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 7141Byte and Packet Congestion NotificationCurrent
February 2014
- RFC 3704Ingress Filtering for Multihomed NetworksUpdated
March 2004
- RFC 2827Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address SpoofingUpdated
May 2000
- RFC 2267Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address SpoofingObsoleted
January 1998
- RFC 5358Preventing Use of Recursive Nameservers in Reflector AttacksCurrent
October 2008
- RFC 9288Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit RoutersCurrent
August 2022
- RFC 3221Commentary on Inter-Domain Routing in the InternetCurrent
December 2001
- RFC 2990Next Steps for the IP QoS ArchitectureCurrent
November 2000
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?