Subject: [p2p-sip] NATs and P2P

From: slavitch at objectworld.com (Michael Slavitch)
Date: Tue, 21 Mar 2006 10:14:58 -0500

This I believe is a disastrous approach.  If it's not resolved day one
it will not happen.

SIP put this off ten years ago, because NAT was thought bad, something
that would go away. It didn't happen.

I'm sorry, but if it doesn't address NAT we might as well go home.  The
whole point of the overlay is to get around structures such as NAT,
different addressing (IPV4/IPV6), walled gardens and the like.

In a pure IPV6 world we already have a P2P SIP protocol.  It is called
SIP.

M 

Michael Slavitch           Lead, Strategic Initiatives 
slavitch at objectworld.com   Objectworld Communications Corp. 
+1.613.599.9698 .225       Ottawa, Ontario, Canada

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Brijesh Kumar
Sent: March 21, 2006 10:18 AM
To: Bruce Lowekamp; Philip Matthews
Cc: P2P-SIP
Subject: Re: [p2p-sip] NATs and P2P

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

----- Original Message -----
From: "Bruce Lowekamp" <lowekamp at cs.wm.edu>
To: "Philip Matthews" <philip_matthews at magma.ca>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Monday, March 20, 2006 8:58 PM
Subject: Re: [p2p-sip] NATs and P2P

