[bittorrent] Re: Re:

larytet.8708132 at bloglines.com larytet.8708132 at bloglines.com
Sat Apr 23 14:20:55 EDT 2005

--- Justin Cormack <justin at street-vision.com wrote:
(cc to list)
On Fri, 2005-04-22 at 21:56 +0000, larytet.8708132 at bloglines.com wrote:
> "You could make a client that passes well formed DNS queries to the real
> > server though..."
> > 
> > that's interesting idea, i will add
it to the existing
> > design.
> > 
> > anyway i am pretty sure that the
moment Rodi gains popularity firewalls
> > will implement DNS relay and will
parse DNS packets. i give it 6-12 months
> > top before commercial firewalls
come with solution. 
> > 
> > Faked HTTP/HTTPS is
> > a reliable way i
see to work around the intelligent firewalls. holes like
> > destination
port 53 (and some others) are going to be closed fairly quick.
> > even simple
traffic policy like up to 100 DNS reuqests/s will prevent using
> > DNS for
data transfer over high speed connections.
> there are audio and video
streaming servers over well-formed DNS, but
> its a hack....
> > to
fake HTTP sessions
> > i will have to use raw sockets (i need to fake TCP
handshake as well to fool
> > the firewall/NATP). not an easy task and code
is not going to be portable.
> At that point you may as well just use
a tcp session, as faking one will
> have the same overhead.

not the
same overhead, because i can use same and permanent TCP session number, for
example, i do not need acks, etc. think about how one could fool firewall.
after the session is established i can stream data exactly as before hijacking
TCP payload. i don't have to calculate CRC, because most of FW do not check
it. and i do not need to care about TCP header - i can use the same pattern
for all packets. and functional requirements are satisfied - you can process
incoming packets on one machine and send response from other (and spoof IP
source address on the way)

> > 
> > One of the functional requirements
in Rodi that you can receive (collect)
> > packets and answer/reply to the
requests using different IPs and even different
> > PCs. For example, request
can be routed through the ring of bouncers - supported
> > by the existing
code, but reply is sent direclty to the peer.
> > 
> > Another alternative

> > is RTP. Shaping of RTP is not easy for ISPs from marketing point of view.

> > 
> > 
> > Not to say that i am not ready to help ISPs. Part of the
desing is URL
> > based data requests. If ISP decides to cooperate Rodi can
leverage existing
> > HTTP caches (not supported by the code today)
> Its a lot of work just to deal with very confined environments, not sure

> I would spend that much more effort on it.

Intelligent statefull
firewalls are getting more and more common. ISPs think that they can drop
one kind of packets and let through another. i am tryin to prove that this
is not an easy task. it's possible, but more expensive than it appears.

I think that the moment ISPs get access to reasonably priced content all
traffic not related to the "pay-per-view"s, will be discarded. BT for obvious
reasons is going to be target number one.

More information about the BitTorrent mailing list