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

Jonathan Lennox <jonathan@vidyo.com> Mon, 10 February 2014 16:19 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 4CED21A086D for <tram@ietfa.amsl.com>; Mon, 10 Feb 2014 08:19:19 -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 0TJvWLkadxvS for <tram@ietfa.amsl.com>; Mon, 10 Feb 2014 08:19:17 -0800 (PST)
Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id E3DAC1A06F6 for <tram@ietf.org>; Mon, 10 Feb 2014 08:19:16 -0800 (PST)
X-Note-AR-ScanTimeLocal: 2/10/2014 11:19:14 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
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-126/SG:2 2/10/2014 11:18:26 AM
X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.76028 p=-0.97375 Source White
X-Signature-Violations: 0-0-0-11844-c
X-Note-419: 31.2006 ms. Fail:0 Chk:1345 of 1345 total
X-Note: SCH-CT/SI:0-1345/SG:1 2/10/2014 11:19:02 AM
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.8) with ESMTPS id 70826734; Mon, 10 Feb 2014 11:19:14 -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; Mon, 10 Feb 2014 10:19:13 -0600
From: Jonathan Lennox <jonathan@vidyo.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [tram] Points that should be clarified in STUN-bis and TURN-bis
Thread-Index: AQHPJgoGGQ3sy9nOWEKxY05M7kNz7JqvEDGA
Date: Mon, 10 Feb 2014 16:19:12 +0000
Message-ID: <DA35AC5F-2D24-4810-B83A-C9B2D4BFEC47@vidyo.com>
References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <CALDtMr+qgdnT5i4fiJidufGZF1CPR=puAZ+Ldqnp5t=At0AS-g@mail.gmail.com> <52F54CDC.1040502@viagenie.ca> <CALDtMrJ4J78t4PboxN5O3ZPMmt243zZ2YV5LBv-Nhz1k3E7LyQ@mail.gmail.com> <52F5550D.3020203@viagenie.ca> <CALDtMrLdxC8Vdge-XQuU0kmF1YaiRQXGZm=6mExbA6LwsnNGow@mail.gmail.com> <52F7C7E7.7050005@alum.mit.edu> <CALDtMrJvH4r3yLTMcXR9PiC-bQVSf3RSS-OoVmxY9s=8RnpQJQ@mail.gmail.com> <52F83D0F.2090301@alum.mit.edu>
In-Reply-To: <52F83D0F.2090301@alum.mit.edu>
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="iso-8859-1"
Content-ID: <94B6E9760FB6114187039BCD1DCDACD1@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Oleg Moskalenko <mom040267@gmail.com>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [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: Mon, 10 Feb 2014 16:19:19 -0000

I agree with Paul.

That said, I could potentially see a use case for allowing servers to select option (3) -- but if we want to support that, we should define a *new* TURN attribute that indicates that the client is giving the server the freedom to pick the relay's address family.

On Feb 9, 2014, at 9:44 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>
 wrote:

> IMO only (1) makes sense. With the others, migration becomes a nightmare. No flag days!
> 
> 	Thanks,
> 	Paul
> 
> On 2/9/14 7:15 PM, Oleg Moskalenko wrote:
>> I am not sure whether we want a very strict language here.
>> 
>> This is about how the TURN server will react in case of missed
>> REQUESTED-TRANSPORT attribute. There may be three ways to react:
>> 
>> 1) Respond with IPv4 relay endpoint (the current TURN way of doing things);
>> 2) Reject the request (strict enforcement of REQUESTED-TRANSPORT attribute);
>> 3) Respond with IPv6 relay endpoint (may make sense in some networks
>> with heavy IPv6 infestation, like mobile networks).
>> 
>> The new standard (TURN-bis) may have three options for the TURN server:
>> 
>> 1) Keep the 1st way (as in current TURN) as backward-compatible solution;
>> 2) Require that the client always includes that attribute and the TURN
>> server rejects the request if not;
>> 3) Make the behavior undefined (as Simon suggests).
>> 4) Make the behavior configurable.
>> 
>> I can see a sense in options 1 and 3. The first option is 100%
>> backward-compatible and that's good. The third option allows legacy TURN
>> clients in networks where IPv6 is the default protocol (if the legacy
>> client is IPv6 - aware) and leaves the decision to the TURN server
>> administrator or implementation. I am not sure about the fourth option -
>> it may impose unnecessary complication on the implementation.
>> 
>> But I am against the option 2. It is too harsh and it introduces
>> mandatory backward incompatibility.
>> 
>> Oleg
>> 
>> 
>> 
>> 
>> 
>> 
>> On Sun, Feb 9, 2014 at 10:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>> 
>>    Shouldn't backward compatibility of TURN-bis servers with TURN
>>    clients be *mandatory*, rather than optional?
>> 
>>             Thanks,
>>             Paul
>> 
>> 
>>    On 2/7/14 5:08 PM, Oleg Moskalenko wrote:
>> 
>>        OK, that's fine.
>> 
>>        Oleg
>> 
>> 
>>        On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault
>>        <simon.perreault@viagenie.ca
>>        <mailto:simon.perreault@viagenie.ca>
>>        <mailto:simon.perreault@__viagenie.ca
>>        <mailto:simon.perreault@viagenie.ca>>> wrote:
>> 
>>             Le 2014-02-07 16:19, Oleg Moskalenko a écrit :
>>              > Well... OK. If we want the client always to send the
>>        address-family -
>>              > but we do not enforce that on the receiving side... that
>>        sounds
>>              > awkward,  like a speed limit without cops. It is great -
>>        but does
>>             that
>>              > strict requirement make sense without enforcement ? We
>>        can always say
>>              > that TURN client SHOULD send the address-family, but MUST
>>             probably would
>>              > be too strict... I guess.
>> 
>>             The idea is: first, we specify that TURN bis clients MUST send
>>             REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server
>>        behaviour
>>             depending on the value of REQUESTED-ADDRESS-FAMILY. We do
>>        *not* specify
>>             TURN bis server behaviour when that parameter is absent. If the
>>             parameter is absent, the client is not following the TURN
>>        bis spec, and
>>             the server is free to behave however it wants. That
>>        includes *wink wink*
>>             being backward-compatible with TURN.
>> 
>>             This is exactly like the STUNv2 magic cookie: STUNv2
>>        clients MUST send
>>             the magic cookie, and STUNv2 server behaviour is defined
>>        when the cookie
>>             is present. But STUNv2 does not specify server behaviour
>>        when the cookie
>>             is absent. The cookie being absent means the client is not
>>        a STUNv2
>>             client. The server is free to behave however it wishes.
>>        That includes
>>             *wink wink* being backward-compatible with STUNv1.
>> 
>>             Simon
>>             --
>>             DTN made easy, lean, and smart -->
>>        http://postellation.viagenie.__ca <http://postellation.viagenie.ca>
>>             NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>>             STUN/TURN server               --> http://numb.viagenie.ca
>>             _________________________________________________
>>             tram mailing list
>>        tram@ietf.org <mailto:tram@ietf.org> <mailto:tram@ietf.org
>>        <mailto:tram@ietf.org>>
>>        https://www.ietf.org/mailman/__listinfo/tram
>>        <https://www.ietf.org/mailman/listinfo/tram>
>> 
>> 
>> 
>> 
>> 
>>        _________________________________________________
>>        tram mailing list
>>        tram@ietf.org <mailto:tram@ietf.org>
>>        https://www.ietf.org/mailman/__listinfo/tram
>>        <https://www.ietf.org/mailman/listinfo/tram>
>> 
>> 
>>    _________________________________________________
>>    tram mailing list
>>    tram@ietf.org <mailto:tram@ietf.org>
>>    https://www.ietf.org/mailman/__listinfo/tram
>>    <https://www.ietf.org/mailman/listinfo/tram>
>> 
>> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>