Subject: [Ietf-behave] STUN Server Discovery

From: <[email-masked]>
Date: Mon, 4 Sep 2006 06:40:30 -0500 (CDT) (envelope-from [email-masked])

Hi,

There seems to be a new non backwards compatible STUN server discovery
process in RFC3489bis (draft-ietf-behave-rfc3489bis-04). I'd hereby like
to initiate a discussion on this issue.

As I've understood, the RFC3489 specifies the services like this (in
9.1):
_stun._tcp.example.com          Shared secret service with TLS (*)
_stun._udp.example.com          Binding query service with UDP

...and RFC3489bis like follows (in 8.1):
_stun-pass._tls.example.com     Shared secret service with TLS (*)
_stun._tcp.example.com          Binding query service with TCP (*)
_stun._udp.example.com          Binding query service with UDP
_stun._tls.example.com          Binding query service with TLS

As can be seen, the shared secret service and binding query service via
TCP have conflicting service queries (marked with '*').
If (and when) a client want's to implement support for both RFC3489 and
RFC3489bis, this becomes a clear problem.

What I'd like to see is that the RFC3489bis would be changed to specify
the discovery process in a way which would not conflict with the RFC3489
specification. Backwards compatibility here would be beneficial for both
the STUN clients and servers.

Second issue regarding the STUN services, is that I'd like to see
consistent default ports for all of the (relevant) STUN services (like
RFC3489 has). The same kind of a conflict is visible also here:

RFC3489:
-Shared secret service with TLS:        3478
-Binding query service with UDP:        3478

RFC3489bis:
-Shared secret service with TLS:        (none)
-Binding query service with UDP:        3478
-Binding query service with TCP:        3478

Having default ports (and of course consistent ones) would enable
implementation of clients which have only STUN server address configured
(i.e. no STUN domain). This would be userful in situations where the
(server/network) setup is static, and thus constant DNS SRV queries
would be unnecessary. Here the ports would have to be configured, just
because there are no default ports.

--
Tomi

---

From: <[email-masked]>
Date: Wed, 6 Sep 2006 00:51:39 -0500 (CDT) (envelope-from [email-masked])

Hi,

Since nobody seems to have anything to say to these issues, I'll now add
my solution proposals for these problems here.
Hopefully this will trigger some discussion.

1) DNS SRV Query:

Since the RFC3489 had a different interpretation of the protocol part in
"_stun._tcp.example.com" (meaning TLS, instead of  TCP), I suggest that
RFC3489bis would specify a new service, namely "stun-bind". This service
would solely be the STUN binding  query service as specified in
RFC3489(bis).
Now, if a client supports both the new and old specification versions,
it can first try the new service names "stun-pass" and  "stun-bind". If
these do not give results, the client can try the old ones.

RFC3489:
_stun._tcp.example.com          Shared secret service with TLS
_stun._udp.example.com          Binding query service with UDP

RFC3489bis:
_stun-pass._tls.example.com     Shared secret service with TLS
_stun-bind._udp.example.com     Binding query service with UDP
_stun-bind._tcp.example.com     Binding query service with TCP
_stun-bind._tls.example.com     Binding query service with TLS

2) Default STUN ports:

For the default port assignment, I'd say that the RFC3489 ports should
be preserved. If we need new default ports, those  should not conflict
with the old ones.
So, the default ports could be like this:

RFC3489:
-Shared secret service with TLS:        3478
-Binding query service with UDP:        3478
RFC3489bis:
-Binding query service with TCP:        ?

Kind regards,
Tomi Kohonen

