> 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
This archive was generated by hypermail 2b29 : Tue Jan 16 2001 - 13:45:22 EST