Re: tcppep

Joe Touch <[email protected]> Thu, 04 Mar 2004 22:14:39 -0800
Newsgroups gmane.ietf.pilc
Message-ID <[email protected]>
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig89A52BFD88545708FB8180BD
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



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

--------------enig89A52BFD88545708FB8180BD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFASBrPE5f5cImnZrsRAugAAKDJBBhr26PUbzeubUiyctL+x5y7XQCdHoi7
NBh0rAlre8ZQgp6j3v9nRZc=
=Ru3O
-----END PGP SIGNATURE-----

--------------enig89A52BFD88545708FB8180BD--

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/