[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                 Steven M. Bellovin
Internet Draft                                        AT&T Labs Research

Expiration Date: August 2002                               December 2001

    A "Reason" Field for ICMP "Administratively Prohibited" Messages


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

2. Abstract

   The current ICMP "Administratively Prohibited" message conveys one
   bit of information:  we don't like your packet.  This memo proposes
   adding additional information to help hosts retry other possible

Bellovin                                                        [Page 1]

Internet Draft      draft-bellovin-adminprohib-00.txt      December 2001

3. Introduction

   The current ICMP "Administratively Prohibited" message conveys one
   bit of information:  we don't like your packet.  Sometimes, more is
   needed.  For example, attempts to deploy systems that use the ECN bit
   [RFC3168] have run into trouble with some firewalls.  Unfortunately,
   all the firewalls can do is silently drop the packet, send a TCP
   Reset packet (which is, arguably, in violation of [RFC793], or send
   an ICMP "Administratively Denied" message [RFC1716].  But that gives
   the sender too little information on what the cause of the failure
   was, and hence no indication on how to recover.

4. An Unused Field

   The ICMP Destination Unreachable message [RFC792] has a field that is
   unused except in the case of Path MTU Discovery messages [RFC1191].
   We suggest that this field (bytes 5-8 of the ICMP header) be used to
   signal which fields of the original packet caused it to be rejected.
   Each byte is a byte offset from the start of the IP header to an
   offending field.  A value of zero ends the field, since we believe
   that byte 0 of the IP header is unlikely to cause offense beyond what
   would be noted by a Parameter Problem message.

   Since the field is currently defined as "unused", it is possible that
   it contains random garbage.  Accordingly, receivers MUST ignore any
   such fields if any of them reach beyond the IP and next-layer

   Senders SHOULD fill in as many fields as they can identify as causing
   problems.  For example, if a packet were rejected because of an
   access control list that matched on source host, destination host,
   and destination port, the field would contain bytes of 12 (the source
   address offset), 16 (destination address), and 22 (destination port),
   as well as a 0 pad byte.

Bellovin                                                        [Page 2]

Internet Draft      draft-bellovin-adminprohib-00.txt      December 2001

5. IP Version 6

   This draft only applies to ICMP for IPv4.  A later version may
   describe the corresponding IPv6 message.

6. Security Considerations

   Many security boxes prefer to give as little information as possible.
   They are welcome to leave the field at 0, if they wish.

7. References

   [RFC793]  "Transmission Control Protocol". J. Postel. September 1981.

   [RFC792]  "Internet Control Message Protocol". J. Postel. September

   [RFC1191] "Path MTU discovery".  J.C. Mogul and S.E. Deering.
        November 1990.

   [RFC1716] "Towards Requirements for IP Routers".  P. Almquist and F.
        Kastenholz.  November 1994.

   [RFC3168] "The Addition of Explicit Congestion Notification (ECN) to
        IP".  K. Ramakrishnan, S. Floyd, and D. Black.  September 2001

8. Author Information

Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07932
Phone: +1 973-360-8656
email: bellovin@acm.org

Bellovin                                                        [Page 3]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/