Subject: [tram] draft-johnston-tram-stun-origin-00

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 9 Jan 2014 17:51:00 -0800

Hi

I've been reviewing the draft
http://www.ietf.org/mail-archive/web/tram/current/maillist.html .

The general idea definitely makes sense.

Large TURN servers may indeed need separate realms for separate groups of
users. It would make the administration more structured. Also, the TURN
server may provide different level of services for different realms. For
example, the "front" TURN server may just redirect with 300 error different
origins to different backend servers with different configurations.

One thing that I wish to be included into the draft would be the exact new
STUN attribute value (section 2). Without that value, a test/proof of
concept implementation cannot be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The value 0x802F is in comprehensive-optional range, and it is not taken
(yet).

Thanks
Oleg
http://code.google.com/p/rfc5766-turn-server/

---

From: Alan Johnston <[email-masked]>
Date: Thu, 9 Jan 2014 22:48:05 -0600

Oleg,

Thanks for the review.  Glad you think it makes sense.  Hopefully an
approach such as we have proposed will make it possible to have STUN and
TURN servers that support multiple domains.

I was thinking using that attribute value, but I held off putting it in the
draft, hoping for 1) feedback from STUN/TURN experts, and 2) making sure
there was interest in the approach.  If others like the approach and think
this value makes sense, then we will rev the draft adding the value.
 Having a browser and a server implement the extension would make for an
excellent proof of concept.

Note: I want to draw everyone's attention to the IPR declaration on the
draft (https://datatracker.ietf.org/ipr/2293/).  It is a standard
free-if-you-re-not-suing-us license, so hopefully it will be OK.

- Alan -

---

From: Dan Wing <[email-masked]>
Date: Thu, 9 Jan 2014 20:57:13 -0800

On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko <[email-masked]> wrote:

> Hi
> 
> I've been reviewing the draft http://www.ietf.org/mail-archive/web/tram/current/maillist.html .
> 
> Large TURN servers may indeed need separate realms for separate groups of users. It would make the administration more structured. Also, the TURN server may provide different level of services for different realms. For example, the "front" TURN server may just redirect with 300 error different origins to different backend servers with different configurations.

Couldn't that be achieved with separate hostnames like

  realm1.turn.example.com
  realm2.turn.example.com
  realm3.turn.example.com
  ...

with each going to the same IP address or each to a different IP address, as needed, without support in the protocol?

-d

> One thing that I wish to be included into the draft would be the exact new STUN attribute value (section 2). Without that value, a test/proof of concept implementation cannot be done. I'd suggest a definition like:
> 
> The value 0x802F is in comprehensive-optional range, and it is not taken (yet).
> 
> Thanks
> Oleg
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Alan Johnston <[email-masked]>
Date: Fri, 10 Jan 2014 00:59:18 -0600

Dan,

Yes, that could be done, but would require a lot of provisioning in the
TURN server and also in the ICE Servers URIs of the JavaScript.  This isn't
scalable, either, and could be mixed up by developers copying code.

- Alan -

On Thu, Jan 9, 2014 at 10:57 PM, Dan Wing <[email-masked]> wrote:

> with each going to the same IP address or each to a different IP address,
> as needed, without support in the protocol?
>
> -d
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 10 Jan 2014 00:10:37 -0800

> as needed, without support in the protocol?
Yes and no. What I like about the proposed solution is that it gives more
control to the TURN server administrator and the overall admin structuring
is better - less parts involved. All changes outside of the TURN server are
"virtual" and "logical" - they all can be ignored and are 100%
backward-compatible.

Regards,
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 10 Jan 2014 00:18:49 -0800

> free-if-you-re-not-suing-us license, so hopefully it will be OK.
Alan, I am not a lawyer and I am not sure how combining IETF draft/standard
with a patent works. Some wording sounds disturbing:

"If the standard is adopted, Avaya will not assert the above-identified
patents against any party for making, using, selling, importing or offering
for sale a product that implements the standard".

But what about the period BEFORE the standard adoption ? Does that mean
that if I add the draft's functionality to our TURN Server BEFORE the RFC
adoption, then you will have the grounds to sue me - for this relatively
common-sense approach ?

Thanks
Oleg

---

From: Dan Wing <[email-masked]>
Date: Fri, 10 Jan 2014 01:09:16 -0800

On Jan 10, 2014, at 12:10 AM, Oleg Moskalenko <[email-masked]> wrote:

> Yes and no. What I like about the proposed solution is that it gives more control to the TURN server administrator and the overall admin structuring is better - less parts involved. All changes outside of the TURN server are "virtual" and "logical" - they all can be ignored and are 100% backward-compatible. 

It might help for the I-D to discuss those advantages, to provide motivation for the new STUN attribute.

-d

---

From: Simon Perreault <[email-masked]>
Date: Fri, 10 Jan 2014 09:23:34 -0500

Le 2014-01-09 23:57, Dan Wing a écrit :
> realm1.turn.example.com <http://realm1.turn.example.com>
> realm2.turn.example.com <http://realm2.turn.example.com>
> realm3.turn.example.com <http://realm3.turn.example.com>
>    ...
>
> with each going to the same IP address or each to a different IP
> address, as needed, without support in the protocol?

IMHO, no.

The problem I'm considering is that of a TURN server that is shared by 
many tenants. Each tenant has its own WebRTC app and its own user DB. 
Using many domains with a single IP doesn't solve this problem: the 
server still doesn't know which realm to reply with. The only solution 
is using one IP address per tenant. And that sucks. And this draft solve 
that. So I like it.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Fri, 10 Jan 2014 09:32:58 -0500

Le 2014-01-09 20:51, Oleg Moskalenko a écrit :
> One thing that I wish to be included into the draft would be the exact
> new STUN attribute value (section 2). Without that value, a test/proof
> of concept implementation cannot be done. I'd suggest a definition like:
>

The problem is that as soon as there's a value in the draft and it gets 
implemented, it becomes de-facto standard, and people complain if you 
try to change it later. Or if the draft gets abandoned, and a different 
draft needs a value, you may have trouble reallocating the value if it 
is "dirty", i.e. used in the wild (currently or in the past) without an 
official allocation. There are already a bunch of those dirty values in 
the STUN IANA registry, and that sucks.

IMHO, wait until the draft is stable before picking a value, Or even 
better, follow the process in RFC 4020.

Simon

---

From: Alan Johnston <[email-masked]>
Date: Fri, 10 Jan 2014 09:13:22 -0600

Oleg,

No, absolutely not!  We wrote this draft because we see a need for it and
we want implementations of it in browsers and servers and adoption of it as
a standard.  Gaining early experience is key to achieving that.

I'm not a lawyer either, but unfortunately with today's insane patent
situation, this type of defensive patent is unfortunately becoming more
common.

- Alan -

On Fri, Jan 10, 2014 at 2:18 AM, Oleg Moskalenko <[email-masked]>wrote:

> Alan, I am not a lawyer and I am not sure how combining IETF
> draft/standard with a patent works. Some wording sounds disturbing:
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 10 Jan 2014 10:30:34 -0800

That's cool.

When the value of the ORIGIN attribute is more-or-less determined (thru RFC
4020 process or else), I'll implement it in the TURN server.

Regards,
Oleg