Subject: [BEHAVE] STUN/TURN "User Agent"

From: Matthew Kaufman <[email-masked]>
Date: Thu, 17 Apr 2008 21:02:24 -0700

We would like to propose using 0x8030 for "User Agent", with the value as a UTF-8 string which identifies a particular client application. This would be to support logging at the TURN server, and to allow enterprise TURN boxes to allow/block usage by checking this string. (Note that it may easily be forged, but in an enterprise environment applications which forge the User Agent can be banned as a matter of policy, employees terminated for using them, etc.)

Comments?

Matthew Kaufman

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Apr 2008 15:01:04 -0400

What is the purpose of this attribute? Is it to identify exactly which  
client has asked for the allocation?

What about using the USERNAME attribute for this purpose? That is,  
require every client to have a unique USERNAME? If every client had a  
unique username and password, then I think this would give you what  
you want, and would not be forge-able either.

- Philip

On Fri, 18-Apr-08, at 00:02 , Matthew Kaufman wrote:
> We would like to propose using 0x8030 for "User Agent", with the  
> value as a UTF-8 string which identifies a particular client  
> application. This would be to support logging at the TURN server,  
> and to allow enterprise TURN boxes to allow/block usage by checking  
> this string. (Note that it may easily be forged, but in an  
> enterprise environment applications which forge the User Agent can  
> be banned as a matter of policy, employees terminated for using  
> them, etc.)
>
> Comments?
>
> Matthew Kaufman
>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 18 Apr 2008 19:56:02 -0700

User Agent is (like the same field in an HTTP header) independent of the 
Username and describes the client application (rather than the user or 
particular instance of that application). For example, I might have a 
Username of "matthew" but a User Agent of "Acme Softphone 1.0" for one 
client application I use, and a Username of "matthew" and a different 
User Agent of "Newco Messenger" for a different client application.

This allows for logging of which client applications are using a 
particular proxy, simplifies debugging if particular client applications 
have issues not experienced by other client applications, and in closed 
ecosystems (e.g., enterprise DMZ-based proxies) might be used to allow 
certain approved client applications.

By the way, I am now able to say that the software we are developing 
that we know will be widely distributed is in fact the next version of 
the Adobe Flash Player, and we intend to use TURN to allow our new 
UDP-based network protocol to work in enterprise environments that have 
UDP blocked but want to enable applications based on the new networking 
capabilities we are adding. We would be happiest if the subset of TURN 
we ship to everyone for this purpose ends up matching what is in the 
final specification of the protocol.

Matthew Kaufman

Philip Matthews wrote:
>> application. This would be to support logging at the TURN server, and 
>> to allow enterprise TURN boxes to allow/block usage by checking this 
>> string. (Note that it may easily be forged, but in an enterprise 
>> environment applications which forge the User Agent can be banned as 
>> a matter of policy, employees terminated for using them, etc.)
>>
>> Comments?
>>
>> Matthew Kaufman
>>
>>
>

---

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Apr 2008 10:07:14 -0400

From a narrow technical perspective, I can see how your proposed  
field differs from Username. However, is it not likely that Adobe will  
set up its own set of TURN servers to support its Flash Player which  
will differ from the TURN servers set up by Acme for their "Acme  
Softphone 1.0"?  So in practice is there going to be a difference?

Note that I could see a difference if Adobe starts shipping multiple  
different client types and you want to distinguish between them.  
However, I don't get the sense that this is what you want to do (but  
perhaps I am wrong).

Anyone else have any comments on Matthew's proposal?

- Philip

BTW, I would be tempted to rename the attribute to "Client", given  
that the term "User Agent" doesn't exist in TURN.

On Fri, 18-Apr-08, at 22:56 , Matthew Kaufman wrote:
> User Agent is (like the same field in an HTTP header) independent of  
> the Username and describes the client application (rather than the  
> user or particular instance of that application). For example, I  
> might have a Username of "matthew" but a User Agent of "Acme  
> Softphone 1.0" for one client application I use, and a Username of  
> "matthew" and a different User Agent of "Newco Messenger" for a  
> different client application.
>
> particular proxy, simplifies debugging if particular client  
> applications have issues not experienced by other client  
> applications, and in closed ecosystems (e.g., enterprise DMZ-based  
> proxies) might be used to allow certain approved client applications.
>
> that we know will be widely distributed is in fact the next version  
> of the Adobe Flash Player, and we intend to use TURN to allow our  
> new UDP-based network protocol to work in enterprise environments  
> that have UDP blocked but want to enable applications based on the  
> new networking capabilities we are adding. We would be happiest if  
> the subset of TURN we ship to everyone for this purpose ends up  
> matching what is in the final specification of the protocol.
>
> Matthew Kaufman
>
> Philip Matthews wrote:
>> What is the purpose of this attribute? Is it to identify exactly  
>> which client has asked for the allocation?
>>
>> require every client to have a unique USERNAME? If every client had  
>> a unique username and password, then I think this would give you  
>> what you want, and would not be forge-able either.
>>
>> - Philip
>>
>>
>>> and to allow enterprise TURN boxes to allow/block usage by  
>>> checking this string. (Note that it may easily be forged, but in  
>>> an enterprise environment applications which forge the User Agent  
>>> can be banned as a matter of policy, employees terminated for  
>>> using them, etc.)
>>>
>>> Comments?
>>>
>>> Matthew Kaufman
>>>
>>>
>>
>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 21 Apr 2008 07:25:01 -0700

Philip Matthews wrote:
> From a narrow technical perspective, I can see how your proposed field 
> differs from Username. However, is it not likely that Adobe will set 
> up its own set of TURN servers to support its Flash Player which will 
> differ from the TURN servers set up by Acme for their "Acme Softphone 
> 1.0"?  So in practice is there going to be a difference?
>
This is a completely different use case of a TURN server, as I've 
mentioned before. The "Internet" use case, and the one I think everyone 
thinks of when they think of STUN/TURN is that a telephony service 
provider would deploy a TURN service on the Internet for use by their 
clients. They would want to restrict the use of their TURN proxies to 
their paying customers, and thus want strong username/password 
authentication. It is also unlikely, as a result, that one service 
provider's software or firmware would be using the TURN servers of 
another service provider, until "white-label" service providers become 
more common. Such providers might in fact want User Agent parameter in 
order to more clearly differentiate between which software or hardware 
is using their service.

The "enterprise" use case (the one we are targeting) is that an 
enterprise would deploy one or more TURN servers in their DMZ in order 
to proxy certain UDP-using applications to the outside of their firewall 
in a controlled fashion. (This is just like the old days of web 
proxying, where enterprises weren't comfortable with opening up port 80 
directly and didn't have transparent proxy features available from their 
firewall vendors.) (This is also where my earlier query about locating 
such an enterprise TURN proxy via DHCP comes from)

In the enterprise case, Adobe doesn't set up its own set of TURN servers 
to support Flash Player... rather, Company XYZ sets up TURN servers to 
support applications that need to get through the firewall, and allows 
their employees to use Flash Player (but might not allow them to use 
some other UDP-using application that also supports TURN, as a matter of 
policy). Now, it might be the case that an enterprise also uses the 
Username field along with their LDAP servers to individually 
authenticate certain employees who are allowed to use the TURN server... 
but this is different than wanting to log which applications are using 
the TURN server, or allow/deny based on which application it is. Again, 
in an enterprise environment, an application could claim to be something 
it isn't, but employees can get fired for downloading and running such a 
thing.

> However, I don't get the sense that this is what you want to do (but 
No. While we will likely use different variations on the User Agent 
string for other applications we ship that use our new UDP-based network 
protocol and which will need a proxy mechanism, it isn't because we will 
be setting up a globally-accessible service that needs to know... it 
would just be so that enterprise IT departments can meet their logging 
requirements.

Please remember that we're talking about large organizations who need to 
do things like get their proxy services signed off by the people doing 
their Sarbanes-Oxley compliance audits, and that is where the 
requirement that applications using the proxy be identified for logging 
purposes comes from.
> that the term "User Agent" doesn't exist in TURN.
I think that "Client" is somewhat more ambiguous, but I'm not attached 
to the name, just making sure we have a place we can send such a value.

