diff options
Diffstat (limited to 'doc/rfc/rfc2075.txt')
| -rw-r--r-- | doc/rfc/rfc2075.txt | 283 |
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc2075.txt b/doc/rfc/rfc2075.txt new file mode 100644 index 0000000..00dd42c --- /dev/null +++ b/doc/rfc/rfc2075.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group C. Partridge +Request for Comments: 2075 BBN +Category: Experimental January 1997 + + + IP Echo Host Service + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + This memo describes how to implement an IP echo host. IP echo hosts + send back IP datagrams after exchanging the source and destination IP + addresses. The effect is that datagrams sent to the echo host are + sent back to the source, as if they originated at the echo host. + +Introduction + + An IP echo host returns IP datagrams to their original source host, + with the IP source and destination addresses reversed, so that the + returning datagram appears to be coming from the echo host to the + original source. IP echo hosts are tremendously useful for debugging + applications and protocols. They allow researchers to create looped + back conversations across the Internet, exposing their traffic to all + the vagaries of Internet behavior (congestion, cross traffic, + variable round-trip times and the like) without having to distribute + prototype software to a large number of test machines. + + IP echo hosts were heavily used on the Internet in the late 1970s and + early 1980s to debug various Internet transport and application + protocols. But, for reasons unclear, at the current date there are + no echo hosts on the Internet and few people are even aware of the + concept. The goal of this memo is to document the concept in the + hopes it will be revived. + +Implementation Details + + While the basic idea of a echo host is simple, there are a few + implementation details that require attention. This section + describes those implementation details. The presentation works from + 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 an + IP datagram with no options and whose protocol field has a value + other than 1 (ICMP). In this case, the echo host modifies the header + by exchanging the source and destination addresses, decrements the + TTL by one and updates the IP header checksum. The host then + transmits the updated IP datagram back to the original source of the + datagram. + + NOTE: If the TTL is zero or less after decrementing, the datagram + MUST not be echoed. In general, an echo host is required to do + all the various sanity checks that a router or host would do to an + 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 path + through an echo host SHOULD set their TTL to twice the normal + value to be sure of achieving connectivity over the echo path. + + If an arriving IP datagram has options, the echo host's + responsibilities are more complex. In general, the IP source and + destination are always exchanged and TTL and checksum updated, but in + certain situations, other special actions may have to take place. + + If the datagram contains an incomplete source route option (i.e. the + echo host is not the final destination), the datagram MUST be + discarded. If the datagram contains a complete source route option, + the source route option MUST be reversed, and the datagram (with + source and destination IP addresses exchanged and updated TTL) MUST + be sent back along the reverse source route. + + More generally, the goal with any option is to update the option such + that when the echoed packet is received at the original source, the + option fields will contain data which makes sense for a datagram + 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 time + estimation. If the option is reset at the echo host, then a history + of roughly half of the trip delay will be lost. But if the option is + not reset, then the timestamp option will appear inconsistent with + the source and destination addresses of the datagram. To try to + balance these two issues, the following rules are suggested: + + 1. If the first entry in the timestamp option contains the IP + address of the source host, the entry SHOULD be rewritten to + contain the IP address of the echo host, and the timestamp option + pointer SHOULD be truncated so that this timestamp is the only one + + + +Partridge Experimental [Page 2] + +RFC 2075 IP Echo Host Service January 1997 + + + in the list. (This rewrite makes the option appear consistent + with the new source and destination IP addresses, and retains the + source timestamp, while losing information about the path to the + echo host). + + 2. If the first entry in the timestamp option does not contain the + IP address of the source host, the entry SHOULD be echoed back + unchanged. The echo host SHOULD NOT appear in the timestamp + option. (This approach retains the entire history of the path, + though observe that on a symmetric route, it means every router + may appear twice in the path). + + Finally, if the IP datagram contains an ICMP packet (i.e. the IP + protocol field value is 1), the datagram SHOULD be discarded. The + reason for this rule is that the most likely reason for receiving an + ICMP datagram is that an echoed datagram has encountered a problem at + some router in the path and the router has sent back an ICMP + datagram. Echoing the ICMP datagram back to the router may confuse + the router and thus SHOULD be avoided. (This rule simply follows the + Internet maxim of being conservative in what we send). + + However, in some cases the ICMP datagram will have useful information + for the source host which it would be desirable to echo. A + sophisticated echo host MAY choose to echo ICMP datagrams according + to the following rules: + + 1. Any ICMP datagram in which the destination address in the + encapsulated IP header (the header within the ICMP datagram) + matches the source address of the ICMP datagram MAY be safely + echoed. + + 2. ICMP Source Quench and ICMP Destination Unreachable with a code + of 4 (fragmentation needed and DF set) MAY be sent to the + *destination* of the encapsulated IP datagram if the source IP + address of the encapsulated IP datagram is that of the echo host. + When the ICMP message is sent on, it SHOULD be rewritten as an + 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 ICMP + messages are passed through, as are messages from routers which are + fairly safe and useful (or necessary) to the end system, but that + potentially dangerous messages such as Redirects are suppressed. + (The ICMP Destination Unreachable with code 4 is required for MTU + discovery under RFC-1191). + + + + + +Partridge Experimental [Page 3] + +RFC 2075 IP Echo Host Service January 1997 + + +Security Considerations + + Echo hosts pose a number of security concerns related to address + spoofing. + + First, echo hosts provide obvious ways to extend attacks that make + use of address spoofing. A malevolent host can write an third + party's IP address as the source address of a datagram sent to an + echo host and thus cause the echo host to send a datagram to the + third party. In general, this trick does not create a new security + hole (the malevolent host could just as well have sent the datagram + with a forged source address straight to the third party host). But + there are some new twists to the problem. + + One exception is if the echo host is a host inside a firewall that + accepts datagrams from hosts outside the firewall. In that case, a + malevolent host outside the firewall may be able to use the echo host + to make its packets appear to originate from inside the firewall + (from the echo host). In general, a good firewall will catch these + cases (the source address of the datagrams sent to the echo host will + be for a host inside the firewall and testing for interior source + addresses on datagrams arriving at an exterior interface is a + standard firewall filter) but since the primary purpose of echo hosts + is for wide scale Internet testing, there seems no reason to invite + danger. So we recommend that echo hosts SHOULD NOT be placed inside + firewalls. + + Second, address spoofing can be used to cause flooding of the + network. In this case, a malevolent host sends a datagram to an echo + host with the source address of another echo host. This trick will + cause datagrams to circulate between the two echo hosts. The + requirement that the echo host decrement the TTL by one ensures that + each datagram will eventually die, but a sufficiently malevolent host + sending a large number of datagrams with high TTLs to an echo host + can cause considerable disruption. There are a number of possible + ways to repair this problem (such as requiring sources to + authenticate themselves before sending datagrams to be echoed). A + simple protection is simply to limit the number of packets echoed + back to any one source per second. For instance, one might limit a + source to a packet rate equal to 10% of the interface bandwidth (for + a 10 Mb/s Ethernet this would be about 75 maximum sized packets per + second). + + One variation of this attack is to generate e-mail addressed to the + echo host (e.g., user@echo.xxx.com). This e-mail will loop over the + network a number of times until the SMTP server determines the + 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 or + broadcast address as the source of the IP datagram sent to an echo + server. Since this results in an illegal arriving IP datagram, the + echo server MUST discard the datagram. (This warning serves as a + reminder that echo servers MUST do the standard checks for an illegal + datagram before echoing). + +Implementation Note + + Echo hosts are often implemented as virtual interfaces on an existing + host or router. One can think of the echo host's IP address as a + second IP address for the host, with the semantics that all datagrams + sent to that address get echoed. Observe that when an echo host is + supported as a module within a larger host implementation, an easy + implementation mistake to make is to accidentally put the non-echo + address of a host into an echoed packet. For a variety of reasons + (including security and correct operation of echo paths) implementors + MUST ensure this NEVER happens. + +Acknowledgements + + This memo was stimulated by a conversation with Jon Crowcroft in + which we both lamented the demise of some beloved IP echo hosts + (e.g., goonhilly-echo.arpa). It has been considerably improved by + 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. Enquiries + to the usual suspects suggest that echo hosts were created by persons + unknown (probably at BBN) very early in the development of IP. I'd + like to thank those persons who created echo hosts and apologize for + any errors in describing their invention. + +Author's Address + + Craig Partridge + BBN Corporation + 10 Moulton St + Cambridge MA 02138 + + EMail: craig@bbn.com + + + + + + + + + +Partridge Experimental [Page 5] + |