Network Working Group F. Gont
Internet-Draft UTN/FRH
Expires: January 31, 2005 August 2, 2004
Increasing the payload of ICMP error messages
draft-gont-icmp-payload-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. This document may not be modified, and derivative works of
it may not be created, except to publish it as an RFC and to
translate it into languages other than English.
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.
This Internet-Draft will expire on January 31, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The original ICMP specification states that when a packet elicits an
ICMP error message, the IP header plus the next 64 bits of the
original datagram must be returned in the payload of the ICMP error
message. This imposes a constraint on the design of transport-layer
protocols, which are forced to include all the relevant information
needed to identify an instance of communication in the first 64 bits
Gont Expires January 31, 2005 [Page 1]
Internet-Draft Increasing the payload of ICMP error messages August 2004
of their protocol header. It also limits the amount of data from the
original packet available to the transport-layer when acting on the
ICMP error message. Including only the first 64 bits of the original
datagram's payload may also not be enough to demultiplex ICMP error
messages if IP is being used to tunnel some other network-layer
protocol. This document proposes to increase the amount of data of
the original datagram to be included in the payload of ICMP error
messages.
1. Introduction
The Internet Control Message Protocol (ICMP) [1] is used in the
Internet Architecture to perform the fault isolation function, that
is, the group of actions that hosts and routers take to determine
that there is some network failure [4].
The original ICMP specification [1] states that, whenever a packet
elicits an ICMP error message, the internet header plus the first 64
bits of the original datagram's data must be included in the payload
of the ICMP error message. These data are used by the receiving host
to match the error message to the instance of communication that
elicited it.
This limit on the amount information returned in the payload of ICMP
error messages has two drawbacks:
o It imposes a constraint on the design of transport-layer
protocols, which are forced to include all the relevant
information needed to identify a communication instance in the
first 64 bits of their protocol header.
o It limits the amount of data the transport-protocol has available
to perform, for example, security checks on the returned datagram.
o If IP [5] is being used for tunneling purposes, including just the
first 8 bytes of the payload of the original datagram may not be
enough information to demultiplex the ICMP error message.
As discussed in [1] and [6], in order to allow ICMP error messages to
be demultiplexed, transport protocols are forced to include in the
first 64 bits of their headers all the information needed to identify
a communication instance. Thus, this limit somehow constrains the
design of transport protocols.
There are a number of scenarios in which a larger amount of data from
the original datagram may be needed, or, at least, desirable. For
example, additional data from the original datagram could be used to
perform security checks on the received ICMP error message [7].
Gont Expires January 31, 2005 [Page 2]
Internet-Draft Increasing the payload of ICMP error messages August 2004
Also, in case IP is being used to tunnel some other protocol, the
first 64 bits of the original datagrams's payload may not provide
enough information to the demultiplex the ICMP error message.
Even when the Host Requirements RFC [2] states that more than 8
octects of the original datagram's payload MAY be included in the
payload of an ICMP error message, it does not require any specific
amount of data, and thus does not remove the constraints discussed
above.
This document proposes a modification to the original ICMP
specification to increase the amount of data of the original packet
to be included in the payload of ICMP error messages.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. Specification
When a host or router sends an ICMP error message, it MUST include in
the payload of the ICMP error message as many bytes of the original
datagram as possible. However, the resulting IP datagram MUST NOT be
greater than 576 bytes.
It must be noted that 576 is the minimum reassembly buffer size [2].
4. Security Considerations
This document proposes a minor modification to the original ICMP
specification [1], to increase the amount of data of the original
packet to be included in the payload of ICMP error messages. This
modification does not raise any new security implications.
5. Acknowledgements
The author would like to thank Guillermo Gont and Michael Kerrisk for
providing many valuable comments.
6. References
6.1 Normative References
[1] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
Gont Expires January 31, 2005 [Page 3]
Internet-Draft Increasing the payload of ICMP error messages August 2004
[2] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2 Informative References
[4] Clark, D., "Fault isolation and recovery", RFC 816, July 1982.
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Clark, D., "Name, addresses, ports, and routes", RFC 814, July
1982.
[7] Gont, F., "ICMP attacks against TCP", (work in progress)
draft-gont-tcpm-icmp-attacks-00.txt, 2004.
Author's Address
Fernando Gont
Universidad Tecnologica Nacional
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
Gont Expires January 31, 2005 [Page 4]
Internet-Draft Increasing the payload of ICMP error messages August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gont Expires January 31, 2005 [Page 5]