Matthew Kaufman

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Apr 2008 10:16:40 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Matthews
> Sent: Monday, April 21, 2008 7:07 AM
> To: [email-masked]
> Cc: Behave WG
> Subject: Re: [BEHAVE] STUN/TURN "User Agent"
> 

I note that rfc3489bis has a free-form text field called SERVER which serves a
purpose very similar to what Matthew wants for the client.
<http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-15#section-15.10>
reads:

   15.10. SERVER

   The server attribute contains a textual description of the software
   being used by the server, including manufacturer and version number.
   The attribute has no impact on operation of the protocol, and serves
   only as a tool for diagnostic and debugging purposes.  The value of
   SERVER is variable length.  It MUST be a UTF-8 [RFC3629] encoded
   sequence of less than 128 characters (which can be as long as 763
   bytes).

As an individual, I find it reasonable to have a CLIENT attribute with text
that is similar to rfc3489bis's SERVER attribute.  I would even say such an
attribute should have been in the base specification (rfc3489bis) rather than
just in TURN, but we are too late for that (rfc3489bis is in IESG review).

-d

---

From: "Feng Liu" <[email-masked]>
Date: Mon, 21 Apr 2008 14:08:55 -0400

Hi,

I am not a TURN expert, but have a few comments regarding this issue. 

1) If the purpose of User Agent is for logging purpose, can you use the
IP/port to identify the application? Just like the web proxy or reverse
proxy for web applications, the application is identified by the URL. This
is because, as Matthew pointed out, the User Agent information may or may
not be correct, and using this for logging or identifying different
applications thus may not be a reliable solution.

2) Is it possible/meaningful to have an extension mechanism that allows
different vendors to specify their own extensions such as User Agent? Then
vendors may have the ability to develop their own TURN solutions. This is a
common practice in web services and XML world.

Just my 2 cents,

Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Matthew Kaufman
Sent: Monday, April 21, 2008 10:25 AM
To: Philip Matthews
Cc: Behave WG
Subject: Re: [BEHAVE] STUN/TURN "User Agent"

Matthew Kaufman

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Apr 2008 12:41:26 -0700

> [mailto:[email-masked]] On Behalf Of Feng Liu
> Sent: Monday, April 21, 2008 11:09 AM
> To: [email-masked]; 'Philip Matthews'
> Cc: 'Behave WG'

A NAT can (and often does) change the port, so even if you managed
to always get a certain application to use a fixed port on the host,
the TURN server would see different ports.  This can happen, for 
example, if two PCs are behind a NAT and use the same source port --
the NAT cannot give both PCs the same source port.

> common practice in web services and XML world.

RFC3489bis (also known as 'STUNbis') does have an extension mechanism to add
new attributes, see
<http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-15#section-18.1>.
TURN uses the STUN protocol, so TURN can be extended using vendor-defined STUN
attributes.

-d

> [mailto:[email-masked]] On Behalf Of
> Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 21 Apr 2008 13:19:40 -0700

> applications thus may not be a reliable solution.
The source IP address and port number does not identify the software or 
firmware that is initiating the TURN session.

> common practice in web services and XML world.
It exists,  so that's an option if we can't get agreement around our 
proposal.

Matthew Kaufman

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 21 Apr 2008 15:24:46 -0500

Hi, Dan/Philip/Matthew,

> just in TURN, but we are too late for that (rfc3489bis is in IESG review).

OK, let's start with the process part, first.

If "Someone" was to submit an IETF Last Call comment that says "there's a 
SERVER attribute that does what we want, but we also need a CLIENT 
attribute, with the same text and obvious substitutions" - in fact, it would 
probably look a lot like this:

   15.whatever. CLIENT

   The client attribute contains a textual description of the software
   being used by the client, including manufacturer and version number.
   The attribute has no impact on operation of the protocol, and serves
   only as a tool for diagnostic and debugging purposes.  The value of
   CLIENT is variable length.  It MUST be a UTF-8 [RFC3629] encoded
   sequence of less than 128 characters (which can be as long as 763
   bytes).

I'm not sure why the IESG would freak out. We've done worse, later in the 
process.

Now, for the technical part. Please keep in mind that I'm not a genius of 
STUN/TURN, and don't have opinions about whether "User-Agent" or "CLIENT" 
are really going to be useful.

When this proposed attribute was called "User-Agent", I expressed offline 
concerns based on the HTTP User-Agent experience, where everyone claimed to 
be Mozilla, whether they were Mozilla or not, for a very long time. If 
CLIENT is documented as "no impact on operation of the protocol", that could 
be "good enough" to decide this isn't a likely problem for STUN/TURN - 
SERVER is currently specified with the same language.

If there are reasons for endpoints to lie, I would think both CLIENT and 
SERVER would be problematic (servers could change their behavior based on 
CLIENT values, but clients could certainly change their behavior based on 
SERVER values from previous exchanges - so I don't think having CLIENT is 
any worse than having SERVER, and we have SERVER now).

Thanks,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Apr 2008 19:17:52 -0400

I think this is a good idea. I know there have been a bunch of times I  
have been trying to debug what is going on where this would have been  
really useful. I suspect adding it to 3489bis might be the best place  
to do it.

Cullen <with my individual hat on>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 22 Apr 2008 08:42:26 +0300

> really useful. I suspect adding it to 3489bis might be the best place

Yeah, it may help troubleshooting IOP problems, and collect statistics.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Apr 2008 16:32:34 -0400

Matthew:

Dan's proposal (below) seems a good one to me. Will this meet your  
needs?

If it does, then there seems to be enough support for this idea to  
include it in the base TURN spec.

- Philip

On Mon, 21-Apr-08, at 13:16 , Dan Wing wrote:
> <http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-15#section-15.10 
> >
> reads:
>
>   15.10. SERVER
>

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 22 Apr 2008 13:35:43 -0700

Philip Matthews wrote:
> Matthew:
>
> Dan's proposal (below) seems a good one to me. Will this meet your needs?
>
Yes.

> include it in the base TURN spec.
That would be good, and we'll use the code point that gets assigned that 
way, assuming the number is assigned before we ship.

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Apr 2008 16:36:54 -0400

> any worse than having SERVER, and we have SERVER now).

The proposal is to make this a free-form text field with no specified  
values. Moreover, I would add some text to say that its purpose is for  
logging and debugging. This will not completely prevent people  
determined to do this from using it to drive behavior, but I don't see  
how to do any better than this.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Apr 2008 13:59:00 -0700

(as an individual,)

> The proposal is to make this a free-form text field with no 
> specified values.  Moreover, I would add some text to say that 
> its purpose is for logging and debugging. 

So you want this only in TURN, and not in the base STUN specification?

> This will not completely prevent people determined to do this from 
> using it to drive behavior, but I don't see how to do any better 
> than this.

Nothing will prevent this; if someone wanted to signal special behavior
they could encode a tag into the Username attribute, as you described
earlier.  Or they could register a proprietary attribute and use that,
or have their TURN client and server use non-IANA ports.  I'm sure
there are another dozen techniques.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Apr 2008 13:56:04 +0200

> I'm not sure why the IESG would freak out. We've done worse, later in the 

I don't think the IESG will freak out. If the WG likes to add this to 
STUNbis I think we have satisfied procedure by having a consensus call 
in the WG and if strong consensus exist go forward. The IESG will of 
course need to have the possibility to put DISCUSS so probably putting 
it back on a call before approving it.

If going forward with this idea, I would please remind that you 
shouldn't forget the security issues with this header. I think HTTP (RFC 
2616) has some text on the issues with Client (User-Agent in HTTP) 
implementation identifiers.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 23 Apr 2008 10:02:10 -0400

When we moved 3489bis ahead, most folks realized there was a  
reasonable chance that small changes might be needed to 3489bis coming  
out of the ICE or TURN work. I don't think IESG would have any  
heartburn over this if the WG wanted to do it.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Apr 2008 10:05:11 -0400

> heartburn over this if the WG wanted to do it.

I see a lot of "if the WG wanted it"...

I, for one, am not an author nor an IESG member, and I want it.

Is it OK now? ;)

/me hums