Re: [tram] Review of dual allocation in TURNbis-11

Brandon Williams <brandon.williams@akamai.com> Fri, 09 March 2018 21:16 UTC

Return-Path: <brandon.williams@akamai.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 ECF80124F57 for <tram@ietfa.amsl.com>; Fri, 9 Mar 2018 13:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 srdY-IeOh8GO for <tram@ietfa.amsl.com>; Fri, 9 Mar 2018 13:16:57 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7C21270FC for <tram@ietf.org>; Fri, 9 Mar 2018 13:16:57 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w29LDKmf029250; Fri, 9 Mar 2018 21:16:47 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=jKarQAEy0UTcvQ/i/rEBLGjBEV25tEkNy+WcCvH2Aew=; b=AIb2QN2SIzl7iyfwNWFNYqpQFGly2ZV1wqIBakK41mLgmTEMxEGwduaQVbnbDvyAsqdB wq9TxIPd/Td48Ac+pKAtTe17udOd1ReBijXOujU3J9kZ2vcJRMeR213iBCFPazcF4wqs hp4ojgkwPx6sSyLqT7JNRwXPXWeG5P8CNcdcWExcU8uvDUYq/1mtcLyneK4ksF9K4vWh LcVcScOim/temS+2skJg1zeBYxC6KIf4MBtjg+++t/HizjVthZI0nDwYqgP+m55DuanY pXp0TmCo277fTf2Bl6c5dodnfnMxSrDjW8qMqb6kgfR8oYeoGVWyVfq9epoozojjOFkC CQ==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2gke67uc97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Mar 2018 21:16:47 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w29LFqqD002562; Fri, 9 Mar 2018 16:16:46 -0500
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2gfqx11gs0-1; Fri, 09 Mar 2018 16:16:46 -0500
Received: from [172.28.118.62] (bowill.kendall.corp.akamai.com [172.28.118.62]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id C82CD84668; Fri, 9 Mar 2018 21:16:45 +0000 (GMT)
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Karl Stahl <karl.stahl@ingate.com>, 'Marc Petit-Huguenin' <petithug@acm.org>, "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> <025201d3b3db$0e182730$2a487590$@stahl@ingate.com> <BN6PR16MB1425C15E7BA5D10DB86AA41DEADA0@BN6PR16MB1425.namprd16.prod.outlook.com>
From: Brandon Williams <brandon.williams@akamai.com>
Message-ID: <a97551ca-4852-1272-ceae-2eb5e9b26520@akamai.com>
Date: Fri, 09 Mar 2018 16:16:42 -0500
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: <BN6PR16MB1425C15E7BA5D10DB86AA41DEADA0@BN6PR16MB1425.namprd16.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-09_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803090252
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-09_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803090251
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/P5L4qJTZmYtw7-c1RYA-qfoE5Sk>
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: Fri, 09 Mar 2018 21:17:00 -0000

This change looks good to me.

Karl, Do you agree that it addresses the inconsistency you previously 
mentioned?

--Brandon

On 03/05/2018 05:47 AM, Konda, Tirumaleswar Reddy wrote:
> Thanks Karl. I have fixed the inconsistency.
> 
> NEW:
>     1.   The server SHOULD require that the request be authenticated.
>          The authentication of the request is optional to allow TURN
>          servers provided by the local or access network to accept
>          Allocation requests from new and/or guest users in the network
>          who do not necessarily possess long term credentials for STUN
>          authentication and its security implications are discussed in
>          [RFC8155].  If the request is authenticated, the authentication
>          MUST be done using the long-term credential mechanism of
>          [I-D.ietf-tram-stunbis] unless the client and server agree to
>          use another mechanism through some procedure outside the scope
>          of this document.
> 
> WG has discussed and agreed only on dual allocation and your proposal to return multiple relayed transport addresses of the same family is new work and the need for this enhancement needs to be discussed and agreed in the WG.
> A new draft looks more suitable to discuss this enhancement.
> 
> -Tiru
> 
>> -----Original Message-----
>> From: Karl Stahl [mailto:karl.stahl@ingate.com]
>> Sent: Sunday, March 4, 2018 10:36 PM
>> To: 'Marc Petit-Huguenin' <petithug@acm.org>; Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>; tram@ietf.org
>> Subject: SV: [tram] Review of dual allocation in TURNbis-11
>>
>> Hi,
>>
>> When we now have "dual allocation" into this draft (I see on page 26: "If the
>> client wishes to obtain one IPv6 and one IPv4 relayed transport address then
>> it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it") can
>> we not generalize that further and allow MORE THAN ONE relayed transport
>> address (of any family) in response to an allocation?
>>
>> I mean that a TURN server could have several relay interfaces at different IP-
>> addresses into different networks - not just the Internet, but also a VoIP
>> (higher quality) network e.g. by some triple play service provider, an IMS
>> network or some branch office network.
>>
>> I think this is specifically important for network provided/auto discovered
>> turn servers (application provided turn servers could instead just list several
>> turn servers).
>>
>> I saw someone snipped this about "SINGLE relayed transport address per
>> allocation request"
>>>> https://tools.ietf.org/html/rfc6156#section-3
>>>> <snip>
>>>>
>>>>     TURN servers allocate a single relayed transport address per
>>>>     allocation request.  Therefore, Allocate requests cannot carry more
>>>>     than one REQUESTED-ADDRESS-FAMILY attribute.  Consequently, a
>> client
>>>>     that wishes to allocate more than one relayed transport address at a
>>>>     TURN server (e.g., an IPv4 and an IPv6 address) needs to perform
>>>>     several allocation requests (one allocation request per relayed
>>>>     transport address).
>>>> </snip>
>>
>> but if that is remedied now, it seems like a small step to generalize so we can
>> get multiple relayed transport addresses from one allocate request?
>>
>> /Karl
>>
>> PS: I also saw one small inconsistency when browsing through.
>>
>> On page 26:
>> "7.2.  Receiving an Allocate Request
>>
>>     When the server receives an Allocate request, it performs the
>>     following checks:
>>
>>     1.   The server MUST require that the request be authenticated..."
>>
>> Without mentioning (making exception from the MUST) that authentication
>> may not be required (which is already mentioned on page 17:
>> "2.9.  Happy Eyeballs for TURN
>> ...
>>
>>     o  For clear text UDP, send TURN Allocate requests to both IP address
>>        families as discussed in [RFC8305], without authentication
>>        information. If the TURN server requires authentication, it will
>>        send back a 401 unauthenticated response and the TURN client uses
>>        the first UDP connection on which a 401 error response is
>>        received.  If a 401 error response is received from both IP
>>        address families then the TURN client can silently abandon the UDP
>>        connection on the IP address family with lower precedence.  If the
>>        TURN server does not require authentication (as described in
>>        Section 9 of [RFC8155]), it is possible for both Allocate requests
>>        to succeed."
>>
>> -----Ursprungligt meddelande-----
>> Från: tram [mailto:tram-bounces@ietf.org] För Marc Petit-Huguenin
>> Skickat: den 2 mars 2018 22:17
>> Till: Konda, Tirumaleswar Reddy; tram@ietf.org
>> Ämne: 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.
>>
>>>>>
>>>>>>
>>>>>> 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.
>>
>>>>>>
>>>>>> 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)
>>
>> --
>> Marc Petit-Huguenin
>> Email: marc@petit-huguenin.org
>> Blog: https://marc.petit-huguenin.org
>> Profile: https://www.linkedin.com/in/petithug
>>
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
> 

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.