[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pilc] tcppep


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

Attachment: signature.asc
Description: OpenPGP digital signature