John Border wrote:
>
> > TCP OPTION?
> >
> > If you can find out why you want to do it, and what benefit you get, why
> > not consider a TCP option? I haven't heard of anyone (yet?) trying
> > these spoofing ideas for UDP (???). If your target is TCP, and your spoofer
> > **must** demultiplex individual flows and interpret TCP header semantics,
> > why not negotiate "willingness to spoof" on TCP connection setup? Failure
> > to see this option, could indicate unwillingness (including encryption? old
> > protocol stack? lazy application?) - I wonder whether this has more
> > potential?
>
> This is an interesting idea. Something like the following...
>
> The initiator adds a "PEP" option to the SYN. If there is no PEP in the path,
> the receiver sends no option in the SYN ACK, letting the initiator know the
> connection is end to end. If there is a PEP in the path, the PEP adds a "PEP"
> option when it sends a SYN ACK to initiator and when it forwards or sends a
> SYN to the receiver. (The receiver could even, in theory, tell the PEP to get
> out of the way by not including the "PEP" option in its own SYN ACK response.)
>
> I see a problem with getting people to put support for such an option in their
> TCP stacks, though. They would have to be convinced of the value of doing
> so...
>
> John
Yes, that sounds encouraging (to me).
I think I still need to be convinced that we **should** do it, but at
least
something at the TCP level seems only to interact with TCP transport
entities... and also give reasonable functionality, rather than trying to
"overload" extra semantics to existing mechanisms...
Gorry
-- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry
This archive was generated by hypermail 2b29 : Tue Jan 16 2001 - 13:49:32 EST