Subject: [p2p-sip] Fw: STUN (rfc3489)

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 4 Jul 2006 08:07:42 -0500

Rather than just posting an "I agree with Greg on this one" note, I'll ask 
the more charter-related question - is it our intention to let other people 
work on NAT traversal while we work on P2P-SIP without much focus on NAT 
traversal, and then look at the state of NAT traversal when we've done our 
own work?

Thanks,

Spencer

----- Original Message ----- 
From: "Greg Daley" <gregd at research.panasonic.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: <p2p-sip at cs.columbia.edu>
Sent: Monday, July 03, 2006 3:06 PM
Subject: Re: [p2p-sip] STUN (rfc3489)

> Dear Peter.
>
> Peter Pan wrote:
>>> But unless the system knows beforehand, it can't use this capability,
>>> as it cannot be reliably detected.
>>>
>>> Working for unknown subsets of NATs isn't a useful requirement IMO.
>>>
>>
>> Capability detection of NAT (or more appropriate to say, of node) seems a
>> well-known technology for many years. Or, nothing would be worth $ 
>> billions.
>
> The issue isn't about new devices.
> If new devices are deployed, they can be IPv6 capable, or UPNP.
>
> It's about writing protocols that work with legacy services which
> cannot be upgraded.
>
> The existing NAT Detection in RFC3489 is deprecated in the draft
> precisely because the unreliability of the detection decreases
> its worth.
>
>
>> I don't mind at all any newer definition of the technology, just as I 
>> cannot
>> forbid the sky from raining or my mother from remarrying :)
>
> I hope that you get your wish in both cases anyway.
>
> Greg
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 4 Jul 2006 09:14:31 -0400

My personal hope is that we consider NAT traversal as an important and
integral issue, but any actual new work in the area be done in other
working groups. I think we should architect our protocols to work with
NATs, and if needed refer problems (if any) with the current suite of
tools to other WGs (BEHAVE, MMUSIC, or what have you).

David

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 4 Jul 2006 09:22:52 -0500

My hope as well - that's why I'm asking!

Spencer

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 04 Jul 2006 16:30:26 +0200

> traversal, and then look at the state of NAT traversal when we've done our 

Mechanisms for NAT traversal -- binding discovery, connectivity check,
binding keepalive as well as media connectivity establishment -- will be
those defined by BEHAVE and MMUSIC WGs.  What we have to start thinking
from the beginning is if/when/how it's worth adopting such mechanisms
for allowing peers behind NATs to participate in distributed service
implementation.

Enrico

---

From: tjc at ecs.soton.ac.uk (Tim Chown)
Date: Tue, 4 Jul 2006 15:28:29 +0100

> > tools to other WGs (BEHAVE, MMUSIC, or what have you).

But how much complexity is "architecting our protocols to work with NATs" 
going to add?

-- 
Tim/::1

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 4 Jul 2006 11:09:52 -0700

> But how much complexity is "architecting our protocols to work with NATs"

Perhaps you would not like to exclude the preludes for P2PSIP to dance with
these WGs.

RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is used to
discover the STUN server following these procedures...The DNS SRV service
name is 'stun' (1)...The default port for STUN requests is 3478 (2)...STUN
makes use of a shared secret between client and server(3)...   A: This is
the "change IP" flag.  If true, it requests the server to send the Binding
Response with a different IP address than the one the Binding Request was
received on(4) "

ASSUMING no central STUN server but many SNs acting as *volatile* STUN
servers (VSS), these can be regretful among others:

