[tram] Points that should be clarified in STUN-bis and TURN-bis

Jonathan Lennox <jonathan@vidyo.com> Fri, 07 February 2014 19:39 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D51A0274 for <tram@ietfa.amsl.com>; Fri, 7 Feb 2014 11:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtUZhCl7jlBW for <tram@ietfa.amsl.com>; Fri, 7 Feb 2014 11:39:20 -0800 (PST)
Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA271A018C for <tram@ietf.org>; Fri, 7 Feb 2014 11:39:20 -0800 (PST)
X-Note-AR-ScanTimeLocal: 2/7/2014 2:39:19 PM
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-76/SG:2 2/7/2014 2:38:39 PM
X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.83967 p=-0.968181 Source White
X-Signature-Violations: 0-0-0-7136-c
X-Note-419: 31.201 ms. Fail:0 Chk:1345 of 1345 total
X-Note: SCH-CT/SI:0-1345/SG:1 2/7/2014 2:39:10 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->LOCAL
X-Note-Sending-IP: 162.209.16.214
X-Note-Reverse-DNS:
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 96119944 for tram@ietf.org; Fri, 07 Feb 2014 14:39:18 -0500
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Fri, 7 Feb 2014 13:39:17 -0600
From: Jonathan Lennox <jonathan@vidyo.com>
To: "tram@ietf.org" <tram@ietf.org>
Thread-Topic: Points that should be clarified in STUN-bis and TURN-bis
Thread-Index: AQHPJDxJGQ3sy9nOWEKxY05M7kNz7A==
Date: Fri, 07 Feb 2014 19:39:16 +0000
Message-ID: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6777D8DC999A9949A5593E122BC83F1E@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [tram] Points that should be clarified in STUN-bis and TURN-bis
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 19:39:22 -0000

I'm in the middle of doing a TURN client implementation from scratch, which gives me the opportunity to note several items that I think should be clarified as TRAM works on STUN-bis and TURN-bis.

Some of these are statements, based on what I think are obvious conclusions about how the protocols should behave; some are questions.  Answers, or disagreement, are welcome for any or all of them.

I haven't cleanly separated STUN and TURN issues here.

Questions:

1. If a STUN (TURN) client receives a "300 Try Alternate" response to a STUN request sent over TLS, it should then connect to a different STUN server over TLS.  What subjectAltName should it expect in the redirected-to server's certificate?

2. What behavior is expected if a TURN ALLOCATE request does not contain a REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute?  Is the server expected to allocate an IPv4 address (since RFC 5766 explicitly says it only discusses IPv4 addresses), or is it at the server's discretion?

3. What should a TURN server's behavior be if it receives a CreatePermission request with multiple XOR-PEER-ATTRIBUTE addresses, and some (but not all) of the addresses are administratively forbidden?  Should it create or refresh permissions for the subset of the destinations that are allowed, despite sending a 403 Forbidden response, or should its operation be atomic (meaning if any are rejected, none are refreshed)?

3a. Relatedly: do we want to add an informational CreatePermission response attribute listing which addresses were forbidden?

4. How should TURN channel de-framing be done if a TURN entity receives a message with a channel ID in the reserved range (0x8000 - 0xffff) over TCP or TLS?  The size of the frame differs depending on whether the message is a TURN message (length+20) or a ChannelData message (length+4, rounded up to a multiple of 4).  There's no obvious reason to expect any particular length formula for items in the reserved range, unless we specify one preemptively.  However, the spec says that an implementation MUST NOT assume that a TURN message always starts with a 0 bit.


Statements:

1. Since all TURN requests must be authenticated, any TURN request can receive a 401 or 438 response, which should be handled in the same manner as described in the TURN spec for the Allocate request.  (401 would normally only happen when the credentials provisioned for the user are changed.)

2. The REQUESTED-ADDRESS-FAMILY attribute (RFC 6156) may be used for TURN/TCP allocations (RFC 6062), if a TURN server supports both mechanisms. (Neither of these documents normatively cites the other, though RFC 6156 notes that TURN can be used to request address/port pairs for receiving TCP.)

3. Nonces are independent for different STUN servers.  STUN clients using long-term credentials should normally expect to receive a 438 Stale Nonce response to the request they send after a 300 Try Alternate redirection, unless they've previously been redirected to that address and already know a nonce to use.