UDP Spoofing

toad · Post by **toad** » 2003-08-27 11:03

What about implementing UDP uploading into DC++? It would ensure the senders anonymity and that would leave the RIAA helpless in finding file sharers.

UPD upploding would work much the same as file upploading works today, but instead of using sockets you'll use UDP datagrams that contain the pieces of the file contents. And you would spoof the datagrams with an invalid and random sender adress, they will reach their destination but the receiver would only see the false sender adress. The first problem with this how do one assert that all datagrams are delivered? Well, you have to number the datagrams and the receiver will calculate how many there should be (based on the file size) and request resends of missing datagrams through a private message to the sender via the hub.

That's it... it's just to implement

TheParanoidOne · Post by **TheParanoidOne** » 2003-08-27 19:58

UDP was not designed for sequenced guaranteed delivery. That is what TCP is for. You seem to want to be reinvent a particularly complicated wheel.

UDP is a connectionless, unreliable, unordered datagram service.

If I am the UDP sender, how do I:

Know whether the dest has received any of the packets I sent? UDP has no acknowledgement mechanism so I may be wasting time sending data into a black hole.
Know whether I am flooding the receiver? eg I am a 100Mb link and receiver is a 56k modem. Again, no ack mechanism and no flow control.

If I am the UDP receiver, how do I:

Know what sequence the packets are in? UDP does not have sequence numbers.
Request the re-sending of a packet? Again, no sequence numbers.
Store the data while awaiting packets? Assuming there were sequence numbers and I had all packets from 0 to 9999 except packet 3, where would I store this while I awaited the errant packet? In memory? On disk?

There are more things, but I think I have made my point (I hope!) There is a reason why TCP exists.

toad · Post by **toad** » 2003-08-28 07:38

