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



                  <draft-lear-icmp-blocked-00.txt>
                          August 21, 2000

                     ICMP Blocked Notification


. 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.

. Copyright Notice

Copyright (C) The Internet Society (2000).  All Rights Reserved.

. 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].


.  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.

.  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.

. 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.

.  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.

.  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.

.  References

[] Rekhter et. al., "Address Allocation for Private Internets", RFC
1918, February 1996.

[] Kent et. al., "IP Authentication Header", RFC 2402, November
1998.

[] Kent et. al., "IP Encapsulating Security Payload (ESP)", RFC
2406, November 1998.

[] 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.

[] Transparency IABReport

[] Postel, J., "Internet Control Message Protocol", RFC 792,
USC/Information Sciences Institute, September 1981.

[] Postel. J., Reynolds, J., "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.

[] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, USC/Information Sciences
Institute, NTIS AD Number A111091, September 1981.

[] draft-ietf-sigtran-sctp-??.txt

[] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.

[] SSH

. Author's Address:

Eliot Lear
Cisco Systems, Inc.
 W. Tasman Dr.
San Jose, CA 95134-1706
Email: lear@cisco.com
Phone: +1 (408) 527 4020

.  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."


.  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]