"Hazards of transparent web caching"
J. Touch
(internal draft)
USC/ISI
Copyright Sept. 1998
Modified April 2000, as noted.

- violates host and gateway requirements RFCs
	(This is perhaps the most important, since it is reflected
	in the assumptions of all the others below.)

	NOTE: "MUST" is a special word in these documents, and the
	documents themselves are special because they are standards
	or proposed standard (i.e., revisions of current standards
	that say the same thing, in this case).

	Hosts MUST not source IP addresses they don't own:

	STANDARD - RFC1122 - Requirements for Internet Hosts -- Comm. Layers
   	    pg 31:

            When a host sends any datagram, the IP source address MUST
            be one of its own IP addresses (but not a broadcast or
            multicast address).

	Routers MUST not source IP addresses they don't own:

	PROPOSED STANDARD - RFC1812 - Requirements for IP Version 4 Routers
		pg 48:

		When a router originates any datagram, the IP
		source address MUST be one of its own IP addresses 
		(but not a broadcast or multicast address).  The 
		only exception is during initialization.

	HOWEVER, network address translation IS allowed, notably for
	sharing load, which is essentially what you're doing
	here. Note that both of these RFCs are 'informational', so
	they specifically do not override the standards or proposed
	standards above.
	
	INFORMATIONAL - RFC1631: The IP Network Address Translator (NAT).
		OK _only_ at the border of a stub domain.
		I.e., if you use DynaCache, you should not
		subordinate stub domains in the path which Dynacache
		hijacks.

		You also need to restrict what is put IN the
		DynaCache, to only things INSIDE your network (you're
		allowed to NAT your own stuff, not the outside world's).

	INFOMATIONAL - RFC2391: Load Sharing using IP Network Address 
			Translation

		This describes how to do what I said just above; 
		how to distribute load among YOUR OWN servers with
		NAT boxes and feedback information.

		There is NO provision for reducing the load to
		access things outside your domain by NAT'ing it
		within your own domain. That would be a violation
		of the host and gateway RFCs above.

- IP authentication will defeat it (by design)

- in effect, it is a use of IP spoofing to do replay attacks
	any tool that detects replay attacks will flag this
	as malicious behavior

- must not be used outside a private network
	if traffic is forwarded, masquerading may break
	routing or network administration elsewhere

- complicates network administration
	traceroute, ping, etc. won't find the cache, since it
	routes differently based on port, so network admin
	tools will see a different network than the user does,
	which can complicate diagnoses.

- complicates TCB sharing, autoconfig, resource discovery
	different ports see different path characteristics
	breaks T/TCP's model of RTT sharing

- destroys TCP semantics
	TCP is e2e, to the end you specify, not to a cache.
	any other techniques that rely on TCP semantics

--- April 2000

- may compromise IP ID requirements
	the IP ID must be unique for 1 MSL, for each src/dst pair
	(Erik Nordmark)

- may compromise TCP port reuse
	the TCP src/dst/srcport/dstport tuple must be unique for 
	2 MSL

	the TCP srd/dst/srcport/dstport/seqnum must be unique for
	2 MSL (??)

----.