>-----Original Message-----
>From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
>Sent: 04 September, 2006 14:40
>To: ietf-behave@xxxxxxxxxxxxxxxxxxx
>Subject: [Ietf-behave] STUN Server Discovery
>
>
>Hi,
>
>There seems to be a new non backwards compatible STUN server 
>discovery process in RFC3489bis 
>(draft-ietf-behave-rfc3489bis-04). I'd hereby like to initiate 
>a discussion on this issue.
>
>As can be seen, the shared secret service and binding query 
>service via TCP have conflicting service queries (marked with '*').
>If (and when) a client want's to implement support for both 
>RFC3489 and RFC3489bis, this becomes a clear problem.
>
>What I'd like to see is that the RFC3489bis would be changed 
>to specify the discovery process in a way which would not 
>conflict with the RFC3489 specification. Backwards 
>compatibility here would be beneficial for both the STUN 
>clients and servers.
>
>Second issue regarding the STUN services, is that I'd like to 
>see consistent default ports for all of the (relevant) STUN 
>services (like
>Having default ports (and of course consistent ones) would 
>enable implementation of clients which have only STUN server 
>address configured (i.e. no STUN domain). This would be 
>userful in situations where the
>(server/network) setup is static, and thus constant DNS SRV 
>queries would be unnecessary. Here the ports would have to be 
>configured, just because there are no default ports.
>
>--
>Tomi
>
>
>_______________________________________________
>Ietf-behave mailing list
>Ietf-behave@xxxxxxxxxxxxxxxxxxx
>https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 7 Sep 2006 10:35:18 -0500 (CDT) (envelope-from [email-masked])

inline.

tomi.kohonen@xxxxxxxxx wrote:

Hi,

In theory perhaps. The reality is, AFAIK, the shared secret service with 
TLS has not been used or deployed to any degree. Thus, I do not believe 
it is important to retain backwards compatibility with that discovery 
procedure.

Furthermore, since binding query service with TCP was never defined in 
RFC3489, there isn't a backwards compatibility issue at all. An older 
client would never try it. A new client trying to contact an old server 
would find that the service is unavailable (no records for it), which is 
exactly the right thing since it is in fact unavailable - this is an old 
server that doesn't support the feature anyway.

The most important thing for backwards compatibility is binding 
discovery for UDP, which is backwards compatible.

Another point, if you are going to build a stun client now, you would 
build an rfc3489bis one. I see no point in doing both.

RFC3489:

RFC3489bis:

Again, the principle difference here is shared secrets with TLS. I still 
assert that backwards compatibility for this is not important.

There is a separate question on whether or not 3489bis should have a 
default port for TLS (for any application usage). This port will 
necessarily be different than 3478. I don't have a very strong feeling 
on this and would be OK with asking IANA for a port.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: <[email-masked]>
Date: Fri, 8 Sep 2006 03:34:10 -0500 (CDT) (envelope-from [email-masked])

Hello,

On  07 September, 2006 Jonathan Rosenberg wrote:
>In theory perhaps. The reality is, AFAIK, the shared secret 
>service with TLS has not been used or deployed to any degree. 
>Thus, I do not believe it is important to retain backwards 
>compatibility with that discovery procedure.

I disagree with this one. There are definitely implementations out
there,
so a good reason is needed for breaking compatibility for these clients.

>Furthermore, since binding query service with TCP was never 
>defined in RFC3489, there isn't a backwards compatibility 
>issue at all. An older client would never try it. A new client 

An older client would do a DNS query for "_stun._tcp", which has 
different semantics in RFC3489 and RFC3489bis. Thus it's a mess
if you are upgrading a server from RFC3489 to RFC3489bis. Of course
the shared-secret procedure would not work anymore, but the old clients
will be able to handle this (as per original 3489).

AFAIK there are also no deployments for RFC3489bis which
utilize "_stun._tcp" yet, so fixing the bis draft should not be a
problem
to anyone, and avoids the break with respect to 3489. Of course, it
seems
difficult to come up with an elegant fix to this ("_stun-bis._tcp"
perhaps), 
but I still think this is a real problem.

-- 
first.surname@xxxxxxxxx (Kai Vehmanen)
Networking Technologies Laboratory, Nokia Research Center

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 8 Sep 2006 03:53:26 -0500 (CDT) (envelope-from [email-masked])

----- Original Message From: <Kai.Vehmanen@xxxx>

Entering style police mode...

If such an approach is thought to be necessary, something like "_stun2._tcp" 
would be better, otherwise we might end up with 
"_stun-bis-bis-bis-bis._tcp"!

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                        for XML to C++ data binding visit
                        http://www.tech-know-ware.com/lmx
                        (or http://www.xml2cpp.com)
=============================================

---

From: <[email-masked]>
Date: Mon, 11 Sep 2006 08:25:34 -0500 (CDT) (envelope-from [email-masked])

Hi,

>>In theory perhaps. The reality is, AFAIK, the shared secret service 
>>with TLS has not been used or deployed to any degree.
>I disagree with this one. There are definitely implementations 
>out there, so a good reason is needed for breaking 
>compatibility for these clients.

I still believe we should make sure that there is no conflicts here
between RFC3489 and RFC3489bis.
If we in any way can make the new RFC3489bis not to conflict here, we
should do it.

Is there reason why this is not possible?

I'd say that adding a new DNS SRV record for the STUN binding request
service might be the way to go here. I would not name this with a
protocol version (like "stun-bis") but rather the protocol name like
"stun-bind", like I wrote earlier. This is consistent with the shared
secret service "stun-pass" as seems to be chosen as the naming
convention in RFC3489bis.

>utilize "_stun._tcp" yet, so fixing the bis draft should not 
>be a problem to anyone, and avoids the break with respect to 
>3489. Of course, it seems difficult to come up with an elegant 
>fix to this ("_stun-bis._tcp" perhaps), but I still think this 
>is a real problem.

Yes, when we have to choose between
1) conflicting with an existing RFC (3489)
or
2) changing an Internet Draft (RFC3489bis),
I don't think we should even concider #1 if we really have to.

