Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt

Justin Uberti <juberti@google.com> Tue, 03 April 2018 05:03 UTC

Return-Path: <juberti@google.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A770712DA50 for <tram@ietfa.amsl.com>; Mon, 2 Apr 2018 22:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 pVgbN6m7-qkt for <tram@ietfa.amsl.com>; Mon, 2 Apr 2018 22:03:15 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80B912D86D for <tram@ietf.org>; Mon, 2 Apr 2018 22:03:14 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id q12so10234756uae.4 for <tram@ietf.org>; Mon, 02 Apr 2018 22:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MXdWPC/LHIBqLopsHwEQluAt8V1o7zCqdlFtupURGu4=; b=dPju9PKIZWI3xD76m3zLD/2XizXsC7a75KF6q7Ga4kqGcxvc1/OB+jWrOD7txy0LtH /IASXuAyzROhi2nrdl5t4dRNd7UD78Up7aZI8hcJZStYwzMK5LjjuPiEVQgoIy6C58Qm lRwNeCEDD2cgHjRrO1k7GjRiL20W/uQerMSg6VKkkd3jWSKOSoZPw8amh1cutWu2sBdb ERtBtJY94yraGhTTkz58+E4Uk1WvCkpzlbMHjwtJddDIyR3tJ/18t4D6JX4pjXBsm3rV YaySQ4HfEbI1KOiWuJziTdSmYRP4rMteWauAs+7CHr9xam1BWKKeYJF/Tbo5xuKg95b6 DhcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MXdWPC/LHIBqLopsHwEQluAt8V1o7zCqdlFtupURGu4=; b=aCNiS25JDmovPxdoyXeancjHV8RwjZTC2/ZfCwz4mMrWTkiGr8yZjEzoIJV2v1+Nrk SFXxlsqCmrDy28+UTpBACeVVBsM61blWMy4qLrL200sO6vFwJSP/alpeGjUdjuxMW69j WXeMTPKNdjkNG1CXmHWTeGMQt51BDtw7Fs2dFxQdxz1vgcjYDoQTt50s70Mr95HGJUMU K0AaUyQZYecp0ZzkahN/gGe8RzCi0RhGmpaEhvRIQhssVlG0e9+OmEZmZQZV5Bo/D7MK j96cSY1INic9Vf9s4ybHjiXz8sj2NOsJXnMP98vL1irWRAEJIMYVe8UcBQqNVjd5LK1C 4rOA==
X-Gm-Message-State: ALQs6tC2JxenafTkZL8cM6+Ly4BZLqc1Op8NkBdJcEyGqzKjgQDNZYee p9iqhbizZ2qxBsSvy1t9DWZY98zTS2VvC10ZQtHDsg==
X-Google-Smtp-Source: AIpwx49A4YQqZ8YdNpoGOQbr4YEodUyqhCVxSoBnZR2DhQLuwXexEX7p6IsuJVJYUXiQfUlGfmn34UTWwn+QTqUZblo=
X-Received: by 10.176.30.136 with SMTP id o8mr541053uak.108.1522731793297; Mon, 02 Apr 2018 22:03:13 -0700 (PDT)
MIME-Version: 1.0
References: <152136260256.18150.10551009018364033510@ietfa.amsl.com> <BN6PR16MB1425D61744AC7480972C800AEAD50@BN6PR16MB1425.namprd16.prod.outlook.com> <BEC020EA-C973-48E5-A918-EF2D25953E33@edvina.net> <BN6PR16MB1425327E5CD094CF18A040F2EAAA0@BN6PR16MB1425.namprd16.prod.outlook.com> <c3584946-2782-2ac7-7f7c-7e7ae273fec9@akamai.com> <CANO7kWC5H_0jv-=MsRzQaO7C=SsTbqz-UJhARm2f1SWOA6uutA@mail.gmail.com> <0e354f75-5ca9-07d2-9e63-2b9bc49fd4fe@akamai.com> <708D2731-0E8B-4AB8-B4C1-27C86573341D@edvina.net>
In-Reply-To: <708D2731-0E8B-4AB8-B4C1-27C86573341D@edvina.net>
From: Justin Uberti <juberti@google.com>
Date: Tue, 03 Apr 2018 05:03:02 +0000
Message-ID: <CAOJ7v-0kXgHp2FmnzKwjGjFawcr=ByWsfAfEH8yEugPbp-u9cA@mail.gmail.com>
To: "Olle E. Johansson" <oej@edvina.net>
Cc: Brandon Williams <brandon.williams@akamai.com>, Simon Perreault <sperreault@jive.com>, TirumaleswarReddy_Konda@mcafee.com, tram@ietf.org, Karl Stahl <karl.stahl@ingate.com>
Content-Type: multipart/alternative; boundary="089e0828e490a1664f0568ea9f67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/irnavFQpPHdK4IwIWRCLzQvbBJw>
Subject: Re: [tram] Multiple allocations SV: I-D Action: draft-ietf-tram-turnbis-15.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 03 Apr 2018 05:03:20 -0000

