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

Oleg Moskalenko <mom040267@gmail.com> Fri, 07 February 2014 21:19 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 D98031A0459 for <tram@ietfa.amsl.com>; Fri, 7 Feb 2014 13:19:34 -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 mvOhbNBk1toi for <tram@ietfa.amsl.com>; Fri, 7 Feb 2014 13:19:33 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 928111A020C for <tram@ietf.org>; Fri, 7 Feb 2014 13:19:33 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id y13so3667582pdi.9 for <tram@ietf.org>; Fri, 07 Feb 2014 13:19:33 -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=qV7F0RUl9KTsIMoAt6iLQbU3hViUGabjJBbt8WP8eFo=; b=wVj1qI523zKpw6OFp5inJyLZBKV2uNshHzNHJnro5DMmc+lJXJcOwC5mB7VpdjF5z5 AWmhGHP6ghDp2lJHu1TOgxn+o1Sn0JHcV1/XckeETVqduEx+XOEPuaT4eirIzuuw0eQF eUcD6R78TkQIIU2jAhp212+0U8LLCCfkjgISlhJ2koSKUsh8HRphSNfDgOpkT9n5fKbN pLjzK/fNZz8u4bGAUylRAOK9iu2AGxCAvUCYBUWPkJO3fuTmQDgOZBHfV6T/O3aj0ISP 5GexgOjwsv6D9HYGeTTyfNqNjLi8oxz4gfOuz5GzuATn6zuASX07NH24eExPgjDdt/Xj Kb7A==
MIME-Version: 1.0
X-Received: by 10.68.139.100 with SMTP id qx4mr22127131pbb.144.1391807973462; Fri, 07 Feb 2014 13:19:33 -0800 (PST)
Received: by 10.68.147.131 with HTTP; Fri, 7 Feb 2014 13:19:33 -0800 (PST)
In-Reply-To: <52F54CDC.1040502@viagenie.ca>
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>
Date: Fri, 07 Feb 2014 13:19:33 -0800
Message-ID: <CALDtMrJ4J78t4PboxN5O3ZPMmt243zZ2YV5LBv-Nhz1k3E7LyQ@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: multipart/alternative; boundary="001a11c361d2da98f204f1d78b6d"
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: Fri, 07 Feb 2014 21:19:35 -0000

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.


On Fri, Feb 7, 2014 at 1:15 PM, Simon Perreault <simon.perreault@viagenie.ca
> wrote:

> Le 2014-02-07 15:58, Oleg Moskalenko a écrit :
> > Still we want a default behavior when a client (legacy ?) does not send
> > REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason
> > to introduce a backward incompatibility for the legacy clients unless
> > there is a good really important security reasons. I do not see any
> > security problem with the default behavior.
>
> I phrased my wish very carefully:
>
> "In TURN bis I would want clients to *always* send
> REQUESTED-ADDRESS-FAMILY."
>
> Note that I did not say anything about server behaviour. Intentionally. :)
>
> 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
> https://www.ietf.org/mailman/listinfo/tram
>