Re: Candidate definitions: Spoofing, Proxying, Splitting, etc.

[Aaron Falk <[e-mail]>]

Keith- a good start. Let me pose some questions and such... --aaron

Keith Scott wrote:

> Topology:
> Node A wants to send data to B, and C is some intermediate entity (router,
> bridge, satellite hop including groundstations, network, etc.) in the
> information path.  Note that the return traffic (acknowledgments) from B to
> A may or may not go through C but in general does not have to.

Are you excluding cases where A can reach B through another path which doesn't
pass through C?

>
>
> Definitions:
>
> Spoofing:  C is a spoofer if it modifies the information flowing between A
> and B unbeknownst to either.  This definition was designed to cover ACK
> spoofing, where C would acknowledge packets sent by A as it forwarded them
> to B.  In this case, C then becomes responsible for seeing that the packets
> actually make it to B.

I think you need to distinguish between the definition of the term and the
recommendation of what should be done. I.e. if C isn't responsible for reliable
delivery, does that mean this isn't spoofing? IMHO, it is the unreliable nature
of some spoofing mechanisms that causes it to be looked at in an unfavorable
light.

> Proxying:  C is a proxy if it aids A's transmission to B in such a way that
> either:  1) it does not modify the data/ack stream flowing though it or  2)

> the endpoint knows that C is there and what it is doing.  This definition
> covers proxy servers, for example.  It would also cover the ACK' method I
> discussed.  I included item (1) in case C only cooperates with one side and
> simply does nothing special in the other direction.

>

> <...stuff deleted...>

> How about something like [hidden/known]
> performance enhancing proxies for spoofing and proxying?
> [covert/cooperative] PEPs?
>

This definition is pretty broad and allows in protocol boosters, which to me are
not proxies. I like the idea of treating known and hidden (to A) proxies
seperately. A known proxy is an entity in the network (C) which a user (A)
contacts to get enhanced performance to between the his node and his destination
(B). A hidden proxy intercepts traffic between A and B and performs some magic
which neither A nor B are aware of but increases the performance of their
connection. I guess TCP pacing would be a hidden proxy mechanism. And all the
following mechanisms are examples of hidden proxies.

> TCP Splitting: C splits the TCP connection if it terminates the TCP
> connection from A and opens up a separate connection to B.  In this case,
> as C receives segments from A, it acknowledges them (since it is the end of
> the connection from A) and resends them on the other side to B.  Again,
> once C has acknowledged a packet from A it becomes responsible for its
> delivery.
>

Some random thoughts here:

   * Connections can be split into 2 or 3 pieces, depending on your architecture
     (i.e. with a GEO satellite you may want to run some special TCP over the
     satellite-between C and C' as below-and then go back to a not-so-special TCP
     so B doesn't need to run a special TCP)
   * If it isn't TCP over the C-C' connection then you have protocol translation
     as defined below
   * This (split TCP, hidden proxy) is what most of the satellite people I've
     spoken to mean when they talk about spoofing.
   * Finally, the ramifications of this method differ considerably depending on
        o a) whether B is multiply connected to the Internet (concerns regarding
          routing flaps) and
        o b) whether everything from C to B is isolated to a single network
          (concerns whether playing with things like congestion control will
          affect unsuspecting users' data)

> Protocol Translation:  If C is a network or piece of a network (in the
> above picture, think of breaking C into C and C' separated by a 'net' box),
> C could take in TCP packets from A and encapsulate them with the C network
> header/trailer and forward them to C', which removes the C network wrapping
> before sending the packets on their way to B.  The C network might do its
> own ARQ, send each packet multiple times, etc.  Alternately C might modify
> the TCP headers in such a way that C' could recover the originals (VJ
> Header compression is a link layer version of this, but if you had some
> other way to do routing within the C network you could conceive of a scheme
> to compress the TCP header at C, move the packet to C', then uncompress the
> header before releasing the packet from the C network).
>

Seems to me that there is an important distinction as to whether this is confined
to the link layer or not. If yes, then this is a protocol booster (as defined
below) it really doesn't affect TCP other than to do things like add delay and
delay variation. If no, this is a variant of the split TCP connection. I.e. Could
be TCP-TCP-TCP or TCP-ProtocolX-TCP.

> Other:  Consider a 'protocol booster' model, with the same topology as for
> the protocol translation definition, but instead of encapsulating the
> incoming TCP packets or changing their formats, C simply forwards them to
> C' and _separately_ sends extra information (FEC, timestamps, etc) to C';
> C' then uses this extra information for something.  This is slightly
> different from protocol translation, as if either the 'special sender' (C)
> or 'special receiver' (C') is removed, the original TCP packets will still
> be forwarded to B.
>

--
Aaron Falk    [phone]
TRW, Inc                     Space & Electronics Group
One Space Park                 Redondo Beach, CA 90278