I spent time with Pal and others coming up with the initial dual allocation
concept (SSODA) and there are clear reasons for this approach (as discussed
in the intro of the original SSODA doc).

It's not clear to me why multiple addresses of the same family are ever
needed though, and even if we supported this, how the client would be
expected to select between them. It seems like a large expansion of scope
beyond the goals of SSODA.

On Mon, Apr 2, 2018 at 11:47 AM Olle E. Johansson <oej@edvina.net> wrote:

> Hi!
>
> Well, since Network-provided servers was added to the security section of
> RFC 8155, I kind of think it’s now in scope for
> everything TURN and from that standpoint I do understand Karl’s objections.
>
> On the other hand, I don’t really like how it was added to that RFC and
> like the idea of a separate document that
> clears this mess up and explains clearly how network-provided TURN-servers
> is supposed to work, the requirements
> and additions to the TURN protocol.
>
> The problem with that is that implementors may think it’s just an add-on
> and not implement it in the TURN client
> implementations, which would be harmful in the long run.
>
> Question: Will adding operations or modifying existing ones in a new
> document make it a mandatory
> part of the TURN protocol, an update to the TURN RFC (turnbis as an RFC
> that is)?
>
> /O
>
>
>
>
> > On 2 Apr 2018, at 18:46, Brandon Williams <brandon.williams@akamai.com>
> wrote:
> >
> > Karl,
> >
> > There is no WG decision to hinder this, simply a disagreement about
> approach.
> >
> > Some of us (the editors in particular) have been working on the turnbis
> draft for quite some time. It went into WGLC several months ago and it is
> already well behind the originally agreed schedule in the charter.
> >
> > Considering the fact that this is not something that was ever called out
> previously, we are only questioning why it has suddenly become critical to
> expand the scope of turnbis and thus delay publishing even further.
> >
> > If there were already a draft that explains the rationale, use cases,
> and protocol changes, it would be easier to assess the impact and consider
> inclusion. This was the path followed by a few other new capabilities that
> were eventually rolled directly into turnbis.
> >
> > If the WG came to the conclusion that we should not delay turnbis any
> further but instead should advance the capability as a new RFC candidate,
> we would already be in a good position to that if we had a draft in hand.
> If the WG decided to include this in turnbis, we would already have text
> available.
> >
> > IOW, I am only resisting the idea of expanding the scope of turnbis
> without WG consensus to do so; I am not resisting your proposal itself. The
> suggestion that you take the time to write down your idea in I-D format
> seems like a good way for you to drive the required WG discussion.
> >
> > --Brandon
> >
> > On 03/22/2018 05:17 PM, Karl Stahl wrote:
> >> No and this draft cannot be approved without the generalization I have
> pointed out.
> >> I really don’t understand why we are having this resistance.
> >> Already the second paragraph of the Abstract states:
> >> The TURN protocol was designed to be used as part of the ICE
> >>    (Interactive Connectivity Establishment) approach to NAT traversal,
> >>    though it also can be used without ICE.
> >> And further in the Introduction
> >> TURN was designed as one piece in the larger ICE approach to NAT
> >>    traversal.  Implementors of TURN are *_urged_* to investigate ICE and
> >>    seriously consider using it for their application.
> >> **
> >> I cannot imagine that there is some WG decision to hinder ICE usage for
> network provided TURN servers EXCEPT FOR EXACTLY BRANDON’S NETWORK.
> >> For now I refrain from writing/debating more – which would override the
> effort of what is required to generalize as asked.
> >> Please be happy that most of the dual allocation work done, can be
> reused to fulfill the generalization.
> >> Tiru and Brandon are encouraged to read the TRAM charter …
> >> /Karl
> >> *Från:*Simon Perreault [mailto:sperreault@jive.com]
> >> *Skickat:* den 21 mars 2018 18:13
> >> *Till:* Brandon Williams
> >> *Kopia:* Konda, Tirumaleswar Reddy; Olle E. Johansson; Karl Stahl;
> tram@ietf.org
> >> *Ämne:* Re: [tram] Multiple allocations SV: I-D Action:
> draft-ietf-tram-turnbis-15.txt
> >> 2018-03-21 17:05 GMT+00:00 Brandon Williams <
> brandon.williams@akamai.com <mailto:brandon.williams@akamai.com>>:
> >> Chairs, Any suggestions on approach?
> >> The proposal on the table is for Karl+Olle to write their idea into a
> new draft.
> >> Karl+Olle, can you guys live with that?
> >> Simon
> >> **********************
> >> Let me explain more clearly why multiple allocations is needed:
> >> ICE is about finding all/many paths for the media, e.g. with the help of
> >> TURN servers.
> >> Those paths are not over ONE IPv4 network, over ONE IPv6 network or
> EXACTLY
> >> ONE OF EACH.
> >> If fact, it is more common that you have several IPv4 networks paths.
> >> Now that we have network provided TURN servers, you only ask for
> Allocation
> >> once (contrary to application provided TURN servers, where you can be
> >> directed to Allocate several times.) and thus we need all relay
> addresses in
> >> one allocation request.
> >> Wasn't that the reason dual allocation was requested? The need for
> multiple
> >> allocation is stronger!
> >> Please address this, e.g. like below (seems you are almost there).
> >> /Karl
> >> ******************* Previous *******************
> >> Allowing a turn allocation to return multiple relayed transport
> addresses,
> >> beyond ONE IPv4 and ONE IPv6 (which may sit on the same or on different
> >> interfaces/network segments), seems like very small step now when the
> dual
> >> allocation was put in place in this draft. We certainly need it (some
> >> reasons below) if TURN is going to be used where needed and we cannot
> wait
> >> for any additional draft.
> >> Seems like it is sufficient to extent this table (found in draft 14)
> with 3
> >> new values (as shown):
> >> 16.  STUN Attributes
> >>    This STUN extension defines the following attributes:
> >>      0x000C: CHANNEL-NUMBER
> >>      0x000D: LIFETIME
> >>      0x0010: Reserved (was BANDWIDTH)
> >>      0x0012: XOR-PEER-ADDRESS
> >>      0x0013: DATA
> >>      0x0016: XOR-RELAYED-ADDRESS
> >>      0x0017: REQUESTED-ADDRESS-FAMILY
> >>      0x0018: EVEN-PORT
> >>      0x0019: REQUESTED-TRANSPORT
> >>      0x001A: DONT-FRAGMENT
> >>      0x0021: Reserved (was TIMER-VAL)
> >>      0x0022: RESERVATION-TOKEN
> >>      TBD-CA: ADDITIONAL-ADDRESS-FAMILY
> >> ADDITIONAL-ADDRESS-ALL
> >> ADDITIONAL-ADDRESS-ALLV4
> >> ADDITIONAL-ADDRESS-ALLV6
> >>      TBD-CA: ADDRESS-ERROR-CODE
> >>      TBD-CA: ICMP
> >> Actually, browsing through the draft for ADDITIONAL-ADDRESS-FAMILY, very
> >> little text seems to be added for generalization to
> ADDITIONAL-ADDRESS-xxx.
> >> Almost everything applies to ADDITIONAL-ADDRESS-xxx and can be reused.
> >> ADDITIONAL-ADDRESS-ALL should be the default for any modern TURN client.
> >> Check! - We need this now.
> >> Thanks,
> >> Karl
> >
> > --
> > Brandon Williams; Chief Architect
> > Cloud Networking; Akamai Technologies Inc.
> >
> > _______________________________________________
> > 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
>