Re: interception proxies

From: Vernon Schryver (vjs@calcite.rhyolite.com)
Date: Mon Apr 17 2000 - 19:55:38 MDT


> From: Joe Touch <touch@ISI.EDU>

> ...
> I'm speaking of a redirection proxy sitting at the entry of a web farm.
> In that case, the redirection proxy never really terminates a
> connection; it forwards the SYN to one of the web farm boxes, and
> changes the IP address in the process:

But that is the virtuous strain of redirection proxy instead of the
hijacking brand. We know it's administratively cleaner.
Even if there were problems in the virtuous strain, the common
administrative control should allow technical fixes or patches for
redirection hazzards, such as ensuring that there is no cause for
unexpected internal IP fragmentation.

My proposed rule of thumb fits here, that a hack that doesn't play
with IPSEC or application layer encryption or authentication is
probably a bad idea.

> ...
> A sends to S
> P 'nat's' the dest S to the dest C
> ...

A NAT box can also do the wrong thing with IP fragmentation, and in more
plausible scenarioes than 600 byte URL's or PUT's. Consider two client
hosts behind a single NAT box that has been configured with a 500 byte
PPP MTU, path MTU discovery is not working (probably a redundant statement
in this case), both client hosts are using ~1500 byte MSS's and MTU's,
and are fetching from the same HTTP server. The NAT box will be receiving
IP packets with identical IP source and destination addresses, but
differing IP ID's. Somehow I suspect many NAT boxes won't do the require
(equivalent of) IP fragment reassembly to recover the port numbers to know
how to demux the stream from the Internet into correct local destination
IP and Ethernet addresses.

Vernon Schryver vjs@rhyolite.com



This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST