Subject: [P2PSIP] NAT Traversal Discussion in Vancouver

From: Philip Matthews <[email-masked]>
Date: Tue, 27 Nov 2007 11:27:01 -0500

Folks:

The chairs have asked me to lead a discussion of "NAT Traversal for  
P2P Messages". What I would like to get is a solid idea of what  
people would like to see discussed during this slot.

As I see it, there are four parts to the whole P2PSIP NAT traversal  
discussion:

1) The high-level NAT Traversal approach that most people seem to be  
adopting is the idea of routing around the overlay to reach peers  
behind NATs. As I understand it, that is going to be covered in the  
"Routing: What does it look like?" discussion. As I see it, even the  
recent ideas to include Relays would fall under that discussion.  
[Spencer: Do you agree?]

2) The very-low-level NAT Traversal approach is ICE, and I don't see  
anyone questioning that. I don't think a discussion of this is worth  
precious meeting time.

This leaves two medium-level issues:

3) Is NAT Traversal is done by each application separately, or is  
done once (by HIP or the Peer Protocol)? In essence, this morphs into  
the whole ID/Locator split idea.

4) How does a peer locate STUN and TURN servers?

Both (3) and (4) would be good topics for a 15 minute discussion, but  
I feel that there is only time for one of these. So I would like to  
choose just one for the discussion. There have been drafts discussing  
both of these, but I think that (3) has been a hotter topic recently  
than (4), so my preference is to discuss (3).

Comments?
Is there something that I have missed?

- Philip

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 27 Nov 2007 11:41:13 -0800

> There have been drafts discussing both of these, but I think that (3) 
> has been a hotter topic recently There have been drafts discussing  

The beauty (of 3; HIP use) is in the eye of the beholder and the
discussions on it may have been due to the fact that it is more
controversial.

Topic 4 (How does a peer locate STUN and TURN servers?)
seems to me more realistic for the Internet 'as is' today and more
interesting. So a counter suggestion is:

- Give topic 4 preference and let's start with it,
- If time permits, I would be interested to understand 

a. How can HIP be used on existing platforms without modifying the
TCP/IP stack? What are the costs and trade-offs in complexity and time
to market?

b. There are several _name based routing_ proposals in the works and HIP
is only one of them. NUTSS is another. Is there a neutral party to
inform us about this field? Just to get a comparison and to make a
reasonable risk assessment on what will eventually get deployed.

The reasons why HIP is championed for P2PSIP have been well articulated
on this list and in the I-Ds, so it is time to take a more balanced look
at all the options that may becomes available with name based routing,
whenever/if this happens. 

Henry 

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, November 27, 2007 10:27 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] NAT Traversal Discussion in Vancouver

Folks:

Comments?

- Philip

---

From: "David Barrett" <[email-masked]>
Date: Tue, 27 Nov 2007 11:54:40 -0800

> anyone questioning that. I don't think a discussion of this is worth

Though it needn't be a topic of discussion, can you ask the attendees if
anybody has some real-world performance and reliability data on ICE that
they can share?  I don't think any has been published to date, but perhaps
new data has come out since our last requests.

Indeed, if anybody has this data (or can get it), this would be an excellent
time to share it.  Specifically, I'm curious to know how long it typically
takes to set up a particular connection, and with what probability it can
establish a direct connection between two arbitrary peers on the internet.
("Connection setup" and "peer connectivity")

Thanks!

-david

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 27 Nov 2007 15:38:47 -0500

Happy to have discussion like that on list or in halls and such, since
it is relevant to building these things, but that definitely isn't in
our space, and I don't want to discuss that in meeting - we have
enough things for our agenda. Be a better topic over in MMUSIC...

David (as chair)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: <[email-masked]>
Date: Wed, 28 Nov 2007 22:30:59 +0200

Hi Philip,

I agree that 3 and 4 are interesting issues but in my opinion 4 is much
more important. I do not see HIP flying anyway. It introduces complexity
and does not offer clear advantages over widely implemented protocols.
Besides HIP together with a distributed nature of P2PSIP introduces more
questions than answers. In my opinion it is a good protocol for
researcher to play with but I see problems with wide deployment of HIP. 

Marcin 

