Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 11:26:21 -0500

On Sat, 26-Jan-08, at 18:29 , Eric Rescorla wrote:

> $Id: draft-ietf-behave-turn-06-rev.txt,v 1.1 2008/01/26 23:08:30  
> ekr Exp $
>
>
> TECHNICAL
> S 4.
> The ALTERNATE-SERVER stuff seems problematic for the reasons
> Cullen indicates. If you're overloaded, better ot simply not
> handle the request and let ordinary H-A methods take over.

I have simplified the ALTERNATE-SERVER stuff in TURN-07, but left it  
in for now.  See my e-mail of a week ago on the subject.  However, I  
have no strong attachment to it, and left it in only because I  
thought there were some who still wanted it. It is listed as one of  
the (currently 2) open issues remaining in the document.

>
>
> S 5.1.1.
>    If the response is an error response and contains a 442, 443 or 444
>    error code, the client knows that its requested properties could  
> not
>    be met.  The client MAY retry with different properties, with the
>    same properties (in a hope that something has changed on the  
> server),
>    or give up, depending on the needs of the application.  However, if
>    the client retries, it SHOULD wait 500ms, and if the request fails
>    again, wait 1 second, then 2 seconds, and so on, exponentially
>    backing off.
>
> I don't see the purpose of this. This kind of backoff is gnenerally
> used for congestion control, but if you're getitng errors you know
> that the packets weren't lost, so why back off?

I have made major changes in this area to try to bring some clarity  
to the various ways a client can try to recover from an Allocate  
error response. The text currently says that a client must wait at  
least one minute before retrying the request (except for a 442, which  
is not likely to change). In the meantime, the client can try a  
different server.

>
> S 5.1.2.
> This 3/4 guidance seems like it's inappropriate in a number of
> respects. Why not simply indicate that clients need to leave
> some time for the refresh.
>
> The idea of refreshing with different bandwidth requested
> seems problematic. What happens if the server refuses? Do you
> need to refresh again with a lower bandwidth if you're willing
> to live with that? A policy that refreshes didn't change anything
> seems more sensible.

I have changed the default allocation lifetime to 10 minutes, which  
the client can increase but not decrease. So the current text  
recommends refreshing the allocation 1 minute before it expires.

You can still change the bandwidth on a refresh. If the client asks  
for less bandwidth, the bandwidth goes down. If the client asks for  
more bandwidth, the server tries to accommodate. If the bandwidth is  
currently 10 and the clients asks for 20 but the server can only do  
15, then the bandwidth is set to 15. Even if the bandwidth cannot be  
increased at all, the request still succeeds.

Having said this, bandwidth is still the biggest open issue in the  
document. I haven't had the time to focus on it, so I just wrote  
something that was vaguely reasonable while I fixed the rest of the  
document. I expect to have extensive discussions on bandwidth once  
TURN-07 gets out.

>
> S 5.2.1.
>    o  If the transport protocol is UDP, and the transaction id in the
>       request message matches the transaction id used for the original
>       allocation, then the server treats this as a retransmission  
> of the
>       original request, and replies with the same response as it  
> did to
>       the original request.  The server may do this by either storing
>       its original response and resending it, or by rebuilding its
>       original response from other state data.
>
> This is a new requirement that's not in STUN (The stun reqt is 10
> seconds) and seems impractical to implement. If I throw an error on a
> transaction, how long do I need to be willing to return the same
> error? Forever?  What seems appropriate here is that as long as an
> allocation exists (And maybe for X seconds afterward) you need
> to return the same response.

We discussed this on the conf call. We will weaken the STUN  
requirement to make the above implementation ok.
And I don't see your point about an error: we are talking about a  
retransmission of the Allocate request here. If the first copy  
generated an error, then the allocation would not be created and the  
above mechanism does not come into play. So the first copy must have  
succeeded, and the problem is only that the success response got lost.

>
>
> S 5.2.1.1.
>    If it does, the server attempts to allocate a transport address for
>    the client.  The Allocate Request can contain several additional
>    attributes that allow the client to request specific  
> characteristics
>    of the transport address.  If it doesn't, it sends an error  
> response.
>
> What error?

This section has been totally rewritten. Cullen's proposal is now  
used, and appropriate error responses are specified.

>
>
> S 5.2.1.4.
> So, I get that you would want an even port for RTP and consecutive
> ports for RTP/RTCP, but are there any implementations which
> need arbitrary odd ports?

As per our conf call, odd ports can no longer be requested.

>
>
> S 6.3.
> This section contains way too much information about the UDP datagram
> (Length, Checksum...)  It should simply specify that a UDP datagram
> with the following contents is sent to the following location as per
> standard procedure.

