Subject: Re: [P2PSIP] Peer protocol, DHT and running code

From: Dean Willis <[email-masked]>
Date: Mon, 2 Jul 2007 01:49:41 -0500

On Jun 30, 2007, at 7:25 PM, Emil Ivov wrote:

>
>> but protocols need to be amenable to this sort of tunneling even  
>> if we don't standardize it.
>> But the FIREWALL doesn't keep track of TCP connections. It just looks
>>  at syn/ack to determine whether an incoming packet appears to be  
>> part of an established TCP flow. If it is an initial connection  
>> "opening" from outside, it gets discarded. This is completely  
>> stateless inspection on the firewall. It does leave one a bit open to
>>  SYN-flood DOS attacks, but there are other workarounds for that.
>
> Well, isn't it quite obvious that this kind of firewalls won't work  
> for
> P2P even when TCP based because it won't allow for end-to-end
> simultaneous connection establishment?
>

They work if one can find something like a STUN-relay for TCP out in  
public address space. This seems to work for at least one VoIP  
application widely advertised to be P2P.

If that STUN-relay like thing is also a peer, which the nodes-behind- 
firewalls found using the overlay, then it seems like we'd have a  
working P2P scenario.

>> Now if you can figure all this out, let me know and I'm sure I can  
>> find some startup money to make us both rich!
>
> Heey, no problem. I am sure that if we start entangling photons right
> now in a month or two we'll be able to build a quantum firewall and
> it'll be doing all kinds of magic, so you better get that money  
> ready! :-))

Cool! I'm on it! I hear venture money is falling out of trees these  
days . . . unfortunately, I'm in the desert this week and there  
aren't any trees, but next week is looking good.

--
Dean

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Emil Ivov <[email-masked]>
Date: Mon, 02 Jul 2007 09:13:17 +0200

Dean Willis wrote:
>>> if we don't standardize it. But the FIREWALL doesn't keep track 
>>> of TCP connections. It just looks at syn/ack to determine whether
>>>  an incoming packet appears to be part of an established TCP
>>> flow. If it is an initial connection "opening" from outside, it
>>> gets discarded. This is completely stateless inspection on the 
>>> firewall. It does leave one a bit open to SYN-flood DOS attacks, 
>>> but there are other workarounds for that.
>>  for P2P even when TCP based because it won't allow for end-to-end

Relaying certainly makes sense for media, but I was actually referring
to the peer protocol and connections among peers. The VoIP application
widely advertised as P2P, that I think you are referring to, would
indeed work behind these firewalls but only as a client. I don't think
that nodes located behind them would be promoted to peers (or super
nodes or whatever).

>>> Now if you can figure all this out, let me know and I'm sure I 
>>> can find some startup money to make us both rich!
>> Heey, no problem. I am sure that if we start entangling photons 
>> right now in a month or two we'll be able to build a quantum 
>> firewall and it'll be doing all kinds of magic, so you better get 
>> that money ready! :-))
> 

OK, then alternately, I could take care of the money, and you could take
care of the photons!

Cheers
Emil
> -- Dean