Re: [pilc] tcppep

[Joe Touch <[e-mail]>]

John Border wrote:

> A purist would say that even encapsulating the original header alters the end
> to end semantics.  Even most non-purists would agree that changing the
> original header alters the end to end semantics.  I happen to agree with the
> purists.  So,...

FWIW, let's me clear about what 'changing E2E semantics' means:

ALL PEP'd transactions fall to the lowest KNOWN service
	i.e., it's not good enough to say "hey, the FTP finished,
	so the file I got is what was on the other end"

	ALL. Let me repeat - ALL - TCP connections must be assumed
	to have corrupted data. There's no way to know if they don't
	from just the TCP connection semantics.

ACK doesn't mean the data is at the recipient.

FIN-ACK doesn't mean all the data got there.

CLOSE doesn't mean the transfer is either complete or correct.

---

It's not encapsulating the header that's the issue - it's modifying it, 
and sending spoof'd ACKs back.

If what you really want is to do something that the endpoint knows 
about, use a proxy. Proxies can do what PEPs do, but much more safely, 
since the endpoints KNOW they're not dealing with an E2E transport layer.

Unfortunately, that means they need another transport layer to provide 
reliability, etc.

Joe