TheParanoidOne wrote::( UDP was not designed for sequenced guaranteed delivery. That is what TCP is for. You seem to want to be reinvent a particularly complicated wheel.

UDP is a connectionless, unreliable, unordered datagram service.

Well it's not that unreliable as you might think, NFS (Network File System) is actually using UDP.

TheParanoidOne wrote:If I am the UDP sender, how do I:
Know whether the dest has received any of the packets I sent? UDP has no acknowledgement mechanism so I may be wasting time sending data into a black hole.
Know whether I am flooding the receiver? eg I am a 100Mb link and receiver is a 56k modem. Again, no ack mechanism and no flow control.

Why would the sender want to know that? It's more important for the receiver to make sure all packages arrive.
Don't know actually...

TheParanoidOne wrote:If I am the UDP receiver, how do I:
Know what sequence the packets are in? UDP does not have sequence numbers.
Request the re-sending of a packet? Again, no sequence numbers.
Store the data while awaiting packets? Assuming there were sequence numbers and I had all packets from 0 to 9999 except packet 3, where would I store this while I awaited the errant packet? In memory? On disk?

That's easy, you just give the datagrams sequence numbers. UPD doesn't have to support sequencing to do this. It's in the data.
Requesting is as I've stated done through the hub, you don't even have to change the protocol.
In memory and/or on this would work nicelly.

TheParanoidOne wrote:There are more things, but I think I have made my point (I hope!) There is a reason why TCP exists.

Sorry but you haven't made any point since there exists filetransfering UDP solutions today and as I said NFS is a old and reliable UDP implementation used today.

cologic · Post by **cologic** » 2003-08-28 08:27

Whilst all of TCP's flow control and reliability features can be implemented over a UDP substrate, they would seem to require interaction between the two clients. Spoofing one's source address makes such things significantly more difficult, in particular.

TheNOP · Post by **TheNOP** » 2003-08-28 12:29

here what's cologic mean.

The Trivial File Transfer Protocol TFTP is defined in RFC-783 [TFTP:1].

TFTP provides its own reliable delivery with UDP as its transport protocol, using a simple stop-and-wait acknowledgment system. Since TFTP has an effective window of only one 512 octet segment, it can provide good performance only over paths that have a small delay*bandwidth product. The TFTP file interface is very simple, providing no access control or security

.

note the underline, need acknowledment and no control or security.
there is better way to hide and IP other then spoofing.
but has i sayed before, impliment it and DC won't be call DC anymore. :wink:

toad · Post by **toad** » 2003-08-28 15:18

TheNOP wrote:there is better way to hide and IP other then spoofing.

Ok, how then? via a proxy is the only other solution I can think of... and that is not so good since the proxy becomes a bottleneck.

TheNOP · Post by **TheNOP** » 2003-08-28 23:20

toad wrote:Ok, how then?

proxy is one, but could potentialy shift the treat from users to the proxy owner if not impliment correctly.
and other one is freenet witch is acting like a delaying proxy.
any ways to get a dout in a jury's minds can be thinks of, like 1 out of 3 transfers would be direct, the others by some one else could work.

DC is DC, the others ways will be call ??? and will proly not use the DC protocol at all.

toad · Post by **toad** » 2003-08-29 07:20

TheNOP wrote:DC is DC, the others ways will be call ??? and will proly not use the DC protocol at all.

Precisely, the only way to protect DC from RIAA is to use UDP Spoofing since that is feasable within the existing protocol hence with a minor extension.

(Edit: Fixed your quote tag -GMT)

cologic · Post by **cologic** » 2003-08-29 10:22

Respond to my previous post, please. I could restate it all, but... Not worth it yet, because you haven't even tried to respond to it.

toad · Post by **toad** » 2003-08-29 13:59

cologic wrote:Respond to my previous post, please. I could restate it all, but... Not worth it yet, because you haven't even tried to respond to it.

Huh!? there's nothing to respond to other than that you're right in that control and reliabilty can be built into a UDP Protocol, but you're wrong when you state that it needs the interaction between two parties. If you add a third party to the mix (a proxy, ie the hub), receiver doesn't have to know who the sender really is since the hub is relaying control messages like missing datagrams and stuff.

cologic · Post by **cologic** » 2003-08-29 14:08

... (probably) noticeably increasing bandwidth demands on the hub, but I guess that's something that can be measured and which you may find a suitable tradeoff.

TheNOP · Post by **TheNOP** » 2003-08-30 03:52

toad

do you understand that by trying to make DC an anonymous client, DC will loose all the features we like in it ?

if you're so concern about anonymity, try the other solutions, they already exist, then you will see what's are the tradeoffs.

then post about it again if you want that to appen to DC.

i, myself, think the tradeoff are to big to worth it.
just switching network is simpler and would be faster to do than wait for DC to be anonymous.

TheNOP · Post by **TheNOP** » 2003-08-30 04:08

the only way to protect DC from RIAA is to use UDP Spoofing

1 you don't have to DC, DC can be a legit P2P network, if use to transfer only none copyrighted material.
2 they can't stop DC development since it is opensource.
who will they drag to court the courriers that post the source on internet ?
hell it can also be post on anonymous network to spread it.

ivulfusbar · Post by **ivulfusbar** » 2003-08-30 06:30

a small comment, well? ofcourse opensource projects can be dragge dinto court.

TheNOP · Post by **TheNOP** » 2003-08-30 17:00

ivulfusbar wrote:a small comment, well? ofcourse opensource projects can be dragge dinto court.

official maintainner, probably yes.
if court can prove that DC is a "bad app" (read geared to transfer copyrighted materials only).
after all it is how/what you use it for that can cause you problems with riaa, not DC itself.

Post by **GargoyleMT** » 2003-08-31 15:28

ivulfusbar wrote:a small comment, well? ofcourse opensource projects can be dragged into court.

Witness Xmule.

http://xmule.org/
http://yro.slashdot.org/article.pl?sid=03/08/21/1333258

takeda · Post by **takeda** » 2003-09-19 03:52

toad wrote:Well it's not that unreliable as you might think, NFS (Network File System) is actually using UDP.

The difference is that NFS doesn't spoof source address, without knowing who is sending there won't be way to control transfer, what about:
- resending bad chunks
- controlling amount and speed of sending data (ICMP)

I know that you could send that information through server but it will be waste of resources on server (mostly bandwidth)
Not to mention that some ISPs block spoofed packets

Why would the sender want to know that? It's more important for the receiver to make sure all packages arrive.
Don't know actually...

It will be waste of bandwidth if we send a lot of informations for nothing.

Sorry but you haven't made any point since there exists filetransfering UDP solutions today and as I said NFS is a old and reliable UDP implementation used today.

Do you know why newer version of NFS allow to use TCP?
Why FTP uses TCP instead going after footsteps of TFTP

Basically TCP and UDP have different purposes:
- tcp is to realiable transfer data (files and other informations that shouldn't be corrupted.
- udp is faster because it doesn't use ACKs, it's good for streaming, if you listen to radiostation when data is corrupted you only hear a noise but you still can continue.

TFTP and older versions of NFS uses UDP, but they, re still using acknowledges.

I think IPv6 could bring some help with p2p, I'm not very deep in that topic but won't it allow to use multicast by regular users?

UDP Spoofing

UDP Spoofing

Who is online