>
> > 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 can see why it makes sense to do so, but this would mean the spoofer
will need to check the TCP header of all passing (TCP) packets, even
those belonging to a connection that did not choose to use the PEP?
I guess this probably still beats using an IP "option", which gets the
packet kicked out of the fast lane...?
-mingyan
This archive was generated by hypermail 2b29 : Tue Jan 16 2001 - 21:42:03 EST