Browse Prior Art Database

The Security Flag in the IPv4 Header (RFC3514)

IP.com Disclosure Number: IPCOM000012010D
Original Publication Date: 2003-Apr-01
Included in the Prior Art Database: 2003-Apr-02
Document File: 7 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Bellovin: AUTHOR

Abstract

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 text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 26% of the total text.

Network Working Group� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � S. Bellovin

Request for Comments: 3514� � � � � � � � � � � � � � � � � � � � � � � � � � � AT&T Labs Research

Category: Informational� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 1 April 2003

� � � � � � � � � � � � � � � � � The Security Flag in the IPv4 Header

Status of this Memo

� � This memo provides information for the Internet community.� It does

� � not specify an Internet standard of any kind.� Distribution of this

� � memo is unlimited.

Copyright Notice

� � Copyright (C) The Internet Society (2003).� All Rights Reserved.

Abstract

� � 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.

1. Introduction

� � Firewalls [CBR03], packet filters, intrusion detection systems, and

� � the like often have difficulty distinguishing between packets that

� � have malicious intent and those that are merely unusual.� The problem

� � is that making such determinations is hard.� To solve this problem,

� � we define a security flag, known as the "evil" bit, in the IPv4

� � [RFC791] header.� Benign packets have this bit set to 0; those that

� � are used for an attack will have the bit set to 1.

1.1. Terminology

� � The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,

� � SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this

� � document, are to be interpreted as described in [RFC2119].

2. Syntax

� � The high-order bit of the IP fragment offset field is the only unused

� � bit in the IP header.� Accordingly, the selection of the bit position

� � is not left to IANA.

Bellovin� � � � � � � � � � � � � � � � � � � � Informational� � � � � � � � � � � � � � � � � � � � � [Page 1]

RFC 3514� � � � � � � � � The Security Flag in the IPv4 Header� � � � � 1 April 2003

� � The bit field is laid out as follows:

� � � � � � � � � � � � 0

� � � � � � � � � � � +-+

� � � � � � � � � � � |E|

� � � � � � � � � � � +-+

� � Currently-assigned values are defined as follows:

� � 0x0� If the bit is set to 0, the packet has no evil intent.� Hosts,

� � � � � � � network elements, etc., SHOULD assume that the packet is

� � � � � � � harmless, and SHOULD NOT take any defensive measures.� (We note

� � � � � � � that this part of the spec is already implemented by many common

� � � � � � � desktop operating systems.)

� � 0x1� If the bit is set to 1, the packet has evil intent.� Secure

� � � � � � � systems SHOULD try to defend themselves against such packets.

� � � � � � � Insecure systems MAY chose to crash, be penetrated, etc.

3. Setting the Evil Bit

� � There are a number of ways in which the evil bit may be set.� Attack

� � applications may use a suitable API to request that it be set.

� � Sys...