[ On Sat, November 21, 1998 at 18:51:46 (-0500), Michael C. Richardson wrote: ]
> Subject: Re: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts 
>
>   The protocol is really fine. The problem is that most firewall people,
> and an awful lot of NAT/VPN people think that ICMP is a protocol in the
> same sense that UDP/TCP is. It isn't. It is rather part of the infrastructure
> that TCP and UDP sites upon. Firewall vendors who implement "TCP/IP" must
> deal with ICMP issues, or they really aren't supporting "IP" properly.

What you've said (about the protocol being fine vs. needing to pay
attention to ICMP issues) is somewhat self contradictory.  It doesn't
really matter how the ICMP "needs frag" packet gets lost if its loss can
cause something like a TCP/IP connection to fail.

Implementing your suggestion (but *always* ignore the DF bit) would make
the router more robust (with only a slightly increased risk of screwing
things up, and with only a slightly increased level of extra
transmissions), and in the case of TCP connections implementing a retry
without DF if there's neither an ACK nor an ICMP reply in a reasonable
time would make the server more robust.  (Until I scanned through RFC
1191 just recently I didn't realize PMTUD was normally at the IP level,
and not only at the TCP level -- I was misled somewhat before I realized
what was going on with the DF bit by watching a router fragment large
ICMP echo packets as necessary.)

My initial reading of RFC 1191 suggests that some of the suggested
implementations are at least as complex as my proposal, if not more so.
(eg. keeping track of all PMTU values and aging them out, etc.)

An initial scan of RFC 1191 also suggests that no attention has been
paid to the possibility of non-malicious loss of ICMP.  The PMTUD
protocol simply *assumes* that higher level protocols such as TCP will
evenually cause successful transmission of the ICMP packets due to their
own retransmission of data packets with the DF bit turned on.  While it
might be argued that faulty firewalls are just as malicious as any
cracker, the intent is entirely different and IMO the PMTUD protocol
should be prepared for this case, and my initial guess is that it can in
fact deal successfully with this problem, at least for TCP connections
where the most damage is done by non-malicious interference.  (I realize
the protocol was most recently published late in 1990, so firewalls,
re-directors, NATs, etc. were not nearly so prevalent, esp. "malicious"
ones!  ;-)

>   Convincing firewall vendor's of this will probably require a rev to the
> PMTU document. It may even fit into tcpimpl's mandate.

Changing PMTUD to this degree would definitely require a new revision of
the protocol, but in the mean time it should be possible to implement
robustness in both ends without damaging the utility of the basic
protocol.

Convincing firewall vendors to not allow filtering of normal ICMP should
not require any changes in the RFCs -- quite the opposite actually.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>