Network Working Group Eliot Lear INTERNET-DRAFT Cisco Systems Category: Experimental August 21, 2000 ICMP Blocked Notification 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 3. Abstract Since the introduction of private addresses[1] the use of NATs and firewalls has introduced not only inability to communicate using certain mechanisms, such as AH[2], ESP[3], and H.323[4], but also difficulty in determining the reason for the failed communication. This document specifies methods an intermediate device such as a router, a firewall, or a NAT may use to inform end hosts that a particular type of communication is not possible. It also recommends practices for both the frequency of transmission of such error notices, and their consumption by the end hosts. This document is an outgrowth of the "foglamps" discussion that occurred within the IETF between late 1999 and 2000, and is not the product of a working group. Lear Expires February 21, 2001 [Page 1] 4. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [5]. 5. Introduction As has been repeatedly discussed over the last several years NATs and firewalls have proven to be necessary evils in so far as end to end host communication is concerned. Their limitations are well documented in [6]. In some cases NATs and firewalls have different properties, but in this document we consider any device that can prevent a proper communication. For these purposes we will describe such devices as "blockers". A blocker is a device that will either prevent a communication from properly occurring, or has knowledge that an end to end communication will not occur properly. A blocker is not merely something that filters packets, but it is also something that modifies packets in such a way that the communication is rendered useless or worse. A blocker could also be a device that does not modify packets, but knows that the upper layer communication will fail. A firewall is a blocker because it prevents certain communications from occurring, such as random UDP-based conversations. A NAT is a blocker because by it modifies the layer 3 addresses in packets, thus causing problems for any mechanism above layer 3 that relies on those addresses. IPSEC is a mechanism that would be blocked, not because the NAT would stop packets reaching their end points, but because the end points could no longer properly interpret the information. Note that in the case of H.323, it is not the NAT itself that blocks the communication, but the fact that the address used by callers and receivers is not unique and not globally routable. Thus, a NAT has knowledge that a communication will fail. It is also quite conceivable, however, that a router within an enterprise could also identify communications destined for the "outside" that it knows will fail. Thus, a router could also be a blocker. Because blockers have knowledge that a communication will fail, they MAY inform the originating end host of this fact. How the end host interprets such a message is a matter of policy. It is useful to have an error message so that the end host can reduce the number of guessing games needed to determine what form of communication will succeed and what will fail. In a world with NATs and firewalls, some guessing games are unavoidable. Lear Expires February 21, 2001 [Page 2] It is not possible to provide feedback for all problems caused by private addresses. For instance, it is not possible for a web server to know who is supposed to have access to its address space. 5. Existing ICMP Messages ICMP[7] is the accepted method for communicating end to end failures of various types. If a blocker is to communicate an end to end failure it MUST use the appropriate ICMP message for that failure. In the case of an administrative failure, such as prevented communication based on a firewall policy, there exists an appropriate ICMP UNREACHABLE code to indicate that the communication is prohibited. In this document we are primarily focusing on failures based not on prohibited destination addresses but on application and Internet layer mechanisms. If the blocker knows that H.323 communications are not possible outside of a certain network range, it might return a UDP PORT_UNREACHABLE error to the sender. Having received such a message, a client stack is likely to interpret the message as an indication that the remote server is not running. Often times an end host is able to use other mechanisms that might succeed where the first one failed. For example, by default FTP[8] requires the connecting end host to be addressable. In order for a transfer to succeed in the face of private address space, a NAT must keep state of each FTP session, modify the PORT commands, and provide translation between the two sides of the connection. FTP has an alternate facility that would not require such involvement from a NAT, known as PASV. As a blocker, a NAT could inform the FTP client that it would need to use PASV. However, one does not want to prevent the communication. Thus, the NAT would return an ICMP message while continuing to forward packets. There is no ICMP message for this purpose. As previously mentioned, AH and ESP are thwarted due to address translation. There exists no ICMP message other than HOST- UNREACHABLE to return an error. Such an error would be overly broad and may be misinterpreted by the stack. This error message has come to have many meanings over its lifetime, and its overloading has limited its utility. 6. A new message: BLOCKED A new ICMP type is defined. The type is called "BLOCKED". Type XXX will be used. In addition, several codes for this ICMP message are defined: Code 0: General notification If a blocker is otherwise unknowledgeable as to the type of failure, but knows one will occur for a given communication, or if the blocker is not permitted to produce a more specific error, it MUST use this code. Lear Expires February 21, 2001 [Page 3] Code 1: Verification failure A blocker MAY return this message when it knows that the communication will fail to be verified on the other end due to address translation. This is the code that a knowledgeable NAT would use for AH or ESP. Code 2: Address failure A blocker MAY return this message when it knows that the protocol in question contains layer 3 information for connectivity that is either inaccurate or will be administratively prevented. Both FTP and H.323 would fall under this category. Code 3: Restart Connection A blocker MAY return this message when it knows that there is a better server available for a particular function. For instance, if a mobile device has moved from an optimal point for one server to a suboptimal point as compared to another, a blocker could return a message. N.B., such functionality would require careful configuration, so as not to cause a storm of such messages along the routed path. It is envisioned that either the closest or the farthest blocker would respond. The major difference between UNREACHABLE and BLOCKED messages is the following: a router sends an UNREACHABLE message only when a packet cannot be forwarded for some reason. In the case of a blocked communication, the blocker should continue forwarding packets, if at all possible, and clients should not interpret a BLOCKED message as a hard failure, but rather as a potential failure that an application or service might not otherwise be able to deduce. 7. Non-usage and Usage To be clear, no blocker is under any obligation to return an error. In the first place, the message is defined as of this document. In the second place and more lasting, return of a message is a policy decision that must conform to a site's security policy. It is envisioned that most blockers will be WITHIN the same security domain as one of the end hosts. Firewalls and other boundary devices should receive BLOCKED messages with suspicion and handle them with great care. An error condition occurs when a blocker determines that a communication will fail. In those cases that will already be readily identifiable to the end hosts the blocker MUST NOT send a message. Examples include checksum failures or protocol errors caused by the end hosts themselves. When a blocker is capable and willing to transmit an error it SHOULD do so only at what it perceives is the beginning of a communication. Lear Expires February 21, 2001 [Page 4] In the case of stateful transports such as TCP[9] and SCTP[10], it is easy to identify the beginning of a communication. With other protocols this may be less obvious. Therefore, a blocker who transmits an error code MUST NOT transmit a second error code for the same type of communication to the same originating host (be that source / destination TCP, SCTP, or UDP[11] ports, ESP or other) for at least XXX minutes. Upon receipt of an ICMP BLOCKED message, an end host is equally free to discard it in accordance with its security policy. The end host should provide mechanisms to consider the validity of such messages such as configuration variable allowing for their acceptance and passage. An end host that is not capable of processing ICMP BLOCKED messages MUST ignore them. When an end host does not wish to discard a BLOCKED message, it should pass the information to the appropriate application or mechanism that would best consume the information. If at all possible, an end host application or mechanism SHOULD cache BLOCKED message for the length of the communication, and so long as conditions remain the same. A good indication that conditions have changed would be the changing or addition of a local IP address. This document will not pursue application interfaces for BLOCKED messages. However, ICMP BLOCKED message can be viewed as an intermediate error message the application can use to provide feedback indicating that the application has encountered an adverse network condition. Lear Expires February 21, 2001 [Page 5] 8. Examples A simple example might be a laptop VPN program that primarily relies on IPSEC. Upon receipt of a BLOCKED message the program might attempt to use a higher level tunnel mechanism, such as SSH, assuming it is allowed by the governing security policies. It might do so in such a way as to offer only limited VPN services, as SSH[12] might not be appropriate for some applications. A telephone or an H.323 gatekeeper might receive a BLOCKED message upon a call attempt, and then produce a more robust error indicating why the call did not succeed. Such a message could be used to discover the need for H.323 proxies, or as a hint for configuration of control or policy mechanisms such as COPS or a firewall control protocol. A blocker may transmit a BLOCKED message to indicate to a mobile client that it should reinitiate an HTTP proxy connection. An FTP program might receive a BLOCKED message and immediately switch to PASV mode. Lear Expires February 21, 2001 [Page 6] 8. Security Considerations As has been mentioned long before this document was written, ICMP is a perfect vehicle for denial of service attacks or worse. An evil villain can masquerade as a blocker to force the use of an alternate method that has been compromised. Therefore, end hosts must be extremely careful in their handling with this- as well as any other- ICMP message. An end host MUST NOT tear down an existing functioning connection solely upon receipt of a BLOCKED message. Further, even when a communication is critical, an end host SHOULD NOT discontinue its original attempts to contact the other end solely on the basis of a BLOCKED message. Where possible, an end host should simultaneously initiate whatever fall back measures are available to it. Should an end host establish functioning communications and still receive a BLOCKED message, it SHOULD log such errors to the appropriate security channels, as a blocker is either misconfigured, or the end host is under attack. The primary envisioned beneficiaries of the BLOCKED message would be end hosts behind firewalls that are attempting to contact end hosts beyond firewalls or NATs. Although BLOCKED messages could be transmitted across the public Internet, a conservative security policy could reasonably require filtering of BLOCKED messages at a site's ingress. As is viewed appropriate to the threat, higher level security mechanisms should be used as appropriate to verify the identity of each remote end. 9. IANA Considerations This document defines a new ICMP type, called "BLOCKED". In addition it defines three codes: general (0), verification failure (1), and address failure (2). This document contemplates a new application interface within the stack. As such, the frequency and variety of assignments of codes is difficult to predict at the time of this writing. Should such new codes be necessary the IANA will be responsible for their assignment. 10. References [1] Rekhter et. al., "Address Allocation for Private Internets", RFC 1918, February 1996. [2] Kent et. al., "IP Authentication Header", RFC 2402, November 1998. [3] Kent et. al., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [4] H.323 Lear Expires February 21, 2001 [Page 7] [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [6] Transparency IABReport [7] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [8] Postel. J., Reynolds, J., "File Transfer Protocol", RFC 959, USC/Information Sciences Institute, October 1985. [9] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, USC/Information Sciences Institute, NTIS AD Number A111091, September 1981. [10] draft-ietf-sigtran-sctp-??.txt [11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [12] SSH 11. Author's Address: Eliot Lear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134-1706 Email: lear@cisco.com Phone: +1 (408) 527 4020 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Lear Expires February 21, 2001 [Page 8] 13. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 14. Expiration Date This memo is filed as , and expires February 21, 2001. Lear Expires February 21, 2001 [Page 9]