Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Wiretapping ICMP messages
Message-ID: <8704051451.a011392@Huey.UDEL.EDU>
Date: Sun, 5-Apr-87 14:51:54 EST
Article-I.D.: Huey.8704051451.a011392
Posted: Sun Apr  5 14:51:54 1987
Date-Received: Mon, 6-Apr-87 01:44:18 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa

Keith,

The mechanism I suggested some time ago involves cacheing ICMP messages of
selected types for a period longer than the typical TCP retransmission
interval, but shorter than the typical "retry" interval, maybe a couple
of minutes or so. I did not specify which message types should be cached
and what detail information (TOS, etc.) should be saved, but did assume
as much information as useful in the routing algorithm. My suggestion
would not affect routing until a number of these messages (tbd) had been
received within a period equal to some number of TCP retransmissions,
maybe fifteen to thirty seconds. When that happened the local routing data
base would be marked "down" for that destination net/TOS/whatever and the
normal routing exchanges would do the rest.

You will note this is functionally identical to the hard-to-reach concept
used in the telephone network, except that routing updates per se are not
used in that network (#4 ESS non-hierarchical routing honkers will be
politely ignored here). I am not suggesting now as the optimum time to
construct a definitive proposal on how to implement this concept in a
j-random gateway, but am suggesting the concept ripe for experimentation
in a real gateway, maybe even a fuzzball.

Dave