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

From: "Barrett, David" <[email-masked]>
Date: Tue, 17 Apr 2007 18:48:30 -0700

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.  If this became the norm, so far as I understand it, wouldn’t P2P-SIP cease to function?

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.

Indeed, in this world (the world that BEHAVE is trying to create), only Napster-style, centrally-managed P2P networks can function.  In other words, all DHTs and decentralized overlay networks *will not work* if BEHAVE succeeds.

Is this correct and commonly understood?  Should we talk with the BEHAVE folks about this?

-david

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 17 Apr 2007 22:03:58 -0400

On 4/17/07, Barrett, David <[email-masked]> 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.  If this became the norm, so far as I understand it, wouldn't P2P-SIP cease to function?
>

Here is the text from RFC4787:

   REQ-8:  If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address-Dependent
      Filtering" behavior.

      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

> Is this correct and commonly understood?  Should we talk with the BEHAVE folks about this?

It's not a problem.  (well, it makes life a bit harder, but the
solutions aren't too bad.)  Philip, Eric, David, and I wrote
draft-matthews-p2psip-dsip-nat-traversal that describes how to use ICE
to open connections between peers behind NATs that have endpoint
dependent filtering.

Bruce

---

From: "Barrett, David" <[email-masked]>
Date: Tue, 17 Apr 2007 19:25:32 -0700

Got it, thanks.  Basically, use a partial-mesh of long-lived connections such so long as everyone has a connection to somebody, they can always establish a connection to everybody (is that a fair summary?).

So that seems like a fine mitigation strategy that will enable DHTs (and other decentralized networks) to live for a few more years.  But as the ratio of NAT'd to non-NAT'd increases, and as the ratio of dependent to independent filtering increases, won't even this fail eventually?

(Not to mention that if endpoint-dependent filtering becomes the norms for NATs, it'll also become the norm for firewalls, and thus even the non-NAT'd clients become inaccessible -- both IPv4 and IPv6.  Imagine for a second if this became the standard for Windows Firewall?  Game over.)

Fundamentally, the point I'm making is that BEHAVE is actively fighting what P2P-SIP wants: end-to-end accessibility.  Even if it's not a bullet to the head in the short term, we're on opposite sides of the issue for the long term.

I bring this up because when researching the reasoning behind the BEHAVE decision, it just came down to numbers: there was a vote, and only one DHT advocate was there, so he was outvoted.  Does P2P-SIP feel that it was fairly represented in this issue?

-david

-----Original Message-----
From: Bruce Lowekamp [mailto:[email-masked]]

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 17 Apr 2007 22:40:14 -0400

I think that this solution continues to work as the proportion of
endpoint-dependent filtering NATs increases, it just requires a bit
more work (you always need to ask for help to establish a new
connection).  The solution starts to fail as the proportion of
endpoint-depending mapping NATs increases, but hopefully 4787's MUST
be endpoint-independent mapping will avert that problem.

IIRC, there were some manufacturers who were prepared to ignore
behave's output entirely if it said MUST be endpoint-independent
filtering, but I may be misremembering (and I wasn't at Paris).  Since
there are workarounds, the argument for requiring it wasn't as strong
as for mapping.

Bruce

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 18 Apr 2007 09:58:42 +0200

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Apr 2007 08:18:15 -0400

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Apr 2007 08:25:09 -0400

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

---

From: "Barrett, David" <[email-masked]>
Date: Wed, 18 Apr 2007 10:00:58 -0700

Oops, I should have done my homework better -- it turns out the BEHAVE group does *not* recommend endpoint-dependent filtering as I earlier said.  (In fact, it makes no recommendation, which is unusual, but at least less bad.)  I apologize for the alarmist post.

(Plus, my subject line is wrong -- I meant "filtering", not "mapping".  I long for the good-ole days of just calling it "restricted cone".)

-david

-----Original Message-----
From: Barrett, David [mailto:[email-masked]]
Sent: Tue 4/17/2007 6:48 PM
To: [email-masked]
Subject: [P2PSIP]BEHAVE recommends endpoint-dependent mapping, kills p2p-sip?

-david

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 18 Apr 2007 19:18:13 +0200

Barrett, David wrote:
> Oops, I should have done my homework better -- it turns out the BEHAVE
> group does *not* recommend endpoint-dependent filtering as I earlier
> said.  (In fact, it makes no recommendation, which is unusual, but at
> least less bad.)  I apologize for the alarmist post.

Actually it recommends both :-(

>From RFC 4787:

-- 
Ciao,
Enrico

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 19 Apr 2007 09:58:52 -0700

David,

In addition to what Bruce Lowekamp has mentioned to this trail, I would
like to add that the bootstrap peers can also be collocated with
STUN/TURN relays so that with ICE, NAT traversal is also always
possible.

Let's hope however that your comments will be taken into consideration
by BEHAVE.

>there was a vote, and only one DHT advocate was there, so he was
outvoted.  >Does P2P-SIP feel that it was fairly represented in this
issue?

Consensus is the worst design approach IMHO, if it is not backed up by
running code and testing of implementations, as used to be the rule in
the IETF. Or people who don't have an implementation should have no
vote. Period.

Beware the flames :-)

Thanks, Henry

-----Original Message-----
From: Barrett, David [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 9:26 PM
To: Bruce Lowekamp
Cc: [email-masked]
Subject: RE: [P2PSIP] BEHAVE recommends endpoint-dependent mapping,kills
p2p-sip?

Got it, thanks.  Basically, use a partial-mesh of long-lived connections
such so long as everyone has a connection to somebody, they can always
establish a connection to everybody (is that a fair summary?).

So that seems like a fine mitigation strategy that will enable DHTs (and
other decentralized networks) to live for a few more years.  But as the
ratio of NAT'd to non-NAT'd increases, and as the ratio of dependent to
independent filtering increases, won't even this fail eventually?

(Not to mention that if endpoint-dependent filtering becomes the norms
for NATs, it'll also become the norm for firewalls, and thus even the
non-NAT'd clients become inaccessible -- both IPv4 and IPv6.  Imagine
for a second if this became the standard for Windows Firewall?  Game
over.)

Fundamentally, the point I'm making is that BEHAVE is actively fighting
what P2P-SIP wants: end-to-end accessibility.  Even if it's not a bullet
to the head in the short term, we're on opposite sides of the issue for
the long term.

I bring this up because when researching the reasoning behind the BEHAVE
decision, it just came down to numbers: there was a vote, and only one
DHT advocate was there, so he was outvoted.  Does P2P-SIP feel that it
was fairly represented in this issue?

-david

-----Original Message-----

Bruce

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 21:05:48 -0700

I agree with Philip. And I think we have plenty of examples that show  
what he is saying is true.

Cullen <with my individual hat on>