The Security Flag in the IPv4 Header
RFC 3514

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
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.