Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip?

Philip Matthews <philip_matthews@magma.ca> Wed, 18 April 2007 12:25 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Dp-0003ym-2C; Wed, 18 Apr 2007 08:25:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Dm-0003ya-Ff for p2psip@ietf.org; Wed, 18 Apr 2007 08:25:14 -0400
Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9Dl-00067b-4z for p2psip@ietf.org; Wed, 18 Apr 2007 08:25:14 -0400
Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3ICPAFj002620; Wed, 18 Apr 2007 08:25:10 -0400
Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l3ICP8OL000641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 08:25:09 -0400
In-Reply-To: <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca>
References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <4625CFB2.4070101@telecomitalia.it> <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <92CC3345-A95F-4EB1-919C-F4D1E74AD5A1@magma.ca>
Content-Transfer-Encoding: 7bit
From: Philip Matthews <philip_matthews@magma.ca>
Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip?
Date: Wed, 18 Apr 2007 08:25:09 -0400
To: David Barrett <dbarrett@akamai.com>
X-Mailer: Apple Mail (2.752.2)
X-magma-MailScanner-Information: Magma Mailscanner Service
X-magma-MailScanner: Clean
X-Spam-Status:
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: P2PSIP WG <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

I should add that, even though all three drafts have my name in their  
filenames,
that just means that I did the work of writing things down. There was  
a host of
people who worked hard at coming up and fleshing out these ideas:
Eric Cooper, Alan Johnston, Bruce Lowekamp, and David Bryan were the  
main
contributors, but others in the IETF also provided inspiration at one  
time or
another.

- Philip

On 18-Apr-07, at 08:18 , Philip Matthews wrote:

> 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".
>
> - Philip
>
>
>
>
> On 18-Apr-07, at 03:58 , Enrico Marocco wrote:
>
>> Barrett, David wrote:
>>> So I'm behind the times, but I just became aware that the BEHAVE  
>>> group,
>>> which is the IETF group dedicated to specifying future NAT behavior,
>>> decided in 8/2005 to recommend that NATs by default implement
>>> "endpoint-dependent" (aka "restricted cone") filtering.
>>
>> Exactly, "filtering", not "mapping" as in the subject.  They are very
>> different things and, in fact,  RFC 4787 explicitly requires
>> endpoint-independent mapping".
>>
>>> Basically, all decentralized P2P networks would stop working as the
>>> ratio of "accessible" to "inaccessible" nodes trends toward  
>>> zero.  At
>>> that point, basically no DHT can possibly function because nobody  
>>> can
>>> accept unsolicited incoming connections.
>>
>> Not true.  In some DHTs, e.g. CAN, nodes use just a pretty stable  
>> set of
>> persistent connections and do not need to receive unsolicited  
>> messages.
>>   If NATs /behave/, what is needed is just a small set of  
>> "unrestricted"
>> peers providing the rendezvous service needed to establish persistent
>> connections between natted peers.
>>
>> -- 
>> Ciao,
>> Enrico
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/p2psip
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip