Manish Karir wrote:
>
> You can check out:
> http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-11/CSHCN_TR_99-11.pdf
>
> I believe this implementation had a way of maintaining seq numbers
> such that they would work even if some traffic was
> routed around the spoofer. but I'm not sure....
It appears to assert that it preserves E2E semantics by preserving
the sequence numbers.
However the source TCP has no way of knowing that this
intermediate has correctly or consistently provided that
guarantee (or the one about delaying the SYN-ACK until
it comes from the source, e.g.).
> > Hi,
> >
> > The requirement is that a TCP session, once it starts in spoofed mode
> > continues thenceforth in spoofing mode unless there is a graceful
> > closure. A route change that causes one of the spoofers to be removed
> > from the path, will not be tolerated by most spoofers that I know of.
> > However, this isn't as severe a restriction as it sounds.....most
> > spoofers that I know operate on access networks where there is only
> > one point of attachment.
The reason this is of further concern is that the spoofer code can
die, in which case the TCP connection should show an error. As
I pointed out before, this would result in erroneous data being
transferred instead.
The key point of the E2E argument is that it does not allow
adding intermediate components except for performance,
exactly because the E2E communication depends critically
on their correct operation. Unless there is a provably
uncrashable spoofer, it clearly violates TCP's E2E semantics
as a result.
Joe
This archive was generated by hypermail 2b29 : Wed Jan 10 2001 - 14:38:28 EST