[tram] Path Forward for STUN ORIGIN

[Alan Johnston <[e-mail]>]

All,

Based on feedback during IETF-93 in Prague, the authors of
draft-ietf-stun-origin are looking for feedback on a possible path forward
to solve the privacy/meta data issues and clear the DISCUSSes (see
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/).
There are two areas of feedback: Use Cases and Proposed Solution.

Use Cases
========

First, we want to be sure that we are considering all the use cases for
STUN ORIGIN.  In the draft, three are described:

1.  Logging of usage of STUN/TURN server. An operator of a STUN or TURN
server would learn the Origin of the web, SIP, and XMPP users.

2.  REALM selection for multi-tenanted TURN server. This avoids having to
run multiple instances on different ports or IP addresses when more than
one REALM is in use.

3.  Service determination after authentication.  Bandwidth or QoS policy
can be applied, after authentication, based on the Origin.

Also, the following use cases have also been discussed but are not in the
draft

4.  Authorization at border TURN server after authentication.  An
enterprise border TURN server can apply policy and allow usage for certain
Origins (whitelist) or block usage of others (blacklist).

5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with
STUN server could use ORIGIN in authorization decisions.

Are there any other use cases we should consider?

Possible Solution
=============

The solution that was discussed in Prague that seems to be the best
tradeoff between privacy and functionality is to only include ORIGIN
information in a STUN or TURN request if the domain of the Origin matches
the domain of the STUN or TURN server in the STUN or TURN URI.  Since web
and STUN and TURN run on different ports, and often will resolve to
different IP addresses, a full host comparison is not possible.  This
proposal is not perfect: it does not provide perfect privacy for subdomains
(e.g. sub1.example.com and sub2.example.com will match with this rule, even
if they are separate entities.  Of course, subdomain users could always
register a new domain and point DNS records to their sub hoster.)

In comparing this solution against the use cases above:

1. Allows logging of your own users on your own TURN server (or one that
you setup DNS SRV records to point towards).  Other users of your STUN or
TURN server will not be identified by an Origin, but you will at least know
if others are using your server.

2. Works for REALM selection as long as you use your own TURN server (or
one that you setup DNS SRV records to point towards).

3. Again, works for service determination as long as you use your own TURN
server (or one that you setup DNS SRV records to point towards).  Having
service-specific TURN credentials is another solution that doesn't rely on
ORIGIN.

4. & 5. Does not seem provide a good solution for these use cases.

Does this analysis make sense?

Feedback most welcome so we can move forward with this draft.

- Alan -