>build an rfc3489bis one. I see no point in doing both.

I don't see how implementing a draft would solve this. Drafts tend to
change rapidly, and when they do, we suddenly have a much bigger mess :)
Keep in mind that there is also equipment which can not be updated as
easily as a PC client.
If one must support the current implementations out there (implementing
just RFC3489), we don't have much choice. Implementing the new
RFC3489bis now will not solve this until the servers are updated too.

>There is a separate question on whether or not 3489bis should have a
default port
>for TLS (for any application usage). This port will necessarily be
different than
>3478. I don't have a very strong feeling on this and would be OK with
asking IANA
>for a port.

Ok, please do that :)

--
Tomi Kohonen

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 22:14:31 -0500 (CDT) (envelope-from [email-masked])

On Sep 8, 2006, at 1:34 AM, <Kai.Vehmanen@xxxxxxxxx>  
<Kai.Vehmanen@xxxxxxxxx> wrote:

Can you point me at a deployed one - I've been looking for some flows  
I can capture to show as an example.

Thanks.

---

From: <[email-masked]>
Date: Fri, 6 Oct 2006 03:30:31 -0500 (CDT) (envelope-from [email-masked])

Hello,

On 04 October 2006,  Cullen Jennings wrote:
>Can you point me at a deployed one - I've been looking for 
>some flows I can capture to show as an example.

uhm, that's more difficult to answer. ;) There are definitely
implementations.
One is for example part of the the Sofia-SIP open-source SIP stack. And
there
have been other implementations at testing events. But I do not know of
any widescale deployments (anyone else on the list?)....

Still, the problem remains. As there are clients implemented according
to
RFC3489 - including the shared-secret discovery part, upgrades to
the servers should not break these clients. Specifically, these clients
will make SRV queries for "_stun._tcp", and it would be harmful to reuse
this service name for something else in the bis draft.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Oct 2006 15:20:54 -0500 (CDT) (envelope-from [email-masked])

Kai.Vehmanen@xxxxxxxxx wrote:

Hello,

My concern is that whats in RFC 3489 is a mistake. A big one. It 
conflates the transport protocol with the usage. Those are totally 
separated in RFC3489bis. I am loathe to retain this mistake in 3489bis 
to maintain backwards compatibility with implementations that are not in 
active deployment.

IETF does not guarantee backwards compatibility across revisions of 
specs. When we went from RFC2543 to RFC3261 is was MOSTLY backwards 
compatible. We did remove some features and change some things. For 
example, we removed the absolute date format for registrations and 
focused on relative times, due to interop problems found in time 
synchronization. This did break interoperability in the sense that there 
were *implementations* of the absolute date format, but no real 
deployments that were truly impacted by this. The result is that this 
has been a non-event.

In order to allow STUN to be extensible to other usages and still have a 
story on DNS discovery, we need to be able to have DNS queries of the form:

_usage._transport.domainname

if we retain backwards compatibility this pattern is broken.

-Jonathan R.