(1). DNS may be infeasible in serverless world, not to mention SRV.
(2). Any well-known port (3478) or ephemeral private port is unreachable if
most VSSs are to be behind NATs.
(3). Shared secrets between STUN clients and VSSs may turn to a chicken or
an egg.
(4). All goodness of the "change IP" flag vanishes with normal single-IP
VSSs w/o *hard wires* between.
(5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs.

Maybe I've decipered the bis wrong or maybe P2PSIP has reserved more seats
for central servers than for serverlessness, otherwise wish these odds and
sods weren't considered deployment-specific.

Peter

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 05 Jul 2006 11:21:11 -0400

Hi Peter

Peter Pan wrote:
[cut]
> (1). DNS may be infeasible in serverless world, not to mention SRV.

Discovery will have to be done another way.
My guess is that we will use the same mechanisms which are
needed for Super Peer (SP) discovery.

> most VSSs are to be behind NATs.

This has no impact on the protocol itself, and can be included in the
discovery information gleaned previously.

> (3). Shared secrets between STUN clients and VSSs may turn to a chicken or

That's not true.

The Shared-Secret establishment in STUN allows previously unknown hosts
to gain binding access.

As a STUN Relay, it's feasible to use a different authentication
mechanism (perhaps based on the credentials to contact a Super Peer)
but this is not strictly necessary.

I know, we've implemented STUN Relay with the short term passwords,
as described in RFC3489bis.

> VSSs w/o *hard wires* between.

"Change IP" is not needed in RFC3489bis.

> (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs.

Neither is the case.

We have running code.

Greg

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Wed, 05 Jul 2006 18:24:48 +0200

> needed for Super Peer (SP) discovery.

As long as PUT/GET operations do not require STUN, we can rely on lookup
functionalites provided by the overlay.  For example, when a device
which has a SIP UA and a STUN Server on joins the overlay, it will bind
its contact address both to its AOR and to a special URN which
identifies the STUN service (e.g. "urn:service:stun").

Enrico

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 5 Jul 2006 09:37:10 -0700

> identifies the STUN service (e.g. "urn:service:stun").
Hi,  Enrico.

Could you further elaborate your oracle, for examples, about whether on
earth STUN in whatever form is required, when it is used relative to node
joining and AOR binding, and how, should it be required?

Thanks a lot!

Peter

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 5 Jul 2006 13:45:32 -0400

I mostly agree with David on this one.

I suspect that much of the work on NAT traversal will happen in other  
WGs,
even if it is done for P2PSIP purposes.

For example, I have been spending a fair amount of time recently on ICE
(= an MMUSIC protocol for setting up connections between two peers
in NAT situations) to make sure it will work well in P2PSIP  
applications.

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 5 Jul 2006 13:50:28 -0400

> But how much complexity is "architecting our protocols to work with  

The main complexity I see it adding is the need for peers to route  
requests
on behalf of other peers.

- Philip

---

From: dwing at cisco.com (Dan Wing)
Date: Wed, 5 Jul 2006 13:46:21 -0700

(for background, I am co-author of rfc3489bis-03 and co-chair of 
BEHAVE.)

> Perhaps you would not like to exclude the preludes for P2PSIP 
> to dance with these WGs.
> 
> RFC 3489bis03 says, "Unless stated otherwise by a STUN usage, DNS is
> used to discover the STUN server following these procedures...The
> DNS SRV service name is 'stun' (1)...The default port for STUN
> requests is 3478 (2)...STUN makes use of a shared secret between
> client and server(3)...  A: This is the "change IP" flag.  If true, 
> it requests the server to send the Binding Response with a different 
> IP address than the one the Binding Request was received on(4) "
> 

Agreed.  You will need to define a STUN usage which won't use DNS
but would rather use some other mechanism to find a STUN server.

> (2). Any well-known port (3478) or ephemeral private port is 
> unreachable if most VSSs are to be behind NATs.

Agreed.  Related to (1).

> (3). Shared secrets between STUN clients and VSSs may turn to 
> a chicken or an egg.

The authentication of STUN messages protects against certain 
on-path attacks.  Many threat models don't worry about on-path
attackers (who can spoof TCP RSTs, among other things).

> (4). All goodness of the "change IP" flag vanishes with 
> normal single-IP VSSs w/o *hard wires* between.

You probably noticed the CHANGED-ADDRESS attribute includes
the following text at the end of its section:

      Issue:  should this attribute be made specific to Binding
      Discovery or moved to another document entirely.

RESPONSE-ADDRESS, CHANGE-REQUEST, and SOURCE-ADDRESS all have 
this same issue, and are being considered for removal from 
rfc3489bis.

> (5). 12.3.2 & 12.3.3 seem to me another two chickens or eggs.

But P2PSIP's chicken-or-egg problem exists no matter if you 
use STUN to learn your public IP address+port or if you use 
something else to learn your public IP address+port:  once
you learn it, you need to register it.  

If you know where to register your IP address+port, you can 
also know where a STUN server can be found.

> Maybe I've decipered the bis wrong or maybe P2PSIP has 
> reserved more seats for central servers than for 
> serverlessness, otherwise wish these odds and

-d

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 05 Jul 2006 18:40:54 -0400

Dan Wing wrote:
[cut]
> also know where a STUN server can be found.

I guess this is the essential point.  Another mechanism
needs to be available for either or both of these operations.

There's some description of how this may be achieved
in a couple of documents, but essentially there may be
a combination of multicast and unicast techniques
(SLP, SLP DS, DNS SRV, well known address?)

One technique (DNS) isn't sufficient if we also want
disconnected network cases to work correctly.

Greg

---

From: dwing at cisco.com (Dan Wing)
Date: Wed, 5 Jul 2006 15:49:56 -0700

> > If you know where to register your IP address+port, you
> > can also know where a STUN server can be found.
> 

Yep - solve one and you have solved the other.

> disconnected network cases to work correctly.

Agreed.  To do that you're looking to some kind of zeroconf
techniques.  http://en.wikipedia.org/wiki/Zeroconf has a 
decent list of solutions and techniques in this space.

-d

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 5 Jul 2006 23:21:30 -0700

> >
> > May I know how you are using RFC 3489bis or which existing RFC(s) you
are
> > using, without the "change IP" flag, to learn a node behind some
*friendly
> > types* of NAT can act as a SN?
>
> We're not doing NAT type detection.
>
> Nat type detection is deprecated in RFC3489bis.
> As explained before, it's unreliable.
>
> We're implementing ICE, using STUN (bis) and STUN
> Relay, base on the current revisions of
>
> draft-ietf-behave-rfc3489bis
> draft-ietf-mmusic-ice
> draft-ietf-behave-turn
>
> This gives us a STUN relay over which to run media,
> and SIP messages.
>
> There's not much more to say.
>
> Greg

Hi Greg,

I bow to these standards and drafts. However, they seems lego only; still
need glue and correct order to glue them for full interoperability among
products using these standards. This is what I meant "chickens and eggs".

Also, by saying "the offer/answer exchange itself must be capable of
traversing the NAT.  Such traversal is facilitated through signaling
elements such as SIP servers, and is outside the scope of this
specification...", ICE seems a shotgun mainly for media streams, not a rifle
for signaling/overlay msgs to penetrate NAT. (Does it assumed that an
overlay and/or a dialog has been formed before ICE is utilized??) When a
restricted node can learn its mapped address only, it can think itself
super, ignorantly or maliciously. When a restricted address is registered
and offered to the others as a SN, overlay inaccuracy is incremented. What
if you're offered hundreds or thousands of useless restricted addresses
before one of a real SN?

Miserably deprecated NAT type detection is the rifle. Rifles may miss
sometimes, but to bring down a flying bird 1 rifle excels 3+ shotguns.

Peter

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 5 Jul 2006 23:56:41 -0700

> decent list of solutions and techniques in this space.

Hi, Dan.

Which (serverless & DNSless) technique do you think the best for WAN or for
a P2PSIP universe? Thanks for any light.

Peter

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 06 Jul 2006 11:28:52 +0200

> joining and AOR binding, and how, should it be required?

I think that natted nodes will need STUN for:
+ participating in the overlay (i.e. STUN should be coupled with the
  "peer protocol");
+ being reachable (i.e. STUN should be used in some mecanisms similar to
  those defined in the outbound draft);
+ establishing media connectivity (i.e. ICE).

OTOH, I hope that the "client protocol" would not need any NAT traversal
mechanisms.  Since its operations have the natted node -- the client --
always as the source and never as the destination, I'm quite confident
it won't.  That's why I think that once a client is able to query the
overlay, it doesn't require any other mechanism for discovering STUN
servers.

Enrico

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 6 Jul 2006 09:08:21 -0400

That model is not end to end,  which limits functionality.   Why should
there be a distinction?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060706/62d48c3b/attachment.html

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 06 Jul 2006 15:29:26 +0200

It *is* end to end.  On the client side there is a UA which has not
joined the overlay yet, while on the server side there is a SN which,
since it has already joined, is reachable from anywhere.  There is no
infrastructure but the overlay.

With "client protocol" and "peer protocol" I'm trying to be consistent
with concepts draft; I hope I'm not causing confusion.

Enrico

Michael Slavitch wrote:
> On 7/6/06, *Enrico Marocco* <enrico.marocco at telecomitalia.it
> <mailto:enrico.marocco at telecomitalia.it>> wrote:
> 
> 
>     p2p-sip at cs.columbia.edu <mailto:p2p-sip at cs.columbia.edu>

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 6 Jul 2006 10:04:06 -0400

It can be a little confusing, yes, so my apologies.  As long as any SN can
be placed anywhere I can see no problem.

If SN's require configuration and have location dependence based on NAT
there may be an issue downstream but let's get going.

Regards

M

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060706/c7e5de08/attachment-0001.html

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Thu, 6 Jul 2006 10:23:11 -0400

> overlay and/or a dialog has been formed before ICE is utilized??) When a

Although ICE has certainly been developed for media streams, I think
it may still have an important purpose for P2PSIP overlays.  Obviously
STUN is the backbone, but ICE is very useful for determining what the
best way is to communicate between two nodes that share a control
connection with a third node (or nodes).  This could be a common case
either when two P2PSIP Overlay Clients try to connect to each other or
during P2PSIP Overlay Peer Insertion.

Bruce

---

From: dwing at cisco.com (Dan Wing)
Date: Thu, 6 Jul 2006 07:30:01 -0700

> Which (serverless & DNSless) technique do you think the best 
> for WAN or for a P2PSIP universe? Thanks for any light.

If by WAN you mean the Internet, I don't believe any of the
zeroconf techniques cited in that wikipedia article provide
a DNS-like, serverless rendezvous service for the Internet.

-d

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 06 Jul 2006 11:20:02 -0400

Hi Dan,

Dan Wing wrote:
[cut]
> a DNS-like, serverless rendezvous service for the Internet.

I think that there are examples of local, and beyond the
first hop multicast techniques which can help where
available.

It's pretty clear though that there's no pervasive
L3 multicast system which can be used for this purpose.

So the mechanisms for bootstrap may require a set of
fixed servers, one would hope that dynamic server
information could be cached for later use, in order
to aid scalability.

I'd guess you'd like to be able to use local zeroconf-like
techniques if possible, falling back to dynamic servers,
and static servers successively.

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 6 Jul 2006 08:24:24 -0700

> overlay, it doesn't require any other mechanism for discovering STUN

The assumption "once a client is able to query the overlay" is an egg.

The optimum "it doesn't require any other mechanism for discovering STUN
servers" is its chicken.

They seems in a fantasyland.

Peter

---

From: adamfisk at gmail.com (Adam Fisk)
Date: Thu, 6 Jul 2006 11:33:53 -0400

> during P2PSIP Overlay Peer Insertion.

Agreed.  All of these protocols have been deployed primarily for media
streams, aka UDP.  There's nothing in ICE that restricts it to UDP,
however, just as there's nothing in STUN that restricts it to UDP.  In
our case, we'd likely advertise TCP addresses for simultaneous open
across NATs using ICE.

It seems this conversation is getting way off track.  If we're talking
about using these protocols to have NATted nodes participate in DHTs,
that's still a long way off and would be a far greater diversion than
this group should pursue at this time, in my humble opinion.  NATted
peers that cannot open ports using UPnP should just be client/leaf
nodes and leave it at that.

-Adam

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 6 Jul 2006 08:52:07 -0700

> this group should pursue at this time, in my humble opinion.

Yep, we should have others make king beds. We just stack the king beds to
build our house.

> NATted peers that cannot open ports using UPnP should just be client/leaf

Do you or anyone know the percentage of residential or even enterprise users
who ever use uPnP? I thought uPnP is used only in Microsoft :-)

