Proxies and loops

Proxies share many problems with routers. Among these, a catastrophic
event is the creation of a loop of proxies, originating from the
misconfiguration of one of more of the members of the loop.

While the configuration of proxies does not really belong in the
HTTP protocol, it helps a lot having a way to detect the existence
of loops, or at least minimising its bad effects.

In this particular case, the ability to identify and break loops
is of fundamental importance because even a single misconfigured
proxy can create large loops and completely disrupt service on the
proxies which are part of the loop.

Note that it is very easy to break service on a given proxy: the
misconfigured proxy, A, only needs to send a request to a proxy
(P) specifying an URI on A itself. With the complicity of an
intermediate node A' on the loop P can loose any possibility of
detecting the existence of the loop.

           +--> A --(A')---> P ----+
	   |                       |
	   +------------<----------+

Now, while it is true that a program can easily be written to induce
such a behaviour, my point is that the above scenario can be
introduced too easily because of misconfiguration of a node running
standard code.

Invoking the "robustness principle", and similarly to IP, I propose
the addition of a Time-To-Live field somewhere in the *compulsory*
headers for the request. A node receiving a request must decrement
the TTL and can only forward it if the TTL is >0. If the TTL goes to 0,
the node should reply with an error message to help the location of the
problem.

The TTL can either be a separate, compulsory header field, or appear
as an additional parameter in the Request-Line, perhaps right after
the protocol version.

A note: a malicious node A, can create an artificial loop even with
a TTL field, and even if an authentication mechanism is used to
allow a proxy to accept and forward requests (although, in this
case the malicious process must first authenticate itself). Actually,
it is not even necessary that data are actually flowing on the
connection, it suffices that enough requests are sent to P while
keeping it waiting for responses: the node running P will quickly
hit against some limit (file descriptors, process table entries,
max concurrent requests...). An alternative approach, namely the
addition, in the request, of a "history" of already visited nodes,
does not help either.

A "robust" proxy should certainly check for requests coming from
a single node, and avoid allocating a significant fraction of its
resource to it.

	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================

Received on Thursday, 23 November 1995 11:11:07 UTC