Subject: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 5 Mar 2015 15:17:51 -0500

Hi TRAM,

I've just written up a proposal for an optional extension to TURN that
would add support for DNS names.  I'd like to discuss this at the upcoming
meeting.

Let me know what you think!

Thanks,
Ben

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Mar 5, 2015 at 3:15 PM
Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt
To: Justin Uberti <[email-masked]>, "Benjamin M. Schwartz" <
[email-masked]>

A new version of I-D, draft-schwartz-tram-turnbyname-00.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the
IETF repository.

Name:           draft-schwartz-tram-turnbyname
Revision:       00
Title:          TURN by name: an extension to TURN for contacting an
endpoint by its DNS name.
Document date:  2015-03-05
Group:          Individual Submission
Pages:          15
URL:
http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt
Status:
https://datatracker.ietf.org/doc/draft-schwartz-tram-turnbyname/
Htmlized:       http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00

Abstract:
   When tunneling traffic through TURN, a client may sometimes desire to
   contact a remote endpoint that it knows by its DNS name, not its IP
   address.  This document describes an extension to TURN that allows
   such a client to contact a named endpoint.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2015 15:55:43 -0500

Le 2015-03-05 15:17, Benjamin Schwartz a écrit :
> would add support for DNS names.  I'd like to discuss this at the
> upcoming meeting.
>

Interesting! You have a twisted mind. ;)

Some random comments/questions as I read the draft:

- What happens when there are multiple A/AAAA records for a name? In 
many places it seems like it is assumed that there will only ever be one 
record.

- The name mapping mechanism is super ugly. It breaks DNS caching. I 
think it would help if you could find a way to get rid of it.

- As soon as the connection to your peer is established, you don't care 
about names anymore. What you care about is the 5-tuple. Yet in your 
proposal the client will keep referring to things by name. This seems 
brittle to me. A more robust design would be to use names in the 
connection initiation phase only, then go back to addresses and ports 
for steady-state.

- Why not just use an unmodified TURN server to proxy UDP packets to 
8.8.8.8:53, for example, and keep all the name-resolving logic client-side?

Simon

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 5 Mar 2015 16:28:50 -0500

On Thu, Mar 5, 2015 at 3:55 PM, Simon Perreault <[email-masked]> wrote:

> - What happens when there are multiple A/AAAA records for a name? In many
> places it seems like it is assumed that there will only ever be one record.
>

Implementation-defined.  I specifically avoided specifying this so that
implementers would be free to use gethostbyname() without worrying about
what it does in this case.

- The name mapping mechanism is super ugly. It breaks DNS caching. I think
> it would help if you could find a way to get rid of it.
>
> brittle to me. A more robust design would be to use names in the connection
> initiation phase only, then go back to addresses and ports for steady-state.
>

I sympathize with both of these points, and I'm totally happy to entertain
alternatives.  (In fact, I've written up several alternatives along those
lines, including one that just introduces a "Resolve Request" message that
resolves a name to an IP address.)

The motivation for this Name Mapping design is to _avoid_ revealing the IP
address to the client, and instead to maintain the kind of DNS abstraction
barrier provided by HTTP CONNECT and SOCKS5 proxies.  For a simple client,
this kind of abstraction does seem convenient.

Also, if the client operates by IP address, then it's likely that WebRTC
will leak the IP through to javascript ... potentially creating a DNS
resolution tool for javascript.  There is currently no such mechanism built
into browsers, so it seems like this should not be done lightly.

If you don't find this convincing, then I'm happy to talk through
alternatives!

> 8.8.8.8:53, for example, and keep all the name-resolving logic

Telling people to hardcode specific DNS server IP addresses in their code,
bypassing network-level DNS configurations like DHCP, gives me the
heebie-jeebies, but I have to admit that this would likely work quite well.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2015 16:41:42 -0500

Le 2015-03-05 16:28, Benjamin Schwartz a écrit :
>     many places it seems like it is assumed that there will only ever be
>     one record.
>

Then the text should say it is implementation-defined. I'm not saying 
that's gonna fly, but at least it won't appear like you overlooked the 
issue.

>     - As soon as the connection to your peer is established, you don't
>     care about names anymore. What you care about is the 5-tuple. Yet in
>     your proposal the client will keep referring to things by name. This
>     seems brittle to me. A more robust design would be to use names in
>     the connection initiation phase only, then go back to addresses and
>     ports for steady-state.
>
>
> I sympathize with both of these points, and I'm totally happy to
> entertain alternatives.  (In fact, I've written up several alternatives
> along those lines, including one that just introduces a "Resolve
> Request" message that resolves a name to an IP address.)
>
> The motivation for this Name Mapping design is to _avoid_ revealing the
> IP address to the client, and instead to maintain the kind of DNS
> abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies.  For a
> simple client, this kind of abstraction does seem convenient.

I agree. The big difference is HTTP CONNECT is TCP-based. The same 
abstraction would apply perfectly to TURN-TCP. For UDP it's much more 
clumsy.

> resolution tool for javascript.  There is currently no such mechanism
> built into browsers, so it seems like this should not be done lightly.

Good point.

>     8.8.8.8:53 <http://8.8.8.8:53>, for example, and keep all the
>     name-resolving logic client-side?
>
> Telling people to hardcode specific DNS server IP addresses in their
> code, bypassing network-level DNS configurations like DHCP, gives me the

Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on 
TURN server config. You're already doing so implicitly in your proposal. 
So reserve a well-known address that will get translated into the actual 
DNS server's address by the TURN server, according to its configuration. 
That well-known address would be special signalling meaning "whatever's 
at the top of the TURN server's /etc/resolv.conf". ;)

Simon

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 5 Mar 2015 17:17:47 -0500

> that's gonna fly, but at least it won't appear like you overlooked the

OK, done.
(
https://github.com/bemasc/ietf-drafts/commit/642f7281ed25272b86fd37bbe310432bc9a75f54
)

>>     the connection initiation phase only, then go back to addresses and
I forgot to mention: When contacting a DNS ICE candidate, this strategy
would result in superfluous peer-reflexive candidates, to represent the IP
address of the remote peer.  If you want to avoid making extra prflx
candidates, then you have to keep everything tied to the DNS name.

> Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on TURN
> server config. You're already doing so implicitly in your proposal. So
> reserve a well-known address that will get translated into the actual DNS
> server's address by the TURN server, according to its configuration. That
> well-known address would be special signalling meaning "whatever's at the
> top of the TURN server's /etc/resolv.conf". ;)

Who's twisted here?

And if that server is unavailable, requiring fallback to the next entry in
resolv.conf?

Also, I'm pretty sure any strategy like this would require the client to
include a complete DNS client implementation. That seems pretty
unfortunate, when we have options that don't require the client or server
to do that.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2015 17:52:23 -0500

Le 2015-03-05 17:17, Benjamin Schwartz a écrit :
>         8.8.8.8:53 <http://8.8.8.8:53> <http://8.8.8.8:53>, for example,
>         and keep all the
>     Ok, here's a small tweak. Instead of hardcoding a DNS server, rely
>     on TURN server config. You're already doing so implicitly in your
>     proposal. So reserve a well-known address that will get translated
>     into the actual DNS server's address by the TURN server, according
>     to its configuration. That well-known address would be special
>     signalling meaning "whatever's at the top of the TURN server's
>     /etc/resolv.conf". ;)
>
>
> Who's twisted here?

:D

> And if that server is unavailable, requiring fallback to the next entry
> in resolv.conf?

Then fallback on the second well-known address which you will have 
defined for that very purpose. ;)

> unfortunate, when we have options that don't require the client or
> server to do that.

True.

A DNS client implementation is of course already present underneath 
getaddrinfo(). If there's no lower-layer API that grants you access to 
it, and you can't just create one, you can fake it by positioning 
yourself as a generic UDP proxy. Just bind a UDP port on the loopback 
interface and use the lower-layer DNS functions already available to you 
(e.g., <resolv.h> with glibc) to send DNS requests to yourself, then 
proxy that over TURN to the TURN server's DNS resolver using the 
well-known address as destination.

:)

Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 5 Mar 2015 15:43:13 -0800

> abstraction would apply perfectly to TURN-TCP. For UDP it's much more

This distinction seems artificial to me. If I want to establish a channel
to foo.com, why does it matter if it's over UDP or TCP?

The ability for the client to behave identically regardless of whether the
remote destination is an IP or hostname is a nice simplification of the
client, and very much in the spirit of the proxy doing work on behalf of
the client.

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

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 6 Mar 2015 19:51:17 +0000

On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz <[email-masked]> wrote:

