Re: [tram] Review of dual allocation in TURNbis-11
Marc Petit-Huguenin <petithug@acm.org> Sun, 11 March 2018 12:45 UTC
Return-Path: <petithug@acm.org>
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 5758212D77C for <tram@ietfa.amsl.com>; Sun, 11 Mar 2018 05:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 8JfijpPj0uIo for <tram@ietfa.amsl.com>; Sun, 11 Mar 2018 05:45:57 -0700 (PDT)
Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EC31201FA for <tram@ietf.org>; Sun, 11 Mar 2018 05:45:57 -0700 (PDT)
Received: from [IPv6:2601:648:8301:730f:ac0b:c7cc:59a:561f] (unknown [IPv6:2601:648:8301:730f:ac0b:c7cc:59a:561f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 62879AE8D9; Sun, 11 Mar 2018 13:45:55 +0100 (CET)
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "tram@ietf.org" <tram@ietf.org>
References: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> <DM5PR16MB17881ABD54B89E14F0291C56EA4C0@DM5PR16MB1788.namprd16.prod.outlook.com> <ea84bcf9-19b6-5492-383b-18e2bc5a93bf@acm.org> <DM5PR16MB178859E2018148DBAD51635EEAF20@DM5PR16MB1788.namprd16.prod.outlook.com> <46fdf931-eb0c-c4fe-9c01-4a066134abfb@acm.org> <BN6PR16MB142530705DF3F28C07FAC9A2EADB0@BN6PR16MB1425.namprd16.prod.outlook.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <6c8962b4-ad44-eeb0-6334-bf496619eaee@acm.org>
Date: Sun, 11 Mar 2018 05:45:53 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <BN6PR16MB142530705DF3F28C07FAC9A2EADB0@BN6PR16MB1425.namprd16.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="V1JlKIE1CC07zyfJ4FHA5KlOkXmFlQR6v"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/dxXcKFznY4IRsN6nri9dLlQDafs>
Subject: Re: [tram] Review of dual allocation in TURNbis-11
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: Sun, 11 Mar 2018 12:46:01 -0000
Inline. On 03/04/2018 05:30 AM, Konda, Tirumaleswar Reddy wrote: > Hi Marc, > > Please see inline > >> -----Original Message----- >> From: Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: Saturday, March 3, 2018 2:47 AM >> To: Konda, Tirumaleswar Reddy >> <TirumaleswarReddy_Konda@McAfee.com>; tram@ietf.org >> Subject: Re: [tram] Review of dual allocation in TURNbis-11 >> >> As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed >> on below, and found some discrepancies. See inline. >> >> On 02/09/2018 04:51 AM, Konda, Tirumaleswar Reddy wrote: >>>> -----Original Message----- >>>> From: Marc Petit-Huguenin [mailto:petithug@acm.org] >>>> Sent: Sunday, October 22, 2017 9:38 PM >>>> To: Konda, Tirumaleswar Reddy >>>> <TirumaleswarReddy_Konda@McAfee.com>; tram@ietf.org >>>> Subject: Re: [tram] Review of dual allocation in TURNbis-11 >>>> >>>> Inline. >>>> >>>> On 10/16/2017 07:14 PM, Konda, Tirumaleswar Reddy wrote: >>>>> Thanks Marc for the detailed review, Please see inline >>>>> >>>>>> -----Original Message----- >>>>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- >>>>>> Huguenin >>>>>> Sent: Saturday, October 14, 2017 12:59 AM >>>>>> To: tram@ietf.org >>>>>> Subject: [tram] Review of dual allocation in TURNbis-11 >>>>>> >> >> [snip] >> >>>>> >>>>>> >>>>>> - Section 6.2 >>>>>> >>>>>> I would suggest to make ADDRESS-ERROR-CODE more generic by >>>> renaming >>>>>> it as WARNING-CODE and use the same format than for ERROR-CODE. >>>> Then >>>>>> allocate a new error code for that specific warning. I would >>>>>> suggest to request the 0x8009 codepoint for that attribute. >>>>> >>>>> I don't understand the need to change ADDRESS-ERROR-CODE ! >>>> >>>> To make it more generic and reusable in future specifications. >>> >>> ADDRESS-ERROR-CODE cannot use the same format as ERROR-CODE, >> ADDRESS-ERROR-CODE signals the IP address family for which the warning is >> generated + all the fields in the ERROR-CODE. >>> >>>> >>>>> >>>>>> >>>>>> Also I think we needs two different warnings, one that states that >>>>>> dual allocation is not available in a TURNbis server, but both >>>>>> protocols are available, and another that says that dual allocation >>>>>> failed because one of the two protocols is not available. This is >>>>>> to let the client know that it is useless to try another allocation >>>>>> for the >>>> missing protocol. >>>>> >>>>> I don't get the reason for two different warnings. >>>> >>>> A server may support both IPv6 and IPv4 allocations and not support >>>> dual allocation, in which case the client can do a second allocation >>>> for the IPv6 relayed address. >>> >>> If the server does not support dual allocation but supports both IPv6 and >> IPv4 allocations, it will only allocate the IPv4 relayed address and not will not >> return ADDRESS-ERROR-CODE in the response, the client will know the >> server does not understand the ADDITIONAL-ADDRESS-FAMILY attribute >> (ADDITIONAL-ADDRESS-FAMILY is a comprehension-optional attribute). >>> >>>> >>>> Alternatively the server may not support IPv6 at all, in which case >>>> the second allocation will fail and was unnecessary. >>> >>> ADDRESS-ERROR-CODE signals both unsupported IP address type (0x02 >> (IPv6 address family)) and the reason for failure (440 (unsupported address >> family)). >>> >>> Cheers, >>> -Tiru >>> >>>> >>>> Using two different warnings permits to know if the second allocation >>>> will succeed or not. >>>> >>>>> >>>>>> >>>>>> What is the policy when reserving the next port with the EVEN-PORT >>>>>> attribute in a dual allocation, but one of them fails to find a >>>>>> pair of subsequent ports available? >>>>> >>>>> It's discussed in section 6.1 >>>>> >>>>> <snip> >>>>> Clients MUST NOT >>>>> include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request >>>>> that contains an EVEN-PORT attribute with the R bit set to 1. >>>>> </snip> >>>>> >>>>>> >>>>>> It is not said that the Allocate successful response must contain >>>>>> two XRAs after a successful dual allocation. >>>>> >>>>> Good point, Updated draft. >> >> I cannot find this update in turn-14. > > This comment is partially addressed in -12 revision, step 9 (in Section 6.2 in -12 revision and Section 7.2 in -14 revision) is updated to discuss dual allocation. > <snip> > If the server can fully meet > the request, then the server allocates one IPv4 and one IPv6 > relay address, and returns an Allocate success response > containing the relayed transport addresses assigned to the dual > allocation. > </snip> > > NEW: > If the server can fully meet > the request, then the server allocates one IPv4 and one IPv6 > relay address, and returns an Allocate success response > containing the relayed transport addresses assigned to the dual > allocation in two XOR-RELAYED-ADDRESS attributes. OK. > >> >>>>> >>>>>> >>>>>> I would also suggest to add some text that says that when a TURNbis >>>>>> server sends an Allocate success response, it must always send the >>>>>> XRAs in the same order than the RAFs were sent. So in case the >>>>>> server sends back by mistake two XRAs, the first one matches the >>>>>> one >>>> requested by the client. >> >> Did not get answer to that and did not see it in turn-14. > > I did not get this comment. If a request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes, the request is rejected by the server. Further, only IPv6 address family is allowed in the > ADDITIONAL-ADDRESS-FAMILY attribute. > No, my request was to ask that in case of dual allocation the address that is selected following the ADDITIONAL-ADDRESS-FAMILY attribute is inserted after the address selected by the REQUESTED-ADDRESS-FAMILY attribute in the response. So if the order in the request is: REQUESTED-ADDRESS-FAMILY for ipv4 ADDITIONAL-ADDRESS-FAMILY for ipv6 then the response contains XOR-RELAYED-ADDRESS for ipv4 XOR-RELAYED-ADDRESS for ipv6 This is a corner case (if the server misbehave, the client still works), so I am OK with this request ignored. > >> >>>>>> >>>>>> The bullet list at the end needs also to be fixed for dual allocation. >>>>> >>>>> Agreed, fixed. >>>>> >>>>>> >>>>>> - Section 6.3 >>>>>> >>>>>> Here's too, the text needs to be updated for the dual allocation case. >>>>> >>>>> >>>>> Yup, updated. >>>>> >> >> Same, there is no update since -11 in section 7.3 (formerly 6.3) > > This comment is addressed in -12 revision itself, the updated text uses "relayed transport address or addresses" and " address family or families" to discuss the > dual allocation case. > OK. -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
- [tram] Review of dual allocation in TURNbis-11 Marc Petit-Huguenin
- Re: [tram] Review of dual allocation in TURNbis-11 Konda, Tirumaleswar Reddy
- Re: [tram] Review of dual allocation in TURNbis-11 Marc Petit-Huguenin
- Re: [tram] Review of dual allocation in TURNbis-11 Konda, Tirumaleswar Reddy
- Re: [tram] Review of dual allocation in TURNbis-11 Marc Petit-Huguenin
- Re: [tram] Review of dual allocation in TURNbis-11 Konda, Tirumaleswar Reddy
- Re: [tram] Review of dual allocation in TURNbis-11 Karl Stahl
- Re: [tram] Review of dual allocation in TURNbis-11 Konda, Tirumaleswar Reddy
- [tram] Extend dual allocation to multiple in TURN… Karl Stahl
- Re: [tram] Review of dual allocation in TURNbis-11 Brandon Williams
- Re: [tram] Extend dual allocation to multiple in … Brandon Williams
- Re: [tram] Review of dual allocation in TURNbis-11 Brandon Williams
- Re: [tram] Review of dual allocation in TURNbis-11 Marc Petit-Huguenin