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 draft-bellovin-adminprohib-00.txt 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 packets. 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 headers. 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 1981. [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]