Peter

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 06 Jul 2006 18:10:30 +0200

> They seems in a fantasyland.

Do they?  They would be chicken and egg if they were mutually dependent,
but do you really think they are?

As long as "client protocol" (draft-willis-p2psip-concepts) queries can
be done in an HTTP-like fashion, i.e. TCP or UDP connections initiated
by natted clients and addressed to reachable peers, they don't need any
NAT traversal support to succeed.  Or are you aware of any NAT scenario
where you need STUN for effectively using HTTP?

Enrico

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 6 Jul 2006 09:27:30 -0700

Peter
----- Original Message -----
From: "Enrico Marocco" <enrico.marocco at telecomitalia.it>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Greg Daley" <gregd at research.panasonic.com>; <p2p-sip at cs.columbia.edu>
Sent: Thursday, July 06, 2006 9:10 AM
Subject: Re: [p2p-sip] Fw: STUN (rfc3489)

> where you need STUN for effectively using HTTP?
Yes, I'm just confused, because sometimes you said STUN is required
sometimes not.

Please shed more light to me about:

* how to define the "reachable peers"? (without have them contact any STUN
server)
* which entity in a P2PSIP network is in charge of defining "reachable
peers"? (I know it is you in P2PSIP ML :)

Peter

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 6 Jul 2006 10:12:50 -0700