>From: ext Philip Matthews [mailto:[email-masked]] 
>Sent: 27 November, 2007 18:27
>To: P2PSIP Mailing List
>The chairs have asked me to lead a discussion of "NAT 
>Traversal for P2P Messages". What I would like to get is a 
>solid idea of what people would like to see discussed during this slot.
>
>1) The high-level NAT Traversal approach that most people seem 
>to be adopting is the idea of routing around the overlay to 
>reach peers behind NATs. As I understand it, that is going to 
>be covered in the
>"Routing: What does it look like?" discussion. As I see it, 
>even the recent ideas to include Relays would fall under that 
>discussion.  
>[Spencer: Do you agree?]
>
>2) The very-low-level NAT Traversal approach is ICE, and I 
>don't see anyone questioning that. I don't think a discussion 
>of this is worth precious meeting time.
>
>3) Is NAT Traversal is done by each application separately, or 
>is done once (by HIP or the Peer Protocol)? In essence, this 
>morphs into the whole ID/Locator split idea.
>
>Both (3) and (4) would be good topics for a 15 minute 
>discussion, but I feel that there is only time for one of 
>these. So I would like to choose just one for the discussion. 
>There have been drafts discussing both of these, but I think 
>that (3) has been a hotter topic recently than (4), so my 
>preference is to discuss (3).
>
>Comments?

---

From: "Greger V. Teigre" <[email-masked]>
Date: Fri, 30 Nov 2007 09:45:42 +0100

To ICE testing, the only data I have seen are from pjsip and only 
anecdotal.
Cut from blog entry: 
http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and-turn/

"I've tried with running two pjsua's behind the same NAT that doesn't do 
hairpin, and the local address pair is used. And trying two pjsua's 
behind different NATs, the public address pair is used. So it looks like 
it's working!
More over, I've been testing it since last week, and quite few bugs have 
been found and fixed. And negotiation is pretty quick, around 100 ms 
with two endpoints on different ADSL line, even though the SDP answer 
was delayed in the proxy (ICE is able to start the checks early even 
when SDP answer hasn't been received by caller).
But one of the major difficulties with testing ICE these days is 
practically there is no other freely available ICE implementation out 
there (I mean, ICE-14/15 compliant ones), so although ICE implementation 
in PJNATH does seem to work, and it follows ICE-15 closely, we couldn't 
be sure that it is compliant until it talks with other implementation. 
So if any of you know one, please do let me know!"

The implementation is documented here: 
http://www.pjsip.org/pjnath/docs/html/index.htm

The library was recently updated to the latest updates. I haven't seen 
any larger scale testing yet.
g-)

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 30 Nov 2007 06:43:02 -0800

(I changed the Subject header)

Greger,

You have given us a valuable pointer to ICE NAT traversal at 

http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun
-and-turn/ where the implementer says:

So Does It Work? 

Yes! (or, erm.. I think so!)

The point is that if ICE does not work satisfactory, there must be a
plan B for NAT traversal for P2PSIP. 

Remember the WG assumption that most endpoints will be behind several
levels of NAT.

We also want 100% success ratio as well as low call setup delay.

One plan B is the model to just use an "openDHT-like overlay" as a
service. 

Endpoints behind NAT may just work using one of several pre-provisioned
or discovered STUN/TURN servers, after which all the p2p happens as in
the openDHT. I believe ICE has a much better chance as well when two
endpoints have to just connect to the DHT.

http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf 

Incidentally, the paper also shows the excellent security properties of
this approach when using the overlay in data mode. Look at Table1.

I understand there are P2P SIP demos working exactly this way.

There is no time to discuss plan B next week in the WG meeting, but
don't exclude the possibility it may happen sometimes later.

Henry

________________________________

From: Greger V. Teigre [mailto:[email-masked]] 
Sent: Friday, November 30, 2007 2:46 AM
To: David Barrett
Cc: 'Philip Matthews'; 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver

To ICE testing, the only data I have seen are from pjsip and only
anecdotal. 
Cut from blog entry:
http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun
-and-turn/

David Barrett wrote: 

	-----Original Message-----
	From: Philip Matthews [mailto:[email-masked]]
	Subject: [P2PSIP] NAT Traversal Discussion in Vancouver
	 
	2) The very-low-level NAT Traversal approach is ICE, and I don't
