One document matched: draft-lear-icmp-blocked-00.txt

Network Working Group                                        Eliot Lear
INTERNET-DRAFT                                            Cisco Systems
Category: Experimental



                  <draft-lear-icmp-blocked-00.txt>
                          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 <draft-lear-icmp-blocked-00.txt>, and expires
February 21, 2001.




Lear                      Expires February 21, 2001                   [Page 9]