Vernon Schryver wrote:
>
> > 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.
It's only virtuous if the redirection proxy is in the same AD as the web
farm. The web farm may be a web cache farm.
> 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.
I'm not proposing that it's a good idea. It's clear that the 'system' -
redirection proxy and set of web caches redirected to - are responsible
for maintaining the IP ID uniqueness, since they, as a whole, intend to
represent a single IP address.
(in the trivial case I outlined, that uniqueness is ensured by the use
of source-determined demux; anytime packets with the same source/dest
pair can go to the different endpoints, uniqueness must be otherwise
avoided, e.g., out of band messages between the endpoints.)
The same applies, BTW, for port reuse and TCP sequence spaces. Sets of
endpoints aliasing as a single must coordinate and ensure uniqueness.
> > ...
> > 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.
Hmmm - is that observation in the NAT specs? If not, is it something
that should be addressed separately there, or in the Transparency
Hazards doc??
Joe
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST