From nobody Wed Jan 6 16:02:45 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2821A1EF2; Wed, 6 Jan 2016 16:02:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 16:02:42 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 00:02:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-06.txt Pages : 15 Date : 2016-01-06 Abstract: Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 6 16:06:50 2016 Return-Path: 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 69B351A1EF9 for ; Wed, 6 Jan 2016 16:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 TYEDTt8mTuGe for ; Wed, 6 Jan 2016 16:06:48 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45AC1A1EEA for ; Wed, 6 Jan 2016 16:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2133; q=dns/txt; s=iport; t=1452125207; x=1453334807; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UreQh7u+gk1PGhBm44R8uewshp38pKKC/fqEWNCVsec=; b=QbS5huTblhRWTCD/Q4wzMGKMTXqyfu1BE24vmPUV5+OZQwqsBlG0d5to cISdcWNwwBiVKiOY/U8UEacS+a4wcGk+uJxQeFPmVM/1DHSlZYfbAo1Rp SKQleq5nlsyq3/USU2HCn2eKQvc92zYOsZZjkqMk7TaNUC9z77wFEE3mR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgA3q41W/4kNJK1egzpSbQaIU7NaA?= =?us-ascii?q?Q2BZBgMhWsCgSU4FAEBAQEBAQF/C4Q1AQEEAQEBaxsCAQhGJwslAgQTiC8OwXM?= =?us-ascii?q?BAQEBAQEBAwEBAQEBAQEchlaEf4QwDheEZwWNc4kXAYVBiBOBXEqDeYhbjkYBI?= =?us-ascii?q?AEBQoQKcoQWQ4EIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="scan'208";a="224873079" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jan 2016 00:06:46 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0706kdC004980 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Jan 2016 00:06:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 19:06:45 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 19:06:45 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-06.txt Thread-Index: AQHRSN9LvK/dhbEQiUuH16vaNFopsg== Date: Thu, 7 Jan 2016 00:06:45 +0000 Message-ID: References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> In-Reply-To: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.2.183] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0CC722825462AF4C867F1C7D1E7EFD6E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-06.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 00:06:49 -0000 We=B9ve submitted a revision of the TURN discovery draft that addresses comments raised at IETF-94. -Prashanth On 1/6/16, 4:02 PM, "tram on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the TURN Revised and Modernized Working >Group of the IETF. > > Title : TURN Server Auto Discovery > Authors : Prashanth Patil > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-tram-turn-server-discovery-06.txt > Pages : 15 > Date : 2016-01-06 > >Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control of > the application or TURN service provider, and not the enterprise, > ISP, or the network in which the client is located. Enterprises and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes three such mechanisms for > TURN server discovery. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-server-discovery-= 06 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Sun Jan 10 20:10:22 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B19A31A6FED; Sun, 10 Jan 2016 20:10:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111041019.31790.40878.idtracker@ietfa.amsl.com> Date: Sun, 10 Jan 2016 20:10:19 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turnbis-08.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 04:10:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-08.txt Pages : 80 Date : 2016-01-10 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 10 20:13:18 2016 Return-Path: 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 36A411A6FFB for ; Sun, 10 Jan 2016 20:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 bJtGvRwAbbn1 for ; Sun, 10 Jan 2016 20:13:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960DD1A6FF5 for ; Sun, 10 Jan 2016 20:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2639; q=dns/txt; s=iport; t=1452485595; x=1453695195; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=t1CWb1XnguKevWfuMUImeC2ivCbYLK2jJQo70W/OLhQ=; b=QE6oR6tQBR197TT+xHxDUgWR+OPof6/tUL8f7MuaP48K3+y+Gc4/77Go 3tOcQolzLy7Q99XcR1wMPsG0YGkOWKt4JaxxvBYekFIxt3ah0VK0grH5R fpfIUJFotgT06QH1KbbTjBRAsmYG6GNUYjsLH2l2IFCS4I0zaFk3Rm1mp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgC0KpNW/5hdJa1egzpSbQaIU7NbA?= =?us-ascii?q?Q2BZhgKhW0CgRg4FAEBAQEBAQF/C4Q0AQEBBAEBATc0FwQCAQgRBAEBHwkHJws?= =?us-ascii?q?UCQgCBBMIiCYOvloBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlaEf4k8BZcTAYVCi?= =?us-ascii?q?A+BZUqDeYhcjlABIAEBQoQKcoR+gQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,551,1444694400"; d="scan'208";a="62160856" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 04:13:14 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0B4DEYR016557 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2016 04:13:14 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 10 Jan 2016 22:13:14 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Sun, 10 Jan 2016 22:13:13 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-08.txt Thread-Index: AQHRTCYHn8QOFQ53YkGsvZA+hnUdtZ71tEag Date: Mon, 11 Jan 2016 04:13:13 +0000 Message-ID: <5a052640736642eab64118dcfb51381e@XCH-RCD-017.cisco.com> References: <20160111041019.31790.40878.idtracker@ietfa.amsl.com> In-Reply-To: <20160111041019.31790.40878.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.55.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-08.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 04:13:17 -0000 This revision addresses comments from Oleg. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, January 11, 2016 9:40 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-08.txt > Pages : 80 > Date : 2016-01-10 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jan 20 11:59:40 2016 Return-Path: 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 28DF01A02B1 for ; Wed, 20 Jan 2016 11:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 cpuGvF7PCXB3 for ; Wed, 20 Jan 2016 11:59:34 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB21A893C for ; Wed, 20 Jan 2016 11:59:34 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9BC8D3F403E; Wed, 20 Jan 2016 19:59:33 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 83C5D3F4034; Wed, 20 Jan 2016 19:59:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453319973; bh=Og7bYN7eZKynZ7HtEEgn4kqpvApUl6KWj3JYLaMCEaI=; l=4349; h=To:References:Cc:From:Date:In-Reply-To:From; b=RwDBcxSRBLDRj1yuavLy4s9gy28U8s9mShjxqlD7czArln/KdF2DVp43F6BmpIzpj a9XyKj8ijUdIrN6mA/wSY9W2z2Mi9tT/TDV0KeVL8YGdS5xxEH6p1Mia20KEWo01D6 E00gAsbo9raSZET+hUFD1E7+uXjkE54FEKv3FqjA= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 789962026; Wed, 20 Jan 2016 19:59:33 +0000 (GMT) To: Justin Uberti , Ted Hardie References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Brandon Williams Message-ID: <569FE725.7030104@akamai.com> Date: Wed, 20 Jan 2016 14:59:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Oleg Moskalenko , Alan Johnston , Martin Thomson , "tram@ietf.org" Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:59:38 -0000 I'm a bit late joining this thread, but nevertheless ... It seems to me that if the application knows the REALM that should be used for auth, it's a different use case than the one we're attempting to handle with the ORIGIN attribute. If I understand correctly, a core purpose for the ORIGIN attribute is to allow the relay to determine which authentication REALM to require from the client, which seems to imply that the client has multiple options and doesn't already know which one to use for this case. If the client already knows the REALM, why does it need to tell the server anything in the initial, unauthenticated allocation request? Or rather, why does the server need to tell it which REALM to use? The only purpose of that allocation request becomes receiving a NONCE value. --Brandon On 12/14/2015 02:36 PM, Justin Uberti wrote: > Exactly what Ted said. > > The difference between REALM/HOST and ORIGIN is that the application > needs to set REALM/HOST, but ORIGIN would be auto-set by the browser. > > The key outstanding question IMO is whether setting REALM properly is > actually useful, versus simply having the application include the domain > in USERNAME. Chrome uses REALM solely to compute HA1 and thereby > MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" realm ":" > SASLprep(password)), the benefit of using REALM would be that you can > use existing password databases that compute HA1 with username/realm > specified separately. However, I'd like someone who actually has to deal > with this sort of thing to weigh in. > > > > On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie > wrote: > > On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko > > wrote: > > In general case, how the user knows his realm ? He may not know it. > The user knows the name, the password, and the TURN server's IP > address or URL; knowing the realm is the TURN server's > responsibility. > > ​If I understood Justin's drift on this, the application needs to > know the realm, not the user. It could be set by the application > just as HOST would have been set. > > regards, > > Ted​ > > > And how transferring the realm in an open request is different from > transferring the ORIGIN ? Those are metadatas of the same nature. > > On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie > wrote: > > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti > > wrote: > >> > >> One possibly important point: USERNAME isn't sent in the > initial ALLOCATE. > >> If choosing a correct REALM on the server is important > (which was the > >> original justification for this work), we need to either > send USERNAME in > >> the initial ALLOCATE, or send up the preferred REALM. > >> > > > > I'm not seeing a downside to sending up the preferred REALM > in the initial > > allocate, other than it not re-using the known username@realm > convention. > > Am I missing something, or is it just spend the bytes and > call it done? > > > > regards, > > > > Ted > > > > > > > >> > >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson > > > >> wrote: > >>> > >>> On 14 December 2015 at 13:15, Justin Uberti > > wrote: > >>> > at that point we're basically coming up with a more > standard and > >>> > aesthetically pleasing way of doing what could already be > done with > >>> > USERNAME > >>> > (e.g. user@realm.com ) > >>> > >>> Yeah, my thoughts exactly. In that case it would possibly > be better > >>> to rely on an @domain convention for USERNAME and be done > with it. > >> > >> > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > > > From nobody Fri Jan 22 07:50:58 2016 Return-Path: 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 EFF291AD0AD for ; Fri, 22 Jan 2016 07:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iz6C-zHOyh-P for ; Fri, 22 Jan 2016 07:50:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AD01A1AD0AA for ; Fri, 22 Jan 2016 07:50:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DE468433423 for ; Fri, 22 Jan 2016 15:50:50 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BEAEB43341C for ; Fri, 22 Jan 2016 15:50:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453477850; bh=iQh1LKYuxvwZr1LmexhHMAN26pRZuoTaA9eshu9YiRE=; l=3947; h=To:References:From:Date:In-Reply-To:From; b=DObaIjQtZYD5+2IFmw0+aPfvwzw0KSTxzYE5Dk+j2ZS5qqc+4wZOuBoAkvdu28JAs uvjU3A9++UB4JTXHh9up/7rpZv8vqzZdhcqqtC1KDcO+8Um5+eSzsN3IIogHW1/sES G087oQeeUl7e576MvBAP0Ite7tk65hZuMi+UsoYo= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B8A26202C for ; Fri, 22 Jan 2016 15:50:50 +0000 (GMT) To: tram@ietf.org References: <20151108043622.19002.79331.idtracker@ietfa.amsl.com> From: Brandon Williams Message-ID: <56A24FDA.9000806@akamai.com> Date: Fri, 22 Jan 2016 10:50:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151108043622.19002.79331.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 15:50:56 -0000 I've got a couple of comments on the current version of the draft. s3.1.2 The current text has some discussion of path MTU and STUN message size restrictions that relates to requirements that I think we have previously decided to relax. If my memory is correct, we decided in Dallas to allow request/response messages to assume reasonable path MTU values (rather than the IPv4 minimum), so we might want to avoid reiterating limiting guidance from RFC5389. I can't find reference to this decision in the meeting minutes from Dallas, though, so maybe I'm mistaken. Nevertheless, it's probably better to just mention that you can't assume MTUs are the same and point to RFC5389 for further guidance, rather than repeating requirements language. s3.2.2 A common use case for mobility will likely be what some have described as the "walk out the door" problem. Two interfaces are functional (e.g. both wifi and lte) and you want to seamlessly switch from one to the other. You probably want to be able to use both interfaces at the same time while you're figuring out whether/when to switch from one to the other (make before break). I don't think the current text supports this, since it indicates that 1) the tuple for the allocation should be updated and 2) the old ticket can only be used for retransmission. If I'm misunderstanding the intent of the text, then it would be helpful to see some explicit discussion of this use case. Finally (same section), while I can see the value of maintaining the existing allocation when switching between interfaces/addresses, sticking to that relay server could be a bad idea if there are other/better options for the new address. To support make before break in this case, I think it would be useful for the relay server to be able to send an ALTERNATE-SERVER attribute in its Refresh response message. IOW, allow the client to continue using the new allocation, but also let it know that a different/better relay is available for that address. There would likely be some ICE work associated with supporting such an option, so maybe it belongs in a separate more-general doc since turn-mobility is useful without it, but it seemed worth bringing up in this context. --Brandon On 11/07/2015 11:36 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. > > Title : Mobility with TURN > Authors : Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Paal-Erik Martinsen > Filename : draft-ietf-tram-turn-mobility-00.txt > Pages : 11 > Date : 2015-11-07 > > Abstract: > It is desirable to minimize traffic disruption caused by changing IP > address during a mobility event. One mechanism to minimize > disruption is to expose a shorter network path to the mobility event > so only the local network elements are aware of the changed IP > address but the remote peer is unaware of the changed IP address. > > This draft provides such an IP address mobility solution using > Traversal Using Relays around NAT (TURN). This is achieved by > allowing a client to retain an allocation on the TURN server when the > IP address of the client changes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Fri Jan 22 13:55:08 2016 Return-Path: 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 9F1761A8A4F for ; Fri, 22 Jan 2016 13:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 6fx8Ht7a7nBI for ; Fri, 22 Jan 2016 13:55:04 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 EA1291A8A4E for ; Fri, 22 Jan 2016 13:55:03 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id k1so48464216vkb.2 for ; Fri, 22 Jan 2016 13:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M8mAFI+h1wg4YxFTFP3Ff9kywRBVuCZoNhSzEkIWCvg=; b=cGPsYXNyEw4cO1dnCYJ2abFmaZKAv4bze19o68PkRPbcAYi/ZAGPNU8gNysZbn0h4D VqH9g7Uy0pzDRzCS3Hpu3TaBIaOQU2wSL+UsdOmFTbIEj6jQena+dzsnNU3cOb9kvMcI mO5OnEfAlfD9XHXkFMur4+DHkQdzAWbloCkaDA7mXs6p2UUndksAD6A+BEFEyw7mzDwy aBZrI/DY4WdMlgIDONLugcEcLxBXaR79U2yqNxeKckR1BpQCJnR/FZG6ORugnwEjnjwA P8d0VGQOUX7wChT1nu43VGW1vlgfwR3+pni+23NH5iFk1BpNBmF3xu9nS1i07t1a2XSY Yc3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M8mAFI+h1wg4YxFTFP3Ff9kywRBVuCZoNhSzEkIWCvg=; b=kehXZoAmLJSjs6k9pi6zL//sc+dKzrK9cAq/5ogN+LK0Lu53tL8Tpmn7lZPChqPHii ab94tNoYVNFOMwSI9HWyJ4lKXr8WhASfiPsyk3GHwEWS/kzvXdVxCK0c5Rcog9/DtrCR +omIwXJ/GYwyoSO3vInfuAcZGNSn6UQhpZFKJ5FsnGmyVz31YtJg9lisj7DwgSKXrC28 TQSXSimN8Ec9Q4lLIdwtU00qZ7UHEsOxt3mJMDNQtm8KZjST+X8/T3KcDrIyjRb7cudw 3xmZrkSU1WAJ29i3RjN+zlsYJMQjmbdUlemvtEic1BA4lA4PEbIcpDjRRDFtxDrLe8l2 GxhQ== X-Gm-Message-State: AG10YOQE25jOfy28cv5PV1yRpgkJ5z51S6uFHtBbW2IRT3lsnNvQ6sybV9wf6mxerGJ7A3PN2KTFemj7vqPkcKj9 X-Received: by 10.31.54.149 with SMTP id d143mr3413423vka.111.1453499702908; Fri, 22 Jan 2016 13:55:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Fri, 22 Jan 2016 13:54:43 -0800 (PST) In-Reply-To: <569FE725.7030104@akamai.com> References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> <569FE725.7030104@akamai.com> From: Justin Uberti Date: Fri, 22 Jan 2016 13:54:43 -0800 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=001a1143901a795cd20529f3458c Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 21:55:06 -0000 --001a1143901a795cd20529f3458c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The client can only use the REALM that the server gives it. If the server is multi-tenant, and only stores password hashes, then it's imperative that the client uses the same realm as was used to compute the hash. On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > I'm a bit late joining this thread, but nevertheless ... > > It seems to me that if the application knows the REALM that should be use= d > for auth, it's a different use case than the one we're attempting to hand= le > with the ORIGIN attribute. If I understand correctly, a core purpose for > the ORIGIN attribute is to allow the relay to determine which > authentication REALM to require from the client, which seems to imply tha= t > the client has multiple options and doesn't already know which one to use > for this case. If the client already knows the REALM, why does it need to > tell the server anything in the initial, unauthenticated allocation > request? Or rather, why does the server need to tell it which REALM to us= e? > The only purpose of that allocation request becomes receiving a NONCE val= ue. > > --Brandon > > > On 12/14/2015 02:36 PM, Justin Uberti wrote: > >> Exactly what Ted said. >> >> The difference between REALM/HOST and ORIGIN is that the application >> needs to set REALM/HOST, but ORIGIN would be auto-set by the browser. >> >> The key outstanding question IMO is whether setting REALM properly is >> actually useful, versus simply having the application include the domain >> in USERNAME. Chrome uses REALM solely to compute HA1 and thereby >> MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" realm ":" >> SASLprep(password)), the benefit of using REALM would be that you can >> use existing password databases that compute HA1 with username/realm >> specified separately. However, I'd like someone who actually has to deal >> with this sort of thing to weigh in. >> >> >> >> On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie > > wrote: >> >> On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko >> > wrote: >> >> In general case, how the user knows his realm ? He may not know >> it. >> The user knows the name, the password, and the TURN server's IP >> address or URL; knowing the realm is the TURN server's >> responsibility. >> >> =E2=80=8BIf I understood Justin's drift on this, the application nee= ds to >> know the realm, not the user. It could be set by the application >> just as HOST would have been set. >> >> regards, >> >> Ted=E2=80=8B >> >> >> And how transferring the realm in an open request is different >> from >> transferring the ORIGIN ? Those are metadatas of the same nature= . >> >> On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie > > wrote: >> > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti >> > wrote: >> >> >> >> One possibly important point: USERNAME isn't sent in the >> initial ALLOCATE. >> >> If choosing a correct REALM on the server is important >> (which was the >> >> original justification for this work), we need to either >> send USERNAME in >> >> the initial ALLOCATE, or send up the preferred REALM. >> >> >> > >> > I'm not seeing a downside to sending up the preferred REALM >> in the initial >> > allocate, other than it not re-using the known username@realm >> convention. >> > Am I missing something, or is it just spend the bytes and >> call it done? >> > >> > regards, >> > >> > Ted >> > >> > >> > >> >> >> >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson >> > >> >> wrote: >> >>> >> >>> On 14 December 2015 at 13:15, Justin Uberti >> > wrote: >> >>> > at that point we're basically coming up with a more >> standard and >> >>> > aesthetically pleasing way of doing what could already be >> done with >> >>> > USERNAME >> >>> > (e.g. user@realm.com ) >> >>> >> >>> Yeah, my thoughts exactly. In that case it would possibly >> be better >> >>> to rely on an @domain convention for USERNAME and be done >> with it. >> >> >> >> >> > >> > >> > _______________________________________________ >> > tram mailing list >> > tram@ietf.org >> > https://www.ietf.org/mailman/listinfo/tram >> < >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRI= uadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3D86SFKZkjNvPDRvmAnJfKfxEY9UdfXAj-Gdyipyp7PA= 0&s=3D3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM&e=3D >> > >> > >> >> >> >> > --001a1143901a795cd20529f3458c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The client can only use the REALM that the server gives it= . If the server is multi-tenant, and only stores password hashes, then it&#= 39;s imperative that the client uses the same realm as was used to compute = the hash.

On= Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams <brandon.willia= ms@akamai.com> wrote:
I'= ;m a bit late joining this thread, but nevertheless ...

It seems to me that if the application knows the REALM that should be used = for auth, it's a different use case than the one we're attempting t= o handle with the ORIGIN attribute. If I understand correctly, a core purpo= se for the ORIGIN attribute is to allow the relay to determine which authen= tication REALM to require from the client, which seems to imply that the cl= ient has multiple options and doesn't already know which one to use for= this case. If the client already knows the REALM, why does it need to tell= the server anything in the initial, unauthenticated allocation request? Or= rather, why does the server need to tell it which REALM to use? The only p= urpose of that allocation request becomes receiving a NONCE value.

--Brandon


On 12/14/2015 02:36 PM, Justin Uberti wrote:
Exactly what Ted said.

The difference between REALM/HOST and ORIGIN is that the application
needs to set REALM/HOST, but ORIGIN would be auto-set by the browser.

The key outstanding question IMO is whether setting REALM properly is
actually useful, versus simply having the application include the domain in USERNAME. Chrome uses REALM solely to compute HA1 and thereby
MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" realm= ":"
SASLprep(password)), the benefit of using REALM would be that you can
use existing password databases that compute HA1 with username/realm
specified separately. However, I'd like someone who actually has to dea= l
with this sort of thing to weigh in.



On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie <ted.ietf@gmail.com
 <mailto:ted.ietf= @gmail.com>> wrote:

=C2=A0 =C2=A0 On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko
<= span class=3D""> =C2=A0 =C2=A0 <= mom040267@gmail.com <mailto:mom040267@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In general case, how the user knows his realm ?= He may not know it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The user knows the name, the password, and the = TURN server's IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 address or URL; knowing the realm is the TURN s= erver's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 responsibility.

=C2=A0 =C2=A0 =E2=80=8BIf I understood Justin's drift on this, the appl= ication needs to
=C2=A0 =C2=A0 know the realm, not the user.=C2=A0 It could be set by the ap= plication
=C2=A0 =C2=A0 just as HOST would have been set.

=C2=A0 =C2=A0 regards,

=C2=A0 =C2=A0 Ted=E2=80=8B


=C2=A0 =C2=A0 =C2=A0 =C2=A0 And how transferring the realm in an open reque= st is different from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transferring the ORIGIN ? Those are metadatas o= f the same nature.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie &l= t;ted.ietf@gmail.co= m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Sun, Dec 13, 2015 at 8:25 PM, Jus= tin Uberti
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <juberti@google.com <mailto:juberti@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> One possibly important point: US= ERNAME isn't sent in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 initial ALLOCATE.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> If choosing a correct REALM on t= he server is important
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (which was the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> original justification for this = work), we need to either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 send USERNAME in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> the initial ALLOCATE, or send up= the preferred REALM.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I'm not seeing a downside to sen= ding up the preferred REALM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in the initial
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> allocate, other than it not re-using= the known username@realm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 convention.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Am I missing something, or is it jus= t spend the bytes and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 call it done?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Ted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> On Sun, Dec 13, 2015 at 6:48 PM,= Martin Thomson
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com&= gt;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> On 14 December 2015 at 13:15= , Justin Uberti
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <juberti@google.com <mailto:juberti@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> > at that point we're= basically coming up with a more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standard and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> > aesthetically pleasing = way of doing what could already be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 done with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> > USERNAME
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> > (e.g. user@realm.com <mailto:user@realm.com>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Yeah, my thoughts exactly.= =C2=A0 In that case it would possibly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be better
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> to rely on an @domain conven= tion for USERNAME and be done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____________________________________= ___________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> tram mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> tram@ietf.org <mailto:tram@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> https://www.ietf.or= g/mailman/listinfo/tram
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3D86SFKZkjNvPDRvmAnJfK= fxEY9UdfXAj-Gdyipyp7PA0&s=3D3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM= &e=3D>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>





--001a1143901a795cd20529f3458c-- From nobody Mon Jan 25 09:25:06 2016 Return-Path: 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 D62A21B322D for ; Mon, 25 Jan 2016 09:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DHB7WEp0nfrJ for ; Mon, 25 Jan 2016 09:25:01 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8742F1B3145 for ; Mon, 25 Jan 2016 09:25:01 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DB058433404; Mon, 25 Jan 2016 17:25:00 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C49F6433403; Mon, 25 Jan 2016 17:25:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453742700; bh=2QCwrvJ3TqCN5VKLeePfHKnvzFUYXmZnCBzsWNuV9ro=; l=6440; h=To:References:Cc:From:Date:In-Reply-To:From; b=yuFFxC92W60ASct/QrpPbTY3Ie3ItgzojjRwbX8DiKKG537cY/mhLqN6OT62h57DM eaDKGAh0QFvbrPj3FX2Th7lx/4ggUr5e7Ab8dhPLRcfXcsBiBfWv3mehoJ5V82A9qS e3qcOON0thhEyfy78K5fofKuW1w4pKme6tR0gL3M= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BC02C202A; Mon, 25 Jan 2016 17:25:00 +0000 (GMT) To: Justin Uberti References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> <569FE725.7030104@akamai.com> From: Brandon Williams Message-ID: <56A65A6C.6090903@akamai.com> Date: Mon, 25 Jan 2016 12:25:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:25:05 -0000 Sure, the client can only use the REALM the server gives it. I know that. But the suggestion in the thread seems to be that the client would dictate to the server what the REALM is, not the other way around. If the client sends ORIGIN or HOST, it's effectively asking to know what REALM to use. If it sends REALM, it's asking a somewhat different question (is this REALM value OK?). If the service is available for multiple HOST values with a different REALM on each, then HOST really must be sent. There are other use cases that REALM could apply to. I'm just not sure it can be used as a replacement for ORIGIN. I think HOST works better for that. Or was the suggestion that both HOST and REALM would be sent together? --Brandon On 01/22/2016 04:54 PM, Justin Uberti wrote: > The client can only use the REALM that the server gives it. If the > server is multi-tenant, and only stores password hashes, then it's > imperative that the client uses the same realm as was used to compute > the hash. > > On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams > > wrote: > > I'm a bit late joining this thread, but nevertheless ... > > It seems to me that if the application knows the REALM that should > be used for auth, it's a different use case than the one we're > attempting to handle with the ORIGIN attribute. If I understand > correctly, a core purpose for the ORIGIN attribute is to allow the > relay to determine which authentication REALM to require from the > client, which seems to imply that the client has multiple options > and doesn't already know which one to use for this case. If the > client already knows the REALM, why does it need to tell the server > anything in the initial, unauthenticated allocation request? Or > rather, why does the server need to tell it which REALM to use? The > only purpose of that allocation request becomes receiving a NONCE value. > > --Brandon > > > On 12/14/2015 02:36 PM, Justin Uberti wrote: > > Exactly what Ted said. > > The difference between REALM/HOST and ORIGIN is that the application > needs to set REALM/HOST, but ORIGIN would be auto-set by the > browser. > > The key outstanding question IMO is whether setting REALM > properly is > actually useful, versus simply having the application include > the domain > in USERNAME. Chrome uses REALM solely to compute HA1 and thereby > MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" > realm ":" > SASLprep(password)), the benefit of using REALM would be that > you can > use existing password databases that compute HA1 with username/realm > specified separately. However, I'd like someone who actually has > to deal > with this sort of thing to weigh in. > > > > On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie > >> wrote: > > On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko > > >> wrote: > > In general case, how the user knows his realm ? He may > not know it. > The user knows the name, the password, and the TURN > server's IP > address or URL; knowing the realm is the TURN server's > responsibility. > > ​If I understood Justin's drift on this, the application > needs to > know the realm, not the user. It could be set by the > application > just as HOST would have been set. > > regards, > > Ted​ > > > And how transferring the realm in an open request is > different from > transferring the ORIGIN ? Those are metadatas of the > same nature. > > On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie > > >> wrote: > > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti > > >> wrote: > >> > >> One possibly important point: USERNAME isn't sent > in the > initial ALLOCATE. > >> If choosing a correct REALM on the server is important > (which was the > >> original justification for this work), we need to > either > send USERNAME in > >> the initial ALLOCATE, or send up the preferred REALM. > >> > > > > I'm not seeing a downside to sending up the > preferred REALM > in the initial > > allocate, other than it not re-using the known > username@realm > convention. > > Am I missing something, or is it just spend the > bytes and > call it done? > > > > regards, > > > > Ted > > > > > > > >> > >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson > > >> > >> wrote: > >>> > >>> On 14 December 2015 at 13:15, Justin Uberti > > >> wrote: > >>> > at that point we're basically coming up with a more > standard and > >>> > aesthetically pleasing way of doing what could > already be > done with > >>> > USERNAME > >>> > (e.g. user@realm.com > >) > >>> > >>> Yeah, my thoughts exactly. In that case it would > possibly > be better > >>> to rely on an @domain convention for USERNAME and > be done > with it. > >> > >> > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Tue Jan 26 09:20:16 2016 Return-Path: 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 D80971A9083 for ; Tue, 26 Jan 2016 09:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 0qHPTgVdVOQI for ; Tue, 26 Jan 2016 09:20:09 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 6A7DE1A905F for ; Tue, 26 Jan 2016 09:20:09 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id n1so95650911vkb.3 for ; Tue, 26 Jan 2016 09:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M7KiFuycZGZ9GaEmLCF/hU/Cf5CNqMDPLPYiSiawRD0=; b=iHqRRDOO9eQVPwZvszZ4aKB7tkkSlF6LkV1NDssaLEGAqRSvgqOpexJVjJqiX8AgqI 08T0ZH1kjgtStfkM0ZOqasKCLWHXCRRN9kWdPA9BikJ38som7eVnI3xX75aJL3VT/TlA 7Nemasz+++UR+NEevgcTLJkJsPEUiP4v42VxIN+DVliBGHNfYiqnjzRdiJFTUn+fxZht HQXP/f2lM+U5MyQiOq0yEFRACat4f0wEkgB3EG6AbxXGv0EoLo8voBtddv1ZtDtNsGAR EJmM5qKAKDG6Gpw0IjGGsptj6NKgQu610fbDK62RkEpsaO7/pXKun8w0xoFbt4mXjDYp 5tTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M7KiFuycZGZ9GaEmLCF/hU/Cf5CNqMDPLPYiSiawRD0=; b=gDj/GW3UcxRRWMHBOoX4dgmReuODmwsnxU+0wld7uLenO4898ZbvRPzlgDPY+OHHne P2v9QzTmXhcTlFpbvQVvVVyrjr88A7UIW45izezNlFIcmqxTy11/z2pWSd5ZSVEYUCsJ x+mkBQbLmCrHRHMyNL2x60eKGQM2XaWVN2ASNp0nTKVLCnSnOIaunqHlupH7YKqFM5Ur sXRWBh/5bfSBqaZy+fHF3TTT1Un5UFW7OmVU8D71mazuam2TR6qkbGXy6sJXFcrD99dO b3h8sH/pUzOdmmWSyikS6DNDORoycc9f/3N9Oem9Ny0THVukwq7trdKuLfhBibn8u8pP dO6Q== X-Gm-Message-State: AG10YOQVlbnp7uPU1b2vt/I6IObobIIr28/TweGui29QyB46Idww8uds8mtPb4sl/0G0CWOqhX9ZQdtLgNCs9pkh X-Received: by 10.31.58.139 with SMTP id h133mr15088626vka.158.1453828808428; Tue, 26 Jan 2016 09:20:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Tue, 26 Jan 2016 09:19:48 -0800 (PST) In-Reply-To: <56A65A6C.6090903@akamai.com> References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> <569FE725.7030104@akamai.com> <56A65A6C.6090903@akamai.com> From: Justin Uberti Date: Tue, 26 Jan 2016 09:19:48 -0800 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=001a11434d8cb12201052a3fe5e0 Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:20:13 -0000 --001a11434d8cb12201052a3fe5e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm... I'm not exactly sure what you are proposing. At this point the only thing that we are trying to do is to ensure proper REALM selection in a multi-tenant case. This could be done multiple ways: a) REALM from the client (potentially different from HOST), server either mirrors this or returns an error (requires new web API) b) HOST from the client, triggering corresponding REALM from server (no new APIs) c) user@realm in USERNAME from client, server either mirrors realm part or returns an error (no new APIs or protocol, but has implications on how pw db is set up) c) is obviously the least work, followed by b) and then a). What do you prefer? On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > Sure, the client can only use the REALM the server gives it. I know that. > But the suggestion in the thread seems to be that the client would dictat= e > to the server what the REALM is, not the other way around. > > If the client sends ORIGIN or HOST, it's effectively asking to know what > REALM to use. If it sends REALM, it's asking a somewhat different questio= n > (is this REALM value OK?). If the service is available for multiple HOST > values with a different REALM on each, then HOST really must be sent. The= re > are other use cases that REALM could apply to. I'm just not sure it can b= e > used as a replacement for ORIGIN. I think HOST works better for that. > > Or was the suggestion that both HOST and REALM would be sent together? > > --Brandon > > On 01/22/2016 04:54 PM, Justin Uberti wrote: > >> The client can only use the REALM that the server gives it. If the >> server is multi-tenant, and only stores password hashes, then it's >> imperative that the client uses the same realm as was used to compute >> the hash. >> >> On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams >> > wrote= : >> >> I'm a bit late joining this thread, but nevertheless ... >> >> It seems to me that if the application knows the REALM that should >> be used for auth, it's a different use case than the one we're >> attempting to handle with the ORIGIN attribute. If I understand >> correctly, a core purpose for the ORIGIN attribute is to allow the >> relay to determine which authentication REALM to require from the >> client, which seems to imply that the client has multiple options >> and doesn't already know which one to use for this case. If the >> client already knows the REALM, why does it need to tell the server >> anything in the initial, unauthenticated allocation request? Or >> rather, why does the server need to tell it which REALM to use? The >> only purpose of that allocation request becomes receiving a NONCE >> value. >> >> --Brandon >> >> >> On 12/14/2015 02:36 PM, Justin Uberti wrote: >> >> Exactly what Ted said. >> >> The difference between REALM/HOST and ORIGIN is that the >> application >> needs to set REALM/HOST, but ORIGIN would be auto-set by the >> browser. >> >> The key outstanding question IMO is whether setting REALM >> properly is >> actually useful, versus simply having the application include >> the domain >> in USERNAME. Chrome uses REALM solely to compute HA1 and thereby >> MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" >> realm ":" >> SASLprep(password)), the benefit of using REALM would be that >> you can >> use existing password databases that compute HA1 with >> username/realm >> specified separately. However, I'd like someone who actually has >> to deal >> with this sort of thing to weigh in. >> >> >> >> On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie > >> >> wrote: >> >> On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko >> >> >> wrote= : >> >> In general case, how the user knows his realm ? He may >> not know it. >> The user knows the name, the password, and the TURN >> server's IP >> address or URL; knowing the realm is the TURN server's >> responsibility. >> >> =E2=80=8BIf I understood Justin's drift on this, the applic= ation >> needs to >> know the realm, not the user. It could be set by the >> application >> just as HOST would have been set. >> >> regards, >> >> Ted=E2=80=8B >> >> >> And how transferring the realm in an open request is >> different from >> transferring the ORIGIN ? Those are metadatas of the >> same nature. >> >> On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie >> >> > >> wrote: >> > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti >> >> >> wrote: >> >> >> >> One possibly important point: USERNAME isn't sent >> in the >> initial ALLOCATE. >> >> If choosing a correct REALM on the server is >> important >> (which was the >> >> original justification for this work), we need to >> either >> send USERNAME in >> >> the initial ALLOCATE, or send up the preferred REAL= M. >> >> >> > >> > I'm not seeing a downside to sending up the >> preferred REALM >> in the initial >> > allocate, other than it not re-using the known >> username@realm >> convention. >> > Am I missing something, or is it just spend the >> bytes and >> call it done? >> > >> > regards, >> > >> > Ted >> > >> > >> > >> >> >> >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson >> > >> > >>> >> >> wrote: >> >>> >> >>> On 14 December 2015 at 13:15, Justin Uberti >> >> >> wrote: >> >>> > at that point we're basically coming up with a >> more >> standard and >> >>> > aesthetically pleasing way of doing what could >> already be >> done with >> >>> > USERNAME >> >>> > (e.g. user@realm.com >> >) >> >>> >> >>> Yeah, my thoughts exactly. In that case it would >> possibly >> be better >> >>> to rely on an @domain convention for USERNAME and >> be done >> with it. >> >> >> >> >> > >> > >> > _______________________________________________ >> > tram mailing list >> > tram@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/tram >> < >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRI= uadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3DbstRUIB98hwOaulLxlErjpDk9i6GF9JdckvEC2nW_1= A&s=3DebOlAsUznfzVZZWlbNMG-Txv4xWvwe9wcDJp2fcpI8E&e=3D >> > >> >> < >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRI= uadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3D86SFKZkjNvPDRvmAnJfKfxEY9UdfXAj-Gdyipyp7PA= 0&s=3D3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM&e=3D >> > >> > >> >> >> >> >> >> > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. > --001a11434d8cb12201052a3fe5e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm... I'm not exactly sure what you are proposing.
At this point the only thing that we are trying to do is t= o ensure proper REALM selection in a multi-tenant case. This could be done = multiple ways:
a) REALM from the client (potentially different fr= om HOST), server either mirrors this or returns an error (requires new web = API)
b) HOST from the client, triggering corresponding REALM = from server (no new APIs)
c) user@realm in USERNAME from client, = server either mirrors realm part or returns an error (no new APIs or protoc= ol, but has implications on how pw db is set up)

c= ) is obviously the least work, followed by b) and then a).

What do you prefer?

On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams <brandon.williams@akamai.com> wrote:
Sure, the client can only use the REALM the server giv= es it. I know that. But the suggestion in the thread seems to be that the c= lient would dictate to the server what the REALM is, not the other way arou= nd.

If the client sends ORIGIN or HOST, it's effectively asking to know wha= t REALM to use. If it sends REALM, it's asking a somewhat different que= stion (is this REALM value OK?). If the service is available for multiple H= OST values with a different REALM on each, then HOST really must be sent. T= here are other use cases that REALM could apply to. I'm just not sure i= t can be used as a replacement for ORIGIN. I think HOST works better for th= at.

Or was the suggestion that both HOST and REALM would be sent together?

--Brandon

On 01/22/2016 04:54 PM, Justin Uberti wrote:
The client can only use the REALM that the server gives it. If the
server is multi-tenant, and only stores password hashes, then it's
imperative that the client uses the same realm as was used to compute
the hash.

On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams
<brando= n.williams@akamai.com <mailto:brandon.williams@akamai.com>> wrote:
=C2=A0 =C2=A0 I'm a bit late joining this thread, but nevertheless ...<= br>
=C2=A0 =C2=A0 It seems to me that if the application knows the REALM that s= hould
=C2=A0 =C2=A0 be used for auth, it's a different use case than the one = we're
=C2=A0 =C2=A0 attempting to handle with the ORIGIN attribute. If I understa= nd
=C2=A0 =C2=A0 correctly, a core purpose for the ORIGIN attribute is to allo= w the
=C2=A0 =C2=A0 relay to determine which authentication REALM to require from= the
=C2=A0 =C2=A0 client, which seems to imply that the client has multiple opt= ions
=C2=A0 =C2=A0 and doesn't already know which one to use for this case. = If the
=C2=A0 =C2=A0 client already knows the REALM, why does it need to tell the = server
=C2=A0 =C2=A0 anything in the initial, unauthenticated allocation request? = Or
=C2=A0 =C2=A0 rather, why does the server need to tell it which REALM to us= e? The
=C2=A0 =C2=A0 only purpose of that allocation request becomes receiving a N= ONCE value.

=C2=A0 =C2=A0 --Brandon


=C2=A0 =C2=A0 On 12/14/2015 02:36 PM, Justin Uberti wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Exactly what Ted said.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The difference between REALM/HOST and ORIGIN is= that the application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 needs to set REALM/HOST, but ORIGIN would be au= to-set by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 browser.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The key outstanding question IMO is whether set= ting REALM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 properly is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 actually useful, versus simply having the appli= cation include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the domain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in USERNAME. Chrome uses REALM solely to comput= e HA1 and thereby
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MESSAGE-INTEGRITY; since HA1 is defined as MD5(= username ":"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 realm ":"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SASLprep(password)), the benefit of using REALM= would be that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use existing password databases that compute HA= 1 with username/realm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 specified separately. However, I'd like som= eone who actually has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to deal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with this sort of thing to weigh in.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie &l= t;ted.ietf@gmail.co= m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>>> wrote= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Dec 14, 2015 at 11:= 02 AM, Oleg Moskalenko
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mom040267@gmail.com <mailto:mom040267@gmail.com&= gt;
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mom040267@gmail.com <mailto:mom040267@gmail.com>>> w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In general ca= se, how the user knows his realm ? He may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not know it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The user know= s the name, the password, and the TURN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server's IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0address or UR= L; knowing the realm is the TURN server's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0responsibilit= y.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=8BIf I understood Ju= stin's drift on this, the application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0know the realm, not the use= r.=C2=A0 It could be set by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0just as HOST would have bee= n set.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ted=E2=80=8B


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0And how trans= ferring the realm in an open request is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 different from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transferring = the ORIGIN ? Those are metadatas of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 same nature.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Dec 1= 4, 2015 at 10:55 AM, Ted Hardie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ted.ietf@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com>>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Sun,= Dec 13, 2015 at 8:25 PM, Justin Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<juberti@google.com <= ;mailto:juberti@goo= gle.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com <mailto:juberti@google.com>>> wrote= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> One= possibly important point: USERNAME isn't sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0initial ALLOC= ATE.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> If = choosing a correct REALM on the server is important
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(which was th= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> ori= ginal justification for this work), we need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0send USERNAME= in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> the= initial ALLOCATE, or send up the preferred REALM.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I'm= not seeing a downside to sending up the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 preferred REALM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the initia= l
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > allocat= e, other than it not re-using the known
=C2=A0 =C2=A0 =C2=A0 =C2=A0 username@realm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0convention. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Am I mi= ssing something, or is it just spend the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bytes and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0call it done?=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > regards= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Ted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> On = Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<martin.thomson@gmail= .com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com <mailto:martin.thomson@gmail= .com>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> wro= te:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= On 14 December 2015 at 13:15, Justin Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<juberti@google.com <= ;mailto:juberti@goo= gle.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com <mailto:juberti@google.com>>> wrote= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= > at that point we're basically coming up with a more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standard and<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= > aesthetically pleasing way of doing what could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 already be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0done with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= > USERNAME
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= > (e.g. user@realm.= com <mailto:user= @realm.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:user@realm.com <mailto:user@realm.com>>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= Yeah, my thoughts exactly.=C2=A0 In that case it would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 possibly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>= to rely on an @domain convention for USERNAME and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > _______= ________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > tram ma= iling list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > tram@ietf.org <mailto:tram@ietf.org>
<= /span> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tram@ietf.org <mailto:tram@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/tram
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3DbstRUIB98hwOaulLxlEr= jpDk9i6GF9JdckvEC2nW_1A&s=3DebOlAsUznfzVZZWlbNMG-Txv4xWvwe9wcDJp2fcpI8E= &e=3D>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3D86SFKZkjNvPDRvmAnJfK= fxEY9UdfXAj-Gdyipyp7PA0&s=3D3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM= &e=3D>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >






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

--001a11434d8cb12201052a3fe5e0-- From nobody Tue Jan 26 11:23:23 2016 Return-Path: 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 5B30C1B2B85 for ; Tue, 26 Jan 2016 11:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 RdMqkUtX0qfQ for ; Tue, 26 Jan 2016 11:23:19 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1D88B1B2BD4 for ; Tue, 26 Jan 2016 11:23:17 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 43C923F402A; Tue, 26 Jan 2016 19:23:17 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2CEF73F4020; Tue, 26 Jan 2016 19:23:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453836197; bh=rI0NwWuaxElrmipS7B56HDlR9eO0kAM+hT/PpllRzfc=; l=9452; h=To:References:Cc:From:Date:In-Reply-To:From; b=OE0xZbjQZscT3Vas+mUtor8LTJVa2qgLAd9Aavh96D4RHmc15TXRvz56PkFhvbxPG lRXwM089/MjLTi9Gf1Zk7RCuctyJGg7dcKSiMoTrsB6lRa8DMRclQdutoRE3bIlhu4 p7hidkjp918oAOakcCqhPqvHwUap8VKCqJUtcfC8= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2277B2030; Tue, 26 Jan 2016 19:23:17 +0000 (GMT) To: Justin Uberti References: <569FE725.7030104@akamai.com> <56A65A6C.6090903@akamai.com> From: Brandon Williams Message-ID: <56A7C7A5.4090407@akamai.com> Date: Tue, 26 Jan 2016 14:23:17 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:23:22 -0000 The thread seemed to be discussing REALM and HOST as interchangeable, so I thought I might be missing something. Your list of options indicates the same difference I was seeing in terms of the server side behavior. I'm interested in possible use cases for 3rd party auth. In that case, USERNAME already has a purpose (it contains the kid value). I think that kid@realm could work, but I haven't fully thought it through. a and b seem to map more directly to a 3rd party auth use case. On a sparate note, b seems to cover more use cases than a/c, since it handles both the case where the client knows the realm ahead of time and the case where it needs to be told by the relay. IOW, if we go with just one, HOST seems the better choice to me. --Brandon On 01/26/2016 12:19 PM, Justin Uberti wrote: > Hmm... I'm not exactly sure what you are proposing. > > At this point the only thing that we are trying to do is to ensure > proper REALM selection in a multi-tenant case. This could be done > multiple ways: > a) REALM from the client (potentially different from HOST), server > either mirrors this or returns an error (requires new web API) > b) HOST from the client, triggering corresponding REALM from server (no > new APIs) > c) user@realm in USERNAME from client, server either mirrors realm part > or returns an error (no new APIs or protocol, but has implications on > how pw db is set up) > > c) is obviously the least work, followed by b) and then a). > > What do you prefer? > > On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams > > wrote: > > Sure, the client can only use the REALM the server gives it. I know > that. But the suggestion in the thread seems to be that the client > would dictate to the server what the REALM is, not the other way around. > > If the client sends ORIGIN or HOST, it's effectively asking to know > what REALM to use. If it sends REALM, it's asking a somewhat > different question (is this REALM value OK?). If the service is > available for multiple HOST values with a different REALM on each, > then HOST really must be sent. There are other use cases that REALM > could apply to. I'm just not sure it can be used as a replacement > for ORIGIN. I think HOST works better for that. > > Or was the suggestion that both HOST and REALM would be sent together? > > --Brandon > > On 01/22/2016 04:54 PM, Justin Uberti wrote: > > The client can only use the REALM that the server gives it. If the > server is multi-tenant, and only stores password hashes, then it's > imperative that the client uses the same realm as was used to > compute > the hash. > > On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams > > >> wrote: > > I'm a bit late joining this thread, but nevertheless ... > > It seems to me that if the application knows the REALM that > should > be used for auth, it's a different use case than the one we're > attempting to handle with the ORIGIN attribute. If I understand > correctly, a core purpose for the ORIGIN attribute is to > allow the > relay to determine which authentication REALM to require > from the > client, which seems to imply that the client has multiple > options > and doesn't already know which one to use for this case. If the > client already knows the REALM, why does it need to tell > the server > anything in the initial, unauthenticated allocation request? Or > rather, why does the server need to tell it which REALM to > use? The > only purpose of that allocation request becomes receiving a > NONCE value. > > --Brandon > > > On 12/14/2015 02:36 PM, Justin Uberti wrote: > > Exactly what Ted said. > > The difference between REALM/HOST and ORIGIN is that > the application > needs to set REALM/HOST, but ORIGIN would be auto-set > by the > browser. > > The key outstanding question IMO is whether setting REALM > properly is > actually useful, versus simply having the application > include > the domain > in USERNAME. Chrome uses REALM solely to compute HA1 > and thereby > MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" > realm ":" > SASLprep(password)), the benefit of using REALM would > be that > you can > use existing password databases that compute HA1 with > username/realm > specified separately. However, I'd like someone who > actually has > to deal > with this sort of thing to weigh in. > > > > On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie > > > > > >>> wrote: > > On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko > > > > >>> wrote: > > In general case, how the user knows his realm > ? He may > not know it. > The user knows the name, the password, and the > TURN > server's IP > address or URL; knowing the realm is the TURN > server's > responsibility. > > ​If I understood Justin's drift on this, the > application > needs to > know the realm, not the user. It could be set by the > application > just as HOST would have been set. > > regards, > > Ted​ > > > And how transferring the realm in an open > request is > different from > transferring the ORIGIN ? Those are metadatas > of the > same nature. > > On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie > > > > > >>> wrote: > > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti > > > > >>> wrote: > >> > >> One possibly important point: USERNAME > isn't sent > in the > initial ALLOCATE. > >> If choosing a correct REALM on the server > is important > (which was the > >> original justification for this work), we > need to > either > send USERNAME in > >> the initial ALLOCATE, or send up the > preferred REALM. > >> > > > > I'm not seeing a downside to sending up the > preferred REALM > in the initial > > allocate, other than it not re-using the known > username@realm > convention. > > Am I missing something, or is it just spend the > bytes and > call it done? > > > > regards, > > > > Ted > > > > > > > >> > >> On Sun, Dec 13, 2015 at 6:48 PM, Martin > Thomson > > > > > >>> > >> wrote: > >>> > >>> On 14 December 2015 at 13:15, Justin Uberti > > > > >>> wrote: > >>> > at that point we're basically coming up > with a more > standard and > >>> > aesthetically pleasing way of doing > what could > already be > done with > >>> > USERNAME > >>> > (e.g. user@realm.com > > > > >>) > >>> > >>> Yeah, my thoughts exactly. In that case > it would > possibly > be better > >>> to rely on an @domain convention for > USERNAME and > be done > with it. > >> > >> > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > > > >> > > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > > > > From nobody Tue Jan 26 11:27:07 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFFA1B2BC7; Tue, 26 Jan 2016 11:27:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160126192706.3394.57544.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 11:27:06 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-pmtud-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:27:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-pmtud-01.txt Pages : 11 Date : 2016-01-26 Abstract: This document describes a Session Traversal Utilities for NAT (STUN) usage for Path MTU Discovery (PMTUD) between a client and a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 11:30:38 2016 Return-Path: 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 E912B1B2BC7 for ; Tue, 26 Jan 2016 11:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 I-4Bvqk_l6zz for ; Tue, 26 Jan 2016 11:30:31 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B4A1B2BEB for ; Tue, 26 Jan 2016 11:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1453836631; x=1455046231; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f2roLv6Sxibj3agre7mSPbuWaQcLsCSsywrB2cewzsk=; b=OWqwr10hbZ1BWDKKB1kX78oUjzsZCtsEY0UuQCyAGhMA9GsAdLE8yrRj R0RSPL9vbQFm1NSTsd2UfxP2qpcWhCMm9ggmiP0aF/K+fK3f4RC9Iaj1M YgA8+lhO0+1xZLbUQDryevvaqdjCG8mwTwjJ/xzvvNMjhk+8fmjvcoang c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQC8yKdW/5BdJa1egzpSbQaIUbIfA?= =?us-ascii?q?Q2BYhgKhW0CHIEzOBQBAQEBAQEBgQqEQQEBAQMBAQEBIBE6EAsCAQgYAgImAgI?= =?us-ascii?q?CJQsVEAIEE4gTCA6vVY8gAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFNwGCA4Jph?= =?us-ascii?q?DMWgwMrgQ8FlnkBhUWIEIFeSoN6iFeOQgEeAQFCg2lqh0h8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,351,1449532800"; d="scan'208";a="65302083" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 19:30:30 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0QJUUd6003727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jan 2016 19:30:30 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 13:30:29 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 13:30:30 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: tram mailing list Thread-Topic: [tram] I-D Action: draft-ietf-tram-stun-pmtud-01.txt Thread-Index: AQHRWG+NPoYfxzc7ckSIS1zBFCt0Ap8Ok7qA Date: Tue, 26 Jan 2016 19:30:29 +0000 Message-ID: <3C4D39D8-92FB-4F5D-975F-200C1F24C382@cisco.com> References: <20160126192706.3394.57544.idtracker@ietfa.amsl.com> In-Reply-To: <20160126192706.3394.57544.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.235.50] Content-Type: text/plain; charset="utf-8" Content-ID: <39D7A8FB143F8A4889E93E4F871F4B63@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-pmtud-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:30:36 -0000 Rm9sa3MgLSANCg0KVGhpcyBpcyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIFBNVFVEIGRyYWZ0 LiAgQXV0aG9ycyB3b3VsZCBhcHByZWNpYXRlIGFueSByZXZpZXdzIGFuZCBjb21tZW50cy4NCg0K T25lIGFyZWEgdGhhdCB3ZeKAmWQgYXBwcmVjaWF0ZSBzb21lIFdHIGNvbnNpZGVyYXRpb24gaXMg aG93IHdlIGhhbmRsZSB0aGUgdHdvIHByb3Bvc2VkIFByb2JpbmcgTWVjaGFuaXNtcyAoU2ltcGxl IGFuZCBDb21wbGV0ZSkuICBEbyB3ZSB3YW50IHRvIGtlZXAgYm90aD8gT3IgcGljayBvbmU/DQoN ClRoYW5rcywNCg0KR29uemFsbw0KDQo+IE9uIEphbiAyNiwgMjAxNiwgYXQgMTE6MjcgQU0sIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRVUk4gUmV2aXNlZCBh bmQgTW9kZXJuaXplZCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAgIFRp dGxlICAgICAgICAgICA6IFBhdGggTVRVIERpc2NvdmVyeSBVc2luZyBTZXNzaW9uIFRyYXZlcnNh bCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1h cmMgUGV0aXQtSHVndWVuaW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEdvbnphbG8gU2Fs Z3VlaXJvDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZC0w MS50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDExDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE2 LTAxLTI2DQo+IA0KPiBBYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIFNl c3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KPiAgIHVzYWdlIGZvciBQ YXRoIE1UVSBEaXNjb3ZlcnkgKFBNVFVEKSBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNlcnZlci4N Cj4gDQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFt LXN0dW4tcG10dWQvDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS1z dHVuLXBtdHVkLTAxDQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLXRyYW0tc3R1bi1wbXR1ZC0wMQ0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== From nobody Tue Jan 26 17:34:15 2016 Return-Path: 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 D0EB11B2D50 for ; Tue, 26 Jan 2016 17:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 m0kHrlbQaHIi for ; Tue, 26 Jan 2016 17:34:10 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 8F3561B2D4D for ; Tue, 26 Jan 2016 17:34:10 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id n1so102566655vkb.3 for ; Tue, 26 Jan 2016 17:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BchLiNdRPKx/cPiXW4qRqq3eM7wf0aRNjGRSuEjLZpI=; b=af+W8DfZdkALjoPeJ4Q0WqHOx8TAml8c6G4y0wfqSAI4syQ+04A6OVO7jDwGX4Z+/d KaZpsQ4b6DyAOi8mA09fzdNvRX2D5iCLaxMo5HZtzQ+iceb+T1tjDUBuDOkJYF/0Md+M xlmn95/4l6tjHD0elbNm48tKeW0XY4Yj09Wb0V2WP1KTaktOGB+UwP1+E/rstVcJM9a9 tnAMY9tbbAVKUVXEZOGCEAt+7eNQVGYYbIj68qtPXHz2acrGvnNOQxQ+knbaP8VlGo7y hthUIhI61tq5Ran+JHy+DKmJDRoUnjbcjNAIJkkg/4P0LnIWiAlXQ/IAVF6P1t8jcHoi DxHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BchLiNdRPKx/cPiXW4qRqq3eM7wf0aRNjGRSuEjLZpI=; b=L3ZSL+s4V6sfaHSPRlcvEI/AYu+SElY/WWlMIolSCAE1vXvzZW4naIdtVOAka9iZ/3 ekawK+zGcq7h5d1aMWY6mD0nGbKEveeXVFHByV60ffvSCn7FxrvmVSqLp+NQtIFk+9Ns rfTVCD8Bd8dZnJghK0myn2CKs0vRLviE4qgG+IxZkcCIAINQWKn7nvOfgJMO9AH3hPaU x1BCHlzHgzvCEFj/YfXEWGJT2LZ0QxMIJZAirFbqMd/RvzHarUDXsofvAGWhNc9tb/y9 AH9K1v0UzA+ssy6uLYJ6hMc4baIbn4rA7/UfHjHayedPR95uVZzTZVcOSc5lJnAI2k6P 4f5w== X-Gm-Message-State: AG10YOSzZMXRt1OzJ/aSaeDuWFcvXY8Z4LVSFJBHSPBO8xtq/5cyuXBHCeZO00IGiecwgZHT3wY+AbXB+24a6krE X-Received: by 10.31.149.78 with SMTP id x75mr16713706vkd.103.1453858449490; Tue, 26 Jan 2016 17:34:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Tue, 26 Jan 2016 17:33:49 -0800 (PST) In-Reply-To: <56A7C7A5.4090407@akamai.com> References: <569FE725.7030104@akamai.com> <56A65A6C.6090903@akamai.com> <56A7C7A5.4090407@akamai.com> From: Justin Uberti Date: Tue, 26 Jan 2016 17:33:49 -0800 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=001a114267486fcc29052a46ccf8 Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 01:34:15 -0000 --001a114267486fcc29052a46ccf8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For 3p auth, can't you embed realm info into kid (either with @realm or some bits in kid?) The only significant issue I see with c) is with existing pw dbs that store HA1 as defined in https://en.wikipedia.org/wiki/Digest_access_authentication#Overview. On Tue, Jan 26, 2016 at 11:23 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > The thread seemed to be discussing REALM and HOST as interchangeable, so = I > thought I might be missing something. Your list of options indicates the > same difference I was seeing in terms of the server side behavior. > > I'm interested in possible use cases for 3rd party auth. In that case, > USERNAME already has a purpose (it contains the kid value). I think that > kid@realm could work, but I haven't fully thought it through. a and b > seem to map more directly to a 3rd party auth use case. > > On a sparate note, b seems to cover more use cases than a/c, since it > handles both the case where the client knows the realm ahead of time and > the case where it needs to be told by the relay. IOW, if we go with just > one, HOST seems the better choice to me. > > --Brandon > > On 01/26/2016 12:19 PM, Justin Uberti wrote: > >> Hmm... I'm not exactly sure what you are proposing. >> >> At this point the only thing that we are trying to do is to ensure >> proper REALM selection in a multi-tenant case. This could be done >> multiple ways: >> a) REALM from the client (potentially different from HOST), server >> either mirrors this or returns an error (requires new web API) >> b) HOST from the client, triggering corresponding REALM from server (no >> new APIs) >> c) user@realm in USERNAME from client, server either mirrors realm part >> or returns an error (no new APIs or protocol, but has implications on >> how pw db is set up) >> >> c) is obviously the least work, followed by b) and then a). >> >> What do you prefer? >> >> On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams >> > wrote= : >> >> Sure, the client can only use the REALM the server gives it. I know >> that. But the suggestion in the thread seems to be that the client >> would dictate to the server what the REALM is, not the other way >> around. >> >> If the client sends ORIGIN or HOST, it's effectively asking to know >> what REALM to use. If it sends REALM, it's asking a somewhat >> different question (is this REALM value OK?). If the service is >> available for multiple HOST values with a different REALM on each, >> then HOST really must be sent. There are other use cases that REALM >> could apply to. I'm just not sure it can be used as a replacement >> for ORIGIN. I think HOST works better for that. >> >> Or was the suggestion that both HOST and REALM would be sent togethe= r? >> >> --Brandon >> >> On 01/22/2016 04:54 PM, Justin Uberti wrote: >> >> The client can only use the REALM that the server gives it. If t= he >> server is multi-tenant, and only stores password hashes, then it= 's >> imperative that the client uses the same realm as was used to >> compute >> the hash. >> >> On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams >> > >> > >> >> wrote: >> >> I'm a bit late joining this thread, but nevertheless ... >> >> It seems to me that if the application knows the REALM that >> should >> be used for auth, it's a different use case than the one >> we're >> attempting to handle with the ORIGIN attribute. If I >> understand >> correctly, a core purpose for the ORIGIN attribute is to >> allow the >> relay to determine which authentication REALM to require >> from the >> client, which seems to imply that the client has multiple >> options >> and doesn't already know which one to use for this case. If >> the >> client already knows the REALM, why does it need to tell >> the server >> anything in the initial, unauthenticated allocation request= ? >> Or >> rather, why does the server need to tell it which REALM to >> use? The >> only purpose of that allocation request becomes receiving a >> NONCE value. >> >> --Brandon >> >> >> On 12/14/2015 02:36 PM, Justin Uberti wrote: >> >> Exactly what Ted said. >> >> The difference between REALM/HOST and ORIGIN is that >> the application >> needs to set REALM/HOST, but ORIGIN would be auto-set >> by the >> browser. >> >> The key outstanding question IMO is whether setting REA= LM >> properly is >> actually useful, versus simply having the application >> include >> the domain >> in USERNAME. Chrome uses REALM solely to compute HA1 >> and thereby >> MESSAGE-INTEGRITY; since HA1 is defined as MD5(username >> ":" >> realm ":" >> SASLprep(password)), the benefit of using REALM would >> be that >> you can >> use existing password databases that compute HA1 with >> username/realm >> specified separately. However, I'd like someone who >> actually has >> to deal >> with this sort of thing to weigh in. >> >> >> >> On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie >> >> > >> >> >>> wrote: >> >> On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko >> >> > >> > > >>> wrote: >> >> In general case, how the user knows his realm >> ? He may >> not know it. >> The user knows the name, the password, and the >> TURN >> server's IP >> address or URL; knowing the realm is the TURN >> server's >> responsibility. >> >> =E2=80=8BIf I understood Justin's drift on this, t= he >> application >> needs to >> know the realm, not the user. It could be set by >> the >> application >> just as HOST would have been set. >> >> regards, >> >> Ted=E2=80=8B >> >> >> And how transferring the realm in an open >> request is >> different from >> transferring the ORIGIN ? Those are metadatas >> of the >> same nature. >> >> On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie >> >> > >> > >> > >>> wrote: >> > On Sun, Dec 13, 2015 at 8:25 PM, Justin >> Uberti >> > > > >> >> >>> wrote: >> >> >> >> One possibly important point: USERNAME >> isn't sent >> in the >> initial ALLOCATE. >> >> If choosing a correct REALM on the server >> is important >> (which was the >> >> original justification for this work), we >> need to >> either >> send USERNAME in >> >> the initial ALLOCATE, or send up the >> preferred REALM. >> >> >> > >> > I'm not seeing a downside to sending up the >> preferred REALM >> in the initial >> > allocate, other than it not re-using the >> known >> username@realm >> convention. >> > Am I missing something, or is it just spend >> the >> bytes and >> call it done? >> > >> > regards, >> > >> > Ted >> > >> > >> > >> >> >> >> On Sun, Dec 13, 2015 at 6:48 PM, Martin >> Thomson >> > >> > > >> > >> > >>> >> >> wrote: >> >>> >> >>> On 14 December 2015 at 13:15, Justin Uber= ti >> > > > >> >> >>> wrote: >> >>> > at that point we're basically coming up >> with a more >> standard and >> >>> > aesthetically pleasing way of doing >> what could >> already be >> done with >> >>> > USERNAME >> >>> > (e.g. user@realm.com >> > > >> >> >>) >> >>> >> >>> Yeah, my thoughts exactly. In that case >> it would >> possibly >> be better >> >>> to rely on an @domain convention for >> USERNAME and >> be done >> with it. >> >> >> >> >> > >> > >> > >> _______________________________________________ >> > tram mailing list >> > tram@ietf.org >> > >> >> >> >> > https://www.ietf.org/mailman/listinfo/tram >> < >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRI= uadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3Dg6KCBNP6ia2BLF1kUm6O9Qo4vF1GUUQ2DJpPoeRYHx= g&s=3D122BpTK5GLl5rnwQECQcXdO0CPIyBmbVxS2thFIoAg4&e=3D >> > >> >> < >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRI= uadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3DbstRUIB98hwOaulLxlErjpDk9i6GF9JdckvEC2nW_1= A&s=3DebOlAsUznfzVZZWlbNMG-Txv4xWvwe9wcDJp2fcpI8E&e=3D >> > >> >> >> < >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRI= uadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3D86SFKZkjNvPDRvmAnJfKfxEY9UdfXAj-Gdyipyp7PA= 0&s=3D3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM&e=3D >> > >> > >> >> >> >> >> >> --001a114267486fcc29052a46ccf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For 3p auth, can't you embed realm info into kid (eith= er with @realm or some bits in kid?)

The only significan= t issue I see with c) is with existing pw dbs that store HA1 as defined in= =C2=A0https://en.wikipedia.org/wiki/Digest_access_au= thentication#Overview.

On Tue, Jan 26, 2016 at 11:23 AM, Brandon Williams <brandon.williams@akamai.com> wrote:
The thread seemed to be discussing REALM and HOST as intercha= ngeable, so I thought I might be missing something. Your list of options in= dicates the same difference I was seeing in terms of the server side behavi= or.

I'm interested in possible use cases for 3rd party auth. In that case, = USERNAME already has a purpose (it contains the kid value). I think that ki= d@realm could work, but I haven't fully thought it through. a and b see= m to map more directly to a 3rd party auth use case.

On a sparate note, b seems to cover more use cases than a/c, since it handl= es both the case where the client knows the realm ahead of time and the cas= e where it needs to be told by the relay. IOW, if we go with just one, HOST= seems the better choice to me.

--Brandon

On 01/26/2016 12:19 PM, Justin Uberti wrote:
Hmm... I'm not exactly sure what you are proposing.

At this point the only thing that we are trying to do is to ensure
proper REALM selection in a multi-tenant case. This could be done
multiple ways:
a) REALM from the client (potentially different from HOST), server
either mirrors this or returns an error (requires new web API)
b) HOST from the client, triggering corresponding REALM from server (no
new APIs)
c) user@realm in USERNAME from client, server either mirrors realm part
or returns an error (no new APIs or protocol, but has implications on
how pw db is set up)

c) is obviously the least work, followed by b) and then a).

What do you prefer?

On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams
 <brando= n.williams@akamai.com <mailto:brandon.williams@akamai.com>> wrote:
=C2=A0 =C2=A0 Sure, the client can only use the REALM the server gives it. = I know
=C2=A0 =C2=A0 that. But the suggestion in the thread seems to be that the c= lient
=C2=A0 =C2=A0 would dictate to the server what the REALM is, not the other = way around.

=C2=A0 =C2=A0 If the client sends ORIGIN or HOST, it's effectively aski= ng to know
=C2=A0 =C2=A0 what REALM to use. If it sends REALM, it's asking a somew= hat
=C2=A0 =C2=A0 different question (is this REALM value OK?). If the service = is
=C2=A0 =C2=A0 available for multiple HOST values with a different REALM on = each,
=C2=A0 =C2=A0 then HOST really must be sent. There are other use cases that= REALM
=C2=A0 =C2=A0 could apply to. I'm just not sure it can be used as a rep= lacement
=C2=A0 =C2=A0 for ORIGIN. I think HOST works better for that.

=C2=A0 =C2=A0 Or was the suggestion that both HOST and REALM would be sent = together?

=C2=A0 =C2=A0 --Brandon

=C2=A0 =C2=A0 On 01/22/2016 04:54 PM, Justin Uberti wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The client can only use the REALM that the serv= er gives it. If the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server is multi-tenant, and only stores passwor= d hashes, then it's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 imperative that the client uses the same realm = as was used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 compute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the hash.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Jan 20, 2016 at 11:59 AM, Brandon Willi= ams
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <brandon.williams@akamai.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:brandon.williams@akamai.com>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:brandon.williams@akamai.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:brandon.williams@akamai.com>>> wr= ote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm a bit late joining = this thread, but nevertheless ...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It seems to me that if the = application knows the REALM that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be used for auth, it's = a different use case than the one we're
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attempting to handle with t= he ORIGIN attribute. If I understand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0correctly, a core purpose f= or the ORIGIN attribute is to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 allow the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0relay to determine which au= thentication REALM to require
=C2=A0 =C2=A0 =C2=A0 =C2=A0 from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client, which seems to impl= y that the client has multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and doesn't already kno= w which one to use for this case. If the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client already knows the RE= ALM, why does it need to tell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anything in the initial, un= authenticated allocation request? Or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rather, why does the server= need to tell it which REALM to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use? The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only purpose of that alloca= tion request becomes receiving a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NONCE value.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--Brandon


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 12/14/2015 02:36 PM, Jus= tin Uberti wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Exactly what = Ted said.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The differenc= e between REALM/HOST and ORIGIN is that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0needs to set = REALM/HOST, but ORIGIN would be auto-set
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0browser.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The key outst= anding question IMO is whether setting REALM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0properly is =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actually usef= ul, versus simply having the application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the domain =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in USERNAME. = Chrome uses REALM solely to compute HA1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and thereby
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MESSAGE-INTEG= RITY; since HA1 is defined as MD5(username ":"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0realm ":= "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SASLprep(pass= word)), the benefit of using REALM would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use existing = password databases that compute HA1 with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 username/realm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specified sep= arately. However, I'd like someone who
=C2=A0 =C2=A0 =C2=A0 =C2=A0 actually has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to deal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with this sor= t of thing to weigh in.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Dec 1= 4, 2015 at 11:11 AM, Ted Hardie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ted.ietf@gmail.com <mailto:ted.ie= tf@gmail.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ted.ietf@gmail.com <mailto:ted.ie= tf@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>>>> w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <mom040267@= gmail.com <mailto:mom040267@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mom040267@gmail.com <mailto:mom040267@gmail.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mom040267@gmail.com<= /a>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mom040267@gmail.com> <mailto:mom040267@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mom040267@gmail.com>>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 In general case, how the user knows his realm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ? He may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not know it.<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 The user knows the name, the password, and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TURN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server's = IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 address or URL; knowing the realm is the TURN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 server's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 responsibility.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =E2=80=8BIf I understood Justin's drift on this, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 application
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 know the realm, not the user.=C2=A0 It could be set by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 just as HOST would have been set.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Ted=E2=80=8B


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 And how transferring the realm in an open
=C2=A0 =C2=A0 =C2=A0 =C2=A0 request is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different fro= m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 transferring the ORIGIN ? Those are metadatas
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same nature.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ted.ietf@gmail.com <= ;mailto:ted.ietf@gm= ail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ted.ietf@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ted.ietf@gmail.com>>>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <juberti@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com> <mailto:juberti@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:juberti@google.com <mailto:jubert= i@google.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com <mailto:juberti@google.com>>>> w= rote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>> One possibly important point: USERNAME
=C2=A0 =C2=A0 =C2=A0 =C2=A0 isn't sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 initial ALLOCATE.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>> If choosing a correct REALM on the server<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 is important
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (which was the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>> original justification for this work), we<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 send USERNAME in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>> the initial ALLOCATE, or send up the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 preferred REALM.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> I'm not seeing a downside to sending up th= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0preferred REA= LM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 in the initial
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> allocate, other than it not re-using the known=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0username@real= m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 convention.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> Am I missing something, or is it just spend th= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bytes and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 call it done?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> Ted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>> On Sun, Dec 13, 2015 at 6:48 PM, Martin =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thomson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <martin.thomson@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:martin.thomson@= gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:martin.thomson@= gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:martin.thomson@gmail.com>>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> On 14 December 2015 at 13:15, Justin U= berti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <juberti@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com> <mailto:juberti@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:juberti@google.com <mailto:jubert= i@google.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:juberti@google.com <mailto:juberti@google.com>>>> w= rote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> > at that point we're basically= coming up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with a more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 standard and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> > aesthetically pleasing way of doi= ng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 what could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0already be =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 done with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> > USERNAME
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> > (e.g. user@realm.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:user@realm.com> <mailto:user@realm.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:user@realm.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:user@realm.com <ma= ilto:user@realm.com= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:user@realm.com <mailto:user@realm.com>>>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> Yeah, my thoughts exactly.=C2=A0 In th= at case
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0possibly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 be better
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>> to rely on an @domain convention for =C2=A0 =C2=A0 =C2=A0 =C2=A0 USERNAME and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be done
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 with it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> ______________________________________________= _
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> tram mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> tram@ietf.org <mailto:tram@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tram@ietf.org <mailto:tram@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tram@ietf.org <mail= to:tram@ietf.org>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tram@ietf.org <mailto:tram@ietf.org>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/= listinfo/tram
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3Dg6KCBNP6ia2BLF1kUm6O= 9Qo4vF1GUUQ2DJpPoeRYHxg&s=3D122BpTK5GLl5rnwQECQcXdO0CPIyBmbVxS2thFIoAg4= &e=3D>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3DbstRUIB98hwOaulLxlEr= jpDk9i6GF9JdckvEC2nW_1A&s=3DebOlAsUznfzVZZWlbNMG-Txv4xWvwe9wcDJp2fcpI8E= &e=3D>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=3D86SFKZkjNvPDRvmAnJfK= fxEY9UdfXAj-Gdyipyp7PA0&s=3D3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM= &e=3D>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0>






--001a114267486fcc29052a46ccf8-- From nobody Tue Jan 26 19:39:17 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A5C1A1B8E; Tue, 26 Jan 2016 19:39:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127033914.13501.35400.idtracker@ietfa.amsl.com> Date: Tue, 26 Jan 2016 19:39:14 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-05.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 03:39:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-05.txt Pages : 57 Date : 2016-01-26 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 19:40:00 2016 Return-Path: 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 98DB41A1C06 for ; Tue, 26 Jan 2016 19:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham 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 VYXX6L-ToNie for ; Tue, 26 Jan 2016 19:39:55 -0800 (PST) Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD21A1A36 for ; Tue, 26 Jan 2016 19:39:55 -0800 (PST) Received: from [IPv6:2001:5c0:1400:b::1121] (petithug.broker.freenet6.net [IPv6:2001:5c0:1400:b::1121]) (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 410882013C; Wed, 27 Jan 2016 04:39:52 +0100 (CET) From: Marc Petit-Huguenin To: Jonathan Lennox , "tram@ietf.org" References: Message-ID: <56A83C06.2000800@acm.org> Date: Tue, 26 Jan 2016 19:39:50 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Comments on draft-ietf-tram-stunbis-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 03:39:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks again for the review, and sorry for the delay in processing it. See inline. On 07/20/2015 04:11 PM, Jonathan Lennox wrote: > Inspired by the pleas in the TRAM working group today, I decided read > over draft-ietf-tram-stunbis-04. > > (Note that I’ve only reviewed the diff from RFC 5389, not re-reading > the document from scratch, so this only catches new problems, not old > problems.) > > Section 8.1: "The DNS SRV service name is the content of the > part.” This is wrong — the DNS SRV service name is “stun” or “stuns”. > This seems to have gotten mangled in the conversion to describing the > resolution process in terms of the URL. Fixed. > > Section 9.1.3: > > “If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the > value for the message integrity as described in Section 14.5, using > the password associated with the username. If the MESSAGE- > INTEGRITY-SHA256 attribute is not present, and using the same > password, compute the value for the message integrity as described in > Section 14.4. If the resulting value does not match the contents of > the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE- INTEGRITY > attribute:” > > Is this saying that a SHA-1 message integrity value (described in > Section 14.4) can be carried in a MESSAGE-INTEGRITY-SHA256 attribute? > That doesn’t seem right. > Can you please suggest some text that would make it clearer that this is not the intended meaning? We fail to see how this conclusion can be made from the text. > Section 9.1.4: > > “The client looks for the MESSAGE-INTEGRITY-SHA256 or the MESSAGE- > INTEGRITY attribute in the response. If present, the client computes > the message integrity over the response as defined in Section 14.4 > or Section 14.5, using the same password it utilized for the request. > If the resulting value matches the contents of the MESSAGE-INTEGRITY > or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered > authenticated. If the value does not match, or if both MESSAGE- > INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST > be discarded, as if it was never received. This means that > retransmits, if applicable, will continue.” > > Parallelism failure. Sometimes MESSAGE-INTEGRITY is listed first, and > sometimes MESSAGE-INTEGRITY-SHA256. If read literally it would seem > to imply you were swapping the values. The two algorithms should be > consistently listed in order, and it should be made clear that they > apply respectively. Fixed. > > Additionally, it should say that if the client only sent one > algorithm in the request (because of the external indication in > section 9.1.2, or this being a subsequent request as defined in > 9.1.5) the algorithm in the response has to match. Fixed. > > Section 9.1.5: > > “A client sending subsequent requests to the same server a MAY choose > to send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY > attribute depending upon the attribute that was received in the > response to the initial request.” > > This should probably be required to be the literal same server —i.e., > the same IP and port — not just the same URL or SRV lookup. Fixed. > > Section 9.2.3: > > There seems to be a random github URL pasted into the document. Fixed :-) > > “If the NONCE attribute starts with the value "obMatJos2" but the > PASSWORD-ALGORITHMS attribute is not present or is not identical to > the PASSWORD-ALGORITHMS attribute sent in the response, the server > MUST generate an error response with an error code of 400 (Bad > Request). This response SHOULD NOT include a USERNAME, NONCE, REALM, > MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 attribute.” > > Doesn’t this break backward compatibility with RFC 5389 (i.e., > MD5-algorithm-only) clients? It’s a server’s choice whether to > support MD5 as a password algorithm, but presumably if it does it’s > doing so for a reason (i.e. an old password database or supporting > old clients). > > I think this should say that if PASSWORD-ALGORITHMS doesn’t match, > the request is dropped; but if the request contains neither > PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, the request is processed > as though PASSWORD-ALGORITHM were MD5. (And MD5 should be added to > PASSWORD-ALGORITHMS, see below.) Depending on the list in > PASSWORD-ALGORITHMS, this may either be supported, or trigger a 400. > > It’s a 400 if only one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS > is present, or if PASSWORD-ALGORITHM doesn’t match one of the entries > in PASSWORD-ALGORITHMS. > > Meanwhile, to prevent bid-down, the *client* requirements should say > that if the nonce begins with obMatJos2 but PASSWORD-ALGORITHMS is > not present, the response should be ignored. > > > “If these checks pass, the server continues to process the request. > Any response generated by the server (excepting the cases described > above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- > SHA256 attributes, computed using the username and password utilized > to authenticate the request.” > > Why do you want both? For short-term you only send > MESSAGE-INTEGRITY-SHA256 if the client supported it. > These were tough, but we think that we captured the essence of your concerns. But please have a look at the new text. > Section 9.2.4: > > “If the response is an error response with an error code of 401 > (Unauthorized), the client SHOULD retry the request with a new > transaction. This request MUST contain a USERNAME, determined by the > client as the appropriate username for the REALM from the error > response. The request MUST contain the REALM, copied from the error > response. The request MUST contain the NONCE, copied from the error > response. If the response contains a PASSWORD-ALGORITHMS attribute, > the request MUST contain the PASSWORD-ALGORITHMS attribute with the > same content. If the response contains a PASSWORD-ALGORITHMS > attribute, and this attribute contains at least one algorithm that is > supported by the client then the request MUST contain a PASSWORD- > ALGORITHM attribute with the first algorithm supported on the list.” > > This text seems to imply that if the PASSWORD-ALGORITHMS list > contains only algorithms the client doesn’t recognize, the client > goes ahead and uses MD5. Does this make sense? I think the client > should give up if it doesn’t support any of the algorithms. Fixed. > > "if the response contains a MESSAGE-INTEGRITY-SHA256 attribute then > the request MUST contain a MESSAGE-INTEGRITY-SHA256 attribute, > computed using the password associated with the username in the > USERNAME attribute. Else the request MUST contain the MESSAGE- > INTEGRITY attribute, computed using the password associated with the > username in the USERNAME attribute. The client MUST NOT perform this > retry if it is not changing the USERNAME or REALM or its associated > password, from the previous attempt.” > > We’re still talking about the 401 Unauthorized here, right? The text > says the response SHOULD NOT contain MESSAGE-INTEGRITY-SHA256, since > there’s no way to know the username to use. Fixed. > > That said, it seems to me to be reasonable to say that if the > response contains PASSWORD-ALGORITHMS, the followup request should be > authenticated using MESSAGE-INTEGRITY-SHA256 only, since we know that > both the client and server are stunbis. > Done. > > > Section 14.10: > > “The PASSWORD-ALGORITHMS attribute is present only in responses.” > > Not true, it’s in followup requests, as mentioned, to prevent > bid-down. Fixed. > > Section 17.4: > > Salted SHA-256 is still listed in the password algorithms table, > despite being otherwise deleted from the document. Fixed. > > Should we define MD5 as a PASSWORD-ALGORITHM value? The use case is a > server that wants to upgrade to stunbis, but wants to keep using its > existing (md5-hashed) password database without forcing users to > re-enter their password. (This would mean a case where long-term > authentication uses the MD5 password algorithm, but > MESSAGE-INTEGRITY-SHA256 integrity.) > OK. > > Section 17.5: > > Should register the stuns over UDP port. My understanding (following a discussion with IANA in Dallas, IIRC) is that as we should only update the RFC 5389 registrations, and not the RFC 7350 registration. > > > A general question about the PASSWORD-ALGORITHM transition process: > do we want to support the use case where a server is gradually > transitioning its existing database to have SHA-256 as the password > hash algorithm (as users change passwords)? This might result in a > case where some users have MD5-hashed passwords in the database, and > some have SHA-256 — but the server doesn’t yet know when responding > to the initial request which user is making the request, and thus > which password algorithms are actually supported for this specific > user. Supporting this would require either putting USERNAME in the > initial request (which seems bad in the absence of a known realm), or > else allowing a server to respond to a followup request with another > 401 Unauthorized response, with a shorter PASSWORD-ALGORITHMS list > (resulting in long-term authentication requiring three transactions > for stunbis clients whose users who are still on MD5). Despite the > triple transaction, I’m inclined to recommend the latter. Interesting use case regarding the management of an hybrid database containing mixed MD5/SHA256 users, but is it worth adding that complexity to the protocol? We're willing to listen to opinion from the working group, especially people with large deployments. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqDwGAAoJECnERZXWan7EQjEP/iiwP/dDObfp7utV3m0ZLPXW UOhtU2WzsceSXvbSw+bkELydYVM9WOqpooCzwmXRI79UI1N6TT6tJuu7/BtJij/B kq/bMARnTgk35QoejI11M0boEcVxIbtN8kOwOc93f4caHz2vMEPArL4BI2wVdeRM euuqdb/Aiuniad2asqyFDQuy9qXAydQKb0ejTFQpqgfDT3quj942nXPG/kzr/8li Xt/36cg9xnnP/B0Ry3/7FWUmk6sKpnVhfEN+wSchcqjR+td9EJGV2yGcXZml3CPS GI/qDe4Le13P2Ez6V2zRLumAITczDL5DplEfVwt9XJWvCqUCqHyW7gGu9lXCDfwI ojvPCaDkHiNb8ff7x4ouUWhQNMX1O7SE58yiUgsKRiVDn56IEXZfOESKiunsJwN2 2+tza3UiaVzM0BGX/u5cQDhyLoMYr2UdiJb70iRkx5OTd2CL5KExq8gJ2+BKSvpz /ZPG4+mqUH2EOiC6NXGv45NgOjnh6QM8rVUACQBh7Ict8pCjN9w7ybv6vf59xdwr grcQ/2OB3QPhsUgOSjS/nenDRSrxa1NVTs7eM/cF+JwQ3ERoh3N8On+nq+wWa6Pd cgIaJbWkHzpMASdTGLi09RP6EXRR6uBM/cJTgAniboAFxpIknWrgrWISKtm09PwQ 6O9Y8Xo1al2reSBrQV2v =I5Cm -----END PGP SIGNATURE----- From nobody Tue Jan 26 19:41:23 2016 Return-Path: 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 1FBDC1A1C02 for ; Tue, 26 Jan 2016 19:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham 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 87Kyd5tdkIrr for ; Tue, 26 Jan 2016 19:41:20 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0D40F1A1B8E for ; Tue, 26 Jan 2016 19:41:20 -0800 (PST) Received: from [IPv6:2001:5c0:1400:b::1121] (petithug.broker.freenet6.net [IPv6:2001:5c0:1400:b::1121]) (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 5735C2013C; Wed, 27 Jan 2016 04:41:18 +0100 (CET) From: Marc Petit-Huguenin To: Brandon Williams , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> Message-ID: <56A83C5B.6010702@acm.org> Date: Tue, 26 Jan 2016 19:41:15 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <55E8644F.8090506@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Review of draft-ietf-tram-stunbis-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 03:41:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks for the review, and sorry for the delay in processing it. See inline. On 09/03/2015 08:16 AM, Brandon Williams wrote: > I have reviewed the STUN changes proposed in stunbis-04. Sorry for > the long delay since Prague -- hope I don't have to return my star > :-) > > First, I've got a small number of substance comments. > > s 6.1 This section still says "MTU constraint MUST be followed" > language. I'm pretty sure that we decided to relax this constraint in > Dallas, but I don't see it in the minutes. It seems to be implied by > the decision about removing the SCTP requirement. My recollection was that the relaxation was linked to the introduction of the SCTP transport in STUN (which permitted safe fragmentation). Now that SCTP is gone, I am not sure that this decision stands alone. > > s 9.2.3 The third bullet states 'If the NONCE attribute starts with > the value "obMayJos2" but the PASSWORD-ALGORITHMS attribute is not > present ... the server MUST generate an error response'. However, I > don't see a way for the server to determine whether it's safe to > require this when sending the PASSWORD-ALGORITHMS attribute. Maybe > the third bullet's requirement can only be safely applied if > MI-SHA256 is present. We are not sure we understand your point, but this section has been heavily rewritten following Jonathan review, so please check that your comment is still valid. > > s 14.4/14.5 There has been some discussion in mmusic about trying to > compress ICE connectivity checks. Justin presented on this. IIRC, one > of his proposals was to shrink the size of the ICV. It would be good > to follow up on this and perhaps update stunbis to allow ICV's that > are shorter. Here's the conclusions (from MMUSIC minutes) of the discussion about that in Prague: "Next steps: We need to discuss more on the approach and get back. Look further into what we can do with ufrag, etc. How much can we reduce packet size safely?" I do not think that there is consensus enough to take any action at this point. > > s 14.10 States "... is present only in responses." This is > incorrect. Fixed. > > The rest of my comments are nits. > > s 9.1.2 "... from an external indication what is the message > integrity algorithm supported by both agents." I suggest "... from an > external indication which message integrity algorithm is supported by > both agents." Done, > > s 9.1.3 In the paragraph that starts "If these checks pass, ...", it > might be useful to explicitly state that only one of MI-SHA256 or MI > will be included, not both. It's probably obvious to most readers > though. Added text. > > s 9.2.3 There is what appears to be a random URL in the text of the > first bullet. Fixed. > > s 11 The text seems to describe backward compatibility with RFC3489, > but the section title is "Backwards Compatibility with RFC 5389". We made a reference to the backward compatibility section of RFC 5389 (section 12), which is RFC 3489. The section is this document is about the backward compatibility to RFC 5389. > > s 13 I think this section should also include TURN in the list of > defined STUN usages. Maybe there are others. Alternatively, change > the wording to indicate it's not a complete list. There is, in fact, more STUN Usages missing besides TURN, so we thought that trying to keep an updated list is pointless, so we dropped the whole paragraph. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqDxbAAoJECnERZXWan7ERsAQAMbUSfSv2zjks3cor812QdZr MsOOwJTgjTSMxWg6U8JhU8tZpzGkjvEqWfxNrV0lFilucgLNxXvvolqZ824xyO/w BhXUaY+OkJtl7uPdyTJ/qGPSP7to475geXv7/ntPZLm+UxHTWhve86lDJLTv07xE i9d+d+FsCHSf83gNQdM7kzAyyDVevMt1pYokWcqeqApLV664zjj/axZMyh7+JVAL 7LY9cwIj+n0B9Y7ybmCipnr6rX87WnebXH67X8NGwc+ixzm3wYQE4Hr32eo42pVG uS6w1VhMMVcAzNTwT7y90mJMwjLID8JrUibZQ3WlFG+Z5pNytE0dd6az6kdIOkwc PFptRpxIGozmA5CEUy+tzVWldDIAHmBId2Cut1OnL9inkbrp8qJfCVjE5Yxd5qQC wmRbIO5jKjcP5nQ8CB9/bBl/DII4tll+Gt70hTCyAGvPdecT7BTKVMEv9M870Jnk lKKRpEltb8UEGN6LzJMwXpuCNQ02uHSR8syb1k1mLpaTQB/AZuhqp1tcuElEwqVG /O3yUJDxjEf21C98CGHudmeVqwBNbPmjj+wlpiE5f17ejlFOZH56/T+d7vvZN+l1 QgCMJiJftRrbb8Max6odCRwynNFQfCcfjXsvievx+o+t/+U+n+JIdVBl+ON62SW4 g0GfJ2KZ80byVOWVzPct =PW/r -----END PGP SIGNATURE----- From nobody Tue Jan 26 19:51:29 2016 Return-Path: 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 177281A2130 for ; Tue, 26 Jan 2016 19:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mjrrGoQ67Ci5 for ; Tue, 26 Jan 2016 19:51:26 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265441A212D for ; Tue, 26 Jan 2016 19:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2523; q=dns/txt; s=iport; t=1453866685; x=1455076285; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9rWmyfQmZi9QagtWZNkSmTOzBAbFGwYuwxqLWH2OV7M=; b=lQQt34IMkp16P2rG3pszaxNmegbfVgqHfUo8Z1uS3XUkldDCMc2tpkkT 9YqiYQ/BA1OGiYGHcmd0Ziz7Q64F8wYOAHm7GzgbsigvlpABOn26gtgw9 lxi5zGi9OENb9Lkkf+hZNEf77EuXfBZ8g+YUOW7bRGwcgLbftdZmWBwn3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgDMPahW/40NJK1egzpSbQaIUbIdA?= =?us-ascii?q?Q2BYhgKhW0CgU84FAEBAQEBAQGBCoRBAQEBAwEBAQE3NBALAgEIGB4QJwslAgQ?= =?us-ascii?q?TCRKHeAgOvg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjIBggKCaYRJNIJ6gQ8Fl?= =?us-ascii?q?nkBhUaIEIFfSoN6iFeHEocvAR4BAUKDaWoBh0d8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,353,1449532800"; d="scan'208";a="65226504" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jan 2016 03:51:25 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0R3pPWm012925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Jan 2016 03:51:25 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 21:51:24 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 21:51:24 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: tram mailing list Thread-Topic: I-D Action: draft-ietf-tram-stunbis-05.txt Thread-Index: AQHRWLRS8jNe8R00kEeVW1lDufPQvJ8PHygA Date: Wed, 27 Jan 2016 03:51:24 +0000 Message-ID: <1CE9A29B-E23B-4A3D-8A8B-487132594C4D@cisco.com> References: <20160127033914.13501.35400.idtracker@ietfa.amsl.com> In-Reply-To: <20160127033914.13501.35400.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.235.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B89BBEE3952EE47AC6E18CD91BDA747@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-05.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 03:51:28 -0000 Hi -=20 This version addresses the pending review comments from Jonathan Lennox and= Brandon Williams. Reviews and comments always welcome and greatly appreciated. Cheers, Gonzalo > On Jan 26, 2016, at 7:39 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working Grou= p of the IETF. >=20 > Title : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-05.txt > Pages : 57 > Date : 2016-01-26 >=20 > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. >=20 > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. >=20 > This document obsoletes RFC 5389. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-stunbis-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jan 27 05:39:29 2016 Return-Path: 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 0F6F11B2DE5 for ; Wed, 27 Jan 2016 05:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 Grw09iR2qB9T for ; Wed, 27 Jan 2016 05:39:25 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 70D1E1B2DE4 for ; Wed, 27 Jan 2016 05:39:25 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id b35so6432112qge.0 for ; Wed, 27 Jan 2016 05:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=pETdtY2mjKvlmdW9XJRyXcTPBOaZYp5LHF8F+Cd2wX8=; b=bYT2aPcRe5JH7jmNIzHGpZAfSd0S4wfeiCf/3gTvzc9HUP0js4hwvGMpsOCr9jpCJJ sfcTE75XOo1JY4LbRpFi6n1C1zCcnJqVzl5MzegxS/6NITMYwc1I5C/KBv1mc+RQkSJ0 aD/A1C81kybuwlnf6f002DW+Sc3QQ84B8sJIqehyiggnt5GX6J8XkToo2AiL7v0dWexn vqL/2qdYlDi7oSf9DtwaKxiOCqvLA9EcXioEwC8m3vyj6d/t4Ul9RqmuNlpnDx08xCm7 N0TvYmpylpfTAHvgZzif0kJWZt2a1f2vMyr+fyXwxWsAGPEQhj4id04vWsgjlwWKzdtF Q1/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pETdtY2mjKvlmdW9XJRyXcTPBOaZYp5LHF8F+Cd2wX8=; b=HRdRA9MUVt4kyIufbWub28EMl3JYP1hy418FXrpbLozd8HB7CuffaEjE7OYjP6hE88 bsdXJ2HjR2Y3TLPqWV3eCJT+we2D2bmjhCAbzO9pZv1cxNQiSFa3iRQx/3LPH4qIWym1 QCQXBq+IqBZm0mj0h8+kVJrnflW1jatTujh6sg+7nMKTjVxG+b4Rgruc2rkOI1tUUnoE CuZuzuW697bQMVjtfo/FxJItKMilxfvUFsg6rolthL5WKSpygcT3HgSbMRo9KJJyu00P XwSGpl7JSnl/SDCx1WmMgf7DYS7cyj/h7ejvimohRSAGhHaB1a8MxrfMnW0m4eKokHzW iN2Q== X-Gm-Message-State: AG10YOTNGBlJuN4v8NQ2TmEPvHsOhAs8R6Q1BTlwR/4K4MlWtnvauP7LK3cqCaR387x90tsw X-Received: by 10.140.32.97 with SMTP id g88mr34935857qgg.40.1453901964348; Wed, 27 Jan 2016 05:39:24 -0800 (PST) Received: from Simons-MacBook-Air.local ([2001:470:b161:0:5cc6:d865:b53d:3f3e]) by smtp.googlemail.com with ESMTPSA id a129sm1660289qkb.45.2016.01.27.05.39.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 05:39:23 -0800 (PST) To: Marc Petit-Huguenin , Brandon Williams , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> From: Simon Perreault Message-ID: <56A8C88A.1090305@jive.com> Date: Wed, 27 Jan 2016 08:39:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A83C5B.6010702@acm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 13:39:27 -0000 Le 2016-01-26 22:41, Marc Petit-Huguenin a crit : >> s 14.4/14.5 There has been some discussion in mmusic about trying to >> > compress ICE connectivity checks. Justin presented on this. IIRC, one >> > of his proposals was to shrink the size of the ICV. It would be good >> > to follow up on this and perhaps update stunbis to allow ICV's that >> > are shorter. > Here's the conclusions (from MMUSIC minutes) of the discussion about that in Prague: > > "Next steps: We need to discuss more on the approach and get back. Look further into what we can do with ufrag, etc. How much can we reduce packet size safely?" > > I do not think that there is consensus enough to take any action at this point. I am seizing this opportunity to restart discussion on this topic. I think we've discussed many possibilities, and what is needed at this moment is an actual concrete text proposal. I don't think it's necessarily up to the draft editors to come up with such a proposal, but rather up to the working group as a whole. Discuss. :) Thanks, Simon From nobody Wed Jan 27 06:12:36 2016 Return-Path: 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 F0B311B2E87 for ; Wed, 27 Jan 2016 06:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gT6pA7ftllQh for ; Wed, 27 Jan 2016 06:12:32 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07771B2E80 for ; Wed, 27 Jan 2016 06:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6714; q=dns/txt; s=iport; t=1453903952; x=1455113552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DXLGdQZLUatJgp4YvHRQY8kBDDRq/5VE+bZXUMKE2YI=; b=atVyIEBM4cjEXqDD9n/X3DOMJAQvSBHqbJXgVoc/hdwLcckd2ns8YUSv TQLNLb/4sYMFFPD2P8J1YILwu6KHqN2eLyB1IsXMWjEYNPMi9vKgsUV/j FUcJcxtUTclYbFRZ3PK7foGSByjoS7g50WvbLI9CBmv6CrdGs9eOuZMGM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgCxz6hW/49dJa1egzpSbQaIUbFOA?= =?us-ascii?q?Q2BYhgKhW0CHIEpOBQBAQEBAQEBgQqEQQEBAQMBAQEBIBE6CwULAgEIGAICJgI?= =?us-ascii?q?CAiULFRACBA4FG4d4CA6uL48vAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFGYFtg?= =?us-ascii?q?kqEIQYogmsrgQ8FlnsBhUaID4FfSoN6iFeOQgEeAQFCg2xqh0h9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,354,1449532800"; d="scan'208";a="67454157" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2016 14:12:31 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0RECV3p031160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2016 14:12:31 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Jan 2016 09:12:30 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Wed, 27 Jan 2016 09:12:30 -0500 From: "Pal Martinsen (palmarti)" To: Brandon Williams Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt Thread-Index: AQHRGd8PNyYawqYrh0qti/HaNjIsw58IeWgAgAfALoA= Date: Wed, 27 Jan 2016 14:12:30 +0000 Message-ID: References: <20151108043622.19002.79331.idtracker@ietfa.amsl.com> <56A24FDA.9000806@akamai.com> In-Reply-To: <56A24FDA.9000806@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.220.158] Content-Type: text/plain; charset="utf-8" Content-ID: <4661A6D6C97A9D4182379AA0165D18E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 14:12:35 -0000 DQpUaGFua3MgZm9yIHJldmlldyBhbmQgY29tbWVudHMNCj4gT24gMjIgSmFuIDIwMTYsIGF0IDE2 OjUwLCBCcmFuZG9uIFdpbGxpYW1zIDxicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+IHdyb3Rl Og0KPiANCj4gSSd2ZSBnb3QgYSBjb3VwbGUgb2YgY29tbWVudHMgb24gdGhlIGN1cnJlbnQgdmVy c2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBzMy4xLjINCj4gVGhlIGN1cnJlbnQgdGV4dCBoYXMg c29tZSBkaXNjdXNzaW9uIG9mIHBhdGggTVRVIGFuZCBTVFVOIG1lc3NhZ2Ugc2l6ZSANCj4gcmVz dHJpY3Rpb25zIHRoYXQgcmVsYXRlcyB0byByZXF1aXJlbWVudHMgdGhhdCBJIHRoaW5rIHdlIGhh dmUgDQo+IHByZXZpb3VzbHkgZGVjaWRlZCB0byByZWxheC4gSWYgbXkgbWVtb3J5IGlzIGNvcnJl Y3QsIHdlIGRlY2lkZWQgaW4gDQo+IERhbGxhcyB0byBhbGxvdyByZXF1ZXN0L3Jlc3BvbnNlIG1l c3NhZ2VzIHRvIGFzc3VtZSByZWFzb25hYmxlIHBhdGggTVRVIA0KPiB2YWx1ZXMgKHJhdGhlciB0 aGFuIHRoZSBJUHY0IG1pbmltdW0pLCBzbyB3ZSBtaWdodCB3YW50IHRvIGF2b2lkIA0KPiByZWl0 ZXJhdGluZyBsaW1pdGluZyBndWlkYW5jZSBmcm9tIFJGQzUzODkuIEkgY2FuJ3QgZmluZCByZWZl cmVuY2UgdG8gDQo+IHRoaXMgZGVjaXNpb24gaW4gdGhlIG1lZXRpbmcgbWludXRlcyBmcm9tIERh bGxhcywgdGhvdWdoLCBzbyBtYXliZSBJJ20gDQo+IG1pc3Rha2VuLiBOZXZlcnRoZWxlc3MsIGl0 J3MgcHJvYmFibHkgYmV0dGVyIHRvIGp1c3QgbWVudGlvbiB0aGF0IHlvdSANCj4gY2FuJ3QgYXNz dW1lIE1UVXMgYXJlIHRoZSBzYW1lIGFuZCBwb2ludCB0byBSRkM1Mzg5IGZvciBmdXJ0aGVyIA0K PiBndWlkYW5jZSwgcmF0aGVyIHRoYW4gcmVwZWF0aW5nIHJlcXVpcmVtZW50cyBsYW5ndWFnZS4N Cj4gDQoNCisxLiBTaG91bGQgYmUgZml4ZWQgdXAgaW4gdGhlIGRvY3VtZW50Lg0KDQo+IHMzLjIu Mg0KPiBBIGNvbW1vbiB1c2UgY2FzZSBmb3IgbW9iaWxpdHkgd2lsbCBsaWtlbHkgYmUgd2hhdCBz b21lIGhhdmUgZGVzY3JpYmVkIA0KPiBhcyB0aGUgIndhbGsgb3V0IHRoZSBkb29yIiBwcm9ibGVt LiBUd28gaW50ZXJmYWNlcyBhcmUgZnVuY3Rpb25hbCAoZS5nLiANCj4gYm90aCB3aWZpIGFuZCBs dGUpIGFuZCB5b3Ugd2FudCB0byBzZWFtbGVzc2x5IHN3aXRjaCBmcm9tIG9uZSB0byB0aGUgDQo+ IG90aGVyLiBZb3UgcHJvYmFibHkgd2FudCB0byBiZSBhYmxlIHRvIHVzZSBib3RoIGludGVyZmFj ZXMgYXQgdGhlIHNhbWUgDQo+IHRpbWUgd2hpbGUgeW91J3JlIGZpZ3VyaW5nIG91dCB3aGV0aGVy L3doZW4gdG8gc3dpdGNoIGZyb20gb25lIHRvIHRoZSANCj4gb3RoZXIgKG1ha2UgYmVmb3JlIGJy ZWFrKS4gSSBkb24ndCB0aGluayB0aGUgY3VycmVudCB0ZXh0IHN1cHBvcnRzIHRoaXMsIA0KPiBz aW5jZSBpdCBpbmRpY2F0ZXMgdGhhdCAxKSB0aGUgdHVwbGUgZm9yIHRoZSBhbGxvY2F0aW9uIHNo b3VsZCBiZSANCj4gdXBkYXRlZCBhbmQgMikgdGhlIG9sZCB0aWNrZXQgY2FuIG9ubHkgYmUgdXNl ZCBmb3IgcmV0cmFuc21pc3Npb24uIElmIA0KPiBJJ20gbWlzdW5kZXJzdGFuZGluZyB0aGUgaW50 ZW50IG9mIHRoZSB0ZXh0LCB0aGVuIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gDQo+IHNlZSBzb21l IGV4cGxpY2l0IGRpc2N1c3Npb24gb2YgdGhpcyB1c2UgY2FzZS4NCj4gDQpIbW0uIEkgdGhpbmsg eW91IGFyZSByaWdodC4gV2lsbCB0cnkgdG8gd3JpdGUgdXAgc29tZXRoaW5nLg0KDQo+IEZpbmFs bHkgKHNhbWUgc2VjdGlvbiksIHdoaWxlIEkgY2FuIHNlZSB0aGUgdmFsdWUgb2YgbWFpbnRhaW5p bmcgdGhlIA0KPiBleGlzdGluZyBhbGxvY2F0aW9uIHdoZW4gc3dpdGNoaW5nIGJldHdlZW4gaW50 ZXJmYWNlcy9hZGRyZXNzZXMsIA0KPiBzdGlja2luZyB0byB0aGF0IHJlbGF5IHNlcnZlciBjb3Vs ZCBiZSBhIGJhZCBpZGVhIGlmIHRoZXJlIGFyZSANCj4gb3RoZXIvYmV0dGVyIG9wdGlvbnMgZm9y IHRoZSBuZXcgYWRkcmVzcy4gVG8gc3VwcG9ydCBtYWtlIGJlZm9yZSBicmVhayANCj4gaW4gdGhp cyBjYXNlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIHJlbGF5IHNlcnZlciB0 byBiZSBhYmxlIA0KPiB0byBzZW5kIGFuIEFMVEVSTkFURS1TRVJWRVIgYXR0cmlidXRlIGluIGl0 cyBSZWZyZXNoIHJlc3BvbnNlIG1lc3NhZ2UuIA0KPiBJT1csIGFsbG93IHRoZSBjbGllbnQgdG8g Y29udGludWUgdXNpbmcgdGhlIG5ldyBhbGxvY2F0aW9uLCBidXQgYWxzbyBsZXQgDQo+IGl0IGtu b3cgdGhhdCBhIGRpZmZlcmVudC9iZXR0ZXIgcmVsYXkgaXMgYXZhaWxhYmxlIGZvciB0aGF0IGFk ZHJlc3MuIA0KPiBUaGVyZSB3b3VsZCBsaWtlbHkgYmUgc29tZSBJQ0Ugd29yayBhc3NvY2lhdGVk IHdpdGggc3VwcG9ydGluZyBzdWNoIGFuIA0KPiBvcHRpb24sIHNvIG1heWJlIGl0IGJlbG9uZ3Mg aW4gYSBzZXBhcmF0ZSBtb3JlLWdlbmVyYWwgZG9jIHNpbmNlIA0KPiB0dXJuLW1vYmlsaXR5IGlz IHVzZWZ1bCB3aXRob3V0IGl0LCBidXQgaXQgc2VlbWVkIHdvcnRoIGJyaW5naW5nIHVwIGluIA0K PiB0aGlzIGNvbnRleHQuDQo+IA0KWWVzLCB0aGUgaW50ZW50aW9uIHdhcyB0byBoYXZlIGEgTUlD RSBkcmFmdCAoTW9iaWxpdHkgZm9yIElDRSkgdGhhdCBjb3ZlcnMgc29tZSBvZiB0aG9zZSB1c2Ut Y2FzZXMuIEJ1dCB3ZSBhcmUgd2FpdGluZyBmb3IgYWxsIHRoZSB0cmlja2xlIGFuZCBub21pbmF0 aW9uIGRpc2N1c3Npb25zIHRvIGZpbmFsaXNlIHRvIHNlZSBpZiB0aGVyZSBpcyBhY3R1YWxseSBh IG5lZWQgZm9yIGEgbW9iaWxpdHkgZXh0ZW5zaW9uLiANCg0KLi0uDQpQw6VsLUVyaWsNCg0KPiAt LUJyYW5kb24NCj4gDQo+IE9uIDExLzA3LzIwMTUgMTE6MzYgUE0sIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyB3cm90ZToNCj4+IA0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVFVSTiBSZXZpc2VkIGFuZCBNb2Rlcm5pemVkIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+PiANCj4+ICAgICAgICBUaXRsZSAgICAgICAgICAg OiBNb2JpbGl0eSB3aXRoIFRVUk4NCj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBEYW4gV2lu Zw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIFByYXNoYW50aCBQYXRpbA0KPj4gICAgICAg ICAgICAgICAgICAgICAgICAgIFRpcnVtYWxlc3dhciBSZWRkeQ0KPj4gICAgICAgICAgICAgICAg ICAgICAgICAgIFBhYWwtRXJpayBNYXJ0aW5zZW4NCj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eS0wMC50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiAx MQ0KPj4gCURhdGUgICAgICAgICAgICA6IDIwMTUtMTEtMDcNCj4+IA0KPj4gQWJzdHJhY3Q6DQo+ PiAgIEl0IGlzIGRlc2lyYWJsZSB0byBtaW5pbWl6ZSB0cmFmZmljIGRpc3J1cHRpb24gY2F1c2Vk IGJ5IGNoYW5naW5nIElQDQo+PiAgIGFkZHJlc3MgZHVyaW5nIGEgbW9iaWxpdHkgZXZlbnQuICBP bmUgbWVjaGFuaXNtIHRvIG1pbmltaXplDQo+PiAgIGRpc3J1cHRpb24gaXMgdG8gZXhwb3NlIGEg c2hvcnRlciBuZXR3b3JrIHBhdGggdG8gdGhlIG1vYmlsaXR5IGV2ZW50DQo+PiAgIHNvIG9ubHkg dGhlIGxvY2FsIG5ldHdvcmsgZWxlbWVudHMgYXJlIGF3YXJlIG9mIHRoZSBjaGFuZ2VkIElQDQo+ PiAgIGFkZHJlc3MgYnV0IHRoZSByZW1vdGUgcGVlciBpcyB1bmF3YXJlIG9mIHRoZSBjaGFuZ2Vk IElQIGFkZHJlc3MuDQo+PiANCj4+ICAgVGhpcyBkcmFmdCBwcm92aWRlcyBzdWNoIGFuIElQIGFk ZHJlc3MgbW9iaWxpdHkgc29sdXRpb24gdXNpbmcNCj4+ICAgVHJhdmVyc2FsIFVzaW5nIFJlbGF5 cyBhcm91bmQgTkFUIChUVVJOKS4gIFRoaXMgaXMgYWNoaWV2ZWQgYnkNCj4+ICAgYWxsb3dpbmcg YSBjbGllbnQgdG8gcmV0YWluIGFuIGFsbG9jYXRpb24gb24gdGhlIFRVUk4gc2VydmVyIHdoZW4g dGhlDQo+PiAgIElQIGFkZHJlc3Mgb2YgdGhlIGNsaWVudCBjaGFuZ2VzLg0KPj4gDQo+PiANCj4+ IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm4tbW9i aWxpdHkvDQo+PiANCj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxl IGF0Og0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJu LW1vYmlsaXR5LTAwDQo+PiANCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4+IA0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHRyYW0gbWFpbGluZyBsaXN0DQo+PiB0cmFtQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJh bUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0N Cg0K From nobody Wed Jan 27 06:12:52 2016 Return-Path: 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 33DA21B2E8D for ; Wed, 27 Jan 2016 06:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nTI_bULxVVFp for ; Wed, 27 Jan 2016 06:12:43 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BE11B2E8C for ; Wed, 27 Jan 2016 06:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6696; q=dns/txt; s=iport; t=1453903963; x=1455113563; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V9sifw1vg1l093JzqDhqZ7yDUvRB8Cpoz98kHPw1wuM=; b=c42nhZBjxBxTzISwFnW+t6D62r8Szo0phicC2tdnQvXXo3HSo7j1nDnN y/o5L0kgku8gecNKv/NZkuc4PCmqPF6PczkLu1EVJEUNBzUKCfcGf3pS+ 5beoxkD6W2JNyFJWn0e1ALQ7bSywKkel7HyjGxEERketChh3Jj+gWVjl9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQAL0KhW/xbLJq1ehAxtBohRsU4BD?= =?us-ascii?q?YFiGAqFbQIcgWEUAQEBAQEBAYEKhEEBAQEDAQEBASAROgsFCwIBCBgCAiYCAgI?= =?us-ascii?q?lCxUQAgQOBRuHeAgOrjOPLwEBAQEBAQEBAQEBAQEBAQEBAQEBARV7hRmBbYJKh?= =?us-ascii?q?CEGEBiCayuBDwWWewGFRogPB4FYSoN6iFeOQgEeAQFCg2xqh0h9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,354,1449532800"; d="scan'208";a="631946334" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2016 14:12:39 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0RECc3w002094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2016 14:12:39 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Jan 2016 09:12:37 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Wed, 27 Jan 2016 09:12:37 -0500 From: "Pal Martinsen (palmarti)" To: Brandon Williams Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt Thread-Index: AQHRGd8PNyYawqYrh0qti/HaNjIsw58IeWgAgAfANYA= Date: Wed, 27 Jan 2016 14:12:37 +0000 Message-ID: References: <20151108043622.19002.79331.idtracker@ietfa.amsl.com> <56A24FDA.9000806@akamai.com> In-Reply-To: <56A24FDA.9000806@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.220.158] Content-Type: text/plain; charset="utf-8" Content-ID: <63E258A6F7F24B4AA9D897D564F30C57@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 14:12:48 -0000 DQpUaGFua3MgZm9yIHJldmlldyBhbmQgY29tbWVudHMNCj4gT24gMjIgSmFuIDIwMTYsIGF0IDE2 OjUwLCBCcmFuZG9uIFdpbGxpYW1zIDxicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+IHdyb3Rl Og0KPiANCj4gSSd2ZSBnb3QgYSBjb3VwbGUgb2YgY29tbWVudHMgb24gdGhlIGN1cnJlbnQgdmVy c2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBzMy4xLjINCj4gVGhlIGN1cnJlbnQgdGV4dCBoYXMg c29tZSBkaXNjdXNzaW9uIG9mIHBhdGggTVRVIGFuZCBTVFVOIG1lc3NhZ2Ugc2l6ZSANCj4gcmVz dHJpY3Rpb25zIHRoYXQgcmVsYXRlcyB0byByZXF1aXJlbWVudHMgdGhhdCBJIHRoaW5rIHdlIGhh dmUgDQo+IHByZXZpb3VzbHkgZGVjaWRlZCB0byByZWxheC4gSWYgbXkgbWVtb3J5IGlzIGNvcnJl Y3QsIHdlIGRlY2lkZWQgaW4gDQo+IERhbGxhcyB0byBhbGxvdyByZXF1ZXN0L3Jlc3BvbnNlIG1l c3NhZ2VzIHRvIGFzc3VtZSByZWFzb25hYmxlIHBhdGggTVRVIA0KPiB2YWx1ZXMgKHJhdGhlciB0 aGFuIHRoZSBJUHY0IG1pbmltdW0pLCBzbyB3ZSBtaWdodCB3YW50IHRvIGF2b2lkIA0KPiByZWl0 ZXJhdGluZyBsaW1pdGluZyBndWlkYW5jZSBmcm9tIFJGQzUzODkuIEkgY2FuJ3QgZmluZCByZWZl cmVuY2UgdG8gDQo+IHRoaXMgZGVjaXNpb24gaW4gdGhlIG1lZXRpbmcgbWludXRlcyBmcm9tIERh bGxhcywgdGhvdWdoLCBzbyBtYXliZSBJJ20gDQo+IG1pc3Rha2VuLiBOZXZlcnRoZWxlc3MsIGl0 J3MgcHJvYmFibHkgYmV0dGVyIHRvIGp1c3QgbWVudGlvbiB0aGF0IHlvdSANCj4gY2FuJ3QgYXNz dW1lIE1UVXMgYXJlIHRoZSBzYW1lIGFuZCBwb2ludCB0byBSRkM1Mzg5IGZvciBmdXJ0aGVyIA0K PiBndWlkYW5jZSwgcmF0aGVyIHRoYW4gcmVwZWF0aW5nIHJlcXVpcmVtZW50cyBsYW5ndWFnZS4N Cj4gDQoNCisxLiBTaG91bGQgYmUgZml4ZWQgdXAgaW4gdGhlIGRvY3VtZW50Lg0KDQo+IHMzLjIu Mg0KPiBBIGNvbW1vbiB1c2UgY2FzZSBmb3IgbW9iaWxpdHkgd2lsbCBsaWtlbHkgYmUgd2hhdCBz b21lIGhhdmUgZGVzY3JpYmVkIA0KPiBhcyB0aGUgIndhbGsgb3V0IHRoZSBkb29yIiBwcm9ibGVt LiBUd28gaW50ZXJmYWNlcyBhcmUgZnVuY3Rpb25hbCAoZS5nLiANCj4gYm90aCB3aWZpIGFuZCBs dGUpIGFuZCB5b3Ugd2FudCB0byBzZWFtbGVzc2x5IHN3aXRjaCBmcm9tIG9uZSB0byB0aGUgDQo+ IG90aGVyLiBZb3UgcHJvYmFibHkgd2FudCB0byBiZSBhYmxlIHRvIHVzZSBib3RoIGludGVyZmFj ZXMgYXQgdGhlIHNhbWUgDQo+IHRpbWUgd2hpbGUgeW91J3JlIGZpZ3VyaW5nIG91dCB3aGV0aGVy L3doZW4gdG8gc3dpdGNoIGZyb20gb25lIHRvIHRoZSANCj4gb3RoZXIgKG1ha2UgYmVmb3JlIGJy ZWFrKS4gSSBkb24ndCB0aGluayB0aGUgY3VycmVudCB0ZXh0IHN1cHBvcnRzIHRoaXMsIA0KPiBz aW5jZSBpdCBpbmRpY2F0ZXMgdGhhdCAxKSB0aGUgdHVwbGUgZm9yIHRoZSBhbGxvY2F0aW9uIHNo b3VsZCBiZSANCj4gdXBkYXRlZCBhbmQgMikgdGhlIG9sZCB0aWNrZXQgY2FuIG9ubHkgYmUgdXNl ZCBmb3IgcmV0cmFuc21pc3Npb24uIElmIA0KPiBJJ20gbWlzdW5kZXJzdGFuZGluZyB0aGUgaW50 ZW50IG9mIHRoZSB0ZXh0LCB0aGVuIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gDQo+IHNlZSBzb21l IGV4cGxpY2l0IGRpc2N1c3Npb24gb2YgdGhpcyB1c2UgY2FzZS4NCj4gDQpIbW0uIEkgdGhpbmsg eW91IGFyZSByaWdodC4gV2lsbCB0cnkgdG8gd3JpdGUgdXAgc29tZXRoaW5nLg0KDQo+IEZpbmFs bHkgKHNhbWUgc2VjdGlvbiksIHdoaWxlIEkgY2FuIHNlZSB0aGUgdmFsdWUgb2YgbWFpbnRhaW5p bmcgdGhlIA0KPiBleGlzdGluZyBhbGxvY2F0aW9uIHdoZW4gc3dpdGNoaW5nIGJldHdlZW4gaW50 ZXJmYWNlcy9hZGRyZXNzZXMsIA0KPiBzdGlja2luZyB0byB0aGF0IHJlbGF5IHNlcnZlciBjb3Vs ZCBiZSBhIGJhZCBpZGVhIGlmIHRoZXJlIGFyZSANCj4gb3RoZXIvYmV0dGVyIG9wdGlvbnMgZm9y IHRoZSBuZXcgYWRkcmVzcy4gVG8gc3VwcG9ydCBtYWtlIGJlZm9yZSBicmVhayANCj4gaW4gdGhp cyBjYXNlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIHJlbGF5IHNlcnZlciB0 byBiZSBhYmxlIA0KPiB0byBzZW5kIGFuIEFMVEVSTkFURS1TRVJWRVIgYXR0cmlidXRlIGluIGl0 cyBSZWZyZXNoIHJlc3BvbnNlIG1lc3NhZ2UuIA0KPiBJT1csIGFsbG93IHRoZSBjbGllbnQgdG8g Y29udGludWUgdXNpbmcgdGhlIG5ldyBhbGxvY2F0aW9uLCBidXQgYWxzbyBsZXQgDQo+IGl0IGtu b3cgdGhhdCBhIGRpZmZlcmVudC9iZXR0ZXIgcmVsYXkgaXMgYXZhaWxhYmxlIGZvciB0aGF0IGFk ZHJlc3MuIA0KPiBUaGVyZSB3b3VsZCBsaWtlbHkgYmUgc29tZSBJQ0Ugd29yayBhc3NvY2lhdGVk IHdpdGggc3VwcG9ydGluZyBzdWNoIGFuIA0KPiBvcHRpb24sIHNvIG1heWJlIGl0IGJlbG9uZ3Mg aW4gYSBzZXBhcmF0ZSBtb3JlLWdlbmVyYWwgZG9jIHNpbmNlIA0KPiB0dXJuLW1vYmlsaXR5IGlz IHVzZWZ1bCB3aXRob3V0IGl0LCBidXQgaXQgc2VlbWVkIHdvcnRoIGJyaW5naW5nIHVwIGluIA0K PiB0aGlzIGNvbnRleHQuDQo+IA0KWWVzLCB0aGUgaW50ZW50aW9uIHdhcyB0byBoYXZlIGEgTUlD RSBkcmFmdCAoTW9iaWxpdHkgZm9yIElDRSkgdGhhdCBjb3ZlcnMgc29tZSBvZiB0aG9zZSB1c2Ut Y2FzZXMuIEJ1dCB3ZSBhcmUgd2FpdGluZyBmb3IgYWxsIHRoZSB0cmlja2xlIGFuZCBub21pbmF0 aW9uIGRpc2N1c3Npb25zIHRvIGZpbmFsaXNlIHRvIHNlZSBpZiB0aGVyZSBpcyBhY3R1YWxseSBh IG5lZWQgZm9yIGEgbW9iaWxpdHkgZXh0ZW5zaW9uLiANCg0KLi0uDQpQw6VsLUVyaWsNCg0KPiAt LUJyYW5kb24NCj4gDQo+IE9uIDExLzA3LzIwMTUgMTE6MzYgUE0sIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyB3cm90ZToNCj4+IA0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVFVSTiBSZXZpc2VkIGFuZCBNb2Rlcm5pemVkIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+PiANCj4+ICAgICAgIFRpdGxlICAgICAgICAgICA6 IE1vYmlsaXR5IHdpdGggVFVSTg0KPj4gICAgICAgQXV0aG9ycyAgICAgICAgIDogRGFuIFdpbmcN Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgIFByYXNoYW50aCBQYXRpbA0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgVGlydW1hbGVzd2FyIFJlZGR5DQo+PiAgICAgICAgICAgICAgICAgICAg ICAgICBQYWFsLUVyaWsgTWFydGluc2VuDQo+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi10cmFtLXR1cm4tbW9iaWxpdHktMDAudHh0DQo+PiAJUGFnZXMgICAgICAgICAgIDogMTENCj4+ IAlEYXRlICAgICAgICAgICAgOiAyMDE1LTExLTA3DQo+PiANCj4+IEFic3RyYWN0Og0KPj4gIEl0 IGlzIGRlc2lyYWJsZSB0byBtaW5pbWl6ZSB0cmFmZmljIGRpc3J1cHRpb24gY2F1c2VkIGJ5IGNo YW5naW5nIElQDQo+PiAgYWRkcmVzcyBkdXJpbmcgYSBtb2JpbGl0eSBldmVudC4gIE9uZSBtZWNo YW5pc20gdG8gbWluaW1pemUNCj4+ICBkaXNydXB0aW9uIGlzIHRvIGV4cG9zZSBhIHNob3J0ZXIg bmV0d29yayBwYXRoIHRvIHRoZSBtb2JpbGl0eSBldmVudA0KPj4gIHNvIG9ubHkgdGhlIGxvY2Fs IG5ldHdvcmsgZWxlbWVudHMgYXJlIGF3YXJlIG9mIHRoZSBjaGFuZ2VkIElQDQo+PiAgYWRkcmVz cyBidXQgdGhlIHJlbW90ZSBwZWVyIGlzIHVuYXdhcmUgb2YgdGhlIGNoYW5nZWQgSVAgYWRkcmVz cy4NCj4+IA0KPj4gIFRoaXMgZHJhZnQgcHJvdmlkZXMgc3VjaCBhbiBJUCBhZGRyZXNzIG1vYmls aXR5IHNvbHV0aW9uIHVzaW5nDQo+PiAgVHJhdmVyc2FsIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFU IChUVVJOKS4gIFRoaXMgaXMgYWNoaWV2ZWQgYnkNCj4+ICBhbGxvd2luZyBhIGNsaWVudCB0byBy ZXRhaW4gYW4gYWxsb2NhdGlvbiBvbiB0aGUgVFVSTiBzZXJ2ZXIgd2hlbiB0aGUNCj4+ICBJUCBh ZGRyZXNzIG9mIHRoZSBjbGllbnQgY2hhbmdlcy4NCj4+IA0KPj4gDQo+PiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLW1vYmlsaXR5Lw0KPj4gDQo+ PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eS0wMA0K Pj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiANCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB0cmFtIG1haWxpbmcg bGlzdA0KPj4gdHJhbUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFtDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== From nobody Wed Jan 27 06:18:51 2016 Return-Path: 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 440801B2EA2 for ; Wed, 27 Jan 2016 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 i5dTms8F1-ov for ; Wed, 27 Jan 2016 06:18:47 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9EA1B2EA3 for ; Wed, 27 Jan 2016 06:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1692; q=dns/txt; s=iport; t=1453904326; x=1455113926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=twlVSgPZUGPm5b8YSsGqpQIiK44YIM5YkCPR1RpHWgE=; b=AxbegL+HyjhIIDkv2aVTvTNR6tpqpMxndIFd7hz1Bxrb351eYJOwXYhu HTpFTBa/vl8xs/kBsUk/kpYZtoSmDfKLqLE+Bnjk8k7pm3pYLHNC88e4j lqLw8ov6dz48sBJaKCtMhj88Y4O7csWyKQawSOgFzs6xS3dkQqx+BdK3+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgBY0ahW/4UNJK1egzpSbQaIUbFCA?= =?us-ascii?q?Q2BYhgKhW0CgUU4FAEBAQEBAQGBCoRBAQEBAwEBAQFrCwULAgEIDgouJwslAgQ?= =?us-ascii?q?OBYgTCA69YwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhSBbQiCQoQUI4MugQ8BB?= =?us-ascii?q?JZ7AY1VgV+NG4VziE8BHgEBQoIAHIFQaocMPH0BAQE?= X-IronPort-AV: E=Sophos;i="5.22,354,1449532800"; d="scan'208";a="70991554" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jan 2016 14:18:45 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u0REIj6l014932 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2016 14:18:45 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Jan 2016 09:18:44 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Wed, 27 Jan 2016 09:18:44 -0500 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [tram] Size of ICE connectivity checks Thread-Index: AQHRWQgtPaQiFbHMm0u1AvdENMUyaJ8PvQKA Date: Wed, 27 Jan 2016 14:18:44 +0000 Message-ID: <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> In-Reply-To: <56A8C88A.1090305@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.220.158] Content-Type: text/plain; charset="Windows-1252" Content-ID: <476236E62BD695498A5606C9BEC478C0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 14:18:49 -0000 > On 27 Jan 2016, at 14:39, Simon Perreault wrote: >=20 > Le 2016-01-26 22:41, Marc Petit-Huguenin a =E9crit : >>> s 14.4/14.5 There has been some discussion in mmusic about trying to >>>> compress ICE connectivity checks. Justin presented on this. IIRC, one >>>> of his proposals was to shrink the size of the ICV. It would be good >>>> to follow up on this and perhaps update stunbis to allow ICV's that >>>> are shorter. >> Here's the conclusions (from MMUSIC minutes) of the discussion about tha= t in Prague: >>=20 >> "Next steps: We need to discuss more on the approach and get back. Look = further into what we can do with ufrag, etc. How much can we reduce packet = size safely?" >>=20 >> I do not think that there is consensus enough to take any action at this= point. >=20 > I am seizing this opportunity to restart discussion on this topic. I > think we've discussed many possibilities, and what is needed at this > moment is an actual concrete text proposal. I don't think it's > necessarily up to the draft editors to come up with such a proposal, but > rather up to the working group as a whole. >=20 > Discuss. :) I think limiting the size to a reasonable value is fine. A smaller limit to= UFRAG and so on is simple and nice.=20 I do not think putting much effort into saving a few bytes is worth it at t= his point in time. Let us save that for later if we want to tackle ICEv2 wi= th a different connectivity check format.=20 .-. P=E5l-Erik >=20 > Thanks, > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jan 27 07:01:45 2016 Return-Path: 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 5F6071B2F31 for ; Wed, 27 Jan 2016 07:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4MIggZuGMWU9 for ; Wed, 27 Jan 2016 07:01:41 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0EA1B2F2B for ; Wed, 27 Jan 2016 07:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5787; q=dns/txt; s=iport; t=1453906900; x=1455116500; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=18R7xB/B/Iaz9IrBiKsORIAG+d3a1sdJKnd6RE/HLI8=; b=YyVUpE9O7btxVoDGQP3RRwvB94nODliTAPR3U0hjjoaNk0s5xAZcfNM4 8DmTMzG+ZTITgM2Oe1eqMJheDLdgWc500MGCzNlDVr/Gd13BXbS7Ga6RS j+U9EWEa2Kz9RbLSS8o5MBx6qzdpFXcGUmvbpz2S5vckspmTbd2ZC0hcV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgDq2qhW/5FdJa1egzpSbQaIUbE+A?= =?us-ascii?q?Q2BYhgKhW0CgUg4FAEBAQEBAQGBCoRBAQEBAwEBAQE3NBAHBgEIEQQBAQEeCS4?= =?us-ascii?q?LFAkJAQQBEggTh3gIDr1lAQEBAQEBAQEBAQEBAQEBAQEBAReGFIQ3hCEGhE0Fl?= =?us-ascii?q?nsBhUaICIFmSoN6iFeOQgEeAQFCg2xqAYdHfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,354,1449532800"; d="scan'208";a="231901848" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2016 15:01:39 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0RF1dHW028915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2016 15:01:39 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Jan 2016 09:01:38 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Wed, 27 Jan 2016 09:01:38 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Brandon Williams (bowill@akamai.com)" , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt Thread-Index: AdFZE5vdeHWfvKN5RDWTgAWASP6Syg== Date: Wed, 27 Jan 2016 15:01:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.43.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 15:01:44 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, January 22, 2016 9:21 PM > To: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt >=20 > I've got a couple of comments on the current version of the draft. >=20 > s3.1.2 > The current text has some discussion of path MTU and STUN message size > restrictions that relates to requirements that I think we have previously > decided to relax. If my memory is correct, we decided in Dallas to allow > request/response messages to assume reasonable path MTU values (rather > than the IPv4 minimum), so we might want to avoid reiterating limiting > guidance from RFC5389.=20 https://tools.ietf.org/html/draft-ietf-tram-stunbis-02 continues to have th= e same limiting guidance from RFC5389. Even new protocols like COAP suggest= implementations to have the same limitation https://tools.ietf.org/html/rf= c7252#section-4.6. > I can't find reference to this decision in the meeting > minutes from Dallas, though, so maybe I'm mistaken. Nevertheless, it's > probably better to just mention that you can't assume MTUs are the same > and point to RFC5389 for further guidance, rather than repeating > requirements language. I don't see a harm repeating the point, it reminds implementers to design t= he ticket with a small size.=20 >=20 > s3.2.2 > A common use case for mobility will likely be what some have described as > the "walk out the door" problem. Two interfaces are functional (e.g. > both wifi and lte) and you want to seamlessly switch from one to the othe= r. > You probably want to be able to use both interfaces at the same time whil= e > you're figuring out whether/when to switch from one to the other (make > before break).=20 I don't see a problem. Applications can pick both interfaces, create multip= le allocations, try connectivity checks on both interfaces, draft-ietf-tram= -stun-path-data and MPRTP can be used to pick interface based on path chara= cteristics. Keep the alternate candidates pair alive for switch-over and us= e ICE continuous nomination for seamless move. > I don't think the current text supports this, since it indicates > that 1) the tuple for the allocation should be updated and 2) the old tic= ket > can only be used for retransmission. If I'm misunderstanding the intent o= f > the text, then it would be helpful to see some explicit discussion of thi= s use > case. >=20 > Finally (same section), while I can see the value of maintaining the exis= ting > allocation when switching between interfaces/addresses, sticking to that > relay server could be a bad idea if there are other/better options for th= e new > address. To support make before break in this case, I think it would be u= seful > for the relay server to be able to send an ALTERNATE-SERVER attribute in = its > Refresh response message. > IOW, allow the client to continue using the new allocation, but also let = it > know that a different/better relay is available for that address. Yes, but TURN service provider should have capabilities discussed in draft-= williams-peer-redirect to pick an alternate TURN server; if the WG sees int= erest in peer-redirect we can propose Refresh response message to optionall= y signal ALTERNATE-SERVER attribute. -Tiru > There would likely be some ICE work associated with supporting such an > option, so maybe it belongs in a separate more-general doc since turn- > mobility is useful without it, but it seemed worth bringing up in this co= ntext. >=20 > --Brandon >=20 > On 11/07/2015 11:36 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. > > > > Title : Mobility with TURN > > Authors : Dan Wing > > Prashanth Patil > > Tirumaleswar Reddy > > Paal-Erik Martinsen > > Filename : draft-ietf-tram-turn-mobility-00.txt > > Pages : 11 > > Date : 2015-11-07 > > > > Abstract: > > It is desirable to minimize traffic disruption caused by changing I= P > > address during a mobility event. One mechanism to minimize > > disruption is to expose a shorter network path to the mobility even= t > > so only the local network elements are aware of the changed IP > > address but the remote peer is unaware of the changed IP address. > > > > This draft provides such an IP address mobility solution using > > Traversal Using Relays around NAT (TURN). This is achieved by > > allowing a client to retain an allocation on the TURN server when t= he > > IP address of the client changes. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-00 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jan 27 08:30:17 2016 Return-Path: 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 8C43C1A8ABE for ; Wed, 27 Jan 2016 08:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 sln8v3rbHdCg for ; Wed, 27 Jan 2016 08:30:14 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11731A8AB8 for ; Wed, 27 Jan 2016 08:30:14 -0800 (PST) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0RGLS2Y024195; Wed, 27 Jan 2016 11:29:58 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 20m4fxtfbg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jan 2016 11:29:58 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 27 Jan 2016 10:29:57 -0600 From: Jonathan Lennox To: Marc Petit-Huguenin Thread-Topic: [tram] Comments on draft-ietf-tram-stunbis-04 Thread-Index: AQHQw0FpsJW7qRa9w02/jU2lMPei7p8QRtIAgADXLAA= Date: Wed, 27 Jan 2016 16:29:57 +0000 Message-ID: References: <56A83C06.2000800@acm.org> In-Reply-To: <56A83C06.2000800@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <2AF67F9973A98541800C2B5714DAF347@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-01-27_04:2016-01-25,2016-01-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1601270267 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-stunbis-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 16:30:16 -0000 DQo+IE9uIEphbiAyNiwgMjAxNiwgYXQgMTA6MzkgUE0sIE1hcmMgUGV0aXQtSHVndWVuaW4gPHBl dGl0aHVnQGFjbS5vcmc+IHdyb3RlOg0KPiANCj4+IA0KPj4gU2VjdGlvbiA5LjEuMzoNCj4+IA0K Pj4g4oCcSWYgdGhlIE1FU1NBR0UtSU5URUdSSVRZLVNIQTI1NiBhdHRyaWJ1dGUgaXMgcHJlc2Vu dCBjb21wdXRlIHRoZSANCj4+IHZhbHVlIGZvciB0aGUgbWVzc2FnZSBpbnRlZ3JpdHkgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMTQuNSwgdXNpbmcNCj4+IHRoZSBwYXNzd29yZCBhc3NvY2lhdGVk IHdpdGggdGhlIHVzZXJuYW1lLiBJZiB0aGUgTUVTU0FHRS0gDQo+PiBJTlRFR1JJVFktU0hBMjU2 IGF0dHJpYnV0ZSBpcyBub3QgcHJlc2VudCwgYW5kIHVzaW5nIHRoZSBzYW1lIA0KPj4gcGFzc3dv cmQsIGNvbXB1dGUgdGhlIHZhbHVlIGZvciB0aGUgbWVzc2FnZSBpbnRlZ3JpdHkgYXMgZGVzY3Jp YmVkIGluDQo+PiBTZWN0aW9uIDE0LjQuIElmIHRoZSByZXN1bHRpbmcgdmFsdWUgZG9lcyBub3Qg bWF0Y2ggdGhlIGNvbnRlbnRzIG9mDQo+PiB0aGUgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2IGF0 dHJpYnV0ZSBvciB0aGUgTUVTU0FHRS0gSU5URUdSSVRZDQo+PiBhdHRyaWJ1dGU64oCdDQo+PiAN Cj4+IElzIHRoaXMgc2F5aW5nIHRoYXQgYSBTSEEtMSBtZXNzYWdlIGludGVncml0eSB2YWx1ZSAo ZGVzY3JpYmVkIGluDQo+PiBTZWN0aW9uIDE0LjQpIGNhbiBiZSBjYXJyaWVkIGluIGEgTUVTU0FH RS1JTlRFR1JJVFktU0hBMjU2IGF0dHJpYnV0ZT8NCj4+IFRoYXQgZG9lc27igJl0IHNlZW0gcmln aHQuDQo+PiANCj4gDQo+IENhbiB5b3UgcGxlYXNlIHN1Z2dlc3Qgc29tZSB0ZXh0IHRoYXQgd291 bGQgbWFrZSBpdCBjbGVhcmVyIHRoYXQgdGhpcyBpcyBub3QgdGhlIGludGVuZGVkIG1lYW5pbmc/ ICBXZSBmYWlsIHRvIHNlZSBob3cgdGhpcyBjb25jbHVzaW9uIGNhbiBiZSBtYWRlIGZyb20gdGhl IHRleHQuDQoNCk15IHByb2JsZW0gaXMgd2l0aCB0aGUgcGhyYXNlIOKAnElmIHRoZSByZXN1bHRp bmcgdmFsdWUgZG9lcyBub3QgbWF0Y2ggdGhlIGNvbnRlbnRzIG9mIHRoZSBNRVNTQUdFLUlOVEVH UklUWS1TSEEyNTYgYXR0cmlidXRlIG9yIHRoZSBNRVNTQUdFLUlOVEVHUklUWSBhdHRyaWJ1dGUs 4oCdIHdoaWNoIGltcGxpZXMgdG8gbWUgdGhhdCB0aGUgY2FsY3VsYXRlZCBtZXNzYWdlIGludGVn cml0eSB2YWx1ZSBpcyBjb21wYXJlZCB3aXRoIHRoZSBjb250ZW50IG9mIGJvdGggYXR0cmlidXRl cy4NCg0KUGVyaGFwcyDigJxJZiB0aGUgcmVzdWx0aW5nIHZhbHVlIGRvZXMgbm90IG1hdGNoIHRo ZSBjb250ZW50cyBvZiB0aGUgY29ycmVzcG9uZGluZyBhdHRyaWJ1dGUgKE1FU1NBR0UtSU5URUdS SVRZLVNIQTI1NiBvciBNRVNTQUdFLUlOVEVHUklUWSk6Ig0KDQo+PiBTZWN0aW9uIDkuMS40Og0K Pj4gDQo+PiDigJxUaGUgY2xpZW50IGxvb2tzIGZvciB0aGUgTUVTU0FHRS1JTlRFR1JJVFktU0hB MjU2IG9yIHRoZSBNRVNTQUdFLSANCj4+IElOVEVHUklUWSBhdHRyaWJ1dGUgaW4gdGhlIHJlc3Bv bnNlLiBJZiBwcmVzZW50LCB0aGUgY2xpZW50IGNvbXB1dGVzDQo+PiB0aGUgbWVzc2FnZSBpbnRl Z3JpdHkgb3ZlciB0aGUgcmVzcG9uc2UgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDE0LjQNCj4+IG9y IFNlY3Rpb24gMTQuNSwgdXNpbmcgdGhlIHNhbWUgcGFzc3dvcmQgaXQgdXRpbGl6ZWQgZm9yIHRo ZSByZXF1ZXN0Lg0KPj4gSWYgdGhlIHJlc3VsdGluZyB2YWx1ZSBtYXRjaGVzIHRoZSBjb250ZW50 cyBvZiB0aGUgTUVTU0FHRS1JTlRFR1JJVFkNCj4+IG9yIE1FU1NBR0UtSU5URUdSSVRZLVNIQTI1 NiBhdHRyaWJ1dGUsIHRoZSByZXNwb25zZSBpcyBjb25zaWRlcmVkIA0KPj4gYXV0aGVudGljYXRl ZC4gSWYgdGhlIHZhbHVlIGRvZXMgbm90IG1hdGNoLCBvciBpZiBib3RoIE1FU1NBR0UtIA0KPj4g SU5URUdSSVRZIGFuZCBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgd2VyZSBhYnNlbnQsIHRoZSBy ZXNwb25zZSBNVVNUDQo+PiBiZSBkaXNjYXJkZWQsIGFzIGlmIGl0IHdhcyBuZXZlciByZWNlaXZl ZC4gVGhpcyBtZWFucyB0aGF0IA0KPj4gcmV0cmFuc21pdHMsIGlmIGFwcGxpY2FibGUsIHdpbGwg Y29udGludWUu4oCdDQo+PiANCj4+IFBhcmFsbGVsaXNtIGZhaWx1cmUuIFNvbWV0aW1lcyBNRVNT QUdFLUlOVEVHUklUWSBpcyBsaXN0ZWQgZmlyc3QsIGFuZA0KPj4gc29tZXRpbWVzIE1FU1NBR0Ut SU5URUdSSVRZLVNIQTI1Ni4gIElmIHJlYWQgbGl0ZXJhbGx5IGl0IHdvdWxkIHNlZW0NCj4+IHRv IGltcGx5IHlvdSB3ZXJlIHN3YXBwaW5nIHRoZSB2YWx1ZXMuICBUaGUgdHdvIGFsZ29yaXRobXMg c2hvdWxkIGJlDQo+PiBjb25zaXN0ZW50bHkgbGlzdGVkIGluIG9yZGVyLCBhbmQgaXQgc2hvdWxk IGJlIG1hZGUgY2xlYXIgdGhhdCB0aGV5DQo+PiBhcHBseSByZXNwZWN0aXZlbHkuDQo+IA0KPiBG aXhlZC4NCg0KSSB3b3VsZCBhbHNvIGFkZCDigJwscmVzcGVjdGl2ZWx5LOKAnSB0d2ljZSwgb25j ZSBhZnRlciDigJxTZWN0aW9uIDE0LjXigJ0gYW5kIG9uY2UgYmVmb3JlIOKAnHRoZSByZXNwb25z ZSBpcyBjb25zaWRlcmVk4oCdLg0KDQoNCj4+IA0KPj4gQWRkaXRpb25hbGx5LCBpdCBzaG91bGQg c2F5IHRoYXQgaWYgdGhlIGNsaWVudCBvbmx5IHNlbnQgb25lDQo+PiBhbGdvcml0aG0gaW4gdGhl IHJlcXVlc3QgKGJlY2F1c2Ugb2YgdGhlIGV4dGVybmFsIGluZGljYXRpb24gaW4NCj4+IHNlY3Rp b24gOS4xLjIsIG9yIHRoaXMgYmVpbmcgYSBzdWJzZXF1ZW50IHJlcXVlc3QgYXMgZGVmaW5lZCBp bg0KPj4gOS4xLjUpIHRoZSBhbGdvcml0aG0gaW4gdGhlIHJlc3BvbnNlIGhhcyB0byBtYXRjaC4N Cj4gDQo+IEZpeGVkLg0KDQpJIHdvdWxkIGFkZCDigJxvdGhlcndpc2UgdGhlIHJlc3BvbnNlIE1V U1QgYmUgZGlzY2FyZGVk4oCdIHRvIHRoZSBuZXcgc2VudGVuY2UgeW91IGFkZGVkLg0KDQo+PiBb TXkgb3JpZ2luYWwgY29tbWVudHMgb24gcGFzc3dvcmQgYWxnb3JpdGhtIG9taXR0ZWRdDQo+IA0K PiBUaGVzZSB3ZXJlIHRvdWdoLCBidXQgd2UgdGhpbmsgdGhhdCB3ZSBjYXB0dXJlZCB0aGUgZXNz ZW5jZSBvZiB5b3VyIGNvbmNlcm5zLiBCdXQgcGxlYXNlIGhhdmUgYSBsb29rIGF0IHRoZSBuZXcg dGV4dC4NCg0KVGhlc2UgZ2VuZXJhbGx5IHNlZW0gYSBsb3QgYmV0dGVyLiAgQSBmZXcgY29tbWVu dHMgb24gdGhlIG5ldyBjb250ZW50Og0KDQrigJxJZiB0aGUgTk9OQ0UgYXR0cmlidXRlIHN0YXJ0 cyB3aXRoIHRoZSB2YWx1ZSAib2JNYXRKb3MyIiBidXQJDQpQQVNTV09SRC1BTEdPUklUSE1TIGRv ZXMgbm90IG1hdGNoLCB0aGVuIHRoZSBzZXJ2ZXIgTVVTVCBnZW5lcmF0ZQkNCmFuIGVycm9yIHJl c3BvbnNlIHdpdGggYW4gZXJyb3IgY29kZSBvZiA0MDAgKEJhZCBSZXF1ZXN0KS7igJ0NCg0KVGhp cyBkb2VzbuKAmXQgc2F5IHdoYXQgdGhlIFBBU1NXT1JELUFMR09SSVRITVMgaGFzIHRvIG1hdGNo IChpdCBnb3QgbG9zdCBpbiB0aGUgY29udmVyc2lvbikuICBQcmVzdW1hYmx5IOKAnGRvZXMgbm90 IG1hdGNoIHRoZSB2YWx1ZSBpbiBzZW50IGluIHRoZSByZXNwb25zZSB0aGF0IHNlbnQgdGhpcyBO T05DReKAnT8NCg0K4oCcSWYgdGhlIE5PTkNFIGF0dHJpYnV0ZSBzdGFydHMgd2l0aCB0aGUgdmFs dWUgIm9iTWF0Sm9zMiIgYnV0IHRoZSByZXF1ZXN0IGNvbnRhaW5zIG5laXRoZXIgUEFTU1dPUkQt QUxHT1JJVEhNUyBub3IgUEFTU1dPUkQtQUxHT1JJVEhNLCB0aGVuIHRoZSByZXF1ZXN0IGlzIHBy b2Nlc3NlZCBhcyB0aG91Z2ggUEFTU1dPUkQtQUxHT1JJVEhNIHdlcmUgTUQ1LuKAnQ0KDQpJIG1p Z2h0IGFkZCDigJwoTm90ZSB0aGF0IGlmIHRoZSBvcmlnaW5hbCBQQVNTV09SRC1BTEdPUklUSE1T IGF0dHJpYnV0ZSBkaWQgbm90IGNvbnRhaW4gTUQ1LCB0aGlzIHdpbGwgcmVzdWx0IGluIGEgNDAw IEJhZCBSZXF1ZXN0IGluIGEgbGF0ZXIgc3RlcCBiZWxvdy4p4oCdLCBidXQgdGhpcyBpcyBlZGl0 b3JpYWwgYW5kIEkgbGVhdmUgaXQgdG8geW91ciBkaXNjcmV0aW9uLg0KDQoiSWYgdGhlIE5PTkNF IGlzIG5vIGxvbmdlciB2YWxpZCwgdGhlIHNlcnZlciBNVVNUIGdlbmVyYXRlIGFuIGVycm9yIHJl c3BvbnNlIHdpdGggYW4gZXJyb3IgY29kZSBvZiA0MzggKFN0YWxlIE5vbmNlKS4gIFRoaXMgcmVz cG9uc2UgTVVTVCBpbmNsdWRlIE5PTkNFIGFuZCBSRUFMTSBhdHRyaWJ1dGVz4oCdDQoNCk1VU1Qg aW5jbHVkZSBQQVNTV09SRC1BTEdPUklUSE1TIGFzIHdlbGwuICBTaW1pbGFybHkgZm9yIHRoZSBn ZW5lcmF0ZWQgNDAxLg0KDQrigJxBbnkgcmVzcG9uc2UgZ2VuZXJhdGVkIGJ5IHRoZSBzZXJ2ZXIg KGV4Y2VwdGluZyB0aGUgY2FzZXMgd2hlcmUgYQkNCnNlcnZlciByZXNwb25kcyB3aXRoIGFuIGVy cm9yIGNvZGUsIHdoaWNoIGNhbm5vdCBiZSBhdXRoZW50aWNhdGVkKeKAnQ0KDQpSZW1vdmUgdGhl IGNvbW1hIOKAlCB0aGlzIHNob3VsZCBiZSBhIGRlcGVuZGVudCBjbGF1c2UsIHNpbmNlIHNvbWUg ZXJyb3IgY29kZXMgY2FuIGJlIGF1dGhlbnRpY2F0ZWQuICANCg0KQWN0dWFsbHksIG1vcmUgZ2Vu ZXJhbGx5LCBhbnkgcmVzcG9uc2UgYWZ0ZXIgdGhpcyBwb2ludCB3aWxsIGJlIGFibGUgdG8gYmUg YXV0aGVudGljYXRlZCwgc2luY2Ugd2XigJl2ZSBwYXNzZWQgYXV0aGVudGljYXRpb24uICBMb29r aW5nIGF0IHRoZSBkaWZmLCBJIHRoaW5rIHRoZSBlYXJsaWVyIGxhbmd1YWdlIGZvciB0aGUgcGFy ZW50aGV0aWNhbCBwaHJhc2Ug4oCcKGV4Y2VwdGluZyBpbiB0aGUgY2FzZXMgZGVzY3JpYmVkIGFi b3ZlKeKAnSB3YXMgYmV0dGVyLCBidXQgbW9yZSB3b3Jkc21pdGhpbmcgaXMgcG9zc2libGUuDQoN CuKAnE1VU1QgaW5jbHVkZSBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgYXR0cmlidXRlLCBjb21w dXRlZCB1c2luZyB0aGUJDQp1c2VybmFtZSBhbmQgcGFzc3dvcmQgdXRpbGl6ZWQgdG8gYXV0aGVu dGljYXRlIHRoZSByZXF1ZXN0LCB1bmxlc3MJDQp0aGUgcmVxdWVzdCB3YXMgcHJvY2Vzc2VkIGFz IHRob3VnaCBQQVNTV09SRC1BTEdPUklUSE0gd2FzIE1ENS4gSW4JDQp0aGF0IGNhc2UgdGhlIE1F U1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0ZSBNVVNUIGJlIHVzZWQgaW5zdGVhZCBvZiB0aGUJDQpN RVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgYXR0cmlidXRlLuKAnQ0KDQpJIHVuZGVyc3RhbmQgd2hh dCB5b3XigJlyZSBzYXlpbmcgYnV0IEkgdGhpbmsg4oCcd2FzIHByb2Nlc3NlZCBhcyB0aG91Z2gg UEFTU1dPUkQtQUxHT1JJVEhNIHdhcyBNRDXigJ0gaXMgYW1iaWd1b3VzLg0KDQpBbmQgYWN0dWFs bHksIHRoaW5raW5nIGFib3V0IGl0LCBpdCBzZWVtcyB0byBtZSB0aGF0IGZvciBsb25nLXRlcm0g YXV0aCwgdGhlcmXigJlzIG5ldmVyIGFueSBuZWVkIGZvciBjbGllbnRzIHRvIHNlbmQgYm90aCBN RVNTQUdFLUlOVEVHUklUWSBhbmQgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2IOKAlCB5b3Ugc2Vu ZCB0aGUgbGF0dGVyIGlmIHRoZXJlIHdhcyBhIFBBU1NXT1JELUFMR09SSVRITVMgYWNjb21wYW55 aW5nIHRoZSBub25jZSwgb3RoZXJ3aXNlIHRoZSBmb3JtZXIuICBJbiB3aGljaCBjYXNlIHRoZSBz ZXJ2ZXIganVzdCBtaXJyb3JzIHRoZSBjbGllbnQuDQoNCuKAnElmIHRoZSByZXNwb25zZSBpcyBh biBlcnJvciByZXNwb25zZSB3aXRoIGFuIGVycm9yIGNvZGUgb2YgNDAxDQooVW5hdXRob3JpemVk KSwgdGhlIGNsaWVudCBNVVNUIHRlc3QgaWYgdGhlIE5PTkNFIGF0dHJpYnV0ZSB2YWx1ZQ0Kc3Rh cnRzIHdpdGggdGhlIGNoYXJhY3RlciBzdHJpbmcgIm9iTWF0Sm9zMiIuICBJZiB0aGUgdGVzdCBz dWNjZWVkcw0KYW5kIG5vIFBBU1NXT1JELUFMR09SSVRITVMgYXR0cmlidXRlIGlzIHByZXNlbnQs IHRoZW4gdGhlIGNsaWVudCBNVVNUDQpOT1QgcmV0cnkgdGhlIHJlcXVlc3Qgd2l0aCBhIG5ldyB0 cmFuc2FjdGlvbi7igJ0NCg0KSSB0aGluayB0aGlzIHRlc3QgbmVlZHMgdG8gYXBwbHkgdG8gNDM4 IFN0YWxlIE5vbmNlIHRvbywgdG8gcHJldmVudCBpdCBiZWluZyB1c2VkIGZvciBiaWQtZG93bi4N Cg0KPj4gDQo+PiBTaG91bGQgd2UgZGVmaW5lIE1ENSBhcyBhIFBBU1NXT1JELUFMR09SSVRITSB2 YWx1ZT8gVGhlIHVzZSBjYXNlIGlzIGENCj4+IHNlcnZlciB0aGF0IHdhbnRzIHRvIHVwZ3JhZGUg dG8gc3R1bmJpcywgYnV0IHdhbnRzIHRvIGtlZXAgdXNpbmcgaXRzDQo+PiBleGlzdGluZyAobWQ1 LWhhc2hlZCkgcGFzc3dvcmQgZGF0YWJhc2Ugd2l0aG91dCBmb3JjaW5nIHVzZXJzIHRvDQo+PiBy ZS1lbnRlciB0aGVpciBwYXNzd29yZC4gIChUaGlzIHdvdWxkIG1lYW4gYSBjYXNlIHdoZXJlIGxv bmctdGVybQ0KPj4gYXV0aGVudGljYXRpb24gdXNlcyB0aGUgTUQ1IHBhc3N3b3JkIGFsZ29yaXRo bSwgYnV0DQo+PiBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYgaW50ZWdyaXR5LikNCj4+IA0KPiAN Cj4gT0suDQoNCkRlZmluaXRpb24gb2YgdGhlIGtleSBpcyB1c2luZyBTSEEyNTYuIDotKQ0KDQo+ IA0KPj4gDQo+PiBTZWN0aW9uIDE3LjU6DQo+PiANCj4+IFNob3VsZCByZWdpc3RlciB0aGUgc3R1 bnMgb3ZlciBVRFAgcG9ydC4NCj4gDQo+IE15IHVuZGVyc3RhbmRpbmcgKGZvbGxvd2luZyBhIGRp c2N1c3Npb24gd2l0aCBJQU5BIGluIERhbGxhcywgSUlSQykgaXMgdGhhdCBhcyB3ZSBzaG91bGQg b25seSB1cGRhdGUgdGhlIFJGQyA1Mzg5IHJlZ2lzdHJhdGlvbnMsIGFuZCBub3QgdGhlIFJGQyA3 MzUwIHJlZ2lzdHJhdGlvbi4NCg0KT2theS4NCg0KPj4gQSBnZW5lcmFsIHF1ZXN0aW9uIGFib3V0 IHRoZSBQQVNTV09SRC1BTEdPUklUSE0gdHJhbnNpdGlvbiBwcm9jZXNzOg0KPj4gZG8gd2Ugd2Fu dCB0byBzdXBwb3J0IHRoZSB1c2UgY2FzZSB3aGVyZSBhIHNlcnZlciBpcyBncmFkdWFsbHkNCj4+ IHRyYW5zaXRpb25pbmcgaXRzIGV4aXN0aW5nIGRhdGFiYXNlIHRvIGhhdmUgU0hBLTI1NiBhcyB0 aGUgcGFzc3dvcmQNCj4+IGhhc2ggYWxnb3JpdGhtIChhcyB1c2VycyBjaGFuZ2UgcGFzc3dvcmRz KT8gIFRoaXMgbWlnaHQgcmVzdWx0IGluIGENCj4+IGNhc2Ugd2hlcmUgc29tZSB1c2VycyBoYXZl IE1ENS1oYXNoZWQgcGFzc3dvcmRzIGluIHRoZSBkYXRhYmFzZSwgYW5kDQo+PiBzb21lIGhhdmUg U0hBLTI1NiDigJQgYnV0IHRoZSBzZXJ2ZXIgZG9lc27igJl0IHlldCBrbm93IHdoZW4gcmVzcG9u ZGluZw0KPj4gdG8gdGhlIGluaXRpYWwgcmVxdWVzdCB3aGljaCB1c2VyIGlzIG1ha2luZyB0aGUg cmVxdWVzdCwgYW5kIHRodXMNCj4+IHdoaWNoIHBhc3N3b3JkIGFsZ29yaXRobXMgYXJlIGFjdHVh bGx5IHN1cHBvcnRlZCBmb3IgdGhpcyBzcGVjaWZpYw0KPj4gdXNlci4gIFN1cHBvcnRpbmcgdGhp cyB3b3VsZCByZXF1aXJlIGVpdGhlciBwdXR0aW5nIFVTRVJOQU1FIGluIHRoZQ0KPj4gaW5pdGlh bCByZXF1ZXN0ICh3aGljaCBzZWVtcyBiYWQgaW4gdGhlIGFic2VuY2Ugb2YgYSBrbm93biByZWFs bSksIG9yDQo+PiBlbHNlIGFsbG93aW5nIGEgc2VydmVyIHRvIHJlc3BvbmQgdG8gYSBmb2xsb3d1 cCByZXF1ZXN0IHdpdGggYW5vdGhlcg0KPj4gNDAxIFVuYXV0aG9yaXplZCByZXNwb25zZSwgd2l0 aCBhIHNob3J0ZXIgUEFTU1dPUkQtQUxHT1JJVEhNUyBsaXN0DQo+PiAocmVzdWx0aW5nIGluIGxv bmctdGVybSBhdXRoZW50aWNhdGlvbiByZXF1aXJpbmcgdGhyZWUgdHJhbnNhY3Rpb25zDQo+PiBm b3Igc3R1bmJpcyBjbGllbnRzIHdob3NlIHVzZXJzIHdobyBhcmUgc3RpbGwgb24gTUQ1KS4gIERl c3BpdGUgdGhlDQo+PiB0cmlwbGUgdHJhbnNhY3Rpb24sIEnigJltIGluY2xpbmVkIHRvIHJlY29t bWVuZCB0aGUgbGF0dGVyLg0KPiANCj4gSW50ZXJlc3RpbmcgdXNlIGNhc2UgcmVnYXJkaW5nIHRo ZSBtYW5hZ2VtZW50IG9mIGFuIGh5YnJpZCBkYXRhYmFzZSBjb250YWluaW5nIG1peGVkIE1ENS9T SEEyNTYgdXNlcnMsIGJ1dCBpcyBpdCB3b3J0aCBhZGRpbmcgdGhhdCBjb21wbGV4aXR5IHRvIHRo ZSBwcm90b2NvbD8gIFdlJ3JlIHdpbGxpbmcgdG8gbGlzdGVuIHRvIG9waW5pb24gZnJvbSB0aGUg d29ya2luZyBncm91cCwgZXNwZWNpYWxseSBwZW9wbGUgd2l0aCBsYXJnZSBkZXBsb3ltZW50cy4N Cg0KVGhpcyBpcyBhdCB0aGUgZW5kIG9mIGEgbG9uZyBhbmQgZWRpdG9yaWFsIGUtbWFpbCwgc28g aXTigJlzIHByb2JhYmx5IHdvcnRoIGNhbGxpbmcgdGhpcyBvdXQgaW4gYSBzdGFuZGFsb25lIG1l c3NhZ2UuDQoNCg== From nobody Wed Jan 27 10:23:38 2016 Return-Path: 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 6DF451B2A93 for ; Wed, 27 Jan 2016 10:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Zyn3eQzlc-tw for ; Wed, 27 Jan 2016 10:23:36 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 760391B2A92 for ; Wed, 27 Jan 2016 10:23:36 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9487E3F4034; Wed, 27 Jan 2016 18:23:35 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 7DD433F4033; Wed, 27 Jan 2016 18:23:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453919015; bh=HP24Zo5MA3CNrnAdzTpJsjnCqIuuunHSWlx+4x1JC78=; l=2173; h=To:References:From:Date:In-Reply-To:From; b=IaGIcFTBL0TblZQCUgeswZVOQO0/qG0bVyoaRsjTaliyFnyIaUa0SiR999vjkyY+x Z+xp8A+KrFdhj3c1I2zM0n4huxVhSQsHQnPKahFXXEXQCoCoahiJeJFTyb3Qh04SHe cxKqFb78vPb9QDAUFb8V2/kn+4YXa7Q9dqLNFj0A= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 77EA5202C; Wed, 27 Jan 2016 18:23:35 +0000 (GMT) To: Marc Petit-Huguenin , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> From: Brandon Williams Message-ID: <56A90B27.9080502@akamai.com> Date: Wed, 27 Jan 2016 13:23:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56A83C5B.6010702@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 18:23:38 -0000 On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> s 6.1 This section still says "MTU constraint MUST be followed" >> language. I'm pretty sure that we decided to relax this constraint in >> Dallas, but I don't see it in the minutes. It seems to be implied by >> the decision about removing the SCTP requirement. > > My recollection was that the relaxation was linked to the introduction of the SCTP transport in STUN (which permitted safe fragmentation). Now that SCTP is gone, I am not sure that this decision stands alone. > IIRC, in Dallas we discussed MTU constraints in the context of both the SCTP requirement and the ORIGIN draft. The point was made that both small MTUs and fragment delivery failure are rare and that the existing requirements language is unnecessary. This was the foundation for removing the SCTP language and for removing some size constraint language from the ORIGIN draft. My understanding of the discussion was also that the group agreed to relax the existing RFC5389 constraint, at least for request/response message types. This really just applies to the following text: If the path MTU is unknown for UDP, messages SHOULD be the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [RFC5780]. Outside of this or similar applications, the MTU constraint MUST be followed. IOW, if you don't know the PMTU, an allocation request MUST be smaller than 576 bytes for IPv4. My sense of the room in Dallas was that we agreed this is an unnecessary restriction, at least for the request/response message types. So, what do others think/remember? Should we keep the existing requirement (in which case I think it will be important to consider this limitation whenever new attribute types are created)? Am I remembering correctly that we already decided to loosen the requirement and it just didn't make it into the notes for the meeting? --Brandon From nobody Wed Jan 27 10:25:59 2016 Return-Path: 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 04C661A9124 for ; Wed, 27 Jan 2016 10:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 bMZmSyN5Vx3a for ; Wed, 27 Jan 2016 10:25:56 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 1ED851A9121 for ; Wed, 27 Jan 2016 10:25:56 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id n1so10039596vkb.3 for ; Wed, 27 Jan 2016 10:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mPcK6UQKVcN+v3iTjLU/3KictK0ZFiXBl3plan7WgQc=; b=Jh17HoaiwLh1G1t27E9k679tokSCnFBiTxXqSI5VCdco565BnmEgEh1R3IHIcvBAI8 3hgQ0FbORfexbyCX+902Fg1QYL4ARm4MYHD3e6kOnYon63mBuvXUbb3qZW4wRllIWHTI YYel+rifftb5j2hSXc1zYrM8xE0H9f+/bLDbhQO78jQISW0odZ5aJGt57QUJ15gwpTxE 7+9DoE+AhpPWGt80znnVUQD1KNU0hDscU8GhGDwKGbVS5DLqeGzWIktY6hxRb5tYaQqY Kqyz11UNzoJ4yqi03bygN4swV4BUxbCLSjIn2FBS474aXQ1HN0Iux197iIfDKB2Du4cY 2aUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mPcK6UQKVcN+v3iTjLU/3KictK0ZFiXBl3plan7WgQc=; b=a1lmVX4xXb/Fy/2kOlvBRPCbXIX5bsak4UEQz0cKyF++BZ4S49vgAgG2QIShThTszl 03tB+BXSGiBbTn1ENPIvkxTZbkwc85A2+VPbdsNgsAdGRue2bgEtVy8Ywn/CG21Cb2GM y9aA1QEPLYIcO6JoaIVB5SMsyY5rKmegcS3D+NtQmvCW6/paDR5D2CdGkedrR9EtTPqI Bg20eSRVdoT7x/KuHyri8TTdGK504KJXO5JOysTvmzeLDP7jA1p/fPe8L8qLLHnK3GQv B4rWWeqVGjvZCxBzTAFe0UbVgUVEt+jCTRr6u82kgGYw9sRXK8i0eq+y0Rq4RkRHav3b O3Hg== X-Gm-Message-State: AG10YOR6OvhpadLTWA91DL1bFIahaxrMLOPsEc1O9GnHkqjK1aP2IbfDebU+FxNGPKWYikxS8XmLInCwiXgmaPQQ X-Received: by 10.31.58.139 with SMTP id h133mr18937974vka.158.1453919154957; Wed, 27 Jan 2016 10:25:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Wed, 27 Jan 2016 10:25:35 -0800 (PST) In-Reply-To: <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> From: Justin Uberti Date: Wed, 27 Jan 2016 10:25:35 -0800 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a11434d8cc3b7a9052a54ee03 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 18:25:58 -0000 --001a11434d8cc3b7a9052a54ee03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ufrag already has a 4-byte lower bound, so we can't really reduce that further. Here is my concrete proposal: https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5deb8ZXH= LJJpadBE/edit#slide=3Did.gc34db0b92_0_23 Basically: - truncate M-I - allow special case for 8-byte USERNAME - remove tiebreaker, fingerprint, priority attributes Possibly: - combine ICE-CONTROLLING and USERNAME - put M-I into transaction ID (for REQUEST; RESPONSE would still need to have an attribute) On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > > On 27 Jan 2016, at 14:39, Simon Perreault wrote: > > > > Le 2016-01-26 22:41, Marc Petit-Huguenin a =C3=A9crit : > >>> s 14.4/14.5 There has been some discussion in mmusic about trying to > >>>> compress ICE connectivity checks. Justin presented on this. IIRC, on= e > >>>> of his proposals was to shrink the size of the ICV. It would be good > >>>> to follow up on this and perhaps update stunbis to allow ICV's that > >>>> are shorter. > >> Here's the conclusions (from MMUSIC minutes) of the discussion about > that in Prague: > >> > >> "Next steps: We need to discuss more on the approach and get back. Loo= k > further into what we can do with ufrag, etc. How much can we reduce packe= t > size safely?" > >> > >> I do not think that there is consensus enough to take any action at > this point. > > > > I am seizing this opportunity to restart discussion on this topic. I > > think we've discussed many possibilities, and what is needed at this > > moment is an actual concrete text proposal. I don't think it's > > necessarily up to the draft editors to come up with such a proposal, bu= t > > rather up to the working group as a whole. > > > > Discuss. :) > > I think limiting the size to a reasonable value is fine. A smaller limit > to UFRAG and so on is simple and nice. > > I do not think putting much effort into saving a few bytes is worth it at > this point in time. Let us save that for later if we want to tackle ICEv2 > with a different connectivity check format. > > .-. > P=C3=A5l-Erik > > > > > Thanks, > > Simon > > > > _______________________________________________ > > 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 > --001a11434d8cc3b7a9052a54ee03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ufrag already has a 4-byte lower bound, so we can'= ;t really reduce that further.

Here is my concrete prop= osal:

Basically:
- truncate M-I
- allow special case for 8-byte USERNAME
- remove tiebreaker, fingerprint, priority attributes
Possibly:
- combine ICE-CONTROLLING and USERNAME
- put M-I into transaction ID (for REQUEST; RESPONSE would still nee= d to have an attribute)

On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti)= <palmarti@cisco.com> wrote:

> On 27 Jan 2016, at 14:39, Simon Perreault <sperreault@jive.com> wrote:
>
> Le 2016-01-26 22:41, Marc Petit-Huguenin a =C3=A9crit :
>>> s 14.4/14.5 There has been some discussion in mmusic about try= ing to
>>>> compress ICE connectivity checks. Justin presented on this= . IIRC, one
>>>> of his proposals was to shrink the size of the ICV. It wou= ld be good
>>>> to follow up on this and perhaps update stunbis to allow I= CV's that
>>>> are shorter.
>> Here's the conclusions (from MMUSIC minutes) of the discussion= about that in Prague:
>>
>> "Next steps: We need to discuss more on the approach and get = back. Look further into what we can do with ufrag, etc. How much can we red= uce packet size safely?"
>>
>> I do not think that there is consensus enough to take any action a= t this point.
>
> I am seizing this opportunity to restart discussion on this topic. I > think we've discussed many possibilities, and what is needed at th= is
> moment is an actual concrete text proposal. I don't think it's=
> necessarily up to the draft editors to come up with such a proposal, b= ut
> rather up to the working group as a whole.
>
> Discuss. :)

I think limiting the size to a reasonable value is fine. A smaller l= imit to UFRAG and so on is simple and nice.

I do not think putting much effort into saving a few bytes is worth it at t= his point in time. Let us save that for later if we want to tackle ICEv2 wi= th a different connectivity check format.

.-.
P=C3=A5l-Erik

>
> Thanks,
> Simon
>
> _______________________________________________
> 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

--001a11434d8cc3b7a9052a54ee03-- From nobody Wed Jan 27 11:06:12 2016 Return-Path: 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 CAAEC1B2EA0 for ; Wed, 27 Jan 2016 11:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3p9kQOb6CfBz for ; Wed, 27 Jan 2016 11:06:08 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC01B2E95 for ; Wed, 27 Jan 2016 11:06:08 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1DDBF423701; Wed, 27 Jan 2016 19:06:08 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 1026A3F4008; Wed, 27 Jan 2016 19:06:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453921568; bh=FcvGP23H6/SeGM4w+Uwcr30tVUJdru3NFUpjL0IcAfg=; l=2946; h=To:References:From:Date:In-Reply-To:From; b=kicuWTVjdhS+COFVheP1FLJx8akuMuUukhxy+w0yPqCAu7M4Ngn+lNO7MrP7vfFXl c4Hph4OAysExRWWU6PfALlvYfq2xEhgvwWLlfaNNgdaL2mvtLUcqlT6ztCqJTnJ4Ka d8oZlZc6qHKU7oVTeZwTuULXn94ExtT1TWV49NJ0= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 09CF0202E; Wed, 27 Jan 2016 19:06:08 +0000 (GMT) To: Marc Petit-Huguenin , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> From: Brandon Williams Message-ID: <56A9151F.3050009@akamai.com> Date: Wed, 27 Jan 2016 14:06:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56A83C5B.6010702@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Review of draft-ietf-tram-stunbis-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 19:06:11 -0000 Thanks Marc. I sent a separate message about the MTU requirements, since I think it seems to be a broader issue to me. There are some responses to other items below. All the rest looks good to me. --Brandon On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > >> s 9.2.3 The third bullet states 'If the NONCE attribute starts with >> the value "obMayJos2" but the PASSWORD-ALGORITHMS attribute is not >> present ... the server MUST generate an error response'. However, I >> don't see a way for the server to determine whether it's safe to >> require this when sending the PASSWORD-ALGORITHMS attribute. Maybe >> the third bullet's requirement can only be safely applied if >> MI-SHA256 is present. > > We are not sure we understand your point, but this section has been heavily rewritten following Jonathan review, so please check that your comment is still valid. > The new text (bullets 3 and 4) looks good to me. My concern was about supporting clients that don't support PASSWORD-ALGORITHMS. I see that you split the third bullet into two bullets and no longer require the server to send an error if PASSWORD-ALGORITHMS is not present, which satisfies the concern about clients that just don't support the functionality. >> >> s 14.4/14.5 There has been some discussion in mmusic about trying to >> compress ICE connectivity checks. Justin presented on this. IIRC, one >> of his proposals was to shrink the size of the ICV. It would be good >> to follow up on this and perhaps update stunbis to allow ICV's that >> are shorter. > > Here's the conclusions (from MMUSIC minutes) of the discussion about that in Prague: > > "Next steps: We need to discuss more on the approach and get back. Look further into what we can do with ufrag, etc. How much can we reduce packet size safely?" > > I do not think that there is consensus enough to take any action at this point. > Since the subject of shorter HMAC values has come up, I don't see any harm in stating that 16 and 32 bytes are the recommended values, but that a specific STUN usage MAY use a truncated HMAC. If the STUN usage does not explicitly allow truncated HMAC values, then the HMAC lengths MUST be 16 and 32. That said, I don't feel strongly about and certainly understand if you want to see a well defined and accepted use case before changing requirements. >> >> s 11 The text seems to describe backward compatibility with RFC3489, >> but the section title is "Backwards Compatibility with RFC 5389". > > We made a reference to the backward compatibility section of RFC 5389 (section 12), which is RFC 3489. The section is this document is about the backward compatibility to RFC 5389. > Both section 12 of 5389 and this section of stunbis describe backward compatibility with 3489. What in the section is about backward compatibility with 5389 STUN? From nobody Wed Jan 27 14:00:15 2016 Return-Path: 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 67DA41B2BE8 for ; Wed, 27 Jan 2016 14:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 eSU-9Zqjc8rJ for ; Wed, 27 Jan 2016 14:00:10 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 28E3C1B2BE5 for ; Wed, 27 Jan 2016 14:00:10 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 56123433411; Wed, 27 Jan 2016 22:00:09 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 37CF8433402; Wed, 27 Jan 2016 22:00:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1453932009; bh=4kC24qO0RYo/uHzeqMO3RZjEAh04NzDO24zOFzfTsF8=; l=7223; h=To:References:From:Date:In-Reply-To:From; b=SXtOrjjudVJmXEQrBTG4o9n7xvx1C9kXgF9Z1pnGFlb72R0O3oRRne9VzQPWD3lvK 906eTNMN8JhXiXG+o+wRpZucpPr9GCSgDZqd2lYgNjBgHU06n5JR7AxcxFdlvA4Shm j+fkLGzZQnyvCoiGepfGyD3fqDWZ8pFdqSyXVYmQ= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 23D442030; Wed, 27 Jan 2016 22:00:09 +0000 (GMT) To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: From: Brandon Williams Message-ID: <56A93DE9.4020909@akamai.com> Date: Wed, 27 Jan 2016 17:00:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:00:13 -0000 On 01/27/2016 10:01 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Friday, January 22, 2016 9:21 PM >> To: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt >> >> I've got a couple of comments on the current version of the draft. >> >> s3.1.2 >> The current text has some discussion of path MTU and STUN message size >> restrictions that relates to requirements that I think we have previously >> decided to relax. If my memory is correct, we decided in Dallas to allow >> request/response messages to assume reasonable path MTU values (rather >> than the IPv4 minimum), so we might want to avoid reiterating limiting >> guidance from RFC5389. > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-02 continues to have the same limiting guidance from RFC5389. Even new protocols like COAP suggest implementations to have the same limitation https://tools.ietf.org/html/rfc7252#section-4.6. > Sure, we apparently haven't settled on something yet (see separate thread). That said, even the COAP draft you cite uses SHOULD not MUST, and it uses more realistic guidance for the unknown MTU case (maybe we should adopt that language for STUN?). Let's make sure we settle on the broader question of MTU size requirements/recommendations for STUN. >> I can't find reference to this decision in the meeting >> minutes from Dallas, though, so maybe I'm mistaken. Nevertheless, it's >> probably better to just mention that you can't assume MTUs are the same >> and point to RFC5389 for further guidance, rather than repeating >> requirements language. > > I don't see a harm repeating the point, it reminds implementers to design the ticket with a small size. > I've seen multiple cases where a draft reiterated specific requirements language from an existing RFC and it went out-of-date due to the referenced draft being updated. Repeating requirements can be a maintenance burden and drive future incompatibility bugs. >> >> s3.2.2 >> A common use case for mobility will likely be what some have described as >> the "walk out the door" problem. Two interfaces are functional (e.g. >> both wifi and lte) and you want to seamlessly switch from one to the other. >> You probably want to be able to use both interfaces at the same time while >> you're figuring out whether/when to switch from one to the other (make >> before break). > > I don't see a problem. Applications can pick both interfaces, create multiple allocations, try connectivity checks on both interfaces, draft-ietf-tram-stun-path-data and MPRTP can be used to pick interface based on path characteristics. Keep the alternate candidates pair alive for switch-over and use ICE continuous nomination for seamless move. So, basically, don't use turn-mobility for this purpose? I'm not clear why you think the more complicated approach is preferable. Why would it be bad for turn-mobility to support make-before-break? > >> I don't think the current text supports this, since it indicates >> that 1) the tuple for the allocation should be updated and 2) the old ticket >> can only be used for retransmission. If I'm misunderstanding the intent of >> the text, then it would be helpful to see some explicit discussion of this use >> case. >> >> Finally (same section), while I can see the value of maintaining the existing >> allocation when switching between interfaces/addresses, sticking to that >> relay server could be a bad idea if there are other/better options for the new >> address. To support make before break in this case, I think it would be useful >> for the relay server to be able to send an ALTERNATE-SERVER attribute in its >> Refresh response message. >> IOW, allow the client to continue using the new allocation, but also let it >> know that a different/better relay is available for that address. > > Yes, but TURN service provider should have capabilities discussed in draft-williams-peer-redirect to pick an alternate TURN server; if the WG sees interest in peer-redirect we can propose Refresh response message to optionally signal ALTERNATE-SERVER attribute. I'm not describing peer redirect here. I'm describing redirect just for my allocation. If the original relay selection was based on your network geography (or just your ISP), turn-mobility could just be a way for you to stick to a relay that won't work well for you and that you never would have been mapped to in the first place, regardless of who you're connecting to. I'm not trying to push the idea that the mobility draft must cover this. I'm just suggesting that it's a possible short-coming of the mechanism that could make it less useful without some sort of solution. I'm happy to leave this for a separate discussion as Pl-Erik suggested. --Brandon > > -Tiru > >> There would likely be some ICE work associated with supporting such an >> option, so maybe it belongs in a separate more-general doc since turn- >> mobility is useful without it, but it seemed worth bringing up in this context. >> >> --Brandon >> >> On 11/07/2015 11:36 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the TURN Revised and Modernized Working >> Group of the IETF. >>> >>> Title : Mobility with TURN >>> Authors : Dan Wing >>> Prashanth Patil >>> Tirumaleswar Reddy >>> Paal-Erik Martinsen >>> Filename : draft-ietf-tram-turn-mobility-00.txt >>> Pages : 11 >>> Date : 2015-11-07 >>> >>> Abstract: >>> It is desirable to minimize traffic disruption caused by changing IP >>> address during a mobility event. One mechanism to minimize >>> disruption is to expose a shorter network path to the mobility event >>> so only the local network elements are aware of the changed IP >>> address but the remote peer is unaware of the changed IP address. >>> >>> This draft provides such an IP address mobility solution using >>> Traversal Using Relays around NAT (TURN). This is achieved by >>> allowing a client to retain an allocation on the TURN server when the >>> IP address of the client changes. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Wed Jan 27 16:32:23 2016 Return-Path: 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 414881B3974 for ; Wed, 27 Jan 2016 16:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zq5bscePvs_5 for ; Wed, 27 Jan 2016 16:32:11 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 A9A4C1B3971 for ; Wed, 27 Jan 2016 16:32:11 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id d63so21109527ioj.2 for ; Wed, 27 Jan 2016 16:32:11 -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:content-transfer-encoding; bh=jw1OIsSNw8qX/6RjUmMiJBikQ0DAMxDG2AOHwejQ+PQ=; b=PrVhXf0I1xyNtBYVGwo8NOb8oNui+jE7NdR8lNlXHuXVrnvMXWBz8LFeRtPaICER6O BFmfOgGRTSx89bYniTTqePm3HWiEsBMfRhJMnVcyC8Zn+CjckISn3i4cVxl/IkQd0bIg YDT4OCvi+XsVwUdzyYXI2KYg05zucoFstyt3HLMcy8WYmPYtvcYwwH3kmyJTc666zOqr ro2Pw5Ay50ORbIFzJTI+2KUEiKgUN+AHJc0Ci7A9kKZwM26lvfnZTHF2Vfq2qd+gTigU UVKY8dynUY5jrstebzJNxtErpU8ffc4krZdOguy7Rs0xaRz1iedQ7JjF9dmac4mJy9vG A5nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jw1OIsSNw8qX/6RjUmMiJBikQ0DAMxDG2AOHwejQ+PQ=; b=lNKr9s1nMxwaMqtKlIh7WpaWFnLgH+op9Ih2Dm2Y6bcodcOTs7F34fZe4i6O4ODYPO wH9u57qkKmJy9SOSMrQjZzBG8SDJP4Aepl08YMOCLG/Ar4bueo0JWfYPc9p4gxi1zD9t ZB3UuzQ8w8x7US6x8ndyPerZ+8OvlTDGKJqQ4Sve4JEwvQiWrJ+xp6RR7bwXmtaLXt+3 ZcXpS6dHqD0U4U+UCjJYEbC/JM+nx4vMxa1WM/NGoy9X0My8KH9v9DQl8lKk+zqjsTS0 8NjWWqEOemrcywmKfNO2hEfyEXDgAivZGjFnSfOtZiUFtvIj0o4KQsGGOepiVruTXn4h W66g== X-Gm-Message-State: AG10YORgiXp8UXPbJudpXdpgHQLmqYTBkRqekWqjnR3B5cfZ3y4raeNNiB5tVLmjD54j4HlGXVRY/9X/PEczQg== MIME-Version: 1.0 X-Received: by 10.107.33.14 with SMTP id h14mr726652ioh.108.1453941130979; Wed, 27 Jan 2016 16:32:10 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 27 Jan 2016 16:32:10 -0800 (PST) In-Reply-To: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> Date: Thu, 28 Jan 2016 11:32:10 +1100 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:32:19 -0000 I think that this is a fine way to shave this down if we want something as close to STUN as possible. But none of these changes is at all compatible. The alternative is to look at what we need and to change the connectivity check entirely so that it is maximally compact. For all of these, we need to clearly signal that the compact form is acceptable, so maybe we can find a way to trim this right down: a demux octet (1) a transaction ID (12-16) a target ufrag (4) a source ufrag (4) an integrity value (8-16) As Justin implies below, we might not need the same aggressive optimization for responses, because the main driver for reducing packet size is reducing the check interval without driving the data rate too high. If too many checks are successful, the responses can be rate limited to reduce the data rate, but in that case you have consent, so the only concern there is congestion. Other possible tweak is to say that the ufrag attributes in SDP include base64 encoded binary so that you can boost the entropy of the reduced sized ufrags by a third. Of course, you don't want to use SHA1 for M-I for any of this. On 28 January 2016 at 05:25, Justin Uberti wrote: > ufrag already has a 4-byte lower bound, so we can't really reduce that > further. > > Here is my concrete proposal: > https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5deb8Z= XHLJJpadBE/edit#slide=3Did.gc34db0b92_0_23 > > Basically: > - truncate M-I > - allow special case for 8-byte USERNAME > - remove tiebreaker, fingerprint, priority attributes > > Possibly: > - combine ICE-CONTROLLING and USERNAME > - put M-I into transaction ID (for REQUEST; RESPONSE would still need to > have an attribute) > > On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti) > wrote: >> >> >> > On 27 Jan 2016, at 14:39, Simon Perreault wrote: >> > >> > Le 2016-01-26 22:41, Marc Petit-Huguenin a =C3=A9crit : >> >>> s 14.4/14.5 There has been some discussion in mmusic about trying to >> >>>> compress ICE connectivity checks. Justin presented on this. IIRC, o= ne >> >>>> of his proposals was to shrink the size of the ICV. It would be goo= d >> >>>> to follow up on this and perhaps update stunbis to allow ICV's that >> >>>> are shorter. >> >> Here's the conclusions (from MMUSIC minutes) of the discussion about >> >> that in Prague: >> >> >> >> "Next steps: We need to discuss more on the approach and get back. Lo= ok >> >> further into what we can do with ufrag, etc. How much can we reduce p= acket >> >> size safely?" >> >> >> >> I do not think that there is consensus enough to take any action at >> >> this point. >> > >> > I am seizing this opportunity to restart discussion on this topic. I >> > think we've discussed many possibilities, and what is needed at this >> > moment is an actual concrete text proposal. I don't think it's >> > necessarily up to the draft editors to come up with such a proposal, b= ut >> > rather up to the working group as a whole. >> > >> > Discuss. :) >> >> I think limiting the size to a reasonable value is fine. A smaller limit >> to UFRAG and so on is simple and nice. >> >> I do not think putting much effort into saving a few bytes is worth it a= t >> this point in time. Let us save that for later if we want to tackle ICEv= 2 >> with a different connectivity check format. >> >> .-. >> P=C3=A5l-Erik >> >> > >> > Thanks, >> > Simon >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Thu Jan 28 01:22:16 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E03831B2C69; Thu, 28 Jan 2016 01:22:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128092200.2481.78103.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 01:22:00 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-path-data-03.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 09:22:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Discovery of path characteristics using STUN Authors : Tirumaleswar Reddy Dan Wing Paal-Erik Martinsen Varun Singh Filename : draft-ietf-tram-stun-path-data-03.txt Pages : 10 Date : 2016-01-28 Abstract: A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to discover the path characteristics using Session Traversal Utilities for NAT (STUN) messages. The measurement information can then be used to influence the endpoint's Interactive Connectivity Establishment (ICE) candidate pair selection algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stun-path-data-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-path-data-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 28 01:24:35 2016 Return-Path: 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 6A8CD1B2CA8 for ; Thu, 28 Jan 2016 01:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lR9fIADanGM4 for ; Thu, 28 Jan 2016 01:24:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C221B2C3C for ; Thu, 28 Jan 2016 01:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2321; q=dns/txt; s=iport; t=1453973072; x=1455182672; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XdMZc3tz8pGu+VK30ECojhIo446MUAf7RyywcI4HZFQ=; b=aMoi6Lra4Z0pgN3KhMfoPgxjSkIRzeOkyJU7aBAGF9iT30wwr9jjhWQn slQBFdnOSrXvgIOugHaPl6jfoY2V7MGG7yomdy72P+m8pZQL+JfdcHPrk eGfSPT0zPFWtoS4/TtixltSXMZZI70MeeMYLaWL+nWqfEKtzVOSnZEHwG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCu3alW/5BdJa1egzpSbQaIUbE6A?= =?us-ascii?q?Q2BYhgKhW0CgT04FAEBAQEBAQF/C4RBAQEBBAEBATc0FwQCAQgRBAEBHwkHJws?= =?us-ascii?q?UCQgCBBMIiBMOvh8BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhguENohsBZZuAYVGh?= =?us-ascii?q?32BYkqDeIhUjjwBHgEBQoNqaogBfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,357,1449532800"; d="scan'208";a="65942193" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2016 09:24:31 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0S9OVXm027816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Jan 2016 09:24:31 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Jan 2016 03:24:30 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Thu, 28 Jan 2016 03:24:31 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-stun-path-data-03.txt Thread-Index: AQHRWa13E4jNAP0ouUuyDBpMwAD3zp8Qp8TA Date: Thu, 28 Jan 2016 09:24:30 +0000 Message-ID: <275e938cbb0b4ed59616062f37913f7d@XCH-RCD-017.cisco.com> References: <20160128092200.2481.78103.idtracker@ietfa.amsl.com> In-Reply-To: <20160128092200.2481.78103.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.92.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-path-data-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 09:24:34 -0000 This revision addresses comments from Spencer. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, January 28, 2016 2:52 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-stun-path-data-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : Discovery of path characteristics using STUN > Authors : Tirumaleswar Reddy > Dan Wing > Paal-Erik Martinsen > Varun Singh > Filename : draft-ietf-tram-stun-path-data-03.txt > Pages : 10 > Date : 2016-01-28 >=20 > Abstract: > A host with multiple interfaces needs to choose the best interface > for communication. Oftentimes, this decision is based on a static > configuration and does not consider the path characteristics, which > may affect the user experience. >=20 > This document describes a mechanism for an endpoint to discover the > path characteristics using Session Traversal Utilities for NAT (STUN) > messages. The measurement information can then be used to influence > the endpoint's Interactive Connectivity Establishment (ICE) candidate > pair selection algorithm. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-stun-path-data-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stun-path-data-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Jan 28 03:05:06 2016 Return-Path: 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 DD04B1B3A2F for ; Thu, 28 Jan 2016 03:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GyarcBN2CcHh for ; Thu, 28 Jan 2016 03:05:03 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887081B3813 for ; Thu, 28 Jan 2016 03:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8683; q=dns/txt; s=iport; t=1453979103; x=1455188703; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BSsUlNNtY5abqlug0CwszAGaJ9Jl2v+2EV9Jz6mQPZA=; b=bygIHQym8+CvIQXybhw6k2vl16DY77ichWPZ3TYMCZTniUrhqSWqNAjn EGJFRYpZVzsCFUDnVGM3kfkskrdygXvEGOQc4KByD5iabjNt+XW0CCbS9 qog2OkVvT3rB53kF8vJGwDQksia/vreD7P5BbcKWqsdOPkcRyL82PBCIf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBl9alW/4sNJK1UCoM6Um0GiFGxO?= =?us-ascii?q?wENgWIYCoVtAoFAOBQBAQEBAQEBgQqEQQEBAQMBAQEBC1cJFwQCAQgRBAEBASc?= =?us-ascii?q?HJwsUCQgBAQQBEggTh3gIDr4aAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYLhDaEC?= =?us-ascii?q?BIGhEwFjVyJEgGFRod9gWJKg3iIVIpsg1ABHgEBQoICGYFPagGIAHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,358,1449532800"; d="scan'208";a="232483900" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jan 2016 11:05:02 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0SB51qM018537 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Jan 2016 11:05:01 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Jan 2016 05:05:01 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Thu, 28 Jan 2016 05:05:01 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt Thread-Index: AdFZE5vdeHWfvKN5RDWTgAWASP6SygAbMU6AAAt7poA= Date: Thu, 28 Jan 2016 11:05:01 +0000 Message-ID: References: <56A93DE9.4020909@akamai.com> In-Reply-To: <56A93DE9.4020909@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.92.83] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 11:05:06 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Thursday, January 28, 2016 3:30 AM > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt >=20 > On 01/27/2016 10:01 AM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >> Williams > >> Sent: Friday, January 22, 2016 9:21 PM > >> To: tram@ietf.org > >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt > >> > >> I've got a couple of comments on the current version of the draft. > >> > >> s3.1.2 > >> The current text has some discussion of path MTU and STUN message > >> size restrictions that relates to requirements that I think we have > >> previously decided to relax. If my memory is correct, we decided in > >> Dallas to allow request/response messages to assume reasonable path > >> MTU values (rather than the IPv4 minimum), so we might want to avoid > >> reiterating limiting guidance from RFC5389. > > > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-02 continues to hav= e the > same limiting guidance from RFC5389. Even new protocols like COAP suggest > implementations to have the same limitation > https://tools.ietf.org/html/rfc7252#section-4.6. > > >=20 > Sure, we apparently haven't settled on something yet (see separate thread= ). > That said, even the COAP draft you cite uses SHOULD not MUST, and it uses > more realistic guidance for the unknown MTU case (maybe we should adopt > that language for STUN?). Let's make sure we settle on the broader questi= on > of MTU size requirements/recommendations for STUN. >=20 > >> I can't find reference to this decision in the meeting minutes from > >> Dallas, though, so maybe I'm mistaken. Nevertheless, it's probably > >> better to just mention that you can't assume MTUs are the same and > >> point to RFC5389 for further guidance, rather than repeating > >> requirements language. > > > > I don't see a harm repeating the point, it reminds implementers to desi= gn > the ticket with a small size. > > >=20 > I've seen multiple cases where a draft reiterated specific requirements > language from an existing RFC and it went out-of-date due to the referenc= ed > draft being updated. Repeating requirements can be a maintenance burden > and drive future incompatibility bugs. Okay, updated draft. =20 >=20 > >> > >> s3.2.2 > >> A common use case for mobility will likely be what some have described > as > >> the "walk out the door" problem. Two interfaces are functional (e.g. > >> both wifi and lte) and you want to seamlessly switch from one to the > other. > >> You probably want to be able to use both interfaces at the same time > while > >> you're figuring out whether/when to switch from one to the other (make > >> before break). > > > > I don't see a problem. Applications can pick both interfaces, create mu= ltiple > allocations, try connectivity checks on both interfaces, draft-ietf-tram-= stun- > path-data and MPRTP can be used to pick interface based on path > characteristics. Keep the alternate candidates pair alive for switch-over= and > use ICE continuous nomination for seamless move. >=20 > So, basically, don't use turn-mobility for this purpose? I'm not clear > why you think the more complicated approach is preferable. Why would it > be bad for turn-mobility to support make-before-break? Extending TURN-mobility to support make-before-break makes the proposal mor= e complex, it may end-up just like MPTCP. Why not use ICE or MPRTP for make-before-break ? make-before-break means client can use multiple interfaces to send traffic = to the same allocation on the server, server must also load balance return = traffic etc. >=20 > > > >> I don't think the current text supports this, since it indicates > >> that 1) the tuple for the allocation should be updated and 2) the old = ticket > >> can only be used for retransmission. If I'm misunderstanding the inten= t of > >> the text, then it would be helpful to see some explicit discussion of = this > use > >> case. > >> > >> Finally (same section), while I can see the value of maintaining the e= xisting > >> allocation when switching between interfaces/addresses, sticking to th= at > >> relay server could be a bad idea if there are other/better options for= the > new > >> address. To support make before break in this case, I think it would b= e > useful > >> for the relay server to be able to send an ALTERNATE-SERVER attribute = in > its > >> Refresh response message. > >> IOW, allow the client to continue using the new allocation, but also l= et it > >> know that a different/better relay is available for that address. > > > > Yes, but TURN service provider should have capabilities discussed in dr= aft- > williams-peer-redirect to pick an alternate TURN server; if the WG sees > interest in peer-redirect we can propose Refresh response message to > optionally signal ALTERNATE-SERVER attribute. >=20 > I'm not describing peer redirect here. I'm describing redirect just for > my allocation. If the original relay selection was based on your network > geography (or just your ISP), turn-mobility could just be a way for you > to stick to a relay that won't work well for you and that you never > would have been mapped to in the first place, regardless of who you're > connecting to. How will the TURN server identify an optimal alternate server just because= =20 the client switched from one interface to another ? -Tiru >=20 > I'm not trying to push the idea that the mobility draft must cover this. > I'm just suggesting that it's a possible short-coming of the mechanism > that could make it less useful without some sort of solution. I'm happy > to leave this for a separate discussion as P=E5l-Erik suggested. >=20 > --Brandon >=20 >=20 > > > > -Tiru > > > >> There would likely be some ICE work associated with supporting such an > >> option, so maybe it belongs in a separate more-general doc since turn- > >> mobility is useful without it, but it seemed worth bringing up in this > context. > >> > >> --Brandon > >> > >> On 11/07/2015 11:36 PM, internet-drafts@ietf.org wrote: > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the TURN Revised and Modernized Worki= ng > >> Group of the IETF. > >>> > >>> Title : Mobility with TURN > >>> Authors : Dan Wing > >>> Prashanth Patil > >>> Tirumaleswar Reddy > >>> Paal-Erik Martinsen > >>> Filename : draft-ietf-tram-turn-mobility-00.txt > >>> Pages : 11 > >>> Date : 2015-11-07 > >>> > >>> Abstract: > >>> It is desirable to minimize traffic disruption caused by changin= g IP > >>> address during a mobility event. One mechanism to minimize > >>> disruption is to expose a shorter network path to the mobility e= vent > >>> so only the local network elements are aware of the changed IP > >>> address but the remote peer is unaware of the changed IP address= . > >>> > >>> This draft provides such an IP address mobility solution using > >>> Traversal Using Relays around NAT (TURN). This is achieved by > >>> allowing a client to retain an allocation on the TURN server whe= n the > >>> IP address of the client changes. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ > >>> > >>> There's also a htmlized version available at: > >>> https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-00 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> 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 >=20 > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. From nobody Thu Jan 28 03:32:22 2016 Return-Path: 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 763B91B3BD7 for ; Thu, 28 Jan 2016 03:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 yFaIqEHewj74 for ; Thu, 28 Jan 2016 03:32:19 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962DA1B3BCF for ; Thu, 28 Jan 2016 03:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6388; q=dns/txt; s=iport; t=1453980739; x=1455190339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VdM42nRpNTKanstXUyJXq85ZP1GDdwcdSSIwtbyrVic=; b=k2hgt5vzGQsSUQZVqfsVjUJpRWTj43RausXsf6T4+3o/agKQxFTlKSzQ JACI2cAmN9+r3vC+EiKRRHRMxtz8b1KJ7RY5Asn1tw/llu3WWd6Bxnkga s8YoQ3ngVPF8ujSqgA7QFUAy4UEgKBGlIHmSpjirsguugmv/+0N1GLhuH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCH+6lW/5BdJa1egzpSbQaIUbE7A?= =?us-ascii?q?Q2BYhgOhWkCHIEmOBQBAQEBAQEBgQqEQQEBAQMBAQEBIBE6CwULAgEIGAICJgI?= =?us-ascii?q?CAh8GCxUQAgQOBYgGAwoIDq58inoNhBkBAQEBAQEBAQEBAQEBAQEBAQEBAQERB?= =?us-ascii?q?HuFEIFtCIJBgjeBVQEjGIJqK4EPBZZuAYVGhU9CgXOBWxaNAIVugQ+HPwEeAQF?= =?us-ascii?q?CgX8cgU9qAYdDAR8dfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,358,1449532800"; d="scan'208";a="231701670" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2016 11:32:18 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0SBWIq7018593 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Jan 2016 11:32:18 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Jan 2016 06:32:17 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Thu, 28 Jan 2016 06:32:17 -0500 From: "Pal Martinsen (palmarti)" To: Martin Thomson Thread-Topic: [tram] Size of ICE connectivity checks Thread-Index: AQHRWQgtPaQiFbHMm0u1AvdENMUyaJ8PvQKAgABE+YCAAGZsAIAAuGwA Date: Thu, 28 Jan 2016 11:32:17 +0000 Message-ID: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.220.158] Content-Type: text/plain; charset="utf-8" Content-ID: <151D74DE1040C6418653800D8B968CB0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Simon Perreault , "tram@ietf.org" , Brandon Williams , Justin Uberti Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 11:32:21 -0000 DQo+IE9uIDI4IEphbiAyMDE2LCBhdCAwMTozMiwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhIGZpbmUg d2F5IHRvIHNoYXZlIHRoaXMgZG93biBpZiB3ZSB3YW50DQo+IHNvbWV0aGluZyBhcyBjbG9zZSB0 byBTVFVOIGFzIHBvc3NpYmxlLiAgQnV0IG5vbmUgb2YgdGhlc2UgY2hhbmdlcyBpcw0KPiBhdCBh bGwgY29tcGF0aWJsZS4NCj4gDQo+IFRoZSBhbHRlcm5hdGl2ZSBpcyB0byBsb29rIGF0IHdoYXQg d2UgbmVlZCBhbmQgdG8gY2hhbmdlIHRoZQ0KPiBjb25uZWN0aXZpdHkgY2hlY2sgZW50aXJlbHkg c28gdGhhdCBpdCBpcyBtYXhpbWFsbHkgY29tcGFjdC4NCj4gDQo+IEZvciBhbGwgb2YgdGhlc2Us IHdlIG5lZWQgdG8gY2xlYXJseSBzaWduYWwgdGhhdCB0aGUgY29tcGFjdCBmb3JtIGlzDQo+IGFj Y2VwdGFibGUsIHNvIG1heWJlIHdlIGNhbiBmaW5kIGEgd2F5IHRvIHRyaW0gdGhpcyByaWdodCBk b3duOg0KPiANCj4gYSBkZW11eCBvY3RldCAoMSkNCj4gYSB0cmFuc2FjdGlvbiBJRCAoMTItMTYp DQo+IGEgdGFyZ2V0IHVmcmFnICg0KQ0KPiBhIHNvdXJjZSB1ZnJhZyAoNCkNCj4gYW4gaW50ZWdy aXR5IHZhbHVlICg4LTE2KQ0KPiANCg0KSSB0aGluayBjb21pbmcgdXAgd2l0aCBhIGNvbXBhY3Qg Zm9ybSBpcyB1c2VmdWwgZm9yIGZ1dHVyZSBleHRlbnNpb25zLiBJZiBRVUlLLCBTUFVELCBHaWdh LCBldGMuIGNvdWxkIGNhcnJ5IHRoYXQgaW5mb3JtYXRpb24gYXMgd2VsbCB3ZSBjb3VsZCBwb3Rl bnRpYWxseSBoYXZlIGV2ZW4gbXVjaCBtb3JlIGVmZmljaWVudCBjb25uZWN0aXZpdHkgY2hlY2tz LiBCdXQgdGhhdCBkaXNjdXNzaW9uIHNob3VsZCBwcm9iYWJseSBoYXBwZW4gaW4gdGhlIElDRSB3 Zz8gKEFueW9uZSBjYXJlIHRvIHdyaXRlIHVwIGltcHJvdmVkIElDRSBjb25uZWN0aXZpdHkgY2hl Y2tzIGRyYWZ0PykNCg0KPiBBcyBKdXN0aW4gaW1wbGllcyBiZWxvdywgd2UgbWlnaHQgbm90IG5l ZWQgdGhlIHNhbWUgYWdncmVzc2l2ZQ0KPiBvcHRpbWl6YXRpb24gZm9yIHJlc3BvbnNlcywgYmVj YXVzZSB0aGUgbWFpbiBkcml2ZXIgZm9yIHJlZHVjaW5nDQo+IHBhY2tldCBzaXplIGlzIHJlZHVj aW5nIHRoZSBjaGVjayBpbnRlcnZhbCB3aXRob3V0IGRyaXZpbmcgdGhlIGRhdGENCj4gcmF0ZSB0 b28gaGlnaC4gIElmIHRvbyBtYW55IGNoZWNrcyBhcmUgc3VjY2Vzc2Z1bCwgdGhlIHJlc3BvbnNl cyBjYW4NCj4gYmUgcmF0ZSBsaW1pdGVkIHRvIHJlZHVjZSB0aGUgZGF0YSByYXRlLCBidXQgaW4g dGhhdCBjYXNlIHlvdSBoYXZlDQo+IGNvbnNlbnQsIHNvIHRoZSBvbmx5IGNvbmNlcm4gdGhlcmUg aXMgY29uZ2VzdGlvbi4NCj4gDQpHb29kIHBvaW50LiBBbmQgaWYgY29uZ2VzdGlvbiBoYXBwZW5z IGl0IHdvdWxkIGJlIGdvb2QgdG8gbm90aWNlLg0KDQoNCj4gT3RoZXIgcG9zc2libGUgdHdlYWsg aXMgdG8gc2F5IHRoYXQgdGhlIHVmcmFnIGF0dHJpYnV0ZXMgaW4gU0RQDQo+IGluY2x1ZGUgYmFz ZTY0IGVuY29kZWQgYmluYXJ5IHNvIHRoYXQgeW91IGNhbiBib29zdCB0aGUgZW50cm9weSBvZiB0 aGUNCj4gcmVkdWNlZCBzaXplZCB1ZnJhZ3MgYnkgYSB0aGlyZC4NCj4gDQorMS4gU28gdGhpcyBp cyByZWFsbHkgc29tZXRoaW5nIGEgc2duYWxsaW5nIHByb3RvY29sIHN1cHBvcnRpbmcgSUNFIG11 c3Qgc3VwcG9ydC4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KPiBPZiBjb3Vyc2UsIHlvdSBkb24ndCB3 YW50IHRvIHVzZSBTSEExIGZvciBNLUkgZm9yIGFueSBvZiB0aGlzLg0KPiANCj4gT24gMjggSmFu dWFyeSAyMDE2IGF0IDA1OjI1LCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+IHdy b3RlOg0KPj4gdWZyYWcgYWxyZWFkeSBoYXMgYSA0LWJ5dGUgbG93ZXIgYm91bmQsIHNvIHdlIGNh bid0IHJlYWxseSByZWR1Y2UgdGhhdA0KPj4gZnVydGhlci4NCj4+IA0KPj4gSGVyZSBpcyBteSBj b25jcmV0ZSBwcm9wb3NhbDoNCj4+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL3ByZXNlbnRhdGlv bi9kLzEwQUdhTVdpZldvRGFHOWlfRktEbnN3OUxnQV81ZGViOFpYSExKSnBhZEJFL2VkaXQjc2xp ZGU9aWQuZ2MzNGRiMGI5Ml8wXzIzDQo+PiANCj4+IEJhc2ljYWxseToNCj4+IC0gdHJ1bmNhdGUg TS1JDQo+PiAtIGFsbG93IHNwZWNpYWwgY2FzZSBmb3IgOC1ieXRlIFVTRVJOQU1FDQo+PiAtIHJl bW92ZSB0aWVicmVha2VyLCBmaW5nZXJwcmludCwgcHJpb3JpdHkgYXR0cmlidXRlcw0KPj4gDQo+ PiBQb3NzaWJseToNCj4+IC0gY29tYmluZSBJQ0UtQ09OVFJPTExJTkcgYW5kIFVTRVJOQU1FDQo+ PiAtIHB1dCBNLUkgaW50byB0cmFuc2FjdGlvbiBJRCAoZm9yIFJFUVVFU1Q7IFJFU1BPTlNFIHdv dWxkIHN0aWxsIG5lZWQgdG8NCj4+IGhhdmUgYW4gYXR0cmlidXRlKQ0KPj4gDQo+PiBPbiBXZWQs IEphbiAyNywgMjAxNiBhdCA2OjE4IEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNCj4+IDxw YWxtYXJ0aUBjaXNjby5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IA0KPj4+PiBPbiAyNyBKYW4gMjAx NiwgYXQgMTQ6MzksIFNpbW9uIFBlcnJlYXVsdCA8c3BlcnJlYXVsdEBqaXZlLmNvbT4gd3JvdGU6 DQo+Pj4+IA0KPj4+PiBMZSAyMDE2LTAxLTI2IDIyOjQxLCBNYXJjIFBldGl0LUh1Z3VlbmluIGEg w6ljcml0IDoNCj4+Pj4+PiBzIDE0LjQvMTQuNSBUaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Np b24gaW4gbW11c2ljIGFib3V0IHRyeWluZyB0bw0KPj4+Pj4+PiBjb21wcmVzcyBJQ0UgY29ubmVj dGl2aXR5IGNoZWNrcy4gSnVzdGluIHByZXNlbnRlZCBvbiB0aGlzLiBJSVJDLCBvbmUNCj4+Pj4+ Pj4gb2YgaGlzIHByb3Bvc2FscyB3YXMgdG8gc2hyaW5rIHRoZSBzaXplIG9mIHRoZSBJQ1YuIEl0 IHdvdWxkIGJlIGdvb2QNCj4+Pj4+Pj4gdG8gZm9sbG93IHVwIG9uIHRoaXMgYW5kIHBlcmhhcHMg dXBkYXRlIHN0dW5iaXMgdG8gYWxsb3cgSUNWJ3MgdGhhdA0KPj4+Pj4+PiBhcmUgc2hvcnRlci4N Cj4+Pj4+IEhlcmUncyB0aGUgY29uY2x1c2lvbnMgKGZyb20gTU1VU0lDIG1pbnV0ZXMpIG9mIHRo ZSBkaXNjdXNzaW9uIGFib3V0DQo+Pj4+PiB0aGF0IGluIFByYWd1ZToNCj4+Pj4+IA0KPj4+Pj4g Ik5leHQgc3RlcHM6IFdlIG5lZWQgdG8gZGlzY3VzcyBtb3JlIG9uIHRoZSBhcHByb2FjaCBhbmQg Z2V0IGJhY2suIExvb2sNCj4+Pj4+IGZ1cnRoZXIgaW50byB3aGF0IHdlIGNhbiBkbyB3aXRoIHVm cmFnLCBldGMuIEhvdyBtdWNoIGNhbiB3ZSByZWR1Y2UgcGFja2V0DQo+Pj4+PiBzaXplIHNhZmVs eT8iDQo+Pj4+PiANCj4+Pj4+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlcmUgaXMgY29uc2Vuc3Vz IGVub3VnaCB0byB0YWtlIGFueSBhY3Rpb24gYXQNCj4+Pj4+IHRoaXMgcG9pbnQuDQo+Pj4+IA0K Pj4+PiBJIGFtIHNlaXppbmcgdGhpcyBvcHBvcnR1bml0eSB0byByZXN0YXJ0IGRpc2N1c3Npb24g b24gdGhpcyB0b3BpYy4gSQ0KPj4+PiB0aGluayB3ZSd2ZSBkaXNjdXNzZWQgbWFueSBwb3NzaWJp bGl0aWVzLCBhbmQgd2hhdCBpcyBuZWVkZWQgYXQgdGhpcw0KPj4+PiBtb21lbnQgaXMgYW4gYWN0 dWFsIGNvbmNyZXRlIHRleHQgcHJvcG9zYWwuIEkgZG9uJ3QgdGhpbmsgaXQncw0KPj4+PiBuZWNl c3NhcmlseSB1cCB0byB0aGUgZHJhZnQgZWRpdG9ycyB0byBjb21lIHVwIHdpdGggc3VjaCBhIHBy b3Bvc2FsLCBidXQNCj4+Pj4gcmF0aGVyIHVwIHRvIHRoZSB3b3JraW5nIGdyb3VwIGFzIGEgd2hv bGUuDQo+Pj4+IA0KPj4+PiBEaXNjdXNzLiA6KQ0KPj4+IA0KPj4+IEkgdGhpbmsgbGltaXRpbmcg dGhlIHNpemUgdG8gYSByZWFzb25hYmxlIHZhbHVlIGlzIGZpbmUuIEEgc21hbGxlciBsaW1pdA0K Pj4+IHRvIFVGUkFHIGFuZCBzbyBvbiBpcyBzaW1wbGUgYW5kIG5pY2UuDQo+Pj4gDQo+Pj4gSSBk byBub3QgdGhpbmsgcHV0dGluZyBtdWNoIGVmZm9ydCBpbnRvIHNhdmluZyBhIGZldyBieXRlcyBp cyB3b3J0aCBpdCBhdA0KPj4+IHRoaXMgcG9pbnQgaW4gdGltZS4gTGV0IHVzIHNhdmUgdGhhdCBm b3IgbGF0ZXIgaWYgd2Ugd2FudCB0byB0YWNrbGUgSUNFdjINCj4+PiB3aXRoIGEgZGlmZmVyZW50 IGNvbm5lY3Rpdml0eSBjaGVjayBmb3JtYXQuDQo+Pj4gDQo+Pj4gLi0uDQo+Pj4gUMOlbC1Fcmlr DQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IFNpbW9uDQo+Pj4+IA0KPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiB0cmFtIG1h aWxpbmcgbGlzdA0KPj4+PiB0cmFtQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+PiB0cmFt QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt DQo+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+IHRyYW1AaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4gDQoNCg== From nobody Thu Jan 28 11:06:33 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 119421AD0D1; Thu, 28 Jan 2016 11:06:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128190632.28844.81875.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 11:06:32 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:06:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-06.txt Pages : 59 Date : 2016-01-28 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 28 11:07:46 2016 Return-Path: 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 101FF1B2F88 for ; Thu, 28 Jan 2016 11:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham 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 1PUW5zdBymAy for ; Thu, 28 Jan 2016 11:07:40 -0800 (PST) Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id B70E91AD0D1 for ; Thu, 28 Jan 2016 11:07:40 -0800 (PST) Received: from [IPv6:2001:5c0:1400:b::1121] (petithug.broker.freenet6.net [IPv6:2001:5c0:1400:b::1121]) (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 E639620078; Thu, 28 Jan 2016 20:07:36 +0100 (CET) From: Marc Petit-Huguenin To: Jonathan Lennox References: <56A83C06.2000800@acm.org> Message-ID: <56AA66F4.4070409@acm.org> Date: Thu, 28 Jan 2016 11:07:32 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-stunbis-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:07:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Inline. On 01/27/2016 08:29 AM, Jonathan Lennox wrote: > >> On Jan 26, 2016, at 10:39 PM, Marc Petit-Huguenin >> wrote: >> >>> >>> Section 9.1.3: >>> >>> “If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the >>> value for the message integrity as described in Section 14.5, >>> using the password associated with the username. If the MESSAGE- >>> INTEGRITY-SHA256 attribute is not present, and using the same >>> password, compute the value for the message integrity as >>> described in Section 14.4. If the resulting value does not match >>> the contents of the MESSAGE-INTEGRITY-SHA256 attribute or the >>> MESSAGE- INTEGRITY attribute:” >>> >>> Is this saying that a SHA-1 message integrity value (described >>> in Section 14.4) can be carried in a MESSAGE-INTEGRITY-SHA256 >>> attribute? That doesn’t seem right. >>> >> >> Can you please suggest some text that would make it clearer that >> this is not the intended meaning? We fail to see how this >> conclusion can be made from the text. > > My problem is with the phrase “If the resulting value does not match > the contents of the MESSAGE-INTEGRITY-SHA256 attribute or the > MESSAGE-INTEGRITY attribute,” which implies to me that the calculated > message integrity value is compared with the content of both > attributes. > > Perhaps “If the resulting value does not match the contents of the > corresponding attribute (MESSAGE-INTEGRITY-SHA256 or > MESSAGE-INTEGRITY):" We used your text. > >>> Section 9.1.4: >>> >>> “The client looks for the MESSAGE-INTEGRITY-SHA256 or the >>> MESSAGE- INTEGRITY attribute in the response. If present, the >>> client computes the message integrity over the response as >>> defined in Section 14.4 or Section 14.5, using the same password >>> it utilized for the request. If the resulting value matches the >>> contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 >>> attribute, the response is considered authenticated. If the value >>> does not match, or if both MESSAGE- INTEGRITY and >>> MESSAGE-INTEGRITY-SHA256 were absent, the response MUST be >>> discarded, as if it was never received. This means that >>> retransmits, if applicable, will continue.” >>> >>> Parallelism failure. Sometimes MESSAGE-INTEGRITY is listed first, >>> and sometimes MESSAGE-INTEGRITY-SHA256. If read literally it >>> would seem to imply you were swapping the values. The two >>> algorithms should be consistently listed in order, and it should >>> be made clear that they apply respectively. >> >> Fixed. > > I would also add “,respectively,” twice, once after “Section 14.5” > and once before “the response is considered”. Done. > > >>> >>> Additionally, it should say that if the client only sent one >>> algorithm in the request (because of the external indication in >>> section 9.1.2, or this being a subsequent request as defined in >>> 9.1.5) the algorithm in the response has to match. >> >> Fixed. > > I would add “otherwise the response MUST be discarded” to the new > sentence you added. Done. > >>> [My original comments on password algorithm omitted] >> >> These were tough, but we think that we captured the essence of your >> concerns. But please have a look at the new text. > > These generally seem a lot better. A few comments on the new > content: > > “If the NONCE attribute starts with the value "obMatJos2" but > PASSWORD-ALGORITHMS does not match, then the server MUST generate an > error response with an error code of 400 (Bad Request).” > > This doesn’t say what the PASSWORD-ALGORITHMS has to match (it got > lost in the conversion). Presumably “does not match the value in > sent in the response that sent this NONCE”? Done. > > “If the NONCE attribute starts with the value "obMatJos2" but the > request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, > then the request is processed as though PASSWORD-ALGORITHM were > MD5.” > > I might add “(Note that if the original PASSWORD-ALGORITHMS attribute > did not contain MD5, this will result in a 400 Bad Request in a later > step below.)”, but this is editorial and I leave it to your > discretion. We found this suggestion useful, so we applied it. > > "If the NONCE is no longer valid, the server MUST generate an error > response with an error code of 438 (Stale Nonce). This response MUST > include NONCE and REALM attributes” > > MUST include PASSWORD-ALGORITHMS as well. Similarly for the > generated 401. Done. > > “Any response generated by the server (excepting the cases where a > server responds with an error code, which cannot be authenticated)” > > Remove the comma — this should be a dependent clause, since some > error codes can be authenticated. > > Actually, more generally, any response after this point will be able > to be authenticated, since we’ve passed authentication. Looking at > the diff, I think the earlier language for the parenthetical phrase > “(excepting in the cases described above)” was better, but more > wordsmithing is possible. Ok, we took an alternative approach which may be a little clearer, please have a look. > > “MUST include MESSAGE-INTEGRITY-SHA256 attribute, computed using the > username and password utilized to authenticate the request, unless > the request was processed as though PASSWORD-ALGORITHM was MD5. In > that case the MESSAGE-INTEGRITY attribute MUST be used instead of the > MESSAGE-INTEGRITY-SHA256 attribute.” > > I understand what you’re saying but I think “was processed as though > PASSWORD-ALGORITHM was MD5” is ambiguous. What we did was copy the text from the 3rd bullet to make it explicitly clear the reason we process as MD5. > > And actually, thinking about it, it seems to me that for long-term > auth, there’s never any need for clients to send both > MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 — you send the latter > if there was a PASSWORD-ALGORITHMS accompanying the nonce, otherwise > the former. In which case the server just mirrors the client. > > “If the response is an error response with an error code of 401 > (Unauthorized), the client MUST test if the NONCE attribute value > starts with the character string "obMatJos2". If the test succeeds > and no PASSWORD-ALGORITHMS attribute is present, then the client > MUST NOT retry the request with a new transaction.” > > I think this test needs to apply to 438 Stale Nonce too, to prevent > it being used for bid-down. Fixed. > >>> >>> Should we define MD5 as a PASSWORD-ALGORITHM value? The use case >>> is a server that wants to upgrade to stunbis, but wants to keep >>> using its existing (md5-hashed) password database without forcing >>> users to re-enter their password. (This would mean a case where >>> long-term authentication uses the MD5 password algorithm, but >>> MESSAGE-INTEGRITY-SHA256 integrity.) >>> >> >> OK. > > Definition of the key is using SHA256. :-) Fixed. > >> >>> >>> Section 17.5: >>> >>> Should register the stuns over UDP port. >> >> My understanding (following a discussion with IANA in Dallas, IIRC) >> is that as we should only update the RFC 5389 registrations, and >> not the RFC 7350 registration. > > Okay. > >>> A general question about the PASSWORD-ALGORITHM transition >>> process: do we want to support the use case where a server is >>> gradually transitioning its existing database to have SHA-256 as >>> the password hash algorithm (as users change passwords)? This >>> might result in a case where some users have MD5-hashed passwords >>> in the database, and some have SHA-256 — but the server doesn’t >>> yet know when responding to the initial request which user is >>> making the request, and thus which password algorithms are >>> actually supported for this specific user. Supporting this would >>> require either putting USERNAME in the initial request (which >>> seems bad in the absence of a known realm), or else allowing a >>> server to respond to a followup request with another 401 >>> Unauthorized response, with a shorter PASSWORD-ALGORITHMS list >>> (resulting in long-term authentication requiring three >>> transactions for stunbis clients whose users who are still on >>> MD5). Despite the triple transaction, I’m inclined to recommend >>> the latter. >> >> Interesting use case regarding the management of an hybrid database >> containing mixed MD5/SHA256 users, but is it worth adding that >> complexity to the protocol? We're willing to listen to opinion >> from the working group, especially people with large deployments. > > This is at the end of a long and editorial e-mail, so it’s probably > worth calling this out in a standalone message. > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqmb0AAoJECnERZXWan7E22sP/07tPcFQ18Xo7AnMFiq1pQ3Z s5KjYZoMIR+1RgV2Z0StjMCDYR0fkvi1PjKfy05dJmHj3dI2rIUdHwDGN2a70AMu gx6n5/WNRrEM2JJ36mTlvuANU9kYyZnN4x/GUuU3Ogqkype/hwZanof6K2K/5wVa 9qzl74crDEv6oYZ68pNFr1URVFpaETzcQE40DSS7Nxn8JM8lsmMKjQSXRRaIszhh gE3z9gfPlxnHLvTeiGffDlGFFZrC1rKl0wufLZ3j+0oD/mLYYGTslo41+PvAvIwg yJVnMaLfCZG/3rCkOUYXXeu2YzsQAg+W6Y0z9cVWBg0YfFg72DLISOPro5DPngcx acu3BedbhrGsNN0755FB1N+G/s9UE69JUodnqB9QL+B7Gd99U4H1r6str3qBIVJ9 CR2T77JpJghpS8p7mAvUMWV8EfJUbPuHU0LZ0ej4QjrXYNpdOxdwVcztGu0aNPgN nB1IC0XK++QtcaKx3/DzV4JjVtvA6NGWFsvaQJW+e1ry5wle4FbWXCfsesro0rNt DT7p4muxxcFT0FJK9Gg9Fl1ElX+/jrtbwap8y82CgTpfzxISQgbntGQcQwCeRzxC lxbRggykRWTWnDBQMvtYpJ0rEPogfIV02UEa5IMZV8FNRUVYLvC8iajXaFWRCcSY 1Uob1jPFb0Et2BuE1zOp =sYtQ -----END PGP SIGNATURE----- From nobody Thu Jan 28 11:08:10 2016 Return-Path: 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 7DF241A89FD for ; Thu, 28 Jan 2016 11:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham 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 w0XXgCsKAg-s for ; Thu, 28 Jan 2016 11:08:06 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2911A87AF for ; Thu, 28 Jan 2016 11:08:06 -0800 (PST) Received: from [IPv6:2001:5c0:1400:b::1121] (petithug.broker.freenet6.net [IPv6:2001:5c0:1400:b::1121]) (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 BBC3720078; Thu, 28 Jan 2016 20:08:04 +0100 (CET) To: Brandon Williams , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A9151F.3050009@akamai.com> From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <56AA6711.3070002@acm.org> Date: Thu, 28 Jan 2016 11:08:01 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <56A9151F.3050009@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Review of draft-ietf-tram-stunbis-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:08:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Inline. On 01/27/2016 11:06 AM, Brandon Williams wrote: > Thanks Marc. I sent a separate message about the MTU requirements, > since I think it seems to be a broader issue to me. > > There are some responses to other items below. All the rest looks > good to me. > > --Brandon > > On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> > >>> s 9.2.3 The third bullet states 'If the NONCE attribute starts >>> with the value "obMayJos2" but the PASSWORD-ALGORITHMS attribute >>> is not present ... the server MUST generate an error response'. >>> However, I don't see a way for the server to determine whether >>> it's safe to require this when sending the PASSWORD-ALGORITHMS >>> attribute. Maybe the third bullet's requirement can only be >>> safely applied if MI-SHA256 is present. >> >> We are not sure we understand your point, but this section has been >> heavily rewritten following Jonathan review, so please check that >> your comment is still valid. >> > > The new text (bullets 3 and 4) looks good to me. > > My concern was about supporting clients that don't support > PASSWORD-ALGORITHMS. I see that you split the third bullet into two > bullets and no longer require the server to send an error if > PASSWORD-ALGORITHMS is not present, which satisfies the concern about > clients that just don't support the functionality. > >>> >>> s 14.4/14.5 There has been some discussion in mmusic about trying >>> to compress ICE connectivity checks. Justin presented on this. >>> IIRC, one of his proposals was to shrink the size of the ICV. It >>> would be good to follow up on this and perhaps update stunbis to >>> allow ICV's that are shorter. >> >> Here's the conclusions (from MMUSIC minutes) of the discussion >> about that in Prague: >> >> "Next steps: We need to discuss more on the approach and get back. >> Look further into what we can do with ufrag, etc. How much can we >> reduce packet size safely?" >> >> I do not think that there is consensus enough to take any action at >> this point. >> > > Since the subject of shorter HMAC values has come up, I don't see any > harm in stating that 16 and 32 bytes are the recommended values, but > that a specific STUN usage MAY use a truncated HMAC. If the STUN > usage does not explicitly allow truncated HMAC values, then the HMAC > lengths MUST be 16 and 32. > > That said, I don't feel strongly about and certainly understand if > you want to see a well defined and accepted use case before changing > requirements. There is a dedicated thread on that subject, we will follow the consensus that the WG will reach. > >>> >>> s 11 The text seems to describe backward compatibility with >>> RFC3489, but the section title is "Backwards Compatibility with >>> RFC 5389". >> >> We made a reference to the backward compatibility section of RFC >> 5389 (section 12), which is RFC 3489. The section is this document >> is about the backward compatibility to RFC 5389. >> > > Both section 12 of 5389 and this section of stunbis describe backward > compatibility with 3489. What in the section is about backward > compatibility with 5389 STUN? OK, you are right, changed to RFC 3489. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqmcRAAoJECnERZXWan7EBjQP/1eZBBNUn0v759trmrasJPN4 Apt84EtBC6MDLEcdSMvlfPPfRRVJOPS7iCAKgsKZ4a4FvJT03ymB0tg5sz0aopWI LyWz6vR62aVAJBbVOPS+6iF1mAAjnj9bfRQynXCLh/ScclVZw7L5oI/tPC2Ln5zC 07Pab1V1yJt64A+rU5RqGb7r7XfrGMEe5+Kgtdw9HztkN8gJi9JjWImmfaxswd+e KF5ZqL2wfqPti6g8wS31yoPiPi93jX0nFm1eyzs0CE5K2T+NRZz5dnpspZsKqbAm O78KdYH5JLbIrtkDNrXMT5BbNsKY8edFgEpMo+Hm8qI+SsfgTZEw1Dpw7GoNvH6n yincMUEf+9lravGQMnkxi+4dA1FwR/38Wizjg8W8MFtc9UQWe3wjocsYBIp1jwg7 IGrjjWSchlFZTbOTwq5wDR7dwvFtE5700K5kfU3ATXHzn9t3xbRcbQYlS6AAcKHj imQMCjg/7dgDnx7x2WFt+E2vsIsNydOScfu9l935VKf5TjJYdFWkXXWyqjztHRB5 7yI7ERHKqxM+EI1vdDRPN/Y1mCGsZfxnySer3r2ra2k8PGJDDwUtyu5QjpbbpJbF Q84LcqtF6/cMb679fVi9UkghP65vyAiwvkV4igQPADzwxLVjINMSPv5q3/l0E+zX gyXcRCtdpoLjTjjQFLqV =u+xM -----END PGP SIGNATURE----- From nobody Thu Jan 28 11:10:34 2016 Return-Path: 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 388CA1B2F88 for ; Thu, 28 Jan 2016 11:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 MNgek-kQ1Zd4 for ; Thu, 28 Jan 2016 11:10:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6551B2F87 for ; Thu, 28 Jan 2016 11:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7624; q=dns/txt; s=iport; t=1454008230; x=1455217830; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=IkVITzQvZU/rSOMHXau3b5iWtirktkc+ShLvWBq17Qg=; b=haqqXKT94eh42cFxl8RlHrMkG4tCFOqTYCZWgSRAKtw1RUysD7rY7qCc Ex4tvg4TehjT3iQVfDNdmMzhTq82yT5WG+ZijxMc/eTt4RrNlIuU6oSAX 7qs4td92g3A8VQYMKGNy8mxdmM5DboS5fJiLTFafMvmDXMpW1VdDxQHLM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAgBvZqpW/5BdJa1egzpSbQaIUbFEA?= =?us-ascii?q?Q2BYhgBCYVtAoFIOBQBAQEBAQEBgQqEQgEBBAEBAWsbAgEIPwcnCxQRAgQTG4g?= =?us-ascii?q?ADsABAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYNAYFsgkqEX4J+gQ8Flm4BhUaIB?= =?us-ascii?q?AeBVEqDeIhUjjwBHgEBQoNqaogBfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,359,1449532800"; d="scan'208,217";a="232411385" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2016 19:10:29 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0SJATa4005921 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Jan 2016 19:10:29 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Jan 2016 13:10:28 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Thu, 28 Jan 2016 13:10:28 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: tram mailing list Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-06.txt Thread-Index: AQHRWf8FAIwQ3VpTh0C03Ix6o7Z+r58Rr7AA Date: Thu, 28 Jan 2016 19:10:28 +0000 Message-ID: References: <20160128190632.28844.81875.idtracker@ietfa.amsl.com> In-Reply-To: <20160128190632.28844.81875.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.246.145] Content-Type: multipart/alternative; boundary="_000_EF0098C7F22C45D38C8FC16588E579C0ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-06.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:10:32 -0000 --_000_EF0098C7F22C45D38C8FC16588E579C0ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi TRAMsters- The -06 version includes the following updates: * Added test vector for MESSAGE-INTEGRITY-SHA256. * Address additional review comments from Jonathan Lennox and Brandon W= illiams. * Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233). * Changed I-D references to RFC references. Cheers, Gonzalo On Jan 28, 2016, at 11:06 AM, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TURN Revised and Modernized Working Group = of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-06.txt Pages : 59 Date : 2016-01-28 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_EF0098C7F22C45D38C8FC16588E579C0ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1D9CA053BE0E134F85DB43050B985661@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi TRAMsters-

The -06 version includes the following updates:
  • Added test vector for MESSAGE-INTEGRITY-SHA256.
  • Address additional review comments from Jonathan Lennox and Brandon = Williams.
  • Changed CHANGE-ADDRESS to CHANGE-REQUEST (Erra= ta #4233).
  • Changed I-D references to RFC references.
Cheers,

Gonzalo


On Jan 28, 2016, at 11:06 AM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the TURN Revised and Modernized Working Group = of the IETF.

       Title           : Sessi= on Traversal Utilities for NAT (STUN)
       Authors         : Marc Petit= -Huguenin
                     = ;    Gonzalo Salgueiro
                     = ;    Jonathan Rosenberg
                     = ;    Dan Wing
                     = ;    Rohan Mahy
                     = ;    Philip Matthews
Filename &n= bsp;      : draft-ietf-tram-stunbis-06.txt
Pages  = ;         : 59
Date  =          : 2016-01-28

Abstract:
  Session Traversal Utilities for NAT (STUN) is a protocol that serves=
  as a tool for other protocols in dealing with Network Address
  Translator (NAT) traversal.  It can be used by an endpoint to   determine the IP address and port allocated to it by a NAT.  It= can
  also be used to check connectivity between two endpoints, and as a   keep-alive protocol to maintain NAT bindings.  STUN works with = many
  existing NATs, and does not require any special behavior from them.<= br class=3D"">
  STUN is not a NAT traversal solution by itself.  Rather, it is = a tool
  to be used in the context of a NAT traversal solution.

  This document obsoletes RFC 5389.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tram-stunbis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

--_000_EF0098C7F22C45D38C8FC16588E579C0ciscocom_-- From nobody Thu Jan 28 12:08:30 2016 Return-Path: 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 8A07E1ACE52 for ; Thu, 28 Jan 2016 12:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 9ZM6zaqgzPeB for ; Thu, 28 Jan 2016 12:08:28 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 4A6C01ACDF0 for ; Thu, 28 Jan 2016 12:08:28 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id yy13so28171346pab.3 for ; Thu, 28 Jan 2016 12:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Wf6g81L0G6ZnmC4ZPOinfoNtHoUPmBS7DWpPfvohAZc=; b=b12rXTdIns77pPX3cCcvj5dvlimuTsBGdbOt6X+ivguSu4SLYHtAPJGgANR4Wk+7FN lZszSakMBhyjVVPFjxJkfpQxINiqoXvN3d6fLGPxI5dMPIHAHtfR4y6fC9LsIOitqNRq afBX3f2SWDE5xKu4LxNVVlfoTPoZzTRb4n91e1/OK01MMILdeP0xSNqMjvxfxXTYRny9 XXLIekiY/pizY2RjnSBw6wkkAVbYd5QQ8LR6lawXut0ViD0zCEPiG6ziczPgQNinih9R Q1gEGo+DlgpijCIlLBhKT2r1qOKDFwXqmyj5fr3fScGfiZnX/K/TC+E3u6J6UprDVCz+ YQGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Wf6g81L0G6ZnmC4ZPOinfoNtHoUPmBS7DWpPfvohAZc=; b=mW5CKxusNwby/adnnJ1Akl/tbT0RHKCOR0dHH9QNSw71LrwRO750VLx32EZ+ZeSPpz vcPQ7Vt7XaCTq17TbFp1uVhHsxriLjA6Wo8J+6hCdXHYOm6U1gCdGCfXdV3n+n/5M1DV k7aGqgKSH0rXRLimWCa4YU6a0TvUNqGy600dGVsLSuRxgzjHL9fxqDokReHvpDoKUu3u yzpybun04r87YsinKd+3vJGZOHwbrNuQpGV2cHslST6AEAD4f+WbM/ayRzZs/OS3NmgK lb7kobpJ7G2gBBJtEwQtoS0YGP+78yujAAgsDu5OgX/6ETP06cBgSqzYwTKpFNGb0lB3 w0CA== X-Gm-Message-State: AG10YOS4AnVdn2cEBhh5A1fKYgMyIZ6hZ/GoWavvvAiJMCq6SeTlJ8uNRdRvsQEzQd1VIaSP X-Received: by 10.66.253.198 with SMTP id ac6mr7427768pad.37.1454011707910; Thu, 28 Jan 2016 12:08:27 -0800 (PST) Received: from Simons-MacBook-Air.local ([2001:470:b161:0:8def:7e97:ae61:41]) by smtp.googlemail.com with ESMTPSA id n8sm18352173pfj.46.2016.01.28.12.08.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 12:08:27 -0800 (PST) To: Marc Petit-Huguenin , Jonathan Lennox References: <56A83C06.2000800@acm.org> <56AA66F4.4070409@acm.org> From: Simon Perreault Message-ID: <56AA7539.5040909@jive.com> Date: Thu, 28 Jan 2016 15:08:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AA66F4.4070409@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: [tram] Transition to new password algorithm 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:08:29 -0000 Starting a new thread, as requested... Le 2016-01-28 14:07, Marc Petit-Huguenin a écrit : >>> A general question about the PASSWORD-ALGORITHM transition >>> >>> process: do we want to support the use case where a server is >>> >>> gradually transitioning its existing database to have SHA-256 as >>> >>> the password hash algorithm (as users change passwords)? This >>> >>> might result in a case where some users have MD5-hashed passwords >>> >>> in the database, and some have SHA-256 — but the server doesn’t >>> >>> yet know when responding to the initial request which user is >>> >>> making the request, and thus which password algorithms are >>> >>> actually supported for this specific user. Supporting this would >>> >>> require either putting USERNAME in the initial request (which >>> >>> seems bad in the absence of a known realm), or else allowing a >>> >>> server to respond to a followup request with another 401 >>> >>> Unauthorized response, with a shorter PASSWORD-ALGORITHMS list >>> >>> (resulting in long-term authentication requiring three >>> >>> transactions for stunbis clients whose users who are still on >>> >>> MD5). Despite the triple transaction, I’m inclined to recommend >>> >>> the latter. >> >> >> >> Interesting use case regarding the management of an hybrid database >> >> containing mixed MD5/SHA256 users, but is it worth adding that >> >> complexity to the protocol? We're willing to listen to opinion >> >> from the working group, especially people with large deployments. >> >> This is at the end of a long and editorial e-mail, so it’s probably >> worth calling this out in a standalone message. Discuss! :D Simon From nobody Thu Jan 28 12:23:06 2016 Return-Path: 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 DEFCC1ACEA4 for ; Thu, 28 Jan 2016 12:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 hqwz59EkIxWK for ; Thu, 28 Jan 2016 12:23:03 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 9F7B81ACE9A for ; Thu, 28 Jan 2016 12:23:03 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id yy13so28344892pab.3 for ; Thu, 28 Jan 2016 12:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Gk7g5bkARJPR8vXty9367Rnj10klxn7/0w0UjMBIZDo=; b=GYI0kOKpIo2pcenjbpNo4z0pPi7fN/JvSbzWSk5sJc8KdxY3iaxdVIdcahrA+ziE/P WRzuYhKk4T3GCchxwNzbV/44P7FawiPN9f8zP88OWkivscEqR6VUTjyI4V2Z2ZgAuAFd f6dSfpr6DiGaOUHitf14dRHx79qIvq6nTUbS4vlOZHfONYtMqp8Sfc6zmE1FKkuKoEIV Htja12Y4U7qlupXocC4WFhxakB5aPjb7WEALWrvHsvmPZNfSexP0kQQw5aE9vJZ7K5kb jR5boQywN9PFxLdobQ4IvVQe4aXwhHUdvgJMPqeXQE2pOxFUzPeGhBrMwOJfXkEsbIzl 6MHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Gk7g5bkARJPR8vXty9367Rnj10klxn7/0w0UjMBIZDo=; b=DcSSYu2sm5AWB08ncNbRH9UqjnFbQ5CDTdznmm4Z5739eiEDm5cGMvQ86ls5GwsOdh eLDAqc+VJgGQcnpMboFIxKhLPcsjkrSjABMIqVYxcGHrognGI9jf7VGXXxdDAoU4xkJi IbUhfio2AfXuVuqzQNPLZLoF1o/k+vhbLMpPtDpXON8cBcaZRgoCnQOQhh3FzhiJKCH0 I5Hf3YqDGlnPcvhJHb1UuN1ayqdWYRlgtuk+oI79ECnT4zPUm4o2NFAwnHQVm4lJw2jh w6FZ7NFuWcktn1EJV/rgdg/qfMo1Grfzvn+Buij3oKuywtG6ClkH81iRyLCmqvdXFLrI F73g== X-Gm-Message-State: AG10YORRsdTFFr1Fl7tUAR0HGFjj26frCDb5QhGbryJf7aorc1k9W35mw2W83iYAx8h8zmHj X-Received: by 10.66.236.103 with SMTP id ut7mr7558868pac.4.1454012583262; Thu, 28 Jan 2016 12:23:03 -0800 (PST) Received: from Simons-MacBook-Air.local ([2001:470:b161:0:8def:7e97:ae61:41]) by smtp.googlemail.com with ESMTPSA id dz8sm18458400pab.19.2016.01.28.12.23.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 12:23:02 -0800 (PST) To: "Pal Martinsen (palmarti)" , Martin Thomson References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> From: Simon Perreault X-Enigmail-Draft-Status: N1110 Message-ID: <56AA78A4.5020301@jive.com> Date: Thu, 28 Jan 2016 15:23:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , "tram@ietf.org" , Brandon Williams , Justin Uberti Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 20:23:05 -0000 Le 2016-01-28 06:32, Pal Martinsen (palmarti) a écrit : > But that discussion should probably happen in the ICE wg? > (Anyone care to write up improved ICE connectivity checks draft?) My 2 cents... If ICE-bis decides to use something completely unlike STUN for connectivity checks, then yeah, and don't call it STUN, call it "ICE connectivity check protocol" or whatever. But if we're aiming for some similarity, or even compatibility, then it's STUN, and STUN belongs here. Simon From nobody Thu Jan 28 14:41:15 2016 Return-Path: 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 F029C1ACEC8 for ; Thu, 28 Jan 2016 14:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 M-wirvjK9uS7 for ; Thu, 28 Jan 2016 14:41:13 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 B146A1ACEC6 for ; Thu, 28 Jan 2016 14:41:13 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id g73so72036735ioe.3 for ; Thu, 28 Jan 2016 14:41:13 -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=V13rxCt5chZZHNxRekAODDRN4sQnjIPMmdfnkNMS6v0=; b=RFELr97x/PiMdUtr1xg2CyGomoK5qGlkiiL/SvaHXr5nSXFIRgvi9j9KV/2F25smym TPwKKL2THbngEVwoGxGFXnbAuJybXVil4zr4J9B8BAcRSsuryVkLgvqNOqp6r6EptAd3 G1hT9kJAti2Po9VyOUmvy0iNtrdpQZfiSXxoGiObjO7zkc1hVWdet9ygQ11hcvSuyVFG azEInGny+uqU3rbygKt2E6cPt1YnmSS3wrHMeew5P5A0nfUnNsFUzGtbjXKh2cBCWEkG VIU+6Yqpr9q9Yp3l8AVDB3pLl41/Ef4tN3872ma3ZBZuEsubn2mabPzMnjWieLQMe/f4 51zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V13rxCt5chZZHNxRekAODDRN4sQnjIPMmdfnkNMS6v0=; b=OSIx65Xc6C++P3HbnVtmuHvmYMU3a5XUQPCfk87k5LuWdrgBPqJZrmVqEmlh8W9idu iKYRSz8GPb8N4xvSMseuX/GuabnWeR9pw3V/VkR/P9/Og5W2w5sBMrHj49UZTxAtR6xf 04hW3dyA047fdKtMxTEgKMLSALdN4CH/rcwGb3aaAIBmRqUeyWNUm88sE/N+tq4Lgc02 QndTjc9OnNJcumDJq51wDq0oOO4t4MAHZ2KyehaDdG0Ocs3Hjm2O2YIrWL2dIYWiNooO kD2vD4FbAdRDsiTi9qsYL8CTXXq7N/34XmrX9yGVEv+JfmuECgFA1FFnEX73hqo+hcBz ehLQ== X-Gm-Message-State: AG10YOQnmQD1hpwrXnQ6GpQ7/3ZboR+HvoGrdloZgmkaIUe+3TVQP0upO2n7a4foYU9ER+uKorHlhsko/dulyQ== MIME-Version: 1.0 X-Received: by 10.107.33.14 with SMTP id h14mr6264907ioh.108.1454020873129; Thu, 28 Jan 2016 14:41:13 -0800 (PST) Received: by 10.36.149.130 with HTTP; Thu, 28 Jan 2016 14:41:13 -0800 (PST) In-Reply-To: <56AA78A4.5020301@jive.com> References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> <56AA78A4.5020301@jive.com> Date: Fri, 29 Jan 2016 09:41:13 +1100 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Marc Petit-Huguenin , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Justin Uberti Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 22:41:15 -0000 On 29 January 2016 at 07:23, Simon Perreault wrote: > If ICE-bis decides to use something completely unlike STUN for > connectivity checks, then yeah, and don't call it STUN, call it "ICE > connectivity check protocol" or whatever. But if we're aiming for some > similarity, or even compatibility, then it's STUN, and STUN belongs here. Ultimately the chairs need to decide this, but I think that since we are here discussing it now, then this is a fine venue. It's not like it's a different set of people. From nobody Thu Jan 28 16:25:41 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 038C31B2D19; Thu, 28 Jan 2016 16:25:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160129002539.19840.88212.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 16:25:39 -0800 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, tram-chairs@ietf.org, tram@ietf.org, spencerdawkins.ietf@gmail.com, sperreault@jive.com Subject: [tram] Last Call: (Discovery of path characteristics using STUN) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 00:25:40 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Discovery of path characteristics using STUN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to discover the path characteristics using Session Traversal Utilities for NAT (STUN) messages. The measurement information can then be used to influence the endpoint's Interactive Connectivity Establishment (ICE) candidate pair selection algorithm. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 28 17:14:34 2016 Return-Path: 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 622421B305D for ; Thu, 28 Jan 2016 17:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 vKHaIj7sQ15Q for ; Thu, 28 Jan 2016 17:14:30 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 9AD691B305A for ; Thu, 28 Jan 2016 17:14:30 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id n1so34089396vkb.3 for ; Thu, 28 Jan 2016 17:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EhPazUsA4wmDFMopxNkTDVOxdxOGHZTQauGG9Acc0RI=; b=muYyfsM+h4Wlxsy7MLPMjeGXKzpAwiURRR3nvb6uT400FOmbM33+5caIDFyvBh//a0 /J9E3F2PAvURotgsvDiN6Fs57RKgw20uizOZornbwfWCAZK4sVG2XmhmPwxNoFz9cI3j RM8QCpLDKa3xm7AMaW+r3q+FSGbCVX2Vnx9jXNJG63kC+zZgqFJZcWTf6RGqMsPTE94N +ge06Hz53EIZ1TUTP/u3DmVFLnOGm6dG3IqhdMwlBNOzwxRySgnI7gjUJHcI1FKP51vw sf880SVS54D9ttt/e/KuHh2e/XzKx2Q12PP1+VvjPw9DEh4PRs8g0+GDwAziqKu2IDmV HhPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EhPazUsA4wmDFMopxNkTDVOxdxOGHZTQauGG9Acc0RI=; b=CyJDqD3XOG/gDglaA03uk+FU17xVA1TR+bhd7v1HgzU4SqcE06av2xhOEs5jyFmVIL KgFiV9xK3TuyHwmuyQe1sEJhYDOFNsrIaIi2UR1KThOB59iMJrmiA23HTpweXI99ZwsS Xxwp/rkUNfUSV/1V2892AVuAmmBsDMs/msQKq39dNZTWumr4lbOuuMvQmWv7vctLTZou Nh3GmXtZH2sV2yOu8U9e0UzOjxaMdb4GoQYAr7uOrEVbm3UHEvoe+PtqwHmP5OhtkLPb NMbiCvFgY0qaCsSA5PIuyHzAi5vFv3v+0YtvIVcQ0h6REpm6ti3GoCuC7cB0pbLhVeMG RMVg== X-Gm-Message-State: AG10YOSayBX4Z/1PtY+HZNz+uMjHk1HFSLFIGgvKP5Y3PX3pWN4necVXykRO2H4S3Z1hbYJIX/apqld7g2ijUy82 X-Received: by 10.31.149.78 with SMTP id x75mr4181717vkd.103.1454030069448; Thu, 28 Jan 2016 17:14:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Thu, 28 Jan 2016 17:14:09 -0800 (PST) In-Reply-To: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> From: Justin Uberti Date: Thu, 28 Jan 2016 17:14:09 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11426748c89dea052a6ec115 Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 01:14:33 -0000 --001a11426748c89dea052a6ec115 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 27, 2016 at 4:32 PM, Martin Thomson wrote: > I think that this is a fine way to shave this down if we want > something as close to STUN as possible. But none of these changes is > at all compatible. > > The alternative is to look at what we need and to change the > connectivity check entirely so that it is maximally compact. > > For all of these, we need to clearly signal that the compact form is > acceptable, so maybe we can find a way to trim this right down: > > a demux octet (1) > a transaction ID (12-16) > a target ufrag (4) > a source ufrag (4) > an integrity value (8-16) > > So that's 32 bytes, assuming the smallest values mentioned here, and assuming we round to multiples of 4. My proposal ends up with a 32-byte STUN message; the remaining areas for optimization are: - unnecessary(?) magic-cookie; 4 bytes - T + L for USERNAME attributes; 4 bytes, but needed to support variable-size ufrags If you get rid of these things, I think you would end up with: - 4 bytes for demux + length + meta - 12 bytes for combined TID + integrity - 8 bytes for lfrag/rfrag combo =3D 24 bytes, which is slightly better, but maybe not enough to define a ne= w format. > As Justin implies below, we might not need the same aggressive > optimization for responses, because the main driver for reducing > packet size is reducing the check interval without driving the data > rate too high. If too many checks are successful, the responses can > be rate limited to reduce the data rate, but in that case you have > consent, so the only concern there is congestion. > > Other possible tweak is to say that the ufrag attributes in SDP > include base64 encoded binary so that you can boost the entropy of the > reduced sized ufrags by a third. > > Of course, you don't want to use SHA1 for M-I for any of this. > > On 28 January 2016 at 05:25, Justin Uberti wrote: > > ufrag already has a 4-byte lower bound, so we can't really reduce that > > further. > > > > Here is my concrete proposal: > > > https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5deb8Z= XHLJJpadBE/edit#slide=3Did.gc34db0b92_0_23 > > > > Basically: > > - truncate M-I > > - allow special case for 8-byte USERNAME > > - remove tiebreaker, fingerprint, priority attributes > > > > Possibly: > > - combine ICE-CONTROLLING and USERNAME > > - put M-I into transaction ID (for REQUEST; RESPONSE would still need t= o > > have an attribute) > > > > On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti) > > wrote: > >> > >> > >> > On 27 Jan 2016, at 14:39, Simon Perreault > wrote: > >> > > >> > Le 2016-01-26 22:41, Marc Petit-Huguenin a =C3=A9crit : > >> >>> s 14.4/14.5 There has been some discussion in mmusic about trying = to > >> >>>> compress ICE connectivity checks. Justin presented on this. IIRC, > one > >> >>>> of his proposals was to shrink the size of the ICV. It would be > good > >> >>>> to follow up on this and perhaps update stunbis to allow ICV's th= at > >> >>>> are shorter. > >> >> Here's the conclusions (from MMUSIC minutes) of the discussion abou= t > >> >> that in Prague: > >> >> > >> >> "Next steps: We need to discuss more on the approach and get back. > Look > >> >> further into what we can do with ufrag, etc. How much can we reduce > packet > >> >> size safely?" > >> >> > >> >> I do not think that there is consensus enough to take any action at > >> >> this point. > >> > > >> > I am seizing this opportunity to restart discussion on this topic. I > >> > think we've discussed many possibilities, and what is needed at this > >> > moment is an actual concrete text proposal. I don't think it's > >> > necessarily up to the draft editors to come up with such a proposal, > but > >> > rather up to the working group as a whole. > >> > > >> > Discuss. :) > >> > >> I think limiting the size to a reasonable value is fine. A smaller lim= it > >> to UFRAG and so on is simple and nice. > >> > >> I do not think putting much effort into saving a few bytes is worth it > at > >> this point in time. Let us save that for later if we want to tackle > ICEv2 > >> with a different connectivity check format. > >> > >> .-. > >> P=C3=A5l-Erik > >> > >> > > >> > Thanks, > >> > Simon > >> > > >> > _______________________________________________ > >> > 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 > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > --001a11426748c89dea052a6ec115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 27, 2016 at 4:32 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
I think = that this is a fine way to shave this down if we want
something as close to STUN as possible.=C2=A0 But none of these changes is<= br> at all compatible.

The alternative is to look at what we need and to change the
connectivity check entirely so that it is maximally compact.

For all of these, we need to clearly signal that the compact form is
acceptable, so maybe we can find a way to trim this right down:

a demux octet (1)
a transaction ID (12-16)
a target ufrag (4)
a source ufrag (4)
an integrity value (8-16)

So that's 32 bytes, assuming the smallest values = mentioned here, and assuming we round to multiples of 4.

My proposal ends up with a 32-byte STUN message; the remaining areas= for optimization are:
- unnecessary(?) magic-cookie; 4 bytes
- T + L for USERNAME attributes; 4 bytes, but needed to support vari= able-size ufrags

If you get rid of these things, I= think you would end up with:
- 4 bytes for demux + length + meta=
- 12 bytes for combined TID + integrity
- 8 bytes for = lfrag/rfrag combo

=3D 24 bytes, which is slightly = better, but maybe not enough to define a new format.
=C2=A0
=
As Justin implies below, we might not need the same aggressive
optimization for responses, because the main driver for reducing
packet size is reducing the check interval without driving the data
rate too high.=C2=A0 If too many checks are successful, the responses can be rate limited to reduce the data rate, but in that case you have
consent, so the only concern there is congestion.

Other possible tweak is to say that the ufrag attributes in SDP
include base64 encoded binary so that you can boost the entropy of the
reduced sized ufrags by a third.

Of course, you don't want to use SHA1 for M-I for any of this.

On 28 January 2016 at 05:25, Justin Uberti <juberti@google.com> wrote:
> ufrag already has a 4-byte lower bound, so we can't really reduce = that
> further.
>
> Here is my concrete proposal:
> https://docs.google.com/presentation/d/10AGaMWifWoDaG9i= _FKDnsw9LgA_5deb8ZXHLJJpadBE/edit#slide=3Did.gc34db0b92_0_23
>
> Basically:
> - truncate M-I
> - allow special case for 8-byte USERNAME
> - remove tiebreaker, fingerprint, priority attributes
>
> Possibly:
> - combine ICE-CONTROLLING and USERNAME
> - put M-I into transaction ID (for REQUEST; RESPONSE would still need = to
> have an attribute)
>
> On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti)
> <palmarti@cisco.com> w= rote:
>>
>>
>> > On 27 Jan 2016, at 14:39, Simon Perreault <sperreault@jive.com> wrote:
>> >
>> > Le 2016-01-26 22:41, Marc Petit-Huguenin a =C3=A9crit :
>> >>> s 14.4/14.5 There has been some discussion in mmusic = about trying to
>> >>>> compress ICE connectivity checks. Justin presente= d on this. IIRC, one
>> >>>> of his proposals was to shrink the size of the IC= V. It would be good
>> >>>> to follow up on this and perhaps update stunbis t= o allow ICV's that
>> >>>> are shorter.
>> >> Here's the conclusions (from MMUSIC minutes) of the d= iscussion about
>> >> that in Prague:
>> >>
>> >> "Next steps: We need to discuss more on the approach= and get back. Look
>> >> further into what we can do with ufrag, etc. How much can= we reduce packet
>> >> size safely?"
>> >>
>> >> I do not think that there is consensus enough to take any= action at
>> >> this point.
>> >
>> > I am seizing this opportunity to restart discussion on this t= opic. I
>> > think we've discussed many possibilities, and what is nee= ded at this
>> > moment is an actual concrete text proposal. I don't think= it's
>> > necessarily up to the draft editors to come up with such a pr= oposal, but
>> > rather up to the working group as a whole.
>> >
>> > Discuss. :)
>>
>> I think limiting the size to a reasonable value is fine. A smaller= limit
>> to UFRAG and so on is simple and nice.
>>
>> I do not think putting much effort into saving a few bytes is wort= h it at
>> this point in time. Let us save that for later if we want to tackl= e ICEv2
>> with a different connectivity check format.
>>
>> .-.
>> P=C3=A5l-Erik
>>
>> >
>> > Thanks,
>> > Simon
>> >
>> > _______________________________________________
>> > 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 >
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

