Subject: [p2p-sip] NATs and P2P

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 20 Mar 2006 18:36:26 -0600

[I guess all this traffic on the mailing list will teach me not to go  
on vacation
just before an IETF meeting!]

As I catch up on all the messages about NATs over the past two weeks,
it seems to me that many people are thinking only of the "Public P2P  
Service Provider"
use-case as described in the use-cases document. In other words, a Skype
competitor.

However, the use-cases document that David Bryan and his co-authors  
wrote
identified a number of other use-cases and it seems to me that these  
have somewhat
different NAT traversal requirements.

In particular, in some of these other use-cases, it seems to me that  
we CANNOT assume
there are peers with public IP addresses.

For example, consider the "Presence using Multimedia Consumer  
Electronics Devices"
use-case (section 3.1.3) -- essentially a P2P network of multimedia  
consumer electronics devices
that need presence information. Who is going to pay the extra money  
to give their digital camera (or those
neat 770 tablets that Nokia is demoing here in Dallas?) a public IPv4  
address?? On the contrary,
devices like this are almost certainly going to have private IP  
addresses -- it is very common today for
wireless internet providers to place a big NAT in front of their  
entire network and give private addresses
to all their customers.

Or consider the "IP PBX" use-case -- a IP PBX system for a company  
with a number of small branches
scattered throughout the world. Each branch is going to have a NAT in  
front of its network, and all
the phones in that branch are going to have private IP addresses.  
None of the phones are going to
have public IP addresses.

It is handling the NAT traversal issues for use-cases like these that  
Eric Cooper and I wrote our
internet-draft on NAT Traversal for P2P:
       http://www.ietf.org/internet-drafts/draft-matthews-p2psip-nats- 
and-overlays-00.txt

- Philip

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Mon, 20 Mar 2006 19:58:02 -0600

Philip,

I absolutely agree that we need to have a solution for this type of
environment.   IMHO, some of the worries about NATs causing problems
have been somewhat overstated.  As you point out, the majority of NATs
in the wild are address independent mapping, and it is relatively
trivial to punch holes to establish communications.  But you're also
right that, especially for corporate networks, this doesn't solve the
entire problem.

I spent some time thinking about how to solve the specific problems
you pose in terms of the protocol we have been playing with in
draft-bryan-sipping-p2p.  We completely ignore the issue of NATs in
there (not because we don't think it's a challenge, but just because
we want to work on a basic protocol first).  If I was to address some
of the problems you pose using that framework (modified chord), then
one approach would be to remove the requirement that DHT operations be
iterative and allow them to be recursive.  If DHT operations can be
recursive, then the number of connections that a node must maintain
through the firewall is limited by the size of the finger table.  That
number doesn't have to be very big to have a rather efficient DHT. 
(never more than 128, and I think in practice the number can be much
smaller.  If your guess of 160 is correct, we're more than OK here.)

I'm a bit unhappy with that because I really like the iterative
approach for a variety of reasons, but certainly the protocol could be
modified that way and a hybrid environment could be established where
some nodes are open (or easy to request opens) and support iterative
queries with anyone, but others are recursive queries only.  One
problem is that the burden of having a finger-table entry to a
recursive-only host is placed on the non-recursive node that would
otherwise redirect to its finger-table entry, but now must recurse the
request.

Right now the scheme would also have problems because, as Eric rightly
points out in a separate thread on this mailing list, we don't have a
good way of selecting Identifiers for nodes behind NATs (in
particular).  But if you have node certificates or another way of
authenticating your nodes, this is less of a problem.

I want to make it clear that I'm not ready to propose a specific
solution, but I think there are ways to support structured DHT
algorithms that are not really very painful and work reasonably well
inside these environments.  Clearly support for such an environment
needs to be a listed in eventual requirements docs.

Bruce

On 3/20/06, Philip Matthews <philip_matthews at magma.ca> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>

---

From: kumarb at research.panasonic.com (Brijesh Kumar)
Date: Tue, 21 Mar 2006 10:17:42 -0500

I think Bruce's approach makes sense.

The first task should be to come out with a  base specification
that works. If nothing else, this can be deployed in a hypothetical
pure IPv6 world, or  in a  limited enterprise universe where
traversing NAT may not be an issue.

The second task should be to modify the spec  that works with
NAT.  Trying to resolve NAT issue from day one is good idea, but
one can equally treat is as an extension of the core design.  It is just
a matter of convenience rather than  any hard logic.

Cheers,

--bk

---

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 22 Mar 2006 13:30:24 +0100

> traversing NAT may not be an issue.

Well, I strongly disagree here! That is the usual mistake people
do when design protocols. They do not care about NATs right
from the beginning and need to fix the protocol spec afterwards.
This fixing is at least factor two of effort compared to thinking
about it right from the beginning.

> a matter of convenience rather than  any hard logic.

Ask all the SIP community what a pain this can be.

   Martin