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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 10 February 2014 02:44 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 E4EDC1A066E for <tram@ietfa.amsl.com>; Sun, 9 Feb 2014 18:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 S2NGzyvd0kWE for <tram@ietfa.amsl.com>; Sun, 9 Feb 2014 18:44:32 -0800 (PST)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id A75F51A062A for <tram@ietf.org>; Sun, 9 Feb 2014 18:44:31 -0800 (PST)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id QSTB1n0060cZkys59SkXkb; Mon, 10 Feb 2014 02:44:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id QSkX1n0083ZTu2S3WSkXzv; Mon, 10 Feb 2014 02:44:31 +0000
Message-ID: <52F83D0F.2090301@alum.mit.edu>
Date: Sun, 09 Feb 2014 21:44:31 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Oleg Moskalenko <mom040267@gmail.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>
In-Reply-To: <CALDtMrJvH4r3yLTMcXR9PiC-bQVSf3RSS-OoVmxY9s=8RnpQJQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392000271; bh=VBVQ865TZh5JKl5R/TQBjX0C65cqJ+YyDzM25iEJ2IY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hq68mJERqR/Pgb0Fhf8QhuznA9Fc1/5fTd+WZH6bel2gRvkpxgZTQNnIV92AobM5k Ak1xuLP/uUsY//Rq84L2zL17ItkAXpjbZ9k74CS8rPle9nuIFwjjhvmTSuiFJO0Ekm hdiGeKuEX71Czj4NJpEgSriaSjhywAj0GIZ9V9UQG6GIdM4hwtQ2DZLBD19a2J3XJI evJpV1XXr3aWXgNoxMBdU+kKlgzIdUBRhS3tWdOWv95YbRXlGLVSGlXlIPuRmYtpkb uYwmnl3JANSLraGgj6q9VjqQsLQr0AVXfvkJbMu8Dl0BJTGfjIAHOyE0jMOo9MoyWF 2fMODz5R+tW4Q==
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 02:44:34 -0000

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>
>
>