> Hi TRAM,
> 
> I've just written up a proposal for an optional extension to TURN that would add support for DNS names.  I'd like to discuss this at the upcoming meeting.
> 

What happens if DNS resolution is slow?  As far as I can tell the TURN server can’t respond to the ChannelBind or CreatePermission request until DNS completes (or fails), and I vaguely think (though I don’t remember exact numbers) that STUN transactions will time out faster than DNS ones will.

The draft should also discuss its operation with TURN-TCP.  As far as I can tell it’s straightforward, and easier than TURN-UDP, but it’s worth discussing it.

---

From: Benjamin Schwartz <[email-masked]>
Date: Fri, 6 Mar 2015 15:53:08 -0500

On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox <[email-masked]> wrote:

> What happens if DNS resolution is slow?  As far as I can tell the TURN
> server can’t respond to the ChannelBind or CreatePermission request until
> DNS completes (or fails), and I vaguely think (though I don’t remember
> exact numbers) that STUN transactions will time out faster than DNS ones
> will.
>

You're right; if the client sends a DNS-name CreatePermission or
ChannelBind, the server can't send a success reply until DNS completes
successfully.  However, I don't share your intuition.  I'm not familiar
with DNS timeouts, but for example, this page [
http://support.microsoft.com/kb/2834226] claims that Microsoft's DNS
resolution times out after 10 seconds.  I'm not aware of any official,
standardized STUN timeout that applies before the first packet has been
received, but in practice implementations seem to allow for at least 30
seconds of delay after signaling is complete.

> The draft should also discuss its operation with TURN-TCP.  As far as I
> can tell it’s straightforward, and easier than TURN-UDP, but it’s worth
> discussing it.

I agree that the extension to TURN-TCP is straightforward, but I'd like to
see if we have rough consensus on this approach for UDP first.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Mar 2015 14:08:13 -0800

> seconds of delay after signaling is complete.

The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 defines
the STUN timeouts. As in, if the client sends channel-bind and gets no
response, it will retransmit several times before giving up, at defined
intervals. Typically this is 5-10 seconds, but it depends on RTO; for a <
50 ms RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout.

Typically I think this case will be encountered when the hostname is
invalid; in these cases, the permission/bind will simply be treated as an
error by the client, and that particular candidate pair will fail, with no
impact on other pairs.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 06 Mar 2015 17:25:24 -0500

Le 2015-03-06 17:08, Justin Uberti a écrit :
>         What happens if DNS resolution is slow?  As far as I can tell
>         the TURN server can’t respond to the ChannelBind or
>         CreatePermission request until DNS completes (or fails), and I
>         vaguely think (though I don’t remember exact numbers) that STUN
>         transactions will time out faster than DNS ones will.
>
>
>     ChannelBind, the server can't send a success reply until DNS
>     completes successfully.  However, I don't share your intuition.  I'm
>     not familiar with DNS timeouts, but for example, this page
>     [http://support.microsoft.com/kb/2834226] claims that Microsoft's
>     DNS resolution times out after 10 seconds.  I'm not aware of any
>     official, standardized STUN timeout that applies before the first
>     packet has been received, but in practice implementations seem to
>     allow for at least 30 seconds of delay after signaling is complete.
>
>
> The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1
> defines the STUN timeouts. As in, if the client sends channel-bind and
> gets no response, it will retransmit several times before giving up, at
> defined intervals. Typically this is 5-10 seconds, but it depends on
> RTO; for a < 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the
> DNS timeout.
>
> invalid; in these cases, the permission/bind will simply be treated as
> an error by the client, and that particular candidate pair will fail,
> with no impact on other pairs.

I too don't see this as problematic. I think it would be enough to say 
that timeout = min(STUN timeout, DNS timeout), and leave it at that.

Simon

---

From: Benjamin Schwartz <[email-masked]>
Date: Fri, 6 Mar 2015 17:30:06 -0500

I don't understand.  Why would these STUN timeouts apply before permission
is granted, or before the channel is bound?  It seems to me that these
timeouts refer to timers that start when you make the first outbound
request to a remote candidate, which is always after the success response
to CreatePermission or ChannelBind.

On Fri, Mar 6, 2015 at 5:08 PM, Justin Uberti <[email-masked]> wrote:

> defines the STUN timeouts. As in, if the client sends channel-bind and gets
> no response, it will retransmit several times before giving up, at defined
>> I agree that the extension to TURN-TCP is straightforward, but I'd like
>> to see if we have rough consensus on this approach for UDP first.
>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Mar 2015 16:32:24 -0800

These are the timeouts for the TURN interaction, not the ICE checks. It's
over UDP, so the client has to do its own retry semantics, which means
retransmission of the CreatePermission/ChannelBind.

If the server doesn't respond for 15 seconds, the client may think the
network or server has died.

On Fri, Mar 6, 2015 at 2:30 PM, Benjamin Schwartz <[email-masked]> wrote:

>>>> > I've just written up a proposal for an optional extension to TURN
>>>> that would add support for DNS names.  I'd like to discuss this at the
>>>> upcoming meeting.
>>>> >

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Mar 2015 16:34:46 -0800

> that timeout = min(STUN timeout, DNS timeout), and leave it at that.

The problem is that the STUN timeout is on the client, whereas the DNS
timeout is on the server, so the client needs to somehow be aware of the
DNS timeout in its STUN calculations.

Generally I think that we could just say that if DNS doesn't respond in X
seconds (e.g. 5), the server MUST consider the lookup to have failed and
return a 4YY error code.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 7 Mar 2015 02:44:39 +0000

The work in DPRIVE WG (http://tools.ietf.org/html/draft-hzhwm-dprive-start-tls-for-dns-01) can also help address the problem discussed in this draft when the client uses DNS-over-TLS and contacts both the DNS servers on the local network and on the Internet (OpenDNS, Google etc.).

It will be good to compare the mechanism in this draft with the work going on in the above WG.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Benjamin Schwartz
Sent: Friday, March 06, 2015 1:48 AM
To: [email-masked]
Subject: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt

Hi TRAM,

Thanks,
Ben

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Mar 5, 2015 at 3:15 PM
Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>, "Benjamin M. Schwartz" <[email-masked]<mailto:[email-masked]>>

Name:           draft-schwartz-tram-turnbyname
Revision:       00
Title:          TURN by name: an extension to TURN for contacting an endpoint by its DNS name.
Document date:  2015-03-05
Group:          Individual Submission
Pages:          15
URL:            http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt
Status:         https://datatracker.ietf.org/doc/draft-schwartz-tram-turnbyname/
Htmlized:       http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 7 Mar 2015 03:00:10 +0000

On some restricted networks, DNS access is also restricted, which may
prevent users from determining the IP address of a domain (e.g. an
application-specified TURN server, for RETURN
[I-D.schwartz-rtcweb-return<http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00#ref-I-D.schwartz-rtcweb-return>], or an ICE candidate that contains a
domain name) that they wish to contact through the escape-hatch TURN
server.

Comment> FW in such restricted network may use various mechanisms like function as HTTPS proxy, protocol identification of encrypted content via statistical analysis to identify and block applications etc.
How will this technique work in such restricted networks ?

-Tiru

Hi TRAM,

Thanks,
Ben

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Mar 5, 2015 at 3:15 PM
Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>, "Benjamin M. Schwartz" <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Mar 2015 08:10:19 -0400

> DNS timeout in its STUN calculations.

Why? From the client's point of view, the server is just taking longer 
than usual to process the request.

> Generally I think that we could just say that if DNS doesn't respond in
> X seconds (e.g. 5), the server MUST consider the lookup to have failed
> and return a 4YY error code.

Why?

Simon

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 9 Mar 2015 08:22:41 -0400

> network or server has died.

Could we resolve this by recommending that clients use STUN binding
requests as a heartbeat?

>> I don't understand.  Why would these STUN timeouts apply before
>> permission is granted, or before the channel is bound?  It seems to me that
>> these timeouts refer to timers that start when you make the first outbound
>>>>> The draft should also discuss its operation with TURN-TCP.  As far as
>>>>> I can tell it’s straightforward, and easier than TURN-UDP, but it’s worth
>>>>> discussing it.
>>>>
>>>>

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 9 Mar 2015 08:33:12 -0400

Thanks for the TLS for DNS reference.  I wasn't aware of that work.

I think these efforts are complementary.  TLS for DNS improves the privacy
of connections to a cooperative, correctly functioning DNS server.  TURN by
name helps the user to perform name lookups when their DNS server is
unavailable, uncooperative, or restricted.

On Fri, Mar 6, 2015 at 9:44 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>   *From:* tram [mailto:[email-masked]] *On Behalf Of *Benjamin
> Schwartz
> *Sent:* Friday, March 06, 2015 1:48 AM
> *To:* [email-masked]
> *Subject:* [tram] Fwd: New Version Notification for
> draft-schwartz-tram-turnbyname-00.txt
>
>
>
> Hi TRAM,
>
>
>
> Htmlized:
> http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00
>
>
> Abstract:

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 9 Mar 2015 09:51:42 -0400

On Fri, Mar 6, 2015 at 10:00 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> [I-D.schwartz-rtcweb-return
> <http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00#ref-I-D.schwartz-rtcweb-return>],
> or an ICE candidate that contains a
>
> Comment> FW in such restricted network may use various mechanisms like
> function as HTTPS proxy, protocol identification of encrypted content via
> statistical analysis to identify and block applications etc.
>

When I describe "escape hatches" in restricted networks, I am principally
referring to situations where the network administrator (who is applying
the restrictions) also deliberately creates such an escape hatch, which is
only available to certain authorized users.  "TURN by name" allows the
network administrator to enable these users to access the whole public
network, on networks where unauthorized users have restricted DNS access.

More broadly, "TURN by name" parallels SOCKS-5 or HTTP CONNECT proxies for
UDP applications (such as WebRTC), so I expect it can be used to extend
most proxy systems to support WebRTC.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 Mar 2015 13:59:10 +0000

On Mar 9, 2015, at 8:10 AM, Simon Perreault <[email-masked]> wrote:

> Why? From the client's point of view, the server is just taking longer than usual to process the request.
> 

According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bis draft), over unreliable channels, a STUN client will consider a transaction to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.e. 79*RTT for the default values of Rc (7) and Rm (16).  For short RTTs (between the client and the TURN server) that’ll likely be shorter than the DNS timeout.

We could tweak Rc and/or Rm for requests that cause the server to do a DNS lookup, but it seems rather like a layer violation.

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 9 Mar 2015 10:32:05 -0400

Ah, so the STUN spec is not designed to carry any message whose response
waits for external communication.  Hmm.

I think we need a mechanism to report DNS resolution failures, and the
client needs to wait for success before attempting to send messages.
 (Otherwise they would have to be queued or dropped on the server for up to
~10 seconds while waiting for DNS resolution to complete.)

To me, it seems like the easiest solution would be to document an exception
for slow transactions.  However, if that seems unappealing, what do you
think about a sequence like:
C->S: Request
S->C (immediately): Error Response, with an attribute indicating "pending"
S->C (later): Success (or Error) Indication, with identifying attributes
(XOR-PEER-ADDRESS or CHANNEL-NUMBER)

On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox <[email-masked]> wrote:

> According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the
> stun-bis draft), over unreliable channels, a STUN client will consider a
> transaction to have failed if it gets no response after
> (2^(Rc-1)-1+Rm)*RTT, i.e. 79*RTT for the default values of Rc (7) and Rm
> (16).  For short RTTs (between the client and the TURN server) that’ll
> likely be shorter than the DNS timeout.
>
> We could tweak Rc and/or Rm for requests that cause the server to do a DNS
> lookup, but it seems rather like a layer violation.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 Mar 2015 14:59:52 +0000

On Mar 9, 2015, at 10:32 AM, Benjamin Schwartz <[email-masked]<mailto:[email-masked]>> wrote:

Ah, so the STUN spec is not designed to carry any message whose response waits for external communication.  Hmm.

I think we need a mechanism to report DNS resolution failures, and the client needs to wait for success before attempting to send messages.  (Otherwise they would have to be queued or dropped on the server for up to ~10 seconds while waiting for DNS resolution to complete.)

To me, it seems like the easiest solution would be to document an exception for slow transactions.  However, if that seems unappealing, what do you think about a sequence like:
C->S: Request
S->C (immediately): Error Response, with an attribute indicating "pending"
S->C (later): Success (or Error) Indication, with identifying attributes (XOR-PEER-ADDRESS or CHANNEL-NUMBER)

I’d do it slightly differently — have the first S->C be a success response (but still with the “pending” attribute), and have the second S->C be a Request, not an Indication.  (You want reliability here, since the message can be lost.)

To be sure, this would be the first S->C Request in TURN, and if we went this way it’d require some thought to make sure we understood properly how authentication should work.

On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Mar 2015 15:02:36 +0000

Inline [TR]

From: Benjamin Schwartz [mailto:[email-masked]]
Sent: Monday, March 09, 2015 7:22 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt

On Fri, Mar 6, 2015 at 10:00 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

When I describe "escape hatches" in restricted networks, I am principally referring to situations where the network administrator (who is applying the restrictions) also deliberately creates such an escape hatch, which is only available to certain authorized users.  "TURN by name" allows the network administrator to enable these users to access the whole public network, on networks where unauthorized users have restricted DNS access.

[TR] Security devices solve this problem by enforcing identity-based policies.

-Tiru

More broadly, "TURN by name" parallels SOCKS-5 or HTTP CONNECT proxies for UDP applications (such as WebRTC), so I expect it can be used to extend most proxy systems to support WebRTC.

-Tiru

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Benjamin Schwartz
Sent: Friday, March 06, 2015 1:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt

Hi TRAM,

Thanks,
Ben

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Mar 5, 2015 at 3:15 PM
Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>, "Benjamin M. Schwartz" <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 9 Mar 2015 11:38:30 -0400

Rather than introducing the first ever S->C STUN Request, what if the
"pending" attribute indicates a timeout, i.e. result-indication guaranteed
in this many seconds.  If there's no response by then, the packet must have
been dropped, and the client should retry.

It's slower than a reliable request/response if the indication is lost, but
it's a lot simpler.

On Mon, Mar 9, 2015 at 10:59 AM, Jonathan Lennox <[email-masked]> wrote:

>
>  On Mar 9, 2015, at 10:32 AM, Benjamin Schwartz <[email-masked]> wrote:
>
>  To me, it seems like the easiest solution would be to document an
> exception for slow transactions.  However, if that seems unappealing, what
> do you think about a sequence like:
> C->S: Request
>  I’d do it slightly differently — have the first S->C be a success
> response (but still with the “pending” attribute), and have the second S->C
> be a Request, not an Indication.  (You want reliability here, since the
> message can be lost.)
>
>  To be sure, this would be the first S->C Request in TURN, and if we went
> this way it’d require some thought to make sure we understood properly how
> authentication should work.
>
>> We could tweak Rc and/or Rm for requests that cause the server to do a
>> DNS lookup, but it seems rather like a layer violation.
>
>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Mar 2015 13:25:52 -0400

> According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bis draft), over unreliable channels, a STUN client will consider a transaction to have failed if it gets no response after…

So what? Why does DNS timeout need to be shorter than STUN timeout?

Simon

---

From: Benjamin Schwartz <[email-masked]>
Date: Tue, 17 Mar 2015 16:30:08 -0400

Looks like this didn't get a response.

Suppose that the RTT to the TURN server is very low.  Then the client will
assume the request has failed if it doesn't get a response quickly.
Therefore, the client will not be able to connect to names that are even a
little bit slow to resolve.  In the extreme case (RTT near zero),
connection to DNS servers won't work at all.

Therefore, we should prefer a design that allows the effective timeout to
be independent of RTT.  That could work by just specifying a minimum
timeout for this request-response, or it could work by choosing a design
that uses a different sequence of messages.

On Mon, Mar 9, 2015 at 1:25 PM, Simon Perreault <[email-masked]> wrote:

> >> > Why? From the client's point of view, the server is just taking
> longer than usual to process the request.
> >> >

---

From: Simon Perreault <[email-masked]>
Date: Tue, 17 Mar 2015 16:58:40 -0400

> Looks like this didn't get a response.

Thanks *a lot* for responding!

> Suppose that the RTT to the TURN server is very low.  Then the client
> will assume the request has failed if it doesn't get a response
> quickly.  Therefore, the client will not be able to connect to names
> that are even a little bit slow to resolve.  In the extreme case (RTT
> near zero), connection to DNS servers won't work at all.

Understood!

> Therefore, we should prefer a design that allows the effective timeout
> to be independent of RTT.  That could work by just specifying a minimum

Makes total sense!

Thanks again,
Simon

---

From: Justin Uberti <[email-masked]>
Date: Tue, 17 Mar 2015 16:59:36 -0700

> > that uses a different sequence of messages.

I wonder if returning some sort of 3xx code "operation pending" would work
here; the client would retry the request after some defined or supplied
interval (which would then be cached at the server and could be returned
instantly).