Re: [BEHAVE] RE: Endpoint-independent filtering is the way to go.

[Philip Matthews <[e-mail]>]

On 23-Apr-07, at 08:41 , Bryan Ford wrote:

> On Sun, 2007-04-22 at 18:02 -0700, Cullen Jennings wrote:
>> I'm curios about what you are suggesting here - let's say two nodes
>> both behind different NAT want to communicate and there is no
>> rendezvous server. I'll assume the NATs have Endpoint-independent
>> filtering. How does this work without a rendezvous server? What
>> address do they use.
>
> Let's be more specific: say they're two nodes participating in a DHT.
> They can learn each others' address/port from any third node already
> participating in the DHT (which may also be behind a NAT).  Any node
> already in the DHT with endpoint-independent filtering will do, and if
> the DHT is big and endpoint-independent filtering is widespread, there
> should be many such nodes - even if practically all of the nodes in  
> the
> DHT are behind NATs.  The same applies if a node is already in the DHT
> but it is just searching through the DHT for a particular key - it
> typically has to contact log(N) nodes to find the key it wants, and if
> these nodes have endpoint-independent filtering, it just finds the  
> next
> target node's address/port from the previous one.  This all falls out
> naturally from any DHT's join/maintenance protocol.
>
> But if nodes with endpoint-independent filtering are rare, then the  
> DHT
> algorithm breaks down because all the NATted DHT node have to  
> hammer on
> one or a very few "true" public rendezvous servers whenever they  
> need to
> talk to ANYONE new.  That's O(log(N)) separate runs of STUN or  
> something
> similar through the central STUN server whenever ANY node wants to  
> join
> or lookup ANYTHING - i.e., O(N log(N)) overall load.  DHT nodes with
> endpoint-dependent filtering can't help out other nodes - they're  
> truly
> "second-class citizens".  You know, 3/5ths of a person and all that.
>
> And if DHT nodes can't help each other out, there's probably no  
> benefit
> of having a DHT at all anymore.  Since you have a server big enough to
> handle the demands of all the clients at once anyway just to handle  
> the
> hole punching load, you might as well just run a centralized hash  
> table
> on that big server in the first place.

Let me repost here an e-mail that I posted to the P2PSIP mailing list a
week ago.  In a nutshell, I believe that DHTs _CAN_ be made to work
when all peers are behind address-dependent filtering NATs,
and the documents below describe how to do this in the specific case
of Chord.

---- Message sent to P2PSIP on April 18th ----
I just want to second what Enrico and Bruce are saying: I believe we  
can live with
NATs and Firewalls that have endpoint-dependent filtering.

The basics of the idea for how to deal with these are described in  
three drafts
     draft-matthews-p2psip-bootstrap-mechanisms, and
     draft-matthews-p2psip-dsip-nat-traversal      (which Bruce  
already mentioned)
     draft-matthews-p2psip-nats-and-overlays

The first draft describes how a node that wishes to join a peer-to- 
peer overlay
can establish a connection to ONE peer in the overlay.
The second draft describes how the node can then leverage this  
connection
to establish a partial mesh of connections to other peers, and then  
use this
partial mesh to route messages through the overlay.
The third draft attempts to explain this idea and compare it with  
other approaches
to NAT Traversal for peer-to-peer networks.

There is still more work to do flesh out all the details, but I  
believe the drafts
adequately describe the core of the idea.

There was a hot debate in the BEHAVE group on the filtering issue.
However, the key fact is that there are many, many NATs today
that already implement endpoint-dependent filtering for "security"  
reasons,
and it was felt that many manufacturers would just ignore the  
recommendation
if the document said "NATs MUST have endpoint-independent filtering".

--- End of message ---

I believe that most people active in P2PSIP today believe that we can  
live
with address-dependent filtering on NATs. It is not ideal, but it is  
not the end
of the world either.

- Philip




_______________________________________________
Behave mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/behave