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

"William S. Marcus" <wsm@bellcore.com> Mon, 08 June 1998 13:36 UTC

X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcppep@lerc.nasa.gov using -f
Message-ID: <357BE8BF.A3C8D5E9@bellcore.com>
Date: Mon, 08 Jun 1998 09:36:00 -0400
From: "William S. Marcus" <wsm@bellcore.com>
Organization: BELLCORE
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 4.1.4 sun4m)
MIME-Version: 1.0
To: Keith Scott <Keith.Scott@jpl.nasa.gov>
CC: tcppep@lerc.nasa.gov
Subject: Re: Candidate definitions: Spoofing, Proxying, Splitting, etc.
References: <v03130303b19dc1cc9809@[137.78.161.32]>
Content-Type: multipart/alternative; boundary="------------D9A84DAA30470550324997FC"
Sender: owner-tcppep@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 7008
Lines: 154

Keith Scott wrote:

>
>
> 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.  Depending on your religious persuasion it can be
> argued that this is 'bad' because it breaks TCP's end-2-end semantics.
>
>
> As an aside, I think Berkeley's snoop would fall under the definition of
> spoofing, which makes me somewhat unhappy with the definition, as I think
> we'd generally like spoofing to be bad.  It was also mentioned that maybe
> the entire term 'spoofing' should be replaced, as it is unclear and
> certainly has bad connotations.  How about something like [hidden/known]
> performance enhancing proxies for spoofing and proxying?
> [covert/cooperative] PEPs?
>
>

Keith, I'd have to disagree with you on Snoop being a spoofer as described in
yourdefinition.  Snoop doesn't assume the responsibility of assuring packets
actually
arrive at node B, it merely assists in reducing the perceived response time for
TCP
when packets that node C has in its cache are dropped between nodes C and B.

I think that you should remove the 'responsibility' assertion in your spoofing
definition;
Spoofing should be a best effort sort of service; one whose aim is to increase
the
performance of the end-2-end communicating entities, making no guarantees on the
performance
enhancement. However it should *NOT* degrade the performance when things don't
go  as planed
(e.g., routing around C, asymmetric paths ....).  If your looking to change the
name of spoofing to
something more pleasant, can I suggest using "Protocol Boosting." I think your
definition of protocol boosting should also allow for a booster to remove or add
messages which are legal to the communication channel being boosted, but never
modify the end-2-end semantics of the protocol being boosted. Berkeley Snoop
fits nicely into this definition of snooping/protocol boosting.

> 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.
>

-Bill

--
William Marcus                                  Bellcore
Senior Research Scientist                       MCC 1C-157B
wsm@bellcore.com                                445 South Street
973 829-4369 (Voice)                            Morristown, NJ 07960
973 829-5886 (Fax)