[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
DNS
> > 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