see
	anyone questioning that. I don't think a discussion of this is
worth
	precious meeting time.

Though it needn't be a topic of discussion, can you ask the attendees if
anybody has some real-world performance and reliability data on ICE that
they can share?  I don't think any has been published to date, but
perhaps
new data has come out since our last requests.
 
Indeed, if anybody has this data (or can get it), this would be an
excellent
time to share it.  Specifically, I'm curious to know how long it
typically
takes to set up a particular connection, and with what probability it
can
establish a direct connection between two arbitrary peers on the
internet.
("Connection setup" and "peer connectivity")
 
Thanks!
 
-david

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 30 Nov 2007 11:43:35 -0800

Hi, Philip,

> Folks:
>
> The chairs have asked me to lead a discussion of "NAT Traversal for  P2P 
> Messages". What I would like to get is a solid idea of what  people would 
> like to see discussed during this slot.
>
> adopting is the idea of routing around the overlay to reach peers  behind 
> NATs. As I understand it, that is going to be covered in the  "Routing: 
> What does it look like?" discussion. As I see it, even the  recent ideas 
> to include Relays would fall under that discussion.  [Spencer: Do you 
> agree?]

yes, I do, and I'm working on slides that cover this. Sorry for not 
responding sooner (you mean you CAN'T read my mind?).

Spencer

---

From: "David Barrett" <[email-masked]>
Date: Fri, 30 Nov 2007 16:28:39 -0800

Are you suggesting that plan B is "don't attempt direct connections between
NAT'd peers" and instead just to relay everything via the DHT?  I think
that's a good fallback plan if a direct connection can't be established.  

Incidentally, also I'd toss out plan C: create a new NAT penetration
protocol that is "ICE-lite".

Basically, refine the best elements of ICE/STUN/TURN into a new protocol
that is simpler to implement and iteratively built in conjunction with
real-world testing (rather than designed first, tested later).

-david

  _____  

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Friday, November 30, 2007 6:43 AM
To: Greger V. Teigre; David Barrett
Cc: Philip Matthews; P2PSIP Mailing List; [email-masked]
Subject: plan B for NAT traversal for P2PSIP 

Greger,

http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and
-turn/ where the implementer says:

So Does It Work? 

The point is that if ICE does not work satisfactory, there must be a plan B
for NAT traversal for P2PSIP. 

Remember the WG assumption that most endpoints will be behind several levels
of NAT.

One plan B is the model to just use an "openDHT-like overlay" as a service. 

Endpoints behind NAT may just work using one of several pre-provisioned or
discovered STUN/TURN servers, after which all the p2p happens as in the
openDHT. I believe ICE has a much better chance as well when two endpoints
have to just connect to the DHT.

Incidentally, the paper also shows the excellent security properties of this
approach when using the overlay in data mode. Look at Table1.

There is no time to discuss plan B next week in the WG meeting, but don't
exclude the possibility it may happen sometimes later.

Henry

  _____  

To ICE testing, the only data I have seen are from pjsip and only anecdotal.

Cut from blog entry:
http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and
-turn/

"I've tried with running two pjsua's behind the same NAT that doesn't do
hairpin, and the local address pair is used. And trying two pjsua's behind
different NATs, the public address pair is used. So it looks like it's
working!
More over, I've been testing it since last week, and quite few bugs have
been found and fixed. And negotiation is pretty quick, around 100 ms with
two endpoints on different ADSL line, even though the SDP answer was delayed
in the proxy (ICE is able to start the checks early even when SDP answer
hasn't been received by caller).
But one of the major difficulties with testing ICE these days is practically
there is no other freely available ICE implementation out there (I mean,
ICE-14/15 compliant ones), so although ICE implementation in PJNATH does
seem to work, and it follows ICE-15 closely, we couldn't be sure that it is
compliant until it talks with other implementation. So if any of you know
one, please do let me know!"

The library was recently updated to the latest updates. I haven't seen any
larger scale testing yet. 
g-)

David Barrett wrote: 

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]]
Subject: [P2PSIP] NAT Traversal Discussion in Vancouver

 

Thanks!
 
-david