I have left this for now. Much of this detail was in previous  
versions of TURN, abeit in different words in a different part of the  
text.

>
>
> S 7.7.
>    When the server receives a valid ChannelData message, it forms a  
> UDP
>    datagram as follows: the source transport address is the relayed
>    transport address of the allocation, where the allocation is
>    determined by the 5-tuple on which the ChannelData message arrived;
>    the destination transport address is the peer address to which the
>    channel is bound; the data following the UDP header is the contents
>    of the data field of the ChannelData message; the Length field  
> in the
>    UDP header is set to the Length field of the ChannelData message  
> + 8;
>    and the Checksum field in the UDP header is computed as  
> described in
>
>
> Again, too much information about the UDP header..

See comment above.

>
>
> EDITORIAL
> Abstract:
> Is TURN really "more properly" used as part of ICE?

The idea is that you should really be using TURN with ICE. Can you  
suggest alternate text that expresses this?

>
> S 1.
>    The only way to obtain a UDP transport address that can be used for
>    corresponding with a peer through such a NAT is to make use of a
>    relay.
>
> Well, actually, the only reliable way. You mgiht guess correctly.

OK. I added "reliable".

>
> S 2.5.
>    the client can determine the peer that send the UDP datagram.
>
> s/send/sends/

This text is not in TURN-07.

>
> S 4.
>    After the initial Allocate transaction, all subsequent TURN
>    transactions need to be sent in the context of a valid allocation.
>    The source and destination IP address and ports for these TURN
>    messages MUST match the those used in the initial Allocate Request.
>
> I'm not sure what "in the context means". The seconds sentence seems
> clearer.

TURN-07 spells out the rules around this in greater detail.

>
>
> S 5.2.1.7.
> This section would be imroved by having the required attributes being
> a bulleted list.

This section has been completely rewritten. Lists are used to  
describe both the checks that need to be done, and the attribute that  
must be included in the response.

>
> S 6.
> Merging send and data indications (which are basically unrelated) into
> a single section is really confusing. It would be better to give them
> separate sections.

This section was rewritten to try to make client and server behavior  
clearer. Send and Data indications are now described separately.

>
> There should be some explicit statement of what missing DATA  
> attributes
> are for (keepalives).

There is now an explicit statement.

>
> S 7.
>    As described in the overview, channel mechanism provides a way  
> for a
>    client and server to send application data using ChannelData
>
> s/channel mechanism/the channel mechanism/

I have rewritten this section to try to clarify how things work. This  
sentence vanished in the rewrite.
>
>
> S 7.1.
>
>    Over UDP, the client SHOULD NOT send ChannelData messages on the
>    channel until it has received a ChannelBind Success Response for  
> the
>    binding attempt.  Sending them before the success response is
>    received risks having them dropped by the server if he ChannelBind
>    Request was lost.
>
> I think we discussed this onlist.

This text was moved up one level and rewritten. It now says:

    In the other direction, the client MAY elect to send ChannelData
    messages before receiving the ChannelBind success response.  Doing
    so, however, runs the risk of having the ChannelData messages  
dropped
    by the server if the ChannelBind request does not succeed for some
    reason (e.g., packet lost if the request is sent over UDP, or the
    server being unable to fulfill the request).  A client that  
wishes to
    be safe should either queue the data, or use Send indications until
    the channel binding is confirmed.

I think this captures what we agreed to on the conference call.

>
>
>
> S 11.
>    discovery.  As a consequence, TURN runs on a separate port from  
> STUN.
>    The client discovers the address and port of the TURN server using
>    the same DNS procedures defined in [I-D.ietf-behave-rfc3489bis],  
> but
>    using an SRV service name of "turn" (or "turns" for TURN over TLS)
>
> Didn't we get rid of separate ports?

By default, TURN now runs on the same port as STUN. This can be  
changed using the SRV procedures, or using ALTERNATE-SERVER.

>
>
> S 12.
>    TURN cannot be used by clients for subverting firewall policies.
>
> This is untrue, as acknowledged in the section on using TLS.

I think this is mostly true, which is why we have all the  
restrictions on how TURN can be used.
Do you have a proposed replacement for this sentence?

> -Ekr

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Feb 2008 08:42:18 -0800

At Wed, 20 Feb 2008 11:26:21 -0500,
> the (currently 2) open issues remaining in the document.

Can those who are in favor of this speak up?

> is not likely to change). In the meantime, the client can try a  

Again, I'd like to understand why you need to wait at all?

> versions of TURN, abeit in different words in a different part of the  

Sure, so I should have caught it before, but that doesn't make it
more right.

> suggest alternate text that expresses this?

I don't see why we should be expressing this sentiment at all.

> Do you have a proposed replacement for this sentence?

