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)
- Re: Candidate definitions: Spoofing, Proxying, Sp… Keith Scott
- Re: Candidate definitions: Spoofing, Proxying, Sp… Aaron Falk
- Re: Candidate definitions: Spoofing, Proxying, Sp… William S. Marcus
- Re: Candidate definitions: Spoofing, Proxying, Sp… Michael C. Richardson
- Candidate definitions: Spoofing, Proxying, Splitt… Keith Scott