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.
_______________________________________________
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