"TURN attempts to adhere as closely as possible to common
firewall policies, consistent with allowing data to flow.
For instance, TURN cannot be used to implement an ordinary
server such as a a Web or SMTP server."

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 13:47:14 -0500

> Can those who are in favor of this speak up?

Yes. Please do.
(See my separate e-mail to the mailing list about this)

> Again, I'd like to understand why you need to wait at all?

Say the server has run out of ports, and has just rejected allocation  
requests from 20 clients. Do you really think they should immediately  
retry? The chance of something having changed is small, and I am  
worried about what looks like an inadvertent DoS attack.

> Sure, so I should have caught it before, but that doesn't make it

OK. OK! You and Cullen sound like a tag team. ;-)

I have removed the last two bullets (that describe how the length and  
the checksum are computed). See my reply to Cullen for the details.

> I don't see why we should be expressing this sentiment at all.

Because TURN is an inefficient solution with certain deficiencies,  
and is thus best reserved for cases where a direct connection cannot  
be established.

> server such as a a Web or SMTP server."

OK. I changed the text to read as follows:

    TURN attempts to adhere as closely as possible to common firewall
    policies, consistent with allowing data to flow.  TURN has fairly
    limited applicability, requiring a user to explicitly authorize
    permission to receive data from a peer, one IP address at a time.
    Thus, it does not provide a general technique for externalizing
    sockets.  Rather, it has similar security properties to the  
placement
    of an address-restricted NAT in the network, allowing messaging in
    from a peer only if the internal client has sent a packet out  
towards
    the IP address of that peer.  This limitation means that TURN cannot
    be used to run web servers, email servers, SIP servers, or other
    network servers that service a large number of clients.  Rather, it
    facilitates rendezvous of NATted clients that use some other
    protocol, such as SIP, to communicate IP addresses and ports for
    communications.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Feb 2008 10:57:31 -0800

At Wed, 20 Feb 2008 13:47:14 -0500,
> worried about what looks like an inadvertent DoS attack.

Fair enough, but what if your credentials didn't work cause
you mistyped your password?

> and is thus best reserved for cases where a direct connection cannot  

Fair enough, but there might be other ways to know this besides
ICE.

>     protocol, such as SIP, to communicate IP addresses and ports for
Looks good.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 14:24:49 -0500

> you mistyped your password?

This is a 401 error. The text currently says:
    o  401 (Unauthorized): If the client has followed the procedures of
       the Long-Term Credential mechanism and still gets this error,  
then
       the server is not accepting the client's credentials.  The client
       SHOULD notify the user or operator and SHOULD NOT send any  
further
       requests to this server until it believes the problem has been
       fixed.  The client MAY try a different server.

The stuff about waiting at least one minute only applies to errors  
where the server effectively says "I cannot satisfy this request  
right now for capacity reasons, but you are welcome to try again later".

As I said, I completely rewrote all the text on handling Allocate  
errors yesterday because I felt there was a mis-mash of text on how  
they should be handled. In the process, I made a number of changes,  
and it is likely that I got some stuff wrong. How about we pause this  
topic for now until you read the TURN-07? I am just waiting for  
Jonathan's and Rohan's comments before publishing TURN-07 (as co- 
authors, they get first peek, sorry! :-).

> Fair enough, but there might be other ways to know this besides

Perhaps. But I still feel that TURN is best viewed as a part of the  
overall ICE solution and I would like to say this somehow in the  
abstract. The STUN (rfc3489bis) abstract has similar words.

>>     protocol, such as SIP, to communicate IP addresses and ports for

Great! Thanks for the text.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Feb 2008 11:47:44 -0800

At Wed, 20 Feb 2008 14:24:49 -0500,
> authors, they get first peek, sorry! :-).

No problem.

> abstract. The STUN (rfc3489bis) abstract has similar words.

Can't say I'm any happier with it there...

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Feb 2008 12:21:29 -0800

>     network servers that service a large number of clients.  

TURN can't listen for incoming TCP connections at all, so referencing web
(HTTP) or email (SMTP/IMAP/POP) servers, which all use TCP, doesn't make
sense.  TURN-TCP could potentially do that, but I expect we will castrate
TURN-TCP in a similar manner to prevent such use.  You might also want to
explicitly point out, in this same paragraph, that TURN can only establish UDP
connections to remote peers.

Please reduce the reference to UDP servers, and use "e.g.".  A reasonable list
of interesting UDP servers might be NTP, SIP, and TFTP.  

-d

> Rather, it

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 15:58:59 -0500

> of interesting UDP servers might be NTP, SIP, and TFTP.

Done.

(Confession time: I didn't even look at the security considerations  
section until now, so it might well be out-of-date from all the  
changes that have been made recently to TURN.)

- Philip