--001a11426748c89dea052a6ec115-- From nobody Thu Jan 28 18:42:18 2016 Return-Path: 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 703FD1B3747 for ; Thu, 28 Jan 2016 18:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_39=0.6, 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 5lEQXx75-5VX for ; Thu, 28 Jan 2016 18:42:16 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 8A58F1B3742 for ; Thu, 28 Jan 2016 18:42:16 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id ik10so27611552igb.1 for ; Thu, 28 Jan 2016 18:42:16 -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=IW3rer6H4jV16KzdyIUYgSic6sSSBp0wTGX7BI2vX6Q=; b=yK5Ckqo9PCWfQXtG5UBiaAw2uW+fIqn0trO4Rm7/ehkxanL7xJuoJqC7Ar+qavlR6u cKIWMOwoTkLWl/w3kVkYXoCK5BGL4WuzuUNcelo55zQ8rDnsVM5WMz5INUHKdnAs95XF eCD8/rIhCBpuLAJGFIaJYmAgGuAthB3UkScF1lNG0JBdQWXouuodKELY/hvxN9pl+bmI GSuynL3J+a+I8FVjOU6MmJpWwEpE4NTskXxi7nzHBTXDTMorvRa9wpF3+n2COM8OQtmQ sa3YewKNLnVoMpx5rbLZeBt8XJgGPEoGxKkrSngfNFSaMtr2kwVh2xkvoMXCR6QSSiAi RJaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IW3rer6H4jV16KzdyIUYgSic6sSSBp0wTGX7BI2vX6Q=; b=b1wkJBlxwwcZ1IzvY+0LQD1Nsa/6CJfLFDoDNMjX3Bg4fz9DKh23QsIkPyHqQsskpm qP2W1IuxAK1qK1ujs6+K9lSWEXcoAtTb4GbxI0NImpMnvS8tZfv2T/c98Ezn4rlGmCSl d8jJ0qTAXrbl2YxNqkPu/dqUzFUOKb4301USFpjsB4nnvEQJ5WTc8BkX6uDDVC6Yrp+P j6qOaDUNBd0nyPKSAySHdgSHJ2X5ZN3PDhRpVaB1A5n/NVJ9peF5OPYbKwDE/iGvKg+v qHHT4gfj+VTdouL26NmvzY9um4HkGeclrxoR6v4V6jFTz9j1ZBU0HsOeNY7R5sISU4Yi 7fpw== X-Gm-Message-State: AG10YOT/AoD3DnEZ/D4cOVkT1U0c8BDJam4nH8UH/XRERRtcAsha8qfK3NgLd9/rvsbE7ZW5m3/B0S5cOWtjJQ== MIME-Version: 1.0 X-Received: by 10.50.13.102 with SMTP id g6mr7508969igc.77.1454035336008; Thu, 28 Jan 2016 18:42:16 -0800 (PST) Received: by 10.36.149.130 with HTTP; Thu, 28 Jan 2016 18:42:15 -0800 (PST) In-Reply-To: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> Date: Fri, 29 Jan 2016 13:42:15 +1100 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 02:42:17 -0000 On 29 January 2016 at 12:14, Justin Uberti wrote: > = 24 bytes, which is slightly better, but maybe not enough to define a new > format. I think that you just did just that: this is a new format. Your savings here are gained by reducing TID+integrity. I'm a little concerned about how aggressively you are reducing the transaction ID space, since the packet no longer includes enough fresh entropy for the integrity to help prevent an off-path attacker from spoofing a packet. But now we're arguing about savings that won't mean much since the per-packet overheads will dominate. I'd say that 32 bytes or 24 is pretty good. From nobody Thu Jan 28 18:52:16 2016 Return-Path: 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 6CEC61B3755 for ; Thu, 28 Jan 2016 18:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 EkSuii56GrKh for ; Thu, 28 Jan 2016 18:52:11 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E811B1B375F for ; Thu, 28 Jan 2016 18:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3876; q=dns/txt; s=iport; t=1454035927; x=1455245527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fNcj5Snw3RzuSLzvkML/iez8pvAaXn77S0I937XbYLc=; b=PKjEqNfb1pUnGgmLN864EXSYjif4QYXa8MqXY5olvGmKJE0OkwD+vIbG +PdRU5M7MVEOI26OGT/BRCiK8J7nEEHU/BCcz5h86jrcLmUpty05b5ylD A04iaQet/Yd+C51MzwpDyS8I5m9gCoDSWsc7Tz2GReWnNqoJDTa7bMhVd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgC50qpW/5xdJa1egzdSbQaIUrFFA?= =?us-ascii?q?Q2BYhgKhW0CHIEhOBQBAQEBAQEBgQqEQQEBAQQBAQEgEToLDAQCAQgOAwQBAQM?= =?us-ascii?q?CFA8DAgICJQsUAQgIAgQBDQUIiBMOsGyPGAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?REEe4UShDeBNgGCYy44gjKBOgWWbgGNQ454jjwBHgEBQoIBAQEYgU9qiAF8AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.22,361,1449532800"; d="scan'208";a="230824304" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2016 02:52:06 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u0T2q7bv018289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2016 02:52:07 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Jan 2016 20:52:06 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Thu, 28 Jan 2016 20:52:06 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Marc Petit-Huguenin , Jonathan Lennox Thread-Topic: [tram] Transition to new password algorithm Thread-Index: AQHRWgeqs/jZE7OlqUG+jWE16jb23Z8RyGjQ Date: Fri, 29 Jan 2016 02:52:06 +0000 Message-ID: <702124c26bf84821a3974ba1db551e7f@XCH-RCD-017.cisco.com> References: <56A83C06.2000800@acm.org> <56AA66F4.4070409@acm.org> <56AA7539.5040909@jive.com> In-Reply-To: <56AA7539.5040909@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.58.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Transition to new password algorithm 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 02:52:13 -0000 ICAgbyAgSWYgdGhlIE5PTkNFIGF0dHJpYnV0ZSBzdGFydHMgd2l0aCB0aGUgdmFsdWUgIm9iTWF0 Sm9zMiIgYnV0IHRoZQ0KICAgICAgcmVxdWVzdCBjb250YWlucyBuZWl0aGVyIFBBU1NXT1JELUFM R09SSVRITVMgbm9yIFBBU1NXT1JELQ0KICAgICAgQUxHT1JJVEhNLCB0aGVuIHRoZSByZXF1ZXN0 IGlzIHByb2Nlc3NlZCBhcyB0aG91Z2ggUEFTU1dPUkQtDQogICAgICBBTEdPUklUSE0gd2VyZSBN RDUgKE5vdGUgdGhhdCBpZiB0aGUgb3JpZ2luYWwgUEFTU1dPUkQtQUxHT1JJVEhNUw0KICAgICAg YXR0cmlidXRlIGRpZCBub3QgY29udGFpbiBNRDUsIHRoaXMgd2lsbCByZXN1bHQgaW4gYSA0MDAg QmFkDQogICAgICBSZXF1ZXN0IGluIGEgbGF0ZXIgc3RlcCBiZWxvdykuDQoNClRoZSBhYm92ZSBy dWxlIGNvdWxkIHJlc3VsdCBpbiBkb3duZ3JhZGUgYXR0YWNrLiBJZiB0aGUgc2VydmVyIHN1cHBv cnRzIGJvdGggcGFzc3dvcmQgYWxnb3JpdGhtcyBhbmQgTUlNIGF0dGFja2VyIHJlbW92ZXMgUEFT U1dPUkQtQUxHT1JJVEhNUyBhdHRyaWJ1dGUgZnJvbSB0aGUgcmVzcG9uc2UsIGZvcmNpbmcgdGhl IGNsaWVudCB0byBwaWNrIE1ENS4gSG93IGRvZXMgdGhlIHNlcnZlciBkZXRlY3Qgc3VjaCBhbiBh dHRhY2sgPw0KDQotVGlydQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNpbW9u IFBlcnJlYXVsdA0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMjksIDIwMTYgMTozOCBBTQ0KPiBU bzogTWFyYyBQZXRpdC1IdWd1ZW5pbjsgSm9uYXRoYW4gTGVubm94DQo+IENjOiB0cmFtQGlldGYu b3JnDQo+IFN1YmplY3Q6IFt0cmFtXSBUcmFuc2l0aW9uIHRvIG5ldyBwYXNzd29yZCBhbGdvcml0 aG0NCj4gDQo+IFN0YXJ0aW5nIGEgbmV3IHRocmVhZCwgYXMgcmVxdWVzdGVkLi4uDQo+IA0KPiBM ZSAyMDE2LTAxLTI4IDE0OjA3LCBNYXJjIFBldGl0LUh1Z3VlbmluIGEgw6ljcml0IDoNCj4gPj4+ IEEgZ2VuZXJhbCBxdWVzdGlvbiBhYm91dCB0aGUgUEFTU1dPUkQtQUxHT1JJVEhNIHRyYW5zaXRp b24NCj4gPj4+ID4+PiBwcm9jZXNzOiBkbyB3ZSB3YW50IHRvIHN1cHBvcnQgdGhlIHVzZSBjYXNl IHdoZXJlIGEgc2VydmVyIGlzDQo+ID4+PiA+Pj4gZ3JhZHVhbGx5IHRyYW5zaXRpb25pbmcgaXRz IGV4aXN0aW5nIGRhdGFiYXNlIHRvIGhhdmUgU0hBLTI1NiBhcw0KPiA+Pj4gPj4+IHRoZSBwYXNz d29yZCBoYXNoIGFsZ29yaXRobSAoYXMgdXNlcnMgY2hhbmdlIHBhc3N3b3Jkcyk/ICBUaGlzDQo+ ID4+PiA+Pj4gbWlnaHQgcmVzdWx0IGluIGEgY2FzZSB3aGVyZSBzb21lIHVzZXJzIGhhdmUgTUQ1 LWhhc2hlZA0KPiA+Pj4gPj4+IHBhc3N3b3JkcyBpbiB0aGUgZGF0YWJhc2UsIGFuZCBzb21lIGhh dmUgU0hBLTI1NiDigJQgYnV0IHRoZQ0KPiA+Pj4gPj4+IHNlcnZlciBkb2VzbuKAmXQgeWV0IGtu b3cgd2hlbiByZXNwb25kaW5nIHRvIHRoZSBpbml0aWFsIHJlcXVlc3QNCj4gPj4+ID4+PiB3aGlj aCB1c2VyIGlzIG1ha2luZyB0aGUgcmVxdWVzdCwgYW5kIHRodXMgd2hpY2ggcGFzc3dvcmQNCj4g Pj4+ID4+PiBhbGdvcml0aG1zIGFyZSBhY3R1YWxseSBzdXBwb3J0ZWQgZm9yIHRoaXMgc3BlY2lm aWMgdXNlci4NCj4gPj4+ID4+PiBTdXBwb3J0aW5nIHRoaXMgd291bGQgcmVxdWlyZSBlaXRoZXIg cHV0dGluZyBVU0VSTkFNRSBpbiB0aGUNCj4gPj4+ID4+PiBpbml0aWFsIHJlcXVlc3QgKHdoaWNo IHNlZW1zIGJhZCBpbiB0aGUgYWJzZW5jZSBvZiBhIGtub3duDQo+ID4+PiA+Pj4gcmVhbG0pLCBv ciBlbHNlIGFsbG93aW5nIGEgc2VydmVyIHRvIHJlc3BvbmQgdG8gYSBmb2xsb3d1cA0KPiA+Pj4g Pj4+IHJlcXVlc3Qgd2l0aCBhbm90aGVyIDQwMSBVbmF1dGhvcml6ZWQgcmVzcG9uc2UsIHdpdGgg YSBzaG9ydGVyDQo+ID4+PiA+Pj4gUEFTU1dPUkQtQUxHT1JJVEhNUyBsaXN0IChyZXN1bHRpbmcg aW4gbG9uZy10ZXJtIGF1dGhlbnRpY2F0aW9uDQo+ID4+PiA+Pj4gcmVxdWlyaW5nIHRocmVlIHRy YW5zYWN0aW9ucyBmb3Igc3R1bmJpcyBjbGllbnRzIHdob3NlIHVzZXJzIHdobw0KPiA+Pj4gPj4+ IGFyZSBzdGlsbCBvbiBNRDUpLiAgRGVzcGl0ZSB0aGUgdHJpcGxlIHRyYW5zYWN0aW9uLCBJ4oCZ bSBpbmNsaW5lZA0KPiA+Pj4gPj4+IHRvIHJlY29tbWVuZCB0aGUgbGF0dGVyLg0KPiA+PiA+Pg0K PiA+PiA+PiBJbnRlcmVzdGluZyB1c2UgY2FzZSByZWdhcmRpbmcgdGhlIG1hbmFnZW1lbnQgb2Yg YW4gaHlicmlkDQo+ID4+ID4+IGRhdGFiYXNlIGNvbnRhaW5pbmcgbWl4ZWQgTUQ1L1NIQTI1NiB1 c2VycywgYnV0IGlzIGl0IHdvcnRoIGFkZGluZw0KPiA+PiA+PiB0aGF0IGNvbXBsZXhpdHkgdG8g dGhlIHByb3RvY29sPyAgV2UncmUgd2lsbGluZyB0byBsaXN0ZW4gdG8NCj4gPj4gPj4gb3Bpbmlv biBmcm9tIHRoZSB3b3JraW5nIGdyb3VwLCBlc3BlY2lhbGx5IHBlb3BsZSB3aXRoIGxhcmdlDQo+ IGRlcGxveW1lbnRzLg0KPiA+Pg0KPiA+PiBUaGlzIGlzIGF0IHRoZSBlbmQgb2YgYSBsb25nIGFu ZCBlZGl0b3JpYWwgZS1tYWlsLCBzbyBpdOKAmXMgcHJvYmFibHkNCj4gPj4gd29ydGggY2FsbGlu ZyB0aGlzIG91dCBpbiBhIHN0YW5kYWxvbmUgbWVzc2FnZS4NCj4gDQo+IERpc2N1c3MhIDpEDQo+ IA0KPiBTaW1vbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Thu Jan 28 22:41:05 2016 Return-Path: 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 D03731A009F for ; Thu, 28 Jan 2016 22:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RP_MATCHES_RCVD=-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 jytp7jVF_7S0 for ; Thu, 28 Jan 2016 22:41:00 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 9B23D1A009E for ; Thu, 28 Jan 2016 22:41:00 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id n1so36994441vkb.3 for ; Thu, 28 Jan 2016 22:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Iu87ALbSI3aS9kJGorCTSlnbLWm+k7eUjGzmnGUA9Ws=; b=bWelXrcNHfkwNSeG4bwrlQ5fBI2CLVv/OtUk20kA9bSCo5n21QXcqvWac9gQeDrfTS EDOy2+1rNN4garRrkCf0cOLE6UdC09BGqL0bxDmdYbh/QGYGgDwIgKf8sZhVGU11U5hI rnUL/k2WF/93cOVAO22F8kxI1eVyRjWXjfQ9swfj9XFyC0zEFmAeHee67YWQk2jbGNVm CohaS2Bp8o+lDF+fls5S5n5gmRiC6jEHikeXBvwKCmJlRYD1gfDwdzrhmevlgOD+xvqB j0VJfIHsWZKfbmnn3RkmyvqkayxM9sJOv7Koov8ILOm4ypPegZECJYXNyBLqfhS5Eb1C F3eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Iu87ALbSI3aS9kJGorCTSlnbLWm+k7eUjGzmnGUA9Ws=; b=NDOY/3IAyG9awb8MxmzPQ0fk0Z/4lwDZq5jBu51+1+zCz/ou4nPWMpxm6JlIWZXrR1 sFPhfg21IT6YwicjnSIpEHwDR0RYAbVORv393eHnZNWXPXXVLQiczzo6RWoKJ9t+Pxc1 ZVFQGzppWK9+rCS5SVuMm7QP2qDpCaqA6EvCYRRpfBfvQi6KA2K8UJT0H0ULUFI8pEgI OFPvT3/jCk9TA/ZkB5MKF9mTCKP3gbtsoDFM4fYaGRSE+Q/vrAQ9KWgx6MuOff2rk91d 2/L3q7FC0IR3ul65x9Yn8ZMm3GC4HmWLyGoWvlEAuUa6mdAX0hh0viW1jAcdfqpuHmRu 2prw== X-Gm-Message-State: AG10YOQU7Z6dIZLO7Sj6Vl+oInx+tfdmePOA/OD+eqskkEIThmFrEXqHUMJ0zpdodZo40fDqZTkl4kfkvPraHQEr X-Received: by 10.31.149.78 with SMTP id x75mr4789719vkd.103.1454049659488; Thu, 28 Jan 2016 22:40:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Thu, 28 Jan 2016 22:40:39 -0800 (PST) In-Reply-To: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> From: Justin Uberti Date: Thu, 28 Jan 2016 22:40:39 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1142674870f4f5052a73515e Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 06:41:02 -0000 --001a1142674870f4f5052a73515e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 28, 2016 at 6:42 PM, Martin Thomson wrote: > On 29 January 2016 at 12:14, Justin Uberti wrote: > > = 24 bytes, which is slightly better, but maybe not enough to define a > new > > format. > > I think that you just did just that: this is a new format. > > Your savings here are gained by reducing TID+integrity. I'm a little > concerned about how aggressively you are reducing the transaction ID > space, since the packet no longer includes enough fresh entropy for > the integrity to help prevent an off-path attacker from spoofing a > packet. Not sure I follow. It's protected by a keyed HMAC, so even if the unique data in the packet is low (4 bytes of random TID value, perhaps), it's unclear how an off-path attacker could generate the right HMAC. > But now we're arguing about savings that won't mean much since the > per-packet overheads will dominate. I'd say that 32 bytes or 24 is > pretty good. > With 32 bytes we can keep the overall STUN heritage, and just tweak the details. Lower than that, we're defining our own demux mechanisms, extension framework, etc. --001a1142674870f4f5052a73515e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 28, 2016 at 6:42 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 29 January 2016 at 12:14, Justin Uberti <juberti@google.com> wrote:
> =3D 24 bytes, which is slightly better, but maybe not enough to define= a new
> format.

I think that you just did just that: this is a new format.

Your savings here are gained by reducing TID+integrity.=C2=A0 I'm a lit= tle
concerned about how aggressively you are reducing the transaction ID
space, since the packet no longer includes enough fresh entropy for
the integrity to help prevent an off-path attacker from spoofing a
packet.

Not sure I follow. It's protect= ed by a keyed HMAC, so even if the unique data in the packet is low (4 byte= s of random TID value, perhaps), it's unclear how an off-path attacker = could generate the right HMAC.


But now we're arguing about savings that won't mean much since the<= br> per-packet overheads will dominate.=C2=A0 I'd say that 32 bytes or 24 i= s
pretty good.

With 32 bytes we can keep = the overall STUN heritage, and just tweak the details. Lower than that, we&= #39;re defining our own demux mechanisms, extension framework, etc.=C2=A0