> peers"? (I know it is you in P2PSIP ML :)

My questions can be stupid and confusing. Let's put a scenario in *reversed*
order:

<= via ICE a NAT-restricted node is offered with public addresses of some
"reachable peers" to be as its Relay candicates
<= the "reachable peers" learn their mapped addresses by some mechanism or
just by STUN (though it is said as not needed sometimes)

How can these reachable peers know whether they are *really reachable* from
nodes other than the one(s) they've queried for mapped address?

Who confirms these reachable peers of their reachability from the other
nodes?

Thanks for the patience of you and all.

Peter

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 06 Jul 2006 19:14:42 +0200

> Yes, I'm just confused, because sometimes you said STUN is required

It is not so complicated.  Natted nodes require STUN for everything but
locating (through DNS, zeroconf, well-known nodes...) and quering
(through HTTP-like transactions) peers.  And since nodes can perform
queries, they can also obtain addresses of STUN servers.

Enrico

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 6 Jul 2006 10:32:12 -0700

Hi, Enrico.

Where nodes can query still seems oracle to me. But forget about it. I'm
kinda stupid and stubborn.

Peter

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sun, 23 Jul 2006 08:58:51 -0700

Sounds reasonable to me - I was fairly convinced by the arguments  
that trying to add NAT support later would be very hard.