[...]
> I'm talking about
>
> client A, IP address 10.1
> client B, IP address 10.2
> redirection proxy P, IP address 192.0.2.1
> distant HTTP server S, IP address 172.16.0.1
>
> Clients A and B try to open HTTP/TCP/IP connections with S. They
> both have private Ethernets and so like MTU=1500 ad MSS=1460, and
> they have typically misconfigured PPP/modem links with MTU=512.
>
> Both clients send SYN's to get rolling. Since they're using common
> operating systems that don't try hard, they both use the same IP ID's
> their corresponding HTTP/TCP/IP packets.
> The first thing they do after the 3-way handshake is try to GET similar
> 600 byte URLs. Or perhaps they do 1000 byte PUT's. Thus, they both send
> IP fragments with the same IP ID's, the same IP destination address,
> and differing only in IP source address (10.1. vs.10.2) and fragmentary
> HTTP payload.
For packets going out, the problem is for the web server at the other end
and you're right - it's got no chance in hell in being able to sanely deal
with this situation. If the NAT box was changing the IP ID field so that
all packets went out with "different" ones, then yes, it has a chance.
> However, what does server S do
> when it gets the second IP fragments? The fragments from the HTTP
> clients as received at S have the same IP source and destination addresses
> and IP ID's. At best they'll have differing IP offsets and lengths,
> but at worst even those will be the same.
Right.
> The only fix is for the proxy P to assign its own IP's, but that has
You mean IP ID's here, I assume, not IP's ?
> serious problems given the small size of the IP ID and relatively long
> lifetimes (a few seconds) of client streams. 64K packets in a few
> seconds is not impressive in a world of Tbit/sec routers. 64K 500 byte
> packets in 3 seconds is only 10 MByte/sec, less than a single FDDI
> interface. Consider that many popular web sites can't answer in less
> than 10 seconds, and you're talking about less than a T3.
I think the main requirement here is that successive packets to the
destination host must have different IP ID's (pre-fragmentation).
[...]
> > ...
> > 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.
The NAT box is just as helpless as the web server. If both packets sent
by the web server have the same IP ID, are destined for different ports
but the same IP# and require demux'ing in the NAT box, if any fragmentation
occurs, the NAT box cannot defragment or send fragments to the correct
destination. Even if the initial packets come in with different port #'s,
the later fragments do not.
There's no real way around this, so long as both origins can be the "same"
at any given point in time.
Darren
p.s. I'm not on this list, someone forwarded me this as being relevant to
IP Filter...
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST