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

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

By the way, could you also reveal your *standard* way of distributing
*different* shared-secret between *different peer pairs* for stronly secure
STUN operation to proceed?

Your kindness can also save us many exchanges of spits on a topic that has
lasted for so long time. I'm sure everyone here will appreciate it very much
if it is indeed all standard and working.  ^_^

Peter
----- Original Message -----
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "Greg Daley" <gregd at research.panasonic.com>
Sent: Wednesday, July 05, 2006 8:58 AM
Subject: Re: [p2p-sip] Fw: STUN (rfc3489)

> Hi Greg,
>
> Thanks for the comments.
>
> 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?
>
> Peter
> ----- Original Message -----
> From: "Greg Daley" <gregd at research.panasonic.com>
> To: "Peter Pan" <huang-ming.pan at comcast.net>
> Cc: "Tim Chown" <tjc at ecs.soton.ac.uk>; "Spencer Dawkins"
> <spencer at mcsr-labs.org>; <p2p-sip at cs.columbia.edu>
> Sent: Wednesday, July 05, 2006 8:21 AM
> Subject: Re: [p2p-sip] Fw: STUN (rfc3489)
>
>
> > Hi Peter
> >
> > Peter Pan wrote:
> > [cut]
> > >
> > > 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.
> >
> > 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.
> >
> > > (2). Any well-known port (3478) or ephemeral private port is
unreachable
> if
> > > 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
> > > an egg.
> >
> > 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.
> >
> > > (4). All goodness of the "change IP" flag vanishes with normal
single-IP
> > > 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: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 05 Jul 2006 15:59:57 -0400

Hi Peter.

> STUN operation to proceed?

We're just using the temporary passwords created with
shared-secret-request/response from STUN.

There's no identity tied to it, except that provided by
certs in TLS.

The TLS session protects the shared password generation,
and every other (non-TLS protected) message is signed using
the HMAC-SHA1 over the message using the shared secret.

This protects the allocate-request/response and indication
packets from modification.  There's no encryption though.

It's all in the rfc3489bis document (except I think the existing
version is described with MD5).  From my reading of ML discussion,
I think I read about a move to SHA1.

> if it is indeed all standard and working.  ^_^

It's not rocket science.
I read the draft, and picked an authentication method.
I didn't implement all of them yet.

Greg

---

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

> packets from modification.  There's no encryption though.

Like sheeps dancing with wolves, the temporary (created) shared secret seems
no secret without trusted relationship or TLS.

By TLS connection to VSS behind NAT, you mean NAT penetration with TCP,
which may fail in usual cases.

Peter

---

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

Peter Pan wrote:
[cut]
> no secret without trusted relationship or TLS.

Sure, if you take away TLS it's not secure ;)

If you take away a man's legs it's hard for him to walk.

Really though, the client can be guaranteed the server is the right
one, because of the server's verifiable certificate chain.

If it makes sense, and the STUN server wishes to know about the
client, mutual authentication based on public keys/certificates
can be performed.

Even without mutual authentication though, the host may choose
to trust the STUN Relay effectively, though the converse isn't
necessarily true.  This is sufficient to prevent eavesdropping
or man-in-the-middle on the delivered secret.

> which may fail in usual cases.

Why would you ever try to contact a STUN server behind a NAT (at least
from the public Internet)?

If the STUN server is on the public Internet and an ordinary peer is
behind a NAT, TCP will not fail (firewalls on the other hand...).

Greg
PS. Can you please not abbreviate STUN server as VSS.
     It doesn't aid clarity.

---

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

> behind a NAT, TCP will not fail (firewalls on the other hand...).

Would you sponsor the public STUN servers? :) I thought we're all serious
about true serverlessness, at least with the best efforts.

> PS. Can you please not abbreviate STUN server as VSS.

My apology. I thought whoever recognized the term "VSS" might have the
common sense of the volatility of STUN servers for P2PSIP.

---

From: saikat at cs.cornell.edu (Saikat Guha)
Date: Thu, 06 Jul 2006 17:44:13 +0100

> > from the public Internet)?

You can run a STUN server behind a NAT with a static mapping, much like
you would an HTTP server behind a NAT today.

> about true serverlessness, at least with the best efforts.

Consider 'reachability' a resource much like you would bandwidth or
processing power. 

P2P networks need to accommodate peers with heterogeneous resources --
offload expensive computation to desktops rather than cellphones, not
require modem users to upload as much as you would a
university/internet-2 host etc. In the same vein, I don't see anything
inherently non-serverless about public nodes providing STUN service.

2c
-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060706/5b0f536e/attachment.bin

---

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

Hi, Saikat.

You don't need to encapsulate your email to reach me :-)

But in no way you can reach me at any (mapped) static address, STUN or HTTP,
behind my NAT, which is very friendly-made by Netgear. I never disable
anything of it but just pretend as naive and happy as ordinary users.

Peter
----- Original Message -----
From: "Saikat Guha" <saikat at cs.cornell.edu>
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:44 AM
Subject: Re: [p2p-sip] Fw: STUN (rfc3489)

2c
--
Saikat

---

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

Hi Peter,

> about true serverlessness, at least with the best efforts.

I'm not talking about infrastructure, the publically addressed peers
are likely to be providing the STUN service: Volatile STUN Servers,
in your parlance.

Your question was about NAT traversal to stun servers on private nets
which doesn't make sense.

Greg

---

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

Hi Saikat,

> you would an HTTP server behind a NAT today.

Sure you can, but what is the purpose?

> inherently non-serverless about public nodes providing STUN service.

Agreed.  Peers may provide limited service in support of others,
so long as they don't experience hardship.

Greg

---

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

> which doesn't make sense.
Hi, Greg.

When a node behind NAT can become your SN, and possibly also become your
voicemail storage server or even class 5 switch, why does the tinier effort
make no sense to equip the SN with STUN server capability?

I don't think all the IPs in my Skype cache are of public-addressed hosts.
Of course, it is proprietary of original sin.

Peter

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 06 Jul 2006 15:38:48 -0400

> make no sense to equip the SN with STUN server capability?

None of those sound like a good idea to me.

> Of course, it is proprietary of original sin.

The allusion surpasses me,
but yes, they are all publically addressed.

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 7 Jul 2006 09:18:40 -0700

> None of those sound like a good idea to me.

Thanks. Your trash is my treasure :)

> but yes, they are all publically addressed.

What I observed seems no.

Except those with port 33033, most of them are NAT-mapped addresses of SNs.

Niklas Zennstrom said that Skype has <10 servers worldwide (likely for aaa).

Peter

---

From: saikat at cs.cornell.edu (Saikat Guha)
Date: Fri, 07 Jul 2006 17:40:39 +0100

> None of those sound like a good idea to me.

Actually, when it comes to Skype, all Skype SN's serve as STUN servers.

In fact, all Skype nodes with a public addresses (SN or not) serve as
STUN servers. See [1].

Skype nodes uses their local address as part of the key for encrypting
signaling traffic. Any public node (SN or otherwise) receiving such an
encrypted packet from a NAT'ed Skype node sees gibberish (since the
apparent source IP/Port isn't the same as the source's local IP/port).
Upon receiving such gibberish, it responds with the source's apparent
IP/port == STUN address. The source thus learns it's external address
(from any public peer it contacts), and re-sends the packet encrypted
with its external address. [2]

[1] S. Guha, N. Daswani and R. Jain. "An Experimental Study of the Skype
Peer-to-Peer VoIP System," In Proceedings of The 5th International
Workshop on Peer-to-Peer Systems (IPTPS '06), Santa Barbara, CA,
February 2006.

[2]
http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf

cheers,
-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060707/d912b55f/attachment.bin

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Fri, 07 Jul 2006 18:45:09 -0400

Hi Saikat,

> with its external address. [2]

Peter's original assertion was that the SP (SN) or STUN server
is behind a NAT. I was responding to that idea particularly.
The essential point with the technology in STUN (+ STUN Relay)
and in Skype is that a publicly addressed node acts as a helper.

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 7 Jul 2006 17:01:24 -0700

Hi Greg,

My assertion, if any, is that a SN/STUN server *CAN BE* behind a NAT. It
might sound a mission impossible to you. Never mind. Alongside iron steel
sometimes feels Orz :D

I wish you abundance of publicly addressed helpers for your billion-users
network as well as a wonderful weekend.

Peter

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Fri, 07 Jul 2006 23:59:21 -0400

> might sound a mission impossible to you. Never mind. Alongside iron steel

I'm not saying that it can't be.

I'm saying that it's not a resonable goal, with the protocols
available to us today.

We don't have enough time or resources to fix both the NAT
traversal issue with non-publically addressed servers, and
create a peer-to-peer SIP system.

Let's focus on what's achievable with the resources available
in a reasonable amount of time.

If someone wants to do research on that, I'd be happy to see
it.

Let's not go off in P2PSIP now, and contemplate all these
peripheral issues in depth.

It's not going to help achieve a workable protocol.

Greg

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 7 Jul 2006 23:46:44 -0700

> > might sound a mission impossible to you. Never mind...
>

Overtrumped by the constraints, I cannot but agree with your reasonable
compromise.

Not knowing the constraints until now, I've been expecting that any
"workable" P2PSIP protocol should go as far as imagination could reach.
Though I cannot figure out the reasons of your squeeze and hurry, I apology
for delay and interference from my naive expectation.

Peter

P.S. In the future when time or resource is no more a constraint, will
P2PSIP approach true serverlessness with better efforts ? I can wait la :-)

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sat, 8 Jul 2006 22:24:40 -0700 (PDT)

As much as I like STUN and ICE, I don't look with
pleasure at the idea of building NAT traversal inside
a DHT, and inside session signalling, and inside every
media stream... I believe we will be much better off
with a layered solution:

             +---------------+
             | Media stream  |
             +---------------+
             | SIP           |
             +---------------+
             | DHT           |
             +---------------+
             | NAT traversal |
             +---------------+

At the bottom layer, something like Teredo could deal
with NAT traversal, making the whole architecture much
simpler.

-- Karst

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com