--001a1142674870f4f5052a73515e-- From nobody Fri Jan 29 07:01:45 2016 Return-Path: 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 ABD651A6FFB for ; Fri, 29 Jan 2016 07:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 w-7KYgQnsYTz for ; Fri, 29 Jan 2016 07:01:42 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E53321A6FF8 for ; Fri, 29 Jan 2016 07:01:41 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2A138433423; Fri, 29 Jan 2016 15:01:41 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 0213E43341C; Fri, 29 Jan 2016 15:01:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454079701; bh=7lbQZqC4Wwg4Eclupxm7s5Y+6fxCa8eKSZQvd/2fv8I=; l=3396; h=To:References:From:Date:In-Reply-To:From; b=vtvyNcaz//MFPyF0EyXaGlanM0yCwB313l+22OTvId2HYX39vjG969cylWDP52m8v pg3rNWM+yp1MWoHpwTSRuJuUX5bC+5HliPdS7oN+qH3BhzR9ls7MhXKx5VFYEEtE1e svPTk02OcNpiBeSGK5LSAeRy8t/6q6yHvHIejkiI= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id EDE42202E; Fri, 29 Jan 2016 15:01:40 +0000 (GMT) To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <56A93DE9.4020909@akamai.com> From: Brandon Williams Message-ID: <56AB7ED4.5010202@akamai.com> Date: Fri, 29 Jan 2016 10:01:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:01:44 -0000 On 01/28/2016 06:05 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Thursday, January 28, 2016 3:30 AM >> To: Tirumaleswar Reddy (tireddy); tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt >> >>>> s3.2.2 >>>> A common use case for mobility will likely be what some have described >> as >>>> the "walk out the door" problem. Two interfaces are functional (e.g. >>>> both wifi and lte) and you want to seamlessly switch from one to the >> other. >>>> You probably want to be able to use both interfaces at the same time >> while >>>> you're figuring out whether/when to switch from one to the other (make >>>> before break). >>> >>> I don't see a problem. Applications can pick both interfaces, create multiple >> allocations, try connectivity checks on both interfaces, draft-ietf-tram-stun- >> path-data and MPRTP can be used to pick interface based on path >> characteristics. Keep the alternate candidates pair alive for switch-over and >> use ICE continuous nomination for seamless move. >> >> So, basically, don't use turn-mobility for this purpose? I'm not clear >> why you think the more complicated approach is preferable. Why would it >> be bad for turn-mobility to support make-before-break? > > Extending TURN-mobility to support make-before-break makes the proposal more complex, it may end-up just like MPTCP. > Why not use ICE or MPRTP for make-before-break ? > make-before-break means client can use multiple interfaces to send traffic to the same allocation on the server, server must also load balance return traffic etc. > Without make-before-break capability, I think the mechanism might be limited enough in utility that it won't be widely used. This is mostly because I think it requires the application to be able to sustain potentially significant bursts of packet loss, which could be unacceptable for realtime communication use cases, and maybe for live video streams as well. If the app keeps both addresses active and sends data on the old address while waiting for the refresh response, then as soon as the refresh request is received by the relay, all in-flight data is now effectively lost because it will be dropped by the relay. If the refresh response is lost, the client will continue sending from the previous address; resumption of data flow will require retransmit of the refresh request with an even longer period of message drops. If on the other hand the app optimistically starts sending messages from the new address as soon as it sends the refresh request, then it's susceptible to message drops if the refresh request is lost or otherwise fails validation. If it keeps the previous allocation active for receiving packets, at least it won't drop a lot of inbound messages. If the old address simply goes away when the new address comes up, there's no way to avoid this anyway. However, when it's possible to have both addresses active during the transition, make-before-break support would allow seamless transition from one to the other. I'm not suggesting we need something as complicated as MPRTP; just that meeting the minimal requirements for seamless transition from one address to another could make the mechanism a lot more useful. --Brandon From nobody Fri Jan 29 07:06:30 2016 Return-Path: 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 5120D1A7008 for ; Fri, 29 Jan 2016 07:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ESi4afSz5Ugh for ; Fri, 29 Jan 2016 07:06:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2A99D1A7002 for ; Fri, 29 Jan 2016 07:06:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D0256433423; Fri, 29 Jan 2016 15:06:21 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A9609433418; Fri, 29 Jan 2016 15:06:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454079981; bh=KlKCKe8VHL5U6O074rcGGSExEmMAGwTKS/jeMohPIUg=; l=3525; h=From:To:References:Date:In-Reply-To:From; b=mCFLwifVUUX15U8rR9Jm34fGpNu3dnCC6IWuYhpaGZ6q4kBEB6YMHSnBhwfR8K4kJ TAniJOT9E5yA9NSKpFuK3jJ8DNFv+0486H8UeAHuPnR/34bfZ/+MEBvYRDSS2WUr9h c/Jth8QBbDRwxV9GGBv0T6ilJ8IlnPgANfgTvcvg= Received: from [172.28.112.83] (bowill.kendall.corp.akamai.com [172.28.112.83]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A2CD0202C; Fri, 29 Jan 2016 15:06:21 +0000 (GMT) From: Brandon Williams To: tram@ietf.org, "Tirumaleswar Reddy (tireddy)" References: <56A83C06.2000800@acm.org> <56AA66F4.4070409@acm.org> <56AA7539.5040909@jive.com> <702124c26bf84821a3974ba1db551e7f@XCH-RCD-017.cisco.com> Message-ID: <56AB7FED.5090801@akamai.com> Date: Fri, 29 Jan 2016 10:06:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <702124c26bf84821a3974ba1db551e7f@XCH-RCD-017.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Transition to new password algorithm 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:06:27 -0000 A client that supports PASSWORD-ALGORITHMS only accepts a NONCE with "obMatJos2" if PASSWORD-ALGORITHMS is present and it is required to echo back the same PASSWORD-ALGORITHMS attribute in the authenticated request. If PASSWORD-ALGORITHMS is not present in the new request, that can only mean that the client doesn't support it. --Brandon On 01/28/2016 09:52 PM, Tirumaleswar Reddy (tireddy) wrote: > o If the NONCE attribute starts with the value "obMatJos2" but the > request contains neither PASSWORD-ALGORITHMS nor PASSWORD- > ALGORITHM, then the request is processed as though PASSWORD- > ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS > attribute did not contain MD5, this will result in a 400 Bad > Request in a later step below). > > The above rule could result in downgrade attack. If the server supports both password algorithms and MIM attacker removes PASSWORD-ALGORITHMS attribute from the response, forcing the client to pick MD5. How does the server detect such an attack ? > > -Tiru > > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: Friday, January 29, 2016 1:38 AM >> To: Marc Petit-Huguenin; Jonathan Lennox >> Cc: tram@ietf.org >> Subject: [tram] Transition to new password algorithm >> >> Starting a new thread, as requested... >> >> Le 2016-01-28 14:07, Marc Petit-Huguenin a écrit : >>>>> A general question about the PASSWORD-ALGORITHM transition >>>>>>>> process: do we want to support the use case where a server is >>>>>>>> gradually transitioning its existing database to have SHA-256 as >>>>>>>> the password hash algorithm (as users change passwords)? This >>>>>>>> might result in a case where some users have MD5-hashed >>>>>>>> passwords in the database, and some have SHA-256 — but the >>>>>>>> server doesn’t yet know when responding to the initial request >>>>>>>> which user is making the request, and thus which password >>>>>>>> algorithms are actually supported for this specific user. >>>>>>>> Supporting this would require either putting USERNAME in the >>>>>>>> initial request (which seems bad in the absence of a known >>>>>>>> realm), or else allowing a server to respond to a followup >>>>>>>> request with another 401 Unauthorized response, with a shorter >>>>>>>> PASSWORD-ALGORITHMS list (resulting in long-term authentication >>>>>>>> requiring three transactions for stunbis clients whose users who >>>>>>>> are still on MD5). Despite the triple transaction, I’m inclined >>>>>>>> to recommend the latter. >>>>>> >>>>>> Interesting use case regarding the management of an hybrid >>>>>> database containing mixed MD5/SHA256 users, but is it worth adding >>>>>> that complexity to the protocol? We're willing to listen to >>>>>> opinion from the working group, especially people with large >> deployments. >>>> >>>> This is at the end of a long and editorial e-mail, so it’s probably >>>> worth calling this out in a standalone message. >> >> Discuss! :D >> >> Simon >> >> _______________________________________________ >> 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 > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Fri Jan 29 07:13:32 2016 Return-Path: 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 D4C641A8700 for ; Fri, 29 Jan 2016 07:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 OJoyfTql85O2 for ; Fri, 29 Jan 2016 07:13:29 -0800 (PST) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34181A86FE for ; Fri, 29 Jan 2016 07:13:29 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0TF6D17021610; Fri, 29 Jan 2016 10:13:18 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 20qrw9rbt1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Jan 2016 10:13:18 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 29 Jan 2016 09:13:17 -0600 From: Jonathan Lennox To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] Transition to new password algorithm Thread-Index: AQHRWgenG3i6BdNwOkeTCX7KOHKjx58SMJkAgADPGQA= Date: Fri, 29 Jan 2016 15:13:16 +0000 Message-ID: <8DA752D4-233F-49E8-ABF3-62AE973F6182@vidyo.com> References: <56A83C06.2000800@acm.org> <56AA66F4.4070409@acm.org> <56AA7539.5040909@jive.com> <702124c26bf84821a3974ba1db551e7f@XCH-RCD-017.cisco.com> In-Reply-To: <702124c26bf84821a3974ba1db551e7f@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <3A1C3A85FAD7C04BBDA30F0526130910@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2016-01-29_06:2016-01-29,2016-01-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1601290262 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Marc Petit-Huguenin Subject: Re: [tram] Transition to new password algorithm 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:13:31 -0000 DQo+IE9uIEphbiAyOCwgMjAxNiwgYXQgOTo1MiBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KSA8dGlyZWRkeUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gICBvICBJZiB0aGUgTk9OQ0Ug YXR0cmlidXRlIHN0YXJ0cyB3aXRoIHRoZSB2YWx1ZSAib2JNYXRKb3MyIiBidXQgdGhlDQo+ICAg ICAgcmVxdWVzdCBjb250YWlucyBuZWl0aGVyIFBBU1NXT1JELUFMR09SSVRITVMgbm9yIFBBU1NX T1JELQ0KPiAgICAgIEFMR09SSVRITSwgdGhlbiB0aGUgcmVxdWVzdCBpcyBwcm9jZXNzZWQgYXMg dGhvdWdoIFBBU1NXT1JELQ0KPiAgICAgIEFMR09SSVRITSB3ZXJlIE1ENSAoTm90ZSB0aGF0IGlm IHRoZSBvcmlnaW5hbCBQQVNTV09SRC1BTEdPUklUSE1TDQo+ICAgICAgYXR0cmlidXRlIGRpZCBu b3QgY29udGFpbiBNRDUsIHRoaXMgd2lsbCByZXN1bHQgaW4gYSA0MDAgQmFkDQo+ICAgICAgUmVx dWVzdCBpbiBhIGxhdGVyIHN0ZXAgYmVsb3cpLg0KPiANCj4gVGhlIGFib3ZlIHJ1bGUgY291bGQg cmVzdWx0IGluIGRvd25ncmFkZSBhdHRhY2suIElmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgYm90aCBw YXNzd29yZCBhbGdvcml0aG1zIGFuZCBNSU0gYXR0YWNrZXIgcmVtb3ZlcyBQQVNTV09SRC1BTEdP UklUSE1TIGF0dHJpYnV0ZSBmcm9tIHRoZSByZXNwb25zZSwgZm9yY2luZyB0aGUgY2xpZW50IHRv IHBpY2sgTUQ1LiBIb3cgZG9lcyB0aGUgc2VydmVyIGRldGVjdCBzdWNoIGFuIGF0dGFjayA/DQoN Ckl0IGRvZXNu4oCZdCwgdGhlIGNsaWVudCBkb2VzIOKAlCBpZiB0aGUgY2xpZW50IHNlZXMgYSBu b25jZSBiZWdpbm5pbmcgd2l0aCBvYk1hdEpvczIgYnV0IG5vIFBBU1NXT1JELUFMR09SSVRITVMg YXR0cmlidXRlIGluIHRoZSByZXNwb25zZSwgaXQgTVVTVCBpZ25vcmUgdGhlIHJlc3BvbnNlLg0K DQooSWYgdGhlIGNsaWVudCBjaG9vc2VzIG5vdCB0byBmb2xsb3cgdGhpcywgaXTigJlzIGVzc2Vu dGlhbGx5IGJlaGF2aW5nIGFzIGFuIFJGQyA1Mzg5IGNsaWVudCwgd2hpY2ggYXMgbG9uZyBhcyB5 b3XigJlyZSBzdXBwb3J0aW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgdW5hdm9pZGFibGUg YmVoYXZpb3IuICBCdXQgYSB0aGlyZC1wYXJ0eSBjYW7igJl0IGZvcmNlIGEgZG93bmdyYWRlLikN Cg0KPiANCj4gLVRpcnUNCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT aW1vbiBQZXJyZWF1bHQNCj4+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAyOSwgMjAxNiAxOjM4IEFN DQo+PiBUbzogTWFyYyBQZXRpdC1IdWd1ZW5pbjsgSm9uYXRoYW4gTGVubm94DQo+PiBDYzogdHJh bUBpZXRmLm9yZw0KPj4gU3ViamVjdDogW3RyYW1dIFRyYW5zaXRpb24gdG8gbmV3IHBhc3N3b3Jk IGFsZ29yaXRobQ0KPj4gDQo+PiBTdGFydGluZyBhIG5ldyB0aHJlYWQsIGFzIHJlcXVlc3RlZC4u Lg0KPj4gDQo+PiBMZSAyMDE2LTAxLTI4IDE0OjA3LCBNYXJjIFBldGl0LUh1Z3VlbmluIGEgw6lj cml0IDoNCj4+Pj4+IEEgZ2VuZXJhbCBxdWVzdGlvbiBhYm91dCB0aGUgUEFTU1dPUkQtQUxHT1JJ VEhNIHRyYW5zaXRpb24NCj4+Pj4+Pj4+IHByb2Nlc3M6IGRvIHdlIHdhbnQgdG8gc3VwcG9ydCB0 aGUgdXNlIGNhc2Ugd2hlcmUgYSBzZXJ2ZXIgaXMNCj4+Pj4+Pj4+IGdyYWR1YWxseSB0cmFuc2l0 aW9uaW5nIGl0cyBleGlzdGluZyBkYXRhYmFzZSB0byBoYXZlIFNIQS0yNTYgYXMNCj4+Pj4+Pj4+ IHRoZSBwYXNzd29yZCBoYXNoIGFsZ29yaXRobSAoYXMgdXNlcnMgY2hhbmdlIHBhc3N3b3Jkcyk/ ICBUaGlzDQo+Pj4+Pj4+PiBtaWdodCByZXN1bHQgaW4gYSBjYXNlIHdoZXJlIHNvbWUgdXNlcnMg aGF2ZSBNRDUtaGFzaGVkDQo+Pj4+Pj4+PiBwYXNzd29yZHMgaW4gdGhlIGRhdGFiYXNlLCBhbmQg c29tZSBoYXZlIFNIQS0yNTYg4oCUIGJ1dCB0aGUNCj4+Pj4+Pj4+IHNlcnZlciBkb2VzbuKAmXQg eWV0IGtub3cgd2hlbiByZXNwb25kaW5nIHRvIHRoZSBpbml0aWFsIHJlcXVlc3QNCj4+Pj4+Pj4+ IHdoaWNoIHVzZXIgaXMgbWFraW5nIHRoZSByZXF1ZXN0LCBhbmQgdGh1cyB3aGljaCBwYXNzd29y ZA0KPj4+Pj4+Pj4gYWxnb3JpdGhtcyBhcmUgYWN0dWFsbHkgc3VwcG9ydGVkIGZvciB0aGlzIHNw ZWNpZmljIHVzZXIuDQo+Pj4+Pj4+PiBTdXBwb3J0aW5nIHRoaXMgd291bGQgcmVxdWlyZSBlaXRo ZXIgcHV0dGluZyBVU0VSTkFNRSBpbiB0aGUNCj4+Pj4+Pj4+IGluaXRpYWwgcmVxdWVzdCAod2hp Y2ggc2VlbXMgYmFkIGluIHRoZSBhYnNlbmNlIG9mIGEga25vd24NCj4+Pj4+Pj4+IHJlYWxtKSwg b3IgZWxzZSBhbGxvd2luZyBhIHNlcnZlciB0byByZXNwb25kIHRvIGEgZm9sbG93dXANCj4+Pj4+ Pj4+IHJlcXVlc3Qgd2l0aCBhbm90aGVyIDQwMSBVbmF1dGhvcml6ZWQgcmVzcG9uc2UsIHdpdGgg YSBzaG9ydGVyDQo+Pj4+Pj4+PiBQQVNTV09SRC1BTEdPUklUSE1TIGxpc3QgKHJlc3VsdGluZyBp biBsb25nLXRlcm0gYXV0aGVudGljYXRpb24NCj4+Pj4+Pj4+IHJlcXVpcmluZyB0aHJlZSB0cmFu c2FjdGlvbnMgZm9yIHN0dW5iaXMgY2xpZW50cyB3aG9zZSB1c2VycyB3aG8NCj4+Pj4+Pj4+IGFy ZSBzdGlsbCBvbiBNRDUpLiAgRGVzcGl0ZSB0aGUgdHJpcGxlIHRyYW5zYWN0aW9uLCBJ4oCZbSBp bmNsaW5lZA0KPj4+Pj4+Pj4gdG8gcmVjb21tZW5kIHRoZSBsYXR0ZXIuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gSW50ZXJlc3RpbmcgdXNlIGNhc2UgcmVnYXJkaW5nIHRoZSBtYW5hZ2VtZW50IG9mIGFuIGh5 YnJpZA0KPj4+Pj4+IGRhdGFiYXNlIGNvbnRhaW5pbmcgbWl4ZWQgTUQ1L1NIQTI1NiB1c2Vycywg YnV0IGlzIGl0IHdvcnRoIGFkZGluZw0KPj4+Pj4+IHRoYXQgY29tcGxleGl0eSB0byB0aGUgcHJv dG9jb2w/ICBXZSdyZSB3aWxsaW5nIHRvIGxpc3RlbiB0bw0KPj4+Pj4+IG9waW5pb24gZnJvbSB0 aGUgd29ya2luZyBncm91cCwgZXNwZWNpYWxseSBwZW9wbGUgd2l0aCBsYXJnZQ0KPj4gZGVwbG95 bWVudHMuDQo+Pj4+IA0KPj4+PiBUaGlzIGlzIGF0IHRoZSBlbmQgb2YgYSBsb25nIGFuZCBlZGl0 b3JpYWwgZS1tYWlsLCBzbyBpdOKAmXMgcHJvYmFibHkNCj4+Pj4gd29ydGggY2FsbGluZyB0aGlz IG91dCBpbiBhIHN0YW5kYWxvbmUgbWVzc2FnZS4NCj4+IA0KPj4gRGlzY3VzcyEgOkQNCj4+IA0K Pj4gU2ltb24NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IHRyYW0gbWFpbGluZyBsaXN0DQo+PiB0cmFtQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0K From nobody Fri Jan 29 19:15:36 2016 Return-Path: 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 C3F991B2F6E for ; Fri, 29 Jan 2016 19:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jlcPu5_T9gi2 for ; Fri, 29 Jan 2016 19:15:31 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88C31B2F6C for ; Fri, 29 Jan 2016 19:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5218; q=dns/txt; s=iport; t=1454123731; x=1455333331; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wxvqKyteXb0UDJmbiO8esTzPX4SnDZLwr83kviWiVq8=; b=FLLKqJ1TaatXfVj6T2EMXv62wY5zCcZNftF70CmGMJF39AWGUvS86dr6 VA45XrAC4nl/q0avAxiqPQoLh7D8a+v4tPDxymEIOdVioCZaBHvzP8BK/ iaEY6C/Nzs1kQ73JoPGd5vBgir7R6DXy0N/4Pj21DoIq7MeYLumJMRxaH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAgCKKqxW/49dJa1egzpSbQaIUrE2A?= =?us-ascii?q?Q2BYxgKhW0CHIEROBQBAQEBAQEBgQqEQQEBAQQBAQEgEToLDAQCAQgRBAEBAQI?= =?us-ascii?q?CFA8DAgICJQsUAQgIAgQOBQiIEw6xTI5jAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR7hRSEN4E2AYJjLjiCMoE6BZZuAY1DjneOPQEeAQFCggEBARiBUWqIAXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,367,1449532800"; d="scan'208";a="68564854" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2016 03:15:21 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0U3FLBd032667 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Jan 2016 03:15:21 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Jan 2016 21:15:20 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Fri, 29 Jan 2016 21:15:20 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Jonathan Lennox Thread-Topic: [tram] Transition to new password algorithm Thread-Index: AQHRWgeqs/jZE7OlqUG+jWE16jb23Z8RyGjQgAE3RQCAAGUK0A== Date: Sat, 30 Jan 2016 03:15:20 +0000 Message-ID: <131bfafe727f4db4971b37e05d0aa827@XCH-RCD-017.cisco.com> References: <56A83C06.2000800@acm.org> <56AA66F4.4070409@acm.org> <56AA7539.5040909@jive.com> <702124c26bf84821a3974ba1db551e7f@XCH-RCD-017.cisco.com> <8DA752D4-233F-49E8-ABF3-62AE973F6182@vidyo.com> In-Reply-To: <8DA752D4-233F-49E8-ABF3-62AE973F6182@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.51.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Marc Petit-Huguenin Subject: Re: [tram] Transition to new password algorithm 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 03:15:33 -0000 R290IGl0LCBUaGFua3MuDQoNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogSm9uYXRoYW4gTGVubm94IFttYWlsdG86am9uYXRoYW5AdmlkeW8uY29tXQ0KPiBT ZW50OiBGcmlkYXksIEphbnVhcnkgMjksIDIwMTYgODo0MyBQTQ0KPiBUbzogVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KQ0KPiBDYzogU2ltb24gUGVycmVhdWx0OyBNYXJjIFBldGl0LUh1Z3Vl bmluOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gVHJhbnNpdGlvbiB0byBu ZXcgcGFzc3dvcmQgYWxnb3JpdGhtDQo+IA0KPiANCj4gPiBPbiBKYW4gMjgsIDIwMTYsIGF0IDk6 NTIgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPHRpcmVkZHlAY2lzY28uY29t PiB3cm90ZToNCj4gPg0KPiA+ICAgbyAgSWYgdGhlIE5PTkNFIGF0dHJpYnV0ZSBzdGFydHMgd2l0 aCB0aGUgdmFsdWUgIm9iTWF0Sm9zMiIgYnV0IHRoZQ0KPiA+ICAgICAgcmVxdWVzdCBjb250YWlu cyBuZWl0aGVyIFBBU1NXT1JELUFMR09SSVRITVMgbm9yIFBBU1NXT1JELQ0KPiA+ICAgICAgQUxH T1JJVEhNLCB0aGVuIHRoZSByZXF1ZXN0IGlzIHByb2Nlc3NlZCBhcyB0aG91Z2ggUEFTU1dPUkQt DQo+ID4gICAgICBBTEdPUklUSE0gd2VyZSBNRDUgKE5vdGUgdGhhdCBpZiB0aGUgb3JpZ2luYWwg UEFTU1dPUkQtDQo+IEFMR09SSVRITVMNCj4gPiAgICAgIGF0dHJpYnV0ZSBkaWQgbm90IGNvbnRh aW4gTUQ1LCB0aGlzIHdpbGwgcmVzdWx0IGluIGEgNDAwIEJhZA0KPiA+ICAgICAgUmVxdWVzdCBp biBhIGxhdGVyIHN0ZXAgYmVsb3cpLg0KPiA+DQo+ID4gVGhlIGFib3ZlIHJ1bGUgY291bGQgcmVz dWx0IGluIGRvd25ncmFkZSBhdHRhY2suIElmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMNCj4gYm90aCBw YXNzd29yZCBhbGdvcml0aG1zIGFuZCBNSU0gYXR0YWNrZXIgcmVtb3ZlcyBQQVNTV09SRC0NCj4g QUxHT1JJVEhNUyBhdHRyaWJ1dGUgZnJvbSB0aGUgcmVzcG9uc2UsIGZvcmNpbmcgdGhlIGNsaWVu dCB0byBwaWNrIE1ENS4NCj4gSG93IGRvZXMgdGhlIHNlcnZlciBkZXRlY3Qgc3VjaCBhbiBhdHRh Y2sgPw0KPiANCj4gSXQgZG9lc27igJl0LCB0aGUgY2xpZW50IGRvZXMg4oCUIGlmIHRoZSBjbGll bnQgc2VlcyBhIG5vbmNlIGJlZ2lubmluZyB3aXRoDQo+IG9iTWF0Sm9zMiBidXQgbm8gUEFTU1dP UkQtQUxHT1JJVEhNUyBhdHRyaWJ1dGUgaW4gdGhlIHJlc3BvbnNlLCBpdA0KPiBNVVNUIGlnbm9y ZSB0aGUgcmVzcG9uc2UuDQo+IA0KPiAoSWYgdGhlIGNsaWVudCBjaG9vc2VzIG5vdCB0byBmb2xs b3cgdGhpcywgaXTigJlzIGVzc2VudGlhbGx5IGJlaGF2aW5nIGFzIGFuIFJGQw0KPiA1Mzg5IGNs aWVudCwgd2hpY2ggYXMgbG9uZyBhcyB5b3XigJlyZSBzdXBwb3J0aW5nIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkgaXMNCj4gdW5hdm9pZGFibGUgYmVoYXZpb3IuICBCdXQgYSB0aGlyZC1wYXJ0eSBj YW7igJl0IGZvcmNlIGEgZG93bmdyYWRlLikNCj4gDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4N Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdHJhbSBbbWFpbHRv OnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNpbW9uDQo+ID4+IFBlcnJlYXVs dA0KPiA+PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMjksIDIwMTYgMTozOCBBTQ0KPiA+PiBUbzog TWFyYyBQZXRpdC1IdWd1ZW5pbjsgSm9uYXRoYW4gTGVubm94DQo+ID4+IENjOiB0cmFtQGlldGYu b3JnDQo+ID4+IFN1YmplY3Q6IFt0cmFtXSBUcmFuc2l0aW9uIHRvIG5ldyBwYXNzd29yZCBhbGdv cml0aG0NCj4gPj4NCj4gPj4gU3RhcnRpbmcgYSBuZXcgdGhyZWFkLCBhcyByZXF1ZXN0ZWQuLi4N Cj4gPj4NCj4gPj4gTGUgMjAxNi0wMS0yOCAxNDowNywgTWFyYyBQZXRpdC1IdWd1ZW5pbiBhIMOp Y3JpdCA6DQo+ID4+Pj4+IEEgZ2VuZXJhbCBxdWVzdGlvbiBhYm91dCB0aGUgUEFTU1dPUkQtQUxH T1JJVEhNIHRyYW5zaXRpb24NCj4gPj4+Pj4+Pj4gcHJvY2VzczogZG8gd2Ugd2FudCB0byBzdXBw b3J0IHRoZSB1c2UgY2FzZSB3aGVyZSBhIHNlcnZlciBpcw0KPiA+Pj4+Pj4+PiBncmFkdWFsbHkg dHJhbnNpdGlvbmluZyBpdHMgZXhpc3RpbmcgZGF0YWJhc2UgdG8gaGF2ZSBTSEEtMjU2DQo+ID4+ Pj4+Pj4+IGFzIHRoZSBwYXNzd29yZCBoYXNoIGFsZ29yaXRobSAoYXMgdXNlcnMgY2hhbmdlIHBh c3N3b3Jkcyk/DQo+ID4+Pj4+Pj4+IFRoaXMgbWlnaHQgcmVzdWx0IGluIGEgY2FzZSB3aGVyZSBz b21lIHVzZXJzIGhhdmUgTUQ1LWhhc2hlZA0KPiA+Pj4+Pj4+PiBwYXNzd29yZHMgaW4gdGhlIGRh dGFiYXNlLCBhbmQgc29tZSBoYXZlIFNIQS0yNTYg4oCUIGJ1dCB0aGUNCj4gPj4+Pj4+Pj4gc2Vy dmVyIGRvZXNu4oCZdCB5ZXQga25vdyB3aGVuIHJlc3BvbmRpbmcgdG8gdGhlIGluaXRpYWwgcmVx dWVzdA0KPiA+Pj4+Pj4+PiB3aGljaCB1c2VyIGlzIG1ha2luZyB0aGUgcmVxdWVzdCwgYW5kIHRo dXMgd2hpY2ggcGFzc3dvcmQNCj4gPj4+Pj4+Pj4gYWxnb3JpdGhtcyBhcmUgYWN0dWFsbHkgc3Vw cG9ydGVkIGZvciB0aGlzIHNwZWNpZmljIHVzZXIuDQo+ID4+Pj4+Pj4+IFN1cHBvcnRpbmcgdGhp cyB3b3VsZCByZXF1aXJlIGVpdGhlciBwdXR0aW5nIFVTRVJOQU1FIGluIHRoZQ0KPiA+Pj4+Pj4+ PiBpbml0aWFsIHJlcXVlc3QgKHdoaWNoIHNlZW1zIGJhZCBpbiB0aGUgYWJzZW5jZSBvZiBhIGtu b3duDQo+ID4+Pj4+Pj4+IHJlYWxtKSwgb3IgZWxzZSBhbGxvd2luZyBhIHNlcnZlciB0byByZXNw b25kIHRvIGEgZm9sbG93dXANCj4gPj4+Pj4+Pj4gcmVxdWVzdCB3aXRoIGFub3RoZXIgNDAxIFVu YXV0aG9yaXplZCByZXNwb25zZSwgd2l0aCBhIHNob3J0ZXINCj4gPj4+Pj4+Pj4gUEFTU1dPUkQt QUxHT1JJVEhNUyBsaXN0IChyZXN1bHRpbmcgaW4gbG9uZy10ZXJtIGF1dGhlbnRpY2F0aW9uDQo+ ID4+Pj4+Pj4+IHJlcXVpcmluZyB0aHJlZSB0cmFuc2FjdGlvbnMgZm9yIHN0dW5iaXMgY2xpZW50 cyB3aG9zZSB1c2Vycw0KPiA+Pj4+Pj4+PiB3aG8gYXJlIHN0aWxsIG9uIE1ENSkuICBEZXNwaXRl IHRoZSB0cmlwbGUgdHJhbnNhY3Rpb24sIEnigJltDQo+ID4+Pj4+Pj4+IGluY2xpbmVkIHRvIHJl Y29tbWVuZCB0aGUgbGF0dGVyLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEludGVyZXN0aW5nIHVzZSBj YXNlIHJlZ2FyZGluZyB0aGUgbWFuYWdlbWVudCBvZiBhbiBoeWJyaWQNCj4gPj4+Pj4+IGRhdGFi YXNlIGNvbnRhaW5pbmcgbWl4ZWQgTUQ1L1NIQTI1NiB1c2VycywgYnV0IGlzIGl0IHdvcnRoDQo+ ID4+Pj4+PiBhZGRpbmcgdGhhdCBjb21wbGV4aXR5IHRvIHRoZSBwcm90b2NvbD8gIFdlJ3JlIHdp bGxpbmcgdG8gbGlzdGVuDQo+ID4+Pj4+PiB0byBvcGluaW9uIGZyb20gdGhlIHdvcmtpbmcgZ3Jv dXAsIGVzcGVjaWFsbHkgcGVvcGxlIHdpdGggbGFyZ2UNCj4gPj4gZGVwbG95bWVudHMuDQo+ID4+ Pj4NCj4gPj4+PiBUaGlzIGlzIGF0IHRoZSBlbmQgb2YgYSBsb25nIGFuZCBlZGl0b3JpYWwgZS1t YWlsLCBzbyBpdOKAmXMgcHJvYmFibHkNCj4gPj4+PiB3b3J0aCBjYWxsaW5nIHRoaXMgb3V0IGlu IGEgc3RhbmRhbG9uZSBtZXNzYWdlLg0KPiA+Pg0KPiA+PiBEaXNjdXNzISA6RA0KPiA+Pg0KPiA+ PiBTaW1vbg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+PiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+PiB0cmFtQGlldGYub3JnDQo+ ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= From nobody Fri Jan 29 23:38:26 2016 Return-Path: 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 A8AEF1A0103 for ; Fri, 29 Jan 2016 23:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 s62y7vwxy_M3 for ; Fri, 29 Jan 2016 23:38:21 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0961A00FE for ; Fri, 29 Jan 2016 23:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4931; q=dns/txt; s=iport; t=1454139501; x=1455349101; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Od9JtYBTLhROsJT6vKUiKIfkjIxhezn88jtFD2xPyoc=; b=JT7HZaJwo5Bt2HvsfmKUsRHOgEZhuiJFwg29qyCLn/xfXX7EdWytQPBX 4Y4vIzGPuomslvzKeSoWpFrVqvnPRz8+5FkBm4OvFivdbv1TLI5k00lRq kzMkHh5T7lc94A8NEkE9nGHqOkV7iObHaP5ZGu6eSSBLWlTYE8geR4EO+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQChZ6xW/4ENJK1dgzqBPwaIUrE2A?= =?us-ascii?q?Q2BY4YPAoEtOBQBAQEBAQEBgQqEQQEBAQMBDiwrGQcEAgEIEQQBAQEeCQcyFAk?= =?us-ascii?q?IAQEEARIIiAsIv3wBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhg+EN4N5Ew4GhEwFl?= =?us-ascii?q?m8BixWCLoF4jH+OPQEeAQFCg2xqh0QCHgcWfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,368,1449532800"; d="scan'208";a="71316434" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2016 07:38:20 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0U7cKeF009646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Jan 2016 07:38:20 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 30 Jan 2016 01:38:20 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Sat, 30 Jan 2016 01:38:19 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt Thread-Index: AdFZE5vdeHWfvKN5RDWTgAWASP6SygAbMU6AAAt7poAASnwGAAAPmgDg Date: Sat, 30 Jan 2016 07:38:19 +0000 Message-ID: <6910d5332d0f4b9baaeeb4bfe74f523f@XCH-RCD-017.cisco.com> References: <56A93DE9.4020909@akamai.com> <56AB7ED4.5010202@akamai.com> In-Reply-To: <56AB7ED4.5010202@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.51.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 07:38:23 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Friday, January 29, 2016 8:32 PM > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt >=20 > On 01/28/2016 06:05 AM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >> Sent: Thursday, January 28, 2016 3:30 AM > >> To: Tirumaleswar Reddy (tireddy); tram@ietf.org > >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt > >> >=20 > >>>> s3.2.2 > >>>> A common use case for mobility will likely be what some have > >>>> described > >> as > >>>> the "walk out the door" problem. Two interfaces are functional (e.g. > >>>> both wifi and lte) and you want to seamlessly switch from one to > >>>> the > >> other. > >>>> You probably want to be able to use both interfaces at the same > >>>> time > >> while > >>>> you're figuring out whether/when to switch from one to the other > >>>> (make before break). > >>> > >>> I don't see a problem. Applications can pick both interfaces, create > >>> multiple > >> allocations, try connectivity checks on both interfaces, > >> draft-ietf-tram-stun- path-data and MPRTP can be used to pick > >> interface based on path characteristics. Keep the alternate > >> candidates pair alive for switch-over and use ICE continuous nominatio= n > for seamless move. > >> > >> So, basically, don't use turn-mobility for this purpose? I'm not > >> clear why you think the more complicated approach is preferable. Why > >> would it be bad for turn-mobility to support make-before-break? > > > > Extending TURN-mobility to support make-before-break makes the > proposal more complex, it may end-up just like MPTCP. > > Why not use ICE or MPRTP for make-before-break ? > > make-before-break means client can use multiple interfaces to send traf= fic > to the same allocation on the server, server must also load balance retur= n > traffic etc. > > >=20 > Without make-before-break capability, I think the mechanism might be > limited enough in utility that it won't be widely used. This is mostly be= cause I > think it requires the application to be able to sustain potentially signi= ficant > bursts of packet loss, which could be unacceptable for realtime > communication use cases, and maybe for live video streams as well. Siri on Apple uses MPTCP but does not send traffic on sub-flows on both int= erfaces. It only sends data on the primary interface and when the primary i= nterface is down, data is sent on the secondary sub-flow (backup interface)= . The time to detect signal is weak/unavailable for switch-over should not = be high otherwise user would notice communication break.=20 >=20 > If the app keeps both addresses active and sends data on the old address > while waiting for the refresh response, then as soon as the refresh reque= st is > received by the relay, all in-flight data is now effectively lost because= it will be > dropped by the relay. If the refresh response is lost, the client will co= ntinue > sending from the previous address; resumption of data flow will require > retransmit of the refresh request with an even longer period of message > drops. Yes, loss of refresh request/response will delay the switch-over. We should= discuss if refresh messages with MOBILITY-TICKET can be sent by the client= and server multiple times in quick succession to handle packet loss.=20 > If on the other hand the app optimistically starts sending messages from = the > new address as soon as it sends the refresh request, then it's susceptibl= e to > message drops if the refresh request is lost or otherwise fails validatio= n. If it > keeps the previous allocation active for receiving packets, at least it w= on't > drop a lot of inbound messages. >=20 > If the old address simply goes away when the new address comes up, there'= s > no way to avoid this anyway. However, when it's possible to have both > addresses active during the transition, make-before-break support would > allow seamless transition from one to the other. >=20 > I'm not suggesting we need something as complicated as MPRTP; just that > meeting the minimal requirements for seamless transition from one address > to another could make the mechanism a lot more useful. Works for me. One possible approach could be TURN server will continue to p= rocess traffic from the old 5-tuple ) i.e. receive and return traffic on th= e old 5-tuple) until it sees traffic (either channelData message or a Send = indication) on the new 5-tuple. In Make-before-make scenario, TURN client c= ontinues to send traffic on the old 5-tuple to the server until it sees Ref= resh response with MOBILITY-TICKET.=20 -Tiru >=20 > --Brandon From nobody Sun Jan 31 16:06:34 2016 Return-Path: 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 BFE571A6F42 for ; Sun, 31 Jan 2016 16:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 eg4iROIYjHvw for ; Sun, 31 Jan 2016 16:06:32 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 1CBD41A6F41 for ; Sun, 31 Jan 2016 16:06:32 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id z14so23532529igp.1 for ; Sun, 31 Jan 2016 16:06:32 -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=q19AT7sAvCha5IPlbA1jQg4G/Cs3J07X/wF0oNYtnMk=; b=Ug+DHsU5Vte1JxZH8LD3FZN3VZec3yYUx0MkAWAw1Qjl0hc53wzhsoHFcZhdtvCKDc 9QKzDt0DuouB+sa4wFcwQvIuEIOhW08O/9tpTqSBFnWLGRsF9zHXzgDPm2whRQUuS42y /DU1o7mObstGsxutn8mZSIdPfV5iKpDRERAq4fH5K+2yLNAbjwY6DYhX8zUW91UoEUEj IcVUVHHclsZq203N9k2GP/BmydsnxIUWF0DD2QjYLfBNx7LRktWcWl6PRnP3hABe+2Jg 771/IZizE/QHhj1ZdfRTQffK0THak9aAiw+sQMxygnXKqqrtu+qDffBSkCJxkyBC5PEX Z0+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q19AT7sAvCha5IPlbA1jQg4G/Cs3J07X/wF0oNYtnMk=; b=ITsxMkZTlXhW/mCz7fcmOOOn3dHX2yqlg9I4q8VorVQhCozPwiMhirp0tsgFWYEI92 KflAkJ+feIn8Kv5v55O5J0NgDv2tc05KYhK2J04YqAxGlN3vMyTu1HbJ9Jv/5JSssvUP fnZzInJtZhbT2RBqbbr+hTaVk9rnduQvkpuq3jXzxi+nhI3IRhp7+kkd8Y5hTf052fGT f37ez8w3Kc1meltI9jAnE8T66SEzQf0xXlEIE8xJAJ/vG855a8KgLcwudDU9XJ9pNtzV kBBNpChfgo/e9R80ycCg7cdKzl0Oh8alpiuHYsJq/83Zr+Yk11RzVg6gpkC6qtk3PZJs 0g7Q== X-Gm-Message-State: AG10YOT8AHplJ4JImhii5uFJLVGV6ZXlFMUC34XVKLoJ2Ya9uQBEElrv4kW+8l45wh6V255C9A/6QO9ime1gMQ== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr8597206igt.94.1454285191522; Sun, 31 Jan 2016 16:06:31 -0800 (PST) Received: by 10.36.149.130 with HTTP; Sun, 31 Jan 2016 16:06:31 -0800 (PST) In-Reply-To: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> Date: Mon, 1 Feb 2016 11:06:31 +1100 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 00:06:33 -0000 On 29 January 2016 at 17:40, Justin Uberti wrote: > Not sure I follow. It's protected by a keyed HMAC, so even if the unique > data in the packet is low (4 bytes of random TID value, perhaps), it's > unclear how an off-path attacker could generate the right HMAC. I'm assuming here that the off-path attacker is in possession of the ufrag and pwd. The point here is to demonstrate that you are both on path and have that information. If the TID is only 4 octets, then the space you need to guess within is very small. Maybe 2^31 is enough that the flood of spoofed packets you send might not be successful, but it's low enough that it almost seems worth trying. From nobody Sun Jan 31 16:41:46 2016 Return-Path: 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 8C4551A7D82 for ; Sun, 31 Jan 2016 16:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 E9OPzoE4huki for ; Sun, 31 Jan 2016 16:41:43 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 707041A711A for ; Sun, 31 Jan 2016 16:41:43 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id e64so68845195vkg.0 for ; Sun, 31 Jan 2016 16:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2K/42IB16BHRhydCZO+rHR2FwiMNqAqrzvR15gQMgQc=; b=MaSJA3hQpvDd/oqX1PnLxd7YZA5q1Mnrvr9waSr+HVrIYSWCZKQnE+Z2W8nt0tpt3Q CzjbXEASFR3XTK1Fe8E5U+GAZ/8qa3MNaGIcQ2T5UhFXehXdAqH4oPaMi0JeL8hdHQHp h4+PQ+TReL7hPTCGbPdMRfWFGcfBvsRftEIF1fwYZyxOTMLb/LgqdCFH+Ju+ObBt7dGd MraZKFjtLXYcAOI/obgwNXJPoFGhLXweebHFmShvnCM6xp44klcW6MVSB7c/x1OzS5I3 AH2s8XOKqtdVWzVBJTG7aojeh8pwormm6+hZ0SACuCkSNl5KoT3R+pthJs3cwER8SwOZ n81A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2K/42IB16BHRhydCZO+rHR2FwiMNqAqrzvR15gQMgQc=; b=k4XQkuglUlukfeeZ1mDrfappGJc2kJTfHHBby7ldNrz7RASQPeIki/OjBBsZeKw/KN 9BTqTi9JpwNAOeYAAlrJUzOdFw/zPTuYmRfvZaXrxALzaNytSeTY8kxjSS5oXX0sIfWv oVerIMqi4hNMvG6zgsJEiVm+uEml08fjQtZRppegpKvmDKn0KsAnxdgj9CIKZSkSnDAH 9l94gYvoGR9T4IqPQweXb1iBZT+WmTViC6Kaxd8z8o2k3dq5h2OZ83JU0fk6pYUBPvuJ Y2G5NcoM4ZanuAubyidLwXwY1cLYRYoJrkyWQUbsxFxgpoRtPvRuN0lRZuagJrPmfX7X 3M+Q== X-Gm-Message-State: AG10YOSBWIprxZG87ziavx1m02cac6lg004Tco7mJh+n6NxhGA/FUm476J7lms52LpN0vvplkDA9ym/RsjeX3HCC X-Received: by 10.31.149.78 with SMTP id x75mr14078026vkd.103.1454287302245; Sun, 31 Jan 2016 16:41:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.198.132 with HTTP; Sun, 31 Jan 2016 16:41:22 -0800 (PST) In-Reply-To: References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> From: Justin Uberti Date: Sun, 31 Jan 2016 16:41:22 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114267480d956d052aaaa693 Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Brandon Williams , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 00:41:44 -0000 --001a114267480d956d052aaaa693 Content-Type: text/plain; charset=UTF-8 I now see what you have in mind. However, sending ~4B packets (requiring 4B HMAC calculations and 240GB of traffic) seems like a heavy cost for unclear gain. On Sun, Jan 31, 2016 at 4:06 PM, Martin Thomson wrote: > On 29 January 2016 at 17:40, Justin Uberti wrote: > > Not sure I follow. It's protected by a keyed HMAC, so even if the unique > > data in the packet is low (4 bytes of random TID value, perhaps), it's > > unclear how an off-path attacker could generate the right HMAC. > > I'm assuming here that the off-path attacker is in possession of the > ufrag and pwd. The point here is to demonstrate that you are both on > path and have that information. If the TID is only 4 octets, then the > space you need to guess within is very small. Maybe 2^31 is enough > that the flood of spoofed packets you send might not be successful, > but it's low enough that it almost seems worth trying. > --001a114267480d956d052aaaa693 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I now see what you have in mind.

However, sen= ding ~4B packets (requiring 4B HMAC calculations and 240GB of traffic) seem= s like a heavy cost for unclear gain.

On Sun, Jan 31, 2016 at 4:06 PM, Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 29 January 2016 at 17:40, Jus= tin Uberti <juberti@google.com= > wrote:
> Not sure I follow. It's protected by a keyed HMAC, so even if the = unique
> data in the packet is low (4 bytes of random TID value, perhaps), it&#= 39;s
> unclear how an off-path attacker could generate the right HMAC.

I'm assuming here that the off-path attacker is in possession of= the
ufrag and pwd.=C2=A0 The point here is to demonstrate that you are both on<= br> path and have that information.=C2=A0 If the TID is only 4 octets, then the=
space you need to guess within is very small.=C2=A0 Maybe 2^31 is enough that the flood of spoofed packets you send might not be successful,
but it's low enough that it almost seems worth trying.

--001a114267480d956d052aaaa693--