Possible Torrent Alternative.

Steve smorrey at gmail.com
Wed Oct 24 17:28:19 MDT 2007

No I really haven't forgotten nor have I misunderstood the OSI model.

Yes anything using TCP would be vulnerable.  So I'm saying for the
purposes of this file transfer protocol lets ditch TCP all together
and instead use UDP.

It's not UDP/TCP we are talking about implementing, it's UDP/IP which
is an altogether different protocol from TCP/IP and is not a riding
layer over TCP/IP, like FTP, HTTP, etc.

Also even though overhead is consideration, it is only a minor
consideration when deciding to go with UDP.  Instead the major
consideration here is that UDP can be hardened to not be vulnerable to
the man in the middle style attacks that Comcast is pulling.  Yes they
could filter UDP traffic all together, and yes that would sorta break
the protocol I guess.  But to be frank what they are doing with TCP is
sending the connection close request packet to each client involved
and forging the clients IP address.

The whole point here is to make an attack like that impossible to pull
off.  Because if Comcast is doing it today,. other ISPs will do it
soon as well.

And finally as I've said a few times already, we can leverage the "no
delivery guarantee, and no data order" to our advantage.  We don't
need to implement those things, it's not crucial that the data arrive
in order, or at all, the only thing that is crucial here is that when
data does arrive it arrives in tact, and can be verified to be from
the original sender.


On 10/24/07, Lonnie Olson <lists at kittypee.com> wrote:
> On Wed, 2007-10-24 at 10:54 -0600, Steve wrote:
> > Therefore I would like to propose that we create a new protocol which
> > is not susceptible to man in the middle attacks, and is stable, safe,
> > secure and reliable.
> You are either forgetting or mis-understanding the OSI model which
> details the layers of protocols.
> Comcast's approach to kill connections is targeted at the TCP layer.
> This makes every layer on top of TCP vulnerable, including FTP, HTTP,
> Gopher, SMTP, IMAP, POP, etc, etc, etc.
> > However instead of using TCP, and a connection based protocol, it
> > should use UDP and a connectionless protocol.
> The overhead of TCP really isn't that bad.  Only 3 packets to start a
> connection.  And an extra return packet for each packet sent.
> p2p apps wouldn't work very well on top of UDP.  UDP has no delivery
> guarantee.  Your proposal will increase overhead beyond that of TCP,
> because no you have to re-implement retransmissions and data order.
> Causing even slower downloads.
> --lonnie
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list