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

Oleg Moskalenko <mom040267@gmail.com> Mon, 10 February 2014 00:15 UTC

Return-Path: <mom040267@gmail.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 C95611A0628 for <tram@ietfa.amsl.com>; Sun, 9 Feb 2014 16:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 PeZGQTkG1jQb for <tram@ietfa.amsl.com>; Sun, 9 Feb 2014 16:15:14 -0800 (PST)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 10E7C1A061B for <tram@ietf.org>; Sun, 9 Feb 2014 16:15:14 -0800 (PST)
Received: by mail-pd0-f181.google.com with SMTP id y10so5338410pdj.26 for <tram@ietf.org>; Sun, 09 Feb 2014 16:15:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZlaKHsmHCuCoHZz1zb/vrz9BAzTYcfX3SylYqcjft3g=; b=rdAzBJ0ot1t+CyNy4/SQPxhvcgcVbmvw/k6o3Boxa/kiO9v97tT5QGAdLLAIbnVW/k ztxIVCH/iLZIf0UH/ZY2sjK9UI5iKOGvKnmqQVjHALEX7xDI8aNWjlsLQRii9IdjNeJ3 HKutHDiy+Ln9sk6qkqshJ+Qn9Zgb08hXEiTy1yuMCANiVHE7Qvq7X59ujnqGMbXK2E7T IN1t3rqHSZFILR0uUpfoKOqnCYenY4eqgvVRbTDwGKGmmP2zjX0EjiNJMG+1yVnOSpV7 gLx//LqQ8X46hWMZy4M6dlfvu3v63l04/3sxxYZAHyGZyH3To3OG5XBn09n5hbGiaImv ulZQ==
MIME-Version: 1.0
X-Received: by 10.68.226.70 with SMTP id rq6mr34334022pbc.107.1391991314212; Sun, 09 Feb 2014 16:15:14 -0800 (PST)
Received: by 10.68.147.131 with HTTP; Sun, 9 Feb 2014 16:15:14 -0800 (PST)
In-Reply-To: <52F7C7E7.7050005@alum.mit.edu>
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>
Date: Sun, 09 Feb 2014 16:15:14 -0800
Message-ID: <CALDtMrJvH4r3yLTMcXR9PiC-bQVSf3RSS-OoVmxY9s=8RnpQJQ@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="e89a8ff24355d06df404f2023bb8"
Cc: "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 00:15:17 -0000

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> 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>> 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
>>     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>
>>     https://www.ietf.org/mailman/listinfo/tram
>>
>>
>>
>>
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>