> 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:
> > [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
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
> >
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 21 Mar 2006 10:28:32 -0500

As the proposed charter says, I believe that we have the consensus that
NAT traversal should be addressed from day one.
That's why we have talked so much about ICE and so on.
Thanks.

Eunsoo

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 21 Mar 2006 09:31:34 -0600

I must agree with Michael on this one.

At Avaya, we have been actively investigating various P2P-SIP  
approaches.
We started with the approach suggested by Brijesh (ignore NATs at  
first).
However, when we started considering NATs, we were amazed at how much
this influenced the overall architecture. We ended up re-thinking  
quite a few
things.

- Philip

On 21-Mar-06, at 9:14 , Michael Slavitch wrote:

> This transmission (including any attachments) may contain  
> confidential information, privileged material (including material  
> protected by the solicitor-client or other applicable privileges),  
> or constitute non-public information. Any use of this information  
> by anyone other than the intended recipient is prohibited. If you  
> have received this transmission in error, please immediately reply  
> to the sender and delete this information from your system. Use,  
> dissemination, distribution, or reproduction of this transmission  
> by unintended recipients is not authorized and may be unlawful.
>
> Any views, opinions and content presented in this e-mail are solely  
> those of the author and may not represent those of Objectworld  
> Communications Corp.
>

---

From: kumarb at research.panasonic.com (Brijesh Kumar)
Date: Tue, 21 Mar 2006 11:33:00 -0500

Eunsoo:

Thanks for pointing to the past discussion, and use cases.

After re-reading the  use cases and some of the threads for
requirements of NAT to enable these use cases.   I  realize that
support for NAT is needed from  early  on, and hence  fully
support your comment that the integration of the NAT is needed
in the architecture from the beginning.  Count me in for this, please.

Cheers,

--brijesh

----- Original Message ----- 
From: "Eunsoo Shim" <eunsoo at research.panasonic.com>
To: "Michael Slavitch" <slavitch at objectworld.com>
Cc: "Brijesh Kumar" <kumarb at research.panasonic.com>; "Bruce Lowekamp"
<lowekamp at cs.wm.edu>; "Philip Matthews" <philip_matthews at magma.ca>;
"P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Tuesday, March 21, 2006 10:28 AM
Subject: Re: [p2p-sip] NATs and P2P

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 21 Mar 2006 10:30:11 -0800

> I'm sorry, but if it doesn't address NAT we might as well go home.

I believe any incremental p2p-sip approach a disaster, too. Since all
technologies involved in p2p-sip have been there integrally proven for years
(by Skype) and most of them seem ought to be tightly coupled for feasibility
and interoperability, I believe a "do it once for all and forever" is the
right approach for the late comers (-: us :-) to attract world attention and
deroot all weeds in the future.

I wish I may add one more sentence: "I'm sorry, but if it doesn't address
SECURITY, TOP-LEVEL FEATURES, SPECIFIC OVERLAY(S)... among others we might
as well go home. The whole point of the overlay is to get around structures
such as NAT ... have STRONG SECURITY beneath it, have TOP-LEVEL FEATURES
(voicemail, centrex, ...) above it, and have INTEROPERABILITY surrounding
it."

peter

*** no bash pls. we are of the same country ***

----- Original Message -----
From: "Michael Slavitch" <slavitch at objectworld.com>
To: "Brijesh Kumar" <kumarb at research.panasonic.com>; "Bruce Lowekamp"
<lowekamp at cs.wm.edu>; "Philip Matthews" <philip_matthews at magma.ca>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Tuesday, March 21, 2006 7:14 AM
Subject: Re: [p2p-sip] NATs and P2P

> This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
>
> Any views, opinions and content presented in this e-mail are solely those
of the author and may not represent those of Objectworld Communications
Corp.

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 21 Mar 2006 17:00:01 -0600

> (voicemail, centrex, ...) above it, and have INTEROPERABILITY  

one caveat here. Skype does a lot of its work by doing things like  
tunneling over port 443. The IETF is NOT going to accept any RFCs  
that include this sort of stuff. It's just not going to happen. It's  
a religion thing. Don't waste your time suggesting it, and if this is  
a REQUIREMENT for getting your solution to work, you'd be best served  
by taking it someplace else.

--
Dean

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 21 Mar 2006 15:15:26 -0800

hehe... i smell some unfriendliness. i propose no solution or proprietary
stuff. (i wish i had)

what a mess up!!

peter
----- Original Message -----
From: "Dean Willis" <dean.willis at softarmor.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Michael Slavitch" <slavitch at objectworld.com>; "Brijesh Kumar"
<kumarb at research.panasonic.com>; "Bruce Lowekamp" <lowekamp at cs.wm.edu>;
"Philip Matthews" <philip_matthews at magma.ca>; "P2P-SIP"
<p2p-sip at cs.columbia.edu>
Sent: Tuesday, March 21, 2006 3:00 PM
Subject: Re: [p2p-sip] NATs and P2P

---

From: jh at tutpro.com (Juha Heinanen)
Date: Wed, 22 Mar 2006 10:43:40 +0200

Dean Willis writes:

 > Skype does a lot of its work by doing things like  
 > that include this sort of stuff. It's just not going to happen. 
 > It's a religion thing.

how about what i suggested:  map SIP into XML-RPC rather than tunnel
over?  what kind of IETF religion would prevent that?

-- juha

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Wed, 22 Mar 2006 07:35:44 -0800 (PST)

That sounds interesting idea to me.

-- mike.
-------------------------
Mike Robinson
VoIP Trainer and Consultant

-- juha

---------------------------------
 Yahoo! Mail
 Use Photomail to share photos without annoying attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060322/8c8b6202/attachment.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Thu, 23 Mar 2006 02:48:48 -0600

> over?  what kind of IETF religion would prevent that?

The one that keeps lots of generally useful ideas from proceeding and  
that holds as a tenet "Gee, that sortof conflicts with something we  
already have", perhaps?

Might be right, might be wrong, but it's an article of faith.

--
Dean

---

From: jh at tutpro.com (Juha Heinanen)
Date: Fri, 24 Mar 2006 07:43:28 +0200

> that holds as a tenet "Gee, that sortof conflicts with something we  

there would be no changes to SIP and the mapping to XML-RPC would be
one-to-one.  sure it should be possible to have multiple ways to carry
SIP requests between SIP entities.

-- juha

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Fri, 24 Mar 2006 12:28:41 -0600

> SIP requests between SIP entities.

I see. Actually, someone did a draft mapping of SIP to XML (I think  
it might have been XML-RPC, might have been SOAP) about 5 years ago.  
I thought it was pretty cool, but there was a strong consensus that  
it was "out of scope" for any of the existing working groups. My  
hunch is that  it would still be out of scope, and probably get a  
violent response from the IESG. But that doesn't keep such work from  
proceeding in other venues, and I suspect that there have been  
several academic mapping exercises since.

But this thread is probably getting out-of-scope for P2PSIP, which I  
believe is restricted to making conventional SIP work where the  
locator database is distributed using P2P techniques, not inventing a  
new format for SIP encoding and transport.

--
Dean

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 24 Mar 2006 15:16:24 -0800

XML-RPC might help the fusion of SIP more into Jabber than into P2P.

A Jabber spy seems sneaking in ... :-)

peter
----- Original Message -----
From: "Dean Willis" <dean.willis at softarmor.com>
To: "Juha Heinanen" <jh at tutpro.com>
Cc: "Peter Pan" <huang-ming.pan at comcast.net>; "P2P-SIP"
<p2p-sip at cs.columbia.edu>
Sent: Friday, March 24, 2006 10:28 AM
Subject: Re: [p2p-sip] NATs and P2P