The Security Flag in the IPv4 Header
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce:; Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com> Date: April 1, 2004 Subject: Protocol Action: 'The Security Flag in the IPv4 Header' to Draft The IESG has approved the following document: - 'The Security Flag in the IPv4 Header' RFC 3514 as a Draft This document is not a product of the IETF, but has been extensively reviewed in the IETF. The IESG contact persons are Steve Bellovin and Russ Housley.
Technical Summary 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. Working Group Summary This document is not the product of an IETF working group. However, the enthusiastic reception that this document has received after its publication has convinced the IESG that this is a worthy candidate for Draft. If the required widespread implementation is achieved, the protocol should be ready for Full status in a year, thus achieving a new record speed through the track, and a first for a document of this renowned dateline. Note, however, the restriction mentioned near the end of the implementation report. Protocol Quality Steve Bellovin reviewed this protocol for the IESG. Interoperability report prepared by: Steve Bellovin Date: April 1, 2004 This memo on implementations of the IPv4 Security Flag has been prepared to meet one of the requirements for advancing RFC 3514 to Draft, as described in RFC 2026. RFC 3514 depends on clients setting the bit appropriately, and firewalls or other security devices reacting to it. Additionally, the RFC specifies appropriate behavior for intermediate devices such as NATs and IDSs. A number of client systems provide support for setting the security flag. FreeBSD committed a fix very early; this is documented at http://lists.freebsd.org/pipermail/cvs-all/2003-April/001098.html . A patch for the Linux 2.4 kernel may be found at http://www.version6.net/patches/linux-2.4.20-rfc3514.dif . Scanning systems support the functionality as well. Netcraft's compliance is documented at http://news.netcraft.com/archives/2003/04/01/netcraft_to_conform_to_new_int ernet_security_rfc.html Nmap support was developed very early on; see http://seclists.org/lists/nmap-hackers/2003/Apr-Jun/0000.html for details. Receiving sytems and firewalls must also implement the functionality. The FreeBSD change mentioned earlier supports this aspect as well; Clavister AB was the first commercial firewall to support it, per http://lists.virus.org/full-disclosure-0304/msg00014.html . We do not have reports of 3514-compliant IDS or NAT systems; accordingly that behavior is excluded from the Draft version of this specification.