As per Relevance of the word datagram, we have this rfc below:
Network Working Group C.
Request for Comments: 2075
Category: Experimental January 1997
IP Echo Host
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This memo describes how to implement an IP echo host. IP echo
send back IP datagrams after exchanging the source and destination
addresses. The effect is that datagrams sent to the echo host
sent back to the source, as if they originated at the echo host
An IP echo host returns IP datagrams to their original source host
with the IP source and destination addresses reversed, so that
returning datagram appears to be coming from the echo host to
original source. IP echo hosts are tremendously useful for
applications and protocols. They allow researchers to create
back conversations across the Internet, exposing their traffic to
the vagaries of Internet behavior (congestion, cross traffic
variable round-trip times and the like) without having to
prototype software to a large number of test machines
IP echo hosts were heavily used on the Internet in the late 1970s
early 1980s to debug various Internet transport and
protocols. But, for reasons unclear, at the current date there
no echo hosts on the Internet and few people are even aware of
concept. The goal of this memo is to document the concept in
hopes it will be revived
Implementation
While the basic idea of a echo host is simple, there are a
implementation details that require attention. This
describes those implementation details. The presentation works
the simplest to most difficult issues
Partridge Experimental [Page 1]
RFC 2075 IP Echo Host Service January 1997
The most straightforward situation is when an echo host receives
IP datagram with no options and whose protocol field has a
other than 1 (ICMP). In this case, the echo host modifies the
by exchanging the source and destination addresses, decrements
TTL by one and updates the IP header checksum. The host
transmits the updated IP datagram back to the original source of
datagram
NOTE: If the TTL is zero or less after decrementing, the
MUST not be echoed. In general, an echo host is required to
all the various sanity checks that a router or host would do to
IP datagram before accepting the datagram for echoing (see STD 3,
RFC 1122, and RFC 1812).
The TTL MUST be decremented for security reasons noted below
Observe, however, that the effect is that hosts using an echo
through an echo host SHOULD set their TTL to twice the
value to be sure of achieving connectivity over the echo path
If an arriving IP datagram has options, the echo host'
responsibilities are more complex. In general, the IP source
destination are always exchanged and TTL and checksum updated, but
certain situations, other special actions may have to take place
If the datagram contains an incomplete source route option (i.e.
echo host is not the final destination), the datagram MUST
discarded. If the datagram contains a complete source route option
the source route option MUST be reversed, and the datagram (
source and destination IP addresses exchanged and updated TTL)
be sent back along the reverse source route
More generally, the goal with any option is to update the option
that when the echoed packet is received at the original source,
option fields will contain data which makes sense for a
originating at the echo host
There is one option for which it is unclear what the correct action
The timestamp option is sometimes used for round-trip
estimation. If the option is reset at the echo host, then a
of roughly half of the trip delay will be lost. But if the option
not reset, then the timestamp option will appear inconsistent
the source and destination addresses of the datagram. To try
balance these two issues, the following rules are suggested
1. If the first entry in the timestamp option contains the
address of the source host, the entry SHOULD be rewritten
contain the IP address of the echo host, and the timestamp
pointer SHOULD be truncated so that this timestamp is the only
Partridge Experimental [Page 2]
RFC 2075 IP Echo Host Service January 1997
in the list. (This rewrite makes the option appear
with the new source and destination IP addresses, and retains
source timestamp, while losing information about the path to
echo host).
2. If the first entry in the timestamp option does not contain
IP address of the source host, the entry SHOULD be echoed
unchanged. The echo host SHOULD NOT appear in the
option. (This approach retains the entire history of the path
though observe that on a symmetric route, it means every
may appear twice in the path).
Finally, if the IP datagram contains an ICMP packet (i.e. the
protocol field value is 1), the datagram SHOULD be discarded.
reason for this rule is that the most likely reason for receiving
ICMP datagram is that an echoed datagram has encountered a problem
some router in the path and the router has sent back an
datagram. Echoing the ICMP datagram back to the router may
the router and thus SHOULD be avoided. (This rule simply follows
Internet maxim of being conservative in what we send).
However, in some cases the ICMP datagram will have useful
for the source host which it would be desirable to echo.
sophisticated echo host MAY choose to echo ICMP datagrams
to the following rules
1. Any ICMP datagram in which the destination address in
encapsulated IP header (the header within the ICMP datagram
matches the source address of the ICMP datagram MAY be
echoed
2. ICMP Source Quench and ICMP Destination Unreachable with a
of 4 (fragmentation needed and DF set) MAY be sent to
*destination* of the encapsulated IP datagram if the source
address of the encapsulated IP datagram is that of the echo host
When the ICMP message is sent on, it SHOULD be rewritten as
ICMP message from the echo host to the source
3. All other ICMP messages MUST be discarded
These rules were chosen to try to ensure that end-to-end
messages are passed through, as are messages from routers which
fairly safe and useful (or necessary) to the end system, but
potentially dangerous messages such as Redirects are suppressed
(The ICMP Destination Unreachable with code 4 is required for
discovery under RFC-1191).
Partridge Experimental [Page 3]
RFC 2075 IP Echo Host Service January 1997
Security
Echo hosts pose a number of security concerns related to
spoofing
First, echo hosts provide obvious ways to extend attacks that
use of address spoofing. A malevolent host can write an
party's IP address as the source address of a datagram sent to
echo host and thus cause the echo host to send a datagram to
third party. In general, this trick does not create a new
hole (the malevolent host could just as well have sent the
with a forged source address straight to the third party host).
there are some new twists to the problem
One exception is if the echo host is a host inside a firewall
accepts datagrams from hosts outside the firewall. In that case,
malevolent host outside the firewall may be able to use the echo
to make its packets appear to originate from inside the
(from the echo host). In general, a good firewall will catch
cases (the source address of the datagrams sent to the echo host
be for a host inside the firewall and testing for interior
addresses on datagrams arriving at an exterior interface is
standard firewall filter) but since the primary purpose of echo
is for wide scale Internet testing, there seems no reason to
danger. So we recommend that echo hosts SHOULD NOT be placed
firewalls
Second, address spoofing can be used to cause flooding of
network. In this case, a malevolent host sends a datagram to an
host with the source address of another echo host. This trick
cause datagrams to circulate between the two echo hosts.
requirement that the echo host decrement the TTL by one ensures
each datagram will eventually die, but a sufficiently malevolent
sending a large number of datagrams with high TTLs to an echo
can cause considerable disruption. There are a number of
ways to repair this problem (such as requiring sources
authenticate themselves before sending datagrams to be echoed).
simple protection is simply to limit the number of packets
back to any one source per second. For instance, one might limit
source to a packet rate equal to 10% of the interface bandwidth (
a 10 Mb/s Ethernet this would be about 75 maximum sized packets
second).
One variation of this attack is to generate e-mail addressed to
echo host (e.g., user@echo.xxx.com). This e-mail will loop over
network a number of times until the SMTP server determines
message has too many Received-From: lines
Partridge Experimental [Page 4]
RFC 2075 IP Echo Host Service January 1997
A third variation of the flooding trick is to place a multicast
broadcast address as the source of the IP datagram sent to an
server. Since this results in an illegal arriving IP datagram,
echo server MUST discard the datagram. (This warning serves as
reminder that echo servers MUST do the standard checks for an
datagram before echoing).
Implementation
Echo hosts are often implemented as virtual interfaces on an
host or router. One can think of the echo host's IP address as
second IP address for the host, with the semantics that all
sent to that address get echoed. Observe that when an echo host
supported as a module within a larger host implementation, an
implementation mistake to make is to accidentally put the non-
address of a host into an echoed packet. For a variety of
(including security and correct operation of echo paths)
MUST ensure this NEVER happens
This memo was stimulated by a conversation with Jon Crowcroft
which we both lamented the demise of some beloved IP echo
(e.g., goonhilly-echo.arpa). It has been considerably improved
comments from various members of the End2End-Interest mailing list
including Bob Braden, Mark Handley, Christian Huitema, Dave Mills
Tim Salo, Vern Schryver, Lansing Sloan, and Rich Stevens
The author is emphatically not the inventor of echo hosts.
to the usual suspects suggest that echo hosts were created by
unknown (probably at BBN) very early in the development of IP. I'
like to thank those persons who created echo hosts and apologize
any errors in describing their invention
Author's
Craig
BBN
10 Moulton
Cambridge MA 02138
EMail: craig@bbn.
Partridge Experimental [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
