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
- Re: [P2PSIP] BEHAVE recommends endpoint-dependent… Enrico Marocco
- [P2PSIP] BEHAVE recommends endpoint-dependent map… Barrett, David
- Re: [P2PSIP] BEHAVE recommends endpoint-dependent… Bruce Lowekamp
- RE: [P2PSIP] BEHAVE recommends endpoint-dependent… Barrett, David
- Re: [P2PSIP] BEHAVE recommends endpoint-dependent… Bruce Lowekamp
- Re: [P2PSIP] BEHAVE recommends endpoint-dependent… Philip Matthews
- Re: [P2PSIP] BEHAVE recommends endpoint-dependent… Philip Matthews
- RE: [P2PSIP]BEHAVE recommends endpoint-dependent … Barrett, David
- Re: [P2PSIP]BEHAVE recommends endpoint-dependent … Enrico Marocco
- RE: [P2PSIP] BEHAVE recommends endpoint-dependent… Henry Sinnreich
- Re: [P2PSIP] BEHAVE recommends endpoint-dependent… Cullen Jennings