idnits 2.17.1 draft-bellovin-adminprohib-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 63: '...Accordingly, receivers MUST ignore any...' RFC 2119 keyword, line 67: '... Senders SHOULD fill in as many fiel...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2001) is 8168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1716 (Obsoleted by RFC 1812) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven M. Bellovin 3 Internet Draft AT&T Labs Research 5 Expiration Date: August 2002 December 2001 7 A "Reason" Field for ICMP "Administratively Prohibited" Messages 9 draft-bellovin-adminprohib-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 The current ICMP "Administratively Prohibited" message conveys one 35 bit of information: we don't like your packet. This memo proposes 36 adding additional information to help hosts retry other possible 37 packets. 39 3. Introduction 41 The current ICMP "Administratively Prohibited" message conveys one 42 bit of information: we don't like your packet. Sometimes, more is 43 needed. For example, attempts to deploy systems that use the ECN bit 44 [RFC3168] have run into trouble with some firewalls. Unfortunately, 45 all the firewalls can do is silently drop the packet, send a TCP 46 Reset packet (which is, arguably, in violation of [RFC793], or send 47 an ICMP "Administratively Denied" message [RFC1716]. But that gives 48 the sender too little information on what the cause of the failure 49 was, and hence no indication on how to recover. 51 4. An Unused Field 53 The ICMP Destination Unreachable message [RFC792] has a field that is 54 unused except in the case of Path MTU Discovery messages [RFC1191]. 55 We suggest that this field (bytes 5-8 of the ICMP header) be used to 56 signal which fields of the original packet caused it to be rejected. 57 Each byte is a byte offset from the start of the IP header to an 58 offending field. A value of zero ends the field, since we believe 59 that byte 0 of the IP header is unlikely to cause offense beyond what 60 would be noted by a Parameter Problem message. 62 Since the field is currently defined as "unused", it is possible that 63 it contains random garbage. Accordingly, receivers MUST ignore any 64 such fields if any of them reach beyond the IP and next-layer 65 headers. 67 Senders SHOULD fill in as many fields as they can identify as causing 68 problems. For example, if a packet were rejected because of an 69 access control list that matched on source host, destination host, 70 and destination port, the field would contain bytes of 12 (the source 71 address offset), 16 (destination address), and 22 (destination port), 72 as well as a 0 pad byte. 74 5. IP Version 6 76 This draft only applies to ICMP for IPv4. A later version may 77 describe the corresponding IPv6 message. 79 6. Security Considerations 81 Many security boxes prefer to give as little information as possible. 82 They are welcome to leave the field at 0, if they wish. 84 7. References 86 [RFC793] "Transmission Control Protocol". J. Postel. September 1981. 88 [RFC792] "Internet Control Message Protocol". J. Postel. September 89 1981. 91 [RFC1191] "Path MTU discovery". J.C. Mogul and S.E. Deering. 92 November 1990. 94 [RFC1716] "Towards Requirements for IP Routers". P. Almquist and F. 95 Kastenholz. November 1994. 97 [RFC3168] "The Addition of Explicit Congestion Notification (ECN) to 98 IP". K. Ramakrishnan, S. Floyd, and D. Black. September 2001 100 8. Author Information 102 Steven M. Bellovin 103 AT&T Labs Research 104 Shannon Laboratory 105 180 Park Avenue 106 Florham Park, NJ 07932 107 Phone: +1 973-360-8656 108 email: bellovin@acm.org