idnits 2.17.1 draft-lear-icmp-blocked-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 7 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 21, 2000) is 8646 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2402 (ref. '2') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 793 (ref. '9') (Obsoleted by RFC 9293) -- No information found for draft-ietf-sigtran-sctp- - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eliot Lear 2 INTERNET-DRAFT Cisco Systems 3 Category: Experimental 5 6 August 21, 2000 8 ICMP Blocked Notification 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 3. Abstract 37 Since the introduction of private addresses[1] the use of NATs and 38 firewalls has introduced not only inability to communicate using 39 certain mechanisms, such as AH[2], ESP[3], and H.323[4], but also 40 difficulty in determining the reason for the failed communication. 42 This document specifies methods an intermediate device such as a 43 router, a firewall, or a NAT may use to inform end hosts that a 44 particular type of communication is not possible. It also 45 recommends practices for both the frequency of transmission of such 46 error notices, and their consumption by the end hosts. 48 This document is an outgrowth of the "foglamps" discussion that 49 occurred within the IETF between late 1999 and 2000, and is not the 50 product of a working group. 52 4. Requirements language 54 In this document, the key words "MAY", "MUST, "MUST NOT", 55 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 56 interpreted as described in [5]. 58 5. Introduction 60 As has been repeatedly discussed over the last several years NATs 61 and firewalls have proven to be necessary evils in so far as end to 62 end host communication is concerned. Their limitations are well 63 documented in [6]. In some cases NATs and firewalls have different 64 properties, but in this document we consider any device that can 65 prevent a proper communication. For these purposes we will describe 66 such devices as "blockers". 68 A blocker is a device that will either prevent a communication from 69 properly occurring, or has knowledge that an end to end 70 communication will not occur properly. A blocker is not merely 71 something that filters packets, but it is also something that 72 modifies packets in such a way that the communication is rendered 73 useless or worse. A blocker could also be a device that does not 74 modify packets, but knows that the upper layer communication will 75 fail. 77 A firewall is a blocker because it prevents certain communications 78 from occurring, such as random UDP-based conversations. A NAT is a 79 blocker because by it modifies the layer 3 addresses in packets, 80 thus causing problems for any mechanism above layer 3 that relies on 81 those addresses. IPSEC is a mechanism that would be blocked, not 82 because the NAT would stop packets reaching their end points, but 83 because the end points could no longer properly interpret the 84 information. 86 Note that in the case of H.323, it is not the NAT itself that blocks 87 the communication, but the fact that the address used by callers and 88 receivers is not unique and not globally routable. Thus, a NAT has 89 knowledge that a communication will fail. It is also quite 90 conceivable, however, that a router within an enterprise could also 91 identify communications destined for the "outside" that it knows 92 will fail. Thus, a router could also be a blocker. 94 Because blockers have knowledge that a communication will fail, they 95 MAY inform the originating end host of this fact. How the end host 96 interprets such a message is a matter of policy. 98 It is useful to have an error message so that the end host can 99 reduce the number of guessing games needed to determine what form of 100 communication will succeed and what will fail. In a world with NATs 101 and firewalls, some guessing games are unavoidable. 103 It is not possible to provide feedback for all problems caused by 104 private addresses. For instance, it is not possible for a web 105 server to know who is supposed to have access to its address space. 107 5. Existing ICMP Messages 109 ICMP[7] is the accepted method for communicating end to end failures 110 of various types. If a blocker is to communicate an end to end 111 failure it MUST use the appropriate ICMP message for that failure. 112 In the case of an administrative failure, such as prevented 113 communication based on a firewall policy, there exists an 114 appropriate ICMP UNREACHABLE code to indicate that the communication 115 is prohibited. In this document we are primarily focusing on 116 failures based not on prohibited destination addresses but on 117 application and Internet layer mechanisms. 119 If the blocker knows that H.323 communications are not possible 120 outside of a certain network range, it might return a UDP 121 PORT_UNREACHABLE error to the sender. Having received such a 122 message, a client stack is likely to interpret the message as an 123 indication that the remote server is not running. 125 Often times an end host is able to use other mechanisms that might 126 succeed where the first one failed. For example, by default FTP[8] 127 requires the connecting end host to be addressable. In order for a 128 transfer to succeed in the face of private address space, a NAT must 129 keep state of each FTP session, modify the PORT commands, and 130 provide translation between the two sides of the connection. FTP 131 has an alternate facility that would not require such involvement 132 from a NAT, known as PASV. As a blocker, a NAT could inform the FTP 133 client that it would need to use PASV. However, one does not want 134 to prevent the communication. Thus, the NAT would return an ICMP 135 message while continuing to forward packets. There is no ICMP 136 message for this purpose. 138 As previously mentioned, AH and ESP are thwarted due to address 139 translation. There exists no ICMP message other than HOST- 140 UNREACHABLE to return an error. Such an error would be overly broad 141 and may be misinterpreted by the stack. This error message has come 142 to have many meanings over its lifetime, and its overloading has 143 limited its utility. 145 6. A new message: BLOCKED 147 A new ICMP type is defined. The type is called "BLOCKED". Type XXX 148 will be used. In addition, several codes for this ICMP message are 149 defined: 151 Code 0: General notification 153 If a blocker is otherwise unknowledgeable as to the type of failure, 154 but knows one will occur for a given communication, or if the 155 blocker is not permitted to produce a more specific error, it MUST 156 use this code. 158 Code 1: Verification failure 160 A blocker MAY return this message when it knows that the 161 communication will fail to be verified on the other end due to 162 address translation. This is the code that a knowledgeable NAT 163 would use for AH or ESP. 165 Code 2: Address failure 167 A blocker MAY return this message when it knows that the protocol in 168 question contains layer 3 information for connectivity that is 169 either inaccurate or will be administratively prevented. Both FTP 170 and H.323 would fall under this category. 172 Code 3: Restart Connection 174 A blocker MAY return this message when it knows that there is a 175 better server available for a particular function. For instance, if 176 a mobile device has moved from an optimal point for one server to a 177 suboptimal point as compared to another, a blocker could return a 178 message. N.B., such functionality would require careful 179 configuration, so as not to cause a storm of such messages along the 180 routed path. It is envisioned that either the closest or the 181 farthest blocker would respond. 183 The major difference between UNREACHABLE and BLOCKED messages is the 184 following: a router sends an UNREACHABLE message only when a packet 185 cannot be forwarded for some reason. In the case of a blocked 186 communication, the blocker should continue forwarding packets, if at 187 all possible, and clients should not interpret a BLOCKED message as 188 a hard failure, but rather as a potential failure that an 189 application or service might not otherwise be able to deduce. 191 7. Non-usage and Usage 193 To be clear, no blocker is under any obligation to return an error. 194 In the first place, the message is defined as of this document. In 195 the second place and more lasting, return of a message is a policy 196 decision that must conform to a site's security policy. 198 It is envisioned that most blockers will be WITHIN the same security 199 domain as one of the end hosts. Firewalls and other boundary 200 devices should receive BLOCKED messages with suspicion and handle 201 them with great care. 203 An error condition occurs when a blocker determines that a 204 communication will fail. In those cases that will already be 205 readily identifiable to the end hosts the blocker MUST NOT send a 206 message. Examples include checksum failures or protocol errors 207 caused by the end hosts themselves. 209 When a blocker is capable and willing to transmit an error it SHOULD 210 do so only at what it perceives is the beginning of a communication. 212 In the case of stateful transports such as TCP[9] and SCTP[10], it 213 is easy to identify the beginning of a communication. With other 214 protocols this may be less obvious. Therefore, a blocker who 215 transmits an error code MUST NOT transmit a second error code for 216 the same type of communication to the same originating host (be that 217 source / destination TCP, SCTP, or UDP[11] ports, ESP or other) for 218 at least XXX minutes. 220 Upon receipt of an ICMP BLOCKED message, an end host is equally free 221 to discard it in accordance with its security policy. The end host 222 should provide mechanisms to consider the validity of such messages 223 such as configuration variable allowing for their acceptance and 224 passage. An end host that is not capable of processing ICMP BLOCKED 225 messages MUST ignore them. 227 When an end host does not wish to discard a BLOCKED message, it 228 should pass the information to the appropriate application or 229 mechanism that would best consume the information. If at all 230 possible, an end host application or mechanism SHOULD cache BLOCKED 231 message for the length of the communication, and so long as 232 conditions remain the same. A good indication that conditions have 233 changed would be the changing or addition of a local IP address. 235 This document will not pursue application interfaces for BLOCKED 236 messages. However, ICMP BLOCKED message can be viewed as an 237 intermediate error message the application can use to provide 238 feedback indicating that the application has encountered an adverse 239 network condition. 241 8. Examples 243 A simple example might be a laptop VPN program that primarily relies 244 on IPSEC. Upon receipt of a BLOCKED message the program might 245 attempt to use a higher level tunnel mechanism, such as SSH, 246 assuming it is allowed by the governing security policies. It might 247 do so in such a way as to offer only limited VPN services, as 248 SSH[12] might not be appropriate for some applications. 250 A telephone or an H.323 gatekeeper might receive a BLOCKED message 251 upon a call attempt, and then produce a more robust error indicating 252 why the call did not succeed. Such a message could be used to 253 discover the need for H.323 proxies, or as a hint for configuration 254 of control or policy mechanisms such as COPS or a firewall control 255 protocol. 257 A blocker may transmit a BLOCKED message to indicate to a mobile 258 client that it should reinitiate an HTTP proxy connection. 260 An FTP program might receive a BLOCKED message and immediately 261 switch to PASV mode. 263 8. Security Considerations 265 As has been mentioned long before this document was written, ICMP is 266 a perfect vehicle for denial of service attacks or worse. An evil 267 villain can masquerade as a blocker to force the use of an alternate 268 method that has been compromised. Therefore, end hosts must be 269 extremely careful in their handling with this- as well as any other- 270 ICMP message. An end host MUST NOT tear down an existing 271 functioning connection solely upon receipt of a BLOCKED message. 272 Further, even when a communication is critical, an end host SHOULD 273 NOT discontinue its original attempts to contact the other end 274 solely on the basis of a BLOCKED message. Where possible, an end 275 host should simultaneously initiate whatever fall back measures are 276 available to it. Should an end host establish functioning 277 communications and still receive a BLOCKED message, it SHOULD log 278 such errors to the appropriate security channels, as a blocker is 279 either misconfigured, or the end host is under attack. 281 The primary envisioned beneficiaries of the BLOCKED message would be 282 end hosts behind firewalls that are attempting to contact end hosts 283 beyond firewalls or NATs. Although BLOCKED messages could be 284 transmitted across the public Internet, a conservative security 285 policy could reasonably require filtering of BLOCKED messages at a 286 site's ingress. 288 As is viewed appropriate to the threat, higher level security 289 mechanisms should be used as appropriate to verify the identity of 290 each remote end. 292 9. IANA Considerations 294 This document defines a new ICMP type, called "BLOCKED". In addition 295 it defines three codes: general (0), verification failure (1), and 296 address failure (2). This document contemplates a new application 297 interface within the stack. As such, the frequency and variety of 298 assignments of codes is difficult to predict at the time of this 299 writing. Should such new codes be necessary the IANA will be 300 responsible for their assignment. 302 10. References 304 [1] Rekhter et. al., "Address Allocation for Private Internets", RFC 305 1918, February 1996. 307 [2] Kent et. al., "IP Authentication Header", RFC 2402, November 308 1998. 310 [3] Kent et. al., "IP Encapsulating Security Payload (ESP)", RFC 311 2406, November 1998. 313 [4] H.323 314 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 315 Levels," RFC 2119, March 1997. 317 [6] Transparency IABReport 319 [7] Postel, J., "Internet Control Message Protocol", RFC 792, 320 USC/Information Sciences Institute, September 1981. 322 [8] Postel. J., Reynolds, J., "File Transfer Protocol", RFC 959, 323 USC/Information Sciences Institute, October 1985. 325 [9] Postel, J., ed., "Transmission Control Protocol - DARPA Internet 326 Program Protocol Specification", RFC 793, USC/Information Sciences 327 Institute, NTIS AD Number A111091, September 1981. 329 [10] draft-ietf-sigtran-sctp-??.txt 331 [11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 332 Sciences Institute, August 1980. 334 [12] SSH 336 11. Author's Address: 338 Eliot Lear 339 Cisco Systems, Inc. 340 170 W. Tasman Dr. 341 San Jose, CA 95134-1706 342 Email: lear@cisco.com 343 Phone: +1 (408) 527 4020 345 12. Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 intellectual property or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; neither does it represent that it 352 has made any effort to identify any such rights. Information on the 353 IETF's procedures with respect to rights in standards-track and 354 standards-related documentation can be found in BCP-11. Copies of 355 claims of rights made available for publication and any assurances 356 of licenses to be made available, or the result of an attempt made 357 to obtain a general license or permission for the use of such 358 proprietary rights by implementors or users of this specification 359 can be obtained from the IETF Secretariat. 361 The IETF invites any interested party to bring to its attention any 362 copyrights, patents or patent applications, or other proprietary 363 rights which may cover technology that may be required to practice 364 this standard. Please address the information to the IETF Executive 365 Director. 367 13. Full Copyright Statement 369 Copyright (C) The Internet Society (2000). All Rights Reserved. 371 This document and translations of it may be copied and furnished to 372 others, and derivative works that comment on or otherwise explain it 373 or assist in its implementation may be prepared, copied, published 374 and distributed, in whole or in part, without restriction of any 375 kind, provided that the above copyright notice and this paragraph 376 are included on all such copies and derivative works. However, this 377 document itself may not be modified in any way, such as by removing 378 the copyright notice or references to the Internet Society or other 379 Internet organizations, except as needed for the purpose of 380 developing Internet standards in which case the procedures for 381 copyrights defined in the Internet Standards process must be 382 followed, or as required to translate it into languages other than 383 English. The limited permissions granted above are perpetual and 384 will not be revoked by the Internet Society or its successors or 385 assigns. This document and the information contained 386 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 387 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 388 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 389 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 390 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 391 PARTICULAR PURPOSE." 393 14. Expiration Date 395 This memo is filed as , and expires 396 February 21, 2001.