From nobody Mon Mar 3 01:22:36 2014 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 BDE971A0AF2; Mon, 3 Mar 2014 01:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] 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 fBHI8NKOotbY; Mon, 3 Mar 2014 01:22:31 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4581F1A0940; Mon, 3 Mar 2014 01:22:23 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403031022175094; Mon, 03 Mar 2014 10:22:17 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'IESG IESG'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Date: Mon, 3 Mar 2014 10:22:12 +0100 Message-ID: <000501cf36c2$0fac5020$2f04f060$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgACxezCAB08LAA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Q1kxEQ9HRlCgL8WVvsoiGRmezHA Cc: 'Magnus Westerlund' , 'Ted Hardie' , tram@ietf.org, 'Simon Perreault' , 'Gonzalo Camarillo' , 'Spencer Dawkins' , rtcweb@ietf.org Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 03 Mar 2014 09:22:34 -0000 Hi Cullen, Memory may be an illusion, still I cannot understand how there can be an ever growing archive in the IETF /Karl Allt v=E4l Hi Cullen, Not to cause more lost in the threads (I am also) I am addressing both = your emails in one, and copy separately to the other guys in the first email. = Further Inline --> >From http://www.ietf.org/mail-archive/web/tram/current/msg00275.html=20 Let me also point out draft-deng-tram-isp-turn-00=20 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me *=93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94* = is a direct quote from one of those. So, in answer to Simon Perreault [simon.perreault at viagenie.ca]=92s = question in another thread the 13th: a) Is this a real problem that is worth fixing? I think we can be confident that the answer is *YES*. Only these three ISP/NSP referred to, may represent 50%(?) of the universe=92s IP = accesses! And the other will follow these most forward looking carriers.=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 01:49 Till: Karl Stahl Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; = David Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning Schulzrinne =C4mne: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > Karl,=20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to > be the point of debate, = and what your view is on what we should do. I think that would help make progress.=20 > Thank you,=20 > Cullen I just did something like that in: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html=20 Hoping this thread subject amplifies what this SHOULD be about. (An how = it will lead to the summary, after all diversion.) Actually, the outcome of "Interfacing to QoS" will be=20 I challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem = IX78 that implements such CLEAR INTERFACE and the actual QoS methods, for = both the Congestion, Default gateway, Surf Pipe=20 Manipulating the RTP extension header etc etc on 6 USD CPU and also = include the ADSL part where that quality handling is based on heavy 57 bytes chopping up at this exact=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 02:06 Till: Karl Stahl; IESG IESG Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo = Camarillo; rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins =C4mne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers. > =20 Reading the charter, the above is *not* at all a clear objective of the = WG (note I am not the chair of this WG or the responsible AD).=20 That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter.=20 My advice to the responsible AD is recharter this WG before IETF 90 or = close it. I would be glad to help write a charter that is not an infinite = blank cheque.=20 From nobody Mon Mar 3 05:25:39 2014 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 D80271A0103; Mon, 3 Mar 2014 05:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] 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 HoaAw75X0hs7; Mon, 3 Mar 2014 05:25:32 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A70581A00FB; Mon, 3 Mar 2014 05:25:30 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403031425262808; Mon, 03 Mar 2014 14:25:26 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'IESG IESG'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Date: Mon, 3 Mar 2014 14:25:22 +0100 Message-ID: <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgACxezCAB08LAIAAQ40g Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FieEVcT_kxkC4NNwnxkPzCidrTU Cc: 'Magnus Westerlund' , 'Ted Hardie' , rtcweb@ietf.org, tram@ietf.org, 'Simon Perreault' Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 03 Mar 2014 13:25:36 -0000 Cullen, Illution I am checking the IETF archive for links - Memory you know... I feel I also have an email from Harald to answer You will not see the below /Kalle Allt v=E4l -----Ursprungligt meddelande----- Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 3 mars 2014 10:22 Till: 'Cullen Jennings (fluffy)'; 'IESG IESG' Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo Camarillo'; 'rtcweb@ietf.org'; 'tram@ietf.org'; 'Spencer Dawkins' =C4mne: SV: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Hi Cullen, Memory may be an illusion, still I cannot understand how there can be an ever growing archive in the IETF /Karl Allt v=E4l Hi Cullen, Not to cause more lost in the threads (I am also) I am addressing both = your emails in one, and copy separately to the other guys in the first email. = Further Inline --> >From http://www.ietf.org/mail-archive/web/tram/current/msg00275.html Let me also point out draft-deng-tram-isp-turn-00 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me *=93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94* = is a direct quote from one of those. So, in answer to Simon Perreault [simon.perreault at viagenie.ca]=92s = question in another thread the 13th: a) Is this a real problem that is worth fixing? I think we can be confident that the answer is *YES*. Only these three ISP/NSP referred to, may represent 50%(?) of the universe=92s IP = accesses! And the other will follow these most forward looking carriers.=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] Skickat: den 26 februari 2014 01:49 Till: Karl Stahl Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; = David Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning Schulzrinne =C4mne: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > Karl,=20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to > be the point of debate, = and what your view is on what we should do. I think that would help make progress.=20 > Thank you,=20 > Cullen I just did something like that in: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html=20 Hoping this thread subject amplifies what this SHOULD be about. (An how = it will lead to the summary, after all diversion.) Actually, the outcome of "Interfacing to QoS" will be=20 I challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem = IX78 that implements such CLEAR INTERFACE and the actual QoS methods, for = both the Congestion, Default gateway, Surf Pipe=20 Manipulating the RTP extension header etc etc on 6 USD CPU and also = include the ADSL part where that quality handling is based on heavy 57 bytes chopping up at this exact=20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 02:06 Till: Karl Stahl; IESG IESG Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo = Camarillo; rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins =C4mne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers. > =20 Reading the charter, the above is *not* at all a clear objective of the = WG (note I am not the chair of this WG or the responsible AD).=20 That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter.=20 My advice to the responsible AD is recharter this WG before IETF 90 or = close it. I would be glad to help write a charter that is not an infinite = blank cheque.=20 From nobody Mon Mar 3 05:32:26 2014 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 47EB01A013F; Mon, 3 Mar 2014 05:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 lAUkKuoY9II8; Mon, 3 Mar 2014 05:32:17 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5766C1A0139; Mon, 3 Mar 2014 05:32:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-8b-5314845b648b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C7.87.10875.B5484135; Mon, 3 Mar 2014 14:32:11 +0100 (CET) Received: from [131.160.126.237] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Mon, 3 Mar 2014 14:32:10 +0100 Message-ID: <5314845A.2060100@ericsson.com> Date: Mon, 3 Mar 2014 13:32:10 +0000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl , "'Cullen Jennings (fluffy)'" , 'IESG IESG' References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se> In-Reply-To: <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW50i0iwwfdTphYdk9ksZvyZyGzx rmctm8Xaf+3sFt1L/7NYNM61s/iw9gKbA7vHlN8bWT12zrrL7rFkyU8mj09b57N4rPtgHsAa xWWTkpqTWZZapG+XwJXx5vg0loK1+hWfVjxmaWC8rNrFyMkhIWAi0bHzNhOELSZx4d56ti5G Lg4hgUOMEo8m9DJCOGsYJRomLmcDqeIV0JbYuXEuUAcHB4uAisSk5mqQMJuAhcSWW/dZQGxR gSiJn1cWsEOUC0qcnPkELC4iUC7x78oBVhCbWWALo8S2z0EgtjDI/K5zyhC7nrFI9O7eCNbA KeAgsfjmMnaQXRIC4hI9jUEQvXoSU662MELY8hLNW2czg9hCQKctf9bCMoFRaBaS1bOQtMxC 0rKAkXkVI3tuYmZOernhJkZg0B/c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwJh381PMqz3L1++LunGj8vXedYyTjzmtOij8ceYqg0V89ie/tPrEXpj7 Q7nliqG8fo936pozR6SWa/Oc+nb03NolAtPKCsXmyHg9T30R4/uUQV4sTtKyN+/G5crwVb/z mddU1fX1s9Vf/TXJ/uxKt9u95zIXbX10tlTNIILblO2FgmfQIbP1pZpKLMUZiYZazEXFiQAm 5f4ASAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kuUqus1qHatgy5hojmvy_fBeH5s Cc: 'Magnus Westerlund' , 'Ted Hardie' , rtcweb@ietf.org, tram@ietf.org, 'Simon Perreault' Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 03 Mar 2014 13:32:20 -0000 Karl, speaking as RAI AD and TRAM WG chair: note that our policy is to avoid cross-posting to several mailing lists. The reason is that doing so may make it more difficult for people who are subscribed to several lists to follow the discussions. Also, messages with too many requirements are moderated and need to be manually approved by the admins of each list. Therefore, from now on, please choose only *one* mailing list; preferably one where the discussions you intend to have are within its scope. Thanks, Gonzalo On 03/03/2014 1:25 PM, Karl Stahl wrote: > Cullen, > > Illution > I am checking the IETF archive for links - Memory you know... > I feel I also have an email from Harald to answer > > > > > You will not see the below > /Kalle > Allt väl > -----Ursprungligt meddelande----- > Från: Karl Stahl [mailto:karl.stahl@intertex.se] > Skickat: den 3 mars 2014 10:22 > Till: 'Cullen Jennings (fluffy)'; 'IESG IESG' > Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo > Camarillo'; 'rtcweb@ietf.org'; 'tram@ietf.org'; 'Spencer Dawkins' > Ämne: SV: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter > Clarification regardig Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs > > Hi Cullen, > > Memory may be an illusion, still I cannot understand how there can be an > ever growing archive in the IETF > > /Karl > > Allt väl > Hi Cullen, > > Not to cause more lost in the threads (I am also) I am addressing both your > emails in one, and copy separately to the other guys in the first email. > > Further Inline --> > >>From http://www.ietf.org/mail-archive/web/tram/current/msg00275.html > Let me also point out draft-deng-tram-isp-turn-00 > http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from China > Mobile that appeared on this mailing list yesterday. It points out the need > and willingness from the ISP/NSP side to do something about QoS for WebRTC > traffic, that they expect to be large and have to bring to their customers > with best QoE. In fact they and some more (a huge European carrier and the > cable operators in general - CableLabs) have expressed similar concerns to > me *"This is exactly something we want to work on as the current way will > cause severe problem on traffic when rtcweb applications get popular"* is a > direct quote from one of those. > > So, in answer to Simon Perreault [simon.perreault at viagenie.ca]'s question > in another thread the 13th: > a) Is this a real problem that is worth fixing? > I think we can be confident that the answer is *YES*. Only these three > ISP/NSP referred to, may represent 50%(?) of the universe's IP accesses! And > the other will follow these most forward looking carriers. > > > -----Ursprungligt meddelande----- > Från: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Skickat: den 26 februari 2014 01:49 > Till: Karl Stahl > Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; David > Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; > Henning Schulzrinne > Ämne: Re: [rtcweb] [tram] I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > >> Karl, > >> I am totally lost on this thread. Could you start a new tmead that > summarize what the issues is, what seems to > be the point of debate, and > what your view is on what we should do. I think that would help make > progress. > >> Thank you, > >> Cullen > > I just did something like that in: > [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 > IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff > http://www.ietf.org/mail-archive/web/tram/current/msg00331.html > Hoping this thread subject amplifies what this SHOULD be about. (An how it > will lead to the summary, after all diversion.) > > Actually, the outcome of "Interfacing to QoS" will be > > > I challenge anyone that this will be outcome, and will start "Interfacing to > QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem IX78 > that implements such CLEAR INTERFACE and the actual QoS methods, for both > the Congestion, Default gateway, Surf Pipe > Manipulating the RTP extension header etc etc on 6 USD CPU and also include > the ADSL part where that quality handling is based on heavy 57 bytes > chopping up > at this exact > > > > > -----Ursprungligt meddelande----- > Från: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Skickat: den 26 februari 2014 02:06 > Till: Karl Stahl; IESG IESG > Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo; > rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins > Ämne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter > Clarification regardig Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs > > > > On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > >> To the TRAM WG and RTCWEB WG and ADs: >> >> It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and > encouraged to route quality demanding WebRTC media into their IP pipes that > are capable of transporting real-time traffic without quality issues, using > TURN servers. >> > > Reading the charter, the above is *not* at all a clear objective of the WG > (note I am not the chair of this WG or the responsible AD). > > That said, I think you have pointed out this charter is abysmally vague - it > does not say what the WG is not going to do. If I decided to do BGP for > routing updates over TURN it would be within the scope of this charter. > > My advice to the responsible AD is recharter this WG before IETF 90 or close > it. I would be glad to help write a charter that is not an infinite blank > cheque. > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Wed Mar 5 09:33:39 2014 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 65B551A0258 for ; Wed, 5 Mar 2014 09:33:38 -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 D4bjLoX5R7cp for ; Wed, 5 Mar 2014 09:33:37 -0800 (PST) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4A1A024F for ; Wed, 5 Mar 2014 09:33:36 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id c13so627683eek.9 for ; Wed, 05 Mar 2014 09:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=O4OBysOBIKvPfDa9/Xraty5NC+B7qBM+sugkiP09eqo=; b=XsfFfAUqthUTpvfSlQTHfFx99tBemi9oO0rK7lVJUTkl8TeaLykuVbo+79bdJpLceL WDSL2lim/KEifyzpw5g7TnYl9rz0SeowTZGMH4iPB4zbeQq7mNySEphahd7ikxPhV4lA 6DD6Y0qkK/igwJ8yenvegZ3WS+GfQ59itZO3yv98zempuKnfw/JsEy/U/tgka0XNq1Ir BKMexPxtxJQgjMvdpv2gzzUsoM/IA2T+L2X9J4uCPxi52Yg9S6vGuY6R4Lk27T3IfibC oQbIg+8Anv0okhLReMBlQINM3D/nywwCN4Oe3gAqVW710hs6IaRP0ufKI+v6bHdluJMy //ew== X-Received: by 10.14.220.193 with SMTP id o41mr7282027eep.22.1394040812471; Wed, 05 Mar 2014 09:33:32 -0800 (PST) Received: from [10.0.2.15] (dhcp-b44b.meeting.ietf.org. [31.133.180.75]) by mx.google.com with ESMTPSA id u6sm11524223eep.11.2014.03.05.09.33.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 09:33:31 -0800 (PST) Message-ID: <53175FE6.9000504@gmail.com> Date: Wed, 05 Mar 2014 18:33:26 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/solOQfIK1YJRsRyRQrq-IHQq_90 Subject: [tram] (ALTO) Server Discover 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, 05 Mar 2014 17:33:38 -0000 Hi, I just mentioned on the mic in the TRAM session about the experiences out of the ALTO WG in terms of (ALTO) server discovery. The findings there may also apply to finding TRAM servers. Dan did mention draft-ietf-alto-server-discovery which covers either local (manual) configuration and DHCP based configuration that both use U-NAPTR resolution at the end to yield a URI for the server. Dan mentioned also anycast and there are two drafts out there that discuss this for PCP and ALTO: draft-kiesel-alto-ip-based-srv-disc draft-ietf-pcp-anycast However, as DHCP and local configuration based approaches have big draw backs and we did work on an approach to get around this. This is documented in draft-kist-alto-3pdisc. I happy to answer questions or to take comments about these draft or just approach the respective authors (where I do partially belong to). Thanks, Martin From nobody Wed Mar 5 09:44:14 2014 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 E06AF1A06A3 for ; Wed, 5 Mar 2014 09:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjbMhNr9TYxv for ; Wed, 5 Mar 2014 09:44:02 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A49F21A0692 for ; Wed, 5 Mar 2014 09:44:02 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id jt11so1359528pbb.8 for ; Wed, 05 Mar 2014 09:43:59 -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=cUMtXFw54TZ4ht6T57/tr73iGD3lv4x6HrkgMBSTXak=; b=tNuHxE64aTR8RMG/mxGl5p9NlvFreOeEteFoWTVY3ZNwgSaBSEnoPs9IwMV6WC2ZOx PKAOQY6G+gJQ14XnpX4rv6Sk2b9ZZZ1jr0wWDq3+FJwfkg7BIagkRF0AFl0LBdU/tcPL w8/vxPeK1j95dU+KWx2LL7XGjauQZQn5J0QTXixy/twj70KlJlVq8YpVmToCDv2mTWhY finJ5Rq/4R5oL9hjqtI2h5xrA7orX/BmnyhnbBLV95k7v1JaXuTm8cIpIrzPawbi7joH FejpIP6ozE+0/RLLDINVeIGlvmx6bNvdtDodUP5kowUFqrbEUjKeUZisZaVSTGtVaohG mPNA== MIME-Version: 1.0 X-Received: by 10.66.228.37 with SMTP id sf5mr8548034pac.19.1394041438242; Wed, 05 Mar 2014 09:43:58 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 5 Mar 2014 09:43:58 -0800 (PST) In-Reply-To: <530CBC2A.8020809@viagenie.ca> References: <530CBC2A.8020809@viagenie.ca> Date: Wed, 5 Mar 2014 09:43:58 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b111dd9ba8cd004f3df90dc Archived-At: http://mailarchive.ietf.org/arch/msg/tram/qKSL3W18kBxWEd7fMNSmmGMeW1w Cc: "tram@ietf.org" Subject: Re: [tram] Remote attendance with Meetecho 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, 05 Mar 2014 17:44:04 -0000 --047d7b111dd9ba8cd004f3df90dc Content-Type: text/plain; charset=ISO-8859-1 The remote experience was great, that was flawless ! Thanks Oleg On Tue, Feb 25, 2014 at 7:52 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > FYI, we have received confirmation that remote attendance will be > possible using Meetecho. > > To join the TRAM session: > http://www.meetecho.com/ietf89/tram > > Full agenda of Meetecho sessions: > http://ietf89.conf.meetecho.com/ > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b111dd9ba8cd004f3df90dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The remote experience was great, that was flawless !<= br>
Thanks
Oleg


On Tue, Feb 25, 2014 at 7:52 AM, Simon Perreaul= t <simon.perreault@viagenie.ca> wrote:
FYI, we have received confirmation that remo= te attendance will be
possible using Meetecho.

To join the TRAM session:
http://ww= w.meetecho.com/ietf89/tram

Full agenda of Meetecho sessions:
http://ietf8= 9.conf.meetecho.com/

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b111dd9ba8cd004f3df90dc-- From nobody Wed Mar 5 10:22:44 2014 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 61B2F1A01A0 for ; Wed, 5 Mar 2014 10:22:42 -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 B_eydMGEhRx7 for ; Wed, 5 Mar 2014 10:22:41 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2CF1A0157 for ; Wed, 5 Mar 2014 10:22:40 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id t61so1726254wes.3 for ; Wed, 05 Mar 2014 10:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=clJmwlnrt7YoxdMBxb9o/9DHvbJuOVt6DF2VYFo5Cao=; b=I/eBhrIXXEeodovU2prfhWpS5bOgv7mVYcTKJxGF5VNKvOb84ZBZAPEBzS3lVeRFDi YhxoRx21zW7LeVKXAJu/KdS8xq21ghY3kxwlO6FP3jCyTOa5EfWZdw2n7buQnmoYa+n8 H2GZiiKWA20Xeeixn8sCX6us9QYSSj8JdfMLx4UldLH5J4ypmXIfvfRisa5EyZ9DB9zo KuTpvXiBSBMwiNwOpTbvE3XzbhUdmB5zM4OxxaZ0UI/LqLV3Lk9Dw9GxtJgkQv6fZKF6 mi/EtuzcZZ9YinI2fYvfKDlDbp38spy3/J9lNd9hQgfF8h/OvzzC/sj9N8oFxfZ6VmPS FePA== MIME-Version: 1.0 X-Received: by 10.194.170.167 with SMTP id an7mr3160468wjc.39.1394043756989; Wed, 05 Mar 2014 10:22:36 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 5 Mar 2014 10:22:36 -0800 (PST) Date: Wed, 5 Mar 2014 18:22:36 +0000 Message-ID: From: Martin Thomson To: tram@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/royU8kLD0l30iyOIvDh6kqL3SRg Subject: [tram] ALPN for STUN 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, 05 Mar 2014 18:22:42 -0000 I'd like to ask that in doing a 5389bis we consider registering an ALPN token for this wonderful protocol. From nobody Wed Mar 5 16:46:08 2014 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 7634C1A004B for ; Wed, 5 Mar 2014 16:46:05 -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_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 s3faJr_0Y4v4 for ; Wed, 5 Mar 2014 16:46:03 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE271A0033 for ; Wed, 5 Mar 2014 16:46:03 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/5/2014 7:45:59 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-30/SG:2 3/5/2014 7:45:49 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.915276 p=-0.984722 Source White X-Signature-Violations: 0-0-0-3241-c X-Note-419: 15.6005 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/5/2014 7:45:57 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 103618458 for tram@ietf.org; Wed, 05 Mar 2014 19:45:59 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 5 Mar 2014 18:45:58 -0600 From: Jonathan Lennox To: "tram@ietf.org" Thread-Topic: TURN-over-DTLS draft: comments on today's session Thread-Index: AQHPONVw7HTv6Y+DsUqOnVx1H6kWmA== Date: Thu, 6 Mar 2014 00:45:58 +0000 Message-ID: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.3.252] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/cSmgzAtmW2CKN1Y6-FxyW4fdVN4 Subject: [tram] TURN-over-DTLS draft: comments on today's session 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, 06 Mar 2014 00:46:05 -0000 Hi =97 due to the conflict with PAYLOAD, I=92m watching TRAM now off Meetec= ho. So, a few comments on the TURN-over-DTLS discussion: On ICE pacing =97 I think the point of ICE pacing is not to reduce the amou= nt of network traffic, but rather to slow the rate at which NAT bindings ar= e created. Even though TURN-over-DTLS uses a fair number of packets, it=92= s still only a single NAT binding establishment. So I think there=92s no i= ssue, and ICE pacing doesn=92t need to change. The other certificate question I had =97 I also raised this previously on t= his list for TURN-over-TLS. If a client receives a 300 Try Alternate respo= nse to a STUN request, it only receives an IP and port for the ALTERNATE-SE= RVER to use. What identity, then, should the client expect the alternate s= erver to assert in its certificate? We could require that the alternate se= rver always presents the same identity as the original did, but that would = seem somewhat limiting to the types of load balancing architectures that co= uld be possible. Do we need to define a new ALTERNATE-SERVER-NAME attribut= e? = From nobody Thu Mar 6 01:27:11 2014 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 6B3C61A019A for ; Thu, 6 Mar 2014 01:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 l7rP0bHmaHaL for ; Thu, 6 Mar 2014 01:27:07 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F21A01C7 for ; Thu, 6 Mar 2014 01:27:00 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 68E7B28561 for ; Thu, 6 Mar 2014 09:26:56 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 5478E2855A for ; Thu, 6 Mar 2014 09:26:56 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 180E3FE0C3 for ; Thu, 6 Mar 2014 09:26:55 +0000 (GMT) Message-ID: <53183F5F.8070504@akamai.com> Date: Thu, 06 Mar 2014 09:26:55 +0000 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> In-Reply-To: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/MlKVvCSrK-IVTl60P4uMoO3uWFM Subject: Re: [tram] TURN-over-DTLS draft: comments on today's session 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, 06 Mar 2014 09:27:09 -0000 In SaaS-based TURN use cases, at least, ALTERNATE-SERVER-NAME would not be required. The name used for DTLS (or TLS) would typically be same for the two servers. I think that without an ALTERNATE-SERVER-NAME attribute, this characteristic of the relationship between the ALTERNATE-SERVER and the server that issues the error (i.e. they have the same name for authentication purposes) may be a requirement. Or is there another way that I'm not thinking of to get an alternate name for auth purposes? --Brandon On 03/06/2014 12:45 AM, Jonathan Lennox wrote: > Hi — due to the conflict with PAYLOAD, I’m watching TRAM now off Meetecho. So, a few comments on the TURN-over-DTLS discussion: > > On ICE pacing — I think the point of ICE pacing is not to reduce the amount of network traffic, but rather to slow the rate at which NAT bindings are created. Even though TURN-over-DTLS uses a fair number of packets, it’s still only a single NAT binding establishment. So I think there’s no issue, and ICE pacing doesn’t need to change. > > The other certificate question I had — I also raised this previously on this list for TURN-over-TLS. If a client receives a 300 Try Alternate response to a STUN request, it only receives an IP and port for the ALTERNATE-SERVER to use. What identity, then, should the client expect the alternate server to assert in its certificate? We could require that the alternate server always presents the same identity as the original did, but that would seem somewhat limiting to the types of load balancing architectures that could be possible. Do we need to define a new ALTERNATE-SERVER-NAME attribute? > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Mar 6 01:34:28 2014 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 3AEEE1A01AF for ; Thu, 6 Mar 2014 01:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 F7zDWxjYEwCS for ; Thu, 6 Mar 2014 01:34:25 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB7601A019D for ; Thu, 6 Mar 2014 01:34:25 -0800 (PST) Received: from porto.nomis80.org (h230.viagenie.ca [206.123.31.230]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 91C62403E7 for ; Thu, 6 Mar 2014 04:34:21 -0500 (EST) Message-ID: <5318411B.9040201@viagenie.ca> Date: Thu, 06 Mar 2014 09:34:19 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> In-Reply-To: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5Bv7maEsYo3IKXr2EdCfY67DCtw Subject: Re: [tram] TURN-over-DTLS draft: comments on today's session 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, 06 Mar 2014 09:34:27 -0000 Le 2014-03-06 00:45, Jonathan Lennox a écrit : > The other certificate question I had — I also raised this previously > on this list for TURN-over-TLS. If a client receives a 300 Try > Alternate response to a STUN request, it only receives an IP and port > for the ALTERNATE-SERVER to use. What identity, then, should the > client expect the alternate server to assert in its certificate? We > could require that the alternate server always presents the same > identity as the original did, but that would seem somewhat limiting > to the types of load balancing architectures that could be possible. What limitations specifically do you have in mind? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 6 02:01:58 2014 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 6F1611A01EF for ; Thu, 6 Mar 2014 02:01:51 -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=unavailable 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 8J36ZlreeoAK for ; Thu, 6 Mar 2014 02:01:47 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D5E091A01F3 for ; Thu, 6 Mar 2014 02:01:46 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so2705843wes.7 for ; Thu, 06 Mar 2014 02:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gBb0wcILWIyZf0juZZ6ux1W14BQJbX5zajJFO/E1lgk=; b=esA8lYdx9Aw/ibaleNLX/y/fi72ISoIoTpXGan8qzihI/1JwZDJAsqMBULFjNful/F JZcyFm4mPB9DXOyNfUfOJp/eoarNlZDMc1nXUxCSZX2DaNgPvX7anpW13/AEBis2omdZ wstQCtX1QOI3pAHoLahbJLN6dZdDgQ89U2+76yl6pbOjP3LZxSNDt9cQQJONB42GPxh1 8hhgvtbsQaBxdpxotHij2vaiGBHBat8ddSPF3e4jiRAy7p5DV/tEmOP2kg8jrVdAVG+2 RFQTx1ddrZPRSyH7uFtMGqCNtg33/AalfSbM17QF30KYtMCj7Cp+vTrL7jQGg041GJDW PwCQ== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr8516313wjc.56.1394100102546; Thu, 06 Mar 2014 02:01:42 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 02:01:42 -0800 (PST) Date: Thu, 6 Mar 2014 10:01:42 +0000 Message-ID: From: Martin Thomson To: tram@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nMbKR7JgIADFJCDKuTnGucQYH6A Subject: [tram] Demux of STUN in RFC 5764 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, 06 Mar 2014 10:01:51 -0000 FYI, I've submitted an erratum on RFC 5764 regarding STUN demux. Triggered by the discussion in MMUSIC (on bcc). http://www.rfc-editor.org/errata_search.php?rfc=5764&eid=3913 This shouldn't really affect anything in BUNDLE, unless you are intending to refer to specific values on the first byte. For any STUN work, pointing this out would probably be a good idea. From nobody Thu Mar 6 02:07:40 2014 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 BC1151A01AF for ; Thu, 6 Mar 2014 02:07:38 -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 YkgjnRy9tCpJ for ; Thu, 6 Mar 2014 02:07:37 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 11C4D1A01AE for ; Thu, 6 Mar 2014 02:07:33 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id t61so2817517wes.17 for ; Thu, 06 Mar 2014 02:07:29 -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=MrllJQPOWO0Ik+tvLaMUldeYGWC/5BH6D9f1HLMHvAw=; b=oS8wim5/aFdjfHxvX1iXgJg9yL7ZNyPZLtLXLcZUxarbCt0ofp1NPNG3ACsTNXFstc ANwawptnsH9orB+9HG3m0SiiTXzmmHVR1iAqMx0fdSI0DJXNqUmlk194YmqaMBVRvEAF TyJTO2FVF6Z/c0ZXiJU7uVylXBURZ0r8QmIV04K5Hsa8AjbOmCYx2OYDEA6p23wIk64I NFO3eJt2VvVCoBecgODiwWIItcVVti6dBIOBrBreWAYqDIrcVncP7TNL4TvFMECeonDv 6jBqvvww9igZg5YC8SFQYIZIOnCNi8G3wUQ7B1jedj35HV2EGD+ww14yGW+Fn0x9Pjdj G1qQ== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr8257855wjc.71.1394100449786; Thu, 06 Mar 2014 02:07:29 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 02:07:29 -0800 (PST) In-Reply-To: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> References: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> Date: Thu, 6 Mar 2014 10:07:29 +0000 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/cR9ADJiD4HAutaq4CXIcN27h2JQ Cc: "tram@ietf.org" Subject: Re: [tram] TURN-over-DTLS draft: comments on today's session 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, 06 Mar 2014 10:07:39 -0000 On 6 March 2014 00:45, Jonathan Lennox wrote: > If a client receives a 300 Try Alternate response to a STUN request, it only receives an IP and port for the ALTERNATE-SERVER to use. What identity, then, should the client expect the alternate server to assert in its certificate? In other protocols, when a redirection of this sort occurs, there is an expectation that the original name is used to authenticate the server. That is, if example.com provides a redirect to some new IP, the server at the new address needs to offer a certificate that is valid for example.com. From nobody Thu Mar 6 05:00:28 2014 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 854271A0289 for ; Thu, 6 Mar 2014 05:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 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.547, 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 WAXpvkeNLl7E for ; Thu, 6 Mar 2014 05:00:26 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2C82C1A02CF for ; Thu, 6 Mar 2014 05:00:23 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so2453173vcb.25 for ; Thu, 06 Mar 2014 05:00:19 -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=D7helWZmQnLkGf8XXNmf5S1H9vseHxaKiJOis8fBTwA=; b=GE+a59l3Won3igdB+yznOu+zEZasZs7CNZlSqxVMob7YHugrBK7xMnQrtmbQWxvaFY KYISoeU2WYKYZgVPt+SQHdj6Z+ZStkVw18R15NUeA/Ypu8fx6UYqBGFYvY99TYra0Djd BSDUusS7Swo/WpgDpQWB0bqjz9Ocb+2/yasieIyfE66sAYVC7fcLsKcIaZzdaTkbkLlW 3BdHDcZTNMfJAg0fvC5Au1nbroj+4txXhIgxD6XIxWDLK1LD2HeIl5sNL38Pb33VJARP drdzR5fTT/Kk2Gvphgl2V4lpgIl2Jm8Nttodu09lELCWvp3qAngpByfivYL69ZNf0JYH 5jAw== 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=D7helWZmQnLkGf8XXNmf5S1H9vseHxaKiJOis8fBTwA=; b=e2cst4bXbPO6sUSwMfWLyvTiDPuXlvBAsYRE+iu47aUtKjoo0S1HmBJu0251wEKssZ fFoF3CVwKYXjPMpv4BxUMPEkA6JMPgfMuOBcHLPUSX0WrfJcIg4oCOjyPXK5Vvbg4sT/ TS7hwmteJW0zHmFtymV5tIoyN/E0ZTgaATY9bpqT9DWVFNWnlGzbdEXmqjswDxTws/9d Yf95z2De1kTJKcTPeb94eJguEvdH3qPuuCOll1E4PRfGpjD10+nc6Az4LLaVlNpg/5DV kQMJNTvozffgQJ0TdTv2z68/Mx+RaqpUp0Ff/ZPo33ajo7lmC5mNxaQr3WkIWrXZCtYd vXaw== X-Gm-Message-State: ALoCoQkRlONoul080mK6GilYZhxMrXMYJJKhgoNZVi2zrD/aQQgvbFUXNmD8Lso6EfJ8RDusaOzeLb/BvyktmHnoMeYLwjoYIxPHqAlPYMbxdjOP/m6jGmkiCaRzTnu/RD9CpVLFT/xVMSYzz3HP5HbIvmGJ4XGjbQ/+xQARq5kZymoSRJbXMQTHDsulLS8gBAEshoil+Uw2 X-Received: by 10.220.103.141 with SMTP id k13mr1289369vco.25.1394110819033; Thu, 06 Mar 2014 05:00:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 04:59:58 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 6 Mar 2014 12:59:58 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b342d3025859604f3efb8d0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4Stor2U0JAvccCCynCQ_lHfzjAI Cc: "tram@ietf.org" Subject: Re: [tram] Demux of STUN in RFC 5764 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, 06 Mar 2014 13:00:27 -0000 --047d7b342d3025859604f3efb8d0 Content-Type: text/plain; charset=UTF-8 Sounds right to me. Hopefully this is only a theoretical problem, and we will never have more than 1280 separate message types in STUN. On Thu, Mar 6, 2014 at 10:01 AM, Martin Thomson wrote: > FYI, I've submitted an erratum on RFC 5764 regarding STUN demux. > Triggered by the discussion in MMUSIC (on bcc). > > http://www.rfc-editor.org/errata_search.php?rfc=5764&eid=3913 > > This shouldn't really affect anything in BUNDLE, unless you are > intending to refer to specific values on the first byte. > > For any STUN work, pointing this out would probably be a good idea. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b342d3025859604f3efb8d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds right to me. Hopefully this is only a theoretical p= roblem, and we will never have more than 1280 separate message types in STU= N.


On Th= u, Mar 6, 2014 at 10:01 AM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
FYI, I've submitted an erratum on RFC 57= 64 regarding STUN demux.
Triggered by the discussion in MMUSIC (on bcc).

http://www.rfc-editor.org/errata_search.php?rfc= =3D5764&eid=3D3913

This shouldn't really affect anything in BUNDLE, unless you are
intending to refer to specific values on the first byte.

For any STUN work, pointing this out would probably be a good idea.

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b342d3025859604f3efb8d0-- From nobody Thu Mar 6 05:08:32 2014 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 EE6251A027D for ; Thu, 6 Mar 2014 05:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 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.547, 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 kbclAfkQVjua for ; Thu, 6 Mar 2014 05:08:28 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0183F1A0046 for ; Thu, 6 Mar 2014 05:08:27 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oy12so2583715veb.32 for ; Thu, 06 Mar 2014 05:08:24 -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=mYr5EFKKqm8iYwd7Z4CWGRsdMmEM9PaehymsYrWnZ5s=; b=HFjy1j+k9ez9wsAlmUEz/WO4UBHlRdd/SQILvGxXXO7qXceOsvZDcTWSKXnD078UgO DRDn/eiH/U2uCi+ylVu9iYsRdt5Em1aZeUH8uEq0YRaE+oWpcYJwLl1PIX3R6uZkt2r6 kF+IEZzA0FS1ViwboWpR+AiJ1U5oiarDnGMfGpUN/gMWJGccZb1TwSFNirLEdv7Lk1X+ IAHuNJ3hncNupOFyhMy9u55DUD8hxsXL8eN2yjSaFBXd+DRqZnR7wFXkvbktiZiKmzRc kLW8f/GWASbK5th4AtsqC10bF+DmejhoQlvKFUd5I8MxOh/YrYZAvqa2LjvNrSHOdhp5 CPBw== 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=mYr5EFKKqm8iYwd7Z4CWGRsdMmEM9PaehymsYrWnZ5s=; b=ktezE/p+ey8owlUDOsyX2ySwOdMvC1YvDGEKnmOkbLDm6JzDELmBb1comx6tSQk/mS 3T0ukVgmk3LupG1ow6mN+fq7htNgxKZqlL6E8Cb6cdFS1+O2x2MgvXz+jth9xv/bZxj/ 3PuDRt8omGgiYKTeqEq0MqGjkeQmxOYWaFNKQhJ0XZPyVp65utAMYyLIMecW3zSWyl8s 6tBW4md7X9L01IIg3PzeaZHFSwraynu1b0TL+FQkEsoSuK0qMP6eaVlot/EvAyxjcHKp 2ieCgoMjwVlt8uQrIIr3Fn9e8jGy6vDOhj28lpNfpcX2O9tlGdD9TtCNyemeZdvvRt7L F5dg== X-Gm-Message-State: ALoCoQno7K7o2QfmMO5/OPuuTfWXUiU7InnW+fg2LRffcqPnzPcLs6WxsMjPRmB4odUr6N7CkukmIUkdw5Q7eqVHiQnySLLwbY/q8X0XQaAnFxMLMa5x4QUkZeMUDtDDXVGXgbCIWxjT0fvFthfp3Fk01gyvqD+XAtt/a1je4eKCyMdPcj/5cwtE9F3VnsEZF5YGkqF+5hih X-Received: by 10.220.161.8 with SMTP id p8mr5043639vcx.4.1394111303903; Thu, 06 Mar 2014 05:08:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 6 Mar 2014 05:08:03 -0800 (PST) In-Reply-To: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> References: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> From: Justin Uberti Date: Thu, 6 Mar 2014 13:08:03 +0000 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11c208100c13e704f3efd5ec Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BQirCQBv8gDzO2FQbktX6fh-Cy0 Cc: "tram@ietf.org" Subject: Re: [tram] TURN-over-DTLS draft: comments on today's session 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, 06 Mar 2014 13:08:30 -0000 --001a11c208100c13e704f3efd5ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 6, 2014 at 12:45 AM, Jonathan Lennox wrote= : > Hi =E2=80=94 due to the conflict with PAYLOAD, I=E2=80=99m watching TRAM = now off Meetecho. > So, a few comments on the TURN-over-DTLS discussion: > > On ICE pacing =E2=80=94 I think the point of ICE pacing is not to reduce = the > amount of network traffic, but rather to slow the rate at which NAT > bindings are created. Even though TURN-over-DTLS uses a fair number of > packets, it=E2=80=99s still only a single NAT binding establishment. So = I think > there=E2=80=99s no issue, and ICE pacing doesn=E2=80=99t need to change. > Agreed regarding pacing, thanks for pointing that out. The overall bandwidth increase will be negligible. > > The other certificate question I had =E2=80=94 I also raised this previou= sly on > this list for TURN-over-TLS. If a client receives a 300 Try Alternate > response to a STUN request, it only receives an IP and port for the > ALTERNATE-SERVER to use. What identity, then, should the client expect t= he > alternate server to assert in its certificate? We could require that the > alternate server always presents the same identity as the original did, b= ut > that would seem somewhat limiting to the types of load balancing > architectures that could be possible. Do we need to define a new > ALTERNATE-SERVER-NAME attribute? > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c208100c13e704f3efd5ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 6, 2014 at 12:45 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
Hi =E2=80=94 due to the conflict with PAYLOA= D, I=E2=80=99m watching TRAM now off Meetecho. =C2=A0So, a few comments on = the TURN-over-DTLS discussion:

On ICE pacing =E2=80=94 I think the point of ICE pacing is not to reduce th= e amount of network traffic, but rather to slow the rate at which NAT bindi= ngs are created. =C2=A0Even though TURN-over-DTLS uses a fair number of pac= kets, it=E2=80=99s still only a single NAT binding establishment. =C2=A0So = I think there=E2=80=99s no issue, and ICE pacing doesn=E2=80=99t need to ch= ange.

Agreed regarding pacing, thanks for pointi= ng that out. The overall bandwidth increase will be negligible.

The other certificate question I had =E2=80=94 I also raised this previousl= y on this list for TURN-over-TLS. =C2=A0If a client receives a 300 Try Alte= rnate response to a STUN request, it only receives an IP and port for the A= LTERNATE-SERVER to use. =C2=A0What identity, then, should the client expect= the alternate server to assert in its certificate? =C2=A0We could require = that the alternate server always presents the same identity as the original= did, but that would seem somewhat limiting to the types of load balancing = architectures that could be possible. =C2=A0Do we need to define a new ALTE= RNATE-SERVER-NAME attribute?
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a11c208100c13e704f3efd5ec-- From nobody Thu Mar 6 05:35:52 2014 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 78BB31A027D for ; Thu, 6 Mar 2014 05:35:49 -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_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 anoBF5Cq5UfA for ; Thu, 6 Mar 2014 05:35:43 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2762A1A01AE for ; Thu, 6 Mar 2014 05:35:43 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/6/2014 8:35:39 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-72/SG:2 3/6/2014 8:35:03 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.930768 p=-0.984226 Source White X-Signature-Violations: 0-0-0-4197-c X-Note-419: 15.6005 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/6/2014 8:35:35 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 103688021; Thu, 06 Mar 2014 08:35:38 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 6 Mar 2014 07:35:37 -0600 From: Jonathan Lennox To: Simon Perreault Thread-Topic: [tram] TURN-over-DTLS draft: comments on today's session Thread-Index: AQHPONVw7HTv6Y+DsUqOnVx1H6kWmJrUMWmAgABDa4A= Date: Thu, 6 Mar 2014 13:35:37 +0000 Message-ID: <0AE64C17-62AF-4ED6-BB15-A1BFD52D27BC@vidyo.com> References: <810C9102-F380-45F2-9EBC-5E20FA55CBAF@vidyo.com> <5318411B.9040201@viagenie.ca> In-Reply-To: <5318411B.9040201@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.226] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/j6NGm-ZNLe20wjeBlQ-cJGkc_NU Cc: "tram@ietf.org" Subject: Re: [tram] TURN-over-DTLS draft: comments on today's session 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, 06 Mar 2014 13:35:49 -0000 On Mar 6, 2014, at 9:34 AM, Simon Perreault w= rote: > Le 2014-03-06 00:45, Jonathan Lennox a =E9crit : >> The other certificate question I had =97 I also raised this previously >> on this list for TURN-over-TLS. If a client receives a 300 Try >> Alternate response to a STUN request, it only receives an IP and port >> for the ALTERNATE-SERVER to use. What identity, then, should the >> client expect the alternate server to assert in its certificate? We >> could require that the alternate server always presents the same >> identity as the original did, but that would seem somewhat limiting >> to the types of load balancing architectures that could be possible. >=20 > What limitations specifically do you have in mind? Consider the use case where turn.small-isp.example is providing TURN relay = services, but has contracted with turn.cloud-provider.example to handle sur= ge capacity if it=92s overloaded. cloud-provider.example charges them for = bandwidth, so they don=92t want to use them all the time. It could be nice if small-isp didn't have to provision a certificate with c= loud-provider, but could just redirect to them securely. With current TURN authentication mechanisms they=92ll still to share user d= atabases and the like, though with the various authentication updates even = that might not be necessary. (Obviously cloud-provider needs to be able to= identify users as being customers of small-isp, but ORIGIN should solve th= at.)= From nobody Thu Mar 6 05:56:02 2014 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 6E9791A017E for ; Thu, 6 Mar 2014 05:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 lO7Do-Ga_MBL for ; Thu, 6 Mar 2014 05:55:51 -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 69AEA1A02CD for ; Thu, 6 Mar 2014 05:55:48 -0800 (PST) Received: from [IPv6:2001:67c:370:160:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:160:c617:feff:feb6:86ed]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id AD02E201F0 for ; Thu, 6 Mar 2014 14:55:43 +0100 (CET) Message-ID: <53187E5D.3040406@acm.org> Date: Thu, 06 Mar 2014 05:55:41 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/viXu2YYbe42DIePtk24JWwVUdVI Subject: [tram] Open issue #4: domain/ip address handling in stun-dtls 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, 06 Mar 2014 13:55:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Following the discussion yesterday in the TRAM session about the domain/ip address handling for STUN over DTLS, we discussed what to do in the draft, and came with an alternate solution that could be better than the conclusion in the session (which was to forbid IP addresses). Because IP addresses are already accepted when TLS will be used with a STUN/TURN URI, that would require a document modifying 7064/65 to change that also for DTLS. As a reminder, here's the text in RFC 5389: "The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [RFC2818]. Those procedures assume the client is dereferencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 8.1 as the host portion of the URI that has been dereferenced. Alternatively, a client MAY be configured with a set of domains or IP addresses that are trusted; if a certificate is received that identifies one of those domains or IP addresses, the client considers the identity of the server to be verified." The problem here is when the IP address has been resolved before the URI was created, which will be the case most of the time in the WebRTC server. What we would suggest is to to add a new member in the RTCIceServer dictionary to carry the domain name (names?) to validate in case IP addresses are used in the STUN/TURN URI (pretty much like what was done for the username and password). Comments? - -- 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 v1 iQIcBAEBCAAGBQJTGH5aAAoJECnERZXWan7EZtIQALdFjEouq/7phAhDD0JgCN21 EQ/iodzUmcH+zTbrxQkx5oVNtI96Akz1zljl5UDyJcWGx2uZI8JMa0a2vojdZmBa 2LqJb64fF64dM7GcPE+/rLAR3tXlmIzr08ZS89gtF0k9aIPGZ/08q62Rj9UJK/vP CFy32yqJq/6YM25VyVkFy28fkb3uAmlcLg1lazCz81YYHHzy9bspVoZmvAtrgXaI 4bAgnzNDKAUV7oE7NO2PcEW2mX/oSyHP8NVLCLnqcbep3aEyRbmmpN2afgdIwtMb lzZZvdBPXc9l4xBE+OoDFopnCabCu+M+7PNjpjp0Y+f+LLxaf0EFjiTEi7Rwpa76 f03+p14a2mH4IiFEvux9JYK627sm+7QtXbJ/I+YyjSAPGsJUMguwe0nxD5K8VwbZ 7IRZ2Rw+kXokG7ULmp6ZdjgJ0YuR3IiBwTJ0eePzfTzRd84B/tWrM9jPk5zYgeVA JooOfbLHk7mijHmynhKj97zq5kRlvxvDwJKC9bFAfgMMAdFWQAUy7GU0lm6XnPVO fGbAVdpuNDkQaQJcIpNSIxs6jsqid15BZUPgcHd1LeABKNc/C7n48E/qW95haAVy 2v+DhW/Xcjt9LMQtNO+KKxX6xZnSrzJ/vFLi5/Vc7DFNnnLGBI6hr6vTuOPK+MDB /YrMurEbSduSe97t9mbB =IlWK -----END PGP SIGNATURE----- From nobody Thu Mar 6 06:04:48 2014 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 065491A01AE for ; Thu, 6 Mar 2014 06:04:47 -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 HEtIvyVDjPx7 for ; Thu, 6 Mar 2014 06:04:45 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 598CE1A0141 for ; Thu, 6 Mar 2014 06:04:45 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so3062304wes.7 for ; Thu, 06 Mar 2014 06:04:41 -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=jMn1bgUqNiGKYBLU8jgIVtIRslmQRKT9q8PWAE5ulwI=; b=HcmL8edsEFfEStnTI5kgbMaDUxXTULFKcnQCxXy6JStLGmRBf4pw7mpfpxbbMQ8ntJ fLxuUrcj2bpbSAV7lfBXBhAO2f3xha55K4qh2IE22Wl0pD6iN8UUY7zm5Pd94W8rVZde v2+4kAs9fOTFXG/kUVWnPIqM+q7DfeJnkT/JLxVQVClhVLRJkpKX4mHUyS80SBHE7OBr yLqChDZlf3bhQ08kEoqM9zNaZNHednXu9g8V2pj1y4O3M6oNgoTZcdp+DcXNWXugkQd1 F892BatQ8ZLS/YdHe//LKVfEiIVPB0eRbeWrds7zuHbdIH8/bFkeBDuwC1Hcov1mSajo 7I2A== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr10546353wjb.28.1394114681047; Thu, 06 Mar 2014 06:04:41 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 6 Mar 2014 06:04:40 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Mar 2014 14:04:40 +0000 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KD82f5iqWuJjyjp7ojqCpKdPyeg Cc: "tram@ietf.org" Subject: Re: [tram] Demux of STUN in RFC 5764 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, 06 Mar 2014 14:04:47 -0000 On 6 March 2014 12:59, Justin Uberti wrote: > Sounds right to me. Hopefully this is only a theoretical problem, and we > will never have more than 1280 separate message types in STUN. I think that at that point, we have other problems, yes. From nobody Thu Mar 13 00:31:13 2014 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 B461B1A03BD; Thu, 13 Mar 2014 00:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 BZdFj11124dT; Thu, 13 Mar 2014 00:31:00 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 510681A0155; Thu, 13 Mar 2014 00:30:57 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403130830476992; Thu, 13 Mar 2014 08:30:47 +0100 From: "Karl Stahl" To: "'Harald Alvestrand'" , "'Colin Perkins'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530D641F.6010504@alvestrand.no> In-Reply-To: <530D641F.6010504@alvestrand.no> Date: Thu, 13 Mar 2014 08:30:47 +0100 Message-ID: <021e01cf3e8e$2752ce10$75f86a30$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021F_01CF3E96.89173610" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8y8zez8ntJdzT0S+yXIDUU2yAcYwJrcLfg Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7Y8ktBYb2KZZ0Tc76xoyyem30Fk Cc: 'Magnus Westerlund' , rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] Payload Types assignments 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, 13 Mar 2014 07:31:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_021F_01CF3E96.89173610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Harald, =20 The answer to your question 26 of February: > Karl, what on Earth does TRAM milestone 3 have to do with whatever it = is you're proposing? TRAM milestone 3 is: Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG > There's no (zero, nada, none) mention of QoS within that charter. --- I didn=92t mention =93QoS=94 (*I want the QoS methods out!*), in my protest/request=20 http://www.ietf.org/mail-archive/web/tram/current/msg00304.html =93It = must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and = encouraged to route quality demanding WebRTC media into their IP pipes that are = capable of transporting real-time traffic without quality issues, using TURN servers.=20 =20 The subject from the TRAM mailing initiation spells out: *Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs* The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be = used for the above purpose. (The objective of the TRAM WG milestone 3 is *not only* to resolve restrictive enterprise NAT/firewall traversal problem using TURN = servers.)=94 =20 However, it is a way of "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff, which = I now have started under=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff =20 You were September 20 actually the first to answer my request for a DHCP provided turn server address (which I withdraw in favor of the anycast method, which is highly preferable): http://www.ietf.org/mail-archive/web/rtcweb/current/msg08920.html=20 =20 There I said: >There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting a =93WebRTC-ready=94 access and we can look forward to = telepresence for everyone. =20 I don=92t really see anyone objecting to those objectives, and I don=92t = think you do either. =20 The Anycast method were suggested October 22 (without further = discussions) http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html=20 and thereafter brought into TRAM WG list February 8=20 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html=20 =20 It took me some time to find the relevant emails from the discussions in September and October which ended up with my entry to the [tram]-list February 8, which is copied in full below, where I still say it was 95% ready (There are a few relevant points from Simon that I will address later). Thereafter, the QoS diversion and confusion started around = February 12th in what looks to me as effort to make it a =93Mission = Impossible=94. =20 I don=92t know how the TRAM WG was created, but I thought Milestrone 3 = was a result of Cullen=92s. See next email in response to Cullen=92s questions = and requests. =20 /Karl =20 Footnote: [1] I think both you (Harald) and Cullen, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned =93by = accident=94 that the TRAM WG was in progress at the November WebRTC conference=94 = and should handle the Auto Discovery of TURN-servers. =20 =20 Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 8 februari 2014 14:11 Till: 'tram@ietf.org'; 'tireddy@icisco.com'; 'Simon Perreault' =C4mne: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Karl from Ingate and Intertex just added himself to this list for = exactly the purpose of the subject of Milestone 3 above=20 =20 I welcome this initiative that I saw yesterday after being reminded by = China Mobile Research Institute who had seen the previous October discussion = on the WebRTC-list, parts of which are inserted below. Large carriers have = also expressed the importance of this milestone. -------------------- We are working on this draft, will publish it next week. -Tiru. =20 Great, please consider the input and suggestions below: =20 > -----Original Message----- > From: tram [ mailto:tram-bounces at ietf.org] On Behalf Of Simon Perreault > Sent: Friday, February 07, 2014 7:58 PM > To: tram at ietf.org > Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs >=20 =85 > Enterprises or ISPs wishing to provide > their own TURN server, in an attempt to reduce so-called "triangle routing", > need a new auto-discovery mechanism. --- There are more reasons heard for auto-discovery of a network = provided TURN server: =20 - NSPs (Network Service Providers) want to provide a path where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 - Note that to achieve some of the above points, TURN must be favored = over STUN to enforce that the TURN-path actually is used. (The Anycast method suggested below, =93automatically=94 does this.)=20 =20 -- In my view, a TURN server is the network providers=92 responsibility = to provide (just like the IP address, the default gateway, the DNS etc.) = =96 rather than the application provider=92s. Our current Internet accesses = may not cope with or be optimized for WebRTC usage =96 The NSP (or = Enterprise LAN administrator) should then be able to fix the access (here by offering a TURN server).=20 =20 > IMHO this is also a top-priority milestone. We need to quickly have a > mechanism that people can implement in WebRTC browsers now, while > there is still frenetic development happening.=20 --- Agree I don't foresee actual server- > side deployment happening quickly though. But as soon as clients are ready, > any ISP or enterprise can deploy and immediately benefit. - There is a definitive interest among forward SPs already, especially carriers owning the network. (They have learned that their networks (especially mobile) seem to = become data crowded no matter how much bandwidth they invest in.) =20 > I imagine that the solution will be fairly simple, spec- and implementation- > wise.=20 --- Agree that such solution should and could be found, but it is not obvious. Below you find 3 proposals (initiated by me or colleagues, = where I see flaws in the two first and now only suggest the third (the Anycast mechanism). From below: =20 - 1st: =85 withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that = you then also have to do something similar for: RA - Router Advertisement - = in IPv6, addition to the IPCP protocol for PPPoE and something for the = mobile OTT channel =96 wherever DHCP is NOT the method to give you an IP = address. (There were also concerns whether OSs actually supports forwards such extended DHCP information for the browser to use.) =20 - 2nd Reverse DNS-Based Service Discovery method: Justin Uberti pointed out: How does this get bootstrapped? That is, how = is the STUN server found? [Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery. (There were also hesitations of having to provision this special reverse = DNS for every access.) =20 - 3rd The Anycast method below =96 I see no problem It also has the advantage of encouraging (but not requiring) the = STUN/TURN to be built in the default gateway or NAT/firewall/access router itself, with a second interface to a public IP address on the WAN side. (Current volume deployed, low cost NSP triple play modems usually have a quality assured level 2 or level 3 WAN pipe for just voice (and another for = IPTV) =96 The anycast discovered TURN-server can be the access gateway to such = quality pipe for WebRTC media, in a single NSP provided CPE, scaling from residential and up.) =20 So I think we can finish this very quickly once we have a candidate > draft. We just need authors. So I would target not long after Toronto. >=20 > Simon =20 WEB BROWSER BEHAVIOUR: =20 Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be =93manually=94 configured. It is previously suggested, and to some extent discussed, that the WebRTC = browser should select the TURN server to use in the following priority order, = where ICE would assure that you get some connectivity if several candidates = are found and needs to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 or a WPAD method as mentioned below 3) TURN server address auto-discovered by the mechanism discussed here 4) TURN server address being supplied by the web application =20 With a good step 3), step 2) becomes obsolete since the network administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.=20 =20 Even if the need for auto-discovery of the TURN server comes from WebRTC usage, a general mechanism that also can be used by SIP clients (and = other protocols using TURN via ICE) is preferable. The anycast method has no application dependence, but e.g. WPAD has (a SIP Client typically does = not have the luxury of a JS engine=85) =20 /Karl =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Harald Alvestrand Skickat: den 26 februari 2014 04:49 Till: Colin Perkins; Karl Stahl Kopia: Magnus Westerlund; rtcweb@ietf.org; tram@ietf.org =C4mne: Re: [tram] [rtcweb] Payload Types assignments =20 Karl, what on Earth does TRAM milestone 3 have to do with whatever it is = you're proposing? TRAM milestone 3 is:=20 Sep 2014 - Send new proposed standard TURN server discovery mechanism = for enterprises and ISPs to IESG There's no (zero, nada, none) mention of QoS within that charter. ------=_NextPart_000_021F_01CF3E96.89173610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Harald,

 

T= he answer to your question 26 of February:
> Karl, what on Earth does TRAM milestone 3 have to do = with whatever it is you're proposing?
TRAM milestone 3 is: Sep 2014 - = Send new proposed standard TURN server discovery mechanism for = enterprises and ISPs to IESG
> There's no (zero, nada, none) = mention of QoS within that charter.

--= - I didn’t mention “QoS” (*I want the QoS methods = out!*), in my protest/request =

= http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = “It must be a clear objective of the TRAM WG that ISPs/NSPs = are allowed and encouraged to route quality demanding WebRTC media into = their IP pipes that are capable of transporting real-time traffic = without quality issues, using TURN servers.

 

The subject from the TRAM mailing initiation spells = out:

*Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs*

The TRAM WG must assure that TURN servers offered by ISPs/NSPs can = be used for the above purpose.

(The objective of the TRAM WG milestone 3 is *not only* to = resolve restrictive enterprise NAT/firewall traversal problem using TURN = servers.)”

 

Ho= wever, it is a way of "Interf= acing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to = lower level's QoS-stuff, wh= ich I now have started under <= /span>

= http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml<= /span>

The way to = "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to = interface to lower level's QoS-stuff

 

Yo= u were September 20 actually the first to answer my request for a DHCP = provided turn server address (which I withdraw in favor of the anycast = method, which is highly preferable):

http://www.ietf.org/mail-archive/web/rtcweb/current/msg08920.html =

 

Th= ere I said:

>There are several reasons for a = network service provider to supply a TURN

server as part of his offered = access:

- to keep media paths short, specifically = not sending media outside its own

network to some distant application = provided TURN server

- to support mobility, i.e. you may want = to move from a LAN with a

configured TURN server to accessing via = WiFi or 3G/4G OTT channels

- to offer a media path with better = quality (than best effort data traffic).

Getting a “WebRTC-ready” = access and we can look forward to telepresence = for

everyone.

 

I = don’t really see anyone objecting to those objectives, and I = don’t think you do either.

 

Th= e Anycast method were suggested October 22 (without further = discussions)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html =

an= d thereafter brought into TRAM WG list February 8 =

= http://www.ietf.org/mail-archive/web/tram/current/msg00132.html =

 

It= took me some time to find the relevant emails from the discussions in = September and October which ended up with my entry to the [tram]-list = February 8, which is copied in full below, where I still say it was 95% = ready (There are a few relevant points from Simon that I will address = later). Thereafter, the QoS diversion and confusion started around = February 12th in what looks to me as effort to make it a “Mission = Impossible”.

 

I = don’t know how the TRAM WG was created, but I thought Milestrone 3 = was a result of Cullen’s. See next email in response to = Cullen’s questions and requests.

 

/K= arl

 

Fo= otnote:

[1= ] I think both you (Harald) and Cullen, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned = “by accident” that the TRAM WG was in progress at the = November WebRTC conference” and should handle the Au= to Discovery of TURN-servers.

 

 

Fr=E5n: Karl Stahl = [mailto:karl.stahl@intertex.se]
Skickat: den 8 februari 2014 = 14:11
Till: 'tram@ietf.org'; 'tireddy@icisco.com'; 'Simon = Perreault'
=C4mne: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and ISPs

 

Ka= rl from Ingate and Intertex just added himself to this list for exactly = the purpose of the subject of Milestone 3 above

 

I = welcome this initiative that I saw yesterday after being reminded by = China Mobile Research Institute who had seen the previous October = discussion on the WebRTC-list, parts of which are inserted below. Large = carriers have also expressed the importance of this = milestone.

--= ------------------

We are working on this draft, will publish it next = week.

-Tiru.

 

Great, please = consider the input and suggestions below:

 

> -----Original Message-----

> From: = tram [mailto:tram-bounces at = ietf.org] On Behalf Of Simon Perreault

> Sent: = Friday, February 07, 2014 7:58 PM

> To: = tram at ietf.org

> Subject: [tram] Milestone 3: TURN server = auto-discovery mechanism for

> = enterprise and ISPs

>

…

> Enterprises or ISPs wishing to = provide

> their = own TURN server, in an attempt to reduce so-called "triangle = routing",

> need a new auto-discovery = mechanism.

--= - There are more reasons heard for auto-discovery of a network provided = TURN server:

 

- = NSPs (Network Service Providers) want to provide a path where the = bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

 

- = Note that to achieve some of the above points, TURN must be favored over = STUN to enforce that the TURN-path actually is used. (The Anycast method = suggested below, “automatically” does this.) =

 

--= In my view, a TURN server is the network providers’ = responsibility to provide (just like the IP address, the default = gateway, the DNS etc.) – rather than the application = provider’s. Our current Internet accesses may not cope with or be = optimized for WebRTC usage – The NSP (or Enterprise LAN = administrator) should then be able to fix the access (here by offering a = TURN server).

 

> IMHO = this is also a top-priority milestone. We need to quickly have = a

> = mechanism that people can implement in WebRTC browsers now, = while

> there = is still frenetic development happening.

--= - Agree

I don't foresee actual server-

> side = deployment happening quickly though. But as soon as clients are = ready,

> any = ISP or enterprise can deploy and immediately = benefit.

- = There is a definitive interest among forward SPs already, especially = carriers owning the network.

(T= hey have learned that their networks (especially mobile) seem to become = data crowded no matter how much bandwidth they invest in.)

 

> I imagine that the solution will be fairly simple, = spec- and implementation-

> wise. =

--= - Agree that such solution should and could be found, but it is not = obvious. Below you find 3 proposals (initiated by me or colleagues, = where I see flaws in the two first and now only suggest the third (the = Anycast mechanism). From below:

 

- = 1st: … withdraw my suggestion to use DHCP to find a = network provider offered TURN server in favor of the DNS-Based Service = Discovery method (inserted last below). The major problem with the DHCP = usage was that you then also have to do something similar for: RA - = Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE = and something for the mobile OTT channel – wherever DHCP is NOT = the method to give you an IP address. (There were also concerns whether = OSs actually supports forwards such extended DHCP information for the = browser to use.)

 

- = 2nd Reverse DNS-Based Service Discovery = method:

Ju= stin Uberti pointed out:  How does this = get bootstrapped? That is, how is the STUN server found?

[K= arl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery.

(T= here were also hesitations of having to provision this special reverse = DNS for every access.)

 

- = 3rd The Anycast method below – I see no = problem

It= also has the advantage of encouraging (but not requiring) the STUN/TURN = to be built in the default gateway or NAT/firewall/access router itself, = with a second interface to a public IP address on the WAN side. (Current = volume deployed, low cost NSP triple play modems usually have a quality = assured level 2 or level 3 WAN pipe for just voice (and another for = IPTV) – The anycast discovered TURN-server can be the access = gateway to such quality pipe for WebRTC media, in a single NSP provided = CPE, scaling from residential and up.)

 

So I think = we can finish this very quickly once we have a = candidate

> draft. = We just need authors. So I would target not long after = Toronto.

> =

> = Simon

 

WE= B BROWSER BEHAVIOUR:

 

Ne= twork provided TURN servers will not appear over night, applications may = for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be “manually” = configured. It is previously suggested, and to some extent discussed, = that the WebRTC browser should select the TURN server to use in the = following priority order, where ICE would assure that you get some = connectivity if several candidates are found and needs to be = tested:

 

1)= TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2)= TURN server address configured by the network administrator via an = “admin policy template” or a WPAD method as mentioned = below

3)= TURN server address auto-discovered by the mechanism discussed = here

4)= TURN server address being supplied by the web = application

 

Wi= th a good step 3), step 2) becomes obsolete since the network = administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.

 

Ev= en if the need for auto-discovery of the TURN server comes from WebRTC = usage, a general mechanism that also can be used by SIP clients (and = other protocols using TURN via ICE) is preferable. The anycast method = has no application dependence, but e.g. WPAD has (a SIP Client typically = does not have the luxury of a JS engine…)

 

/K= arl

 

Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Harald = Alvestrand
Skickat: den 26 februari 2014 04:49
Till: = Colin Perkins; Karl Stahl
Kopia: Magnus Westerlund; = rtcweb@ietf.org; tram@ietf.org
=C4mne: Re: [tram] [rtcweb] = Payload Types assignments

 

Karl,

what on Earth does TRAM milestone 3 have = to do with whatever it is you're proposing?

TRAM milestone 3 is: =

Sep 2014 - Send new proposed standard TURN server discovery = mechanism for enterprises and ISPs to IESG

There's no (zero, = nada, none) mention of QoS within that = charter.

------=_NextPart_000_021F_01CF3E96.89173610-- From nobody Thu Mar 13 00:57:07 2014 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 6EEF01A094F; Thu, 13 Mar 2014 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 Rmibw6z-5Jh5; Thu, 13 Mar 2014 00:56:54 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF791A094E; Thu, 13 Mar 2014 00:56:53 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403130856442069; Thu, 13 Mar 2014 08:56:44 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'IESG IESG'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Mar 2014 08:56:44 +0100 Message-ID: <022301cf3e91$c7a31ed0$56e95c70$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0224_01CF3E9A.296786D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgACxezCAB08LAIAOOy+g Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2wNQMx6jAuUUCZTJQRACOKU14wI Cc: 'Magnus Westerlund' , 'Ted Hardie' , tram@ietf.org, 'Simon Perreault' , 'Gonzalo Camarillo' , 'Spencer Dawkins' , rtcweb@ietf.org Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs 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, 13 Mar 2014 07:56:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0224_01CF3E9A.296786D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cullen, =20 You may first want to read the previous email to Harald:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00349.html=20 =20 Regarding your request from February 26: > Karl,=20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to be the point of debate, and = what your view is on what we should do. I think that would help make = progress.=20 > Thank you, Cullen =20 I already February 26 started a new thread for the =93mission to bring = quality to real-time traffic over our best effort Internet=94 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1]=20 =20 And from your email February 25 below: > Reading the charter, the above is *not* at all a clear objective of = the WG (note I am not the chair of this WG or the responsible AD).=20 =20 >That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP = for routing updates over TURN it would be within the scope of this charter.=20 =20 >My advice to the responsible AD is recharter this WG before IETF 90 or close it. I would be glad to help write a charter that is not an = infinite blank cheque. =20 I actually thought it was you (Cullen) that at least initiated tram Milestone 3 with Subject: =93TURN server auto-discovery mechanism for enterprise and ISPs=94 [2] =20 After your request http://www.ietf.org/mail-archive/web/rtcweb/current/msg09007.html=20 [Karl, I, had said]=93> I've heard several carries expressing that they = want to provide their own TURN servers with their accesses. =20 [Cullen asked] Any chance you could put me in touch with some of them. = I'd love to get more information on what is needed so we can solve this.=93 =20 The =93 huge European carrier and the cable operators in general =96 = CableLabs=94 that I refer to in http://www.ietf.org/mail-archive/web/tram/current/msg00275.html were = the ones I put you in touch with, and then China Mobile reached out for = getting the auto-discovery mechanism in place: =93Let me also point out draft-deng-tram-isp-turn-00 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me *=93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94* = is a direct quote from one of those.=93 =20 Whoever you left this to, it somehow appeared as [tram] Milestone 3. [2] =20 The complete Anycast method for auto discovery of ISP=92s TURN servers = was suggested October 22 (without further discussions) http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html=20 and thereafter brought into [tram] Milestone 3 by me February 8=20 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html=20 =20 It took me some time to find the relevant emails from the discussions in September and October which ended up with my entry to the [tram]-list February 8, where I still say it was 95% ready (there are a few relevant points from Simon that I will address later). Thereafter, the QoS = diversion and confusion started around February 12th in what looks to me as an = effort to make it a =93Mission Impossible=94. =20 So referring to http://www.ietf.org/mail-archive/web/tram/current/msg00275.html, step A) = is for the TRAM WG to allow ISPs/NSPs to route quality demanding WebRTC = media into their IP pipes that are capable of transporting real-time traffic, using TURN servers. Step B), how the WebRTC browser shall use the auto discovered TURN server, which I suggested in=20 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html=20 =20 WEB BROWSER BEHAVIOUR: =20 Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be =93manually=94 configured. It is previously suggested, and to some extent discussed, that the WebRTC = browser should select the TURN server to use in the following priority order, = where ICE would assure that you get some connectivity if several candidates = are found and needs to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 or a WPAD method as mentioned below 3) TURN server address auto-discovered by the mechanism discussed here 4) TURN server address being supplied by the web application =20 may be for the RTCWEB WG rather than TRAM WG to handle. Further I would guess step D) is an AVTEXT WG thing =96 What do you think? =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] I think both you (Cullen) and Harald, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned =93by = accident=94 that the TRAM WG was in progress at the November WebRTC conference and should handle the Auto Discovery of TURN-servers. =20 PS: To avoid being stopped by the =93to many recipients=94 spam filter, = the Guys (including Mary) from=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html=20 and the ones mentioned in the email are copied separately. =20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [ mailto:fluffy@cisco.com] Skickat: den 26 februari 2014 01:49 Till: Karl Stahl Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; Bernard Aboba; David Singer; = Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning = Schulzrinne =C4mne: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 > Karl,=20 =20 > I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to be the point of debate, and = what your view is on what we should do. I think that would help make = progress.=20 =20 > Thank you,=20 =20 > Cullen =20 I just did something like that in: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff=20 http://www.ietf.org/mail-archive/web/tram/current/msg00331.html=20 Hoping this thread subject amplifies what this SHOULD be about. (An how = it will lead to the summary, after all diversion.) =20 Actually, the outcome of "Interfacing to QoS" will be=20 =20 =20 I challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem = IX78 that implements such CLEAR INTERFACE and the actual QoS methods, for = both the Congestion, Default gateway, Surf Pipe=20 Manipulating the RTP extension header etc etc on 6 USD CPU and also = include the ADSL part where that quality handling is based on heavy 57 bytes chopping up at this exact=20 =20 =20 =20 =20 -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [ mailto:fluffy@cisco.com]=20 Skickat: den 26 februari 2014 02:06 Till: Karl Stahl; IESG IESG Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo = Camarillo; rtcweb@ietf.org; tram@ietf.org; Spencer Dawkins =C4mne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 =20 On Feb 25, 2014, at 7:02 AM, Karl Stahl < = karl.stahl@intertex.se> wrote: =20 > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers. > =20 =20 Reading the charter, the above is *not* at all a clear objective of the = WG (note I am not the chair of this WG or the responsible AD).=20 =20 That said, I think you have pointed out this charter is abysmally vague = - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter.=20 =20 My advice to the responsible AD is recharter this WG before IETF 90 or = close it. I would be glad to help write a charter that is not an infinite = blank cheque.=20 =20 =20 =20 =20 =20 ------=_NextPart_000_0224_01CF3E9A.296786D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Cullen,

 

Yo= u may first want to read the previous email to Harald: =

= http://www.ietf.org/mail-archive/web/tram/current/msg00349.html =

 <= /o:p>

R= egarding your request from February 26:
> Karl,

> I am totally lost on this = thread. Could you start a new tmead that summarize what the issues is, = what seems to be the point of debate, and what your view is on what we = should do. I think that would help make progress. =

> Thank you, = Cullen

<= o:p> 

I = already February 26 started a new thread for the = &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;= = http://www.ietf.org/mail-archive/web/tram/current/ms= g00331.html=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] =

<= o:p> 

A= nd from your email February 25 below:

> Reading the charter, the above is *not* at all a clear = objective of the WG (note I am not the chair of this WG or the = responsible AD).

 

>That said, I think you have pointed out this charter is = abysmally vague - it does not say what the WG is not going to do. If I = decided to do BGP for routing updates over TURN it would be within the = scope of this charter.

 

>My advice to the responsible = AD is recharter this WG before IETF 90 or close it. I would be glad to = help write a charter that is not an infinite blank = cheque.

 

I = actually thought it was you (Cullen) that at least initiated tram = Milestone 3 with Subject: “TURN server = auto-discovery mechanism for enterprise and ISPs&#= 8221; [2]

 

Af= ter your request http://www.ietf.org/mail-archive/web/rtcweb/current/msg09007.html = 

[Karl, I, had =
said]“> I've heard several carries =
expressing that they want to provide their own TURN servers with their =
accesses.

 

[C= ullen asked] Any chance = you could put me in touch with some of them. I'd love to get more = information on what is needed so we can solve this.&#= 8220;

 

Th= e “ huge European carrier and the cable = operators in general – CableLabs” that I refer to in = = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html = =A0were the ones I put you in touch with, and then China Mobile reached = out for getting the auto-discovery mechanism in place: = “Let me also point out = draft-deng-tram-isp-turn-00 =A0= http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out = the need and willingness from the ISP/NSP side to do something about QoS = for WebRTC traffic, that they expect to be large and have to bring to = their customers with best QoE. In fact they and some more (a huge = European carrier and the cable operators in general - CableLabs) have = expressed similar concerns to me *“This is exactly something we = want to work on as the current way will cause severe problem on traffic = when rtcweb applications get popular”* is a direct quote from one = of those.&#= 8220;

 

Wh= oever you left this to, it somehow appeared as [tram] Milestone 3. = [2]

 

Th= e complete Anycast method for auto discovery of ISP’s TURN servers = was suggested October 22 (without further = discussions)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html =

an= d thereafter brought into [tram] Milestone 3 by me February 8 =

= http://www.ietf.org/mail-archive/web/tram/current/msg00132.html =

 

It= took me some time to find the relevant emails from the discussions in = September and October which ended up with my entry to the [tram]-list = February 8, where I still say it was 95% ready (there are a few relevant = points from Simon that I will address later). Thereafter, the QoS = diversion and confusion started around February 12th in what looks to me = as an effort to make it a “Mission = Impossible”.

 

So= referring to = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html, = step A) is for the TRAM WG =A0to allow = ISPs/NSPs to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic, using TURN servers. = Step B), how the WebRTC browser shall use the auto discovered TURN = server, which I suggested in

= http://www.ietf.org/mail-archive/web/tram/current/msg00132.html =

 

WEB BROWSER BEHAVIOUR:<= /span>

 

Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions = where the TURN server address is preferred to be “manually” = configured. It is previously suggested, and to some extent discussed, = that the WebRTC browser should select the TURN server to use in the = following priority order, where ICE would assure that you get some = connectivity if several candidates are found and needs to be = tested:

 

1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an = “admin policy template” or a WPAD method as mentioned = below

3) TURN server address auto-discovered by the mechanism discussed = here

4) TURN server address being supplied by the web = application

 

ma= y be for the RTCWEB WG rather than TRAM WG to handle. Further I would = guess step D) is an AVTEXT WG thing – What do you = think?

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] I think both you (Cullen) and Harald, are good, have the best = intentions and integrity, but no one of us have infinite memory capacity = (especially when the VP8/H.264 flooding came in between). I only learned = “by accident” that the TRAM WG was in progress at the = November WebRTC conference and should handle the Auto Discovery of = TURN-servers.

 

PS= : To avoid being stopped by the “to many recipients” spam = filter, the Guys (including Mary) from

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html =

an= d the ones mentioned in the email are copied = separately.

 

-----Ursprungligt meddelande-----

Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]

Skickat: den 26 = februari 2014 01:49

Till: Karl = Stahl

Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org;= Bernard Aboba; David Singer; Harald Tveit Alvestrand; Marc Robins; Eric = Burger; Mary Barnes; Henning Schulzrinne

=C4mne: Re: [rtcweb] [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

> = Karl,

 

> I am totally lost on this thread. Could you start a new tmead that summarize what the issues = is, what seems to be the point of debate, and what your view is on what = we should do. I think that would help make progress. =

 

> Thank you,

 

> = Cullen

 

I just did something like that in:

[tram] [rtcweb] The way to "Interfacing to = QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower = level's QoS-stuff

= http://www.ietf.org/mail-= archive/web/tram/current/msg00331.html

Hoping this thread subject amplifies what this = SHOULD be about. (An how it will lead to the summary, after all = diversion.)

 

Actually, the outcome of "Interfacing to = QoS" will be

 

 

I = challenge anyone that this will be outcome, and will start = "Interfacing to QoS" with what IP "Interfacing to = QoS" that we have the tiny ADSL modem IX78 that implements such = CLEAR INTERFACE and the actual QoS methods, for both the Congestion, = Default gateway, Surf Pipe

Manipulating the RTP extension header etc etc on 6 = USD CPU and also include the ADSL part where that quality handling is = based on heavy 57 bytes chopping up

=A0=A0 at this exact

 

 

 

 

-----Ursprungligt meddelande-----

Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]

Skickat: den 26 = februari 2014 02:06

Till: Karl = Stahl; IESG IESG

Kopia: Magnus = Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo; rtcweb@ietf.org; tram@ietf.org;= Spencer Dawkins

=C4mne: Re: = [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification = regardig Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

 

 

On Feb = 25, 2014, at 7:02 AM, Karl Stahl <karl.stahl@intertex.se> wrote:

 

> = To the TRAM WG and RTCWEB WG and ADs:

>=A0

> = It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP = pipes that are capable of transporting real-time traffic without quality = issues, using TURN servers.

>=A0

 

Reading the charter, the above is *not* at all a = clear objective of the WG (note I am not the chair of this WG or the = responsible AD).

 

That = said, I think you have pointed out this charter is abysmally vague - it = does not say what the WG is not going to do. If I decided to do BGP for = routing updates over TURN it would be within the scope of this charter. =

 

My advice to the responsible AD is recharter this = WG before IETF 90 or close it. I would be glad to help write a charter = that is not an infinite blank cheque.

 

 

 

 

 

------=_NextPart_000_0224_01CF3E9A.296786D0-- From nobody Thu Mar 13 01:27:12 2014 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 CF3911A096F; Thu, 13 Mar 2014 01:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 7-cp3xrKI_FX; Thu, 13 Mar 2014 01:26:59 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2E1A095A; Thu, 13 Mar 2014 01:26:57 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403130926480855; Thu, 13 Mar 2014 09:26:48 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , "'Colin Perkins'" , "'Magnus Westerlund'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Mar 2014 09:26:49 +0100 Message-ID: <022d01cf3e95$fafd57b0$f0f80710$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_022E_01CF3E9E.5CC1BFB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPMa7rPKSdbWG+c0KNNHF0bIvNNJrGUOCAgBSaP9A= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/O0C6ckVC6YN4RYk1tRBSjcHVXqs Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] RTP header extension for "Interfacing to QoS" WAS: I-D Action: draft-thomson-tram-turn-bandwidth-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, 13 Mar 2014 08:27:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_022E_01CF3E9E.5CC1BFB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_022F_01CF3E9E.5CC1BFB0" ------=_NextPart_001_022F_01CF3E9E.5CC1BFB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 =20 *SUMMARY* to be brought into the common "Interfacing to QoS"-thread (From there it will be clearer how to split =93Interfacing to QoS=94 = into [tram], [rtcweb] and [avtext]-threads.) =20 The steps A), B) to D) for achieving the mission: http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =20 a: Step D) using the RTP extension header RCF5285 (that works for all IP network types) can obsolete step C) (Using STUN-attributes which is an incomplete transfer of traffic info to the network level.) We need = traffic info (bandwidth and type) that is unchanged through various networks and = can be read and used by network elements (here in a TURN-server flow) and = for traffic in both directions. =20 b: Here it is only discussed for RTP (not for the data channel), but it could be good to also consider this for the webrtc data channel. I will discuss that in next email responding to Magnus=92 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html coming soon. =20 c: How to find and pick out the traffic information from the RTP = extension header when RCF 5285 is used for this purpose is trivial, especially = when =93in-band=94 in a known TURN-flow.=20 =20 There are further detail in-line below for P=E5l, Colin, Magnus and = other interested. =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] Here it is about recreation of the idea/intention of the RTP payload type (PT) header that is not available for the network level anymore, by instead having the application/browser filling the RTP header extension = with relevant traffic info that all IP network types can use. There will be = more detail in the response to Magnus=92 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html coming soon. =20 Fr=E5n: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Skickat: den 25 februari 2014 13:48 Till: Karl Stahl Kopia: tram@ietf.org; rtcweb@ietf.org; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 On 24 Feb 2014, at 23:22 pm, Karl Stahl < = karl.stahl@intertex.se> wrote: =20 Hi P=E5l, =20 You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =20 Sorry about that. I did not notice any clear items to answer or comment = on.=20 [Karl -regarding =93Interfacing to QoS=94] From what you answer below, I conclude: a: step D) (that works for all IP network types) can obsolete step C) = (using STUN-attributes which is an incomplete transfer of traffic info to the network level) (We need a quality marking that is unchanged and can be = read and used throughout various networks and for traffic in both = directions). b: here it is only discussed for RTP (not for the data channel, but I = will discuss that in next email responding to Magnus. c: you have hesitations how to find and pick out the traffic information from the RTP extension header when RCF5285 is used for this purpose, but that is trivial, especially when =93in-band=94 in a known TURN-flow. See = further below. =20 =20 (DISCUSS/MALICE) by allowing the application/browser to transfer = relevant real-time traffic information (types and bandwidth) into every RTP = package by using the already IETF standardized RTP extension header RCF 5285, = which could be used by any current or future Internet (including OTT) network where WebRTC real-time traffic may flow. It seems to have been = standardized already 2008 to allow such usage. whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already 2008 to = allow such usage. =20 [P=E5l] draft-martinsen-tram-discuss is intended to solve internal = application stream prioritisation pr flow, i.e. it is more important for me to get = the video stream across than my application stream at this moment in time. = Its intention is to describe the 5-topple the STUN message was sent on.=20 =20 Moving to a pr packet prioritisation is interesting as it can solve the bundle problem, and mark the relative importance of specific video = frames (I-Frames for example). Since its pr packet the network element might = not keep stream state so it might be easier that way. But the information = needs to be in a fixed offset for quick network element processing. And we = want to describe other streams than just RTP. That makes RTP header extensions unsuitable.=20 =20 QoS related step C) draft-martinsen-tram-discuss can then be taken out = of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. =20 [P=E5l] I was hoping to argue that the draft is only new signalling of = old concepts (DSCP and ECN). In the end it is the WG that decides if there = is enough interest.=20 =20 =20 I have repeated my suggestion to RTCWEB WG from the October discussions = on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC5285, where traffic information in RTP packets = simply would be filled by any browser under any OS. =20 Without step B), TRAM =93Enforcing the real-time traffic through the offered/discovered TURN servers=94, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used = (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT. =20 [P=E5l] If both clients supports draft-martinsen-tram-discuss you would = get an bi-directional end to end description of the flow that works through = NAT. The information in the STUN packet can be used to remark DSCP bits to whatever values that is of best use for the network the packet is = flowing though. [Karl] Again, this is only applicable for all-diffserve networks and you cannot even route the flow to a quality pipe, not even a duplicate pipe = that is not the default gateway surf pipe (which is a very common method used = for VoIP). =20 [P=E5l] I dont see how TURN gives that ability.=20 [Karl - ???] Haven=92t we many times agreed that you can add exactly the = same STUN-attributes to the TURN allocate request AND in addition to that, control where the flow goes? BUT THIS IS ALSO INSUFFICIENT.=20 I discarded such (similar) interface to QoS already October 22 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 =85 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =85 [P=E5l] Once the channel is bound you only have a channel number in = front of the UDP payload. And TURN is designed to carry alls sort of traffic. For this to work there must be some sort of only webRTC traffic is allowed through this TURN server. (And Ill bet bitorrent or others find a way to mimic webRTC to set up only a data channel..) [Karl] I owe Simon a response to misuse of prioritized channels =96 will = do later after first collecting these diversions. This has nothing to do = with STUN vs TURN! TURN just gives the addition of ALSO directing the flow. = In both cases it is insufficient to transfer traffic info in the STUN/TURN attributes. =20 That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. I know a few of you Cisco guys are among the ones that have been = fighting against the general =93it is all about bandwidth=94 and =93it will go = away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but = the pointers given in the current QoS discussion within TRAM: =20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. =20 (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no = extra cost, *by proprietary usage* of RFC5285 by browsers. =20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explainations about QoS methods and their implementation were = given a few days ago in: http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =20 (i), (ii) and (iii) will *seriously delay* usage of telepresence capable = and quality demanding WebRTC (bandwidth being around 30 times higher over = best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 Below you are giving pointers saying =93They are currently working on a problem-statement draft and a use-case draft, any input to those would = be very helpful.=94 Those are unnecessary, risking leading to (i), (ii) and = (iii) above. =20 [P=E5l] We find them quite useful. It allows us to engage with potential = users and see if there are real problems to solve. If the customer/users do = not see a problem there is little incentive for us to invest in creating a solution that nobody wants. That said, it is always the danger of = crating a to complicated solution that solves to many problems. =20 [Karl] This is QoS stuff. Let=92s stick to =93Interfacing to QoS=94 and = with a general interface, that the =93QoS device including the TURN server=94 = should be able to do whatever network QoS-method you arrive at. So are pointers such as: =93RMCAT where congestion avoidance for RTP is = being developed=94. TRAMs Milestone 3 is for the purpose of directing = real-time traffic where congestion control isn=92t already in place. Using RFC5285 available since 2008, to fill traffic information in RTP packets (step = D)) is probably a necessity for most future =93congestion control=94 = discussed. =20 [P=E5l] There are some good example of RTP header extension usage. For = example draft-avtext-berger-framemarking. But that information may very well be encrypted and unavailable to the network element. [Karl] You (P=E5l), Colin and Magnus seem to worry about trivial things = when using the RTP header extension, for transferring traffic information = from the application (here browser) to the network level. Don=92t worry! J = These are really trivial things : - If we select to use the RTP extension header RCF5285 for this purpose, = it should of course NOT use RFC6904 encryption, since it is meant for = network level reading/usage! - Finding the RTP header extension (especially when =93in-band=94 in a = known TURN-flow) is really trivial. =20 Linking each RTP-flow by its SSRC and sequence number, and picking = exactly the right traffic type and bandwidth parameters is no problem (I am not aware of any =93Zero CPU=94 DPI device that needs to be considered =96 = But if we can ease the job, we should.) This link shows much more advanced things are available in Cisco = devices:=20 http://www.cisco.com/en/US/products/ps6616/products_white_paper09186a0080= 110 040.shtml#wp39132=20 and the ADSL 2+ modem doing a lot of advanced QoS-stuff, described in=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html=20 is our Intertex/Ingate IX78, just powered by a 6 USD 264 MHz ARM ADSL = chip set CPU and we have implemented a check box TO REMOVE the RTP Header extension (for the ugly reason that the ITSP=92s billing system requires = G.711 VoIP packets of a certain length) =96 It does not take noticeable CPU = power to do this at 100 Mbps wire speed!=20 /Karl=20 .-. P=E5l-Erik This chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to: http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos focusing on DSCP-mapping without even mentioning RFC 5285 available = since 2008, to fill traffic information in RTP packets where it is a = necessity and will allow: (1) applications to directly convey QoS related real-time traffic info = to the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS methods = for the particular network* for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of using the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place, market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. l Please see further emails soon following this one, for details and = history. =20 /Karl =20 Fr=E5n: tram [ = mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen (palmarti) Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working = on a problem-statement draft and a use-case draft, any input to those would = be very helpful. ( = http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik ------=_NextPart_001_022F_01CF3E9E.5CC1BFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = = http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]=

 

 

*S= UMMARY* = to be brought into the common "Interfacing to = QoS"-thread

(F= rom there it will be clearer how to split “Interfacing to = QoS” into [tram], [rtcweb] and = [avtext]-threads.)

 

Th= e steps A), B) to D) for achieving the mission:

= http://www.ietf.org/mail-archive/web/tram/current/msg00273.html<= /o:p>

 

a:= Step D) using the RTP extension header RCF5285 (that works for all IP = network types) can obsolete step C) (Using STUN-attributes which is an = incomplete transfer of traffic info to the network level.) We need = traffic info (bandwidth and type) that is unchanged through various = networks and can be read and used by network elements (here in a = TURN-server flow) and for traffic in both = directions.

 

b:= Here it is only discussed for RTP (not for the data channel), but it = could be good to also consider this for the webrtc data channel. I will = discuss that in next email responding to Magnus’ http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html = coming soon.

 

c:= How to find and pick out the traffic information from the RTP extension = header when RCF 5285 is used for this purpose is trivial, especially = when “in-band” in a known TURN-flow.

 

Th= ere are further detail in-line below for P=E5l, Colin, Magnus and other = interested.

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] Here it = is about recreation of the idea/intention of the RTP payload type (PT) = header that is not available for the network level anymore, by instead = having the application/browser filling the RT= P header extension with relevant traffic info that all IP network types = can use. There will be more detail in the response to Magnus’ http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html = coming soon.

 

Fr=E5n: Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com]
Skickat: den = 25 februari 2014 13:48
Till: Karl Stahl
Kopia: = tram@ietf.org; rtcweb@ietf.org; Oleg Moskalenko; Alan Johnston; Yoakum, = John H (John)
=C4mne: Re: [tram] [rtcweb] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

On 24 Feb 2014, at 23:22 pm, Karl = Stahl <karl.stahl@intertex.se> = wrote:

 

Hi= P=E5l,

&n= bsp;

Yo= u did not comment nor answer, in response to any = of:

= http://www.ietf.org/mail-archive/web/tram/current/= msg00275.html

= http://www.ietf.org/mail-archive/web/tram/current/= msg00273.html

 

Sorry about that. I did not notice any clear items to = answer or comment on. 

[Karl = -regarding “Interfacing to QoS”] From what you answer below, = I conclude:

a: step D) (that works for all IP network types) = can obsolete step C) (using STUN-attributes which is an incomplete = transfer of traffic info to the network level) (We need a quality = marking that is unchanged and can be read and used throughout various = networks and for traffic in both directions).

b: here it = is only discussed for RTP (not for the data channel, but I will discuss = that in next email responding to Magnus.

c: you have = hesitations how to find and pick out the traffic information from the = RTP extension header when RCF5285 is used for this purpose, but that is = trivial, especially when “in-band” in a known TURN-flow. See = further below.

 

 

(D= ISCUSS/MALICE) by allowing the application/browser to transfer relevant = real-time traffic information (types and bandwidth) into every RTP = package by using the already IETF standardized RTP extension header RCF = 5285, which could be used by any current or future Internet (including = OTT) network where WebRTC real-time traffic may flow. It seems to have = been standardized already 2008 to allow such usage.



wh= ether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the = application/browser to transfer relevant real-time traffic information = (types and bandwidth) into every RTP package by using the already IETF = standardized RTP extension header RCF 5285, which could be used by any = current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already = 2008 to allow such usage.

&n= bsp;

[P=E5l] draft-martinsen-tram-discuss is intended to solve internal = application stream prioritisation pr flow, i.e. it is more important for = me to get the video stream across than my application stream at this = moment in time. Its intention is to describe the 5-topple the = STUN message was sent on. 

 

Moving to a pr packet prioritisation is interesting as = it can solve the bundle problem, and mark the relative importance of = specific video frames (I-Frames for example). Since its pr packet the = network element might not keep stream state so it might be easier that = way. But the information needs to be in a fixed offset for quick network = element processing. And we want to describe other streams than just RTP. = That makes RTP header extensions = unsuitable. 

 

Qo= S related step C) draft-martinsen-tram-discuss ca= n then be taken out of TRAM, and step D) (that was never intended to be = handled by TRAM anyway) will be handled = elsewhere.

 

[P=E5l] = I was hoping to argue that the draft is only = new signalling of old concepts (DSCP and ECN). In the end it is = the WG that decides if there is enough = interest. 

 

&n= bsp;

I = have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] [mmusic]&n= bsp;li= sts http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09129.html to introduce the QoS related = step D) into draft-ietf-rtcweb-rtp-usage sug= gesting usage of RFC5285, where traffic information in RTP packets = simply would be filled by any browser under any OS.

&n= bsp;

Wi= thout step B), TRAM “Enforcing the = real-time traffic through the offered/discovered TURN servers”, = the real-time traffic may happen through the IP default gateways often = congested by data traffic and QoS insensitive streaming video and file = sharing. Without specific QoS methods at those points, the network raw = bandwidth capacity may have to be 10-folded to achieve sufficient QoE = when WebRTC usage becomes popular. Methods like DISCUSS addresses such = things occurring when STUN instead TURN is used (by allowing flows into = such congestion points), but only provides direct traffic info for = outgoing (not incoming) real-time traffic and locally, therefore are not = even applicable to reservation type of networks like Cable Networks and = Mobile OTT.

 

[P=E5l] = If both clients supports = draft-martinsen-tram-discuss you would get an bi-directional end to end = description of the flow that works through = NAT.

The = information in the STUN packet can be used to remark DSCP bits to = whatever values that is of best use for the network the packet is = flowing though.

[Karl] = Again, this is only applicable for all-diffserve networks and you cannot = even route the flow to a quality pipe, not even a duplicate pipe that is = not the default gateway surf pipe (which is a very common method used = for VoIP).

 

[P=E5l] I = dont see how TURN gives that ability.

[Karl - = ???] Haven’t we many times agreed that you can add exactly the = same STUN-attributes to the TURN allocate request AND in addition to = that, control where the flow goes?

BUT THIS IS = ALSO INSUFFICIENT.

I discarded such (similar) = interface to QoS already October 22

http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg09129.html

…

PS Microsoft seems to have done work in this field, defining a = proprietary attribute “MS Service Quality”; =

However that seems to apply to the TURN server allocation request and = would therefore:

--- Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and

--- Does not handle = the bandwidth requirement for incoming real-time traffic (required to = reserve in RSVP type of networks)

However the quality attributes conveyed and their encoding may=A0 be = considered.

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(= v=3Doffice.12).aspx

…

[P=E5l] Once the channel = is bound you only have a channel number in front of the UDP payload. = And TURN is designed to carry alls sort of traffic. For this to = work there must be some sort of only webRTC traffic is allowed through = this TURN server. (And Ill bet bitorrent or others find a way to mimic = webRTC to set up only a data channel..)

[Karl] I owe Simon a response to misuse of prioritized channels – = will do later after first collecting these diversions. This has nothing to do with STUN vs = TURN! TURN just gives the addition of ALSO directing the flow. In both = cases it is insufficient to transfer traffic info in the STUN/TURN = attributes.
&n= bsp;

Th= at would leave certain network types to investing in raw bandwidth = increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable = for the carriers when delivering to their = customers.

I = know a few of you Cisco guys are among the ones that have been fighting = against the general “it is all about bandwidth” and = “it will go away with time”-attitude within IETF work, e.g. = see http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09031.html, but the pointers given in the current QoS = discussion within TRAM:

&n= bsp;

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time = traffic.

&n= bsp;

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. All networks will *also be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time = usage

(<= b>*by resisting TRAM implementation of step = B*)

Ne= wer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC5285 by browsers.

&n= bsp;

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may has to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

&n= bsp;

Fu= rther explainations about QoS methods and their implementation were = given a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/= msg00274.html

&n= bsp;

(i= ), (ii) and (iii) will *seriously delay* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

&n= bsp;

Be= low you are giving pointers saying “They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful.&#= 8221; Those are unnecessary, risking leading to (i), (ii) and (iii) = above.

&n= bsp;

[P=E5l] = We find them quite useful. It allows us = to engage with potential users and see if there are real problems to = solve. If the customer/users do not see a problem there is little = incentive for us to invest in creating a solution that nobody wants. = That said, it is always the danger of crating a to complicated solution = that solves to many problems.  

[Karl] This = is QoS stuff. Let’s stick to “Interfacing to QoS” and = with a general interface, that the “QoS device including the TURN = server” should be able to do whatever network QoS-method you = arrive at.

So= are pointers such as: “RMCAT where = congestion avoidance for RTP is being developed&#= 8221;. TRAMs Milestone 3 is for the purpose of directing real-time = traffic where congestion control isn’t already in place. Using = RFC5285 available since 2008, to fill traffic information in RTP packets = (step D)) is probably a necessity for most future “congestion = control” discussed.

&n= bsp;

[P=E5l] = There are some good example of RTP header = extension usage. For = example draft-avtext-berger-framemarking. But that information may = very well be encrypted and unavailable to the network = element.

[Karl] You (P=E5l), Colin and = Magnus seem to worry about trivial things when using the RTP header = extension, for transferring traffic information from the application = (here browser) to the network level. Don’t worry! J =A0These are really trivial things = :

- If we select to use the RTP extension header = RCF5285 for this purpose, it should of course NOT use RFC6904 = encryption, since it is meant for network level = reading/usage!

- Finding the RTP header extension = (especially when “in-band” in a known TURN-flow) is really = trivial. =A0

Linking each RTP-flow by its SSRC = and sequence number, and picking exactly the right traffic type and = bandwidth parameters is no problem (I am not aware of any “Zero = CPU” DPI device that needs to be considered – But if we can = ease the job, we should.)

This link shows much more advanced things are = available in Cisco devices:

http://www.cisco.com/en/US/products/ps6616/= products_white_paper09186a0080110040.shtml#wp39132 =

and the ADSL 2+ modem doing a lot of advanced = QoS-stuff, described in

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html =

is our Intertex/Ingate IX78, just powered by a 6 = USD 264 MHz ARM ADSL chip set CPU and we have implemented a check box TO = REMOVE the RTP Header extension (for the ugly reason that the = ITSP’s billing system requires G.711 VoIP packets of a certain = length) – It does not take noticeable CPU power to do this at 100 = Mbps wire speed!

/Karl =

.-.

P=E5l-Erik



Th= is chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:

= http://datatracker.ietf.org/doc/draft-dhesikan-tsv= wg-rtcweb-qos

fo= cusing on DSCP-mapping without even mentioning RFC 5285 available since = 2008, to fill traffic information in RTP packets where it  is a = necessity and will allow:

(1= ) applications to directly convey QoS related real-time traffic info to = the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS = methods for the particular network* = for

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of using the Internet (including = OTT).

&n= bsp;

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for current = and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09129.html

<snip><= /span>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic = scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 =

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

&n= bsp;

Th= en this could be assigned numbers to have the RFC in = place.

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it = MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

&n= bsp;l

Pl= ease see further emails soon following this one, for details and = history.

&n= bsp;

/K= arl

&n= bsp;

Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti)
Skickat: den 21 februari 2014 = 10:37
Till: tram@ietf.org
Kopia: Karl Stahl; Oleg Moskalenko; = Alan Johnston; Yoakum, John H (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

------=_NextPart_001_022F_01CF3E9E.5CC1BFB0-- ------=_NextPart_000_022E_01CF3E9E.5CC1BFB0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAVUAAADlCAIAAABs0/O4AAAAAXNSR0IArs4c6QAAjaNJREFUeF7t vQeAXFX1Pz6zfVM3vZAQ0nsgECCQRHoNoQnoFxGQPyihRBBE/Yl0xIYgloggUhRpAtKRXmJCM5SQ nmwa6b1v/5/z+Zx735vZmd3ZtC15Ly+zb968d8u5p99zz4237dC9sqK8srJCzpJYeSyzI44jxj9y ZGXJmSV35D9+kJ/kIziqqpdbFdN/sViVHvjDD/zjTf7hhbufWQN39ClrfAzt9x1BT7R9bIg2lF/1 Qh+1j8RarcnopB32NIEDSLm341ay66uBJQXcdrRr/j0MD3qHNrDx/LcbDjfMBjyOcwDM3VBjqFuG otY7Anxnu4khceMSjA+75fF5j3RzB4CXVymkmp2dnQOCzYoXte0ilL+9qrRls2YTvv/9iy68sPZC HeIY/pLkSfnAaP8vDCkDDksPYBUAjfcd3MgMjBcYdyALSCw0TWulGY4yQ3iPezX0D795kiBheLpw 5I+SjXUBm9IQTkD+vsnAEeCgNYPoaOylqqoSdcincT3fYUIlfCTfSUDI6thpPXf99yzAmHiYI7AW ttIdQRdTg8/A7eii2kMGgRDLZ8k2nAk9SwBncknyvX2bou9+93uPPPRgDQO5Az/94U9/uuKyy3bg xXSv/OUH47/724m7sMCdKeqCsSf85dkX7vzdPXJs2rIlp1J4QE5WVna8VVHHkrKtN95805HHHv/B tC+/WrnSRiYB4fjFEFflfXZWdk5udm5Odk5Odm5eXn5eTn5+bn5BTl6u8Bb9OScrFs+iqORHpRKz fug1DvvDi4oK/1Wu5SwvK5f/FeXlleVyIXfK5ab8Im87AgyxAiCg4az8kWpMxgVt1nvG/o01GDXI 49o7VV+kzXFtf048JxsX2TE9c6S0qsqKKmmkdKGiIlZZEddmaEuEk6r+k50t3BToDCquikkP5BXf ZrkybpatvDImn9nxKjmlUvkai1VIX0vLK6TXpbwoq5TPisqYVAgQeTXJFCbTRbzIIYSNhTreaYqK fHWaDRqro5abLYOVkytHdl5OTq7+FxDI0IEnyPAF/7yGk8Au5CnA2T70EiQtUKzCP469NlzaLx8V OpQCQ/koK8NPel/+geSrOADSA4EkOJARv8gp+dXJ7vjl3zj7/Asv/Ndjjy1avjzEHhzv9n9FvkHC yYhqb3Cl/TL2lsBZ2rdu9ciDD1522WULtEyHMyE5lsgOQ5QY4u1edMlgtWvd6vVf3HjSd763afZ0 eTrbMVS9AJRyUIa0Bg2qlE+ImrRHkuQCisUqUYYAmtfyWQF5UqknqhE8rIo123e/G2+95f9NfOC9 Tz8fMbD/G6++evNNN+bEcwUPskTy33jzzb2HHfD0W2954k9sRaLoMUhQ3CvCCMZk5eQKIuXk5+bk 5ekp7EBYQn6ecAa5kDtZgmS5OfJYVk6O0JVQS1zpRbENgyQlgN7wkzZLqEp/kv8yePqAchMOotoZ wE4eghz4BRc6znriFUEZoy6lTJok+gAKhMIiz8tjfFnusBDoMtXGwd9HpdnyonYBDQQtgZyU/eXl 5sqncEa5g/5K1/QZuZYu4xVBSK3C2oKmZqGpRl7srrZNx1JbLVShFMBRp7ouzcZNULj8pN2RT/0V vcYFP8G65RkpqEqLjQt3k4Yp8ctIFeTnFRTmFxbmtWiW36J5XrNmec1byEWB/2zePL+5fG1ewJv4 mt+smZx5LeS6RYG+KJ9y3Uwf0PvN8gub5RUW6nWzQik/t7Agt6AgOy9fWI/ULvABDHWMFE0Be+0R L7S1QGScwD8j6zT0YeNl6hr+ODVOmYknfoezhjsBCsWNYIBaVGYBKLbAlRtcG7XyV/7uHybnilcJ 5QlrKy+PqRgTbl4WKyurKCupKiuJlZVWlpXGyksry0uryuVChVwVPtOdVSr/gpNfY3qGyikri4vY 0MJLqkq1RuGzUnulCFDhB/H4ijVrX3x/8sADR9x88y0V2SJySrNE7T/yuOM+/lK5VHAYLzdeGTCm sG6GniuOkgUIiiuWC97niCSRC6C+3BTsV4MDDxmZGe2SXEne8ul5gbIGvAKCIf3rhTwABkDGYXwB 9ZOe0R7HFMidwDVI2KBtjI2dykT0DkmCVG1sBQTjrTxQkIpQIJJyINOepKO5WdJfI/6cLKV8yFVw AfmJkjYrV+hNSU65m3I0MrVsKctLTZC51gC25RiZSmMlEtVEwLmUhtFKzy/wMMmekGRP2Sm+K8BB jVo5+KwQobQtPy9bGHRBvlBmrlBpoVBpoV40l89metGMX4WGm+c1b54rZwvhDnJdKCxA7gt55zaX x+QBua9nLj6lKN7JLWyWI8TfTIg/XzREEQxSo8AhxmYAKTzXZo+0naaMqT6DQTSKgoqnpI5b+GdM wlinQ2ASoLEAe8ZLDLIGStuQzBXFJCyAnfWmIx/673HC00qiEsoi0MhKIbxK+SgtLy2rKlWCB7UL LYLUK4QslTiFNVRVlAktVgolpz/BJoJTipJ3q+QsK68sK4/hUwrkV9GwqkTDEuJXjlMWV421HEik kvWzOfOPOfGkls2bCa+J3/yLX7bqtu/SVau8iRbmAiHRDwXERkLQKVtRR2S+qI8iQAqF3xfIp8gT 1f8p4YWnUmvVT2j8quOrSoyvzgyAYuyNAtGbRd1VtVmaXl5ejg7oVzMBtEDajabihgcCsNcRoMjw UiEQ5x5/qLbyB144xFISUspUkoOcNxxEE1G1yScVt/KcsjiQtzzv7B3tgaq72lm1ZdS9inui7VLU Z8UqRXuG9BZalfuq+ZdVVJZJx4WzS8flWg0f1f9VRxZlWQWK/IOeLzcUArzmMHm7IGwImP2Fzgnf EqNDhiZXjDXRy/LzddSE/vPlU2036GPKe0mEjsaMr5qF5GQx+S20fEDbmCTgiQFVjqlav7qW9VP6 V7K9vKS0rKSkQkSTIKv0qFztKb7KkkKi1Il+z7Xx6+VnnyX6/+P/+MeCpUtt1NywuzFUCje9ErJB u8M7Dif8G2h6rH3r1g/cf//3r7iiePkK3nEoE3/n1be/+OTLgCiqXQ09aPCRJxxpiORMnnatW79x 0w9PvOSK9Z9/pCIIKEYln1qaHGpV0jQQk8cMAb3/9NxVk5duYj2Hd215Zp8Ocue/iXfkJ0EAKPmq uYiSCOVfC1RbQJBEfwUbEv2/14Ab7rjtlocee+btSXRTdm7XZuXcmRNv/2P84+kznnztDcFNvmmD x8oTvDMB/auFJnJNiB8swNG/KHuFgliUMKILSO0w8knsZuSDCMRspt2n7EAfMHeXGLpiYystqMYi /8rKy0tLlSEov8SnvksigK/MHdX9Y4CMkbU23VRJFYcOCTDEiaxBh8mMCKgkkLrqAtCSyKWEfk2B oHqhWorq0soy5AF4OPRB9VyAlynngtdAOQJsZaFppX8dG5tOUOouVa4nHRcuIK/oW0IjWoR2VrtN kDnWR8In9TurXxupTwBIHGkyS2U50AtA4dkmjYVxg/LzyAXy8kkz6soQxmegoSilsUKGqR/aVQde D0WldtQFvgSzA5xc+aD0vaxc6L+spLS8pEROGVxVaEUYag+1fepPwQF9hkD2HJ1flXAuO+tMof9/ PPTgvMVfsY1e5FKBMg5i9j/0RChB5ACswjF+Q6Aubdv+9b77r/r+hDlLloTQSh+8/zf3PfX4vYk3 E76d9Y3vfffaS3DLEVBVVae2bd66/poTL71i3f8+gGzRn3JQK10A/ATZw0pzz8gDP/5gma9RCh/Z qXDKim3hO784tAs7QSIn5UsJwgV4B7KBvgCtuEXfwT/9+e0/f/Rfz747mTQtcBh72KEjRx6a1bFN G088aIQNsoEpxAgJMzwMxw/xy7n37Atfc8qT4SjIW73aMPBsYEE6qpCIegxLIQYNWVVTMf4hTjFP AQuC1gTMbCrV+pZ7UcmPPzmjg7/SBpECzRiRcsQHQf+CloATv+IBsC39pDkDXIF1onY09GjShgp8 a6pIUro2pGptGK/l1EpF0c3LM7+APKBukXy5KXdycvKEBlGYs3CqaPyo61Eds+hRXBwKymRhUGgJ ciH6MzqeC0VaS8OptbO/+goMEPG84Hk2zwwTba1cZ4mapqp4vnzqNYqSMy4tLMiP5xfE8wqy9NcC +ZpdUJAld+S+XMsdeUa4fGFBjtjzcqewQE99LD9L7uivUri+JZYF72QVaBVxbTzqEqBpdblxAEo9 qDodpfYXzT21CKCFqWmjOgv4Eb0ktNTiWdtLyzZt3SKu7M1bt27aulU+eaHX27bxYtM2ucZP8rlF LrbYA/5J9+K27du3l5aUlJZu2rIVJ0rWc3MNlO9/wpNyWi1btm7dLmrO9m2iupZs3oxzS+nmLfjU r6WbN5Vu0bNMPzeX4ZSv5TgPbZcjZM/CheyTiF9+rdiyuRyv4FNfqWBpm+VE4fq5uQw1yllWKgpX iULNjFCBdnb7olbGFUnJKY5ANib/qGQsh3fjQ8k3Ry+ElOqrTq6ro5x6qr7jBhh0KBhAwgbpwiEZ sADQJJ0IjkQ9hXPqwX1V9VuNjjCpm4VJngK3oprffIVeRjAXxyOCkhUdQZhgAnQbi0TKVmtAEBUy Uj0d6j6jnw98BEa1ci68LphNHgQtCdSo9AZXKFiGukvQX61JG6TEH8eUDLQnaFgKGU/GYDFkNI4P kuMIPZOuwB2UJYFHsAF4GFxD6FCc/OqaNa7kWIkyGiFO/czNjeUqodqZrxcxKVnYhLZcWIPyCC2K BKxlkr8ozct9YRBZ4AXC7NgqeUVYCYk/jr5r81CXIgBGR9wBwmJV21LZT81LFRbVtejHVS4gEzE6 O0PXoKgVpWIkiYIotpLoTPKJr/w0FUpnUTivUi6TKvqw6CBl+Mp3y8Q615uqWOIoLSvFWSZniZyl pR71hSaTTv+TPOZexLtqvIlpgwkgKV2MHfXGlYq/TTxzogWJLwDXOtMjlrw7zfk3tkPOIW2ywiyA FckduX9Kh1zMiMnD8qI6EeSUTshXLc1KLpF6UaN2GKanqgjGYZWZUs+lSVf9oIPEHRT87oRuAVIO lFFO52l3vclPCx92vxn4cEHT1afUQto22U5GAGxQEW0eBKgA9FdRbtsEgZ8scCUoXZKSvfS2qQT6 vfRF1f5QlGASXXFkGRT7bAnqQqXwP5L46Ts0mxJoCpq11hIvRYjJG6LCaPmswtxsgvSgQ6UfTgpg LoDMTmvNhVqLyQ66SmX2UecUlEFki6aASQTIeaPnQPcB63EKDtkQ+an62ExXAqFCEXBaEpiI+P88 j4jL1xyhfD1VJvPM4x1tv3yCL+ABcgelZK1FLngtJQR6hBA8lBR5EvxOGb28yxr1xHgJuDC9Ch9n VpaqsoohqiRW0iFv3lD4RPHVPDVC/5ViTzgyxkWpWBjqVVMvinIEvVBGoH4VnmpaGSOwd9XLBD8T LTWhf8dTyALkq1S7AYdcnHL+qTzHnX9q+L4SmRzgOzzVbKsQx56YOPD86Sme+eCkfy7dObZt/ODW SvCsWg65ljty35XGAsk7wAWs8FBFelOrVgurEiaCudLNIaIAXbJixT3/fNxZLgHNU4XnYddh34nK TkpmnUMSR7HM94izVyb8FHdBQjp4cHmp9FfdH8Opo4h/MKPNZ0RNQTgFB4Kmvo4Lhkacmf6mtyi0 WWwfLQ8zz91fU1D0dxiEdCzptZmR6sx3+MSftIl4Un9iO/0LaDT96jAnoRkYQyFbUZaBGD5rCExg OjnNAQJeCBap9+gbcApUcK1OAn0Odr8+yK98GW4/haUWgr57V593h6rXzZwCIc8g221NzZJJWRHR 4vajI0D9/yK01Y5Q1mOzs94Id8MFZuisVmeac2DVHQDyhH/D2Xtw08gACpabN2f79vLt4gIoqYAX UJw7KqNkYgz9g4nIWACMTDAAOsEptct9acHlZ5x2wXcu/MF1P3pt8hS69vRxHQ/VLcuWbqjYWhLg cbWrvNbN2wzs7jGbuHNA377/ePjhH1977fPvvQcAEqN0OFd9Mu+P99wi3y6fcEPH4T29WFwxtdjf 73JQbwjSoMkH9Os368pvjf3JrTP/fj8n/1W3qVJrXyJjxFGcE6sUd4Dcl0AAOcP+P7btrZa9Py/s yipY+7BtS4/aNM8JZpr95gUULqVuoqq4UHlFLEuuy807oCPS7YRTf/bb3zzw6eznP/jYuShiFxx7 VO8BA+iJTJD2DmLW0+q2gYKFKr5RrXqowT/JQ0nCoFnDf4ws+QmsaDf9Q4kdyHzc9xN7qgpi3KkQ Qlhy0ggud1XdXbAAnQUmwCFKbVYJ/h7OKhv/YwSI+fZDdbnpSXXjY4YP9E3vEWaQoUDYHTVWoY9A XUdd1je0GawCyiqDiKjVa/MkLgrzfxJTBEpDCaZgcMYBs4PaR/0JUQZqctBggW5CJUVVJygdnmIt ZokvcnYNn2pge+vGmk31B9OEaL8o1aZpIzABSrjiLKxuPCANViXcDPJs8Ve4pmr3VXvHY/y08dV3 c/irvQirXu5UQLDLQd+1+qvhtRQMYaiTnDpZZBf0H4E9OA4ryEUZXoKAKZW95eJCrRDiF5u5hrN0 wxZaB/ZJqwESG/q/ivESKhQ6+1Qm4wrhrhcrpxYL2fMM33fahJSjUx3qvYUwU/mHCSyeSSpADV/f bN5TiP/uO3/GquWQa7kj972crxLBHjqdOiCTgskah8r/igrKLsotpSnSYjpOmcosICsQ1YyucPJ5 U/IDmUYOAHiSBZicI08lzhEPXBQNv1qzgHkIVqGJAkEArZskCMsZdnvIgDd3QKDzB6VRgweXU7el qZEUV9RoUBEYhDUjYAGkfzAUcAFcm3sQZM/wIbAW79rk3Lu77ehQJxECjiD8Q07MLMqL+hMnHdlV L6stzIEkTcYBCsQwMp5CyscMBRkHPWd2TTNK4eQA6BtAgkQXKAG0GTjNR6tEixAj+aQejgAktcaz BAP0vlPOab3rTUAC8Qh014nMk3fNhwftii5rPVR80SvstBsoRTZTqjMG4ASgStC9Ywo25WEDaLFf HBoO6LoaD/aW3AdDxhJoWZic4OBBtdGbpMBf/+LHSafnC0BWfpjEIjrhuw60jakyTefdcEauKY/G r/WBt9v2/6J5N6mL5V91za2+AXL/7Tb9jVLUI+UYLkWFoVDAfym9AHjSERtJexZy0NE/RWRg9Ycn Baj9YtCoHJED6DfnNyHJc6IXlA9OqLN7HD9l7E5VBIVTRBrVUa2kheAZkjP5VB7B6CbBU5TRr0ZX FsIQ4NNC9BH4A6xxQwgXJyettage02lMHyF4OH4KEqVeOONtCtAIHooxFA29IK7zRbnW8CqSCo1Y ZQj2QEj0IdxNnfwQ9cbpLAyQ/ELpUCMnvN5BjUP5Hl0Y2ioK9kCocuyttaH74FkUzowLglFGdsbJ B7nHiEAfZ6NUjelCMAJ3YgI7iDi0LmucKfR9Wor2DDuiD4NEUZTNSIu+Ssmh4t1UflC3zQU7fCHt A5tgQFGrZPyFqeYKAnpJGWIlOKA6YZ78vrXGQx4gDkGfNFcwgaJOH+cfFpBJyVK+PA+vYtpDHqA3 1+LhxW2rnt3sKnWO5GYX5sWb52U1y48X5stnTjOdLokXNssqaBbPbxbPa1ZV0CxWUBgrtDNeWPhF 4T533HYt6/vhj38xtHS5fPKr3Jdf/cNyoa8XSlHNs6VAuZBymmlFWm9hXlZhXqyZuG9FC5Ohd0wS PMFM2iUrVt7zmNn/3tL3RoInRrtj0EdBzhsnRJibXygGZG5BoVzT2aaAg9RVjqFEBQLG7Br8Z0bU MFWJCKonwKtJmz8IhFRMYcy/c0gAwcSSCtgVLGM/B4FJc8eZTEsR1CHXAtfxnB6C1LiPV4rQa9QB aaYWpudX+jhASeqlRezZKmpgPZz+UBOY1g/QHB2FPgTlSHRE7TWuGOXvYyVgznEqRadZyk3TsrKc 9W8EgVl+nXKBSxb0SHNLDVk1ybXH1BoYncEYbWGaGpMXROappKJv1fXaw0EZmlOZGPkDHo64ABr/ plrhm/VdqFxUYXjhEfBTum17qdj/29QLIDNSEg5QsV0CAcRBZcxAum9BP6Jg0LAH7CnCOFhXnXXm Bd/5zo9+fP1rH34kv6mbVq0z2C3ZWdsXLi/ftM3jbfWLgrYt2w7uIy0kbDBGVQf06SX2/4+uueb5 9/9rr9C7VFW1ceGyras21FBgi05Fbfbbh9qH10GG9en9xRXnnn7D7XOe/DtBJydDfYSjQHxU6oUy I+dScXW8ldXli3h7fhtatfqoymXV75AYGOFTjmgf4a3AmayKyizwWVO15LrbkSf89Oe/+NunM178 36fOq1d13pgxfQYOFP/fyt8/9oST9ubpS6J/+5WimXjlJJLKZOG9oP8cXf+Tj0g4dfAyih5CQMcx S1aXQIBDiBFS2nWz8uA9EEcRYt8QyaiLksVu0T+sGZ/UGoh9eB36NzQRM0UYaAMrzCwP8gI0haX4 ApwhBNKAeoRfDfNM8Joip1RB29jYh1MPNeBFtQAUDuCwKqKWAkzJG9ILcyTKnED29PKxj+gAZo18 X9Qk5ntqDLOPKI3XGAvwB+dhxZOmmfE3ECpGwOZ+tEsan63TgX6lBtiBxiao4UO91NmHpDtPhNSR XBybIawwc4KUyqEd6LPc0vknnOLtK922rUwm2rdvUxbAKKBS+ZRAwEqZ0IOKL/RPNPOsFS3AoJCD XXXW179zySU/+dH/e2fqF/KO88nYz2bgwlIErmCILX6JGhlHxemAYAHDeu33yMMP/eSaa16c/KH/ yS4cI/A9M2wEtWPMzVwjgyLLGtyrx+dXfOu0m38+77knlPfi1PgfOPwYAijEr0oqfIFoIeMCQTVO 1PG7tZXISfBoFJke5XhJPsH+dQG/DILSv7gANRhL6sjpPOron95w6/3/+/zlqZ95xPzWmFF9Bg5y +r8rNRT4bzo/0Rp1eggYiw+UOYbxUeSS6ARjIZJprWFAgzIcYeCmkxb2BRXBWKEiKTwdCr2oVYK2 qmvIKUtWNGQtTyNYcS1LTQoL8tWPrQFt5tYW64DhQ0AKFddk90BNzk5SpYSMBVGZTmGmPnQZVTBV VOqiBj11dQNmsBwLU8tY6FOX6mGiw1MpvmmZ4phVVZleLrmuiJdXxnktoyU8m2SL6GK9NhjYSDv8 gVuhElZ6JXwHci04p6+IAw/eZfJEHDBuDZac5wX2kX9RWIG4oR3gJ4yw4YcXE4GQ5EDaaNng4ob0 l/D0Jeiv4NEEh6EGFSCgBvV7eYosGl8EgOAAfMNMfhr+/hMPx0TnbSZx5m2KWhfKUVBQWNBMPgpx FshElN4BNghOyJEvy5v0Mx+fuMlf7ZRfaUPKSMt1cLoytTScVkVQl1ZkTXC168OyjEJiJXKFwxbk tyqSM691UY6erfNatc6RUy7atM6Vs1XLnKJW0pOcoqKsNm2yi+Qs0q9t2uhZpKfclOtsnDlt9Fc9 i/QVlpnbunV+Ky1QT/mKKuRmbpHWW9ihc2WzVkWtmpN7mCLrGJVz/zisSaRyvMIPx9jDTID6kzls qcOTjDhL5VlsmJ2ZfCKu8T/xyv9nfAcsDJsQh9qgNKjkrytr7JCIVeUAyg1wIZQvY6qfcg2ZphNd Li6Q4gO8U0iOB3zOZARAYIo7rJnR+sl6ZBKeYXbmcZCSs0VUSgCf2Diq06mtaz4q+rSobbBQLHJV 8aYMAqdO0oDs9ULZgXAB3AHzxWI+DJTFvWBuHEJMA4TUcajGv17Ab5+LNqiAcd47TKRjsOmJ9JRv /kU6NenOhICEnU+mYTyaowz+RSbEoYY+YrDTaF1YLLhB0oVz2DERQwHGS8OtgNWKpq4oHeMlMF+G LAMTFBFsWRSgxCp8bHAs/tXqNfv27v3SKy8N7dO7Y7u2zWUxYoiiwQGABzhA83Io+eNCUUPDnpVv 6A1+yk2hf8EyvaOyRDkGWIedVlroDh8Ag9G/+pVV455MquYUaNBUXotWuS1b5cn6yJYt8lq0zGvV Mr9Vyzy9I2dLodW8lq3lgZyWrWQNZW5LnHLBk19xR0qQ0/3UUt/F6/mtWim1t2yZI4VLmVJOq5YF LfRrQVFR805d2w/ef+6qdUMOGE62jxOEQK0tQf8PRDRGJnS4L3bbTB0WJpQpHFTXk0iwJyJbNb5N JCT0c5PkMP5z1ATQuimQYUea8a8qscZtYGGjXJcD+wQvVM2xlYGkSlAm1wJqq6C3A1lpMSvxaZCX TjkjGEynhiQ6SxcRWTiC0KJglpOBvKDeKAqZOifgR4UfUYlcPTsMH+IkRVw0K9VzMMlD4WZxT+Bb gRJsPQCikwvYcgdKPf2Qlph7C3xDvlIKmmqvBKAQAsNSZkFSAbuRR41+FEpQuFSwcjEIKBcfkMMA EqdLdRJR1RkXLOhiEzVqCKYZ/KZw3UOzpdTANS6gmZtMcKqGXx0QyAmna0kUjC6AqyiVT9H/t6oJ sFW9AOUSlCqfJTIxVupMGugSZFxO6WSVqsZSn8/K6tttn0N797r+hhuGDhl89plfb9GmnVh66CPU Restv9incTYabgloTaVFMe3ee+/95Y03zF++QoCKSt3hxVhohZK3AUlEviq+SO31/e+effYfH9w4 bxbm/9XzC2KA9aTOKwkEUK+xXIZ4b7hxSdehxoeEMdVGdqJCbAHwUZoGsZy81dtLZ8xf+OIjD/34 70+sKClZum49CVkK+MZhh/YZNEjpP+T/Y0nqR0rQ9smZ+R6RStEBzuRYvKS0pHR7ydYtW+heVlEt vCA3r3XHjs2LiloUtVEkUtrRCT+6nTlhTkNeZaVitxrtIiV1zkC4gCbY0FER/o+xZ8CiI1QtTQUX cNKm+i3EQAsSBqBuJwaD6oITCeQSbFO3gvqjGIKjvj0qRCYPVd6r1aiKvbqF1U5WbR/R9erUsLAC aY8u7RH61zgvXbEUWttjI0wgKUUr0WrGEKpJCOrhnJZyDSV4BbUyAqVe8Dsa/BwHqAmKNrAU5Am1 DpR7UTDKhWlaWEVTpaXJ7/oOkJo6PgSqNJ4rKeCGRZiwpP3Q+EIuLuCyBaV/mwQFDmOYMMpm8wM/ ADg3deRRHuSmg4KuK7uSZzEBTheABPwo8W/bVrJlq3gBhP7FCyisQUKApL0cbrxl5XPNnBYCgnSs X8ehZ+dORwwZ/Lcnnlg4Z+6WDevYRmq2oD3nwEHLzatDNkbs9+TttE+pokAiIHl4ycfHzKxJokYT nyzNcRqtjVQiF/vN+nidESIJBbaZPgz+4jRwkgF/stZ5JZw3QHmYYMIj9hWAMbWZyixG3WwoamOx js2b9R806Kgbfzlv5erVupbBcY547JxDD+k7aDDl/+NhYW/ix2BBgCToAmzS1s2bN61bv2nDujVb yja3672qoHMsJ395fkf5tWv5mqzK8q7xDW23Le/UvrVwgU779Srq2JH0r1MA7D+YvLn3qVkiUEHu CN4I9YD4hacpQuisNiEt72E2nvNzqv0ywsRNUAkY1IOIeUhEeIvwLxH5ryuxoRToAmxdS+sGCrwM DIVzjKIHqoKtF8jhoXH+ulxH42HkUP7KkFGEjZAV6F9psCKvMnvpF5VnpX/IdcxIaF8R4GKHfFFK 0cbI3XKMJp4j+VIfjqmYqBAYCDwg2cEwlW0InPRtNTaEJ+hKWk1MZIq2Ok1pR5j0lzkvZW6hlVRY ecFVBoga1lkiameQ+yQlxRgMmF5xRkdVABA58dqwGhWRR6Pthp8ax0nIK/1vLdm6vWz71tKt22Qh sLoAGf+nCG7GhmE5Ywq1LnoSTABA+9P53/7duh06cECH1rqIxWhQu2rcyrXc7gREn0oFCDC8Gp4n cwRHmY5SSelASrIVwst98vUQuwkRFUk7DXOxekPk6gjXirQHwncTadSzOHly2pKvlqxdy7b49px9 yMF9B0P+i//fQODGzZqZ0DpvC8Y2bli3ce26JUtXLe40fPE+h7m2pv3bd9OXfbYV9+yzX5fevdt0 6WJWCDEKCgC8BpBnUAGgJVdmORYA+ldxrQ5SQwTFM02hJRY4Isy4VkzJTgJR1MHGSQAV+CL/hQWI /MfKD9UF1BZQMWszQMqYYZXANtGZS+TqQZIapX+R/3Jyvl3NDmkr15doVKuKcgaPcRbGuJAyLXPv gVyxrBlsDTVrV63X4K0wb1X+k5L1lhE/ZuOF+IUc5BOKAa0AfVbYGGrBu8o+1HyA7U8rgIRr/yXm 3693Uh1HvV1G9n4ZlQ4N9H86SjzyEq8x4QlpTNVMbSiMIJVuamjgzNQAiFTm/BeWLFx467aSrTAB tm1T+V8iI6IrVSD2LarM0z98EpgOBDzojyGxwatLp5COmd5hAKgKBTBpNIY/eRjYfU+l2j6bfqLd AcXLbBDQClgohwNdNphocwlWU0gVntQQyZ9YpRmYppx4SsdslS+Q17bw2ZMo6w6La/JZtsr01iQe AJ9PoLaT60BTw0BYf5yGEj/74INE/ofi//C610Icn/B8RKsXFW7RvLlzZ8x6t7L3fw+8LBPil3Lm tBz8csdTXvyq4LP33i/+4nPBAMNwdIBAZTuNfwO4EOiq7wojUF4gHgGdFGSOFFnwoKlU5AJ3RPtV kW6aipai0NdR4VpaRRRxGOvyGATJEZCqmavL3bzSHH1iLcUvSBfiWr13Yu2XS3oVXUGiyQmwpgS6 LZaYMHCBqZR9BCQsENNEEBXpcwKQaaBmbwzQDwnGAGUOqIgWguYVFeHyoHYgtC7fyQg492OQpGJj WO7kP+OmsaRJTihfTqhT76bVwT9eP3E+XYZ18x+TGjJSzwV9ocOMaaAflb5AWjlqlhCwLjLKKRPw dDImirMSCGREXJOOPx2HoXgqv0DI7D4IMywZ9P5LJB8g7wnpxhhtKJsW+acCQyc7BTxOG9VHQLEu JtL0JyN+gh0YFnyiXK5ZMg3JekEw4z74KaJIYLT6mNcgFlB/gHThrJOxUopJizWlierYC68h9gAl nuQ4HGFax3ZBqYZaEG/OyB0iidG/dgoA8hwozO94d/PGjV8tKJ69rfDt/S9f3vVA4z4Z/1nYss9T LY6bMnPF/E+nbly12phpksYFOUCZpSxf6V8oXwxapT/JYSQEL8q9yF+l/ApZ+aSULyYmDQdnV2OE HBdg4L2tuiMNmH5rzB08nzPt5s3mHVVH1FbHiVykGoapbiyVZPBnMUOJagOIKCcjQNIf3LC/jApn jjcN+NE4Jyb1gSPCeADUfjSB/If6P5phmCc9QstwV0UjSB8HpD1vG0ZS6hjemGhSIrAlCcZgbfSM BQR075yybB3gojEKzN9k0TrOm0pXBh/iTAo0GfnD8H7yU01NgT756QByKJ0KdxacXhCbEX2MEXTT BxpfbDzCSE71DkyRKOKSsKFDAI9xoVXjgYCJeEajfMM8RxY2C7XFu8gRE2lyQuv1iGp6KxsDTsoF IAQ1Iq9hrEKdpNsYbhed6zcFE5YmQw2hOHCRuy1gTbgGxYYWrVv4llsj4xgESksI+maUqqXSEF0P Jxfd2uJaBZKKAlBBEhVThPhDLjesWb1i8eKP4z0+760rH3f4mNT84NcXVy2aMW2NJFqhtCXS6l/j oQzrgQEK/7+atapDu4lmFUHMxsukwGZ+W4JgCyEHLuogQxPj8hsPI7B5sBo4zOE+ByWpsCI9Qasm eSKADTMJ6kkQS0JPuBVlKTeWnNsKUlodjheAJbivYnGUVUpsj1K+qgh01xm1m/ublGz/oeNT2hgn UDrUBiugcFe9Zorm+s10QniVKAxMPpg0sIVVtthWYGKxvRZ0YGyEzMTzQfsCp5JSL/IYuTZb6zgl oeyIFwZAK0QhSb8UxhrtJNlwWQQvbGIK0hKmHKNodPkQBB3cvybr6O5FKKJXEBxPMcVHG8PBRTFM IsLVDUa0WrjWYq5okqstr4AaauHVZAGO1KlFGNviggtH8zSayFuDNDa2bp2MwJacCyNwGS7IF9y6 9aQ8F46kzWXGBV1kBy4dDlw2WLvt2IdfIW7ZaJjhBg+IAwurzrkqXNkBBWSC/W/MwNgBVGFI/k0b Vixa9E7LQ9a1H7DDlB9+sdPWxWd0Wd9jyNBW7TvoYAGr4ON2nj+R+ciLmlVeFlfLVgZBFjJv37B2 7eqVK4XmFCGV3eqMbbt9urXu0CG7oHmVrlHLtWFWfZPONZXSSsW65FQmK8T/tF3EN2hVhbb2EZEG DFuGcamBQwoyCdnSuUBO8sOHj9ZSeRfCN9cdOAaahLU8cGFzelwboPxFL9RdBxLBbcgonR+g1WIz 3BLWRZK3H8T5B+8nYoRsFoDOP2WMpjPIIxL3hRLi4ihxiraqk4qVUGw1Up5Tmm6BIBVCpUMnrEyr hC4K0gHGe73QhSWA0HGomqZ0qDWozga1U6mCjJ3hP5qRUv0lzP8lIcDlkhxH4n+hSlXI/J8MtBao gw+3ibB+BY1a/8bqKMXN4oYCx0UeiNiHle+tb3zD7DAdAO6gi5eFKK1CPaJ1Z/weLM7GjHO4ZMgW 0kLODIDAOaJTwgwtgxfCrhN8AFqNailQTGiCOJLCBQ61502jg94SPkL6eNIl9GMqOjisbHfDhg4M kdqQygj3EF44fWD/fkOHmv9foe80HAocHnJTiGbJgvkfx3os6j56lxA/C+m/dcZxPbJ6HTBcYi1M x8Wcn7n9hSzLS+NC/Er/Fdu2bimeOUtaU9C8oEPXLrmy1KBFc+mPzCUJai0uXiheL8la3blX37wW rTEjoFKGsEEQsVLrtHfelTkoM9mRFIUGA8hGnQKMKXDz5BJXA1OZQXVQYumYN3cBVAMgiNzUeR69 gHgDxUBi6sN81Wx7N9DOVkcDHVShMmMUqBZBf1GaByXxQh/hXCCrNhUBei6tAOh1UAxgRAH9yAAg 7xTz0VlnakJxhU9E5LB72FBKMYf/GFFkh3kBiXYENWMDQFRAM/YAqKTw0mUOCm64YLEYFnOxkqAC fNQojfoMWYdBwdeKxF/oEdkA07PQIuZhNO98kTZJ5Jx0eBY6AwQ8VF+BJOdfoJpgkLR2bbYqX7QP MUR0jZiCyp5KcQNHjqRYnv3Rh8AcVqBFm3OF/FHBChGGfrnKAnhmeAV0Dn2EyTnECTgsPDx/2P/I I5PunNqvT/+hw6rJf4OEDZ98W7Zw4Zcbcz7rPS7DVmb+2JiSqSMHdNxvyFCisc70UAvQeBdH/xWl y4oXrFu9uku3fdp2bE961H7B8yEBsMh2mC2SY83K1cuWfNWqY5dOPftgEIzz0ecun1+8+/Z1F12I b0EAqmO9IdwFuZh7zNirx0YySaN6R4HAWmdGqfC3YTbNHaD0BC9XAY+njkKIef6Lp1kjpCKEDh8i NoauPbMgcnnSwVMhAU7KJI0G117AU0ARZoYzXlgErTXsc9Rt+OQEkJM0KMr1CRREOFEXojcVUte0 I8yD+O6jQwlVOnxyTfO9cszGugSqNnXFWBF66m8FPQq6Se5t3MpfKJjJa0NAt5teM7p14sRBhx1G 3X7WlCmnHXlkwADZluDTIGej4sGDrr00adLJhx9uhO06a38TAVENLA7UwQ8JCkTAKmKx5bLEMPH9 U3v16jdsWMj/FwCaCoN+37xh44qVqzIk/hN7tzm1X9ukLtTw9b384YvmzFu/QjIuO0Yb4DO06FjV kuIFG9atGzh8/3adO9qqoZApSIELhhpr3alTn+EHbli9esmc2eqWs7Wj8EwpToEdiKRWX5ya4GqI M9Gu5qaxE/N68pNmktJnNAevnXaN9FJyiv1gD+uFpu3Giy6rBDNPIULAck5ZjgompVLBB53Y0kXx ms1AaeZSQGoKPK/+h1DWiiBFMLNNIN0V3CGWQBzeeHRT+mKfcELwtOfFJ6FfZZIODr7gWu7offFY 6NJDf8oduDES7uhXmRPVEqq0KCtQHR7y1bWB5Wt1UiZrtMbgAq/jPjIh20+a0gsnLqyFuMBp2b74 jMJfq9NmsAprPEIjXUdk0tQ13nVEs+Uk3tRJXYZkuYbJA7zmTbMC4Fk3lzv5qmdCpktRFJO9gh84 qRSIaLO2+EBwGqv2OhVVCR/wRs8/FRovsZwqZBNonEOhLHMODro5NBgPbWWQRUi3I72SAYrbb+2a 6W0OyoSkhfj/ddZAOS8c1imT5/nMhyVdl82fS9lAu9jxY23S0gULZOJ+4IEHSCSOaZjQM2GPM3mD dgIv0Xmb3fvAg0q2b106f56a4/Rdh2RQSCEyTkne4Tvt9Fa9RzMbwHCatslx0/O9kupeD6ryV/SY sQz0zZ3yzRhXCFqmZ1BV9CpD+BLTfGwOOm1YQZ8fSiIWUu306kswwFaFKx8BS3YQU9nhEExYX+gZ 9MFjqldovRS1LhLy1tyQ7uLeJMEAZQ2VvUS3XoXuE9edboJxZ2u9xMMUgEKEnQgoyU0N0DajxhXq s80dhso3MqP4ZBXuM3RBb7/zArqmw+iU0wIj3DXVVj9GbCEPN2JWRUircVzD98WzhBRcwnMfK9Uj hmGFm0G0uUPGc6rlZkQUYCEHW17bvGH90pVrl3Wtnf6F+J89e1ChOJji8QfG9f3BofuEkLqmy+Lm fZYsXLpiwXy4y0xZJCItW7BQZhx7DhwQdB9uqTA0DNMYcAbMFXrrNmDQlg3rF02fRnUTZjrJTl7G Y4YigDxfszZWlZRX5m2f1nrTY33Ljuu7fFCvmft2nzs6pyyUE96hl7VER9WoRooNyIyYzyOBgHBH Cwnx3BAt+SZ5ArTxc8wChiTJPqBBh5ahsQ+xAAoO35h04xEWAvZ0QPWeYMJ4EirJmJL5JUznN7Ye YllsBimf3niuKiAbIM467yMfqvZpvkmFoI1eMPnnKZ9zgaR2N9yOZdhNBxUyCxbFBoQJnoNln3jI v27OB/gVjD1Z/XyO94JOGNHbzRASOkRJAWO+b+1yaOvQJdQ1cHzX1BQDbEW7vpLvoJEhaggRAn4U Z/vs9rUTv+j8Qvx5WAXOQ7hAOiSrfn9qVY+1spELdQCAQmTcti1b165e1XfYUD/9A3AGLF6QZO3K 1XM++2zThvWAECncNP0eQ4du37xx25ZNygLguaMQdlwgoRWiLk4u3nTvpBX/+Gha6aZbO8Z/2nnd 7ZXzF66pOGtZs1+uKbyo/aff1PKlT8bVPeoQ7AA9GKkfA1Mb0B0n9h14Q7BJZNKOSB3CYbQCuvXv YaCp/QTzUw4tPb6AkxA01jCjvWpDEEIOj+r+oUAXMS3GWctk1mbeJ9A9rX0jfsfTDRQs11MGfXn0 UPoruuzMgxaotAnswPFum/Z3tO2HwFEq+b3pBdQOQIcmLvyAGfhc2/B33dp11nvjDgwqCbWD/mKb VLCxIiIYXZkGE9CwVe9JFYRoA2AKU/L4VBMUSYOUCbGZwmhSiXSgh+1E5Kt04JFQv7IyifNd3qWW OB8h/ifOHOiJX6yjS16c8+spSZuo1MQNFrbos2n9epkWQuybtat4xvRO++4rcemYmHUwhrClb27N ypVL5xcfcehhK+YWr1+1CgAmMehYy1RX++7dRQVQLd6iUVx8uWsLhja+dEPpL99aOXVt7hEjel51 5LujOj8Tn7rojUVn3730zxOXXbqp2zc2d/tOpeKBO4gBWMNlHD5wfZNc3Wjy2nQpR9NBMZ4Fm0gx 6iTRO4QzYiHWeDngr0HfnCwn3bMBJjVI9+QACTgTNJJIYD8HTMuzLF2wS85qJ593cUe8qHZiyt/u k/OS9RILA3ZDmp/5xRcvPPHEQ3/440N//MMLTz4xc9o0zw4wE+nCAS1skZ1zWgD7bWCyC46s/Lv3 t3fee+edf77zN/f+5td//vVvJv7m1w/c8/tVfodr33mT+SR+K0wK+fcTj69bu8YaHIysFe5nSamG BMLYywKTDGiN471BVZ71cABsEJy9FPqaoEn6kQisSfOveqPQPeJNah0BOl5VGlpMp4lLv6AjTKI6 6Fs2bVq1JRyWnIKGz+jfLkz828orv/7UjL9+ih3U6nJ8tXLDpjUCaGKKRBmXykXbzrpSgKFU7lTK 18CsqqqFs+Yed9TRXTt3PuWE41cuLF6/ZjVWrMjstwxHhUwLFHVuL9O7pdu3arEmqAIipvhYvqn0 d++s6DOo77e+ln9a5/P23XLnV+8eMHnQU18M/+387sdOXlh67xvzBWbbOx3jKMuPM/m2TS6FlTzo Am7ETb4beRqFBuTtCZcaBB9zc+/gMUbXISHodUojkqBsRNFYGf5uIGoNSR0uup6QtVSb3iOoTE6E GICiEm6bNlBNB7A4QK8QUPkPeRRAq9bTWPydV16Z8vbbq1foqls5JLjjg7fffvc//3FTMAwo8BMy AfEDUH6WzWk6BLgdCsBjxo49Zuwpep5yyrFjT+nVr9+LTz65etUqY6gJWOr5iMFk65atzz35ZIgF hKkc4w+AIy2UHb7+8B3zlhjfIFMOsWV73YsYhezYQw4++WCeI/QcMeKkFOdBJ43QM7CviOlktPhr hpiGmmJZrSXEEqTmysRA/ocEF8hw8/r1G9r0qoGKzxrY/p9nDPCSf0NJ+QmPTntuNpcZ1e1YU7jP uuXLvRxav3plYYuWjBJj1CR3gGKwCmaqs/bp3XPj5k1y3bJly3EnnLCqeP7GNasQM6oZ0HUNbLyy oEXhxtXCjHRlDsNwgHsmICUa5973Vx5w4IBvDFzytfwzWsx+47/Pj7m+5I6/TCpcOG919w4tBx3U d0lFyz+9sWBL97NBukaMQqgSRPT0/X9ZZ3qHeWLxjKKqVoAQvOAO3bbww1rsPQNUnHCTC5nm/OC1 10DV+tPShQs/fOMNYlhA6oEyxNlm9x0XViJ0aveOex28in2YP2vW1w8bOX/WTA6Sk0xG8Ia4wAE7 wvLf9GnTJ83osgcSbgZSKCS/TE0HXKQtMz//vHjWLEnecsSJJ1501dUXff/qr51woiTSKJ49e9a0 L6j3MYjH8wCXgsEWhJPlJTMC8lBHktu3WTpAaeY++/bo0bv3C08+6X9NYH3x+LRPP/3X3//x59/+ 9t67fitlCAv49xPCAgSrDW+cJmaLq9mVRCAqXTlPE9Q/bYvpgU41CUDvW2JaAKFYl8NpYG4YPOWr FmZJWriDJvNr2raLwhskqqxaRVa5RLqua8ZtBlMcQvx/P62/J/7lm0u/9vAX7y/eWJdmB8+ujBeV cJAgJ9YsW9Z+n27wrzKmUtel6vSYmwMTbtZ+n04zFs377MtpAtDWrVudcvzxKxcUb16/ViLlJCxA N0GIVbTp0n7t8q9gier6e89fMCTxDxZsbNO29Ul9Vx+Q9a3cz6d9/Mkxm4+995pj9rl8TMcusY3z Pp3TPCu7y36dFm+qnFl5kOcagUXNgTVaU0yVqYp/P3D/utWr9Lqk9LkH/7Z+9RqGoDlU9uRrpItA NOULwpfnTpvW/8CDGG4oqto8+Tr8QLyIWSbLSsIk35ZGVeHDwpmdJKATiiVaKPpAoBrEs3oPGPj0 Bx/2HjBImUGCcurVX1CnzakkDqlJFyC8qQFOsfdsIuENH9+g8EK5JH5t66wvPpe7o485rt/goczp 3n/I0FHHHCuPzJr2ZahHlnwFIUwhlmd8kQ4ExwgsI6mxgDkzpn/xySdzZsxg9SUl2/fp0WPbli3h NjoKjr/+wgvvvf76yuXL6Timkig91SAxU9zZfOp++PSqWYij4NIUJLlYNL/4k3fenzNd24BmmB5h nN1ZFnLf6Vs7xgBMKTMqCox8GGyIs2K8vCgCMllK7cD8/67FvoF6sbFF15T0/I1BIvkD4pdnOrfI ++yS4ZU/HV3rmbLAdXmS7dQkrIZqx2Ia3sd4bHiDp035aMn0uUtmzlsya55+zpgrZ6y0vHjxgplz Zwsci4panXTU0ctmz96yfi2WxqkKIInAZMoWa+e5ZJ69o+4V//SrzScOzTms8JKceTPnTB/T7Mz7 OrZuWRXL6VRUeNqBHTdv2pJVViFhpYUtWvxnxkr/lqd5Q2UKH5AZnakOQdUHSur1M662As8ImPRp 5L1p3YYWrYvade4CJ1jWpvXytXW7zp2xcsuWLfDCVoQhjQoOLmliLLqxCR/4ansEkENodaG9Rkg8 QF9TyImZIc3U0JhwcyLNa87UZzGP4XQqE4UOxA7XHdHIfWN80m5ByHWr10gyt14DBjpGprxP2JPk WVu3ZrWIK0QoWzfBMaz9geudMEwyEpwCJK2TtHDnXHjRls2bFxcXCxf4ZPLkuY4OHTYYWkybOlUe kPxfR5908qXXXCun/FDYrPm4s89p37EjoUXYOEsK0PN6gf1IDTxgjkL8q5csveC8b8s+nElWkGMH ZIuGm0kEIqV9+eXMLVu2rF+3fvacYll/NnfeolWrxVgODlPyITylp9dfeeV13/vu0sWL0Ay0Rz1r tmRGVs2CC2hMvfzq5X/Acqg5Cc8ro1qTeJw7uMPfT+9fJw9/9UKS7pRgsl7pB+JMmJOgBcEtKC0d kDw8p48dh/NUdzHuDPl68riB/frReG3Xpuiko49eOnNWRXkJouiFeiV6WHLLWKiZVwA4ltvKyke3 u7vZxinTF553U4vfXfqPheP/MWf8o7PG/33G9x76clN5Tn4L2c88O5afN2+5iAtOU2Gg6JSSfSZW r3rkN7+6/9abpn/0kahLz95/79qVK5657y9vPfP0vx+4b+3Klc/+9b7Jr74intTnHri/eMbMR+++ 62933D7jf59Ir5YWL/jPE4+JmOEcsqyt6tqzF9cpybliyeKuvXrLqL32xONLFyzkTkHLFi54/UnJ 1FK1fs2ax35310O/+LmcEiIh5C8Lk5776/1ffvjBQ3fc9vAdt8363yfGOMARJHJowv+dc/i++xze veuUt97atHHjuUcdIVbApg0b/u+Ir/3nmaePG9B3ZJeOj/3lXungxvXrvzlm1EP3/O7Qzh3k/Oe9 90qHN67TmzddcdkpBwyVBwJlmEzbhDr/hoid1k0QgxJyY4D3kJkqD1MFhnH90PigViERk1p9ZKCi Ir367DN/vfsuOe+/C+fdd73y7DPCJshJEchso0MVQ7T9o08eKxuoHjfu1OI5c6XQcy/+rmiRaD/d tsa85Hr6Z5/J/a8dd/yAIUPJZwubNz/1nG8I8UsAlusynmcXyfQ5W0mCNw8W/yrhLZw7b81Xy84/ 97y2RW22b98WBG44XVQLUm+Ra4YjjK1bJeR9qxS5YOHiFavWFy9Ysnjp6lnTp7zz4l0zPn97ytuP Tfvw8bLSLStXrTXfitMcpICiNm1uvPPOrt0T9jiDc12jYFW1QUQ8eYP5/0IEaWs3aiXaXfyAjjgY Kq1UZ9yC3jQHL6VUcqU+lINJbyS5cm62BpKB/i3VBpei08lK9o3R+8awj7tVPbz49QPeGfyLYaOH nHzmqFPPHn3aWaNPPXvMaed87egTh2cVaEL10vK4BJ+xPRToyvRjcUl5NuezT791zQ9POu+Czyf/ V34989LL23bq9PVLLz/mnG+e8b3L5PrM71026pTTRIKJv2DuF5/931XXyn2hUhFuWgzYm/wXf+f8 6dM6dt8XiJ4jxFw8/ctO3feVNMdDDjt80ZzZXCgmF0NGHi6s8o0nHzvyjLP+v5/dLKVNfvWl9aul tGxZWiMum4tuuOWEb53/5ZT/iqCwRabZ2Z9MntS5e/cPlq2Sc9RxxwuVCShoLGzZtPH5fz768hcz Hn37vX/+5d55M2dKqzZv2ri4eP6HK9be/ejj/5j4ByF4eVJu9h+2/4uffdm6TVvQuJuJ8WPGobJw M8cJbFi90s7NcPSULK7tOnYU6i2eM0db4/QX+So35SfJKEn9hrZNXl7+8aef2V24pDu679fr+NPO kMecCgCidAxI/p585lkl20vEmyhtPunMM4ULyMMnnH5Guw4diAderZMAyzWrV0m6lz4DBgLN9Cch /nYdOkoA5r+ffFwWLhj3dzqOvQukovA0u50it6pq+VdLN65cLcTfpk2Rs+29Z46IbPiMksmO7M4H 7zz15Sf//nTKC9O/nFlYOXPFV/NWLZ3erkVJeeGIdq0knW/XZWubF09//cO3H/nvuy+HuEeYlfjC WRfncYLJGrYZ8t+rb5Skjivnhi1mR3mPfrnqgn/Pxo6+u+zIlyGW3WCh4MmnpA+UoFYDt4xtTo6Q 8rMvv/jsyy88+/Lz+AzO2XPnsB3r1q975Z032/XqLs8jlFA8HSVCOboC0JJoaN84b948+4sjO/9+ w1sF/x71wuqc9q//59OnH3v3GTkff+eZx3A+8c5zz743+e2Pli9Y1LNDCxsbN+EuaCbGxaHHnyiZ Tzt26y7XmzdtUpKA2AEZmy0AMsvOKyjUh2WpYpeu3Xr33b55S/e+/U/69oXA3exVS5f2Hrp/QbMW VGtX42t+s+byU6du+65buUJTGMmcSGWV6AhbN22W0pRZZGezNLFmpTq5OeiQkUIuaE+hPAaK0rNz t+5vv/SikHegKmOUpcEtWrW65rY7JOVtn4GDD/naESslECMel5vnXnq5/DzkoIPlepW4ZmN689Aj jgrZu4GgZ1HBTwmMIEHmh3mFPD/kwBECr0mvvTZ3+nSWIAxo0uuvSQEHjDzMI4ACEzgp9HncaWd0 69lLroURHH/6GSLbw2Ss156qY/GZ07548aknN23Y+L8pU7p27yEWx1svvySfJ591dhJqBzlbDam1 HCF+oeT/vPD8ymXLBZDAeNTgDxeB5Vwfbg4O2SyXLVx06injhPhJfgiKoLTmBy9Imv7TojEP+drX Bx98RvcePfPKP1+xLqtsy7ztG+aX5vTv269vRf6QVm17HTrqqH4HnDZizDdGjjo+1KRqVAmRSV4H GHoOY3Sf6P9DZkJoN3q03Lw0JYkLC/i/Z2aVIoMej0UbSwb++ZOs29+v9UxZYJuyNSb9VSoqypaU bHPKpPr+hxx2cPfB/fcd1HffwXL20c8hfWL5OT337dGvT18B4PoN6199782Ovbu3aNPaJ5KXICLO X4fiPW0AW8VezV02/+Wqi1ZUFEkqqmbxqr9eciDOgx747ogHvjfib9895MHvHfLQpYc+NH7ktaeo TDBT2aJHCTeqmfShQCTKhSE8HnAUiGcVv8X7IsEOpjdCZRV0nPPp1C779YLglK8Vs/GVpCtcQHjB 3C8+l1OoXTgjq/O0TdrTRb5G0frNt4dE1XfQkLfnLpTnDunU7r9vvg5XheoeXtDJT7IgevmSxdSM qGg5RLBr0774gD5DZkdlOBCkbtRCdw2l+Mfsf2nktm1bv/jkYylDsim8/fKLf/nNL//y61+++cLz 4jodMGz/vgMHE2JARqtC/kj69+NPO33EqNHCCGTfGSN+UkAIv0mm77/xuqS46tm3r2hAC+fNleAC mQt4+emnxJwE1XlVVzmLivqysnmzZoVQNC5fF8ybK/oCXnG05JwhRtKYVqKEN/mua6+yOu3b7d8v PC97EVqB5hB0U3L2hmdEZoyQATRv3qxZYUH7LoOPPPnKfoNHH37M+SOPOr9jp/b77btP+3ateuzb tVVLzeffuXNn3VDHkawjXLNRMIyBOPc6tWmx+CmJ/gODSBwnbbYJ4099PDVj9Xn/DljAvq3yJ12w /yFdW6Z7vub7HSvXy44OZPPSJHH+r/5qqY+WVrgJ75eE6vm617hsXCU5DFYtXTGwR6/9Bw+VHzds 2vjqu2936LVvy7Zt/DyLDMH65SvbdOqsrF15rVuaC3Qq3PLW2rlt38s+e+6iNWIKte7U5u7/FM9c ukksh62lFXOWb7792S8v/PMH50+ccsG9U17+XPggOaeJF+9KDOOQY67yDI0Fr2Gq/r984QLp4Ma1 a7du3ijSe8ncuS8/8qB4OjauXdOiqKhdly5kzhJzqV/FEehoS2T+V/PnrVi8qK+mcI/Lr1Laqq+W SBWiGqxYvFBKc6hvBEZlUh575k/3yDOkz2+Nv/zqW3++cN48oyjAWiKsP3z3HbkQhV8m4YcedHBI a0QTHALxQm5tXLfunFGHzps5XeyCc0aPnDdzhl3MsIu5M6az7XaGQefwQHSW5x/7pzgyhOq+dsJJ Hbt0VaTMzurQpcvR40494sSTwkQojfCiRi6EVg887HBJWxp4JPl0aObMZKwQkmTFz8/ff8Qhn/z3 v/vsu6/seNWseYvHHrgf5Oo+QLUHHjpS7r392quzpknYmB4yd/DOa/+RiwNHjnQ+PRjNrI0mPueW LdGD0TZDHzt26dKiXZu///NRsgAwC/6Cltp/xwbYR0DYwI5aBOMHDejVqlXrtu3aDhrQV1Y9DxzY r2NHyZoRPjy0HRPUoogFRtHwB2HHQ8tzgdxnjP/nQWcwzUL506pd2zbr5ydWk/BNWMA5T8/wWkDb wpy3vj1UFgLU8Eq6n9ptW9q6Y2foHjqvW9Spk87QIOAW29poR9ynDfTSeQtat24tT2zavPmVd97q 0LNby3btlPBU+unWmgLN7Vu3t2wvN5WuQgikXysWz6ro9XUJ/ls4a/HajVu69uzabJ8uD364/JK/ fnTtY58/NPmrrv0HHHniqEEjhrQpyD1uSBen4LEHVpjjAqZT5RU269y9x1N//N37zz+T36yw8764 fu5ZeUEMhDXLl//lZz+WO4cef7KmPDCgx5ctKN6nVx8vS+1riH5at+sg87bYt6aZwEE+Tzzvwjef elxKe+GB+44+65sFzViaG2xcO9mu16JRj+hQJOff//j7cd8815qLKkSrn/X5Z/LTN792+FU339a6 bVuHfKYzWsmuucSp5OocknlUqtk4lFTxzz/2qBB/2w4dxn7j/wbuP/z0b19wybU/uuSaH53x7Qtk U6qAJoxSrOAgpoVkaHp0Alp5C5ev0uUuFQ0dMUI+5Uav/v2lARYbg9Ek35B5hwHDholb542XXvzT r38p52svPFeyffvAocP69Je0N2QWjmeA5uFksnztrjmWiJEBkN167te8fdsH//7I2nXrZCMRpkgy K8AzAlMfgkBrgfB6pzVIxppZM2fKhqbs5ILi4k+nTt2+bTu/Llmsh5NKHPdg+Knzm+LqU6G4NYuG Mpr///EniTvkPsAP3bZt1mefPt/7OwnQrfYlKf5X2IHE/z7yxcqa30r69fyqSQcee1x+oVi8Wrtw oBlTJnXu0b19107xKsljLXlByrN0Vq9cvlJBWr1sxdK5C44cfcTbUyZ16NuzVbv2motHpjaxclNg u+DzGdl5+Z169YJpp1utzfzvlJ9dcokuB47Hu33We8n+89duKf3Z41/EmxV22G/fjh1aFhbkCQBk 2CSv36rVGzYuW71h5errTh3Qo4PqNY7oA9zmVYhQCDtV/sIdlNCG5x+496ivf7Ntp858wR+SCXfK qy+NGnuqpOKVm7IxHr6eJhllghpZS0KRVnEykF3TqIsmlSA3AkGKqw3r11089oQ77n9Q9oGo03gl PByCR0qnUFLDhWCe+ttf169dK0q1EH9hs2ahhibbxaQ2/V+t6HCxybAxKoj95Te/Djc1/Nj3rr0u iWvxV5kC/PyTj0UVkuv2nToNO+igvuIRhAIJi8HsaZmPuf3++weMHq0iNB6b/f57p44ZA3OC0cAJ iyqXLFiwYfnKgjZFvQfIYjaLU3AMOv7SlCknSx4RNtSN2qIpky+78kq5MfV//7vyssseffxxCVyS r08+/sQTjz/24MMPN2/RQr6ee843xp46ro1MoPL1uM7/TfzVry677jp5QK7vvuWWC6+4onWbNpva iiAMseWq2Kn9+vYfNiz7Bz/84YfTZ+j75mflnLCqCiXbtq/asG1zC2BtmmPWmm0fL9t89sAOuv+q 5tGKS1DwptKKyV9tyhCl9t04Z0in3M49+zj9X3lRyzZtvpo9q31XqIWW3JW6tqonkuGrmWx7VFg4 ffbsffr1EyGPtFvMGClntizUXrlwaedevbJz82Nx3We1Kpa9ZslXRxx4ILdMzSudGV8zL6fz6MP7 Fc2aO2v1ii2rV65bumrjsjWb1y5btWH5qq0rV2WVbr/mlIHd2yugA3XRDRL/hpf8Af7KXGwoXP8l bmn2/z7pOWiwBjX6QcbrQuc9BgxUhzyGRhKO29dk2FWjfofi4Qc92bOWsJbi172En5ckXM89+vdj Tzu9bQfZtUH5f8ozwbgPafYJnCxUX5hUU3AtseFz82Tq8eRzvkniR1dMsDpAO3rzlK+wxk3Pw0zQ +Q455hvirweNGjXi8FEHudNfywXHKFlxgaYwcNj+Bx122EGHHT5w2LB27dsHcKSEhoyUaYx3Pvlf O1pesdiqRYsG9OgBgNvoh/TNWKs2RR267dOmvQa5UJOlOkkWMGfxkn7dupnkxgjI7S4tW/bspdG3 Mhm0ceOGww4/nATftl2bzl26DB4yhN3etm3b1886a8Hq1ZDz+rI8//GkSQePGi1Wj1xPeffdAw45 ROBc1kKEa2jKJiurf9s2f/jznyFw0RSle7XBbAd08SvIDNbADZ8mo2K176/MW3f6k9Ml+N//Uqfo gMHbZ3UW7xcTJBl04vktW8o5639T5aam94lny2x+THL7ZeVWxpnkL7dNl679Dx7Rol07cX7rjsNx ye0tu4/JpFHewi9mFnXqXNCytWwQIK4DzQiGnAF+eNZ2vblg/Rtt/9Gmxyujbxz4+bcO69S7KDdr w7rtS5YUbtu0b7Oqcw7uevs3DtinbTMbKtM3aeCpfsHVFJZlwFJ4W6pcly2KDyNHH1VHRiL45DcI lXfLMVzBbtmcvezKsKSB7i6MzqR7oakd30y/CC9YkJOsv4SlQq1jnf4B10eXkdi3v3pL+w4ecvp5 58s+eeyCpWkw2xgAckB2Crw3lr3eb+yNo+OkpnP1KCoZlXHWyxi4a70jPwdcb8v7RlPim7qvo+cl gDIqQNqtVpfm2uauYFHYnQ1ncIEHeNIgAU+xjHu+EnNRgYkcfeyxbOy+Pfa98ZZbOnaynBpdunQ9 eexYPwrnnX++7D5KqRdwb8eFmrds8dNf/UriHZu3ZDQ9J14tYQk5V3zJypV/eOJfkPhK/EL+xpGB s/OmT3u7tMdXnYbXihnH9Sx69pxBQvl10v+7b5w9tuu2gYeP0T02sH0YzVhtW1XV0jkzN69dPXDk IRLPBxGpUf3MmKi/I700gK4XNt1fGZv/2ecy4SbCH2m3NcYZ6BOfOWnSDZdcJKt9nY3jQteczRQI LuqhyWIfQ2/jT3h4WnJyzksUL52c4i7vedGVQjt3bNjDubrkxE/Jcr/6YwmqStKwmbwjw08SoGkq tFpTjL8DEhAFSI0DX5PAkwZ7rEr9E/Ld8fWQFkFlOlHwW4neLAo9EvQr3CV/HS7MD1swlMFcEVEg PMpO/otbLivrlvvv73/4aA1PiMdnT3r/9DGjTPSHGKorH+RuCSnpQSGeK9W+OGXyKYcfFuALOjpW V/Vkerz8v//5R0Xnv+PHP5acnd+/4Qbxd7rmV61o3jyEfnr7lB49+u+/v83iwBVo4VMWWAo/Qad9 uu+/xdyhNTfnteL14x6fLopAnYz/4WWzO/YQPQdoHSRmsS1xu/Tu17xt+xkffizRAOWiAsRyKmMi +fWzQj9Fsc+VT1EQJG5Xryuy5nz8aV6BJALto2q/bpJNu0B3ByJ75hgikYBd2yAHcpEDGHYZGn46 8sdfCCqXyc5tdRHKDWreXqoJUAmoMvBFvzw+ENX0IztxGTyboCP4L3bhpWsgZr36EdQVXo1vpEVK zVD4OxmbGgV8SWQCVIrsj+sGAeMPSwTI79hIwMHJdCgvtS1kC1weOBKYI/4asy0+R7iP1TSkAqEl GTFU40Ppk7wMhbWJKSO7CKGlGfd4ESVIdAlxCbGAlpUFa9QDVZ8JyC3hus25Ev1CGKjF2Svy1yIC M6X/kE0Wb9Gy5e1//OOv7v+rxD6atsumco886vg4TdYuWbnqD08+jTui+TOdsgsKAhueLyso1ud8 ss/xGTcn0wcP3TB5eLfm/Q8+VGLBJOhHY3XMXelMa8WsyuXz5qxfubzTfj3bde4EB6Figgkal6dQ nLBrly5bXlzcskPHjvv1FGTSvXnVOatbiql0kdVm7793w8XfccIfyA9eEDTXc/xA+JtuqZKfflun gZoWR9w3YcqSnA82qXDPZpL4cDK0EiQ8GxdiTa65Qau9CLSC0sp/EztoLdrm3L1sdU3y33Usoa0m /20knIGjDCAkNxU+SZ3wFQVOMtdFA2YARdNr/Six3QRJAKgQpOXHMLTCo2v1puynFWlqH8pnMTa+ LMf6Qn5y8/0PDBg9huEesya9f+Zo9Sm4x8L1GtBMwjtU8WPwwpQPxh0mU49OIfNdTNT1amh97SMX i61s2coNnsFnbLduA/bfX/T/VX968ml1/mFLNawlMfoHolaJF1DS7HyU1bO448HJuLoT33uv/3x0 0cZ+Iw4pbNVad6EF/SsQlDMBkiB+fFZt27Jx2Zy5sphfwgTade8mQSCyw7k8JHPpsgPH6iWLt8ni iqqq7kOGSsAMJ2SwTY1IIY3hJS+fPek9clnbMSaRtAIR51R/WmrIHwTpzf1uIKvMPpW/jlNwdG3s qN4BMwxNQZQahRzyEAY2pUNvvu/cFMn8w1FSAukncB4OBw1UM16p5uirauC55YCQAG4bVWwfkgkO VR9t0/iptbhNwSDKncXu1PhQ+Y5ujZkqSMCKnUTEtq7hSHA0PgxgRUwV2E5OOnamnWdFQN2ACDEM PKynzNKso0GF31M7chFzO0BAUi98mdQjeAia9hszBoFY6v8/YxR9ima66mMB7wtVHAgLG+0Xp3xw iuQRJlQSuYP1JMzqqo1B2oEL/1AVW9mqFWugoSVXY/fpOuCAA5T+//jk0whaNfp3iGv9lkclx9a8 aV++3WzkmjY9qyPBDtxpt3HRsVlfCvG37tgJxK/7T8t+G6biYVydKek0QQnrL92+ftXKNV8tkcBe CRDWwdatrPPadu3aqn17USI4uQqF2+0VxEFUt4F0R3Ue+OeVxaBc+JRhmFNLIN8nMpDyKfeVm+iq Se7npzO/5AKaWRyFkOQ5+nSlkgfIp/xH9gETJqzXxBRqYnWe9h0bIcabHRIyhw2ZDBcTdQ/CzTkq tM/G7aUcrGnR3WlsxSBW2oDbwqMCjM1gLD1eKSY5m0WVLd0miamUxccSHJ4oQmUrwNFIfRAbHTCS VgdEhlSbKhvUMPJfpYJb24POmk4ASsRaDNvwBcEskkKe9agqifLAAAlJj9FyzXkgQp8zC0gQFdpQ 0SbrFWXwjHwiOIYTZD5YRq9nv//uGYH8J3IlHGyA5z6hL2L/C/2PJFsypSBgA+FXDEvSEny1CsM3 VrZq7coCyMX+7yr0r/a/iTALTKCaCxtOFTmMY4vWbfbt1+/IrVN6rfo4Awyp5ZFeaz89uvKz/QYN bqlzkmEzm1LSJBd/0nHRodHxkpj7Nl279zn4sP6HHzHwa0cPGHNU/1Gjex90SOsu+8jW4zL/oLvq 6QbC2EMAdhfmFBhWCFNN8UFxDb5ZCkmrhVAxZoMf2DTPDnANNq32nhK5Pg76QRglJzAoVJgjB3yB uUmBs+Z0wCOGjSZPgJrAbYcZrMc9aNgTADbwUtmbRhd80FGIFuKzg2FWlxtnmVri63PYGQjMuo2y 18StRMhHLyitPgbz0vj0cb0KVEIZohZkI68yElT3urIEUNz3irtryaypbW6HTfV0az3d40j3DtQF 424PIlKTq8sDmsv+xHRnNkedykOCYN1oUE5uNo7NwsCTdPNp5yZgNipCGqfNWLEcHviL0Uk4vW/f /eQA7HhSiL87hNSCIAgTCbt64Ul1WSNSDSG0MvIuNlgRl0ROHY7+GNvdFTu9Godu06FDnyFDR1Qt GLH8jbohR+LTB616++Dcr3oPP7BINgLXsefElNlZIBW0im4YJU6lWLml8hlb36hJb/nM4hWVWZro g/uGa1m60F9ekRxASCYIhq7jhC3lND0QRtf6rAUS95wNS+7jkBIt97vJkudj31jH/HULGsU5JCnh Mnx4T+wJy+gFvRsrWTm9Sj0c0zDBGn4rgct2mdbDIrYgA128v0v/QUFk6/1JViwQjhzz8HA5EQM/ 8VOwAxYClPXgWgHjCR6BaxrhaqLN6SleJrLhXM1rFqVQqczD6uZjDkjWVhcOAybB1YPGI7BJkb7G NNtKyigzRxc7cHdNbFtE6U+Gg84YSfl5LK8vgDyNnysLJ32p8gOTkySBBHKIMSFfIE82KeICTBwL sKUSIRLV0vhOcNgXBzgPQF4kwNMkjhc7JpHcM9UVi8SRMvGVKLUSGgI5xM3nOG4y//f7x58i0HU1 ajx+5IHDm+Xn8y3XFwMtoRv0zjU31GxToklRfB6qGBeGElWVGlijPuByV7gh1DZ4gvQgSiBLL6q9 um5ShBRrME2Eb2gUnNcwGfpQPTy47HX8cf56Kidq3ZJthMGvEt9BzUS+ASBcZAJmhEY/uJ8IYr7r upSIVx7fXUeAzwGeUa/nd5AI9QmH7ja4QIbqoEjErFTfWJMNjFP4qfr7BtdQikHSmC/aqAV6B7WL BwPCQdEPi1kHakpbb2pDnXM0lQTrxK8KKgdc0hVBhTawA3DX2JAaED0FkIKMjowsHAZ4VHN1OBAb q+RwsMRwMeEbxs38LUd3CWAIoMuhAAaGydseiMdKZP+r9RvDozF2n84D9hf7X+N/hf6BFlmxo0cc +M4bbzzy1L8ctMmPPfbYBRtfjaMRhgFlGNlrGZBQ3CaRSWy4kykyW0AowN4D//fASUQeP1qsOIH2 3NdUIx4QZai8pAdTomlC90DsxG2yieCfw6KkFqUo04ixhgdTEb9VmFSeYZDXPAkQX7RjTkGBbgyN FRDxwvVlApNwI3xvyIWhXPJgS9J007Uzif69IcgwFRMPZFyUz15mJQDJkSgpn/QS1F29TwGEDIf1 EeNk/k8wykmPO5abyI3SQI6kYBTBDrB9Ifo3WeSRuxrr5C+Jg0U+4sQk8IOdSRJJJpHkyTOPPOLY sSeTBRB8J3ft5On/CQUAyPyU0aO++Z3vzPnvpBTYG92KIBBBoHFC4MjLv//Anb/+aO16bySR/nWd HE183aidM1s6Yx4dEQQiCDQhCNAqprMtOMz/Z1qKm7atXZFtCICBVREdEQQiCNQEAZKqxay47SM9 /cYXr1jxu0efsK3jY7FTj/jaN86/YP5HHzQECq+5DdLpTz755O23354jCeSiI4JABIFUEPjTn/4k t8d874q/3XXnh6vWwROnM1RjRf+XjDKg/8fVdwDl4DSh/wsubBT0L/Nkd95558UXX9xOM39ERwSB CAIpICAZROTu6EuE/n/zwer1cMSrd/UUpf8DOAtMy6DxgW/+/PlC/M7rHP2NIBBBIBkCRtW0+21p NUleDyyrDbwC4dnTRsAO3CxqI2hq1MQIAvUIAZsfNFEfzBO7+F82LdE5WI/NzbBqRNbVddo6w7Kj xyIINB0IJIUkungBn/8TwRuNrrvMkxcdEQQiCNQMAWZ1d4F8QQgvF6iFNm1JDF3e9WB99XLJWITj 8lfTli4PHfH7ebVXrimDoiOCQASB2iBg6yzCC6/wCreqZ2S4xYfXVlTsb+7wT1a/k7qQeb8/4vTY s5K1UI5pA2YbA5C7ygwyJfpQ0dXp/5VLsYw5dIy+J5GRzLtndHbyvdq6nFDqpa/o42kqCt+uXov8 WteqqzdtlxRSW4+j35sWBBjErwu+dbUk102D/uV/QPyZ9fk73/kOHxSy959y4e+nLWbuzA8PGSDJ 7vXofeWVJ7ird7b98YTYCX/c9s6VvTNrgj1VXf8/8c+yg44cL14SO+yu2Xr1/oTEMntPeL/avQwq tdKk4PvGKgdIX5E9Ofuu2NUXJPGeDOqJHokgsBsgYEu/LCdNWP/nKhAXFpyhMy2JBWRE/PLQCade 9OF1FyVp9ir+05kEsBbS6wb1YP+fePolsWmzM7BNek+4/pLJT7yYwZO7YbijIiMIJEDAcpb4hXzO zHfyP2QFZAi5sLSvXfJboSLjp5311JCQ9f/q5UOuG0KTYNqvpp0eNvudtSC6QZojY/pXnfnSS0dn Z4vo9vozLl4Rc0AP+UEtAxw16eivPHvfYeeMrZuaktj6OVZNUIuvWFuhR2BF2I2Yb9zoe2YHxSW/ GO5mhsMYPbZXQABmPk7IfuR80sPy/7vkLHtgMq33le+Q1OEAnDd7WuyiU0ngva/8fxd9OHOujcdT Fw156qxpRvs7YBskD+vkaYMeqqj484kJ9ydffVtM7kKrz74Al3I9+epfkw5Dx+Sr+4E3PHt6htbD vHtuS8UpghpdLa9c2u+Jc2CqVLwYuw0WQ2Bc3Mcb8szVQ17URx6KPXGfNSvFi7FYym7uFSgedbIm CIDcmakonJ9EHQHh1QNJ84Q1lEjjn0f4OqNh6H3lA7865IHn0s8AxD6MxQ4JmEGaQjOW//J+Sql9 2F0PwT2gWr17ILWGD6t+9l2H3fdsNdaQmlMowSb7HrQZoRphRygHdMxl7H2Tp2MtgykAY43U5ZnD 7vohWJeaFaww5Yupu5nRmEQPNWEIMIsWttPU/TB02a8emgXJVtH5WYBMoOAJvrojoKbXX/29s/3n vfQUXIG9+w2JOT4w7/c/f8DpArFDznrgnWdjzh5IMzdQF/rPpFu1PdN7wkN3TaNETn84T2GyrlHD K5dAtOMQBUW0+rEx3BF+U3OTEl+srfnR73stBHxwj892QlDo/B+yy1m6uUwMgCTirwMLOKHfTLX9 5VCjH97+E/4IWwD3An2fjZPf1FmQPhRAdoCvlvFk9w6xiN8hu9atrxzQtHxr+pzpkw8b1Fcl/ItP TMY9ecZZC2pW8LnqL+7erkelN2oIaIAf9tURmY8tseQQdYDuf5cpUhlBrb0Ugufhn6x+J00hYse7 w3v14BDA4af/vLmP3+R2Gvtf6L/W1u7qB0784S6e2DvxzzpVSO8C/JCoQb9fMH2Iyf8T/wwPhd6L nWP6v3gJkl7c1V2Nyms6EBDKx2ofNQHMBaidiy9btfqBfz/n048dN/KQ07957vyPG8H6fyGG++67 b/z48XtYBWg6OBH1ZC+AQGlpqfTy6MuufOiuOz+T/F8m+OPH7NOp3zDJ/6/+P5eUE/msGxFMovjf RjRYUVPrFwKi6EvsH3PDa6JvtEZnBDQvu26jgP1/GhX914f+X7+DGNUeQWBHIIBZP9lFIc4zB5sm KP2L/If010NYQOOS/xH97wguRO/sjRBA/D8z7XM/GVsQaPJfiV+2VsH9RnN07Nhx06ZNbk+C6G8E gQgCyRAgMXNtn4h9OWX5j3wyFDC+cu26p15/07bUqKoadcD+J515VmPx/3311Vfr16/fsmVLo+FY UUMjCOxZCBx00EFS4XGX/+Dvd/9m9satxg4kuq5jUZ+h+8dXrVv3zJtvy13OCB42bMgJZ3y9UdA/ py33LDCj2iIINDIISBiZ0v8VP3j07jvnkP6h4h/cvnXvYQfEV69b//y77yntYxrt0CGDjzvtjEZB /41sHKLmRhCoPwgI/f/zd7+dt2mbb8KB7Vr1lvk/MQvU8yf7qmZn5zY2/1/9wTOqOYJAo4IANtbW TF8yC4ATgcBV8bUbNrw6GdE+0P+HD+h31CmnnnPsUY2qc1FjIwhEEKgJAh9vLH3i979dsDmQ//u3 bdVz6LD4uo0b3/zoE5cOvGpo3z5HnHzKsi8/34VBdTfffPNVV11VU+ve+0nRuNjz6+8YE36o+OET hz967tRXzu+pd/WRifh5/D33TJ1gP+gzE6bYWyPvwcOJ74VelFeT68CbQdHBA4mFJBUZtLJ6wxPv pCoa9fne+idG3nPP8AkTqkHB6krVUd/4hJf4pPT0u8UBbFJ3PCKZvQYCJ1/1o6f+cPeiEP0Padtq vyFD4+s3bXpv6meAg5L84F49R5948p6m/71mGKKORhCoFwicOOG6Z/70u8Wbt/np/UFtW+07eKhO A4rZL6fa/xIG2Kjm/+sFlFGlEQQaHQRkb2/J+SPL/nT9H05u+6MB/7m5Obk5OXm5uXk5udGMWqMb 2qjBEQRqhUCl0r85/0TEZyP6RxR+pX8h+7zcnLwc5QISG1RrWdEDEQQiCDQuCCipx2I5SvkSBahL ACT2j/QfE7KHBiAqgIYGN66ORa2NIBBBoHYIyPyfxv/Hc7JsCZBb/yf6v9J/NuW/bg4eHREEIgg0 OQiIqBfxLh4+BPuYn0/9f3LLrQBsZOt/m9wYRR2KILBbIKDrfXT9r55q/6MSjaAXPwBX/mNtYCPL /7FbQBUVGkGgyUEAe39qpk+efuNslf+Q/vIh24M1svX/TW6Yog5FENgtECDB6zYfSABE9R/y3x/i CWyEW4DvFmhFhUYQaFoQoP7v9vpjNiDQ/8YtW16f8qGcr0354LUPPly8YkXT6njUmwgCEQREyY+v 2lby2eoNn65a/9nq9Z+v3rBN1gUL/W8vKZk+v/jLefOnz1/w5bziNes3RNCKIBBBoIlBQDT/TWXl izZvXbJl+5ItJUu2lpRVVOneXxIHWF5RIWdZRXl5RXllVaXbGrSJQSDqTgSBvRkCEu0Tq6yqwokP bAGq9r9cIRrQLQLcm6EU9T2CQFOEAPb81Jh/YQJq+8s2APpp9B/uMSYKoiOCQASBJgUB2/FLnfyi 42P5jxwi/+Wvbgqi2gC4RMKkQJMCQdSZCAJ7KQQo/5HUA3QP+W/6PxMB6yHB/8iquZcCKep2BIFG C4Fp06bdcMMN8pmyB1TpaQJA1pMLYC9ALgWWsEDuCxQtAWq0OBA1fC+FgJD9I488snHjRvlMyQJs Wy/SOhQBmP+w/yH6JUBI1v5qcJBc7KVQjLodQaARQoDEX1JSIm2Xz5QsANt/UOU3TYB/sP83dgaq UsKH/h8tAW6ESBA1ee+EQJj4W7VqlY4FmP4v0/1Y+I+JAL2Gqa+LALBBULZsEBrZ/3snIkW9bnwQ CBP/kCFDbrnlFvlMyQIw5yd2vwp4m/pz+j9+ER2Awl/d/5H/r/GhQtTivRACXu0Xsr/44osFAvIZ ZgEBTMAAVPALE+D8Pw7a/2L2OxWAikB0RBCIINDgIUCb3xM/2xtmAYk9gOBX0jfiB/3TD0izgJQf 0X+DH/iogREECIEk4k9iAUn0X6GRv3pUavivk/9YB6CUz8mBSPpHuBVBoFFAICXxp2YBSvOxqkrh AMoEdJkPyN1MffUGmlJAJSE6IghEEGjoEKDNn+4I/6oSX0i/vLK8olKW+8l/kjzX/+DDxwRFDKCh j3vUvggCdYNApYh9ofyy0ooyLPQV+uf+H0r6GhZMuwDzgtGRAgKyT1/RT97TH2SDvaITHy6OoBRB oPFAQAhetgApLy8rLy+VT+ECpPgsGv2qHRgjqI8+KXGFDxIaduZMecjvSoXB0aTpMWI49YGTTavO KqF/yfFRKik+oAFA/1f5b/uAyaWygHoU/rJFrR3Pj584jgQ95o7gHnbvtcM2CpYNf3nj+eEThu8x FtDz/FfW26bETQtHot40XQhUivivovxX418Oqvqq/2NOANYA/9b3Mebk8bEpM5bUoRljvnvPyCmP vldNJ6fkfNhrEaI3BCqFUzKSNY3Q/ZCSYZuPJ+n/CQpKOg4E0+Fhr6+EHwu9H1RLU8N+OvFE7OI9 ZcJw1XaqV8EuvmelV1OMfKkpQOEBnKhLmZmTpH8lQKsOQxM92iAgQBNfTAB3wNiH/58072YG65/8 ix++fWJs/Mlj6gq34T17pnplyoQZJ0NJmHrPyInjim4fCJ0BX0JmxrippksEyoewiuETYl7FGJ+q 8EBBWf/8+CkTxqd1C0x8NDbRWhGbMNw7Eny1Ur3pPKxm4riX2OpXXnlF2hozVSe13jFlwu1WuihG qp7YkdBJKTQRFEHvU3dTGFAqqNR1WKLnGwgE6Oanl8+5+ZD/W+YCVTmwX+qrtUKbPIY/eu7U9abh Z9aY4ofHT5iSjmOMvOe7ZCU9ew4XG+Kn54NL9Bxz7sjY1GJoDO+9NHHkPRN5PwZVAspHwu3aG1Kz 1uLqDVX83l+k0dYcodqfCv/4i/k91NapAwSC1ic2M9xJ/SUARbreh95PA5XaARE90QAhwABfXe+H jQA0xh/T/LD/ne1fr8o/rXuVdRnr/qYUF0F+1YFeEsenuHiqU6/BfkTbVsagt2s/UloINb6mbCjj HtbegBRPBEaF9qWWI10300CltuKi3xsmBLD/h+z7JzsA5uhKH933F3xAnf+Q/MwNSu2g/g7RXkMa eC3t8P6/nfbHBSVR6TZloDbaeVhs8+HOK/l8SguhWhFKWCMHdttdIA5r7eCmO3HsGFR2osLo1d0F AU3tIzxA6F92/8xWLsC9QNz8P/IBW2LA3dWGDMsdc8fUe7yNnOE7O/MYVe/AdBeRrqaxKs9eI4dP otqxZMaUwFEh+nImrVCtf+S5Y8TYUEtj4u3mMdAKvHqeVE5dNAZwFxQvR/F7j9Yq/xO6qTaPVZ4G Kpl0MXqm4UFAdvgz+lf5L8v8JcePS/UpccEMAEIasPqV/4Bcz/Mnwle3p3zO4sXTGUTnf5gwHM5H U0Vwd3zs3BTSfcwdqqvYay/FapL//jF1qZl6oRW4alWPSKt1gFOgnlonORV0wjzZpvEzhtcu/x2w 8Ua4E6mh0vBQO2pRBhDQ1F7Q/6EIZPscP/F5S5f++L6/IvmnaAVZ3z72mO9fe+2ct9/ahYbAzTff fNVVV2XQyCb6iKrksefr5tKsJ1CI7qPu1wztn3pqZFRt3SFwxg9/dMfNN7+2+CsmARPv33cG9R9+ 8MFe/3fxv3UvOnqjyUBADQZvPTSZXkUdEQgw94cs/tedfuKy+o/rfoz+6flDBGAD0P+jAduTEAhN YdRohezJNkV17WIIkKwrdKYf/n636k/9/972r3fv/y7udAMpToOEdnh2cvf3IRQw1KDbufsh0ZRr 0Am+GFb/V+kpy/8QBIT5f0sK0iCCf5vyGER9iyBQTxCgVq+RfroOUJYCCzfQg/G/5AU+/0+UAKSe RimqNoLA7oMANH2hewvzwVdv/1sWAK09Iv/dNwZRyREE6gUCmNi3SD8G+3PTL4h+WwJkewJG+T/r ZYSiSiMI7D4IQKjbYn/N92EOQNK/2w0E1Uf5v3ffKEQlRxCoLwiEJvaQDBRyn/k/sQjIqf7BJmH1 1dKo3ggCEQR2AwR08k/df6L++/w/FP7GAbgXUENyADTYvHtBw5IHKv0v/skmmNKrIQ1UEwTvTnID 8+4jxqeiXLOBufx/9Aow7B8xQvWn/3Ph6p6K+t9JiIZez4Dgd7KyNAkSkxL3+HyIukwg8ZXGB9Sd hFj0eiIEwACwA4CkApYsgOVc72f6vwv84/4/9QM7XQI3fvz42MSXfBaM+mnIzta6m+J9UiRIDEJ3 QjmCQuuX3SuaXWjP8dUoQeLOYtDueB+BPjgqZBMA0QFwYP6fy//MB2D7ge2OJtRYpsaejz/5Dl3q lgkDCIk+tygurPWluw41IbPkgImqZApJLw9obkBb4KdyNvRQDan/klpisrvWBX76Wp0TJOpi3pR8 NTMYSJUpwK0t2TUJEhN0lQACqeqsCaDp8p6kKqda2sTEhNJNTl1imh9hAJoIXMi/DPRfafP/qhvo E9T/9zjpA5NA/pK+Tpbd+1XxaVuiqflc4g1dQ4vxwlJ25g3FyneXEVSW6adb1JJBcsDaoIFlwj45 cYo431Sp/xKJ3/cls8QHO5ggMV3SkdphoKsCHbjDTdw1CRKVgbrsi5KxJGYjmKZOgZwHaDjlIthw oO/4dc/p2i7lhNMmhhFKUjlaZrjaxr7+fp9Xl0ObiZh/oX3dBUSkf3k5Jb7l/6Iy4N0Ae75fSIbH ZfdKxSly+SaQTDhZRpBHQxNlQHkQ8o/d8/w9MRSjiexcRozkjtWeHHDnQZEi9V+4L8r3XLI/yOl0 uLcTCRLf+8m4nYABWHOKJu7CBIk+IZpwU7DQdHUq5DxAQ3pQwvMZgjc5baIH/Jg7muQCaE3yBfVf t/9D/K/G/3D9D1jEzuP6jpYAVHJ5OmtnAOmqUYSQUVTyP3fMmDHnKgPQjDhpUgPvaGt39L1UiXw0 h5Cn7KIiMSXSJQfcgQSJrmCVjDuO0mmauKsSJCYkIHEZTjIHCwdDn091ZFqOpnJx6SQbows6A5TU +D9O9XP/T7nSRADq/1f1gAnA9IE9bwBo2qkA+sh3X7MGUAMDmDLjPZB/T9UkhAG8NyNtauAMgLZL H0mX+i/w7CH7YI1rBeuUILHajik73J26NDGoJKx8yy4t6RIkBW7MhCTqO1Zn9S5mVo5P5Z6cNX2H YdYQX3QTfJr+U9qH/H9C8xINUI+LfyH9bSsf29AnIRl2MiATk2Un5NHuNnDkxAkTQP4wJWITJkzc qWybYZmdOgtgLCaVptXaQ20PUv+FbjK3V3jzj1pdgHs6QWKaJu6qBInv/STosUISR13Bopqfdxsp oA3EGZZjOR/xEvLEN8WD+f40EbhkA8zRlF/yXbUCrAkCH6gPOwCpL5MMdAxnDdMASgIypYVDnUde ZCLlvS8t8duOjWmQfC9NFkDNFKgZRJF0L4XjOFXqv1BTRPgFfdHepPNVJLyzRxMkpmniLkqQOObk hNyLZqjUFSzGFJnFcGCQ9zizcgRRHDolIdSOIU0DfAtRfZIFMFty/0oKUNC/fJ21ePGlv/2d3svP zynI+96JJ/z4pz+b/p+XYQvsmmMvzv/XiFL/7ZqxjkrZMxAQ93/mFfXu3fvUa3508403Pj17Ptx/ FTIT8KPRBx80gvn/9D+DAHcZzWfeuOjJCAIRBPYABBDYL3sASJbf7HiO5P/n/h+B3q/pQSIGsAdG IqoigsAehwBie3TbLzEB5Mhx+/9YaIAL/2sQGwDsceDsrgp3Uyjw7mpuVG7ThQAJXEW+bv6njID+ QEz5uf0/kBc4UgKaLhZEPdu7IcAw/2CNr8//s3eDJep9BIEmDQGf3sOCe3QbADkw/8e1ASL6ER4U eQCaNCJEnduLIaDUHZdlPm6RD+P/GPenIQBkBtERQSCCQFODgBG2rPELx/fGZy5adPGv79Q9gQsK c/LyLjvl5J/87Gcz/vNKvcz/33TTTZmAPcPHMikqeiaCQGOEQF3n/8f94Lpbbrrp6bkLofVrLNC1 Bw0ZccghoP9f3SlTAjkF+Tl5+ZefMrZ+6f+uu+6qeTyuvvrqiP4bI8pGba5HCDj6X8T8fjIZeA3o P5j/1wVADfaY88AZvXr1OuOBOQ22hVHDIgg0eAio41/tfbgAcLj1f/zGPQEa3DHngetu+2y3tKrh JYoMkgftQFZBnwFnT+SvaUgJP3cLcjTBQn2aD0flmP93B2f/G5oP0FH/ufc9c1HfGsckTZbMJjiO KbukWT5srWsD3m50949GKsbpGX1iytRg5SFxJ7z2cgf47+7v207UYNN8WObvvXvU/7kFECm/vjUA UfWvfyPo5hvXnwDZf+59tx2TSedTZMnM5LUG+ExdYwfTZRdogF3bvU3Cis3ExaOaHihYY+oXm2vq uBDJjx8/fMJ4SZ3cFA+SPbJ+61IfZ+xb/A+mAOtj8W8yqDepqv/oJc7Uf+P6Sx7VRzKl/nBxyVky 06SwdK8kCgZToJPtgzT2QvWslEFpCcv565JGMyx/EjSblAkCNIGdpE3BKmR7IPRSOL+ALlK2n1KV FIYDX6u98jDYw0+nSWWQAgrJwjb8PbP8naE2VMshiexgPz1fc0IkHMopwplmTr5DOMJfGnn66ZTc y8J8kOdHdwHmSh+//48ZAZYUrD7535hx52r1n912Qq/rr98J6pd8rrdPjDGloBw1pIG03gZJaCQJ pUvJkZhpJJaQaiQJSglZKYcPn/FTZDJJSlG5+9Jo6vp3yXyANCqa6iucVVPzC4RJceK4l05G66rl BEtI2CO5OItVGPrMOIndSYUlqXN5Jj6ZMndrkMQRDwf54DLM35lYRVIOSZdbNjVeJySHk3ZMvb1J qgAq37nzbzjVp8X/KWRgAdS3969l34tum//q9ftrgx59dAdkf+osmTWlk6yOFUgbYtkgw5lINE2Z 5yjJr3n5ojlsfDLDdCkqQ5k+d2EazaBNCZwqiYvFfDLP5D7gLZfpU9Ka3JEsMjPJPF4tl2dCLcj2 4lI9Ms0P6C1MsqGMMDUNXHL+zlA9CQwgyC2b1N/ih8e7rLP+F4FVUzUCYORXcgLAhfox/q+BEL8b hL4XPTP/PqgBddf8U2fJzCgNZOr88R5FEzE3tSyp6e5uTqNZ9wZl/EbKLP8p306ZyzOzesCkkPUx rK1nNHApKghKU10iiWu7VJPDJ8RCqaNcKTLgsSZpBOjkn078VWn4j00AWvwv++5cf/WtBGhbjoEa sCN2v76dKktmzWkgNVNPKAu9zx/vJZNkFU27jUBmGC5PZZaKMrm4DNNoZtyKOj1Yx8rT5PLMpEpR LqYI4VXT1ncMaFZayJTwbQiSTaZMiqxMrKkZAYz6cYeGAJIFmP9fib8hUH0CmogakJnPPyVyJWTJ rDUNJJznLvMedg8JDqrP40RVTOFCygSx+cxuTqOZ2JAEezpjzSWxicUP/0Q0c5XA3uhRWVrTkTKX Z8ILNeRuNQipVLZU8HXPAxqqi5bbT2rY/SFtT2AETKi5q5kPfIN4EgwgW7L/aNY/Cfe3Xb5zLP0X xb/7qMcWS3jvrqpd+fijw8cVxZ6XlNqSZTN2ojjHrXARAQneYD47vGiC/j5y/Hix/5NRaWJa0z/D BmsqyhRtUF1lRtG4IkW3kffcMz5WLZO9Jqe3B0SFkC0SMzhYqnVI9Y7q3u8UpYTbIj/La+L9q0Pl kstznKsTr6eoVRmzHwkZh1fMRSv1wfEyxbI3s3lpgJYBBMBOhkv656ShzuRVsiKfRTijVxr0Q5D3 SvpJLr74jIULL7zjV1k5kv8zT+L/rzx13P/72c9mvv6feln/02BBKNbB7QOn7vgWGg22Y1HD9g4I nHbNdTfdeNO/5i1Gd0XSx687aLDF/weKf0OYAWiA45EqQ3kDbGbUpAgCaSFA+a/ZvzQBGFYAqgMg bP83OAdAAxnOmmb9G0gTo2ZEEKgFAiB4cAEyAj4exP/W+9R/gx3BugbiNtiORA3beyFAfz+3/fIX IfkfCf+9Fzeinu8dEAgS//grN//fIHz/e8coRL2MILDnIUDXXrAMQF2AahGI//+Cn/9SNwSU/b/y C6487ZSf/uyG+vL/Z5jYJ8PH9jyQoxojCDRMCJx27Y9vuunGp9X/b7L/h8MHHuzy/1ibG0L6D8n/ VfPRMOEbtSqCQEOGgJn3FvwfxPow/0dk/DfksYvaFkFgpyGgmn9cdv7gTj8+yYet/6Fd0HSP0Lr9 hpfyKzXYm1r6maReBsOwmwakicOv7rRqtr+sAfKr/+j/b2oaANfx7YkUeDoIiXlDghRSycnIsDM9 25UuB1XdxzR6I4BARPA1YENIulvkPx92+/80HfmvwXoaI5+UAWq3UkqwoExyZkwYDtYTZM14XgL2 gzVslpovXQ4q3869JupAVwzuhsjqvQZ+O4XZQfxf/Wf+26mOuJe5evSO6ing0mvZgWDGM8l5t5wi kZF8CacOyaw/yTmo3Fuh6qghPwy1pgbVhm8kpvaqlgOsxoxmqTKGVS81dYavWtKrsVupUiyEW5RR F5KL0nxnmnhIFlBZ9hcdssThSp8L7WEBLo802coyG8ZG8FR4+t9lAAjTfyPoQq1NdIvHq6WAS/Vm 6hxZum7Ukv9guaspErpCuPYVgBorHCSarLW57oGEHFQp35oyYQZzdgXJyVI9l5DaK5zT4PnxE5ED LCkXUCjXRqqnrYpQqTEhtFCehNiMJfpM7enV+JBPUKzdSAOdWrtAPhK04vnhM5Yg4YNXs5LSH9eY C+3R2MRqmdoyHrdG9SCn/22zb7gBgvi/gDc0qi4lNzZI9ZSUAi5Vr9LlyJIEXkxEI+Q//nkhHM0l W2MOOZdQpqhonCw2rpMymyoHVarG+pxZNWsY4dReCYnFoGaAWBMymmnCL+ZITPM02pKUMKxahq+M 0qslPFQDltXeBeYzmOjWFo+5o+Z05zXnQnM5HTJJbdaoacNF/jL+1+IAkuV/454FCNJGJiaUq9u4 gXUIqSj5nzxG8EIZgKTBGDmwW5qCzJhXCWSaQ6011pyDqtbXM3hAFZaAMRVpemA2LsiPHYJX2qeT akqZ4SujLF36UB2PTBtVx2KbzOP3339/DX1J/DVxd19MB4bkvxXT6Mk/hPHIhw05XtdDGcDU4odB /pCXE196uHhq7Wp9QsqhWiqtJQdVXZtcM2OCghvk+3XGkZK/y3mkBQRtSp0dmJWkyfC1Y1m6au9n Zo2qvZym+MS0adPSsQC5L7/W2ummZP9Dmmn+a39o9u306dzT58jq2XP4FMn/ZJqxMoAJE6bUbqOn zjtY6xjspgdo6Qf7WYgV7FyZ/Gm4WOM+o1kNTye0L2WGr1rTq2kRsDtcbm3VyWvvd5pGJd1+7yfo l+ZdTql97VgutNpb1yCeSMkC0hE/koAlHI7+g4igeu6V5P+q+UjXvlRJOsKmbor31GkkGfnh/NXM /IHhri8G3r7Eb7UASPNlCW01BGeyTIH5/qGHbjcEEmOoh6DP9E+HuiwZvgxiYZhpli7ZZMBNUIyb GlYr3NumHuGhlwam9f8lwDdNo8JFiScQhpkxtRQTJOnHuZ6RfWerz8/PlyKSWIAnfv5a7WACALsd n75g4Xk/vyM7Kzs3vyC3IP/K0069/oZ6W/+zs/CI3o8gsDdBQCj/kUceKSkpkU4PGTLk4osvDhP/ t7/9bblJeIy75kc333Tzv+Yz/5ccVdcdOOjgg7n/t9v8r+GlAN6bBjPqawSBOkJAyFuI3GsBN9xw A21+uRMm/hpKDfb/QFRwlAagjiMQPR5BoF4hEGYBGzduTE/8VTGu/bHTGq35gCH+uSgIZ9NeClSv oxVVHkFgl0MgzAJqkvw64Qe7P7QASNf/VlVWkPiNEezyBkYFRhCIILA7IUAW0KpVq3Rqv4r1uDAA T/qc6a/C+h/ZEZh7gtssQOOOAtidcI7KjiDQQCEgLOCWW27xDr9UrYyD+vlpR/zL4uJv3nizbP8h yb9yCwqu/voZ199w46w3X6+X/T8yTOyV8rHWrYsa6Mg0qmZt2LC+UbU3amxGEBj3g+tuvuXmp+Yt 4tOi7f94+JCDDzmY+r8cYgJUygV8gPUp/2tL/3VXRt2NHoogEEEgDAFd9W87f3AvUP4o+n9VVUWF 6v6wAeqb/KNBiyAQQWB3QEBjfnTnT9kD0LYAklriIv+F8CtU/kML2Cv8/28pA3xrdwB558q8f3Rs dE0LOnak9LeujsV32Y6qO9KA6J2GAAHd8Ysb/+r/bPnkbkA6/w/ZrwcCgepX/d9hWBUL8SCyMfm8 f94Ol5nmRbCP8ElWMu/+1A1Qkk585eoGyHt2NZCi8hoUBLj1X05OVnaO/BMOIAxBZwMR/0PNH0yg 0SYD7Hnx+xa+MPe+WGxUbK6LZri4d7WBOEqfPGrnxudNV/6bV8WOHh0TJtP7YhddMVfqj903176+ f7HVZK/MjX10dCxiATsH/ujtukEAFn9cdvmA/FcNgJuBZWHer9KzAOj/Te2gDqyf0mOh1ZD+r0J7 dOx+/iSnqMohWZ2JnD7q1FhsUsz8qplArnfs1qtidz+X9tGrnXIR5hFh5cJrNAkqT1jJnxcb7Qo5 +u6EioJXwLP0IDRcryVFUHQ0PQhw518hfqF8kH92IP+F5Dn97zcIanr9j90de+5UCOT3Y8kKwaTY l/xJ5PbdsfjPTHe4b1Ts6Aws5/t/FotdVWdtYtTg1DCedEnsVGgWosXcfbQ5KYT4+1wSo/og9y/p Y/e9ysOWe35xdR9RP0z7EPXEH0L8lxxs90VJ6hPq3dHP2X2XVKcJosDe3iWKhCzxAgbr/5D/G8o/ JgDUBdAkVQAh0bvSafyjYlfwp96xg4WWbzUGcdSFsdhHTkhWw52jnYB98MJYVZ0mJd+KiUy+ME1j Rt1nrKT3UWpEzIOMfuvB2FVvuvsXS1fsftCo3rELR8U+okB/K3b3qNhDzugInpkXe3BS7E3X1Itv Teidv7+3E0kT7b9f9m+7f1P6W/5/tQAcE2ii/d/l3aI0Fh1h0peZlm0s42gl5hReifTFfDlJdQHv cbw7FvuS9kbIVLlkkr1PlpHiWCRmSsyzrfjRdTRbMu1l9FzDhAAzfmm0j51w9QXrf8EAosU/dRs8 0cCvujvTSTvvMkyriaSvXFhGePWWliDEf3TgZRROlMnh28DSdtIJmkmN0TMNAQJc4qeUH1P6t+y/ VRL/r8a//ia/GAdoCO1tPG24a24sdsnu9edfEfIFqNS/OiYuQJXzo2JH0ZkB3Z6HGg6TYn+wOcnY z0Rb4HGUaithj8bV3gXYeKAdtXRHIcCl/ZW6CBgsgOXY+l+V/PAB1rvxX1v6rww8cjsKoR18r3fs IdDn7pvSk5lFcft51f3oj5Ts5ab68OiGuCB2sJf/vWPvv+nshQtiF14VdEu0lfs+CuyIjy6s5grd QRBErzV8CHC+GsIfygBVgPjnc+aMu/oH2bm5kv8rr7DgJ+edd+Mtt8x55+16Wf+zM1CM1v/sDPT8 u9H6n10CxoZWyNevu+7WW299eclS37BLB/QbMULW/wRHpP43tFGL2hNBYBdBwDx79ieYDhD5f8rV P8D63/zcwsL/d955N916a2OU/7sITlExEQSaIATOvPaHt9526ytLvgrk/8ABI0aMCOf/1JUA/FkS 6G/YdcdVV4Vs0CYI26hLEQQaPATg2pMAfyz2xUp/HGr/n3LV1dm5mv8jL7/gJ+d/++Zbb/3o38/u gQ7NSztVvQcq39kqeveuvq5gZ8uM3o8gsJsgcPrVP7jttltfWLBQQ/+qquTz8mFDzf5nCjA3+9cE 4/93E0yjYiMINBYIVFZUyFleUqJnWZmcTPZB/58t+lHS3xXkL0nIf/SjH4naL0fNWxQ2FvBF7Ywg sDMQECogOQhdZLIt387UlfJdIX45jP5LSspKShj07/f/ssygO19x9T1Jdr7MqIQIAo0aArIzDzNz yl49smPPnmcBQv9V5RWlJaVlJaXlOBnvmzD/J7EBOyn+I+Jv1GgaNX73QaB+WQCze5WXqv5PFqDO /kT6d33fUR4QEf/uw56o5CYAgXpkAcjyUVVRVi6H2AFyBPLfggF2lOw5MBHxNwEEjbqwuyFQXyzA /PtI81dRLlOAFdwGKND/PfnvGB944oknuA+pbEIindzdcIzKjyDQSCEg1CE0Ql+AUM2e6YWt98e+ 39z8mwsC3f6fbMWOkT5ePeecc7gPqWxCGPn898ygRrU0RggIdfiNOoVq9lQXXAJgZAAXHkCtP+z/ 2ykekLQVccQC9tS4RvU0JggIXdR1i+5d0j3J+SlkL2F+cmZJEtCcHGUBzP/LlcFWzU7EAEQsYJcM VVRIU4VAfRG/6vya+1/oP1fOnNy8nNxcrgOvLv93CvgRC9gp8EUvN10I1CPxk/4l+3d2bh5O5QIu G2gI4lW6NejOHhEL2FkIRu83OQjUL/Eb/cdN/6cVwE0Adf3P2Kuukozgsv4nJz/v+vMvuPm22z5+ 7t97YAii9T97AMhRFREEBAKnfv+q22699dm5QXLYq0cc6Nb/Bua/zwsQAS2CQASBpgMB9fWJtY+9 P3hiGjDu5L/sCybyvyD/+vPP32Pyv+lAN+pJBIGGDYHTrr5G8n88X7zQN3PC/rL+d4TX/8UpmJed X3DZmWd8NHnyR1M/FQ+huQpyxFrIzZZP8AxsJCqcAzuG+E8GE7qcgSEvAlcZVmGyQTcg5T6EtgmB 2h8yA8G5SHywDEtD7ncitfL2jHISajx3SQebROP1IosbJ2CvJLa1QiIrZQNlTZ/K2wri6o4Ua72V 6EpOgTWYliGYQkBj9n+t2+/d3rAxLkXrHHxcMBp2ndCMlFiKZmOvPmmFAKBNGYU+E0ds2woHYiSx 9E9ZlamcWAa7mkBmrwGJiYEYYoyUHgZ5aw43ysTC2RB6AtG5s55raagoYAjwpIaW7qpRTYTCyJGH HnnCSW9+FeT/mzBs0EEHCf3PnXvK978fzzb6P3zYsIMGDmjfpg1oXucJlPJzhBfI1qGyZ5g/0BHD dnYI/XLoLRcONqAIUrzQP1kIKco+zRPBMgh6wsjilKzYtIDZhXyBQAN9+yHHQCa2N+g4Aiq5fTJy qhBp2FT/l7jjOuSwqVp/HIcg/WOr9iRG4NtmuGisJhXCuzZYU6oDj/ib0N3UEK7FJ1zt58QbSd8c XSEZjRI/Po34bdQN2pqkwuQGOAA5sf6x2BXLYEtMImsOUMU95MHOZ+zVpJ7iNeKrw2Wkyg0o1QZN eRMZEiv3D3jPuTEsT/8BqmjXjdMZengCcs2pBdRpKSD5h+oUsaWiYuGmzfM2bvI/XTFkoMr/W3/9 6/cXLJi5eElOXp6aAHl5ec2a5Tdrkd+iZUHzFvnNmuc3b5ZfKJ+FkiFYdw/n5uHSfQkhriDjtm2D dfNgLV6xViEal0TDmmxYfleUzs6JY/dRlqDhCHbGha+A50sCMk1OBDBxJ2LmKnZHGkLfhfQPskV1 hmgy0qL1oKXC/tB/aSlWU4DsZS1FWWl5aVlFWamsqsBtbqak3BHswLffcNjhIStIGHHBeFQtoALD 1U/hv2qtCQ/WBjhdBPhqDDIkhRLx1SsjRDcPxhCe855TtJxeY08msbEU2JdO2Qn1yvMhUD4IXcdX QVdWqRArx9L0ctGgJEOFAC8maqb0VD6zsgVWHkmgEcXiAiNhjhq4qsgmn0Ai3dlShQs4LeQQDw4k IMeSktiCySZHyop7GLvyCkVFWTNbUW6KKTkMGgZk0PpNT9ALaZE+APmvzBsxdkFyfZTqREWVILlB ARwAQxASFikAXcdbqSnCyWb527lZYfyDyff//o9Z99x997knnQS0c+CqNnqGyewudTbybiwYxjpC 20EU8tukt8Mth6ZslMn0hA4BNYKj2jV/RzV74GQdVEMSCSfcaAxcQnvQb+MLZIvGI9zAw1LA/YB9 CBeF9UADAhd8i4Ti+uvh40Y2GBIHU/KTFIhiUjPxFzAjGwsPb1xUMy+c5ZGy6JSFe5U5/Io+mShQ XU36C+NQrFXpGXqgV2N4TFck/WAbG9UnSMT40ZfkDAjiuTEHE+VesQiwk6+LhGPCPM2Z5z5NyzNN NRmPUxFq0AiDFrU3Y0hm5pE3BVafb+WOXNAAST48U4zHD+nQ7q7f/rZDh05ZG7dsWTpr1jnHHks2 lNx+FQnafmN2Dq7kW4bxvAmxBxZH4DkuYIyNzCc8JMlVKW9JBc5qbUrxYq3PpBqXHbmXoiLShwGb 4sqJ6QQF1mNdysFx9i1V3QRzFUIrkSZYhO+A/cxq/aPBM5BQIWpIInN2wJXmL1PT9o5ALc07VIVA 9gn4GnxVic+mhxpTnfQoRcE1yZS5k43xUKdDGod04+W5pRM/iWNrLACiTnkBhF3YUAnrdtbBatjh irbWS+I9XXJfBVpXuqI+IsxPT1zvgXNE+7afvPhCSWVFi5atsitLSt+bNOmkI4449YTj12zcuHbz FlU+xRbIyxdbQC7EC6jZwfNyA/tftR0IK5C9kT+TB0unHPJ74QnMUnuWZm0SW7LvpmYpgAI+4GUw pUN6uUD41/Z7Rqgb0qENUzBKVOqMQQcqM2w6fg2UczxsnICB12o4qAXBKEyqkbynimLoceqWou9r kLZ86qkWk5UAKIBYDZmTybpaF93DXvQkcwIW5fTQ6iCqBaiOqFIIjvRleRKFKqTPkXBBxs4u5D7V +gHSYL/JCsLMgHyQqjdEjBRlbcYrjhkD9Kq3QwjJE8Yrwko8WqK/g9pNs0VhJrgCm9Ust5AOQ6Ya 4vKoxNQUCkTYs3LFFltfjAGic+AB9j9ZfCd9J5M03mjXsKLdmeL9rs0Lj+rSafZ//nPD9de3zs4u 3b5FIRzLzspr2bJ18xZXXvX9M886SxFdURN2DvDV8BlyjYjnEAbEEnA9XJFMw2gD4Llx8n0PKJoj 6NAgjI17TK6nYw2+acS9QOpCvcRhqqa7EQZJiJfg0QAyBE+67pkkMKAZplQDa7o2u2bV/Hv41zTt qCP0M3g87JIwkgAGeaAp8bKjhFCAGtWxKoxijiUm9TkYPj961sokpDWYudfNsPAizI0VqTOtIILb K9R4P8IBtqTitBkArqbR8q+nYtUJ95587LHf3fXb7RWVh/bv16NHD1mGDPrPyT7mqKOmfPRROeQR xRV9Xe6avhM10jz5u2GzrqUXIK55Xm4Z/GxsTJQ5YnLwMZUucxzePU8SrzxGGhMLjasxAGMEdSA9 PzDVR99VCgERfEkYylRjvXtAsHOlVuudkxjAGxtlkn/waIgFhMk+VZ+pcIbkTVKF9o6nWYguHKH6 qiOvQ78Q4ZIfeUmWCBathuW6mtCuoLP+d7tIaHRdBzOhj6k7nG7UBu/TVci+a9euLVq0aN68+f8P xKidGrK/Q2sAAAAASUVORK5CYII= ------=_NextPart_000_022E_01CF3E9E.5CC1BFB0-- From nobody Thu Mar 13 02:02:43 2014 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 081191A097E; Thu, 13 Mar 2014 02:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 SRGo627rHd_s; Thu, 13 Mar 2014 02:02:34 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5F1A098E; Thu, 13 Mar 2014 02:02:33 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403131002241330; Thu, 13 Mar 2014 10:02:24 +0100 From: "Karl Stahl" To: "'Magnus Westerlund'" , "'Colin Perkins'" , "'Pal Martinsen \(palmarti\)'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530C56CD.3010003@ericsson.com> In-Reply-To: <530C56CD.3010003@ericsson.com> Date: Thu, 13 Mar 2014 10:02:25 +0100 Message-ID: <025d01cf3e9a$f4267340$dc7359c0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025E_01CF3EA3.55EADB40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8yBSCWxibhG6xCSg6taQKdZO7sAgMCDfJw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eXBqgmG9BDSdXk2B_G584T-snd4 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] Payload Types assignments 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, 13 Mar 2014 09:02:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_025E_01CF3EA3.55EADB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 Hi Magnus, =20 With the response just sent to P=E5l http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, = skipping all the QoS methods and functions that really does not belong here when creating an =93Interface to QoS=94, I only see the suggestion of =93data = channel information=94, i.e. also marking each data channel packet with traffic bandwidth and type information to be relevant and interesting. I = checked with one of our developers and I think the same traffic information as = for RTP can be transferred in data channel packets as follows: =20 The RTP header has the following format (RFC 3550): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | RFC5285 header extension ... | | 2 bytes Max Bandwidth | 2 bytes Traffic Type | | .... | RTP Payload (often encrypted) =20 A Data Channel header could have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Channel Magic Cookie | (sequence number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | RFC5285 header extension ... | | 2 bytes Max Bandwidth | 2 bytes Traffic Type | | .... | DTLS Header 13 bytes SCTP =20 The RFC5285 header extension is not in a fixed position in any of these cases, but still trivial to find (especially when in a TURN flow). This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5=20 by making room for these bytes after the UDP header, but before the DTLS header. =20 What do you think? =20 Please apply the thought that we must allow ISPs/NSPs to route the = WebRTC media to where it can be handled, by using TURN servers. A TURN server = in a QoS-box can then use the traffic info (max bandwidth and traffic type) = found in the extension header, to do whatever QoS method or function that is appropriate for the specific network type (none discriminated).=20 =20 Regarding what to encode, I have several times suggested, e.g. already October 22 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits), that could be combined as required to describe the stream. And with the highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the = individual bits. =20 Please provide what more you see required (for any QoS method/function = for any network type)! =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] Here it is about recreation of the idea/intention of the RTP payload type (PT) header that is not available for the network level anymore, by instead having the application/browser filling the RTP header extension = with relevant traffic info that all IP network types can use. Here, similar traffic type marking is suggested for the data channel. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Skickat: den 25 februari 2014 09:40 Till: Karl Stahl Kopia: rtcweb@ietf.org; tram@ietf.org =C4mne: Re: SV: [rtcweb] [tram] Payload Types assignments =20 Karl, (As individual) =20 I also wish for more usable QoS mechanisms. However, I don't see that = being achieved by your proposal. In addition I agree with Colin about the = issues with putting the information in the RTP header extension. I would also = note that this would be very RTP specific, and not at all help with the data channels multiple streams and their priorities. There might be data = channel information that is more crucial than any of the RTP media stream = packets. =20 You are pushing for a small piece in the middle. A piece that will not = help with the more general issue of QoS.=20 --- Not at all! I am pushing for "Interfacing to QoS" rather mixing the application layer directly to lower level QoS methods like setting DSCP = bits etc.. =20 How does the application and the multiple ISPs that carries the traffic reach an agreement on what properties that can be provided, that the application in this instance have the right to request those properties = and that any cost is correctly associated with the user or the user's agent = in regards to carrying the associated cost. =20 When it comes to setting DSCP from user land in the OS, that is = restricted due to the security implications. If those implications where resolved, = then OS could open up those interfaces. There are many interlinked reasons = why things look like they do today. I don't believe in tugging on a single random thread in ball of yarn and hope that it comes out without any = knots and ties on it. =20 Show me the framework for the QoS functions you have in mind that at = least has less issues than the currently deployed and take care of at least = some of the bigger issues. If that requires information in the RTP streams = for some reasons, then let us talk about how to best encoded it. But, we need that framework first, the architecture that makes this a = better solution than the current Diffserv architecture or any other QoS architecture. =20 Cheers =20 Magnus Westerlund =20 ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------=_NextPart_000_025E_01CF3EA3.55EADB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = = http://www.ietf.org/mail-archive/web/tram/current/ms= g00331.html=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]=

 

Hi= Magnus,

 

Wi= th the response just sent to P=E5l http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, = skipping all the QoS methods and functions that really does not belong = here when creating an “Interface to QoS”, I only see the = suggestion of “data channel = information&#= 8221;, i.e. also marking each data channel packet with traffic bandwidth = and type information =A0to be relevant and interesting. I checked with = one of our developers and I think the same traffic information as for = RTP can be transferred in data channel packets as = follows:

 

The RTP header has the following format (RFC = 3550):

    = 0            =        = 1            =        = 2            =        3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=3D2|P|X|  CC   = |M|     PT      = |       sequence = number         = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |            =             &= nbsp;  = timestamp          &nbs= p;            = ;    |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |           = synchronization source (SSRC) = identifier          &nb= sp; |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = contributing source (CSRC) = identifiers          &n= bsp;  |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = RFC5285 header extension = ...           &nbs= p;          = |

   |     2 bytes = Max Bandwidth     |   2 bytes Traffic = Type        |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

RTP Payload (often = encrypted)

 

A Data Channel header could have the following = format:

    = 0            =        = 1            =        = 2            =        3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Data Channel Magic = Cookie   |      (sequence = number)        = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |            =             &= nbsp;  = timestamp          &nbs= p;            = ;    |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |           = synchronization source (SSRC) = identifier          &nb= sp; |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = contributing source (CSRC) = identifiers          &n= bsp;  |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = RFC5285 header extension = ...           &nbs= p;          = |

   |     2 bytes = Max Bandwidth     |   2 bytes Traffic = Type        |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

  DTLS Header 13 = bytes

  SCTP

 

Th= e RFC5285 header extension is not in a fixed position in any of these = cases, but still trivial to find (especially when in=A0 a TURN flow). = This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#secti= on-5

by= making room for these bytes after the UDP header, but before the DTLS = header.

 

Wh= at do you think?

 

Pl= ease apply the thought that we must allow ISPs/NSPs to route the WebRTC = media to where it can be handled, by using TURN servers. A TURN server = in a QoS-box can then use the traffic info (max bandwidth and traffic = type) found in the extension header, to do whatever QoS method or = function that is appropriate for the specific network type (none = discriminated).

 

Re= garding what to encode, I have several times suggested, = e.g.

al= ready October 22 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type e.g: Best Effort, Audio, = Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video = streaming), Minimum Delay, Reliable Delivery, Prioritize X(2 bits), = Variation Y(2 bits), that could be combined as required to describe the = stream.

And with the = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

 

Pl= ease provide what more you see required (for any QoS method/function for = any network type)!

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] Here it = is about recreation of the idea/intention of the RTP payload type (PT) = header that is not available for the network level anymore, by instead = having the application/browser filling the RT= P header extension with relevant traffic info that all IP network types = can use. Here, similar traffic type marking is suggested for the data = channel.

 

 

-----Ursprungligt meddelande-----
Fr=E5n: Magnus = Westerlund [mailto:magnus.westerlund@ericsson.com]
Skickat: den 25 = februari 2014 09:40
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = tram@ietf.org
=C4mne: Re: SV: [rtcweb] [tram] Payload Types = assignments

 

Karl,

(As = individual)

 

I also = wish for more usable QoS mechanisms. However, I don't see that being = achieved by your proposal. In addition I agree with Colin about the = issues with putting the information in the RTP header extension. I would = also note that this would be very RTP specific, and not at all help with = the data channels multiple streams and their priorities. There might be = data channel information that is more crucial than any of the RTP media = stream packets.

 

You = are pushing for a small piece in the middle. A piece that will not help = with the more general issue of QoS.

--- Not at all! I am pushing for = "Interfacing to QoS" rather mixing the application layer = directly to lower level QoS methods like setting DSCP bits = etc..

 

How does the application and the multiple ISPs that carries = the traffic reach an agreement on what properties that can be provided, = that the application in this instance have the right to request those = properties and that any cost is correctly associated with the user or = the user's agent in regards to carrying the associated = cost.

 

When it comes to setting DSCP from user land in the OS, = that is restricted due to the security implications. If those = implications where resolved, then OS could open up those interfaces.=A0 = There are many interlinked reasons why things look like they do today. I = don't believe in tugging on a single random thread in ball of yarn and = hope that it comes out without any knots and ties on = it.

 

Show me the framework for the QoS functions you = have in mind that at least has less issues than the currently deployed = and take care of at least some of the bigger issues. If that requires = information in the RTP streams for some reasons, then let us talk about = how to best encoded it.

But, we = need that framework first, the architecture that makes this a better = solution than the current Diffserv architecture or any other QoS = architecture.

 

Cheers

 

Magnus = Westerlund

 

----------------------------------------------------= ------------------

Services, Media = and Network features, Ericsson Research EAB/TXM

----------------------------------------------------= ------------------

Ericsson = AB=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Phone=A0 +46 10 = 7148287

F=E4r=F6gatan = 6=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Mobile +46 73 = 0949079

SE-164 80 Stockholm, = Sweden | mailto: magnus.westerlund@ericsso= n.com

----------------------------------------------------= ------------------

------=_NextPart_000_025E_01CF3EA3.55EADB40-- From nobody Thu Mar 13 02:24:35 2014 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 6E0861A0991; Thu, 13 Mar 2014 02:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] 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 YADHXjM7GUsC; Thu, 13 Mar 2014 02:24:21 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.160]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEBF1A0928; Thu, 13 Mar 2014 02:24:20 -0700 (PDT) Received: from ([95.199.19.223]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403131024119732; Thu, 13 Mar 2014 10:24:11 +0100 From: "Karl Stahl" To: "'Colin Perkins'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Mar 2014 10:24:11 +0100 Message-ID: <026201cf3e9d$ff05ee00$fd11ca00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0263_01CF3EA6.60CA5600" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8yhC9wiXnjCRHsTROqPtmeJmmGVQLhu7dw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bZ8txjek2vMg1M56FynY7SO8XpY Cc: 'Magnus Westerlund' , "'Pal Martinsen \(palmarti\)'" , rtcweb@ietf.org, tram@ietf.org, 'Harald Alvestrand' Subject: Re: [tram] [rtcweb] Payload Types assignments 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, 13 Mar 2014 09:24:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0263_01CF3EA6.60CA5600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 Hi Colin, =20 Please see the just sent email to P=E5l and Magnus where I address your concerns.=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg11847.html =20 /Karl =20 Footnotes: =20 [1] Please do not divert or confuse this with QoS methods in themselves (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all networks types should be able to use the traffic information for QoS methods = relevant to the particular network. =20 [2] Here it is about recreation of the idea/intention of the RTP payload type (PT) header that is not available for the network level anymore, by instead having the application/browser filling the RTP header extension = with relevant traffic info that all IP network types can use. Similar traffic type marking is suggested for the data channel. =20 Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 Skickat: den 26 februari 2014 00:49 Till: Karl Stahl Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 Karl, =20 I sympathise with your goal, but I really do not think RTP header = extensions are appropriate for this purpose. =20 Ignoring the semantic mismatch, in order to identify an RTP header extension, you need access to the signalling data, and if you have = access to the signalling, you can signal the QoS parameters without using RTP.=20 =20 You state that only the payload is encrypted in SRTP. That is not necessarily true. RTP header extensions can be encrypted when RFC 6904 = is in use, and rtcweb-rtp-usage draft recommends this be done in some cases.=20 =20 The signalling channel is also likely encrypted end-to-end in new applications, so making it difficult to extract the information you need = to parse the RTP header extension, even if it is unencrypted.=20 =20 Besides these focussed issues, I would also urge you to consider the = much broader comments Magnus made. The QoS problem is broad, and a point = solution based on RTP header extensions - even if it were workable, which I doubt = - would address only a small part of the problem space. =20 =20 =20 Colin =20 =20 =20 =20 On 25 Feb 2014, at 01:45, Karl Stahl wrote: Colin, =20 If the below were the case, it would be =93DPI guesswork=94 that I also = advice against. RTP doesn=92t even have unique protocol header within UDP =96 = it can even be confused with other UDP payload.=20 =20 However, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS methods relevant to the network (which is not diffserve in Mobile OTT and Cable Networks) has not a too difficult tasks. Linking each RTP-flow by its ID = and sequence number, and picking exactly the right traffic type and = bandwidth parameters is doable (see inline below, we at Ingate do it already)! =20 Also DiffServ DSCP-bits are seldom maintained crossing network = boundaries, thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there is no bandwidth requirement information when entering networks requiring reservation. That is always (and dynamically set) available in the RTP extension header for each packet. =20 And, I am sure you are aware of the difficulties of getting DSCP-bits through OS sockets, which is even worse with multiple streams over the = same UDP-port =20 Further, defining the QoS RTP extension header as in RFC5285, does not = in anyway conflict with other RTP extension headers or DSCP transfer or settings. =20 /Karl =20 Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 Skickat: den 24 februari 2014 23:52 Till: Karl Stahl Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 Karl, =20 I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not have a well-defined magic number in the header,=20 This is how to find the traffic info: The payload of the classifier header extension element can be encoded using either the one-byte or two-byte header defined in [rfc5285 ] and shown below in Figure 1 and 2 below. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D1 | Namespace | Value | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 1: Classifier Using the One-Byte Header =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D2 | Namespace | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Figure 2: Classifier Using the Two-Byte Header =20 indicated using a dynamically assigned identifier that is conveyed in an out-of-band=20 --- It is the TURN flow!!! Requested by the ICE protocol for the = specific media to come! and encrypted signalling channel,=20 --- Only the payload is encrypted in SRTP =96 leaving id, seq no and = header ext to be used as intended! --- Thus being the appropriate place=85 is not an appropriate place to put QoS information that has to be = processed on a per-packet basis.=20 If you want DiffServ, you know where to find it. --- True, but if it cannot be used=85 Colin =20 =20 On 24 Feb 2014, at 22:09, Karl Stahl wrote: I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: =20 (1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any suitable QoS = methods for the particular network* for=20 (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE=20 (3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT). =20 The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have an RFC in place. =20 With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established. =20 =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl Skickat: den 22 oktober 2013 16:37 Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' Kopia: 'Colin Perkins' =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 =20 =20 =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 =20 =20 ------=_NextPart_000_0263_01CF3EA6.60CA5600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = = http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml=

= [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]=

 

Hi= Colin,

 

Pl= ease see the just sent email to P=E5l and Magnus where I address your = concerns.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11847.html

 

/K= arl

 

Fo= otnotes:

 

[1= ] Please do not divert or confuse this with QoS methods in themselves = (like diffserve, bandwidth reservation, congestion control etc.) This is = the interface from the application to the network level, where all = networks types should be able to use the traffic information for QoS = methods relevant to the particular network.

 

[2= ] Here it = is about recreation of the idea/intention of the RTP payload type (PT) = header that is not available for the network level anymore, by instead = having the application/browser filling the RT= P header extension with relevant traffic info that all IP network types = can use. Si= milar traffic type marking is suggested for the data = channel.

 

Fr=E5n: Colin = Perkins [mailto:csp@csperkins.org]
Skickat: den 26 februari = 2014 00:49
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = Magnus Westerlund; tram@ietf.org; Harald Alvestrand
=C4mne: = Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I = sympathise with your goal, but I really do not think RTP header = extensions are appropriate for this purpose.

 

Ignoring the semantic mismatch, in = order to identify an RTP header extension, you need access to the = signalling data, and if you have access to the signalling, you can = signal the QoS parameters without using RTP. 

 

You state that only the payload is encrypted in SRTP. = That is not necessarily true. RTP header extensions can be encrypted = when RFC 6904 is in use, and rtcweb-rtp-usage draft recommends this be = done in some cases.

 

The = signalling channel is also likely encrypted end-to-end in new = applications, so making it difficult to extract the information you need = to parse the RTP header extension, even if it is = unencrypted. 

 

Besides these focussed issues, I would also urge you = to consider the much broader comments Magnus made. The QoS problem is = broad, and a point solution based on RTP header extensions - even if it = were workable, which I doubt - would address only a small part of the = problem space.

 

 

 

Colin

 

 

 

 

On = 25 Feb 2014, at 01:45, Karl Stahl <karl.stahl@intertex.se> = wrote:

Co= lin,

&n= bsp;

If= the below were the case, it would be “DPI guesswork” that I = also advice against. RTP doesn’t even have unique protocol header = within UDP – it can even be confused with other UDP payload. =

&n= bsp;

Ho= wever, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS = methods relevant to the network (which is not diffserve in Mobile OTT = and Cable Networks) has not a too difficult tasks. Linking each RTP-flow = by its ID and sequence number, and picking exactly the right traffic = type and bandwidth parameters is doable (see inline below, we at Ingate = do it already)!

&n= bsp;

Al= so DiffServ DSCP-bits are seldom maintained crossing network boundaries, = thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there = is no bandwidth requirement information when entering networks requiring = reservation. That is always (and dynamically set) available in the RTP = extension header for each packet.

&n= bsp;

An= d, I am sure you are aware of the difficulties of getting DSCP-bits = through OS sockets, which is even worse with multiple streams over the = same UDP-port

&n= bsp;

Fu= rther, defining the QoS RTP extension header as in RFC5285, does not in = anyway conflict with other RTP extension headers or DSCP transfer or = settings.

&n= bsp;

/K= arl

&n= bsp;

Fr=E5n: Colin = Perkins [mailto:csp@csperkins.org] =
Skickat: den 24 februari 2014 23:52
Till: Karl = Stahl
Kopia: rtcweb@ietf.org; Magnus Westerlund; = tram@ietf.org; Harald = Alvestrand
=C4mne: Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I = strongly disagree with this suggestion. An RTP header extension, located = at an unknown and variable offset into a packet that does not have a = well-defined magic number in the header,

Th= is is how to find the traffic info:

   The payload of the classifier header = extension element can be encoded

   using either the one-byte or two-byte header = defined in [rfc5285] and

   shown below in Figure 1 and 2 = below.

 

      = 0            =        = 1            =        = 2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |  ID   | len=3D1 = |   Namespace   |    = Value      |    0 = (pad)    |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

          = ;   Figure 1: Classifier Using the One-Byte = Header

 

      0     =             &= nbsp; 1          &= nbsp;        = 2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

     |      = ID       |    = len=3D2      |   = Namespace   |    = Value      |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

 

 

          = ;   Figure 2: Classifier Using the Two-Byte = Header

&n= bsp;

indicated using a dynamically assigned identifier that is = conveyed in an out-of-band

--= - It is the TURN flow!!! Requested by the ICE protocol for the specific = media to come!

and encrypted signalling channel,

--= - Only the payload is encrypted in SRTP – leaving id, seq no and = header ext to be used as intended!

--= - Thus being the appropriate place…

is not an appropriate place to put = QoS information that has to be processed on a per-packet basis. =

If you = want DiffServ, you know where to find = it.

--- True, but if it cannot be = used…

Colin

 

 

On = 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I = suggest to the RTCWEB WG that the below from the September and October = discussions on the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage = fo= r usage of RFC 5285, to allow:

&n= bsp;

(1= ) WebRTC applications to directly convey QoS related real-time traffic = info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for =

(2= ) *all* WebRTC browsers *and* clients, under *all* = OSs, and *all* current and future IP network, to achieve best QoE =

(3= ) *without* ha= ving to force WebRTC into application specific networks (such as IMS) = instead of using the Internet (including OTT).

&n= bsp;

Th= e only further activity required, is to call for ISPs’ to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= /span>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 =

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

&n= bsp;

Th= en this could be assigned numbers to have an RFC in = place.

&n= bsp;

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just this, = without even having it MUST-established.

&n= bsp;

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

&n= bsp;

Pl= ease see further emails soon following this one, for details and = history.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good way to = show these needs to the network (without using the PT, or diffserv bits, = which aren’t sufficient anyway).

 

Let's use the RTP header = extension field that also is visible outside the encrypted payload. A = week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have = done work in this field, defining a proprietary attribute “MS = Service Quality”;

However that seems to apply = to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not handle the = bandwidth requirement for incoming real-time traffic (required to = reserve in RSVP type of networks)

However the quality = attributes conveyed and their encoding may  be = considered.

 

=

This is 2.2.2.19 MS-Service = Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service Quality = Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The following stream types = are supported in this extension. All other stream types are reserved for = future use.

=A7 "0x0001": = Audio

=A7 "0x0002": = Video

=A7 "0x0003": = Supplemental Video

=A7 = "0x0004": = Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The following service = quality levels are supported in this extension. All other service = quality levels are reserved for future use.

=A7 = "0x0000": Best = effort delivery.

=A7 = "0x0001": = Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________<= /o:p>

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb=

 

 

-- 

Colin Perkins

 

 

 

 

 

-- 

Colin = Perkins

 

 

 

------=_NextPart_000_0263_01CF3EA6.60CA5600-- From nobody Thu Mar 13 07:27:29 2014 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 8CBB21A096A; Thu, 13 Mar 2014 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 JGi_Kt-71k_u; Thu, 13 Mar 2014 07:00:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BB6CE1A095E; Thu, 13 Mar 2014 07:00:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A7FE3C94BD; Thu, 13 Mar 2014 10:00:09 -0400 (EDT) Date: Thu, 13 Mar 2014 10:00:09 -0400 From: John Leslie To: Karl Stahl Message-ID: <20140313140009.GS18217@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6HLSgwI1en7xx4QTu_OyAb3MxTE X-Mailman-Approved-At: Thu, 13 Mar 2014 07:27:28 -0700 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] Payload Types assignments 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, 13 Mar 2014 14:00:19 -0000 Karl Stahl wrote: > > [879 lines] > [2135 lines] > [816 lines] > [1598 lines] I do appreciate your commitment to our tasks, Karl, but there is no hope that very many of us can slog through all that text. If you want wide readership, may I suggest you limit the number of lines you impose on the rest of us per day? -- John Leslie From nobody Mon Mar 17 03:55:41 2014 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 465221A03CD for ; Mon, 17 Mar 2014 03:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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.547, 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 LbNXBY_faQVT for ; Mon, 17 Mar 2014 03:55:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 12D371A03C8 for ; Mon, 17 Mar 2014 03:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4463; q=dns/txt; s=iport; t=1395053729; x=1396263329; h=from:to:subject:date:message-id:mime-version; bh=POozGugKdPQEbNLBXQ4AgezS7BrxoyKK7DYWygq9PHc=; b=OdHAuAlzq0QCwLvA6lHm9vWrOPpu08nPNYytW1/I4VDS8Nnu9oIPZ3vg WD5UbSPRbgFjyOG+/RGWaVG9SFZPHeY1Wk/n3WzD5TYUISUBwxHvZRfvc CiCzUOcuF/r/NVpHCYvrmG3EvvZJs7xoHXAnofTkIwtp/8tszEL5eKrXp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAFbUJlOtJXG9/2dsb2JhbABZgwY7V7kTgT2HMIEaFnSCLIELAQx0JwQch3ANoQqxMheOZII5doEUBIkainyEMIEykH2DLYIr X-IronPort-AV: E=Sophos;i="4.97,669,1389744000"; d="scan'208,217";a="310748976" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 17 Mar 2014 10:55:29 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2HAtTXD031896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Mar 2014 10:55:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 05:55:28 -0500 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: AQHPQc9oAM43PdanGEKAQmjn6WQD7Q== Date: Mon, 17 Mar 2014 10:55:28 +0000 Message-ID: <5DCC4DBD-B03F-4F75-A96A-EF8C9F241921@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.71] Content-Type: multipart/alternative; boundary="_000_5DCC4DBDB03F4F75A96AEF8C9F241921ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/MKaCFEsSs3QaWOrs4vH9o9BW2C8 Subject: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 17 Mar 2014 10:55:39 -0000 --_000_5DCC4DBDB03F4F75A96AEF8C9F241921ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi TRAMsters, Justin, Oleg and myself wrote up some of the thoughts regarding single sock= et dual IPv4/IPv6 allocations that was discussed earlier on the list. There= are still open issues, but we feel it is important that the discussion con= tinue on the list. Below are the submission details: A new version of I-D, draft-martinsen-tram-ssoda-00.txt has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository. Name: draft-martinsen-tram-ssoda Revision: 00 Title: Single SOcket Dual Allocation with TURN Document date: 2014-03-17 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-martinsen-tram-ss= oda-00.txt Status: https://datatracker.ietf.org/doc/draft-martinsen-tram-ssoda= / Htmlized: http://tools.ietf.org/html/draft-martinsen-tram-ssoda-00 Abstract: This draft describes a simple method for allocating one IPv4 and one IPv6 relay address from a single ALLOCATE request to the TURN server. This saves local ports on the client, reduces the number of candidates gathered by the client, and reduces the number of messages sent between the client and the TURN server. .-. P=E5l-Erik --_000_5DCC4DBDB03F4F75A96AEF8C9F241921ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7E58F4BACFC2AF48AE8DC31167238522@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi TRAMsters,

Justin, Oleg and myself wrote up some of the thoughts regarding single= socket dual IPv4/IPv6 allocations that was discussed earlier on the list. = There are still open issues, but we feel it is important that the discussio= n continue on the list. 

Below are the submission details:

A new version of I-D, draft-martinsen-tram-ssoda-= 00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository.

Name: draft-martin= sen-tram-ssoda
Revision: 00
Title: Single SOck= et Dual Allocation with TURN
Document date: <= /span>2014-03-17
Group: Individual = Submission
Pages: 8
URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-ssoda-00.txt
Status:         https://datatracker.i= etf.org/doc/draft-martinsen-tram-ssoda/
Htmlized:       http://tools.ietf.org/html/draft-ma= rtinsen-tram-ssoda-00


Abstract:
  This draft describes a simple method for allocating one IPv4 an= d one
  IPv6 relay address from a single ALLOCATE request to the TURN s= erver.
  This saves local ports on the client, reduces the number of
  candidates gathered by the client, and reduces the number of me= ssages
  sent between the client and the TURN server.

.-.
P=E5l-Erik
--_000_5DCC4DBDB03F4F75A96AEF8C9F241921ciscocom_-- From nobody Tue Mar 18 03:13:28 2014 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 3DDE01A00A2 for ; Tue, 18 Mar 2014 03:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 5kTrf0CkN9mQ for ; Tue, 18 Mar 2014 03:13:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 28B7F1A012B for ; Tue, 18 Mar 2014 03:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3316; q=dns/txt; s=iport; t=1395137597; x=1396347197; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sMR65oWSiTvi4bd1CAGSpbUHp/SfWcxelwjkBeebfPg=; b=QJkD1/EDyhkkbAd9xj9MHQi++lGGZM6a/q0hTOW7fpXtjcQhjbNM6YYz QBJBMPDt8M5Lmtsy5UMyS9fK/o75AN3RTSZLoROkhKZ4JfbxXK/v8/J1b JFAFQyF1d3A2QDpbRVgfbKNQVuNqJu5OM0qN/pMzyML+P4/LzFdYSPSJ0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAHsbKFOtJV2a/2dsb2JhbABagwY7V8IigSMWdIIlAQEBBIELAQgRBAEBCx05FAkJAQQBEggBh3AN0UoXjiARg1yBFASJGop8hWKQfoMtgWtA X-IronPort-AV: E=Sophos;i="4.97,677,1389744000"; d="scan'208";a="311039101" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 18 Mar 2014 10:13:16 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2IADGoS021529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Mar 2014 10:13:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 18 Mar 2014 05:13:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Pal Martinsen (palmarti)" , "tram@ietf.org" Thread-Topic: SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZJGocJ2jdTwSef3K1BegT6w== Date: Tue, 18 Mar 2014 10:13:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Zhhs7d_mYfMr7_TIHG9OjCQTlxo Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 10:13:27 -0000 My initial comments 1) Introduction Secondly, with fewer local host ports there will be fewer NAT bindings for= the NAT to keep track of, and fewer server reflexive candidates. Comment>=20 This benefits IPv4 only hosts and the above sentence may not be applicable = for dual-stack hosts. With IPv6 there will no NAT or even with NPTv6 it's = just 1:1 mapping. Dual-stack host let's say behind both NAT44 and NPTv6, ca= nnot use single ALLOCATE request to learn both relayed and server-reflexive= addresses for both families.=20 Additional details when client should use this mechanism will be helpful. 2) If the Allocate Response contains only one XOR-RELAYED-ADDRESS attribute, then the client knows that the TURN server does not support SSODA. The client can retry the missing address family allocations on new 5-tuples, if desired. Subsequent Allocate requests towards the same TURN server SHOULD NOT include multiple REQUESTED-ADDRESS-FAMILY attributes Comment> =20 How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ? May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. 3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated) 4) How does this mechanism reduce the number of candidates gathered during = the discovery process ? 5) Section 2.3 =20 The allocated non-ANY address can be used, but the client SHOULD NOT try to allocate any of the unsupported families on a different 5-tuple. Comment> I guess the above line does not hold good for errors like "Insuffi= cient capacity". -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen (palma= rti) Sent: Monday, March 17, 2014 4:25 PM To: tram@ietf.org Subject: [tram] SSODA (Single SOcket Dual Allocation with TURN) Hi TRAMsters, Justin, Oleg and myself wrote up some of the thoughts regarding single sock= et dual IPv4/IPv6 allocations that was discussed earlier on the list. There= are still open issues, but we feel it is important that the discussion con= tinue on the list.=A0 Below are the submission details: A new version of I-D, draft-martinsen-tram-ssoda-00.txt has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository. Name: draft-martinsen-tram-ssoda Revision: 00 Title: Single SOcket Dual Allocation with TURN Document date: 2014-03-17 Group: Individual Submission Pages: 8 URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/d= raft-martinsen-tram-ssoda-00.txt Status: =A0=A0=A0=A0=A0=A0=A0=A0https://datatracker.ietf.org/doc/draft-mart= insen-tram-ssoda/ Htmlized: =A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-martinsen-tram= -ssoda-00 Abstract: =A0=A0This draft describes a simple method for allocating one IPv4 and one =A0=A0IPv6 relay address from a single ALLOCATE request to the TURN server. =A0=A0This saves local ports on the client, reduces the number of =A0=A0candidates gathered by the client, and reduces the number of messages =A0=A0sent between the client and the TURN server. .-. P=E5l-Erik From nobody Tue Mar 18 03:54:14 2014 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 0598E1A03C2 for ; Tue, 18 Mar 2014 03:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 7TgqAq-7pE1x for ; Tue, 18 Mar 2014 03:54:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4971D1A06A8 for ; Tue, 18 Mar 2014 03:54:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c8-532825ca69a7 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3D.FF.10875.AC528235; Tue, 18 Mar 2014 11:54:03 +0100 (CET) Received: from [131.160.36.168] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Mar 2014 11:54:02 +0100 Message-ID: <532825CA.2000408@ericsson.com> Date: Tue, 18 Mar 2014 12:54:02 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvje5pVY1gg///WSy6lwKJD2svsDkw eSxZ8pPJY90H8wCmKC6blNSczLLUIn27BK6MNdvvsxccYKzY8vgPewPjPMYuRk4OCQETiY2T p7FC2GISF+6tZwOxhQQOMUrcmcbSxcgFZK9hlOjYtAGsiFdAW2Lq/4XMIDaLgKpE995rYDab gIXEllv3WUBsUYEoiZ9XFrBD1AtKnJz5BCwuIiAsMffgXTCbWcBQ4vLXD0xdjBwcwkC988+w gJgSAuISPY1BEBV6ElOutjBC2PIS29/OYYY4TVti+bMWlgmMArOQLJiFpGUWkpYFjMyrGNlz EzNz0ssNNzECg+7glt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBkb+5OqUxyrXjGQed89j8T7UJLZinfKRJ6q/8zV6TY690XU7VTpXatdqf8+V+ekTphuV V8tKfI7xk6u3c93h8EQvTnnVRAnd1mXla32e3d/87O7alNMJkaJzX+c2OzUfsr+o+iNApr52 XkjAyh+TnOUtT2plmSnYivu5uIdEiB39tV1rubjYciWW4oxEQy3mouJEAPFAx7UIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AcXQIEtYO-DC68mQg3ByLV0sEYk Cc: Simon Perreault Subject: [tram] Draft minutes of meeting - IETF 89 TRAM session 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, 18 Mar 2014 10:54:14 -0000 Folks, please, find the drafts minutes of meeting from our session in London under the following link: http://www.ietf.org/proceedings/89/minutes/minutes-89-tram Cheers, Gonzalo From nobody Tue Mar 18 03:56:18 2014 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 4AFB71A03D8 for ; Tue, 18 Mar 2014 03:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 yR1dunf24SrS for ; Tue, 18 Mar 2014 03:56:15 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6F1A03CA for ; Tue, 18 Mar 2014 03:56:14 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-7c-53282646dc1b Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BA.1A.04853.64628235; Tue, 18 Mar 2014 11:56:06 +0100 (CET) Received: from [131.160.36.168] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Mar 2014 11:56:05 +0100 Message-ID: <53282645.70309@ericsson.com> Date: Tue, 18 Mar 2014 12:56:05 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3RtdNTSPY4O8+UYvupf9ZLD6svcDm wOSxZMlPJo91H8wDmKK4bFJSczLLUov07RK4Mm4/es1asIi54se9D8wNjMeYuhg5OSQETCSm zpzDDmGLSVy4t56ti5GLQ0jgBKPEsxfnWCGcNYwSbxa8ZQSp4hXQlPi2oh0owcHBIqAqMWG/ CkiYTcBCYsut+ywgtqhAlMTPKwvYIcoFJU7OfAIWFxEQlph78C6YzSxgKHH56wcmkDHCAuYS t8+ogJgSAuISPY1BEBV6ElOutjBC2PIS29/OYQaxhQS0JZY/a2GZwCgwC8mCWUhaZiFpWcDI vIpRsji1uDg33chALzc9t0QvtSgzubg4P0+vOHUTIzAwD275bbSD8eQe+0OM0hwsSuK811lr goQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwenFrJtxavPiEy5H5PR6HgvnO1/B+01qetqp+ 7lMuBWn//RO2rA44Olc+pLeOZYP+YcHejTfFCm48OtXKav5pYoHS4RBptc8bOg6vu2Ekneay scH9z6zYF87ef3w0V6TdOvmtJuDWh/4Txg76xc/4Pi35zL7renxPhPIxDcGlz24G3hUMf898 RomlOCPRUIu5qDgRAPMqZSUaAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RjnY8evVfh3kLYUqSVdd_Fq4lAo Cc: Simon Perreault Subject: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 18 Mar 2014 10:56:16 -0000 Hi, from the draft minutes of meeting: > * draft-petithuguenin-tram-stun-dtls > Discussions led by Marc Petit-Huguenin > > There was a strong consensus in the room to adopt this draft as a WG > item for the miletone about adding DTLS as a transport for STUN/TURN. We would like to confirm this decision on the list. So, if you have any comments, please share them with the group. Cheers, Gonzalo From nobody Tue Mar 18 03:57:51 2014 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 176B91A06E0 for ; Tue, 18 Mar 2014 03:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 roS6GxIluYLb for ; Tue, 18 Mar 2014 03:57:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCFE1A03C2 for ; Tue, 18 Mar 2014 03:57:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-00-5328269c7e78 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.80.10875.C9628235; Tue, 18 Mar 2014 11:57:32 +0100 (CET) Received: from [131.160.36.168] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Mar 2014 11:57:30 +0100 Message-ID: <5328269A.6080907@ericsson.com> Date: Tue, 18 Mar 2014 12:57:30 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvje4cNY1gg+61ShbdS/+zWHxYe4HN gcljyZKfTB7rPpgHMEVx2aSk5mSWpRbp2yVwZSzcMYOlYAJrxcOvW9gaGLtZuhg5OSQETCRu v5zPCGGLSVy4t56ti5GLQ0jgEKPE5w3r2CGcNYwSM54uZwKp4hXQlthztxMowcHBIqAq8ea+ P0iYTcBCYsut+2BDRQWiJH5eWcAOUS4ocXLmE7C4iICwxNyDd8FsZgFDictfP4CNFAbqvbHi HzPISAkBcYmexiCIEj2JKVdbGCFseYntb+cwg9hCQBcsf9bCMoFRYBaSDbOQtMxC0rKAkXkV I3tuYmZOernhJkZg2B3c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwNj6Q+fQuqNLPnls9Q9+nVbK3HBTclnCCo2L+2q7d3Q8rjk4/0s8057ImGeK6Qsk v348bnXDt9q3KP5RUTTLwqPi/ErXqmPbM/P+HbKucLub7q5yIsPOhbPMVmG/3ubNKYlTppru Zl7msjulxExkc6ZA3N/vy798fv7J5nG6383KW5NuSpXl/lZiKc5INNRiLipOBADXEzxLCQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-DdVx9aH_P1ZtiWXjEANlkxv4-s Cc: Simon Perreault Subject: [tram] Adoption of draft-reddy-behave-turn-auth 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, 18 Mar 2014 10:57:47 -0000 Hi, from the draft minutes of meeting: > * draft-reddy-behave-turn-auth > Discussions led by Justin Uberti > > There was a strong consensus in the room to adopt this draft as a WG > item for the miletone about analysing the problems with current TURN > authentication. Additionaly, the relevant milestone will updated to > reflect the fact that the eventual RFC will be Informational. We would like to confirm this decision on the list. So, if you have any comments, please share them with the group. Additionally, we (the chairs) will update the milestone to indicate that it is about an Informational document. Cheers, Gonzalo From nobody Tue Mar 18 04:01:19 2014 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 AD52C1A06F7 for ; Tue, 18 Mar 2014 04:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 JEgQlCKvGBDj for ; Tue, 18 Mar 2014 04:01:02 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 717CB1A06EC for ; Tue, 18 Mar 2014 04:01:01 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id DDE4493C2A1; Tue, 18 Mar 2014 11:00:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <53282645.70309@ericsson.com> Date: Tue, 18 Mar 2014 12:00:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55D26D7B-59E5-4299-8692-52E95849BB4A@edvina.net> References: <53282645.70309@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PRVW_T2DB9qTyTSYcbvRdFkWB9A Cc: Simon Perreault , Olle E Johansson , tram@ietf.org Subject: Re: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 18 Mar 2014 11:01:11 -0000 On 18 Mar 2014, at 11:56, Gonzalo Camarillo = wrote: > Hi, >=20 > from the draft minutes of meeting: >=20 >> * draft-petithuguenin-tram-stun-dtls >> Discussions led by Marc Petit-Huguenin >>=20 >> There was a strong consensus in the room to adopt this draft as a WG >> item for the miletone about adding DTLS as a transport for STUN/TURN. >=20 > We would like to confirm this decision on the list. So, if you have = any > comments, please share them with the group. My only comment was that we might want to look into using DANE as an alternative here. There was another discussion about not = validating the certificate at all. I think we should happily adopt this draft and discuss these issues. /O= From nobody Tue Mar 18 04:05:47 2014 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 852401A03CB for ; Tue, 18 Mar 2014 04:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 MXcZaWN7hHxA for ; Tue, 18 Mar 2014 04:05:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 154991A06F6 for ; Tue, 18 Mar 2014 04:05:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c1-532828793443 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 45.22.10875.97828235; Tue, 18 Mar 2014 12:05:29 +0100 (CET) Received: from [131.160.36.168] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.347.0; Tue, 18 Mar 2014 12:05:28 +0100 Message-ID: <53282878.4000209@ericsson.com> Date: Tue, 18 Mar 2014 13:05:28 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <53282645.70309@ericsson.com> <55D26D7B-59E5-4299-8692-52E95849BB4A@edvina.net> In-Reply-To: <55D26D7B-59E5-4299-8692-52E95849BB4A@edvina.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+JvjW6lhkawwYoPIhYvVx9ituhe+p/F 4sPaC2wOzB7T1q5k9Viy5CeTx7oP5gHMUVw2Kak5mWWpRfp2CVwZX04GFZziqHixYTZLA+M9 ti5GTg4JAROJltt3oGwxiQv31gPZXBxCAocYJV63nmGBcNYwStxu2w2U4eDgFdCWmHVLGcRk EVCV+DrbGqSXTcBCYsut+ywgtqhAlMTPKwvYQWxeAUGJkzOfgMVFBDQkLny5AraLWcBJ4tX+ FkYQWxjI/r79EFi9kEC0xJRHJ8BsTgE7ie7VV9hBVkkIiEv0NAZBtOpJTLkK0cosIC+x/e0c ZohWbYnlz1pYJjAKzUKyeRaSlllIWhYwMq9iZM9NzMxJLzfcxAgM24NbfuvuYDx1TuQQozQH i5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNsevNdbGXG5RUDL4pbgMr+PtgVx jHUMhSsNVpfX8sQ90ljN79u+KmXOmxjdRIYJUcLm13KiQ76cnKpf4y8sfvTr/kOZ9tIsd9+3 RCqWndl6wV3Qtk9fIzLi1GH2X89c3t5PWfEg+n7KJdWLhTEGWz98Wl58+bpmr1rXg31bztbc v/PGpb2mT4mlOCPRUIu5qDgRAHAYMXYpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tram/k5vtNAaTEhajZGsPT9P9Jf83sKk Cc: Simon Perreault , tram@ietf.org Subject: Re: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 18 Mar 2014 11:05:44 -0000 Hi Olle, exactly, adopting the draft does not mean that its content is cast in stone. It means that change control passes from the authors to the WG, which will discuss all relevant issues before requesting its publication, as usual. Cheers, Gonzalo On 18/03/2014 1:00 PM, Olle E. Johansson wrote: > > On 18 Mar 2014, at 11:56, Gonzalo Camarillo wrote: > >> Hi, >> >> from the draft minutes of meeting: >> >>> * draft-petithuguenin-tram-stun-dtls >>> Discussions led by Marc Petit-Huguenin >>> >>> There was a strong consensus in the room to adopt this draft as a WG >>> item for the miletone about adding DTLS as a transport for STUN/TURN. >> >> We would like to confirm this decision on the list. So, if you have any >> comments, please share them with the group. > > My only comment was that we might want to look into using DANE > as an alternative here. There was another discussion about not validating > the certificate at all. > > I think we should happily adopt this draft and discuss these issues. > > /O > From nobody Tue Mar 18 05:45:28 2014 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 89AEC1A03D7 for ; Tue, 18 Mar 2014 05:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 U-0YACq2pYz2 for ; Tue, 18 Mar 2014 05:45:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 726181A03D3 for ; Tue, 18 Mar 2014 05:45:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C131A47381 for ; Tue, 18 Mar 2014 12:45:14 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A971647373 for ; Tue, 18 Mar 2014 12:45:14 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 6354A80062 for ; Tue, 18 Mar 2014 12:45:14 +0000 (GMT) Message-ID: <53283FD9.3040303@akamai.com> Date: Tue, 18 Mar 2014 08:45:13 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <53282645.70309@ericsson.com> In-Reply-To: <53282645.70309@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2cz4Mt-MX_xIt-Gmf4hL_sGizJg Subject: Re: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 18 Mar 2014 12:45:25 -0000 +1 On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote: > Hi, > > from the draft minutes of meeting: > >> * draft-petithuguenin-tram-stun-dtls >> Discussions led by Marc Petit-Huguenin >> >> There was a strong consensus in the room to adopt this draft as a WG >> item for the miletone about adding DTLS as a transport for STUN/TURN. > > We would like to confirm this decision on the list. So, if you have any > comments, please share them with the group. > > Cheers, > > Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Mar 18 05:45:47 2014 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 385471A03D7 for ; Tue, 18 Mar 2014 05:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 jVjO-Ki9BXVl for ; Tue, 18 Mar 2014 05:45:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id EE53F1A03D3 for ; Tue, 18 Mar 2014 05:45:36 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 76709284FA for ; Tue, 18 Mar 2014 12:45:28 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 64B68284F1 for ; Tue, 18 Mar 2014 12:45:28 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 41B13204B for ; Tue, 18 Mar 2014 12:45:28 +0000 (GMT) Message-ID: <53283FE6.2050809@akamai.com> Date: Tue, 18 Mar 2014 08:45:26 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <5328269A.6080907@ericsson.com> In-Reply-To: <5328269A.6080907@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wLn-LXM2eyXFgmOp76E3eI84860 Subject: Re: [tram] Adoption of draft-reddy-behave-turn-auth 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, 18 Mar 2014 12:45:40 -0000 +1 On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote: > Hi, > > from the draft minutes of meeting: > >> * draft-reddy-behave-turn-auth >> Discussions led by Justin Uberti >> >> There was a strong consensus in the room to adopt this draft as a WG >> item for the miletone about analysing the problems with current TURN >> authentication. Additionaly, the relevant milestone will updated to >> reflect the fact that the eventual RFC will be Informational. > > We would like to confirm this decision on the list. So, if you have any > comments, please share them with the group. Additionally, we (the > chairs) will update the milestone to indicate that it is about an > Informational document. > > Cheers, > > Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Mar 18 07:23:10 2014 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 AD37F1A0248 for ; Tue, 18 Mar 2014 07:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 os0FKpwSUOVP for ; Tue, 18 Mar 2014 07:23:06 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2681A02F9 for ; Tue, 18 Mar 2014 07:23:06 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so3744446wiw.12 for ; Tue, 18 Mar 2014 07:22:58 -0700 (PDT) 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=g+Zvp699Gzy6N4D7CWHcVAI0yn23iUEbp3T4Eq91Nmg=; b=jYWr6w07bYu+tqxH1huz2Ru3PqItivJRsCCsCfnYhzNGWilNjVb8if1aNavsKtR8y0 eFmf/AYS8WvFlptTkod+TWNR7JOCczp1/ZBN8L2dnj+0UwZgdfG/rcP4Lm9qwOBhODKH MoZQNAdaWsijT0x3RkIKGcc8kGzxqxPLe2nRUtILeLjKFQlNOUfgKBMwUBDkcTozdTY4 HhdTd54DCmPbdGfQOxzO7DdiIjCZf8LACWHMbuXBZ62frb8sbr55UaYxKMnCNfjOy9fc 0I9DU1EbsZEfOY16TRRk8/8qnyG0F5nmtNcVy1UyCR/5zHf6ZkWSpmemG5uly1d2Et9c dauw== MIME-Version: 1.0 X-Received: by 10.180.19.138 with SMTP id f10mr14640274wie.11.1395152577943; Tue, 18 Mar 2014 07:22:57 -0700 (PDT) Received: by 10.194.110.166 with HTTP; Tue, 18 Mar 2014 07:22:57 -0700 (PDT) In-Reply-To: <53283FE6.2050809@akamai.com> References: <5328269A.6080907@ericsson.com> <53283FE6.2050809@akamai.com> Date: Tue, 18 Mar 2014 19:52:57 +0530 Message-ID: From: Suhas Nandakumar To: Brandon Williams Content-Type: multipart/alternative; boundary=bcaec53d550dd0de6204f4e2454d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FjPKw3lS6Hs3Idd2HghiK0_jsCY Cc: tram@ietf.org Subject: Re: [tram] Adoption of draft-reddy-behave-turn-auth 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, 18 Mar 2014 14:23:08 -0000 --bcaec53d550dd0de6204f4e2454d Content-Type: text/plain; charset=ISO-8859-1 + 1 On Tue, Mar 18, 2014 at 6:15 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > +1 > > > On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> from the draft minutes of meeting: >> >> * draft-reddy-behave-turn-auth >>> Discussions led by Justin Uberti >>> >>> There was a strong consensus in the room to adopt this draft as a WG >>> item for the miletone about analysing the problems with current TURN >>> authentication. Additionaly, the relevant milestone will updated to >>> reflect the fact that the eventual RFC will be Informational. >>> >> >> We would like to confirm this decision on the list. So, if you have any >> comments, please share them with the group. Additionally, we (the >> chairs) will update the milestone to indicate that it is about an >> Informational document. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --bcaec53d550dd0de6204f4e2454d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+ 1


On Tue, Mar 18, 2014 at 6:15 PM, Brandon Williams <= brandon.williams@akamai.com> wrote:
+1

On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote:
Hi,

from the draft minutes of meeting:

* draft-reddy-behave-turn-auth
Discussions led by Justin Uberti

There was a strong consensus in the room to adopt this draft as a WG
item for the miletone about analysing the problems with current TURN
authentication. Additionaly, the relevant milestone will updated to
reflect the fact that the eventual RFC will be Informational.

We would like to confirm this decision on the list. So, if you have any
comments, please share them with the group. Additionally, we (the
chairs) will update the milestone to indicate that it is about an
Informational document.

Cheers,

Gonzalo

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--bcaec53d550dd0de6204f4e2454d-- From nobody Tue Mar 18 07:36:09 2014 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 56DAA1A04BA for ; Tue, 18 Mar 2014 07:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 J_To3ZvJRmFt for ; Tue, 18 Mar 2014 07:36:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4129C1A0481 for ; Tue, 18 Mar 2014 07:36:05 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C848640D17 for ; Tue, 18 Mar 2014 10:35:56 -0400 (EDT) Message-ID: <532859CC.9030307@viagenie.ca> Date: Tue, 18 Mar 2014 10:35:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/k5Rhev3DEhTyR6DbB7KuFXGqnTk Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 14:36:07 -0000 Le 2014-03-18 06:13, Tirumaleswar Reddy (tireddy) a écrit : > My initial comments > > 1) Introduction > > Secondly, with fewer local host ports there will be fewer NAT bindings for the NAT to keep track of, and fewer server reflexive candidates. > > Comment> > This benefits IPv4 only hosts and the above sentence may not be applicable for dual-stack hosts. With IPv6 there will no NAT or even with NPTv6 it's just 1:1 mapping. The statement would also apply to IPv6 hosts behind stateful IPv6 firewalls. I, for one, am behind such a firewall at work (actually two layers of stateful IPv6 firewalls). And NAT64... > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use single ALLOCATE request to learn both relayed and server-reflexive addresses for both families. This is true, but if I'm not mistaken, and please correct me if I'm wrong, in ICE you can not use a single TURN connection for creating both a server-reflexive and a relayed candidate. Each candidate needs its own socket. If that is correct then SSODA is no worse and no better than the status quo in this regard. > Additional details when client should use this mechanism will be helpful. > > 2) If the Allocate Response contains only one XOR-RELAYED-ADDRESS > attribute, then the client knows that the TURN server does not > support SSODA. The client can retry the missing address family > allocations on new 5-tuples, if desired. Subsequent Allocate > requests towards the same TURN server SHOULD NOT include multiple > REQUESTED-ADDRESS-FAMILY attributes > > Comment> > How will the client ever know that the server has upgraded and now supports the new mechanism proposed in the draft ? > May be the client once in a day can probe and find if the server supports multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. Good observation. IMHO that last sentence is not necessary for interoperability. Let client implementers figure it out. > 4) How does this mechanism reduce the number of candidates gathered during the discovery process ? It does not. That's not the goal. The goal is being able to obtain two candidates (IPv4 and IPv6 relayed candidates) using a single socket. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 11:51:15 2014 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 A89141A044C for ; Tue, 18 Mar 2014 11:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2jdrTn0CMYE for ; Tue, 18 Mar 2014 11:51:13 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2051A040E for ; Tue, 18 Mar 2014 11:51:13 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r10so7471726pdi.16 for ; Tue, 18 Mar 2014 11:51:05 -0700 (PDT) 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=UyH7AgP2GqLmMd6q8buPoZluoef2lHxRm7HPJoD5nso=; b=jNQrNmH0NRPXsatNtpzqoX0BbEwhidReFb3pGjmfE4QJWDRHzghh4UMajutKeUJG8w Pc/ndPjwADgEZW0W49yjEbsScjQ4Z4mybQgNbOBdwfM6+52z3agiajcuyOlWJQSP6thH WZEl1WPV7Hqj4hjCzSAazx6gkHQi8KNXhgdTRsWhksDJ1qWxeGjvqhsVqu5E5PCRlYkO dbvgeAzmoVvt0G9x+6O7jGi2cLy3wqjbWDQXoS71XrT5H4hYQTGxrHWsq3a7zLPMgJ4J AeWj8BsOmhkrkvbFCJtTEj7n1+uN0R+Mdzcv83eg8tscqL1XvsD2qwqR5L//4fllIGs9 NxzA== MIME-Version: 1.0 X-Received: by 10.66.142.233 with SMTP id rz9mr34946947pab.71.1395168664864; Tue, 18 Mar 2014 11:51:04 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 11:51:04 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> Date: Tue, 18 Mar 2014 11:51:04 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11344808abcecb04f4e604df Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4DGKem6gmoHzqsLrV6XVjO4PWgA Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 18:51:14 -0000 --001a11344808abcecb04f4e604df Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru please see below: On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > 2) If the Allocate Response contains only one XOR-RELAYED-ADDRESS > attribute, then the client knows that the TURN server does not > support SSODA. The client can retry the missing address family > allocations on new 5-tuples, if desired. Subsequent Allocate > requests towards the same TURN server SHOULD NOT include multiple > REQUESTED-ADDRESS-FAMILY attributes > > Comment> > How will the client ever know that the server has upgraded and now > supports the new mechanism proposed in the draft ? > May be the client once in a day can probe and find if the server supports > multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. > I guess so > > 3) Security Considerations section is missing. (Section 2.2 is assuming > client has already authenticated) > I suppose that this document does not introduce any new security concerns (besides the ones we already have about TURN in general) > > 5) Section 2.3 > > The allocated non-ANY address can be used, but the client > SHOULD NOT try to allocate any of the unsupported families on a > different 5-tuple. > > Comment> I guess the above line does not hold good for errors like > "Insufficient capacity". > > Do you mean a use case when one family relay address can be allocated - but the other one can't - due to the exhaustion of capacity of that single address family ? That's true. But we do know that that address family cannot be allocated at the moment. So, I'd change the text to: ======================================= The allocated non-ANY address can be used, but the client SHOULD NOT try to allocate any of the unsupported families on a different 5-tuple within the subsequent 600 seconds interval. After that interval, the allocation can be re-tried. ======================================= Agree ? Thanks Oleg --001a11344808abcecb04f4e604df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

please see below:
<= div class=3D"gmail_extra">

On Tue, Mar 18= , 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>= wrote:

2) =A0If the Allocate Response contains only one XOR-RELAYED-ADDRESS
=A0 =A0attribute, then the client knows that the TURN server does not
=A0 =A0support SSODA. =A0The client can retry the missing address family =A0 =A0allocations on new 5-tuples, if desired. =A0Subsequent Allocate
=A0 =A0requests towards the same TURN server SHOULD NOT include multiple =A0 =A0REQUESTED-ADDRESS-FAMILY attributes

Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.

I guess so
=A0

3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)

I suppos= e that this document does not introduce any new security concerns (besides = the ones we already have about TURN in general)
=A0

5) Section 2.3

=A0 The allocated non-ANY address can be used, but the client
=A0 =A0SHOULD NOT try to allocate any of the unsupported families on a
=A0 =A0different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".


Do you mean a u= se case when one family relay address can be allocated - but the other one = can't - due to the exhaustion of capacity of that single address family= ? That's true. But we do know that that address family cannot be alloc= ated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY a= ddress can be used, but the client SHOULD NOT try to allocate any of the un= supported families on a different 5-tuple within the subsequent 600 seconds= interval. After that interval, the allocation can be re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

Thanks
Oleg
<= br>
--001a11344808abcecb04f4e604df-- From nobody Tue Mar 18 13:20:21 2014 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 CA9771A0417 for ; Tue, 18 Mar 2014 13:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8uBgqpM0ZUi for ; Tue, 18 Mar 2014 13:20:16 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBA31A030A for ; Tue, 18 Mar 2014 13:20:16 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so7794652pbc.34 for ; Tue, 18 Mar 2014 13:20:08 -0700 (PDT) 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=OuxhkpZHTOfD8k6IL1MmWirwrmvMLMpbkx3ys/AOItU=; b=HABXgJy5LTe1cpUR+0ZpI13MsyuRLnep3hR3IP1bu3q9SK0ksKrivLkOZtnf3pc+uW fLDUf4Gzs2QGyDK3kuZLYsuA7/v/Nt9qlMsf5gPKvsnaySkiZu4QKhHsh81h2eDwxiHS MaX18qS1xdmO0JTMj63Dp5jW0kob3UXN+DDqqTPPJJ+AeAspDKDPfBqMQqcKSiTstl+q m+D2zaLHqRPkJav+plq/SZ8nZ/g/keDS/YI7+9FmNajjE4cANT9eGqQqNv8IsZr+QB2k ZOWjVeivRqBMCOis1uqYuYCEZK69iuKZKGE7t9ruJJiEwZofN0feL7BftEw0huYmW8l2 8Bsw== MIME-Version: 1.0 X-Received: by 10.66.228.37 with SMTP id sf5mr34722833pac.19.1395174008017; Tue, 18 Mar 2014 13:20:08 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 13:20:07 -0700 (PDT) In-Reply-To: <532859CC.9030307@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> Date: Tue, 18 Mar 2014 13:20:07 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b111dd925df0204f4e743fa Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tp2tLwu_pcexQTfrleZCbCcwQrM Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 20:20:19 -0000 --047d7b111dd925df0204f4e743fa Content-Type: text/plain; charset=ISO-8859-1 Simon, please see below On Tue, Mar 18, 2014 at 7:35 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > > > > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use single > ALLOCATE request to learn both relayed and server-reflexive addresses for > both families. > > This is true, but if I'm not mistaken, and please correct me if I'm > wrong, in ICE you can not use a single TURN connection for creating both > a server-reflexive and a relayed candidate. Each candidate needs its own > socket. If that is correct then SSODA is no worse and no better than the > status quo in this regard. > idates gathered during the discovery process ? > > Strictly speaking, a single client-side UDP socket can be used for both purposes. When the client receives ALLOCATE response, it learns both the reflexive address and the relayed address. This is from RFC 5766, about ALLOCATE response content: - An XOR-MAPPED-ADDRESS attribute containing the client's IP address and port (from the 5-tuple). NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response as a convenience to the client. TURN itself does not make use of this value, but clients running ICE can often need this value and can thus avoid having to do an extra Binding transaction with some STUN server to learn it. When TCP is used then I am not sure that the same client socket / port can be used for the dual purpose without some extra efforts. But with UDP we indeed learn both candidates with single ALLOCATE request. So, with single ALLOCATE request we are getting three candidates: - reflexive candidate (whatever address family it belongs to); - IPv4 relayed address; - IPv6 relayed address. Thanks Oleg --047d7b111dd925df0204f4e743fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Simon, please see below


On Tue, Mar 18, 2014 at 7:35 AM, Simon = Perreault <simon.perreault@viagenie.ca> wrote:


> Dual-stack host let's say behind both NAT44 and NPTv6, cannot use = single ALLOCATE request to learn both relayed and server-reflexive addresse= s for both families.

This is true, but if I'm not mistaken, and please correct me if I= 'm
wrong, in ICE you can not use a single TURN connection for creating both a server-reflexive and a relayed candidate. Each candidate needs its own socket. If that is correct then SSODA is no worse and no better than the status quo in this regard.
idates gathered during the discovery process ?

=A0
Strictly speaking, a single client-side UDP = socket can be used for both purposes. When the client receives ALLOCATE res= ponse, it learns both the reflexive address and the relayed address. This i= s from RFC 5766, about ALLOCATE response content:

      - An XOR-MAPPED-ADDRESS attribute cont=
aining the client's IP address
      and port (from the 5-tuple).

      NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response
      as a convenience to the client.  TURN itself does not make use of
      this value, but clients running ICE can often need this value and
      can thus avoid having to do an extra Binding transaction with some
      STUN server to learn it.
=A0When TCP is used then I am not sure = that the same client socket / port can be used for the dual purpose without= some extra efforts. But with UDP we indeed learn both candidates with sing= le ALLOCATE request. So, with single ALLOCATE request we are getting three = candidates:

=A0- reflexive candidate (whatever address family it belongs= to);
=A0- IPv4 relayed address;
=A0- IPv6 rela= yed address.


Thanks
Oleg

--047d7b111dd925df0204f4e743fa-- From nobody Tue Mar 18 13:23:00 2014 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 097F81A01A5 for ; Tue, 18 Mar 2014 13:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 I7IRclhSKusM for ; Tue, 18 Mar 2014 13:22:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D64B41A030A for ; Tue, 18 Mar 2014 13:22:54 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4492040233; Tue, 18 Mar 2014 16:22:46 -0400 (EDT) Message-ID: <5328AB15.8000306@viagenie.ca> Date: Tue, 18 Mar 2014 16:22:45 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WlQzDJ7OdVRTi-pE6IdjKbE3PSU Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 20:22:58 -0000 Le 2014-03-18 16:20, Oleg Moskalenko a écrit : > > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use > single ALLOCATE request to learn both relayed and server-reflexive > addresses for both families. > > This is true, but if I'm not mistaken, and please correct me if I'm > wrong, in ICE you can not use a single TURN connection for creating both > a server-reflexive and a relayed candidate. Each candidate needs its own > socket. If that is correct then SSODA is no worse and no better than the > status quo in this regard. > idates gathered during the discovery process ? > > > Strictly speaking, a single client-side UDP socket can be used for both > purposes. When the client receives ALLOCATE response, it learns both the > reflexive address and the relayed address. This is from RFC 5766, about > ALLOCATE response content: > > - An XOR-MAPPED-ADDRESS attribute containing the client's IP address > and port (from the 5-tuple). > > NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response > as a convenience to the client. TURN itself does not make use of > this value, but clients running ICE can often need this value and > can thus avoid having to do an extra Binding transaction with some > STUN server to learn it. I know that TURN allows it. Does *ICE* allow it? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 13:26:02 2014 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 6F8EF1A02FB for ; Tue, 18 Mar 2014 13:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YRxcmDFkiVA for ; Tue, 18 Mar 2014 13:25:59 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A96EC1A01A5 for ; Tue, 18 Mar 2014 13:25:59 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id rd3so7816954pab.25 for ; Tue, 18 Mar 2014 13:25:51 -0700 (PDT) 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=muwzGIXXieJhsXOGdl+Sx2Vcedl6LlIsSNSXrhX7B9M=; b=Dgq9NR4wMrWA52/F5PJ3rDWGSn/4glgiIoJXpQVNMEml1j6e1s2SZjQsYobH2C5Tmq J+svRtmSlwsEt7QwfAAT6hX61xMwF3hhtiCXQXU9sOyq14JZZEscaCsw3QAQ+Fe4FXoh S/ZUArcFuquzpqGg6IzXt0gag+SYKz0snHBaeV3Wxo84yY+CqzvDUnrdXncKejq70War l7d3PLYDWUyo6IsZonbQrHT6PCFuXTkMJVCJwEiFgOuftCB1ldrJiHDaZiH1N4wrxyPw 6cMjDlp6pF0uc5PLOU2yqHzFV8lzm9R4J4FV1xFgM8ar6UuAwHeRVqJCxUkE5rnEm4Kw sAVA== MIME-Version: 1.0 X-Received: by 10.66.148.134 with SMTP id ts6mr35134943pab.113.1395174351417; Tue, 18 Mar 2014 13:25:51 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 13:25:51 -0700 (PDT) In-Reply-To: <5328AB15.8000306@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> Date: Tue, 18 Mar 2014 13:25:51 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b6783009db9a504f4e757b6 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/C0I-t6nhQSyWqk-rgXUEnjugOvQ Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 20:26:01 -0000 --047d7b6783009db9a504f4e757b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure that I understand why ICE must be concerned. From ICE point of view, there are three unrelated different addresses. How ICE knows that those three addresses are coming (eventually) from the same client socket ? I did not get what is the problem. May be, that's more a problem of an ICE implementation, not ICE specs problem ? Then I'd understand that. On Tue, Mar 18, 2014 at 1:22 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-18 16:20, Oleg Moskalenko a =E9crit : > > > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use > > single ALLOCATE request to learn both relayed and server-reflexive > > addresses for both families. > > > > This is true, but if I'm not mistaken, and please correct me if I'm > > wrong, in ICE you can not use a single TURN connection for creating > both > > a server-reflexive and a relayed candidate. Each candidate needs it= s > own > > socket. If that is correct then SSODA is no worse and no better tha= n > the > > status quo in this regard. > > idates gathered during the discovery process ? > > > > > > Strictly speaking, a single client-side UDP socket can be used for both > > purposes. When the client receives ALLOCATE response, it learns both th= e > > reflexive address and the relayed address. This is from RFC 5766, about > > ALLOCATE response content: > > > > - An XOR-MAPPED-ADDRESS attribute containing the client's IP > address > > and port (from the 5-tuple). > > > > NOTE: The XOR-MAPPED-ADDRESS attribute is included in the respons= e > > as a convenience to the client. TURN itself does not make use of > > this value, but clients running ICE can often need this value and > > can thus avoid having to do an extra Binding transaction with som= e > > STUN server to learn it. > > I know that TURN allows it. Does *ICE* allow it? > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b6783009db9a504f4e757b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not sure that I understand why ICE must be concerned.= From ICE point of view, there are three unrelated different addresses. How= ICE knows that those three addresses are coming (eventually) from the same= client socket ? I did not get what is the problem. May be, that's more= a problem of an ICE implementation, not ICE specs problem ? Then I'd u= nderstand that.


=A0


On Tue, Mar 18, 2014 at 1:22 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-18 16:20, Oleg Moskalenko a =E9cr= it :
> =A0 =A0 > Dual-stack host let's say behind bo= th NAT44 and NPTv6, cannot use
> =A0 =A0 single ALLOCATE request to learn both relayed and server-refle= xive
> =A0 =A0 addresses for both families.
>
> =A0 =A0 This is true, but if I'm not mistaken, and please correct = me if I'm
> =A0 =A0 wrong, in ICE you can not use a single TURN connection for cre= ating both
> =A0 =A0 a server-reflexive and a relayed candidate. Each candidate nee= ds its own
> =A0 =A0 socket. If that is correct then SSODA is no worse and no bette= r than the
> =A0 =A0 status quo in this regard.
> =A0 =A0 idates gathered during the discovery process ?
>
>
> Strictly speaking, a single client-side UDP socket can be used for bot= h
> purposes. When the client receives ALLOCATE response, it learns both t= he
> reflexive address and the relayed address. This is from RFC 5766, abou= t
> ALLOCATE response content:
>
> =A0 =A0 =A0 - An XOR-MAPPED-ADDRESS attribute containing the client= 9;s IP address
> =A0 =A0 =A0 and port (from the 5-tuple).
>
> =A0 =A0 =A0 NOTE: The XOR-MAPPED-ADDRESS attribute is included in the = response
> =A0 =A0 =A0 as a convenience to the client. =A0TURN itself does not ma= ke use of
> =A0 =A0 =A0 this value, but clients running ICE can often need this va= lue and
> =A0 =A0 =A0 can thus avoid having to do an extra Binding transaction w= ith some
> =A0 =A0 =A0 STUN server to learn it.

I know that TURN allows it. Does *ICE* allow it?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--047d7b6783009db9a504f4e757b6-- From nobody Tue Mar 18 13:35:52 2014 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 9E81A1A049E for ; Tue, 18 Mar 2014 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 zRCCatE95Wfg for ; Tue, 18 Mar 2014 13:35:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 969651A02FB for ; Tue, 18 Mar 2014 13:35:46 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 16E4A40233; Tue, 18 Mar 2014 16:35:38 -0400 (EDT) Message-ID: <5328AE19.50707@viagenie.ca> Date: Tue, 18 Mar 2014 16:35:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/DfbKLudCYyHqd2o_Hp9jRb1wuSE Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 20:35:49 -0000 Le 2014-03-18 16:25, Oleg Moskalenko a écrit : > I am not sure that I understand why ICE must be concerned. From ICE > point of view, there are three unrelated different addresses. How ICE > knows that those three addresses are coming (eventually) from the same > client socket ? I did not get what is the problem. May be, that's more a > problem of an ICE implementation, not ICE specs problem ? Then I'd > understand that. It seems you're right. From RFC 5245: The agent will receive a Binding or Allocate response. A successful Allocate response will provide the agent with a server reflexive candidate (obtained from the mapped address) and a relayed candidate in the XOR-RELAYED-ADDRESS attribute. So it seems it is already possible without SSODA to have IPv4 and IPv6 server-reflexive and relayed candidates using only two sockets. What is the advantage of SSODA again? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 13:38:23 2014 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 6FE581A06C1 for ; Tue, 18 Mar 2014 13:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQsmefUk0Sc5 for ; Tue, 18 Mar 2014 13:38:17 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 23F461A0655 for ; Tue, 18 Mar 2014 13:38:17 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r10so7589361pdi.21 for ; Tue, 18 Mar 2014 13:38:08 -0700 (PDT) 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=iuUGuJZhsK4xP6PP9F5B5Adt00Wa6lTlFCzQl50z3Ko=; b=OU13QlUfz5Owg6otUoUVOSxz8mSKNyEYiT+4N/porPJrMYiijBR5YTtK1UK+OiAx3f FV66UotfypTMX4MwQG5T2F+uUQT3+AHFv1K5nsH+AeyezNkPgQ9sONZLqxebiQNSQ2Lx efwU6lR8mZ/J2jvIbmxdDX1QUGLVIjJZQn6F0b+Qd1yh89IS8Uxb4LwTe48ImW7gF2me KjaedAiYvQIYAWuebX9Lh+H8ijETMHumdHgZLdC6lpR/6UjrdvtSty+H4YxgMcUaplDJ igMuGWqdK+h0CuRE22pa2oW+jAWjwT3TAQP1joXrTd+X0F7eEKRuXc1dxsNDfPM2sT5+ lHdA== MIME-Version: 1.0 X-Received: by 10.68.217.234 with SMTP id pb10mr12490532pbc.142.1395175087520; Tue, 18 Mar 2014 13:38:07 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 13:38:07 -0700 (PDT) In-Reply-To: <5328AE19.50707@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> Date: Tue, 18 Mar 2014 13:38:07 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b2edaa77e79dd04f4e78310 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/d5xeaVJtDJM01lGumfvYP8rqe3M Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 20:38:19 -0000 --047d7b2edaa77e79dd04f4e78310 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My understanding is that with a single client socket, we are getting three candidates - reflexive, IPv4 relayed, IPv6 relayed. On Tue, Mar 18, 2014 at 1:35 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-18 16:25, Oleg Moskalenko a =E9crit : > > I am not sure that I understand why ICE must be concerned. From ICE > > point of view, there are three unrelated different addresses. How ICE > > knows that those three addresses are coming (eventually) from the same > > client socket ? I did not get what is the problem. May be, that's more = a > > problem of an ICE implementation, not ICE specs problem ? Then I'd > > understand that. > > It seems you're right. From RFC 5245: > > The agent will receive a Binding or Allocate response. A successful > Allocate response will provide the agent with a server reflexive > candidate (obtained from the mapped address) and a relayed candidate > in the XOR-RELAYED-ADDRESS attribute. > > So it seems it is already possible without SSODA to have IPv4 and IPv6 > server-reflexive and relayed candidates using only two sockets. > > What is the advantage of SSODA again? > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b2edaa77e79dd04f4e78310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My understanding is that with a single client socket, we a= re getting three candidates - reflexive, IPv4 relayed, IPv6 relayed.


On Tue, Ma= r 18, 2014 at 1:35 PM, Simon Perreault <simon.perreault@viagenie= .ca> wrote:
Le 2014-03-18 16:25, Oleg Moskalenko a =E9cr= it :
> I am not sure that I understand why ICE must be conc= erned. From ICE
> point of view, there are three unrelated different addresses. How ICE<= br> > knows that those three addresses are coming (eventually) from the same=
> client socket ? I did not get what is the problem. May be, that's = more a
> problem of an ICE implementation, not ICE specs problem ? Then I'd=
> understand that.

It seems you're right. From RFC 5245:

=A0 =A0The agent will receive a Binding or Allocate response. =A0A successf= ul
=A0 =A0Allocate response will provide the agent with a server reflexive
=A0 =A0candidate (obtained from the mapped address) and a relayed candidate=
=A0 =A0in the XOR-RELAYED-ADDRESS attribute.

So it seems it is already possible without SSODA to have IPv4 and IPv6
server-reflexive and relayed candidates using only two sockets.

What is the advantage of SSODA again?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--047d7b2edaa77e79dd04f4e78310-- From nobody Tue Mar 18 13:40:54 2014 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 413CA1A0304 for ; Tue, 18 Mar 2014 13:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 gRkT_S-pDJR0 for ; Tue, 18 Mar 2014 13:40:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8135A1A0417 for ; Tue, 18 Mar 2014 13:40:49 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0752140377; Tue, 18 Mar 2014 16:40:40 -0400 (EDT) Message-ID: <5328AF48.1060605@viagenie.ca> Date: Tue, 18 Mar 2014 16:40:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9Udp-HhKZ7cPIOKZieBnpNVyCNM Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 20:40:51 -0000 Le 2014-03-18 16:38, Oleg Moskalenko a écrit : > My understanding is that with a single client socket, we are getting > three candidates - reflexive, IPv4 relayed, IPv6 relayed. Sure, but what's the point if you still need two sockets to get all four candidates? Simon > On Tue, Mar 18, 2014 at 1:35 PM, Simon Perreault > > wrote: > > Le 2014-03-18 16:25, Oleg Moskalenko a écrit : > > I am not sure that I understand why ICE must be concerned. From ICE > > point of view, there are three unrelated different addresses. How ICE > > knows that those three addresses are coming (eventually) from the same > > client socket ? I did not get what is the problem. May be, that's > more a > > problem of an ICE implementation, not ICE specs problem ? Then I'd > > understand that. > > It seems you're right. From RFC 5245: > > The agent will receive a Binding or Allocate response. A successful > Allocate response will provide the agent with a server reflexive > candidate (obtained from the mapped address) and a relayed candidate > in the XOR-RELAYED-ADDRESS attribute. > > So it seems it is already possible without SSODA to have IPv4 and IPv6 > server-reflexive and relayed candidates using only two sockets. > > What is the advantage of SSODA again? > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 14:05:12 2014 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 DB3111A073C for ; Tue, 18 Mar 2014 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdbFoMjbmEKi for ; Tue, 18 Mar 2014 14:05:07 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 208C81A06E8 for ; Tue, 18 Mar 2014 14:05:04 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so7797261pbb.5 for ; Tue, 18 Mar 2014 14:04:55 -0700 (PDT) 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=ewNrsjwveo0oR0akxKQvv5kyzIJzpYJriYl5/+xwV+E=; b=HaoPTbtxpZ4g10Bg7TejXsQHzi0KPM4gE5s7TTcPJfXIOWfLm+EZuuy+4PC5lJNJmF 3zLjjyyjWCgdLJv6GTL1jPmaTcQ7hzMtywTYZLggzvFqj3n56VgOsUIJXBGzlO6Fqbxn p3dd3tZy1mDTzG922zsWn8BIv9LCPj3uP7KKJb7nrPokC3HncjNgq/o51U6UGscEnxfs +NZvwDEgg/gk4DrFRXokaDrqY8x4gg7m6rBpulyIDKuqX3rfxWxcQoz/28AgbWrb4KiW Te1p75PKIZGlNY35dd1sFajWIiiivNnuot086Prm+mlBjs+Onr+PhiHcjUmKqwpuMABM 50/Q== MIME-Version: 1.0 X-Received: by 10.66.144.227 with SMTP id sp3mr35942699pab.100.1395176695843; Tue, 18 Mar 2014 14:04:55 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 14:04:55 -0700 (PDT) In-Reply-To: <5328AF48.1060605@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> <5328AF48.1060605@viagenie.ca> Date: Tue, 18 Mar 2014 14:04:55 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b6d82705ad10b04f4e7e3e2 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/V0y5_QEhYggKCcN8NzXS2mGztJA Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 21:05:10 -0000 --047d7b6d82705ad10b04f4e7e3e2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Without SSODA, if we want both IPv4 and IPv6 candidates, then we need: 1) two client sockets for two allocations 2) two server sockets for two allocations 3) two relayed sockets for the server relayed endpoints (one per allocation= ) With SSODA: 1) One client socket for one allocation 2) one server socket for one allocation 3) two relayed sockets in single allocation So, this is totally 6 sockets vs 4 sockets with SSODA: 1) 2 sockets vs 1 socket on client 2) 4 sockets vs 3 sockets on server On Tue, Mar 18, 2014 at 1:40 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-18 16:38, Oleg Moskalenko a =E9crit : > > My understanding is that with a single client socket, we are getting > > three candidates - reflexive, IPv4 relayed, IPv6 relayed. > > Sure, but what's the point if you still need two sockets to get all four > candidates? > > Simon > > > On Tue, Mar 18, 2014 at 1:35 PM, Simon Perreault > > > > wrote: > > > > Le 2014-03-18 16:25, Oleg Moskalenko a =E9crit : > > > I am not sure that I understand why ICE must be concerned. From I= CE > > > point of view, there are three unrelated different addresses. How > ICE > > > knows that those three addresses are coming (eventually) from the > same > > > client socket ? I did not get what is the problem. May be, that's > > more a > > > problem of an ICE implementation, not ICE specs problem ? Then I'= d > > > understand that. > > > > It seems you're right. From RFC 5245: > > > > The agent will receive a Binding or Allocate response. A > successful > > Allocate response will provide the agent with a server reflexive > > candidate (obtained from the mapped address) and a relayed > candidate > > in the XOR-RELAYED-ADDRESS attribute. > > > > So it seems it is already possible without SSODA to have IPv4 and > IPv6 > > server-reflexive and relayed candidates using only two sockets. > > > > What is the advantage of SSODA again? > > > > Simon > > -- > > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > > > > > > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b6d82705ad10b04f4e7e3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Without SSODA, if we want both IPv4 an= d IPv6 candidates, then we need:

1) two client sockets for two= allocations
2) two server sockets for two allocations
3) two relayed sockets for the server relayed endpoints (one per allocation= )

With SSODA:

1) One client socket for = one allocation
2) one server socket for one allocation
3) two relayed sockets in single allocation

So= , this is totally 6 sockets vs 4 sockets with SSODA:

1) 2= sockets vs 1 socket on client
2) 4 sockets vs 3 sockets on s= erver







On Tue= , Mar 18, 2014 at 1:40 PM, Simon Perreault <simon.perreault@viag= enie.ca> wrote:
Le 2014-03-18 16:38, Oleg Moskalenko a =E9cr= it :
> My understanding is that with a single client socket= , we are getting
> three candidates - reflexive, IPv4 relayed, IPv6 relayed.

Sure, but what's the point if you still need two sockets to get a= ll four
candidates?

Simon

> On Tue, Mar 18, 2014 at 1:35 PM, Simon Perreault
> <simon.perreault@viagenie.ca <mailto:simon.perreault@viagenie.ca&g= t;> wrote:
>
> =A0 =A0 Le 2014-03-18 16:25, Oleg Moskalenko a =E9crit :
> =A0 =A0 > I am not sure that I understand why ICE must be concerned= . From ICE
> =A0 =A0 > point of view, there are three unrelated different addres= ses. How ICE
> =A0 =A0 > knows that those three addresses are coming (eventually) = from the same
> =A0 =A0 > client socket ? I did not get what is the problem. May be= , that's
> =A0 =A0 more a
> =A0 =A0 > problem of an ICE implementation, not ICE specs problem ?= Then I'd
> =A0 =A0 > understand that.
>
> =A0 =A0 It seems you're right. From RFC 5245:
>
> =A0 =A0 =A0 =A0The agent will receive a Binding or Allocate response. = =A0A successful
> =A0 =A0 =A0 =A0Allocate response will provide the agent with a server = reflexive
> =A0 =A0 =A0 =A0candidate (obtained from the mapped address) and a rela= yed candidate
> =A0 =A0 =A0 =A0in the XOR-RELAYED-ADDRESS attribute.
>
> =A0 =A0 So it seems it is already possible without SSODA to have IPv4 = and IPv6
> =A0 =A0 server-reflexive and relayed candidates using only two sockets= .
>
> =A0 =A0 What is the advantage of SSODA again?
>
> =A0 =A0 Simon
> =A0 =A0 --
> =A0 =A0 DTN made easy, lean, and smart --> http://postellation.viagenie.ca > =A0 =A0 NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
> =A0 =A0 STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
>
>


--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--047d7b6d82705ad10b04f4e7e3e2-- From nobody Tue Mar 18 14:08:58 2014 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 9E7CC1A0421 for ; Tue, 18 Mar 2014 14:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 XXjjg2htGycO for ; Tue, 18 Mar 2014 14:08:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 98F081A0417 for ; Tue, 18 Mar 2014 14:08:53 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2037340377; Tue, 18 Mar 2014 17:08:45 -0400 (EDT) Message-ID: <5328B5DC.5000702@viagenie.ca> Date: Tue, 18 Mar 2014 17:08:44 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> <5328AF48.1060605@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oe6tC_1m7l7jQiwZtavY7xgTThk Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 21:08:56 -0000 Le 2014-03-18 17:04, Oleg Moskalenko a écrit : > Without SSODA, if we want both IPv4 and IPv6 candidates, then we need: > > 1) two client sockets for two allocations > 2) two server sockets for two allocations > 3) two relayed sockets for the server relayed endpoints (one per allocation) > > With SSODA: > > 1) One client socket for one allocation > 2) one server socket for one allocation > 3) two relayed sockets in single allocation > > So, this is totally 6 sockets vs 4 sockets with SSODA: > > 1) 2 sockets vs 1 socket on client > 2) 4 sockets vs 3 sockets on server Aren't you missing one server-reflexive candidate in your "with SSODA" scenario? I'm assuming you want dual-stack server-reflexive and dual-stack relayed candidates. If that assumption doesn't hold, please explain why. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 14:20:10 2014 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 863981A030C for ; Tue, 18 Mar 2014 14:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEPx1mJxxXfT for ; Tue, 18 Mar 2014 14:20:04 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8281A01A5 for ; Tue, 18 Mar 2014 14:20:03 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p10so7642884pdj.12 for ; Tue, 18 Mar 2014 14:19:55 -0700 (PDT) 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=DQJn+uHcusg8/AuYyssM+vonqqEiASGdu5mnzWiBEuU=; b=ljoYSQyeqlf74k+UP+IzF+N4v19Ft4VdjWP05w+z9M56MYcKenfyyRRq34kG+WSCCO sFBGc6/4qNKO5VgxcvF7LKO6M68K9xbZRBRIQxxZj4g/pq8/Qiyk4tn0rbJ1B/B6V8gf v2o2EPZOYOk8avLY+MkUARzO86QoBnkfBYyfXXNGXnn5skISyNuasRe4wWkqBgwcR/gj 6+gcHJ9aWS4G+GHefe0pbkgkdvrRjYhCSmfIJlHaoYnq13HmDUDfjAlq7u4b8cu+v5bQ OG3cOJK29HqsB/AwuizgTink9tzLxEIklzgLI7Mtrtddgj3p5yOGnVi0Tv1a7jM4/nF7 Lu9A== MIME-Version: 1.0 X-Received: by 10.66.144.227 with SMTP id sp3mr36009380pab.100.1395177595679; Tue, 18 Mar 2014 14:19:55 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 14:19:55 -0700 (PDT) In-Reply-To: <5328B5DC.5000702@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> <5328AF48.1060605@viagenie.ca> <5328B5DC.5000702@viagenie.ca> Date: Tue, 18 Mar 2014 14:19:55 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b6d8270fd591b04f4e81828 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/O2eRQSsyJZomzPXuOtmaJ7BlaDw Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 18 Mar 2014 21:20:05 -0000 --047d7b6d8270fd591b04f4e81828 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we do want two server-reflexive candidates (both IPv4 and IPv6) then you are right, two client sockets are involved. One client socket will have a TURN allocation session (with dual relay candidates) and another will be just a reflexive candidate obtained by STUN BINDING request. We still have some noticeable optimization because we need only one TURN allocation dialog (plus STUN stateless request for the second address family candidate). So we still are consuming less resources, because a TURN allocation is a much heavier thing than a STUN stateless request-response. Oleg On Tue, Mar 18, 2014 at 2:08 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-18 17:04, Oleg Moskalenko a =E9crit : > > Without SSODA, if we want both IPv4 and IPv6 candidates, then we need: > > > > 1) two client sockets for two allocations > > 2) two server sockets for two allocations > > 3) two relayed sockets for the server relayed endpoints (one per > allocation) > > > > With SSODA: > > > > 1) One client socket for one allocation > > 2) one server socket for one allocation > > 3) two relayed sockets in single allocation > > > > So, this is totally 6 sockets vs 4 sockets with SSODA: > > > > 1) 2 sockets vs 1 socket on client > > 2) 4 sockets vs 3 sockets on server > > Aren't you missing one server-reflexive candidate in your "with SSODA" > scenario? > > I'm assuming you want dual-stack server-reflexive and dual-stack relayed > candidates. If that assumption doesn't hold, please explain why. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b6d8270fd591b04f4e81828 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we do want two server-reflexive candidates (b= oth IPv4 and IPv6) then you are right, two client sockets are involved. One= client socket will have a TURN allocation session (with dual relay candida= tes) and another will be just a reflexive candidate obtained by STUN BINDIN= G request.

We still have some noticeable optimization because we need only o= ne TURN allocation dialog (plus STUN stateless request for the second addre= ss family candidate). So we still are consuming less resources, because a T= URN allocation is a much heavier thing than a STUN stateless request-respon= se.

Oleg



On Tue, Mar 18, 2014 at 2:08 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-03-18 17:04, Oleg Moskalenko a =E9cr= it :
> Without SSODA, if we want both IPv4 and IPv6 candida= tes, then we need:
>
> 1) two client sockets for two allocations
> 2) two server sockets for two allocations
> 3) two relayed sockets for the server relayed endpoints (one per alloc= ation)
>
> With SSODA:
>
> 1) One client socket for one allocation
> 2) one server socket for one allocation
> 3) two relayed sockets in single allocation
>
> So, this is totally 6 sockets vs 4 sockets with SSODA:
>
> 1) 2 sockets vs 1 socket on client
> 2) 4 sockets vs 3 sockets on server

Aren't you missing one server-reflexive candidate in your "w= ith SSODA"
scenario?

I'm assuming you want dual-stack server-reflexive and dual-stack relaye= d
candidates. If that assumption doesn't hold, please explain why.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--047d7b6d8270fd591b04f4e81828-- From nobody Tue Mar 18 20:37:45 2014 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 577EA1A04A3 for ; Tue, 18 Mar 2014 20:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 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.547, 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 InfKWAiPp9V9 for ; Tue, 18 Mar 2014 20:37:39 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C73E51A043E for ; Tue, 18 Mar 2014 20:37:38 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so8566243vcb.13 for ; Tue, 18 Mar 2014 20:37:30 -0700 (PDT) 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=y48Pi94dSmB2xO46IRNWBnsSO6lbs30LEd8BD7GMK5k=; b=Y+HRneXB1F9ULxJo9u0uKejWAMQ0hh8t+0oE2mriG7O5sEW1BCTfnNmnPBWELUpwxc rNaEPn6qU0uGVUc7jHIX1iCy0ApuIMJHG0/V9+BKir1L7FcKr83S8cbgy8/pygbiSUoo U3JKamhl5rO7gZMiJgPh7OkqcsAuKG5H6jJaiybhIB0z4RVf+MtYTXBDxFE0RzHy+IY5 KOOXs0RlJWrtN0UqCKm0t1mybTsFelMQMotoPNHWQoqcgqOb29F2GZrHL38mF7/abiQc aFNsjj4CitVfpW6yM/Q4z9RjEZJ+JgVmMCQ6Ms82+d57VyT7d3aYTnfeJluoyhQifC0N gO6A== 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=y48Pi94dSmB2xO46IRNWBnsSO6lbs30LEd8BD7GMK5k=; b=UPnWpK0Jy3IRSYXd1deIsD9duIY0c7qoDy+q+dD9xrtr6p/2vpI8+YbrOiZRdEZqpG /+/6om4f787mn5eL2/lZAVc+iyIMX+RpU0eIY098HNO5vtmHrb0idGTMfnjwJzAmBN1V RESGqirlGpRZu05IFGKV5DBtB4oFkiHsD86PnTzjh9yLmT92JCIqpppDZxpbSYXnXS+C ph2+SQE3HGNS8MXD/3yfkNalgkDjKFCgkm/Cypt7sH6OzvM38+SpzPZ7Iz/iO392akxT dvcT78E8M1v82WSauh2DjsXppHfP7VyV3Ca0AhyjzxYeFJCLSgseLRaRJiwkz98pNP7b 93Bw== X-Gm-Message-State: ALoCoQlpI4a/9R/9Ill/10SRobQmZr2TPb/QeKwt5U7wCrOi2ml6p9bw0EvdcL43BWx9z4Xht2zKcJhUiWW5+adAsi/zMqV2DMA7e5sk7vkF7AmJ+WNr+lFRhOVE8pwjhwcNoJUdaZk31DOxK7XeWXXC5M+9eabgdx/qNUffx4vGj+6Mu0VYyVR8+voLPnCr17/Ic6iTp6dG X-Received: by 10.58.207.74 with SMTP id lu10mr27591251vec.15.1395200250009; Tue, 18 Mar 2014 20:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 18 Mar 2014 20:37:09 -0700 (PDT) In-Reply-To: References: <5328269A.6080907@ericsson.com> <53283FE6.2050809@akamai.com> From: Justin Uberti Date: Tue, 18 Mar 2014 20:37:09 -0700 Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=047d7b6783ce4af38e04f4ed5f0d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZiXw9jr3mx6jBpVa4uEhRMbCZDU Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Adoption of draft-reddy-behave-turn-auth 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, 19 Mar 2014 03:37:41 -0000 --047d7b6783ce4af38e04f4ed5f0d Content-Type: text/plain; charset=UTF-8 +1 On Tue, Mar 18, 2014 at 7:22 AM, Suhas Nandakumar wrote: > + 1 > > > On Tue, Mar 18, 2014 at 6:15 PM, Brandon Williams < > brandon.williams@akamai.com> wrote: > >> +1 >> >> >> On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote: >> >>> Hi, >>> >>> from the draft minutes of meeting: >>> >>> * draft-reddy-behave-turn-auth >>>> Discussions led by Justin Uberti >>>> >>>> There was a strong consensus in the room to adopt this draft as a WG >>>> item for the miletone about analysing the problems with current TURN >>>> authentication. Additionaly, the relevant milestone will updated to >>>> reflect the fact that the eventual RFC will be Informational. >>>> >>> >>> We would like to confirm this decision on the list. So, if you have any >>> comments, please share them with the group. Additionally, we (the >>> chairs) will update the milestone to indicate that it is about an >>> Informational document. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b6783ce4af38e04f4ed5f0d Content-Type: text/html; charset=UTF-8
+1


On Tue, Mar 18, 2014 at 7:22 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
+ 1


On Tue, Mar 18, 2014 at 6:15 PM, Brandon Williams <brandon.williams@akamai.com> wrote:
+1


On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote:
Hi,

from the draft minutes of meeting:

* draft-reddy-behave-turn-auth
Discussions led by Justin Uberti

There was a strong consensus in the room to adopt this draft as a WG
item for the miletone about analysing the problems with current TURN
authentication. Additionaly, the relevant milestone will updated to
reflect the fact that the eventual RFC will be Informational.

We would like to confirm this decision on the list. So, if you have any
comments, please share them with the group. Additionally, we (the
chairs) will update the milestone to indicate that it is about an
Informational document.

Cheers,

Gonzalo

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


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


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


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


--047d7b6783ce4af38e04f4ed5f0d-- From nobody Tue Mar 18 20:38:00 2014 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 48A4D1A04A3 for ; Tue, 18 Mar 2014 20:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 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.547, 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 sFgtu7t4s42J for ; Tue, 18 Mar 2014 20:37:55 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 549B11A0357 for ; Tue, 18 Mar 2014 20:37:55 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz12so7986670veb.7 for ; Tue, 18 Mar 2014 20:37:46 -0700 (PDT) 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=kj/yCw1CA3q3QaVr47S2hlyxBTFFW485vrgj7So37mQ=; b=P2St+QqY4FhUXQF+7qGfa0tc4315CET5kg7LaCFKF0lK9O+jXIlb3Lksh1gi6DvqMw e5uVrXQS+YkZF+VGFy76L1b9zAvY3qE1xlQRqKBXpqyt7MeDvMR9PulO/I12T9Dx54pz GQS4Jr/+JZbv6nr1eUnxbxLgUTae2WnaQjXkoJI3ySeCRJaCUKxI65FuDl4Y5TzQtkwA wGKCMsyeDB9Khp9w6rXUcT7BFQmRCLgPEGI2kpcSd7gjtWZka4SP0WRrl68Wq7QwYRLC Ty0e6kczjGoWsG0AlrjlgVRKA+Dfz9Wa6IXY8rBsl4o6xoxz3sNHAtAAlp/095wQtb3A z7Nw== 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=kj/yCw1CA3q3QaVr47S2hlyxBTFFW485vrgj7So37mQ=; b=mogKrjLGHPamMEN2oyK+Qu6F4z43HKDetntAHspvomb+6YCAvgKYS3R+wYL2nN1ZVT 4w++pop9aBLuaAC9H+apqhPoKtadhkOQu0yqYXrNT9cEUlV8kaPmI3TgPiSFK7+VevH5 wFK7tOJnXsa4khOIZAhiNCDcJJpZWHyxikMnRXF2rcOcwTR5OKJ1hOrGTAlyKZcj3cK1 uJcSdjZ1BA0zU+L5JXrazGqWNz351KKPihsZxdH7t2Hu8iQHoqvs/l54V5ugSxr1/DyJ TEgMqhTNGDa0mQT0beuMO60vuShhnBci0CTyqkm6fAU72yFMwdSftUEVbN2BOfLs/lEa ZVFQ== X-Gm-Message-State: ALoCoQkRIhDpEB0MAhvVfTC3JzqCwy+Sk56dXszaWzX8cgUTGIcspxhHOxrF9FnQ6t+uiVwN0RIXMA63Grw9U0nDg8u+k6I7Hhepd5VvcTk+ta8lkEmpGLHn6CH2bgTW3DLqiymivOwdLisltbGMHMSsBD3MxEdBPnjUSTm437k6bZX+OvfCWV0HliJcTCq3vXodMpXBR8aN X-Received: by 10.220.10.2 with SMTP id n2mr9766810vcn.26.1395200266611; Tue, 18 Mar 2014 20:37:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Tue, 18 Mar 2014 20:37:24 -0700 (PDT) In-Reply-To: <53283FD9.3040303@akamai.com> References: <53282645.70309@ericsson.com> <53283FD9.3040303@akamai.com> From: Justin Uberti Date: Tue, 18 Mar 2014 20:37:24 -0700 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=001a11c3a92048504b04f4ed60db Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6AotJ9r8JJU0k7r-kOZ_SWUsEfs Cc: "tram@ietf.org" Subject: Re: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 19 Mar 2014 03:37:57 -0000 --001a11c3a92048504b04f4ed60db Content-Type: text/plain; charset=UTF-8 +1 On Tue, Mar 18, 2014 at 5:45 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > +1 > > > On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> from the draft minutes of meeting: >> >> * draft-petithuguenin-tram-stun-dtls >>> Discussions led by Marc Petit-Huguenin >>> >>> There was a strong consensus in the room to adopt this draft as a WG >>> item for the miletone about adding DTLS as a transport for STUN/TURN. >>> >> >> We would like to confirm this decision on the list. So, if you have any >> comments, please share them with the group. >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c3a92048504b04f4ed60db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Tue, Mar 18, 2014 at 5:45 AM, Brandon Williams <b= randon.williams@akamai.com> wrote:
+1

On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote:
Hi,

from the draft minutes of meeting:

* draft-petithuguenin-tram-stun-dtls
Discussions led by Marc Petit-Huguenin

There was a strong consensus in the room to adopt this draft as a WG
item for the miletone about adding DTLS as a transport for STUN/TURN.

We would like to confirm this decision on the list. So, if you have any
comments, please share them with the group.

Cheers,

Gonzalo

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a11c3a92048504b04f4ed60db-- From nobody Tue Mar 18 22:17:26 2014 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 EB6C01A0351 for ; Tue, 18 Mar 2014 22:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4jmkmcdQjCY for ; Tue, 18 Mar 2014 22:17:21 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 425E51A031E for ; Tue, 18 Mar 2014 22:17:21 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so8384007pbb.39 for ; Tue, 18 Mar 2014 22:17:12 -0700 (PDT) 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=HECnh8ALTpCxh8TltnLgorB/zRsQPWqQ+iDrG4UOwHo=; b=Y+tman3BosMyTxGtBeY1TD8Um6xyCKwFcALLiM+59TIleQRRuLOsx5yLyBUs6WplVx 5BPktjPus4p/YNHjTrVe2Y/prI76SlHd1vQco9johiuj9kjZRkUxdXKdmCTsEXSps2s6 sCmW8O5H8phjsotPIdt0OAyD/v1/ePX9zEWmdsGtXxmfqBw/KgNc2hocfLmnXMkRu0Uo 9/QUcL/T4azsy0QS8c4bJHFy9KLhkCLHmvFuP9aHwv8oUZbOaUfh4vzHAC9bvyxT0a/2 h13u2TuTXyGY4W6AqxPnKm3/LeexBj1i76WAwdbWblxSFnKAoz5jlDG020mC10KcFdQU sUXg== MIME-Version: 1.0 X-Received: by 10.68.193.166 with SMTP id hp6mr14674651pbc.144.1395206232859; Tue, 18 Mar 2014 22:17:12 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 22:17:12 -0700 (PDT) In-Reply-To: References: <5328269A.6080907@ericsson.com> <53283FE6.2050809@akamai.com> Date: Tue, 18 Mar 2014 22:17:12 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b15a61be5ef5104f4eec31c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YadrJ6I-ZSQYS3FVpU1y-7rCRGw Cc: Suhas Nandakumar , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Adoption of draft-reddy-behave-turn-auth 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, 19 Mar 2014 05:17:23 -0000 --047d7b15a61be5ef5104f4eec31c Content-Type: text/plain; charset=ISO-8859-1 +1 On Tue, Mar 18, 2014 at 8:37 PM, Justin Uberti wrote: > +1 > > > On Tue, Mar 18, 2014 at 7:22 AM, Suhas Nandakumar wrote: > >> + 1 >> >> >> On Tue, Mar 18, 2014 at 6:15 PM, Brandon Williams < >> brandon.williams@akamai.com> wrote: >> >>> +1 >>> >>> >>> On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote: >>> >>>> Hi, >>>> >>>> from the draft minutes of meeting: >>>> >>>> * draft-reddy-behave-turn-auth >>>>> Discussions led by Justin Uberti >>>>> >>>>> There was a strong consensus in the room to adopt this draft as a WG >>>>> item for the miletone about analysing the problems with current TURN >>>>> authentication. Additionaly, the relevant milestone will updated to >>>>> reflect the fact that the eventual RFC will be Informational. >>>>> >>>> >>>> We would like to confirm this decision on the list. So, if you have any >>>> comments, please share them with the group. Additionally, we (the >>>> chairs) will update the milestone to indicate that it is about an >>>> Informational document. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>> -- >>> Brandon Williams; Senior Principal Software Engineer >>> Emerging Products Engineering; Akamai Technologies Inc. >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b15a61be5ef5104f4eec31c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Tue, Mar 18, 2014 at 8:37 PM, Justin Uberti <jubert= i@google.com> wrote:
+1


On Tue, Mar 18, 2014 at 7:22 AM, Suhas Nandakumar <suhasietf@gma= il.com> wrote:
+ 1


On Tue, Mar 18, 2014 at 6:15 PM, Brandon Williams <brandon.willi= ams@akamai.com> wrote:
+1


On 03/18/2014 06:57 AM, Gonzalo Camarillo wrote:
Hi,

from the draft minutes of meeting:

* draft-reddy-behave-turn-auth
Discussions led by Justin Uberti

There was a strong consensus in the room to adopt this draft as a WG
item for the miletone about analysing the problems with current TURN
authentication. Additionaly, the relevant milestone will updated to
reflect the fact that the eventual RFC will be Informational.

We would like to confirm this decision on the list. So, if you have any
comments, please share them with the group. Additionally, we (the
chairs) will update the milestone to indicate that it is about an
Informational document.

Cheers,

Gonzalo

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
<= div>

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b15a61be5ef5104f4eec31c-- From nobody Tue Mar 18 22:17:44 2014 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 C6B341A0351 for ; Tue, 18 Mar 2014 22:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KxZUcdlHOs7 for ; Tue, 18 Mar 2014 22:17:41 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 43AD81A031E for ; Tue, 18 Mar 2014 22:17:41 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so8353509pab.41 for ; Tue, 18 Mar 2014 22:17:32 -0700 (PDT) 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=jiiFUkkWg+KthWjH0suBr/Ond4q9TrdSgw2C9OuY1Ic=; b=br9WKl7iBeDFFyEvq/PrsqSO/DxQ3CPN/1ppbEYmR7wtQQQMaP+wosLGxSoUeLABUZ OloV9HcyrLbsHTPlOq3iXqRy1p8g+uVHAGdIYjZIO6/759UfMFYE+1qIE6zxgGrbLqj1 JLpVlt75FFXaG/lSp4Jh7+t7HDaaIpce9xejY1QuZdNLMFXiG5U/ThiaXmR0+LMnCOvG easmGfwdt/QTdAgOHAUcsR3oj4adBjkETTjRVe/cBeiWmFVJLJGnO7c3mReeELQ3x8bl AJGMHzMvg7eoe80wkQBQhOSXfvL9BPiFCuvP0fgBQ6XW1c5y9bmainlyxhWIn27lT/FC v/kw== MIME-Version: 1.0 X-Received: by 10.68.178.1 with SMTP id cu1mr36996031pbc.34.1395206252879; Tue, 18 Mar 2014 22:17:32 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 18 Mar 2014 22:17:32 -0700 (PDT) In-Reply-To: References: <53282645.70309@ericsson.com> <53283FD9.3040303@akamai.com> Date: Tue, 18 Mar 2014 22:17:32 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b86f76a1764df04f4eec561 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JEpPreWqAuwqwXT70LzgeQmcm9E Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 19 Mar 2014 05:17:43 -0000 --047d7b86f76a1764df04f4eec561 Content-Type: text/plain; charset=ISO-8859-1 +1 On Tue, Mar 18, 2014 at 8:37 PM, Justin Uberti wrote: > +1 > > > On Tue, Mar 18, 2014 at 5:45 AM, Brandon Williams < > brandon.williams@akamai.com> wrote: > >> +1 >> >> >> On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote: >> >>> Hi, >>> >>> from the draft minutes of meeting: >>> >>> * draft-petithuguenin-tram-stun-dtls >>>> Discussions led by Marc Petit-Huguenin >>>> >>>> There was a strong consensus in the room to adopt this draft as a WG >>>> item for the miletone about adding DTLS as a transport for STUN/TURN. >>>> >>> >>> We would like to confirm this decision on the list. So, if you have any >>> comments, please share them with the group. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b86f76a1764df04f4eec561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Tue, Mar 18, 2014 at 8:37 PM, Justin Uberti <jubert= i@google.com> wrote:
+1


On Tue, Mar 18, 2014 at 5:45 AM, Brandon Williams <brand= on.williams@akamai.com> wrote:
+1


On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote:
Hi,

from the draft minutes of meeting:

* draft-petithuguenin-tram-stun-dtls
Discussions led by Marc Petit-Huguenin

There was a strong consensus in the room to adopt this draft as a WG
item for the miletone about adding DTLS as a transport for STUN/TURN.

We would like to confirm this decision on the list. So, if you have any
comments, please share them with the group.

Cheers,

Gonzalo

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
<= div>

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b86f76a1764df04f4eec561-- From nobody Tue Mar 18 23:22:21 2014 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 A22A21A05E5 for ; Tue, 18 Mar 2014 23:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 5VSE1m9T2Wx2 for ; Tue, 18 Mar 2014 23:22:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFAD1A04F8 for ; Tue, 18 Mar 2014 23:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3506; q=dns/txt; s=iport; t=1395210126; x=1396419726; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+QhVZWN0GQ42fZdjh1YPD9zF7zYy5rhCd7JbaHsSY7Q=; b=KcaykTWw2vhFa47nlhYEcXFZGzyfhBOwo4qLTCfa+8QPPjAkS8PO6eHt 6+cj1HM6oIeneLE+JpQcvWDcwsJRMKfgTs5QMLD6sNt9Q1Cqq3/k5OERH zh+xLepuD0QN+nJO1OoTSTP2TRxA95/5TjnWig7MBdOqk9gONXF5VBBHm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAEc3KVOtJV2Y/2dsb2JhbABagwY7V7schzyBGRZ0giUBAQEDAQEBASRHEAcGAQgRBAEBCx0uCxQJCQEEARIIh2kIDdBQF44gET6DHoEUBIkakF+QfoMtgWtA X-IronPort-AV: E=Sophos;i="4.97,683,1389744000"; d="scan'208";a="28578402" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 19 Mar 2014 06:22:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2J6M5lj010433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 06:22:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 01:22:05 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9DO4qilWHYwaI7QFa5XRC44wZatQ== Date: Wed, 19 Mar 2014 06:22:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D7C8F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PySBgESGGIQIFe7o4puMNkoQUFM Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 06:22:16 -0000 Please see inline > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Tuesday, March 18, 2014 8:06 PM > To: tram@ietf.org > Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) >=20 > Le 2014-03-18 06:13, Tirumaleswar Reddy (tireddy) a =E9crit : > > My initial comments > > > > 1) Introduction > > > > Secondly, with fewer local host ports there will be fewer NAT bindings= for the > NAT to keep track of, and fewer server reflexive candidates. > > > > Comment> > > This benefits IPv4 only hosts and the above sentence may not be applica= ble for > dual-stack hosts. With IPv6 there will no NAT or even with NPTv6 it's ju= st 1:1 > mapping. >=20 > The statement would also apply to IPv6 hosts behind stateful IPv6 > firewalls. I, for one, am behind such a firewall at work (actually two > layers of stateful IPv6 firewalls). Good point. =20 >=20 > And NAT64... >=20 > > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use singl= e > ALLOCATE request to learn both relayed and server-reflexive addresses for= both > families. >=20 > This is true, but if I'm not mistaken, and please correct me if I'm > wrong, in ICE you can not use a single TURN connection for creating both > a server-reflexive and a relayed candidate.=20 It's explained in section 2.1 of RFC 5245 http://tools.ietf.org/html/rfc524= 5#section-2.1 with an example that single TURN allocate request can be used= by ICE agent=20 to learn both sever-reflexive and relayed candidates. > Each candidate needs its own > socket. If that is correct then SSODA is no worse and no better than the > status quo in this regard. >=20 > > Additional details when client should use this mechanism will be helpfu= l. > > > > 2) If the Allocate Response contains only one XOR-RELAYED-ADDRESS > > attribute, then the client knows that the TURN server does not > > support SSODA. The client can retry the missing address family > > allocations on new 5-tuples, if desired. Subsequent Allocate > > requests towards the same TURN server SHOULD NOT include multiple > > REQUESTED-ADDRESS-FAMILY attributes > > > > Comment> > > How will the client ever know that the server has upgraded and now supp= orts > the new mechanism proposed in the draft ? > > May be the client once in a day can probe and find if the server suppor= ts > multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request= . >=20 > Good observation. IMHO that last sentence is not necessary for > interoperability. Let client implementers figure it out. Yup, last line can also be removed. >=20 > > 4) How does this mechanism reduce the number of candidates gathered dur= ing > the discovery process ? >=20 > It does not. That's not the goal. The goal is being able to obtain two > candidates (IPv4 and IPv6 relayed candidates) using a single socket. Agreed. But Introduction needs to be fixed to remove the following line "reduce the number of candidates gathered during the discovery process" Cheers, -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Mar 18 23:31:07 2014 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 44A0E1A0395 for ; Tue, 18 Mar 2014 23:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, 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 9JnreugNpj33 for ; Tue, 18 Mar 2014 23:31:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id B86241A034C for ; Tue, 18 Mar 2014 23:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10563; q=dns/txt; s=iport; t=1395210653; x=1396420253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DEurXdblMwwuWGy/SSlZD3CclPmpyrZVuWFbZr6UiGU=; b=OggTOvQCsdxuDFla/lKVRtgmqX/X12wBMDAB+HWfOsW7xD3Giz0htv4N /eVDsvS8P1e0KvUWkX8KGLgSf8sS9kS6xLKaTDKD+0X4rSMp6rcCQ08bE dAnlLn4yhxn3C6JJGIsWg6zc9w6BFgOnczgmpYHjHbcnN32LyMquZhJMb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABo5KVOtJXG+/2dsb2JhbABagkJEO1fCWIEZFnSCJQEBAQQtTBACAQgOAwQBAQsdByERFAkIAQEEDgUIh10DEclKDYcSF4xKgVYRMQYBgySBFASWWo5VhUiDLYFrQA X-IronPort-AV: E=Sophos; i="4.97,684,1389744000"; d="scan'208,217"; a="28581270" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-4.cisco.com with ESMTP; 19 Mar 2014 06:30:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2J6UrHJ030494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 06:30:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 01:30:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZJGocJ2jdTwSef3K1BegT6wAckHsAAA27zZA= Date: Wed, 19 Mar 2014 06:30:52 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.114] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242D7CC0xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Dubfwg8WT2wbzfCEy2HE7c5QX00 Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 06:31:04 -0000 --_000_913383AAA69FF945B8F946018B75898A242D7CC0xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, Please see inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Wednesday, March 19, 2014 12:21 AM To: Tirumaleswar Reddy (tireddy) Cc: Pal Martinsen (palmarti); tram@ietf.org Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) Hi Tiru please see below: On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) > wrote: 2) If the Allocate Response contains only one XOR-RELAYED-ADDRESS attribute, then the client knows that the TURN server does not support SSODA. The client can retry the missing address family allocations on new 5-tuples, if desired. Subsequent Allocate requests towards the same TURN server SHOULD NOT include multiple REQUESTED-ADDRESS-FAMILY attributes Comment> How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ? May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. I guess so 3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated) I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general) [TR] Yes, you just need say something similar to the above line. 5) Section 2.3 The allocated non-ANY address can be used, but the client SHOULD NOT try to allocate any of the unsupported families on a different 5-tuple. Comment> I guess the above line does not hold good for errors like "Insuffi= cient capacity". Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single add= ress family ? That's true. But we do know that that address family cannot b= e allocated at the moment. So, I'd change the text to: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agree ? [TR] Yes -Tiru Thanks Oleg --_000_913383AAA69FF945B8F946018B75898A242D7CC0xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 <= /p>

Please see inline [TR]

 <= /p>

From: Oleg Mos= kalenko [mailto:mom040267@gmail.com]
Sent: Wednesday, March 19, 2014 12:21 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Pal Martinsen (palmarti); tram@ietf.org
Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN)<= o:p>

 

Hi Tiru

please see below:

 

On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:


2)  If the Allocate Response contains only one XOR-RELAYED-ADDRESS
   attribute, then the client knows that the TURN server does not=
   support SSODA.  The client can retry the missing address = family
   allocations on new 5-tuples, if desired.  Subsequent Allo= cate
   requests towards the same TURN server SHOULD NOT include multi= ple
   REQUESTED-ADDRESS-FAMILY attributes

Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.

 

I guess so

 


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)

 

I suppose that this document does not introduce any = new security concerns (besides the ones we already have about TURN in gener= al)

 <= /p>

[TR] Yes, you just need s= ay something similar to the above line.

 


5) Section 2.3

  The allocated non-ANY address can be used, but the client
   SHOULD NOT try to allocate any of the unsupported families on = a
   different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

 

Do you mean a use cas= e when one family relay address can be allocated - but the other one can't = - due to the exhaustion of capacity of that single address family ? That's = true. But we do know that that address family cannot be allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

-Tiru

Thanks
Oleg

--_000_913383AAA69FF945B8F946018B75898A242D7CC0xmbrcdx10ciscoc_-- From nobody Wed Mar 19 01:28:00 2014 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 C532E1A068F for ; Wed, 19 Mar 2014 01:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 ZY9_H6y7jRcu for ; Wed, 19 Mar 2014 01:27:57 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6691A04B4 for ; Wed, 19 Mar 2014 01:27:57 -0700 (PDT) Received: from [IPv6:2001:5c0:1101:2d00:11a4:7223:387:448a] (unknown [IPv6:2001:5c0:1101:2d00:11a4:7223:387:448a]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id DA5F7215C6; Wed, 19 Mar 2014 09:27:45 +0100 (CET) Message-ID: <532954FF.6030809@acm.org> Date: Wed, 19 Mar 2014 02:27:43 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: Gonzalo Camarillo , tram@ietf.org References: <5328269A.6080907@ericsson.com> In-Reply-To: <5328269A.6080907@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/cC1E31yd2TaF2i2j_nxpMof9F6Y Cc: Simon Perreault Subject: Re: [tram] Adoption of draft-reddy-behave-turn-auth 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, 19 Mar 2014 08:27:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/18/2014 04:57 AM, Gonzalo Camarillo wrote: > Hi, > > from the draft minutes of meeting: > >> * draft-reddy-behave-turn-auth Discussions led by Justin Uberti >> >> There was a strong consensus in the room to adopt this draft as a WG item >> for the miletone about analysing the problems with current TURN >> authentication. Additionaly, the relevant milestone will updated to >> reflect the fact that the eventual RFC will be Informational. > > We would like to confirm this decision on the list. So, if you have any > comments, please share them with the group. Additionally, we (the chairs) > will update the milestone to indicate that it is about an Informational > document. > I support the adoption of this document as WG item. - -- 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 v1 iQIcBAEBCAAGBQJTKVT9AAoJECnERZXWan7ETnQQAL8Enat2ThR62yeQA4RwT7er r3sV/J9YfLI06lIdilPbAG4l6vVUehq60HgPtz7NgmBbI6hcyZ5FG0kL6cJeFlP9 KTXK4ORorYuFYRi6z/gRNmUWXzBA3O5R9TgM9gffxjuGNAZCX7yPXNM97CVBavWA 1Vld3cKb1JgISfNg+G3a0fvmCQM/udAkaoKRTDXLnwT8gSNzxtnueDgkIwMZK3SC ZOhWO3tweR5PzCNwhdWytXsslaXw82ODzS3RdObpuIA6dBkFebw51DpPjZhsOQTn Reg9YoVwNtlJ9w79JRqDaAzneWq/tbMy9bW3KgyJDt5zpiGgjAYuTuih8rw+i8y9 tFeRaW0o6xtGjBO++84sK9L3blp1eX/HML/1V6qhJcMGpyNPvt7xGOECg7pNQCvh ipPgmctRDho6w42q//Ra1K6YxzS26jbaOg8fhQinPwEJ17wLnKAGQLf5RpJCFI0v ZMitmsJ9IviIsE0R1RD7wD4EgTAe0TaXzEzeDM4NofTyiBHO53iHs1ZgJNpEAZJB AhthnTjXYHzcOqF6Hx6QvY6LYCJKsCB/aBGLEi9Hfrkrp8kjaT5FP5GgQSRXThYY 45rIKKV0hV6hpy4IrzlrtNkHY8SUU7P9kJOxauRkm8C2hCKd2o7HsShVZzFkly0V +AC6nDgMHWZUaOuRvWf/ =1/mV -----END PGP SIGNATURE----- From nobody Wed Mar 19 02:36:33 2014 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 CEFDD1A0695 for ; Wed, 19 Mar 2014 02:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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.547, 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 o3gPKvWFn9uo for ; Wed, 19 Mar 2014 02:36:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3961A03BD for ; Wed, 19 Mar 2014 02:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5539; q=dns/txt; s=iport; t=1395221780; x=1396431380; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kIHazkA7mfFEC2in+amhl+EdrmPI8soYn61M9GhR79s=; b=PxPCsFmVBrqDTY6RLSlOuTI0Y6ymUHLpUmfY2+aE1PDRC/DP6oAYRIje 2TSaXpT/eMQ/Jb1mG1r4RvVO5tjZU43tMnPu9bLcpGg+oj9hVEKDTrNL3 PnabTugyZRVV1YOozF/TkO5TFrAUhyI9xHzWr1z7YVu2L0gBYMVq/o+cp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOJjKVOtJV2d/2dsb2JhbABagwY7V7sahzyBGhZ0giYBAQQBAQFrGwIBCD8HIQYLFBECBBOHZQMRDcd6DYcSEwSMTYIUC4MkgRQEiRqNQIFtjGiFSIFAgW2CKw X-IronPort-AV: E=Sophos;i="4.97,684,1389744000"; d="scan'208,217";a="311342724" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2014 09:36:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2J9aJdL014485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Mar 2014 09:36:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.22]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 04:36:19 -0500 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: [tram] Adoption of draft-petithuguenin-tram-stun-dtls Thread-Index: AQHPQpivnLjPRULL0U+s79kalTV8fprnHm+AgAD5RgCAABv6AIAASEoA Date: Wed, 19 Mar 2014 09:36:18 +0000 Message-ID: References: <53282645.70309@ericsson.com> <53283FD9.3040303@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.71] Content-Type: multipart/alternative; boundary="_000_A0CBC9F67E664429AADD269835222E6Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nsMMZqqB7DT__Z_5d77ojj1_n-s Subject: Re: [tram] Adoption of draft-petithuguenin-tram-stun-dtls 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, 19 Mar 2014 09:36:33 -0000 --_000_A0CBC9F67E664429AADD269835222E6Bciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 On 19 Mar 2014, at 06:17, Oleg Moskalenko > wrote: +1 On Tue, Mar 18, 2014 at 8:37 PM, Justin Uberti > wrote: +1 On Tue, Mar 18, 2014 at 5:45 AM, Brandon Williams > wrote: +1 On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote: Hi, from the draft minutes of meeting: * draft-petithuguenin-tram-stun-dtls Discussions led by Marc Petit-Huguenin There was a strong consensus in the room to adopt this draft as a WG item for the miletone about adding DTLS as a transport for STUN/TURN. We would like to confirm this decision on the list. So, if you have any comments, please share them with the group. Cheers, Gonzalo _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_A0CBC9F67E664429AADD269835222E6Bciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
+1

On 19 Mar 2014, at 06:17, Oleg Moskalenko <mom040267@gmail.com> wrote:

+1


On Tue, Mar 18, 2014 at 8:37 PM, Justin Uberti <= span dir=3D"ltr"> <juberti@google.= com> wrote:
+1


On Tue, Mar 18, 2014 at 5:45 AM, Brandon William= s <brando= n.williams@akamai.com> wrote:
+1


On 03/18/2014 06:56 AM, Gonzalo Camarillo wrote:
Hi,

from the draft minutes of meeting:

* draft-petithuguenin-tram-stun-dtls
Discussions led by Marc Petit-Huguenin

There was a strong consensus in the room to adopt this draft as a WG
item for the miletone about adding DTLS as a transport for STUN/TURN.

We would like to confirm this decision on the list. So, if you have any
comments, please share them with the group.

Cheers,

Gonzalo

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


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

--_000_A0CBC9F67E664429AADD269835222E6Bciscocom_-- From nobody Wed Mar 19 02:48:44 2014 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 30C2D1A06A9 for ; Wed, 19 Mar 2014 02:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.447 X-Spam-Level: X-Spam-Status: No, score=-14.447 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, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 bMh-kK9F8ZAS for ; Wed, 19 Mar 2014 02:48:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D9B761A06F6 for ; Wed, 19 Mar 2014 02:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18240; q=dns/txt; s=iport; t=1395222507; x=1396432107; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YPoTzpeV4xHQj6hwQA613LSO//yPVv0MLpv8J/2QR64=; b=XAaGaWct8pX9E3Z8K0xhXKcZWMuK9UFl9M7yZnKK4PN+5iWZyi4rVZZ+ uIwWbqTXbKy3nfu3hJFLvglDwr74kGqUrUoB6++pfRFjPj3suWZH+xmoh QSg6vCJkTFvTv34qLczkdOUidOi02jdLT6+vk+kNzZm/s41bhXZMozTR4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGpnKVOtJV2c/2dsb2JhbABagkJEgQYMwlaBGhZ0giUBAQEEeRACAQgRBAEBKAchERQJCAEBBA4Fh2UDEcgRDYcSF4xNgVZCBgGDJIEUBIkajUCBbYxohUiDLYFrQA X-IronPort-AV: E=Sophos;i="4.97,684,1389744000"; d="scan'208,217";a="311133472" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2014 09:48:27 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2J9mQ2s031048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 09:48:26 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.22]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 04:48:26 -0500 From: "Pal Martinsen (palmarti)" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZAM43PdanGEKAQmjn6WQD7QAckHsAABhwswAABuTlAA== Date: Wed, 19 Mar 2014 09:48:25 +0000 Message-ID: <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.71] Content-Type: multipart/alternative; boundary="_000_4783A5B482F64DE08D628865ACAC4EB4ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zOv2GxNuVzsc8S8Rphe9D3jquz0 Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 09:48:41 -0000 --_000_4783A5B482F64DE08D628865ACAC4EB4ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 19 Mar 2014, at 07:30, Tirumaleswar Reddy (tireddy) > wrote: Hi Oleg, Please see inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Wednesday, March 19, 2014 12:21 AM To: Tirumaleswar Reddy (tireddy) Cc: Pal Martinsen (palmarti); tram@ietf.org Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) Hi Tiru please see below: On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) > wrote: 2) If the Allocate Response contains only one XOR-RELAYED-ADDRESS attribute, then the client knows that the TURN server does not support SSODA. The client can retry the missing address family allocations on new 5-tuples, if desired. Subsequent Allocate requests towards the same TURN server SHOULD NOT include multiple REQUESTED-ADDRESS-FAMILY attributes Comment> How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ? May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. I guess so I do not think the client should cache this information. It just needs to k= now if it specks to a SSODA server,if it does not it might do more steps to= get all the allocated RELAY addresses the client needs. 3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated) I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general) [TR] Yes, you just need say something similar to the above line. It might have some positive security aspects. SSODA have the potential of r= educing chatter between agent and TURN server. This means that the TURN ser= ver can put in more restrictive rate limiting hemes to restrict the number = of allocate request it will handle without impacting the client. 5) Section 2.3 The allocated non-ANY address can be used, but the client SHOULD NOT try to allocate any of the unsupported families on a different 5-tuple. Comment> I guess the above line does not hold good for errors like "Insuffi= cient capacity". Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single add= ress family ? That's true. But we do know that that address family cannot b= e allocated at the moment. So, I'd change the text to: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agree ? [TR] Yes I am unsure. This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server? ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. ANY:9 means insufficient resources. Try again later. Or is using port numbers like this a slippery slope? .-. P=E5l-Erik -Tiru Thanks Oleg --_000_4783A5B482F64DE08D628865ACAC4EB4ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4ED4E7B92850CC4AAF63C3CC4A229D13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 19 Mar 2014, at 07:30, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Hi Oleg,
 
Please see inline [TR]
 
From:<= /span> Oleg Moskalenko [mailto:mom040267@gmail.com] 
Sent: Wednesday, M= arch 19, 2014 12:21 AM
To: Tirumaleswar R= eddy (tireddy)
Cc: Pal Martinsen = (palmarti); tr= am@ietf.org
Subject: Re: [tram= ] SSODA (Single SOcket Dual Allocation with TURN)
 

Hi Tiru

please see below:

 

On Tue, Mar 18, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

2)  If the Allocate Response contains only one XOR-RELAYED-ADDRESS
   attribute, then the client knows that the TURN server does not=
   support SSODA.  The client can retry the missing address = family
   allocations on new 5-tuples, if desired.  Subsequent Allo= cate
   requests towards the same TURN server SHOULD NOT include multi= ple
   REQUESTED-ADDRESS-FAMILY attributes

Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
 
I guess so
 

I do not think the client should cache this information. It just needs= to know if it specks to a SSODA server,if it does not it might do more ste= ps to get all the allocated RELAY addresses the client needs.


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)
 
I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general)
 
[TR] Yes, you just need say something similar to the above= line.

It might have some positive security aspects. SSODA have the potential= of reducing chatter between agent and TURN server. This means that the TUR= N server can put in more restrictive rate limiting hemes to restrict the nu= mber of allocate request it will handle without impacting the client.

 


5) Section 2.3

  The allocated non-ANY address can be used, but the client
   SHOULD NOT try to allocate any of the unsupported families on = a
   different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

 

Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single add= ress family ? That's true. But we do know that that address family cannot b= e allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

I am unsure.

This is a problem with the partial success scheme introduced in SSODA.= The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. W= e do not know the reason why the SSODA server used a ANY address. 

Can we use the port number in the ANY address to distinguish between i= nsufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not= try to allocate this address on a different 5-tuple. This address type is = disabled on this server. 

ANY:9 means insufficient resources. Try again later. 

Or is using port numbers like this a slippery slope?

.-.
P=E5l-Erik

-Tiru

Thanks
Oleg


--_000_4783A5B482F64DE08D628865ACAC4EB4ciscocom_-- From nobody Wed Mar 19 03:01:24 2014 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 E60061A06A7 for ; Wed, 19 Mar 2014 03:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, 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 rQqhs4AUUmxU for ; Wed, 19 Mar 2014 03:01:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A8BFB1A06D9 for ; Wed, 19 Mar 2014 03:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7936; q=dns/txt; s=iport; t=1395223266; x=1396432866; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AntkNPaQ9cZatXWsfuLL5+y1VYX2ZOj/l/HNFFY4b7k=; b=GxoQvTVz+k2AvtxMkX9ZmYTnazjGfs4wd2rkOYQX47Wq9HcXIg0f9Zf4 r6xu/r5msCpRy+PiVyS6xPGdULcE1gJAG9nMpIGZf26xUAgTbLvz80ras ehGpumMfYaXZrPAC0NwuiGxRMU7fwJqVLTEp1vWegZoJ7pxIuoksMsNJT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4GAHFqKVOtJV2a/2dsb2JhbABagwY7V6wejT6BPoc8gRoWdIIlAQEBAwEBAQEkRwsFCwIBCA4xByEGCxQRAgQOBYdlAwkIDcgMDYcSF4xNghgHCYMbgRQEllqBbYEyizaFSIMtgis X-IronPort-AV: E=Sophos; i="4.97,685,1389744000"; d="scan'208,217"; a="28610406" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 19 Mar 2014 10:01:05 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2JA15vK008578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 10:01:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.22]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 05:01:04 -0500 From: "Pal Martinsen (palmarti)" To: Oleg Moskalenko Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZAM43PdanGEKAQmjn6WQD7QATp2kAAAwFPYAAABeLgAAAG7iAAABXUoAAABZagAAAFswAAADY0IAAACIgAAAAY/yAABqU6gA= Date: Wed, 19 Mar 2014 10:01:02 +0000 Message-ID: <5BF17A69-A4C5-48C5-AE57-D094D50F8282@cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> <5328AF48.1060605@viagenie.ca> <5328B5DC.5000702@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.71] Content-Type: multipart/alternative; boundary="_000_5BF17A69A4C548C5AE57D094D50F8282ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KlmlnNfvGZRTMsFyDyJFSlq5HPA Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 10:01:22 -0000 --_000_5BF17A69A4C548C5AE57D094D50F8282ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 18 Mar 2014, at 22:19, Oleg Moskalenko > wrote: If we do want two server-reflexive candidates (both IPv4 and IPv6) then you= are right, two client sockets are involved. One client socket will have a = TURN allocation session (with dual relay candidates) and another will be ju= st a reflexive candidate obtained by STUN BINDING request. We still have some noticeable optimization because we need only one TURN al= location dialog (plus STUN stateless request for the second address family = candidate). So we still are consuming less resources, because a TURN alloca= tion is a much heavier thing than a STUN stateless request-response. I was thinking about an alternate way of getting the IPv6 RFLX candidate. 1. Use IPv4 to allocate a dual IPv4/IPv6 SSODA RELAY addresses. 2. From HOST IPv6 address send a some data (STUN packet?) to the RELAY IPv6= address. 3. Receive data on the IPv4 =93tunnel=94 and look at the PEER ADDRESS, this= will be the RFLX IPv6 address. But=85 What about permissions. Any clever way of getting the TURN server to= securely accept traffic from your IPv6 RFLX address? It is a nice way to a= ctually check connectivity before the real connectivity checks. Probably easier with a STUN Binding request if the TURN server also support= s STUN. We should definitively add some wording in the SSODA draft that a S= SODA server should also respond to STUN Binding Request to solve the missin= g RFLX candidate problem. .-. P=E5l-Erik Oleg On Tue, Mar 18, 2014 at 2:08 PM, Simon Perreault > wrote: Le 2014-03-18 17:04, Oleg Moskalenko a =E9crit : > Without SSODA, if we want both IPv4 and IPv6 candidates, then we need: > > 1) two client sockets for two allocations > 2) two server sockets for two allocations > 3) two relayed sockets for the server relayed endpoints (one per allocati= on) > > With SSODA: > > 1) One client socket for one allocation > 2) one server socket for one allocation > 3) two relayed sockets in single allocation > > So, this is totally 6 sockets vs 4 sockets with SSODA: > > 1) 2 sockets vs 1 socket on client > 2) 4 sockets vs 3 sockets on server Aren't you missing one server-reflexive candidate in your "with SSODA" scenario? I'm assuming you want dual-stack server-reflexive and dual-stack relayed candidates. If that assumption doesn't hold, please explain why. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_5BF17A69A4C548C5AE57D094D50F8282ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 18 Mar 2014, at 22:19, Oleg Moskalenko <mom040267@gmail.com> wrote:

If we do want two server-reflexive candidates (both IPv4 and IPv6) the= n you are right, two client sockets are involved. One client socket will ha= ve a TURN allocation session (with dual relay candidates) and another will = be just a reflexive candidate obtained by STUN BINDING request.

We still have some noticeable optimization because we need only one TURN al= location dialog (plus STUN stateless request for the second address family = candidate). So we still are consuming less resources, because a TURN alloca= tion is a much heavier thing than a STUN stateless request-response.

I was thinking about an alternate way of getting the IPv6 RFLX candida= te.

1. Use IPv4 to allocate a dual IPv4/IPv6 SSODA RELAY addresses. <= /div>
2. From HOST IPv6 address send a some data (STUN packet?) to the RELAY= IPv6 address. 
3. Receive data on the IPv4 =93tunnel=94 and look at the PEER ADDRESS,= this will be the RFLX IPv6 address.

But=85 What about permissions. Any clever way of getting the TURN serv= er to securely accept traffic from your IPv6 RFLX address? It is a nice way= to actually check connectivity before the real connectivity checks.

Probably easier with a STUN Binding request if the TURN server also su= pports STUN. We should definitively add some wording in the SSODA draft tha= t a SSODA server should also respond to STUN Binding Request to solve the m= issing RFLX candidate problem.

.-.
P=E5l-Erik







Oleg



On Tue, Mar 18, 2014 at 2:08 PM, Simon Perreault= <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-18 17:04, Oleg Moskalenko a =E9crit :
> Without SSODA, if we want both IPv4 and IPv6 candida= tes, then we need:
>
> 1) two client sockets for two allocations
> 2) two server sockets for two allocations
> 3) two relayed sockets for the server relayed endpoints (one per alloc= ation)
>
> With SSODA:
>
> 1) One client socket for one allocation
> 2) one server socket for one allocation
> 3) two relayed sockets in single allocation
>
> So, this is totally 6 sockets vs 4 sockets with SSODA:
>
> 1) 2 sockets vs 1 socket on client
> 2) 4 sockets vs 3 sockets on server

Aren't you missing one server-reflexive candidate in your "with SSODA&= quot;
scenario?

I'm assuming you want dual-stack server-reflexive and dual-stack relayed candidates. If that assumption doesn't hold, please explain why.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

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

--_000_5BF17A69A4C548C5AE57D094D50F8282ciscocom_-- From nobody Wed Mar 19 07:11:05 2014 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 6C0351A0774 for ; Wed, 19 Mar 2014 07:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 pFPpqoGJYuHC for ; Wed, 19 Mar 2014 07:11:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81ECD1A076D for ; Wed, 19 Mar 2014 07:11:01 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 859FA40233; Wed, 19 Mar 2014 10:10:52 -0400 (EDT) Message-ID: <5329A56C.4070205@viagenie.ca> Date: Wed, 19 Mar 2014 10:10:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> <5328AF48.1060605@viagenie.ca> <5328B5DC.5000702@viagenie.ca> <5BF17A69-A4C5-48C5-AE57-D094D50F8282@cisco.com> In-Reply-To: <5BF17A69-A4C5-48C5-AE57-D094D50F8282@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QV7qA9mPrQhS_PNN8meyHZWHE_g Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 14:11:03 -0000 Le 2014-03-19 06:01, Pal Martinsen (palmarti) a écrit : > Probably easier with a STUN Binding request if the TURN server also > supports STUN. We should definitively add some wording in the SSODA > draft that a SSODA server should also respond to STUN Binding Request to > solve the missing RFLX candidate problem. TURN servers usually respond to Binding requests... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 19 08:42:37 2014 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 0AF371A0771 for ; Wed, 19 Mar 2014 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Qgta5VX8Z2Df for ; Wed, 19 Mar 2014 08:06:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A5D1A0773 for ; Wed, 19 Mar 2014 08:06:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140319150641.10846.19583.idtracker@ietfa.amsl.com> Date: Wed, 19 Mar 2014 08:06:41 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Faj99y80uGsOAR0Uf4GZEp5N_Hk X-Mailman-Approved-At: Wed, 19 Mar 2014 08:42:31 -0700 Subject: [tram] Milestones changed for tram WG 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, 19 Mar 2014 15:06:45 -0000 Deleted milestone "Send draft adding DTLS as a transport for STUN/TURN to IESG ". Deleted milestone " Send analysis of problems with current TURN authentication to IESG". Deleted milestone "Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG". Deleted milestone "Send new proposed standard TURN authentication mechanism(s) to IESG". Deleted milestone "Send STUN-bis draft to IESG". Deleted milestone "Send TURN-bis draft to IESG". URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Wed Mar 19 08:42:39 2014 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 E28E21A0422 for ; Wed, 19 Mar 2014 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F_Y7IjtpBJI5 for ; Wed, 19 Mar 2014 08:12:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D30DF1A0771 for ; Wed, 19 Mar 2014 08:12:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140319151221.23674.57403.idtracker@ietfa.amsl.com> Date: Wed, 19 Mar 2014 08:12:21 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CChJe0mRaGA1ChKfeJz252gKvNM X-Mailman-Approved-At: Wed, 19 Mar 2014 08:42:31 -0700 Subject: [tram] Milestones changed for tram WG 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, 19 Mar 2014 15:12:26 -0000 Changed milestone "Send draft adding DTLS as a transport for STUN/TURN to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Send analysis of problems with current TURN authentication to IESG for publication as Informational", set state to active from review, accepting new milestone. Changed milestone "Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Send STUN-bis draft to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Send TURN-bis draft to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. Changed milestone "Send new authentication mechanism(s) to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Wed Mar 19 08:42:43 2014 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 C40051A03FF for ; Wed, 19 Mar 2014 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 R_p9i7nXIZ6X for ; Wed, 19 Mar 2014 08:21:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BB11A077F for ; Wed, 19 Mar 2014 08:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140319152107.28664.33267.idtracker@ietfa.amsl.com> Date: Wed, 19 Mar 2014 08:21:07 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PUnHA4q_rcax5OyaxG5KZbkkMJA X-Mailman-Approved-At: Wed, 19 Mar 2014 08:42:31 -0700 Subject: [tram] Milestones changed for tram WG 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, 19 Mar 2014 15:21:09 -0000 Changed milestone "Send new authentication mechanism(s) to IESG for publication as Proposed Standard", set due date to November 2014 from November 2015. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Wed Mar 19 09:47:26 2014 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 1B5FA1A07DF for ; Wed, 19 Mar 2014 09:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UZVSelZoo8a for ; Wed, 19 Mar 2014 09:47:22 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6279A1A0706 for ; Wed, 19 Mar 2014 09:47:14 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ma3so9191274pbc.13 for ; Wed, 19 Mar 2014 09:47:05 -0700 (PDT) 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=y/VG+Tqn2g4Qeo6zCS8QsvY+2MXqxzaWCm7DZPAaHs0=; b=b/v5Z726mK4SiIFWx7GTl2WgOoeghFSVYSR0wGyYXLfvzLdOrMqcEurRtc4nXYcRwN RzCmQ2j42k45mx8yEG/TJGwJcr3GbrSl6nVhe778rOHLvO1GvrQ2JPpJ6raDa54FUaui kskzHb8XddQXYebfVy8G2CqnzBC0Bs++AKFVFhnVEdR01d9z2eGAX2cFgi4L2Lgae9XI infLAV/97hVke5APEmRBYgNmyzqe9puo4qcTeD/60MJSpHo7mL1PkT8mRRxIEWVd4pvp d61o2A0rKGjDW81RHLeXQOPVgMz8qdanxRRuRSjF8a2C7jNbQlPVc8dH1ILiO12BdASB YG8w== MIME-Version: 1.0 X-Received: by 10.68.178.1 with SMTP id cu1mr40310954pbc.34.1395247625893; Wed, 19 Mar 2014 09:47:05 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Wed, 19 Mar 2014 09:47:05 -0700 (PDT) In-Reply-To: <5329A56C.4070205@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <532859CC.9030307@viagenie.ca> <5328AB15.8000306@viagenie.ca> <5328AE19.50707@viagenie.ca> <5328AF48.1060605@viagenie.ca> <5328B5DC.5000702@viagenie.ca> <5BF17A69-A4C5-48C5-AE57-D094D50F8282@cisco.com> <5329A56C.4070205@viagenie.ca> Date: Wed, 19 Mar 2014 09:47:05 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b86f76a1d7d1f04f4f8677b Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VYBI45aNewaXbyX-oIYHE_JPVRQ Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 16:47:23 -0000 --047d7b86f76a1d7d1f04f4f8677b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2014 at 7:10 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-19 06:01, Pal Martinsen (palmarti) a =E9crit : > > Probably easier with a STUN Binding request if the TURN server also > > supports STUN. We should definitively add some wording in the SSODA > > draft that a SSODA server should also respond to STUN Binding Request t= o > > solve the missing RFLX candidate problem. > > TURN servers usually respond to Binding requests... > > > yes, that's true. I do not see a problem here. --047d7b86f76a1d7d1f04f4f8677b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 19, 2014 at 7:10 AM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-19 06:01, Pal Martinsen (palmarti= ) a =E9crit :
> Probably easier with a STUN Binding request if the TUR= N server also
> supports STUN. We should definitively add some wording in the SSODA > draft that a SSODA server should also respond to STUN Binding Request = to
> solve the missing RFLX candidate problem.

TURN servers usually respond to Binding requests...



yes, that's true. I do= not see a problem here.

=A0

--047d7b86f76a1d7d1f04f4f8677b-- From nobody Wed Mar 19 09:55:38 2014 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 3001F1A06D8 for ; Wed, 19 Mar 2014 09:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=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 mDIyBsLEN2CL for ; Wed, 19 Mar 2014 09:55:35 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5036E1A0429 for ; Wed, 19 Mar 2014 09:55:35 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id bj1so9225211pad.2 for ; Wed, 19 Mar 2014 09:55:26 -0700 (PDT) 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=baW9JhlEWxoy7ExYfu4f0zPkSsxD+iCTrxkKAmj6BJw=; b=lBYeHMRvAgs7p/0oEVQO+ACX0I5Rc9F6nwCDlDt3tejVSg6Kvi4VIs6hYYhwZ+XepJ gruEskrsf/3aW3LLJH/vso9Qs6405nWDH0F3/Glyk8xrALCGqUd7UM1ac7Y+IiqWtQYt taeHx32qe6l4k0UUx19q7v6lqFrEGQvUxzJE4WTddW/rZR2FPpriTk9Sa5SktzkmUK83 9dU6YIiNMblSmq4OkflfzJaW460CSHLjqIEHgL2ZMxYAzlGaRNfKS2aQPled28RyL1mD V4vbUKWZQfZyzrW73Irb9a+yJiuzBp2WSpJnd3mFXUWVemjYK6oH/k3L4pk4+atmhgc0 asAA== MIME-Version: 1.0 X-Received: by 10.68.171.4 with SMTP id aq4mr18300624pbc.150.1395248126764; Wed, 19 Mar 2014 09:55:26 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Wed, 19 Mar 2014 09:55:26 -0700 (PDT) In-Reply-To: <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> Date: Wed, 19 Mar 2014 09:55:26 -0700 Message-ID: From: Oleg Moskalenko To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=047d7bacbb48f82e0204f4f884a6 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FmLoWWEgXq2w3p1HXRF4S5K_Tec Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 19 Mar 2014 16:55:37 -0000 --047d7bacbb48f82e0204f4f884a6 Content-Type: text/plain; charset=ISO-8859-1 Hi Pal please see inline: On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > > > Comment> > How will the client ever know that the server has upgraded and now > supports the new mechanism proposed in the draft ? > May be the client once in a day can probe and find if the server supports > multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. > > I guess so > > > > I do not think the client should cache this information. It just needs > to know if it specks to a SSODA server,if it does not it might do more > steps to get all the allocated RELAY addresses the client needs. > My understanding is that a client app can be a very long-living client app, and it can connect to both old and new TURN servers. And a TURN server can be upgraded overnight. So the client app has to learn somehow at some momemnt of time that the server has been upgraded. > > > 3) Security Considerations section is missing. (Section 2.2 is assuming > client has already authenticated) > > > I suppose that this document does not introduce any new security > concerns (besides the ones we already have about TURN in general) > > [TR] Yes, you just need say something similar to the above line. > > > It might have some positive security aspects. SSODA have the potential > of reducing chatter between agent and TURN server. This means that the TURN > server can put in more restrictive rate limiting hemes to restrict the > number of allocate request it will handle without impacting the client. > OK > > > > 5) Section 2.3 > > The allocated non-ANY address can be used, but the client > SHOULD NOT try to allocate any of the unsupported families on a > different 5-tuple. > > Comment> I guess the above line does not hold good for errors like > "Insufficient capacity". > > > > Do you mean a use case when one family relay address can be allocated - > but the other one can't - due to the exhaustion of capacity of that single > address family ? That's true. But we do know that that address family > cannot be allocated at the moment. So, I'd change the text to: > > ======================================= > The allocated non-ANY address can be used, but the client SHOULD NOT try > to allocate any of the unsupported families on a different 5-tuple within > the subsequent 600 seconds interval. After that interval, the allocation > can be re-tried. > ======================================= > > Agree ? > > [TR] Yes > > I am unsure. > > This is a problem with the partial success scheme introduced in SSODA. > The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We > do not know the reason why the SSODA server used a ANY address. > > Can we use the port number in the ANY address to distinguish between > insufficient capacity and address type not supported on this server? > > ANY:0 means address type not supported. I understand SSODA, but do not > try to allocate this address on a different 5-tuple. This address type is > disabled on this server. > > ANY:9 means insufficient resources. Try again later. > > Or is using port numbers like this a slippery slope? > > I think that assigning special meanings to the port numbers is indeed somewhat a slippery slope... but if we do want to do something like that, I would suggest using standard error codes as the port numbers, not some arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:508 address value. Thanks Oleg --047d7bacbb48f82e0204f4f884a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pal

please see inline:
<= div class=3D"gmail_extra">

On Wed, Mar 19= , 2014 at 2:48 AM, Pal Martinsen (palmarti) <palmarti@cisco.com>= wrote:



Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
=A0
I guess so
=A0

I do not think the client should cache this information. It just= needs to know if it specks to a SSODA server,if it does not it might do mo= re steps to get all the allocated RELAY addresses the client needs.

My understanding is that a cli= ent app can be a very long-living client app, and it can connect to both ol= d and new TURN servers. And a TURN server can be upgraded overnight. So the= client app has to learn somehow at some momemnt of time that the server ha= s been upgraded.

=A0


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)
=A0
I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general)
=A0
[TR] Yes, you just need say something similar to the above line.

It might have some positive security aspects. SSODA have the pot= ential of reducing chatter between agent and TURN server. This means that t= he TURN server can put in more restrictive rate limiting hemes to restrict = the number of allocate request it will handle without impacting the client.
OK


=A0


5) Section 2.3

=A0 The allocated non-ANY address can be used, but the client
=A0 =A0SHOULD NOT try to allocate any of the unsupported families on a
=A0 =A0different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

=A0

Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single= address family ? That's true. But we do know that that address family = cannot be allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

I am unsure.

This is a problem with the partial success scheme introduced in SSODA.= The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. W= e do not know the reason why the SSODA server used a ANY address.=A0

Can we use the port number in the ANY address to distinguish between i= nsufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not= try to allocate this address on a different 5-tuple. This address type is = disabled on this server.=A0

ANY:9 means insufficient resources. Try again later.=A0

Or is using port numbers like this a slippery slope?


I think=A0 that assignin= g special meanings to the port numbers is indeed somewhat a slippery slope.= .. but if we do want to do something like that, I would suggest using stand= ard=A0 error codes as the port numbers, not some arbitrary values like 9. F= or example, "insufficient capacity" partial error would be signal= ed as ANY:508 address value.

Thanks
Oleg

--047d7bacbb48f82e0204f4f884a6-- From nobody Wed Mar 19 19:48:25 2014 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 CAFCD1A07FE for ; Wed, 19 Mar 2014 19:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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.547, 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 ybD2BSsPv3yX for ; Wed, 19 Mar 2014 19:48:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9361A063F for ; Wed, 19 Mar 2014 19:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5622; q=dns/txt; s=iport; t=1395283689; x=1396493289; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QiZCbBvOP9VT8tK60Or3PdCX1gitIEauFggNuuBuSE4=; b=Vnoq/VoXzUis/F6py5KQv9K/SY/cUz8YP2lk/UiSPNBbrcrZDDjYQI78 U7zo5kWq0IJK9byIWzUjCBpNa6blsOEmQl+C96pCbyemW2bJ3VZDj2yuM gd6CSawo1IdBqONAUZyCqoWRvNfE2c07p1svdMzt8NN/JJ+RxQEt1Rtyk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFALpVKlOtJXG9/2dsb2JhbABagkJEO1fCTYEeFnSCJgEBBC1MEAIBCA4UJDIlAQEEAQ0Nh3HQKxeOBBQcMQeDJIEUBKp3gy2BakE X-IronPort-AV: E=Sophos;i="4.97,691,1389744000"; d="scan'208,217";a="311586482" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 20 Mar 2014 02:48:09 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2K2m9vc020273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 02:48:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 21:48:09 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , "Pal Martinsen (palmarti)" Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZJGocJ2jdTwSef3K1BegT6wAckHsAAA27zZAAEZsigAAO6dQAAAnJFIA= Date: Thu, 20 Mar 2014 02:48:08 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.134] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242D8566xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fNkMfaWiZQIQn9fj75kok6c7Cxg Cc: "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 02:48:22 -0000 --_000_913383AAA69FF945B8F946018B75898A242D8566xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline [TR] I am unsure. This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server? ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. ANY:9 means insufficient resources. Try again later. Or is using port numbers like this a slippery slope? I think that assigning special meanings to the port numbers is indeed some= what a slippery slope... but if we do want to do something like that, I wou= ld suggest using standard error codes as the port numbers, not some arbitr= ary values like 9. For example, "insufficient capacity" partial error would= be signaled as ANY:508 address value. [TR] There are two types of errors long-term (unsupported family), short-te= rm (insufficient capacity, quota exceeded etc.). For the short-term errors,= the server can suggest the client to re-try after specific duration. I don= 't think it's a good idea to populate error codes in the port field. -Tiru Thanks Oleg --_000_913383AAA69FF945B8F946018B75898A242D8566xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline [TR]

 

I am unsure.

 

This is a problem with the partial success scheme in= troduced in SSODA. The TURN server will return one valid XOR-ADDRESS and on= e ANY:0 address. We do not know the reason why the SSODA server used a ANY = address. 

 

Can we use the port number in the ANY address to dis= tinguish between insufficient capacity and address type not supported on th= is server?

 

ANY:0 means address type not supported. I understand= SSODA, but do not try to allocate this address on a different 5-tuple. Thi= s address type is disabled on this server. 

 

ANY:9 means insufficient resources. Try again later.=  

 

Or is using port numbers like this a slippery slope?=

 

I think  that as= signing special meanings to the port numbers is indeed somewhat a slippery = slope... but if we do want to do something like that, I would suggest using= standard  error codes as the port numbers, not some arbitrary values like 9. For example, "insufficient capacity= " partial error would be signaled as ANY:508 address value.=

[TR] There are two ty= pes of errors long-term (unsupported family), short-term (insufficient capa= city, quota exceeded etc.). For the short-term errors, the server can sugge= st the client to re-try after specific duration. I don’t think it’s a good idea to populate error cod= es in the port field.

-Tiru

Thanks
Oleg

--_000_913383AAA69FF945B8F946018B75898A242D8566xmbrcdx10ciscoc_-- From nobody Wed Mar 19 21:58:42 2014 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 3B8A31A0373 for ; Wed, 19 Mar 2014 21:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 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_62=0.6, RP_MATCHES_RCVD=-0.547, 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 iUYE0Uh5t1Zy for ; Wed, 19 Mar 2014 21:58:34 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 420571A035F for ; Wed, 19 Mar 2014 21:58:34 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jx11so345895veb.17 for ; Wed, 19 Mar 2014 21:58:25 -0700 (PDT) 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=+bIoh8LdZLC/9ZVe7EpTTjqP+F/Pzi/fk1fCu49WKaY=; b=EOcHgIN6BJBFbAwe8nzjBCohoOJADjI3NhkYveVBXac1WDkB16QuqZiWSZwK8+8gx8 e3/Jmqk3RjHcBF6rnFTdrEcsELiqQ0lOvnJiU7TPiJhjl2p/V0n5xlCILhMrefcFaDWU qmK2pvokL7g97GV4AD4rAeaG1wrwMwsjSfRbj6KpTOXbqC7HELoRZjAmUTJnII5165BD OQ8r/rSb146Qo1k0DjBE8cjTPEbYrPdw7+nQ2T7Ci5UiV4ED4hN546KSlXGDe3oTMvK1 rdIaO/eVhJiZyFT5hcIGEYOH875va7KHeGKPOTZFmSIONndiFm2G048oEudFtvMqtdal IYXg== 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=+bIoh8LdZLC/9ZVe7EpTTjqP+F/Pzi/fk1fCu49WKaY=; b=PDF+WThvEWSPAwkX34tblel3VrN0EEHNDlDmsbCqeGfaUU8bvAthaTKQMFaaL5NaP9 5fsSbT255SlcpzDKQwm5j4Mxb1OZi+DJBLTRAaei3r+KrX+rSStClqsfhYvUCpRYVLZo /gKQDn3z+EQF7j+lnA4uQtFHTaz9zJ7Jw/nQkeVYX9zAuaY3hcsmOvB1IaMYFwfxu2b7 ujYsXG1eSUmxtH2Mz1jJybtZzAEWcCI0m0ZwqVJazQuSeZDAe3l7BiEyn7Dhz0NU94Rs GT4Jjkh+y0L9VbzakVZp5FfmistSnTIoWQc9mntmFE4HWhYSakVQKnfejQYrsxcmY2qP +WmA== X-Gm-Message-State: ALoCoQm6TkShjE7ItW9C1+puoTbspQE3gYry5cnRQ6xRbwRbw9r8Ob4+Hn68tKkO8dqwoJs4sviVknyvapN6HxiYwrYHE8MTb7/mwiUnZxj4nRgOHSGkJmBcsCNAzmUG6GNrBDRxJPWpGUzK3CWZqFYP4/VRH2e7E+Nb5EHOfCBoUAB/zh0E1hkrLcY3QEx3LWsryjz9at4b X-Received: by 10.59.7.170 with SMTP id dd10mr32226913ved.12.1395291505085; Wed, 19 Mar 2014 21:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 21:58:05 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> From: Justin Uberti Date: Wed, 19 Mar 2014 21:58:05 -0700 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=047d7bdc988284fa1d04f5029e0c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bbQ5jVr6DXTmCxY-QOc_YwOTh9M Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 04:58:36 -0000 --047d7bdc988284fa1d04f5029e0c Content-Type: text/plain; charset=UTF-8 A few comments on things that were raised in this discussion: - Using port numbers to indicate errors is a slippery slope. But I'm not convinced it's even necessary; it's not clear to me that there's a case where the client needs to take different action based on the error code. If it is necessary, one solution might be to include ERROR-CODE attributes in the partial success message. - Client should not cache any information about the server other than for an active allocation. If SSODA isn't supported, there's little harm in trying again the next time. - SSODA should work fine for both TCP and UDP server connections. I don't see any difference here. - Regarding srflx candidates - there is no need for SSODA to try to get multiple srflx candidates; you just get srflx for the IPvX that you used to connect to the TURN server, which is fine. When you are dual-stack, you will connect from both interfaces to the TURN server. This is important because you want to use the same socket you use for TURN for ICE as well (this ensures proper working of peer-reflexive candidates learned from XOR-PEER-ADDRESS). The overall allocation sequence will yield these candidates (for a single-interface, dual-stack host, single dual-stack TURN server), prioritized in descending order: 1) host IPv6 2) host IPv4 3) srflx IPv6 (from TURN IPv6 conn) 4) srflx IPv4 (from TURN IPv4 conn) 5) relay IPv6 (from TURN IPv6 conn) 6) relay IPv6 (from TURN IPv4 conn) 7) relay IPv4 (from TURN IPv6 conn) 8) relay IPv4 (from TURN IPv4 conn) SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, 8 On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko wrote: > Hi Pal > > please see inline: > > > On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com> wrote: > >> >> >> >> Comment> >> How will the client ever know that the server has upgraded and now >> supports the new mechanism proposed in the draft ? >> May be the client once in a day can probe and find if the server supports >> multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. >> >> I guess so >> >> >> >> I do not think the client should cache this information. It just needs >> to know if it specks to a SSODA server,if it does not it might do more >> steps to get all the allocated RELAY addresses the client needs. >> > > My understanding is that a client app can be a very long-living client > app, and it can connect to both old and new TURN servers. And a TURN server > can be upgraded overnight. So the client app has to learn somehow at some > momemnt of time that the server has been upgraded. > > > >> >> >> 3) Security Considerations section is missing. (Section 2.2 is assuming >> client has already authenticated) >> >> >> I suppose that this document does not introduce any new security >> concerns (besides the ones we already have about TURN in general) >> >> [TR] Yes, you just need say something similar to the above line. >> >> >> It might have some positive security aspects. SSODA have the potential >> of reducing chatter between agent and TURN server. This means that the TURN >> server can put in more restrictive rate limiting hemes to restrict the >> number of allocate request it will handle without impacting the client. >> > > OK > > >> >> >> >> 5) Section 2.3 >> >> The allocated non-ANY address can be used, but the client >> SHOULD NOT try to allocate any of the unsupported families on a >> different 5-tuple. >> >> Comment> I guess the above line does not hold good for errors like >> "Insufficient capacity". >> >> >> >> Do you mean a use case when one family relay address can be allocated - >> but the other one can't - due to the exhaustion of capacity of that single >> address family ? That's true. But we do know that that address family >> cannot be allocated at the moment. So, I'd change the text to: >> >> ======================================= >> The allocated non-ANY address can be used, but the client SHOULD NOT try >> to allocate any of the unsupported families on a different 5-tuple within >> the subsequent 600 seconds interval. After that interval, the allocation >> can be re-tried. >> ======================================= >> >> Agree ? >> >> [TR] Yes >> >> I am unsure. >> >> This is a problem with the partial success scheme introduced in SSODA. >> The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We >> do not know the reason why the SSODA server used a ANY address. >> >> Can we use the port number in the ANY address to distinguish between >> insufficient capacity and address type not supported on this server? >> >> ANY:0 means address type not supported. I understand SSODA, but do not >> try to allocate this address on a different 5-tuple. This address type is >> disabled on this server. >> >> ANY:9 means insufficient resources. Try again later. >> >> Or is using port numbers like this a slippery slope? >> >> > I think that assigning special meanings to the port numbers is indeed > somewhat a slippery slope... but if we do want to do something like that, I > would suggest using standard error codes as the port numbers, not some > arbitrary values like 9. For example, "insufficient capacity" partial error > would be signaled as ANY:508 address value. > > Thanks > Oleg > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7bdc988284fa1d04f5029e0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few comments on things that were raised in this discussi= on:

- Using port numbers to indicate errors is a slipper= y slope. But I'm not convinced it's even necessary; it's not cl= ear to me that there's a case where the client needs to take different = action based on the error code. If it is necessary, one solution might be t= o include ERROR-CODE attributes in the partial success message.
- Client should not cache any information about the server other than = for an active allocation. If SSODA isn't supported, there's little = harm in trying again the next time.
- SSODA should work fine for = both TCP and UDP server connections. I don't see any difference here.
- Regarding srflx candidates - there is no need for SSODA to try to ge= t multiple srflx candidates; you just get srflx for the IPvX that you used = to connect to the TURN server, which is fine. When you are dual-stack, you = will connect from both interfaces to the TURN server. This is important bec= ause you want to use the same socket you use for TURN for ICE as well (this= ensures proper working of peer-reflexive candidates learned from XOR-PEER-= ADDRESS).

The overall allocation sequence will yield these candid= ates (for a single-interface, dual-stack host, single dual-stack TURN serve= r), prioritized in descending order:
1) host IPv6
2) host IPv4
3) srflx IPv6 (from TURN IPv6 conn)
4)= srflx IPv4 (from TURN IPv4 conn)
5) relay IPv6 (from TURN IPv6 c= onn)
6) relay IPv6 (from TURN IPv4 conn)
7) rel= ay IPv4 (from TURN IPv6 conn)
8) relay IPv4 (from TURN IPv4 conn)

SSO= DA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, 8



On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
Hi Pal

please see inline:
<= div class=3D"gmail_extra">

On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) <palmarti@cis= co.com> wrote:



Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
=C2=A0
I guess so
=C2=A0

I do not think the client should cache this information. It just= needs to know if it specks to a SSODA server,if it does not it might do mo= re steps to get all the allocated RELAY addresses the client needs.

My understanding is that= a client app can be a very long-living client app, and it can connect to b= oth old and new TURN servers. And a TURN server can be upgraded overnight. = So the client app has to learn somehow at some momemnt of time that the ser= ver has been upgraded.

=C2=A0
<= div style=3D"word-wrap:break-word">


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)
=C2=A0
I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general)
=C2=A0
[TR] Yes, you just need say something similar to the above line.

It might have some positive security aspects. SSODA have the pot= ential of reducing chatter between agent and TURN server. This means that t= he TURN server can put in more restrictive rate limiting hemes to restrict = the number of allocate request it will handle without impacting the client.
OK


=C2=A0


5) Section 2.3

=C2=A0 The allocated non-ANY address can be used, but the client
=C2=A0 =C2=A0SHOULD NOT try to allocate any of the unsupported families on = a
=C2=A0 =C2=A0different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

=C2=A0

Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single= address family ? That's true. But we do know that that address family = cannot be allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

I am unsure.

This is a problem with the partial success scheme introduced in SSODA.= The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. W= e do not know the reason why the SSODA server used a ANY address.=C2=A0

Can we use the port number in the ANY address to distinguish between i= nsufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not= try to allocate this address on a different 5-tuple. This address type is = disabled on this server.=C2=A0

ANY:9 means insufficient resources. Try again later.=C2=A0

Or is using port numbers like this a slippery slope?


I think=C2=A0 that= assigning special meanings to the port numbers is indeed somewhat a slippe= ry slope... but if we do want to do something like that, I would suggest us= ing standard=C2=A0 error codes as the port numbers, not some arbitrary valu= es like 9. For example, "insufficient capacity" partial error wou= ld be signaled as ANY:508 address value.

Thanks
Ole= g


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7bdc988284fa1d04f5029e0c-- From nobody Wed Mar 19 22:19:01 2014 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 6F6531A07FE for ; Wed, 19 Mar 2014 22:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=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 pLiVlxh_G6Gh for ; Wed, 19 Mar 2014 22:18:56 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 97CD71A06CC for ; Wed, 19 Mar 2014 22:18:56 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id x10so401201pdj.23 for ; Wed, 19 Mar 2014 22:18:47 -0700 (PDT) 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=a2VYQ8LLaNBe1CJwPWGTubzRKNVaaNgjHlT45AS9ZHw=; b=yp7Rd+7BqSXcOAVrGRlV3WVLX31IsSLXiams3+eDt0zms4guVge4iRHjqkqom267MT VlMf8J6MsXyXKUfcyvC7SKJu32S/TsBatN4+mIhAPhZ7MdDyEyPI3qnn0ejR1urNXsA6 7oO8Iyh1u5Oj0R8Wjzli8ifQeayqvFeYh4vs2ZjlCebJfB+u6R4Z2p91E4UNK5+i9YeG uRzzh5sUbutyiO9Se+1nCi69WDJWculid1mZTX8Wuh1OqN2hiDdDP4hf+LlyCzsUKyFG L4tlV+qGmyS/KvBb1lrPSbuE8OuI95fHzkeSNMVQnE6e1nUioMEueQfhF6PUoyClPTmq NAIA== MIME-Version: 1.0 X-Received: by 10.66.228.37 with SMTP id sf5mr43748723pac.19.1395292727829; Wed, 19 Mar 2014 22:18:47 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Wed, 19 Mar 2014 22:18:47 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> Date: Wed, 19 Mar 2014 22:18:47 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b111dd9666a1104f502e799 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tGjkf5Lfa613DJj7Zr0EB3DP5xA Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 05:18:59 -0000 --047d7b111dd9666a1104f502e799 Content-Type: text/plain; charset=ISO-8859-1 I agree. I suggested ANY:error_code only as an alternative to ANY:9. Overall, I think that we can assume that the allocation could not be completed for some reason and that can be retried later. Oleg On Wed, Mar 19, 2014 at 9:58 PM, Justin Uberti wrote: > A few comments on things that were raised in this discussion: > > - Using port numbers to indicate errors is a slippery slope. But I'm not > convinced it's even necessary; it's not clear to me that there's a case > where the client needs to take different action based on the error code. If > it is necessary, one solution might be to include ERROR-CODE attributes in > the partial success message. > - Client should not cache any information about the server other than for > an active allocation. If SSODA isn't supported, there's little harm in > trying again the next time. > - SSODA should work fine for both TCP and UDP server connections. I don't > see any difference here. > - Regarding srflx candidates - there is no need for SSODA to try to get > multiple srflx candidates; you just get srflx for the IPvX that you used to > connect to the TURN server, which is fine. When you are dual-stack, you > will connect from both interfaces to the TURN server. This is important > because you want to use the same socket you use for TURN for ICE as well > (this ensures proper working of peer-reflexive candidates learned from > XOR-PEER-ADDRESS). > > The overall allocation sequence will yield these candidates (for a > single-interface, dual-stack host, single dual-stack TURN server), > prioritized in descending order: > 1) host IPv6 > 2) host IPv4 > 3) srflx IPv6 (from TURN IPv6 conn) > 4) srflx IPv4 (from TURN IPv4 conn) > 5) relay IPv6 (from TURN IPv6 conn) > 6) relay IPv6 (from TURN IPv4 conn) > 7) relay IPv4 (from TURN IPv6 conn) > 8) relay IPv4 (from TURN IPv4 conn) > > SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, > 8 > > > > On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko wrote: > >> Hi Pal >> >> please see inline: >> >> >> On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) < >> palmarti@cisco.com> wrote: >> >>> >>> >>> >>> Comment> >>> How will the client ever know that the server has upgraded and now >>> supports the new mechanism proposed in the draft ? >>> May be the client once in a day can probe and find if the server >>> supports multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE >>> request. >>> >>> I guess so >>> >>> >>> >>> I do not think the client should cache this information. It just needs >>> to know if it specks to a SSODA server,if it does not it might do more >>> steps to get all the allocated RELAY addresses the client needs. >>> >> >> My understanding is that a client app can be a very long-living client >> app, and it can connect to both old and new TURN servers. And a TURN server >> can be upgraded overnight. So the client app has to learn somehow at some >> momemnt of time that the server has been upgraded. >> >> >> >>> >>> >>> 3) Security Considerations section is missing. (Section 2.2 is assuming >>> client has already authenticated) >>> >>> >>> I suppose that this document does not introduce any new security >>> concerns (besides the ones we already have about TURN in general) >>> >>> [TR] Yes, you just need say something similar to the above line. >>> >>> >>> It might have some positive security aspects. SSODA have the potential >>> of reducing chatter between agent and TURN server. This means that the TURN >>> server can put in more restrictive rate limiting hemes to restrict the >>> number of allocate request it will handle without impacting the client. >>> >> >> OK >> >> >>> >>> >>> >>> 5) Section 2.3 >>> >>> The allocated non-ANY address can be used, but the client >>> SHOULD NOT try to allocate any of the unsupported families on a >>> different 5-tuple. >>> >>> Comment> I guess the above line does not hold good for errors like >>> "Insufficient capacity". >>> >>> >>> >>> Do you mean a use case when one family relay address can be allocated - >>> but the other one can't - due to the exhaustion of capacity of that single >>> address family ? That's true. But we do know that that address family >>> cannot be allocated at the moment. So, I'd change the text to: >>> >>> ======================================= >>> The allocated non-ANY address can be used, but the client SHOULD NOT try >>> to allocate any of the unsupported families on a different 5-tuple within >>> the subsequent 600 seconds interval. After that interval, the allocation >>> can be re-tried. >>> ======================================= >>> >>> Agree ? >>> >>> [TR] Yes >>> >>> I am unsure. >>> >>> This is a problem with the partial success scheme introduced in SSODA. >>> The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We >>> do not know the reason why the SSODA server used a ANY address. >>> >>> Can we use the port number in the ANY address to distinguish between >>> insufficient capacity and address type not supported on this server? >>> >>> ANY:0 means address type not supported. I understand SSODA, but do not >>> try to allocate this address on a different 5-tuple. This address type is >>> disabled on this server. >>> >>> ANY:9 means insufficient resources. Try again later. >>> >>> Or is using port numbers like this a slippery slope? >>> >>> >> I think that assigning special meanings to the port numbers is indeed >> somewhat a slippery slope... but if we do want to do something like that, I >> would suggest using standard error codes as the port numbers, not some >> arbitrary values like 9. For example, "insufficient capacity" partial error >> would be signaled as ANY:508 address value. >> >> Thanks >> Oleg >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --047d7b111dd9666a1104f502e799 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree. I suggested ANY:error_code only as an altern= ative to ANY:9. Overall, I think that we can assume that the allocation cou= ld not be completed for some reason and that can be retried later.

Oleg


On Wed, Mar 19, 2014 at 9:58 PM, Justin Uberti <= ;juberti@google.com= > wrote:
A few comments on things th= at were raised in this discussion:

- Using port numbers = to indicate errors is a slippery slope. But I'm not convinced it's = even necessary; it's not clear to me that there's a case where the = client needs to take different action based on the error code. If it is nec= essary, one solution might be to include ERROR-CODE attributes in the parti= al success message.
- Client should not cache any information about the server other than = for an active allocation. If SSODA isn't supported, there's little = harm in trying again the next time.
- SSODA should work fine for = both TCP and UDP server connections. I don't see any difference here.
- Regarding srflx candidates - there is no need for SSODA to try to ge= t multiple srflx candidates; you just get srflx for the IPvX that you used = to connect to the TURN server, which is fine. When you are dual-stack, you = will connect from both interfaces to the TURN server. This is important bec= ause you want to use the same socket you use for TURN for ICE as well (this= ensures proper working of peer-reflexive candidates learned from XOR-PEER-= ADDRESS).

The overall allocation sequence will yield these candid= ates (for a single-interface, dual-stack host, single dual-stack TURN serve= r), prioritized in descending order:
1) host IPv6
2) host IPv4
3) srflx IPv6 (from TURN IPv6 conn)
4)= srflx IPv4 (from TURN IPv4 conn)
5) relay IPv6 (from TURN IPv6 c= onn)
6) relay IPv6 (from TURN IPv4 conn)
7) rel= ay IPv4 (from TURN IPv6 conn)
8) relay IPv4 (from TURN IPv4 conn)

SSO= DA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, 8



On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
Hi Pal

please see inline:
<= div class=3D"gmail_extra">

On Wed, M= ar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) <palmarti@cisco.com&= gt; wrote:



Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
=A0
I guess so
=A0

I do not think the client should cache this information. It just= needs to know if it specks to a SSODA server,if it does not it might do mo= re steps to get all the allocated RELAY addresses the client needs.

My understanding is that= a client app can be a very long-living client app, and it can connect to b= oth old and new TURN servers. And a TURN server can be upgraded overnight. = So the client app has to learn somehow at some momemnt of time that the ser= ver has been upgraded.

=A0


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)
=A0
I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general)
=A0
[TR] Yes, you just need say something similar to the above line.

It might have some positive security aspects. SSODA have the pot= ential of reducing chatter between agent and TURN server. This means that t= he TURN server can put in more restrictive rate limiting hemes to restrict = the number of allocate request it will handle without impacting the client.
OK


=A0


5) Section 2.3

=A0 The allocated non-ANY address can be used, but the client
=A0 =A0SHOULD NOT try to allocate any of the unsupported families on a
=A0 =A0different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

=A0

Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single= address family ? That's true. But we do know that that address family = cannot be allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

I am unsure.

This is a problem with the partial success scheme introduced in SSODA.= The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. W= e do not know the reason why the SSODA server used a ANY address.=A0

Can we use the port number in the ANY address to distinguish between i= nsufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not= try to allocate this address on a different 5-tuple. This address type is = disabled on this server.=A0

ANY:9 means insufficient resources. Try again later.=A0

Or is using port numbers like this a slippery slope?


I think=A0 that as= signing special meanings to the port numbers is indeed somewhat a slippery = slope... but if we do want to do something like that, I would suggest using= standard=A0 error codes as the port numbers, not some arbitrary values lik= e 9. For example, "insufficient capacity" partial error would be = signaled as ANY:508 address value.

Thanks
Oleg

<= /span>

___________________________________________= ____
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



--047d7b111dd9666a1104f502e799-- From nobody Thu Mar 20 01:59:35 2014 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 AA9D91A0691 for ; Thu, 20 Mar 2014 01:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.447 X-Spam-Level: X-Spam-Status: No, score=-14.447 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, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 JwuggY2-nGoj for ; Thu, 20 Mar 2014 01:59:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 08D4C1A034A for ; Thu, 20 Mar 2014 01:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24367; q=dns/txt; s=iport; t=1395305960; x=1396515560; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Uj63CuuCFGWURdUiqNmDSF3DpzV5EVmoayJ64HSgUnk=; b=AFaQ8b++sVNt5CCQ2Ue7q8dceM6nQHaq26Qa8MZu0vUcStP3LKSkoLd8 hayN32ud5X1OEeizdD1p/gAjM3Y2Zf3FeSG4TjAMWL+aBXltrNs7afsHG eZKqKLr8cQAMrQ9MWDfOeyFkQw6ioA60c+ziZ4XzoQ6xTi39yuAn04ZaK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FAJqtKlOtJV2b/2dsb2JhbABagkJEO1e7G4c0gRwWdIImAQEEAQEBawYFEAIBCA4xByEGCxQRAgQOBRuHSgMRDchoDYclEwSMTYE1IT4EB4MkgRQEiRqLQYF/gW2MaIVIgy2BaQIeBB4 X-IronPort-AV: E=Sophos;i="4.97,693,1389744000"; d="scan'208,217";a="311622294" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 20 Mar 2014 08:59:19 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2K8xJcL001794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 08:59:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.22]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 03:59:18 -0500 From: "Pal Martinsen (palmarti)" To: Justin Uberti Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZAM43PdanGEKAQmjn6WQD7QAckHsAABhwswAABuTlAAAO6ysAABk8/oAACGwzgA== Date: Thu, 20 Mar 2014 08:59:17 +0000 Message-ID: <1107CDF8-BDB7-404F-98CD-F38D3D9D42FB@cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.64.208] Content-Type: multipart/alternative; boundary="_000_1107CDF8BDB7404F98CDF38D3D9D42FBciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9hFWmyotRaaKCGyFsLrh1rsbmAo Cc: Oleg Moskalenko , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 08:59:33 -0000 --_000_1107CDF8BDB7404F98CDF38D3D9D42FBciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for summarising. On 20 Mar 2014, at 05:58, Justin Uberti > wrote: A few comments on things that were raised in this discussion: - Using port numbers to indicate errors is a slippery slope. But I'm not co= nvinced it's even necessary; it's not clear to me that there's a case where= the client needs to take different action based on the error code. If it i= s necessary, one solution might be to include ERROR-CODE attributes in the = partial success message. RFC4583 Distinguishes between port 0 and port 9 (Discard port). Distinguishing between address type not supported and address type temporar= ily exhausted is probably not important as the client should not keep state= for the next call. How do we deal with alternate server? Should we enable the possibility to s= end each address type to different servers. A fun engineering task, but wil= l probably get complicated and not solve many real world problems? - Client should not cache any information about the server other than for a= n active allocation. If SSODA isn't supported, there's little harm in tryin= g again the next time. +1 - SSODA should work fine for both TCP and UDP server connections. I don't s= ee any difference here. The connection between agent and TURN server or TURN-TCP? - Regarding srflx candidates - there is no need for SSODA to try to get mul= tiple srflx candidates; you just get srflx for the IPvX that you used to co= nnect to the TURN server, which is fine. When you are dual-stack, you will = connect from both interfaces to the TURN server. This is important because = you want to use the same socket you use for TURN for ICE as well (this ensu= res proper working of peer-reflexive candidates learned from XOR-PEER-ADDRE= SS). I think dual stacked host can benefit from SSODA as well. Use IPvX to alloc= ate the RELAY addresses. The reflexive candidate of IPvY needs to be learnt= with a STUN binding request. This saves the TURN server for work like chec= king credentials, alternate server might kick in, ++. Only drawback is in some cases you might end up converting from IPvX to IPv= Y on the TURN server. Not sure how expensive such an IP address translation= is? Peer reflexive adresses are learnt when sending a STUN binding request from= your HOST address towards any of the remote HOST, RFLX or RELAY candidates= . If the XOR-PEER-ADDRESS in the STUN Binding Response differs from your SR= FLX previously discovered it is a PRFLX candidate. I do not see the need fo= r a direct mapping of HOST addr type and RELAY addr type necessary. Or? In a IPv6 deployment you might get lucky and get a PRFLX candidate without = having SRFLX candidate. Dependant on the remote side setup. This is useful = in a webRTC Trickle ICE scenario where you must chose if you want to spend = time slots on connectivity checks or candidate gathering. The overall allocation sequence will yield these candidates (for a single-i= nterface, dual-stack host, single dual-stack TURN server), prioritized in d= escending order: 1) host IPv6 2) host IPv4 3) srflx IPv6 (from TURN IPv6 conn) 4) srflx IPv4 (from TURN IPv4 conn) 5) relay IPv6 (from TURN IPv6 conn) 6) relay IPv6 (from TURN IPv4 conn) 7) relay IPv4 (from TURN IPv6 conn) 8) relay IPv4 (from TURN IPv4 conn) SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, = 8 I would like fewer candidates 1) host IPv6 2) host IPv4 3) srflx IPv4 (From SSODA allocate Request) 4) srflx IPv6 (STUN Binding Request, With Trickle Ice might be deferred to = later stage) 5) relay IPv4 (From SSODA Allocate Request) 6) relay IPv6 (FROM SSODA Allocate Request) The client needs to take some decision on how to contact the TURN server. T= here should be a discovery mechanism for that.. Not just IPv4 or IPv6, but = UDP, TCP, TLS and DTLS as well. .-. P=E5l-Erik On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko > wrote: Hi Pal please see inline: On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) > wrote: Comment> How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ? May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request. I guess so I do not think the client should cache this information. It just needs to k= now if it specks to a SSODA server,if it does not it might do more steps to= get all the allocated RELAY addresses the client needs. My understanding is that a client app can be a very long-living client app,= and it can connect to both old and new TURN servers. And a TURN server can= be upgraded overnight. So the client app has to learn somehow at some mome= mnt of time that the server has been upgraded. 3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated) I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general) [TR] Yes, you just need say something similar to the above line. It might have some positive security aspects. SSODA have the potential of r= educing chatter between agent and TURN server. This means that the TURN ser= ver can put in more restrictive rate limiting hemes to restrict the number = of allocate request it will handle without impacting the client. OK 5) Section 2.3 The allocated non-ANY address can be used, but the client SHOULD NOT try to allocate any of the unsupported families on a different 5-tuple. Comment> I guess the above line does not hold good for errors like "Insuffi= cient capacity". Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single add= ress family ? That's true. But we do know that that address family cannot b= e allocated at the moment. So, I'd change the text to: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agree ? [TR] Yes I am unsure. This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server? ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. ANY:9 means insufficient resources. Try again later. Or is using port numbers like this a slippery slope? I think that assigning special meanings to the port numbers is indeed some= what a slippery slope... but if we do want to do something like that, I wou= ld suggest using standard error codes as the port numbers, not some arbitr= ary values like 9. For example, "insufficient capacity" partial error would= be signaled as ANY:508 address value. Thanks Oleg _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_1107CDF8BDB7404F98CDF38D3D9D42FBciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <19777BF597B24044A4D4E36AF3088F5D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Thanks for summarising. 

On 20 Mar 2014, at 05:58, Justin Uberti <juberti@google.com> wrote:

A few comments on things that were raised in this discussi= on:

- Using port numbers to indicate errors is a slippery slope. But I'm n= ot convinced it's even necessary; it's not clear to me that there's a case = where the client needs to take different action based on the error code. If= it is necessary, one solution might be to include ERROR-CODE attributes in the partial success message.

RFC4583 Distinguishes between port 0 and port 9 (Discard port). <= /div>

Distinguishing between address type not supported and address type tem= porarily exhausted is probably not important as the client should not keep = state for the next call. 

How do we deal with alternate server? Should we enable the possibility= to send each address type to different servers. A fun engineering task, bu= t will probably get complicated and not solve many real world problems?

- Client should not cache any information about the server other than = for an active allocation. If SSODA isn't supported, there's little harm in = trying again the next time.

+1
- SSODA should work fine for both TCP and UDP server connections. I do= n't see any difference here.

The connection between agent and TURN server or TURN-TCP?

- Regarding srflx candidates - there is no need for SSODA to try to ge= t multiple srflx candidates; you just get srflx for the IPvX that you used = to connect to the TURN server, which is fine. When you are dual-stack, you = will connect from both interfaces to the TURN server. This is important because you want to use the same soc= ket you use for TURN for ICE as well (this ensures proper working of peer-r= eflexive candidates learned from XOR-PEER-ADDRESS).


I think dual stacked host can benefit from SSODA as well. Use IPvX to = allocate the RELAY addresses. The reflexive candidate of IPvY needs to be l= earnt with a STUN binding request. This saves the TURN server for work like= checking credentials, alternate server might kick in, ++.

Only drawback is in some cases you might end up converting from IPvX t= o IPvY on the TURN server. Not sure how expensive such an IP address transl= ation is?

Peer reflexive adresses are learnt when sending a STUN binding request= from your HOST address towards any of the remote HOST, RFLX or RELAY candi= dates. If the XOR-PEER-ADDRESS in the STUN Binding Response differs from yo= ur SRFLX previously discovered it is a PRFLX candidate. I do not see the need for a direct mapping of HOST a= ddr type and RELAY addr type necessary. Or?

In a IPv6 deployment you might get lucky and get a PRFLX candidate wit= hout having SRFLX candidate. Dependant on the remote side setup. This is us= eful in a webRTC Trickle ICE scenario where you must chose if you want to s= pend time slots on connectivity checks or candidate gathering. 


The overall allocation sequence will yield these candidates (for a sin= gle-interface, dual-stack host, single dual-stack TURN server), prioritized= in descending order:
1) host IPv6
2) host IPv4
3) srflx IPv6 (from TURN IPv6 conn)
4) srflx IPv4 (from TURN IPv4 conn)
5) relay IPv6 (from TURN IPv6 conn)
6) relay IPv6 (from TURN IPv4 conn)
7) relay IPv4 (from TURN IPv6 conn)
8) relay IPv4 (from TURN IPv4 conn)

SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4= , 6, 8


I would like fewer candidates

1) host IPv6
2) host IPv4
3) srflx IPv4 (From SSODA allocate Request)
4) srflx IPv6 (STUN Binding Request, With Trickle Ice might be deferre= d to later stage)
5) relay IPv4 (From SSODA Allocate Request)
6) relay IPv6 (FROM SSODA Allocate Request)

The client needs to take some decision on how to contact the TURN serv= er. There should be a discovery mechanism for that.. Not just IPv4 or IPv6,= but UDP, TCP, TLS and DTLS as well. 

.-.
P=E5l-Erik




On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko= <mom040267@gmai= l.com> wrote:
Hi Pal

please see inline:


On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) <= span dir=3D"ltr"> <palmarti@cisco.= com> wrote:



Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
 
I guess so
 

I do not think the client should cache this information. It just needs= to know if it specks to a SSODA server,if it does not it might do more ste= ps to get all the allocated RELAY addresses the client needs.

My understanding is that a client app can be a very long-living client= app, and it can connect to both old and new TURN servers. And a TURN serve= r can be upgraded overnight. So the client app has to learn somehow at some= momemnt of time that the server has been upgraded.

 


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)
 
I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general)
 
[TR] Yes, you just need say something similar to the above line.

It might have some positive security aspects. SSODA have the potential= of reducing chatter between agent and TURN server. This means that the TUR= N server can put in more restrictive rate limiting hemes to restrict the nu= mber of allocate request it will handle without impacting the client.

OK


 


5) Section 2.3

  The allocated non-ANY address can be used, but the client
   SHOULD NOT try to allocate any of the unsupported families on = a
   different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

 

Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single add= ress family ? That's true. But we do know that that address family cannot b= e allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

I am unsure.

This is a problem with the partial success scheme introduced in SSODA.= The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. W= e do not know the reason why the SSODA server used a ANY address. 

Can we use the port number in the ANY address to distinguish between i= nsufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not= try to allocate this address on a different 5-tuple. This address type is = disabled on this server. 

ANY:9 means insufficient resources. Try again later. 

Or is using port numbers like this a slippery slope?


I think  that assigning special meanings to the port numbers is i= ndeed somewhat a slippery slope... but if we do want to do something like t= hat, I would suggest using standard  error codes as the port numbers, = not some arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:5= 08 address value.

Thanks
Oleg


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



--_000_1107CDF8BDB7404F98CDF38D3D9D42FBciscocom_-- From nobody Thu Mar 20 06:29:48 2014 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 CE6DD1A08C6 for ; Thu, 20 Mar 2014 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 H2kMI96KBACs for ; Thu, 20 Mar 2014 06:29:45 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 141BF1A06D2 for ; Thu, 20 Mar 2014 06:29:45 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C067040233 for ; Thu, 20 Mar 2014 09:29:35 -0400 (EDT) Message-ID: <532AED3F.4050801@viagenie.ca> Date: Thu, 20 Mar 2014 09:29:35 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/t0zPsFV4eWHIdisUwsH0Cl8zN50 Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 13:29:47 -0000 Le 2014-03-20 00:58, Justin Uberti a écrit : > The overall allocation sequence will yield these candidates (for a > single-interface, dual-stack host, single dual-stack TURN server), > prioritized in descending order: > 1) host IPv6 > 2) host IPv4 > 3) srflx IPv6 (from TURN IPv6 conn) > 4) srflx IPv4 (from TURN IPv4 conn) > 5) relay IPv6 (from TURN IPv6 conn) > 6) relay IPv6 (from TURN IPv4 conn) > 7) relay IPv4 (from TURN IPv6 conn) > 8) relay IPv4 (from TURN IPv4 conn) > > SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, 6, 8 Great summary. Makes total sense. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 20 06:51:42 2014 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 52F3A1A074E for ; Thu, 20 Mar 2014 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 asNGIURVXIL0 for ; Thu, 20 Mar 2014 06:51:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4676B1A06CF for ; Thu, 20 Mar 2014 06:51:33 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 315E340233 for ; Thu, 20 Mar 2014 09:51:24 -0400 (EDT) Message-ID: <532AF25B.4020301@viagenie.ca> Date: Thu, 20 Mar 2014 09:51:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nbQDo8DV8TZKsEe2ReYCyz-JMUU Subject: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 13:51:35 -0000 Tramsters, During the meeting in London there was a mixed reaction to the presentation of draft-patil-tram-turn-serv-disc-00. We heard very few hums both for and against adoption. As a reminder, here is the related milestone: Sep 2014 - Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard I'd like people to respond to this email explaining their position regarding the presented solution. Why do you (not) support it? What is missing? What would be a good solution in your opinion? It seems we did not have time to fully discuss those questions face-to-face, so let's do it here. Basically, the draft proposes two mechanisms: DHCP and anycast. We know each of these solutions has drawbacks which were well discussed. The question is: are they deal breakers, or could we live with them? WPAD was also discussed. The main issue seems to be that WPAD is not really standardized anywhere. IMHO this issue can be worked around if the solution is good technically. So, how is it technically? Would it work? What are the drawbacks? I don't think this has been discussed enough. Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for inspiration. As I understand it, that solution relies on the client's IP address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records pointing to the network-provided TURN server. Can this work? This is a new idea for which I have not seen any discussion yet. Let's solve this! Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 20 07:08:35 2014 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 8297D1A075C for ; Thu, 20 Mar 2014 07:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3G3KbpI0k16 for ; Thu, 20 Mar 2014 07:08:28 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B00991A08DD for ; Thu, 20 Mar 2014 07:08:09 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn9so6270934wib.4 for ; Thu, 20 Mar 2014 07:08:00 -0700 (PDT) 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=Yke4U6o2AiQrvk0r2jxPLvWv+2d9/drJpqnY9dR4txg=; b=HljQs8lw/NVH8iHgmMZWN44hMSQUkSDvocEQVlnUrcMvLIFchMEmI3U6GIJ3WQFjj4 3EOU3tGWRQ/GBsMXZ0yVvYOomJBk1kmpexk1on5VRYr+Hm5blI1tVV0bqXQBgmUf0clg Y55bJlMGaXH1zHUmMw1Wou6+PCepV0UqNCDZ0sdqMlT2RX0e0aJ3cY1CXRgEdYzt5YmY R6H5GbqC1lbGiHQ3GfLeKzol4bFR6PPVjqN7IrdPzgPkODT1uyB7YWFgyMnlKYSW5mSh vJ8ikkKRBQf4JZbJS1qAfzfQXVB4frxP1nRO6zjByXS03Dj5YOHRhtdvxq5Eej0Smjnw D/xw== MIME-Version: 1.0 X-Received: by 10.180.149.143 with SMTP id ua15mr23767984wib.36.1395324480256; Thu, 20 Mar 2014 07:08:00 -0700 (PDT) Received: by 10.216.106.130 with HTTP; Thu, 20 Mar 2014 07:08:00 -0700 (PDT) Received: by 10.216.106.130 with HTTP; Thu, 20 Mar 2014 07:08:00 -0700 (PDT) In-Reply-To: <532AF25B.4020301@viagenie.ca> References: <532AF25B.4020301@viagenie.ca> Date: Thu, 20 Mar 2014 07:08:00 -0700 Message-ID: From: Cb B To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c38e70fe010204f50a4b3a Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ldiwkH1WP16b65zwtJ7HjrRJSAI Cc: tram@ietf.org Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 14:08:30 -0000 --001a11c38e70fe010204f50a4b3a Content-Type: text/plain; charset=ISO-8859-1 On Mar 20, 2014 6:51 AM, "Simon Perreault" wrote: > > Tramsters, > > During the meeting in London there was a mixed reaction to the > presentation of draft-patil-tram-turn-serv-disc-00. We heard very few > hums both for and against adoption. > > As a reminder, here is the related milestone: > > Sep 2014 - Send new TURN server discovery mechanism for enterprises and > ISPs to IESG for publication as Proposed Standard > > I'd like people to respond to this email explaining their position > regarding the presented solution. Why do you (not) support it? What is > missing? What would be a good solution in your opinion? It seems we did > not have time to fully discuss those questions face-to-face, so let's do > it here. > > Basically, the draft proposes two mechanisms: DHCP and anycast. We know > each of these solutions has drawbacks which were well discussed. The > question is: are they deal breakers, or could we live with them? > > WPAD was also discussed. The main issue seems to be that WPAD is not > really standardized anywhere. IMHO this issue can be worked around if > the solution is good technically. So, how is it technically? Would it > work? What are the drawbacks? I don't think this has been discussed enough. > > Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for > inspiration. As I understand it, that solution relies on the client's IP > address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse > zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records > pointing to the network-provided TURN server. Can this work? This is a > new idea for which I have not seen any discussion yet. > > Let's solve this! > Just adding a data point, mobile networks generally don't use dhcp so that limits the scope of dhcp as an option. I anticipate mobile networks will need TURN. CB > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --001a11c38e70fe010204f50a4b3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 20, 2014 6:51 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:
>
> Tramsters,
>
> During the meeting in London there was a mixed reaction to the
> presentation of draft-patil-tram-turn-serv-disc-00. We heard very few<= br> > hums both for and against adoption.
>
> As a reminder, here is the related milestone:
>
> Sep 2014 - Send new TURN server discovery mechanism for enterprises an= d
> ISPs to IESG for publication as Proposed Standard
>
> I'd like people to respond to this email explaining their position=
> regarding the presented solution. Why do you (not) support it? What is=
> missing? What would be a good solution in your opinion? It seems we di= d
> not have time to fully discuss those questions face-to-face, so let= 9;s do
> it here.
>
> Basically, the draft proposes two mechanisms: DHCP and anycast. We kno= w
> each of these solutions has drawbacks which were well discussed. The > question is: are they deal breakers, or could we live with them?
>
> WPAD was also discussed. The main issue seems to be that WPAD is not > really standardized anywhere. IMHO this issue can be worked around if<= br> > the solution is good technically. So, how is it technically? Would it<= br> > work? What are the drawbacks? I don't think this has been discusse= d enough.
>
> Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for=
> inspiration. As I understand it, that solution relies on the client= 9;s IP
> address "owner" (e.g. the ISP or enterprise) to populate the= DNS reverse
> zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records > pointing to the network-provided TURN server. Can this work? This is a=
> new idea for which I have not seen any discussion yet.
>
> Let's solve this!
>

Just adding a data point, mobile networks generally don'= t use dhcp so that limits the scope of dhcp as an option.

I anticipate mobile networks will need TURN.

CB
> Thanks,
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
> STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.iet= f.org/mailman/listinfo/tram

--001a11c38e70fe010204f50a4b3a-- From nobody Thu Mar 20 07:45:17 2014 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 15AB71A08E9 for ; Thu, 20 Mar 2014 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 4Dm9mjzRh60s for ; Thu, 20 Mar 2014 07:45:11 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id C0B7E1A08E7 for ; Thu, 20 Mar 2014 07:45:07 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id fnnu1n0050vyq2s58qkyRk; Thu, 20 Mar 2014 14:44:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id fqky1n00b3ZTu2S3Rqkyx4; Thu, 20 Mar 2014 14:44:58 +0000 Message-ID: <532AFEEA.2060801@alum.mit.edu> Date: Thu, 20 Mar 2014 10:44:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <532AF25B.4020301@viagenie.ca> In-Reply-To: <532AF25B.4020301@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395326698; bh=0bgjtx7QmUBDumZX5De3436LxBDURcYllp6vuGSgXac=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WkY9mmSUjFUjSokyKXNmZo9CofOUvyln4DHyiK1VD/nF7Pd74K2vNldc7IfdOLGMc QQj4b9BctAKxjCRpeHdO/vRCFeCsARBckmu32zMYFxNhF8aRktlwDb7voSP+5kckIN X/UpZNWtR4wMBBaZIsaUsL2ojBjWWzpJ6s3atwbyXK+KsS962naiWHWqk2aDMP381/ Mf7AesWhzFF9+AKk9XmIgKbSMynfyXfjri5stvW6RFlS6ao7sKa1mzQU1GyerooVJF Iit3rd+a5LkyZK8ygJGsoSbMSgsXxWxAFi703H/moWr/UWTKvyfMgsOtItPDPTA7db 3ia9j9441Vtpg== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/GTxM9aSDEIoQFyWDR1yrtTnLzLs Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 14:45:16 -0000 I made a suggestion back in february: http://www.ietf.org/mail-archive/web/tram/current/msg00156.html IMO there are important use cases for that, and it is worth mentioning. Thanks, Paul On 3/20/14 9:51 AM, Simon Perreault wrote: > Tramsters, > > During the meeting in London there was a mixed reaction to the > presentation of draft-patil-tram-turn-serv-disc-00. We heard very few > hums both for and against adoption. > > As a reminder, here is the related milestone: > > Sep 2014 - Send new TURN server discovery mechanism for enterprises and > ISPs to IESG for publication as Proposed Standard > > I'd like people to respond to this email explaining their position > regarding the presented solution. Why do you (not) support it? What is > missing? What would be a good solution in your opinion? It seems we did > not have time to fully discuss those questions face-to-face, so let's do > it here. > > Basically, the draft proposes two mechanisms: DHCP and anycast. We know > each of these solutions has drawbacks which were well discussed. The > question is: are they deal breakers, or could we live with them? > > WPAD was also discussed. The main issue seems to be that WPAD is not > really standardized anywhere. IMHO this issue can be worked around if > the solution is good technically. So, how is it technically? Would it > work? What are the drawbacks? I don't think this has been discussed enough. > > Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for > inspiration. As I understand it, that solution relies on the client's IP > address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse > zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records > pointing to the network-provided TURN server. Can this work? This is a > new idea for which I have not seen any discussion yet. > > Let's solve this! > > Thanks, > Simon > From nobody Thu Mar 20 07:48:17 2014 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 92EFA1A08E9 for ; Thu, 20 Mar 2014 07:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 aNmGo_1zPCgi for ; Thu, 20 Mar 2014 07:48:12 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA841A074E for ; Thu, 20 Mar 2014 07:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2486; q=dns/txt; s=iport; t=1395326883; x=1396536483; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=r/0kkrUH6pFcVEqK+WL9P1qVif0msgbZx1aRmQbSNKE=; b=fNuW9Iw7LnfK78Mjl2VZe1BDhaI3JnhfyPiT9w/qlWf/iAqzRyjnMlw4 MvMGx+lz2E3lTW8X/vvKuudtPRdE/Ii+CSNbuPy9lRv0aFgbgrrMXNgkI 3Bk78wKwrmghTNH+22/XHMBEov090p9yc134MfmwArPyEk0DwCy7qmnUx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFACb/KlOtJXG//2dsb2JhbABQCYMGO1e7G4czgRgWdIImAQEEAQEBJBM0GwIBCDYQJwslAgQBEgkSh14Nz1YXjgIBBwcCAgFRBYQ4BJhHgTKQfoMtgis X-IronPort-AV: E=Sophos;i="4.97,695,1389744000"; d="scan'208";a="29008292" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 20 Mar 2014 14:48:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2KEm36V001604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 14:48:03 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 09:48:03 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: AQHPREtlatIbewbwn0WFgqmF2DvJFA== Date: Thu, 20 Mar 2014 14:48:02 +0000 Message-ID: References: <532AF25B.4020301@viagenie.ca> In-Reply-To: <532AF25B.4020301@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.127.18.26] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6w9vusRnmHq6_lk702xsdkFoPjQ Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 14:48:14 -0000 On 3/20/14 7:21 PM, "Simon Perreault" wrote: >Tramsters, > >During the meeting in London there was a mixed reaction to the >presentation of draft-patil-tram-turn-serv-disc-00. We heard very few >hums both for and against adoption. > >As a reminder, here is the related milestone: > >Sep 2014 - Send new TURN server discovery mechanism for enterprises and >ISPs to IESG for publication as Proposed Standard > >I'd like people to respond to this email explaining their position >regarding the presented solution. Why do you (not) support it? What is >missing? What would be a good solution in your opinion? It seems we did >not have time to fully discuss those questions face-to-face, so let's do >it here. > >Basically, the draft proposes two mechanisms: DHCP and anycast. We know >each of these solutions has drawbacks which were well discussed. The >question is: are they deal breakers, or could we live with them? The first mechanism is actually Service Resolution. The draft suggests DHCP as the primary means to obtain a domain name which can be used for service resolution. There was a suggestion that domain name could also be extracted from own SIP/XMPP/email identity (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- which we plan to add to the draft in the next version. -Prashanth > >WPAD was also discussed. The main issue seems to be that WPAD is not >really standardized anywhere. IMHO this issue can be worked around if >the solution is good technically. So, how is it technically? Would it >work? What are the drawbacks? I don't think this has been discussed >enough. > >Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for >inspiration. As I understand it, that solution relies on the client's IP >address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse >zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records >pointing to the network-provided TURN server. Can this work? This is a >new idea for which I have not seen any discussion yet. > >Let's solve this! > >Thanks, >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Thu Mar 20 07:49:15 2014 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 6CB411A08E6 for ; Thu, 20 Mar 2014 07:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, 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 FrGYtjZAEQsR for ; Thu, 20 Mar 2014 07:49:07 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id CB1391A08ED for ; Thu, 20 Mar 2014 07:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8805; q=dns/txt; s=iport; t=1395326927; x=1396536527; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IPf4vajeDk7lVmJDFhzS44Tae+3xNSLlmqcuGbNMlDE=; b=haSamQ5cr5D7Jr9XBMt0K8LZY41aHTR3iyLTPbUXJnfJOvnrvPbYZP4h q4EXM7yET/eSmHuTK4PR8VhJ9rfPpIhdM1hZDESgeAjK5Ohrd8sohTmHM 4A24YS86vTko2z0VMk3dnVX6p9GJtcSB+I3gMM0nw18JVI4BortR8uF8E s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFADL/KlOtJV2Z/2dsb2JhbABZgkJEO1eFaLN1iHGBGBZ0giYBAQQtTBACAQgiJDIlAgQBDQ0Th14Nz1UXjjQxB4MkgRQEmXmQfoMtgis X-IronPort-AV: E=Sophos; i="4.97,695,1389744000"; d="scan'208,217"; a="29020399" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 20 Mar 2014 14:48:46 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2KEmk7u003272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 14:48:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 09:48:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cb B , Simon Perreault Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: AQHPREOE1UDf9oubAkWwBYvhNFfsfZrqVuQA//+xblA= Date: Thu, 20 Mar 2014 14:48:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D8EFD@xmb-rcd-x10.cisco.com> References: <532AF25B.4020301@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.182] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242D8EFDxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5uxhVF5Xmye_cpIIdgLOL9-WY1s Cc: "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 14:49:09 -0000 --_000_913383AAA69FF945B8F946018B75898A242D8EFDxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just adding a data point, mobile networks generally don't use dhcp so that = limits the scope of dhcp as an option. I anticipate mobile networks will need TURN. CB [TR] we had discussed similar problem to discover PCP servers in Mobile Networks= (http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-04#section-4)= sometime back. Based on the discussion 1)DHCPv6 stateless configuration information is supported by 3GPP specifica= tion (http://tools.ietf.org/html/rfc6459#section-5.2) 2)Since DHCPv4 is not widely used, possible solutions discussed to solve th= e problem are anycast, enhancing PCO to provide TURN {PCP} server IP addres= s -Tiru --_000_913383AAA69FF945B8F946018B75898A242D8EFDxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just adding a data point, mobile networks generally don't use dhcp so th= at limits the scope of dhcp as an option.

I anticipate mobile networks will need TURN.

CB

[TR]

 <= /p>

we had discussed similar = problem to discover PCP servers in Mobile Networks (http://tools.= ietf.org/html/draft-chen-pcp-mobile-deployment-04#section-4) sometime back. Based on the discussion

1)DHCPv6 stateless config= uration information is supported by 3GPP specification (http://tools.ietf.org/html/rfc6459#= section-5.2) 

2)Since DHCPv4 is not widely used, possible=
 solutions discussed to solve the problem are anycast, enhancing PCO to pro=
vide TURN {PCP} server IP address
 
-Tiru
--_000_913383AAA69FF945B8F946018B75898A242D8EFDxmbrcdx10ciscoc_-- From nobody Thu Mar 20 08:03:36 2014 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 8741A1A076E for ; Thu, 20 Mar 2014 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GXYqwCDtvjD for ; Thu, 20 Mar 2014 08:03:32 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD221A0764 for ; Thu, 20 Mar 2014 08:03:31 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 3B5EF93DE3C; Thu, 20 Mar 2014 15:03:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_A217A78A-3B36-4F1C-AD91-3982A6A690DB" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <913383AAA69FF945B8F946018B75898A242D8EFD@xmb-rcd-x10.cisco.com> Date: Thu, 20 Mar 2014 16:03:18 +0100 Message-Id: References: <532AF25B.4020301@viagenie.ca> <913383AAA69FF945B8F946018B75898A242D8EFD@xmb-rcd-x10.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QdtTcOxQXsbj2mb3PVIs8sZwJ6Q Cc: Simon Perreault , Cb B , Olle E Johansson , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 15:03:35 -0000 --Apple-Mail=_A217A78A-3B36-4F1C-AD91-3982A6A690DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Mar 2014, at 15:48, Tirumaleswar Reddy (tireddy) = wrote: > Just adding a data point, mobile networks generally don't use dhcp so = that limits the scope of dhcp as an option. >=20 > I anticipate mobile networks will need TURN. >=20 While DHCP is working fine for devices like IP phones, it will not work = for applications running in an operating system. I don't know how to = discover DHCP options from an app - is there an API for that? /O --Apple-Mail=_A217A78A-3B36-4F1C-AD91-3982A6A690DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 20 Mar 2014, at 15:48, Tirumaleswar = Reddy (tireddy) <tireddy@cisco.com> = wrote:

Just adding a data point, mobile networks generally don't use = dhcp so that limits the scope of dhcp as an option.

I anticipate mobile networks = will need TURN.

While DHCP is = working fine for devices like IP phones, it will not work for = applications running in an operating system. I don't know how to = discover DHCP options from an app - is there an API for = that?

/O

= --Apple-Mail=_A217A78A-3B36-4F1C-AD91-3982A6A690DB-- From nobody Thu Mar 20 08:30:10 2014 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 609421A08EF for ; Thu, 20 Mar 2014 08:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 eBAZFiiCC63c for ; Thu, 20 Mar 2014 08:30:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A34C71A08FF for ; Thu, 20 Mar 2014 08:30:06 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 41C66403B0; Thu, 20 Mar 2014 11:29:57 -0400 (EDT) Message-ID: <532B0974.1010404@viagenie.ca> Date: Thu, 20 Mar 2014 11:29:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <532AF25B.4020301@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/e5lA9cXy9vsOry7lTDyW-EN7HJI Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 15:30:08 -0000 Le 2014-03-20 10:48, Prashanth Patil (praspati) a écrit : > There was a suggestion that domain name could also be > extracted from own SIP/XMPP/email identity > (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- which > we plan to add to the draft in the next version. But that doesn't work because it would be an application-provided TURN server. We need to discover network-provided TURN servers. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 20 08:39:39 2014 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 91C3D1A0750 for ; Thu, 20 Mar 2014 08:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 PGQtrJWcb3eL for ; Thu, 20 Mar 2014 08:39:34 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 524241A03FD for ; Thu, 20 Mar 2014 08:39:34 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/20/2014 11:39:24 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-405/SG:5 3/20/2014 11:38:37 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.909264 p=-0.982627 Source White X-Signature-Violations: 0-0-0-15770-c X-Note-419: 31.201 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/20/2014 11:39:18 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 107673824; Thu, 20 Mar 2014 11:39:23 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 20 Mar 2014 10:39:23 -0500 From: Jonathan Lennox To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZJGocJ2jdTwSef3K1BegT6wAckHsAAA27zZAAEZsigAAO6dQAAAnJFIAAJdlvAA== Date: Thu, 20 Mar 2014 15:39:22 +0000 Message-ID: <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.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: multipart/alternative; boundary="_000_22471A072B9F4AB49168DD4F3DFC21CBvidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bYB6ILoSZkjBy0NZO6M1pPGl2u8 Cc: Oleg Moskalenko , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 15:39:36 -0000 --_000_22471A072B9F4AB49168DD4F3DFC21CBvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don=92t think using XOR-RELAYED-ADDRESS with ANY to mean partial failure = is a good idea. STUN attributes are cheap. I suggest an a new attribute UNAVAILABLE-ADDRES= S-FAMILY, which can be sent in an SSODA success response. If we want to be= able to distinguish reasons for unavailability, the attribute can be forma= tted as address-family/error-code/reason-phrase. In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure resp= onses as well, if people think it would be useful to be able to describe ca= ses where the IPv4 and IPv6 allocations failed for different reasons. Additionally =97 I don=92t like SSODA=92s mechanism of deliberately trigger= ing behavior that=92s undefined according to RFC 6156. It seems like this = will be fragile. I=92d suggest instead that we define a comprehension-opti= onal ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically t= o REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN server will use but a = strict 6156 TURN server will ignore. On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) > wrote: Inline [TR] I am unsure. This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server? ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. ANY:9 means insufficient resources. Try again later. Or is using port numbers like this a slippery slope? I think that assigning special meanings to the port numbers is indeed some= what a slippery slope... but if we do want to do something like that, I wou= ld suggest using standard error codes as the port numbers, not some arbitr= ary values like 9. For example, "insufficient capacity" partial error would= be signaled as ANY:508 address value. [TR] There are two types of errors long-term (unsupported family), short-te= rm (insufficient capacity, quota exceeded etc.). For the short-term errors,= the server can suggest the client to re-try after specific duration. I don= =92t think it=92s a good idea to populate error codes in the port field. -Tiru Thanks Oleg _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_22471A072B9F4AB49168DD4F3DFC21CBvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <49B88404FB473B44B429B7ECDDFB4D5F@vidyo.com> Content-Transfer-Encoding: quoted-printable
I don=92t think using XOR-RELAYED-ADDRESS with ANY to mean partial fai= lure is a good idea.

STUN attributes are cheap.  I suggest an a new attribute UNAVAILA= BLE-ADDRESS-FAMILY, which can be sent in an SSODA success response.  I= f we want to be able to distinguish reasons for unavailability, the attribu= te can be formatted as address-family/error-code/reason-phrase.

In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure= responses as well, if people think it would be useful to be able to descri= be cases where the IPv4 and IPv6 allocations failed for different reasons.&= nbsp;

Additionally =97 I don=92t like SSODA=92s mechanism of deliberately tr= iggering behavior that=92s undefined according to RFC 6156.  It seems = like this will be fragile.  I=92d suggest instead that we define a com= prehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSOD= A-aware TURN server will use but a strict 6156 TURN server will ignore.
On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Inline [TR]
 
I am unsure.
 
This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. 
 
Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server?
 
ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. 
 
ANY:9 means insufficient resources. Try again later. 
 
Or is using port numbers like this a slippery slope?
 

I think  that assigning special meanings to the port numbers is indeed= somewhat a slippery slope... but if we do want to do something like that, = I would suggest using standard  error codes as the port numbers, not s= ome arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:5= 08 address value.

[TR] There are two types of errors long-term (unsupported family), short-te= rm (insufficient capacity, quota exceeded etc.). For the short-term errors,= the server can suggest the client to re-try after specific duration. I don= =92t think it=92s a good idea to populate error codes in the port field.

-Tiru

Thanks
Oleg

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

--_000_22471A072B9F4AB49168DD4F3DFC21CBvidyocom_-- From nobody Thu Mar 20 09:13:50 2014 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 E93FC1A0457 for ; Thu, 20 Mar 2014 09:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 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_62=0.6, RP_MATCHES_RCVD=-0.547, 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 POoj8eqcAXFm for ; Thu, 20 Mar 2014 09:13:38 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB6271A0794 for ; Thu, 20 Mar 2014 09:13:37 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so1178784veb.6 for ; Thu, 20 Mar 2014 09:13:28 -0700 (PDT) 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=0J2nNbZQn+H5/I2htpYbUKR1HtfMRUch6dKuO4K2CHQ=; b=nibhYl0qfnayTCp1joYqeNXFsyWo5xIh41fBjdpYQqnVLI114Sa39/D5CRLhJ+7eIT OjpQ41VdB4zpLXSVe/8hqo/fJpAbQSlrl7PW0LbtOcPJcvOymBWPuFJb76Xo3Gvq2/SP qfJ4meLxB//GMSzBl7pIssF8iqnISU2BLSlNTXYoWydNGvJfe1hXke8vqfMn10NlJR1K +5jb4Vr7eFCrVNkIXijNwGwmjvX1+LKaYCwFC3GvoqwNpzC6vDZwEMESpIMyOUsfe40r oD0h4Wgl5m3P4e2CR9JEL2Lv8doL6iKD7iR9B7xJtS3S0Vb9w6jVeR48S9b5Fgw9P5xv fFKA== 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=0J2nNbZQn+H5/I2htpYbUKR1HtfMRUch6dKuO4K2CHQ=; b=LQqfzL38Nj5k8v0Nue784tRWl3X61u3w8IIGpJZBSX5GYL7quaOanb+16UGm5k6DnW YoUB6Iyy6SevkBGEEm00eIPZQOemGl7HKbepQizLU2b+3BKx/4H6yKfuzilYHJho9NMC 46WVR73mf+mebH5cFm/pbaqjJ83HkaVNsv/563w5fBNrybtCsdCISWqfKomzcusddRMy TiOfqODIqflMZkWnzzp4Zu9qikuQq2fW3n58igMqnZSIGO2yMZfMq4Z+w9/OGjOPxQ84 EY9X5Khg0ElfCVqNyPcFYf1Dm+dLSF6DfKhpCjVGYsCL2zwyJICtWJaqt0IHcB+v3zk9 6eZw== X-Gm-Message-State: ALoCoQmRhSbBC8bQOQ+KVukrA8CLUJiH33ZE24u/xmzXQuzG/8D/c4nZudbLFpl/U/kOpNNimbC61xSROQuViDssJHVIZT6SRz3DMx87Zcf9Yq3KopIioZH2UytNd13sjVHxwRKXqbw2Ij2WnPfZfRN3iy/FdqlLNo4dVfqawraxx4IcilXNNRtEpFnqlLxKo4m+OsS/uAvz X-Received: by 10.52.186.39 with SMTP id fh7mr479147vdc.72.1395332008433; Thu, 20 Mar 2014 09:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:13:08 -0700 (PDT) In-Reply-To: <1107CDF8-BDB7-404F-98CD-F38D3D9D42FB@cisco.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <1107CDF8-BDB7-404F-98CD-F38D3D9D42FB@cisco.com> From: Justin Uberti Date: Thu, 20 Mar 2014 09:13:08 -0700 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=bcaec5489e17b4fdf304f50c0c1f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/DgR54Jwv89fxB_dB0Pw0ZtcoN8A Cc: Oleg Moskalenko , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 16:13:42 -0000 --bcaec5489e17b4fdf304f50c0c1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2014 at 1:59 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > Thanks for summarising. > > On 20 Mar 2014, at 05:58, Justin Uberti wrote: > > A few comments on things that were raised in this discussion: > > - Using port numbers to indicate errors is a slippery slope. But I'm not > convinced it's even necessary; it's not clear to me that there's a case > where the client needs to take different action based on the error code. = If > it is necessary, one solution might be to include ERROR-CODE attributes i= n > the partial success message. > > > RFC4583 Distinguishes between port 0 and port 9 (Discard port). > > Distinguishing between address type not supported and address type > temporarily exhausted is probably not important as the client should not > keep state for the next call. > > How do we deal with alternate server? Should we enable the possibility > to send each address type to different servers. A fun engineering task, b= ut > will probably get complicated and not solve many real world problems? > I would like to invoke YAGNI here and avoid doing this work. It diminishes the benefit of SSODA to have v4-only and v6-only servers. > > - Client should not cache any information about the server other than > for an active allocation. If SSODA isn't supported, there's little harm i= n > trying again the next time. > > > +1 > > - SSODA should work fine for both TCP and UDP server connections. I > don't see any difference here. > > > The connection between agent and TURN server or TURN-TCP? > agent and TURN server. I wasn't sure what the actual issue was here, but Oleg mentioned this in a recent message. > > - Regarding srflx candidates - there is no need for SSODA to try to get > multiple srflx candidates; you just get srflx for the IPvX that you used = to > connect to the TURN server, which is fine. When you are dual-stack, you > will connect from both interfaces to the TURN server. This is important > because you want to use the same socket you use for TURN for ICE as well > (this ensures proper working of peer-reflexive candidates learned from > XOR-PEER-ADDRESS). > > > I think dual stacked host can benefit from SSODA as well. Use IPvX to > allocate the RELAY addresses. The reflexive candidate of IPvY needs to be > learnt with a STUN binding request. This saves the TURN server for work > like checking credentials, alternate server might kick in, ++. > > Only drawback is in some cases you might end up converting from IPvX to > IPvY on the TURN server. Not sure how expensive such an IP address > translation is? > > Peer reflexive adresses are learnt when sending a STUN binding request > from your HOST address towards any of the remote HOST, RFLX or RELAY > candidates. If the XOR-PEER-ADDRESS in the STUN Binding Response differs > from your SRFLX previously discovered it is a PRFLX candidate. I do not s= ee > the need for a direct mapping of HOST addr type and RELAY addr type > necessary. Or? > > In a IPv6 deployment you might get lucky and get a PRFLX candidate > without having SRFLX candidate. Dependant on the remote side setup. This = is > useful in a webRTC Trickle ICE scenario where you must chose if you want = to > spend time slots on connectivity checks or candidate gathering. > > > The overall allocation sequence will yield these candidates (for a > single-interface, dual-stack host, single dual-stack TURN server), > prioritized in descending order: > 1) host IPv6 > 2) host IPv4 > 3) srflx IPv6 (from TURN IPv6 conn) > 4) srflx IPv4 (from TURN IPv4 conn) > 5) relay IPv6 (from TURN IPv6 conn) > 6) relay IPv6 (from TURN IPv4 conn) > 7) relay IPv4 (from TURN IPv6 conn) > 8) relay IPv4 (from TURN IPv4 conn) > > SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4, > 6, 8 > > > I would like fewer candidates > > 1) host IPv6 > 2) host IPv4 > 3) srflx IPv4 (From SSODA allocate Request) > 4) srflx IPv6 (STUN Binding Request, With Trickle Ice might be deferred t= o > later stage) > 5) relay IPv4 (From SSODA Allocate Request) > 6) relay IPv6 (FROM SSODA Allocate Request) > That is fine - that's a client choice, and doesn't affect SSODA. > > The client needs to take some decision on how to contact the TURN > server. There should be a discovery mechanism for that.. Not just IPv4 or > IPv6, but UDP, TCP, TLS and DTLS as well. > > .-. > P=C3=A5l-Erik > > > > > On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko wro= te: > >> Hi Pal >> >> please see inline: >> >> >> On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) < >> palmarti@cisco.com> wrote: >> >>> >>> >>> >>> Comment> >>> How will the client ever know that the server has upgraded and now >>> supports the new mechanism proposed in the draft ? >>> May be the client once in a day can probe and find if the server >>> supports multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOC= ATE >>> request. >>> >>> I guess so >>> >>> >>> >>> I do not think the client should cache this information. It just needs >>> to know if it specks to a SSODA server,if it does not it might do more >>> steps to get all the allocated RELAY addresses the client needs. >>> >> >> My understanding is that a client app can be a very long-living client >> app, and it can connect to both old and new TURN servers. And a TURN ser= ver >> can be upgraded overnight. So the client app has to learn somehow at som= e >> momemnt of time that the server has been upgraded. >> >> >> >>> >>> >>> 3) Security Considerations section is missing. (Section 2.2 is assuming >>> client has already authenticated) >>> >>> >>> I suppose that this document does not introduce any new security >>> concerns (besides the ones we already have about TURN in general) >>> >>> [TR] Yes, you just need say something similar to the above line. >>> >>> >>> It might have some positive security aspects. SSODA have the potential >>> of reducing chatter between agent and TURN server. This means that the = TURN >>> server can put in more restrictive rate limiting hemes to restrict the >>> number of allocate request it will handle without impacting the client. >>> >> >> OK >> >> >>> >>> >>> >>> 5) Section 2.3 >>> >>> The allocated non-ANY address can be used, but the client >>> SHOULD NOT try to allocate any of the unsupported families on a >>> different 5-tuple. >>> >>> Comment> I guess the above line does not hold good for errors like >>> "Insufficient capacity". >>> >>> >>> >>> Do you mean a use case when one family relay address can be allocated - >>> but the other one can't - due to the exhaustion of capacity of that sin= gle >>> address family ? That's true. But we do know that that address family >>> cannot be allocated at the moment. So, I'd change the text to: >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> The allocated non-ANY address can be used, but the client SHOULD NOT tr= y >>> to allocate any of the unsupported families on a different 5-tuple with= in >>> the subsequent 600 seconds interval. After that interval, the allocatio= n >>> can be re-tried. >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Agree ? >>> >>> [TR] Yes >>> >>> I am unsure. >>> >>> This is a problem with the partial success scheme introduced in SSODA. >>> The TURN server will return one valid XOR-ADDRESS and one ANY:0 address= . We >>> do not know the reason why the SSODA server used a ANY address. >>> >>> Can we use the port number in the ANY address to distinguish between >>> insufficient capacity and address type not supported on this server? >>> >>> ANY:0 means address type not supported. I understand SSODA, but do not >>> try to allocate this address on a different 5-tuple. This address type = is >>> disabled on this server. >>> >>> ANY:9 means insufficient resources. Try again later. >>> >>> Or is using port numbers like this a slippery slope? >>> >>> >> I think that assigning special meanings to the port numbers is indeed >> somewhat a slippery slope... but if we do want to do something like that= , I >> would suggest using standard error codes as the port numbers, not some >> arbitrary values like 9. For example, "insufficient capacity" partial er= ror >> would be signaled as ANY:508 address value. >> >> Thanks >> Oleg >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > > --bcaec5489e17b4fdf304f50c0c1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 1:59 AM, Pal Martinsen (palmarti) <palmar= ti@cisco.com> wrote:

Thanks for summarising.=C2=A0

On 20 Mar 2014, at 05:58, Justin Uberti <juberti@google.com> wrote:

A few comments on things that were raised in this discussi= on:

- Using port numbers to indicate errors is a slippery slope. But I'= ;m not convinced it's even necessary; it's not clear to me that the= re's a case where the client needs to take different action based on th= e error code. If it is necessary, one solution might be to include ERROR-CODE attributes in the partial success message.

RFC4583 Distinguishes between port 0 and port 9 (Discard port).= =C2=A0

Distinguishing between address type not supported and address type tem= porarily exhausted is probably not important as the client should not keep = state for the next call.=C2=A0

How do we deal with alternate server? Should we enable the possibility= to send each address type to different servers. A fun engineering task, bu= t will probably get complicated and not solve many real world problems?

I would like to invoke YAGNI h= ere and avoid doing this work. It diminishes the benefit of SSODA to have v= 4-only and v6-only servers.

- Client should not cache any information about the server other than = for an active allocation. If SSODA isn't supported, there's little = harm in trying again the next time.

+1

- SSODA should work fine for both TCP and UDP server connections. I do= n't see any difference here.

The connection between agent and TURN server or TURN-TCP?
<= /div>

agent and TURN server. I wasn&#= 39;t sure what the actual issue was here, but Oleg mentioned this in a rece= nt message.=C2=A0

- Regarding srflx candidates - there is no need for SSODA to try to ge= t multiple srflx candidates; you just get srflx for the IPvX that you used = to connect to the TURN server, which is fine. When you are dual-stack, you = will connect from both interfaces to the TURN server. This is important because you want to use the same soc= ket you use for TURN for ICE as well (this ensures proper working of peer-r= eflexive candidates learned from XOR-PEER-ADDRESS).


I think dual stacked host can benefit from SSODA as well. Use IP= vX to allocate the RELAY addresses. The reflexive candidate of IPvY needs t= o be learnt with a STUN binding request. This saves the TURN server for wor= k like checking credentials, alternate server might kick in, ++.

Only drawback is in some cases you might end up converting from IPvX t= o IPvY on the TURN server. Not sure how expensive such an IP address transl= ation is?

Peer reflexive adresses are learnt when sending a STUN binding request= from your HOST address towards any of the remote HOST, RFLX or RELAY candi= dates. If the XOR-PEER-ADDRESS in the STUN Binding Response differs from yo= ur SRFLX previously discovered it is a PRFLX candidate. I do not see the need for a direct mapping of HOST a= ddr type and RELAY addr type necessary. Or?

In a IPv6 deployment you might get lucky and get a PRFLX candidate wit= hout having SRFLX candidate. Dependant on the remote side setup. This is us= eful in a webRTC Trickle ICE scenario where you must chose if you want to s= pend time slots on connectivity checks or candidate gathering.=C2=A0


The overall allocation sequence will yield these candidates (for a sin= gle-interface, dual-stack host, single dual-stack TURN server), prioritized= in descending order:
1) host IPv6
2) host IPv4
3) srflx IPv6 (from TURN IPv6 conn)
4) srflx IPv4 (from TURN IPv4 conn)
5) relay IPv6 (from TURN IPv6 conn)
6) relay IPv6 (from TURN IPv4 conn)
7) relay IPv4 (from TURN IPv6 conn)
8) relay IPv4 (from TURN IPv4 conn)

SSODA allows the same socket to be used for 1, 3, 5, 7 as well as 2, 4= , 6, 8


I would like fewer candidates

1) host IPv6
2) host IPv4
3) srflx IPv4 (From SSODA allocate Request)
4) srflx IPv6 (STUN Binding Request, With Trickle Ice might be deferre= d to later stage)
5) relay IPv4 (From SSODA Allocate Request)
6) relay IPv6 (FROM SSODA Allocate Request)

That is fine - that's a client choice, and does= n't affect SSODA.=C2=A0

The client needs to take some decision on how to contact the TURN serv= er. There should be a discovery mechanism for that.. Not just IPv4 or IPv6,= but UDP, TCP, TLS and DTLS as well.=C2=A0

.-.
P=C3=A5l-Erik




On Wed, Mar 19, 2014 at 9:55 AM, Oleg Moskalenko= <mom040267@gmai= l.com> wrote:
Hi Pal

please see inline:


On Wed, Mar 19, 2014 at 2:48 AM, Pal Martinsen (palmarti) <palmarti@cisco.= com> wrote:



Comment>
How will the client ever know that the server has upgraded and now supports= the new mechanism proposed in the draft ?
May be the client once in a day can probe and find if the server supports m= ultiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
=C2=A0
I guess so
=C2=A0

I do not think the client should cache this information. It just needs= to know if it specks to a SSODA server,if it does not it might do more ste= ps to get all the allocated RELAY addresses the client needs.

My understanding is that a client app can be a very long-living client= app, and it can connect to both old and new TURN servers. And a TURN serve= r can be upgraded overnight. So the client app has to learn somehow at some= momemnt of time that the server has been upgraded.

=C2=A0


3) Security Considerations section is missing. (Section 2.2 is assuming cli= ent has already authenticated)
=C2=A0
I suppose that this document does not introduce any new security concerns (= besides the ones we already have about TURN in general)
=C2=A0
[TR] Yes, you just need say something similar to the above line.

It might have some positive security aspects. SSODA have the potential= of reducing chatter between agent and TURN server. This means that the TUR= N server can put in more restrictive rate limiting hemes to restrict the nu= mber of allocate request it will handle without impacting the client.

OK


=C2=A0


5) Section 2.3

=C2=A0 The allocated non-ANY address can be used, but the client
=C2=A0 =C2=A0SHOULD NOT try to allocate any of the unsupported families on = a
=C2=A0 =C2=A0different 5-tuple.

Comment> I guess the above line does not hold good for errors like "= ;Insufficient capacity".

=C2=A0

Do you mean a use case when one family relay address can be allocated - but= the other one can't - due to the exhaustion of capacity of that single= address family ? That's true. But we do know that that address family = cannot be allocated at the moment. So, I'd change the text to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The allocated non-ANY address can be used, but the client SHOULD NOT try to= allocate any of the unsupported families on a different 5-tuple within the= subsequent 600 seconds interval. After that interval, the allocation can b= e re-tried.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agree ?

[TR] Yes

I am unsure.

This is a problem with the partial success scheme introduced in SSODA.= The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. W= e do not know the reason why the SSODA server used a ANY address.=C2=A0

Can we use the port number in the ANY address to distinguish between i= nsufficient capacity and address type not supported on this server?

ANY:0 means address type not supported. I understand SSODA, but do not= try to allocate this address on a different 5-tuple. This address type is = disabled on this server.=C2=A0

ANY:9 means insufficient resources. Try again later.=C2=A0

Or is using port numbers like this a slippery slope?


I think=C2=A0 that assigning special meanings to the port numbers is i= ndeed somewhat a slippery slope... but if we do want to do something like t= hat, I would suggest using standard=C2=A0 error codes as the port numbers, = not some arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:5= 08 address value.

Thanks
Oleg


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram




--bcaec5489e17b4fdf304f50c0c1f-- From nobody Thu Mar 20 09:27:11 2014 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 477CC1A08C7 for ; Thu, 20 Mar 2014 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 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.547, 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 M69ropNMMb_H for ; Thu, 20 Mar 2014 09:27:04 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D22021A08C5 for ; Thu, 20 Mar 2014 09:27:03 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so1209980veb.20 for ; Thu, 20 Mar 2014 09:26:54 -0700 (PDT) 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=skDiGUpt0HWw0mYifitqZ+6WfJcsEghGAZZYUIB/zk4=; b=CTm93jEP9wlWL5wINetzDHIvVBjsuRQpV1o0xDSGBMhokcfb82NDQEP29+6C9nijRj QuEmsPL9YjAR61l1p8srGlK3B+Q5/xLCM5W5XeSdk2xizxfTEy6o2Pj3KyBG0kbolij6 LrkTVVIfOqANXDzZkhzF55X6pR8PCkUZGzWxXBZ6yySc4lOuZnoL00GmamcJEOHTq0lF rVv7oXzJ7o3nt908Bs3L0He4lmfsBj7EVcw0Vsl3I/eDP13x+KBGqcrmWrxuBtR3c21t bUrP9UqNyxvbsxiUORftGcNgSZgU6nbUhNgCXB9WI8JHFGvvmHN6XcL7exTQe3eJ5xN1 nP1g== 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=skDiGUpt0HWw0mYifitqZ+6WfJcsEghGAZZYUIB/zk4=; b=OxIZYXfzt3F1e1fJDJa5QQU43sJRYQy2AVUxQut/7OE6MrYA4FFrWcaR+10KM0lyVH ANS5fMhA7O583yavCSA9eEcwRt3VSHICQMqofA4OoNo+qhBATbLeJN/p+AVFsrtFHx6E Qs/PhM5opOIIkJ6/tgZ5yprGGLfHzWvt/Ay849734X4amXY5K61wxgHA7x77OfQrjJdy FSxTzifqnysOP7StEEinzr4HpcK1YI59GCVGtGJyk/mZXDdCVIPwacpHp8Hc+/INzd9l u84eOBqCpwUmH2kzvSfRtIkR90jB4K4s/NPsY/jZfKmxA76JRG+fRdvPKi5p/iF64LuL R0dA== X-Gm-Message-State: ALoCoQkptc3qj3ZnMkfsSVPM5/tiYFpjNuewv2lqf4rfMmH4WMPQB81EJCz9s6Fs1+TQgRA3ZVnuj5Dd34euYVjlqFxfYl8TkhC39rmq/bQHJpE9FTU4fIpuMPknVH6f87qEC5la7Q0pJzOyVW+UwAqSRv4os45Qzr5BCrrLEkuYV/q+ei8QZSW71BSLBpVW8HC+LXaXBbV0 X-Received: by 10.221.66.209 with SMTP id xr17mr86211vcb.71.1395332814614; Thu, 20 Mar 2014 09:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Thu, 20 Mar 2014 09:26:34 -0700 (PDT) In-Reply-To: <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> From: Justin Uberti Date: Thu, 20 Mar 2014 09:26:34 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a1136291cc2971004f50c3cbc Archived-At: http://mailarchive.ietf.org/arch/msg/tram/uu8pERXn6DjFQ4fPbfm0NqCbl9k Cc: Oleg Moskalenko , "Pal Martinsen \(palmarti\)" , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 16:27:10 -0000 --001a1136291cc2971004f50c3cbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox wrote= : > I don=E2=80=99t think using XOR-RELAYED-ADDRESS with ANY to mean partial= failure > is a good idea. > > STUN attributes are cheap. I suggest an a new attribute > UNAVAILABLE-ADDRESS-FAMILY, which can be sent in an SSODA success respons= e. > If we want to be able to distinguish reasons for unavailability, the > attribute can be formatted as address-family/error-code/reason-phrase. > > In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure > responses as well, if people think it would be useful to be able to > describe cases where the IPv4 and IPv6 allocations failed for different > reasons. > This would be essentially ERROR-CODE with an address family. We could make a new attribute as you describe, or we could try to claim some of the reserved bits in the existing ERROR-CODE. > > Additionally =E2=80=94 I don=E2=80=99t like SSODA=E2=80=99s mechanism of= deliberately triggering > behavior that=E2=80=99s undefined according to RFC 6156. It seems like t= his will > be fragile. I=E2=80=99d suggest instead that we define a comprehension-o= ptional > ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically to > REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN server will use but a > strict 6156 TURN server will ignore. > Agree this would be a better approach. > > On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Inline [TR] > > I am unsure. > > This is a problem with the partial success scheme introduced in SSODA. > The TURN server will return one valid XOR-ADDRESS and one ANY:0 address. = We > do not know the reason why the SSODA server used a ANY address. > > Can we use the port number in the ANY address to distinguish between > insufficient capacity and address type not supported on this server? > > ANY:0 means address type not supported. I understand SSODA, but do not > try to allocate this address on a different 5-tuple. This address type is > disabled on this server. > > ANY:9 means insufficient resources. Try again later. > > Or is using port numbers like this a slippery slope? > > > I think that assigning special meanings to the port numbers is indeed > somewhat a slippery slope... but if we do want to do something like that,= I > would suggest using standard error codes as the port numbers, not some > arbitrary values like 9. For example, "insufficient capacity" partial err= or > would be signaled as ANY:508 address value. > > [TR] There are two types of errors long-term (unsupported family), > short-term (insufficient capacity, quota exceeded etc.). For the short-te= rm > errors, the server can suggest the client to re-try after specific > duration. I don=E2=80=99t think it=E2=80=99s a good idea to populate erro= r codes in the > port field. > > -Tiru > > Thanks > Oleg > _______________________________________________ > > 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 > > --001a1136291cc2971004f50c3cbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
I don=E2=80=99t think using XOR-RELAYED-ADDRESS with ANY to mean parti= al failure is a good idea.

STUN attributes are cheap. =C2=A0I suggest an a new attribute UNAVAILA= BLE-ADDRESS-FAMILY, which can be sent in an SSODA success response. =C2=A0I= f we want to be able to distinguish reasons for unavailability, the attribu= te can be formatted as address-family/error-code/reason-phrase.=C2=A0

In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure= responses as well, if people think it would be useful to be able to descri= be cases where the IPv4 and IPv6 allocations failed for different reasons.= =C2=A0

This would be essentially ERROR-CODE= with an address family. We could make a new attribute as you describe, or = we could try to claim some of the reserved bits in the existing ERROR-CODE.=

Additionally =E2=80=94 I don=E2=80=99t like SSODA=E2=80=99s mechanism = of deliberately triggering behavior that=E2=80=99s undefined according to R= FC 6156. =C2=A0It seems like this will be fragile. =C2=A0I=E2=80=99d sugges= t instead that we define a comprehension-optional ADDITIONAL-REQUESTED-ADDR= ESS-FAMILY attribute, formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSOD= A-aware TURN server will use but a strict 6156 TURN server will ignore.

Agree this would be a better appro= ach.

On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> w= rote:

Inline [TR]
=C2=A0
I am unsure.
=C2=A0
This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address.=C2=A0
=C2=A0
Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server?
=C2=A0
ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server.=C2=A0
=C2=A0
ANY:9 means insufficient resources. Try again later.=C2=A0
=C2=A0
Or is using port numbers like this a slippery slope?
=C2=A0

I think=C2=A0 that assigning special meanings to the port numbers is indeed= somewhat a slippery slope... but if we do want to do something like that, = I would suggest using standard=C2=A0 error codes as the port numbers, not s= ome arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:5= 08 address value.

[TR] There are two types of errors long-term (unsupported family), short-te= rm (insufficient capacity, quota exceeded etc.). For the short-term errors,= the server can suggest the client to re-try after specific duration. I don= =E2=80=99t think it=E2=80=99s a good idea to populate error codes in the port field.

-Tiru

Thanks
Oleg

_______________________________________________

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


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--001a1136291cc2971004f50c3cbc-- From nobody Thu Mar 20 09:32:19 2014 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 394A91A0770 for ; Thu, 20 Mar 2014 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XL0loTVD6XGD for ; Thu, 20 Mar 2014 09:32:16 -0700 (PDT) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id D808C1A0457 for ; Thu, 20 Mar 2014 09:32:15 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/20/2014 12:32:06 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-195/SG:5 3/20/2014 12:31:38 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.912535 p=-0.983169 Source White X-Signature-Violations: 0-0-0-20158-c X-Note-419: 15.6005 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/20/2014 12:32:01 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 107702902; Thu, 20 Mar 2014 12:32:06 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 20 Mar 2014 11:32:05 -0500 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZJGocJ2jdTwSef3K1BegT6wAckHsAAA27zZAAEZsigAAO6dQAAAnJFIAAJdlvAAABpgAAAAAxLQA= Date: Thu, 20 Mar 2014 16:32:04 +0000 Message-ID: <561F556D-4F22-43B1-BAF2-DA5E477075C1@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_561F556D4F2243B1BAF2DA5E477075C1vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FBZ6E8WarEueE-XES1Jtwt3iaBI Cc: Oleg Moskalenko , "Pal Martinsen \(palmarti\)" , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 20 Mar 2014 16:32:18 -0000 --_000_561F556D4F2243B1BAF2DA5E477075C1vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 20, 2014, at 12:26 PM, Justin Uberti > wrote: On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox > wrote: I don=92t think using XOR-RELAYED-ADDRESS with ANY to mean partial failure = is a good idea. STUN attributes are cheap. I suggest an a new attribute UNAVAILABLE-ADDRES= S-FAMILY, which can be sent in an SSODA success response. If we want to be= able to distinguish reasons for unavailability, the attribute can be forma= tted as address-family/error-code/reason-phrase. In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure resp= onses as well, if people think it would be useful to be able to describe ca= ses where the IPv4 and IPv6 allocations failed for different reasons. This would be essentially ERROR-CODE with an address family. We could make = a new attribute as you describe, or we could try to claim some of the reser= ved bits in the existing ERROR-CODE. Formatting-wise, yes, I=92d use some of the reserved bits in ERROR-CODE to = carry the address family. I think that giving it a different attribute number would be a good idea, t= hough, since it=92s semantically different. Additionally =97 I don=92t like SSODA=92s mechanism of deliberately trigger= ing behavior that=92s undefined according to RFC 6156. It seems like this = will be fragile. I=92d suggest instead that we define a comprehension-opti= onal ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically t= o REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN server will use but a = strict 6156 TURN server will ignore. Agree this would be a better approach. On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) > wrote: Inline [TR] I am unsure. This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server? ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. ANY:9 means insufficient resources. Try again later. Or is using port numbers like this a slippery slope? I think that assigning special meanings to the port numbers is indeed some= what a slippery slope... but if we do want to do something like that, I wou= ld suggest using standard error codes as the port numbers, not some arbitr= ary values like 9. For example, "insufficient capacity" partial error would= be signaled as ANY:508 address value. [TR] There are two types of errors long-term (unsupported family), short-te= rm (insufficient capacity, quota exceeded etc.). For the short-term errors,= the server can suggest the client to re-try after specific duration. I don= =92t think it=92s a good idea to populate error codes in the port field. -Tiru Thanks Oleg _______________________________________________ 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 --_000_561F556D4F2243B1BAF2DA5E477075C1vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <33F49BC05613474999FE5533AE637F0E@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Mar 20, 2014, at 12:26 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:
I don=92t think using XOR-RELAYED-ADDRESS with ANY to mean partial fai= lure is a good idea.

STUN attributes are cheap.  I suggest an a new attribute UNAVAILA= BLE-ADDRESS-FAMILY, which can be sent in an SSODA success response.  I= f we want to be able to distinguish reasons for unavailability, the attribu= te can be formatted as address-family/error-code/reason-phrase. 

In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure= responses as well, if people think it would be useful to be able to descri= be cases where the IPv4 and IPv6 allocations failed for different reasons.&= nbsp;

This would be essentially ERROR-CODE with an address family. We could = make a new attribute as you describe, or we could try to claim some of the = reserved bits in the existing ERROR-CODE.

Formatting-wise, yes, I=92d use some of the reserved bits in ERROR-COD= E to carry the address family.

I think that giving it a different attribute number would be a good id= ea, though, since it=92s semantically different.

Additionally =97 I don=92t like SSODA=92s mechanism of deliberately tr= iggering behavior that=92s undefined according to RFC 6156.  It seems = like this will be fragile.  I=92d suggest instead that we define a com= prehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSOD= A-aware TURN server will use but a strict 6156 TURN server will ignore.

Agree this would be a better approach.

On Mar 19, 2014, at 10:48 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> w= rote:

Inline [TR]
 
I am unsure.
 
This is a problem with the partial success scheme introduced in SSODA. The = TURN server will return one valid XOR-ADDRESS and one ANY:0 address. We do = not know the reason why the SSODA server used a ANY address. 
 
Can we use the port number in the ANY address to distinguish between insuff= icient capacity and address type not supported on this server?
 
ANY:0 means address type not supported. I understand SSODA, but do not try = to allocate this address on a different 5-tuple. This address type is disab= led on this server. 
 
ANY:9 means insufficient resources. Try again later. 
 
Or is using port numbers like this a slippery slope?
 

I think  that assigning special meanings to the port numbers is indeed= somewhat a slippery slope... but if we do want to do something like that, = I would suggest using standard  error codes as the port numbers, not s= ome arbitrary values like 9. For example, "insufficient capacity" partial error would be signaled as ANY:5= 08 address value.

[TR] There are two types of errors long-term (unsupported family), short-te= rm (insufficient capacity, quota exceeded etc.). For the short-term errors,= the server can suggest the client to re-try after specific duration. I don= =92t think it=92s a good idea to populate error codes in the port field.

-Tiru

Thanks
Oleg

_______________________________________________

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


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



--_000_561F556D4F2243B1BAF2DA5E477075C1vidyocom_-- From nobody Thu Mar 20 10:19:20 2014 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 15EFA1A0700 for ; Thu, 20 Mar 2014 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6nEjLh-Skxj for ; Thu, 20 Mar 2014 10:19:15 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7986F1A03BF for ; Thu, 20 Mar 2014 10:19:15 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so6510063wib.2 for ; Thu, 20 Mar 2014 10:19:06 -0700 (PDT) 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=uaagFBvzFfAykIXMSqtWJ+Dqi0sR3hCtIBt+LPQLBZI=; b=Bc9IkyxMEkWSDZDmIMpt/ACK10o1CpR1WPTyVJ9ehH27yWfc1kFcgogWZgxgyq8duo xidxB5atKOHEzbGfLNLWrYWzc5GjACPZ0URMU6Q3qsSp4VzE41n1H7gdyb61hGmQWHdQ JcNdn4jCnFMmw1Hlf3fBynggcdg1Eve9NiymHofm6tKh8PtF2antzNUYKV53sJcgZQpR fwY3m2LOA8W1kVfOUqxsz3UMuH2sYLUt/665F38rfrO7yGbK6EWGNR+1qtsItv/74bd8 ktWUWZtA1nHX3GPwltpXuoGTpAod3cSqo4MdLqJRg1mT8SjbUbu17JR7JMhhEC/Cpyoo rGng== MIME-Version: 1.0 X-Received: by 10.194.63.46 with SMTP id d14mr35433491wjs.24.1395335945954; Thu, 20 Mar 2014 10:19:05 -0700 (PDT) Received: by 10.216.106.130 with HTTP; Thu, 20 Mar 2014 10:19:05 -0700 (PDT) Received: by 10.216.106.130 with HTTP; Thu, 20 Mar 2014 10:19:05 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A242D8EFD@xmb-rcd-x10.cisco.com> References: <532AF25B.4020301@viagenie.ca> <913383AAA69FF945B8F946018B75898A242D8EFD@xmb-rcd-x10.cisco.com> Date: Thu, 20 Mar 2014 10:19:05 -0700 Message-ID: From: Cb B To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7ba97a8866aa7a04f50cf7ad Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BoH6R7ERa5fbzXKIusbI6CnNl4g Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 20 Mar 2014 17:19:17 -0000 --047d7ba97a8866aa7a04f50cf7ad Content-Type: text/plain; charset=ISO-8859-1 On Mar 20, 2014 7:48 AM, "Tirumaleswar Reddy (tireddy)" wrote: > > Just adding a data point, mobile networks generally don't use dhcp so that limits the scope of dhcp as an option. > > I anticipate mobile networks will need TURN. > > CB > > [TR] > > > > we had discussed similar problem to discover PCP servers in Mobile Networks ( http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-04#section-4) sometime back. Based on the discussion > > 1)DHCPv6 stateless configuration information is supported by 3GPP specification (http://tools.ietf.org/html/rfc6459#section-5.2) > > 2)Since DHCPv4 is not widely used, possible solutions discussed to solve the problem are anycast, enhancing PCO to provide TURN {PCP} server IP address > > > > -Tiru I dont know any deployed mobile network where those will work today. Today with IMS in mobile networks, NAPTR is used in DNS, so in would suggest that as a viable path CB --047d7ba97a8866aa7a04f50cf7ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 20, 2014 7:48 AM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> wrote:
>
> Just adding a data point, mobile networks generally don't use dhcp= so that limits the scope of dhcp as an option.
>
> I anticipate mobile networks will need TURN.
>
> CB
>
> [TR]
>
> =A0
>
> we had discussed similar problem to discover PCP servers in Mobile Net= works (http://tools.ietf.org/html/draft-chen-pcp-mobile-deploymen= t-04#section-4) sometime back. Based on the discussion
>
> 1)DHCPv6 stateless configuration information is supported by 3GPP spec= ification (http:= //tools.ietf.org/html/rfc6459#section-5.2)
>
> 2)Since DHCPv4 is not widely used, possible solutions discussed to sol= ve the problem are anycast, enhancing PCO to provide TURN {PCP} server IP a= ddress
>
> =A0
>
> -Tiru

I dont know any deployed mobile network where those will wor= k today.

Today with IMS in mobile networks, NAPTR is used in DNS, so = in would suggest that as a viable path

CB

--047d7ba97a8866aa7a04f50cf7ad-- From nobody Thu Mar 20 22:29:40 2014 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 884FE1A0908 for ; Thu, 20 Mar 2014 22:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyKCq6a7TOFk for ; Thu, 20 Mar 2014 22:29:36 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 189821A035F for ; Thu, 20 Mar 2014 22:29:36 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id x10so1900654pdj.9 for ; Thu, 20 Mar 2014 22:29:27 -0700 (PDT) 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=ZscfLHORVmT/d7ehTrzuZtw05OoJHxuO+CiCT3KCxPA=; b=TA55cQigE1HjpM/YtEf6VE1kFdmgbK5srQUF8RqXD54Vi0snnY1/XAZQ7kslmM4XaS KrmPxwefkOWKaYTSlw9tf1FV1omJaD+U5OK3avJyphg6C/i7zc86KTmDth7faKDU/WaM hdAKv1kj7yXlyv9GHBTYZ9zNqGfvqEsYlOPOGA9g/BeSRR9MRIQS2+1CDkQoq+2LisKL bdaZ8hbqKoVTYmar9F945krTmgHAWnBp+zMyZ70eeVHbRnQ0w8FoeFLdrtE2O+jIhc7x fqm9ZMsjWd9HRFTes8RLkZU6YNgemA3E/K8VHtQiOFioRGFQfkzHbJsQV2mBV01i79Oe 9oRw== MIME-Version: 1.0 X-Received: by 10.67.22.100 with SMTP id hr4mr51903555pad.112.1395379766986; Thu, 20 Mar 2014 22:29:26 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Thu, 20 Mar 2014 22:29:26 -0700 (PDT) In-Reply-To: <561F556D-4F22-43B1-BAF2-DA5E477075C1@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> <561F556D-4F22-43B1-BAF2-DA5E477075C1@vidyo.com> Date: Thu, 20 Mar 2014 22:29:26 -0700 Message-ID: From: Oleg Moskalenko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7b5dadd0568ab204f5172bc1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zHvSJegbfigf56WT6zWwazorSXg Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 21 Mar 2014 05:29:38 -0000 --047d7b5dadd0568ab204f5172bc1 Content-Type: text/plain; charset=ISO-8859-1 Please see inline: On Thu, Mar 20, 2014 at 9:32 AM, Jonathan Lennox wrote: > > On Mar 20, 2014, at 12:26 PM, Justin Uberti wrote: > > On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox wrote: > >> I don't think using XOR-RELAYED-ADDRESS with ANY to mean partial >> failure is a good idea. >> >> STUN attributes are cheap. I suggest an a new attribute >> UNAVAILABLE-ADDRESS-FAMILY, which can be sent in an SSODA success response. >> If we want to be able to distinguish reasons for unavailability, the >> attribute can be formatted as address-family/error-code/reason-phrase. >> > >> In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure >> responses as well, if people think it would be useful to be able to >> describe cases where the IPv4 and IPv6 allocations failed for different >> reasons. >> > > This would be essentially ERROR-CODE with an address family. We could > make a new attribute as you describe, or we could try to claim some of the > reserved bits in the existing ERROR-CODE. > > > Formatting-wise, yes, I'd use some of the reserved bits in ERROR-CODE to > carry the address family. > > I think that giving it a different attribute number would be a good > idea, though, since it's semantically different. > [Oleg] That's probably OK. I guess we want it in comprehension-optional range; then we can try to make it somewhat backward compatible for older clients. > > Additionally -- I don't like SSODA's mechanism of deliberately >> triggering behavior that's undefined according to RFC 6156. It seems like >> this will be fragile. I'd suggest instead that we define a >> comprehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, >> formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSODA-aware TURN >> server will use but a strict 6156 TURN server will ignore. >> > > Agree this would be a better approach. > > [Oleg] I actually think that the original proposal of two equally important "symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than introducing an "asymmetric" schema of "primary" and "additional" addresses families. I feel that there may be a number of potential behavioral and compatibility issues if we treat them differently. > > --047d7b5dadd0568ab204f5172bc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please see inline:


On Thu, Mar 20, 2014 at 9:32 AM, Jonath= an Lennox <jonathan@vidyo.com> wrote:

On Mar 20, 2014, at 12:26 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:
I don’t think using XOR-RELAYED-ADDRESS with ANY to mean partial= failure is a good idea.

STUN attributes are cheap.  I suggest an a new attribute UNAVAILA= BLE-ADDRESS-FAMILY, which can be sent in an SSODA success response.  I= f we want to be able to distinguish reasons for unavailability, the attribu= te can be formatted as address-family/error-code/reason-phrase. 

In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure= responses as well, if people think it would be useful to be able to descri= be cases where the IPv4 and IPv6 allocations failed for different reasons.&= nbsp;

This would be essentially ERROR-CODE with an address family. We could = make a new attribute as you describe, or we could try to claim some of the = reserved bits in the existing ERROR-CODE.

Formatting-wise, yes, I’d use some of the reserved bits in= ERROR-CODE to carry the address family.

I think that giving it a different attribute number would be a good id= ea, though, since it’s semantically different.

[Oleg] That's probably OK. I guess we want = it in comprehension-optional range; then we can try to make it somewhat bac= kward compatible for older clients.
 

Additionally — I don’t like SSODA’s mechanism of del= iberately triggering behavior that’s undefined according to RFC 6156.=  It seems like this will be fragile.  I’d suggest instead = that we define a comprehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSOD= A-aware TURN server will use but a strict 6156 TURN server will ignore.

Agree this would be a better approach.

[Oleg] I actually t= hink that the original proposal of two equally important "symmetric&qu= ot; REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than introdu= cing an "asymmetric" schema of "primary" and "addi= tional" addresses families. I feel that there may be a number of poten= tial behavioral and compatibility issues if we treat them differently.
 


--047d7b5dadd0568ab204f5172bc1-- From nobody Fri Mar 21 00:32:46 2014 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 898B31A0077 for ; Fri, 21 Mar 2014 00:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 1HbLw2TL2WzO for ; Fri, 21 Mar 2014 00:32:43 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 145891A00D4 for ; Fri, 21 Mar 2014 00:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1120; q=dns/txt; s=iport; t=1395387154; x=1396596754; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jZkpqZM9QK7fRtkW+CoRqfwwe0YLNm0VP+trX0X6gN4=; b=ByOXhGI6MDLLLKuFwtCFhk+uoQ+kkUv88uViHi3FoQmLrMf4rpAKGYxr vcJ4BOCR2Gjc83NN95Zn2ghFP43Xh5CcWNyVr6EJXnoI2Q09YLOIyn2/r NoFnvnMhJahBNbzezJgpPpXh/YxyPf7XrfKkpwWd1FTWXNgzE4BOH4F85 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJfpK1OtJXG8/2dsb2JhbABQCYMGO1fCUIESFnSCJgEBBCdiAgEIRjIlAgQBEgmHcA3PXxeOAwcJAgFRBYQ4BIkajy+BMpB/gy2CKw X-IronPort-AV: E=Sophos;i="4.97,702,1389744000"; d="scan'208";a="29237485" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 21 Mar 2014 07:32:33 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2L7WXts012818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 07:32:33 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 02:32:32 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: AQHPRFE/TuSDFtQ6w0CH5HnkZEyyrprr1s4A Date: Fri, 21 Mar 2014 07:32:32 +0000 Message-ID: References: <532AF25B.4020301@viagenie.ca> <532B0974.1010404@viagenie.ca> In-Reply-To: <532B0974.1010404@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.127.18.26] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <025412943674634D95F217800A92A7C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OVzcbtR3KdCo6MR7o0TdK3gyCeE Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 07:32:44 -0000 On 3/20/14 8:59 PM, "Simon Perreault" wrote: >Le 2014-03-20 10:48, Prashanth Patil (praspati) a =E9crit : >> There was a suggestion that domain name could also be >> extracted from own SIP/XMPP/email identity >> (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- which >> we plan to add to the draft in the next version. > >But that doesn't work because it would be an application-provided TURN >server. We need to discover network-provided TURN servers. Sure, but should we not provide a means for discovering those? Maybe suggest that this should be attempted only if the client is not able to discover a network-provided server. The network provided server is probably closer, so attempt to discover that first. How to prioritize if a client discovers more than one TURN server is another discussions altogether. -Prashanth > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 00:33:51 2014 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 B50661A0077 for ; Fri, 21 Mar 2014 00:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 aGl14J60L8j3 for ; Fri, 21 Mar 2014 00:33:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1464A1A0144 for ; Fri, 21 Mar 2014 00:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1376; q=dns/txt; s=iport; t=1395387218; x=1396596818; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=fSvA6uumx2d/Z/wmO6vZT5qkbp3sxEciHHYM1u2ruME=; b=Z3XCNNw36rR70gAK0Y94ETn6Tq17bvbAO+XcZQ9JhWqZavsSQDJ0uhGw QC8vfiNFpu+3WdqaIkqa7W6grs2BvcI9qwz/ecD/fn5LXgmx9POIgoKRt emdRZuTUDdfd0blRaKwkPmmlbQ5KQNRP8RZe1yh5B0X71s2oRmnAkdIyA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAK/qK1OtJXG+/2dsb2JhbABQCYMGO1e7HIc0gRIWdIIlAQEBAwEBAQEkRxcGAQgRBAEBCx0uCxQJCQEEARIIAYdoCA3PUheOAwcJAgEeMwuDHoEUBIkakGGQf4Mtgis X-IronPort-AV: E=Sophos;i="4.97,702,1389744000"; d="scan'208";a="311843142" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 21 Mar 2014 07:33:37 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2L7Xb8a032135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 07:33:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 02:33:37 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9E19q/qiV60XKLSP25jrslH+QrGA== Date: Fri, 21 Mar 2014 07:33:36 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.130] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QaF0uuWv-lRc_k8EbzLpcTUzPog Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 07:33:50 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Thursday, March 20, 2014 9:00 PM > To: Prashanth Patil (praspati); tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Le 2014-03-20 10:48, Prashanth Patil (praspati) a =E9crit : > > There was a suggestion that domain name could also be extracted from > > own SIP/XMPP/email identity > > (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- > > which we plan to add to the draft in the next version. >=20 > But that doesn't work because it would be an application-provided TURN se= rver. > We need to discover network-provided TURN servers. Yes. It brings few other challenges like if TURN server is provided by ISP = then how will authentication and authorization work ? I mean for users logging into a coffee shop, Hotels etc.=20 How will these endpoints know the credentials to use with the TURN servers = provided by ISP ? -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Mar 21 00:37:10 2014 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 6F8461A0077 for ; Fri, 21 Mar 2014 00:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 4i5geDDkBBuR for ; Fri, 21 Mar 2014 00:37:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5D41A00D4 for ; Fri, 21 Mar 2014 00:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1500; q=dns/txt; s=iport; t=1395387417; x=1396597017; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=X8I9SSa2hiCWr4apmr0vaq7oFijnbXSA4RXJ2e5UwLs=; b=bQTnOHHw1RoMwpV1pDFcMJi1YwdVjoehfm87iOaTzZVQ4rKyrWmZwAH8 mO5+1B8cNloOqn+d+mR1sufB9Qn7OVV6FjZpYcRKvbq9b1qaXvBuSD9mb BohivVST0+mNjHmJi05pjdROjYrZCyQaDpY5BMr66o8VPuDUq8nN8zYUc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADPrK1OtJV2d/2dsb2JhbABZgwY7V8JQgRIWdIIlAQEBBHkSAQgRBAEBAQodKBEUCQkBBA4FCBOHSgMRDcgsDYcZF4xNgWcxgyuBFASJGo1Cgx+LNoVJgy2CKw X-IronPort-AV: E=Sophos;i="4.97,702,1389744000"; d="scan'208";a="29238260" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 21 Mar 2014 07:36:57 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2L7avBD029413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 07:36:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 02:36:57 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Cb B Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9E2FL923iaaXtsQriQrwRz05SM7g== Date: Fri, 21 Mar 2014 07:36:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242D98F2@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.130] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/GKZLT_ghcZgkylcJEQ4BLuGY7EU Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 07:37:08 -0000 From: Cb B [mailto:cb.list6@gmail.com]=20 Sent: Thursday, March 20, 2014 10:49 PM To: Tirumaleswar Reddy (tireddy) Cc: Simon Perreault; tram@ietf.org Subject: RE: [tram] TURN server discovery (please discuss!) On Mar 20, 2014 7:48 AM, "Tirumaleswar Reddy (tireddy)" = wrote: > > Just adding a data point, mobile networks generally don't use dhcp so tha= t limits the scope of dhcp as an option. > > I anticipate mobile networks will need TURN. > > CB > > [TR] > > =A0 > > we had discussed similar problem to discover PCP servers in Mobile Networ= ks (http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-04#section-= 4) sometime back. Based on the discussion > > 1)DHCPv6 stateless configuration information is supported by 3GPP specifi= cation (http://tools.ietf.org/html/rfc6459#section-5.2) > > 2)Since DHCPv4 is not widely used, possible solutions discussed to solve = the problem are anycast, enhancing PCO to provide TURN {PCP} server IP addr= ess > > =A0 > > -Tiru=20 > I dont know any deployed mobile network where those will work today. > Today with IMS in mobile networks, NAPTR is used in DNS, so in would sugg= est that as a viable path=20 > CB Even the TURN discovery draft is using NAPTR http://tools.ietf.org/html/dra= ft-patil-tram-turn-serv-disc-00#section-4.2; But DHCP is used to get the do= main name to be used for TURN service discovery.=20 Is there any other mechanism to get the domain name ? -Tiru From nobody Fri Mar 21 05:55:00 2014 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 201B71A04FA for ; Fri, 21 Mar 2014 05:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 EwtEjGprsoPY for ; Fri, 21 Mar 2014 05:54:56 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 46CD21A00E6 for ; Fri, 21 Mar 2014 05:54:56 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AF0AC40203; Fri, 21 Mar 2014 08:54:46 -0400 (EDT) Message-ID: <532C3696.1080004@viagenie.ca> Date: Fri, 21 Mar 2014 08:54:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <532AF25B.4020301@viagenie.ca> <532B0974.1010404@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/f-BphVJDidtGXVBVKFufC-f9CeQ Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 12:54:58 -0000 Le 2014-03-21 03:32, Prashanth Patil (praspati) a écrit : >>> There was a suggestion that domain name could also be >>> extracted from own SIP/XMPP/email identity >>> (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- which >>> we plan to add to the draft in the next version. >> >> But that doesn't work because it would be an application-provided TURN >> server. We need to discover network-provided TURN servers. > > Sure, but should we not provide a means for discovering those? The point is that those means already exist. > Maybe > suggest that this should be attempted only if the client is not able to > discover a network-provided server. The network provided server is > probably closer, so attempt to discover that first. > > How to prioritize if a client discovers more than one TURN server is > another discussions altogether. Right. But IMHO prioritization is an easy problem compared with the actual discovery. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 05:59:16 2014 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 AB1BC1A04FA for ; Fri, 21 Mar 2014 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 GOsiZEFEzlwt for ; Fri, 21 Mar 2014 05:59:09 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 209861A04DC for ; Fri, 21 Mar 2014 05:59:09 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9786340203; Fri, 21 Mar 2014 08:58:59 -0400 (EDT) Message-ID: <532C3793.9050203@viagenie.ca> Date: Fri, 21 Mar 2014 08:58:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ma98wxru_wLs4nLq3E94A5ZKFdc Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 12:59:11 -0000 Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a écrit : > Yes. It brings few other challenges like if TURN server is provided by ISP then how will authentication and authorization work ? > I mean for users logging into a coffee shop, Hotels etc. > > How will these endpoints know the credentials to use with the TURN servers provided by ISP ? If the TURN server is provided by the network, couldn't we assume that authentication is network-based? That is, if you succeed in talking to the server, then that means you're good. TURN servers would effectively have "no authentication" in the protocol. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 06:02:22 2014 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 B14721A04FA for ; Fri, 21 Mar 2014 06:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 s9k4CLq5qq36 for ; Fri, 21 Mar 2014 06:02:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C49481A03D2 for ; Fri, 21 Mar 2014 06:02:17 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4E03F40203; Fri, 21 Mar 2014 09:02:08 -0400 (EDT) Message-ID: <532C384F.4080601@viagenie.ca> Date: Fri, 21 Mar 2014 09:02:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Cb B References: <913383AAA69FF945B8F946018B75898A242D98F2@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242D98F2@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sGvdclCJv-z72j0XFjjyqaujdVA Cc: "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 13:02:19 -0000 Le 2014-03-21 03:36, Tirumaleswar Reddy (tireddy) a écrit : >> Today with IMS in mobile networks, NAPTR is used in DNS, so in would suggest that as a viable path > > Even the TURN discovery draft is using NAPTR http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-00#section-4.2; But DHCP is used to get the domain name to be used for TURN service discovery. > Is there any other mechanism to get the domain name ? Yes. Please refer to: http://tools.ietf.org/html/draft-kist-alto-3pdisc That discovery mechanism looks up NAPTR records in the {in-addr,ip6}.arpa zone corresponding to the IP address(es) that the client was assigned by the network. No DHCP involved. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 07:15:46 2014 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 B96BB1A0760 for ; Fri, 21 Mar 2014 07:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 bV4vAaBkj1_9 for ; Fri, 21 Mar 2014 07:15:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id D0FA71A08C2 for ; Fri, 21 Mar 2014 07:15:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5B152474CC; Fri, 21 Mar 2014 14:14:58 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A850C474CE; Fri, 21 Mar 2014 14:14:57 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id DDF6A80048; Fri, 21 Mar 2014 14:14:56 +0000 (GMT) Message-ID: <532C4960.9030005@akamai.com> Date: Fri, 21 Mar 2014 10:14:56 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simon Perreault , "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> In-Reply-To: <532C3793.9050203@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/C_sv4Rw_OgBWhSAJP_ljC9byvy8 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 14:15:45 -0000 I think that some type of authentication is necessary, even if all it provides is the ability to verify that the two ends of the tunnel remain consistent throughout the life of the allocation. Without at least that, then the service is open to DOS attacks via message injection. The network geographic location of the attacker could be limited, but such attacks could not be prevented entirely. Of course, TLS or DTLS could be used for this purpose, but is it reasonable to require that overhead just for the purpose of authenticating the TURN control traffic? --Brandon On 03/21/2014 08:58 AM, Simon Perreault wrote: > Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a écrit : >> Yes. It brings few other challenges like if TURN server is provided by ISP then how will authentication and authorization work ? >> I mean for users logging into a coffee shop, Hotels etc. >> >> How will these endpoints know the credentials to use with the TURN servers provided by ISP ? > > If the TURN server is provided by the network, couldn't we assume that > authentication is network-based? That is, if you succeed in talking to > the server, then that means you're good. TURN servers would effectively > have "no authentication" in the protocol. > > Simon > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 21 07:31:16 2014 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 5521B1A0990 for ; Fri, 21 Mar 2014 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 xBldOxTKzsXV for ; Fri, 21 Mar 2014 07:31:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 96AE71A0760 for ; Fri, 21 Mar 2014 07:31:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0B6772856A for ; Fri, 21 Mar 2014 14:31:01 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id EB67E28569 for ; Fri, 21 Mar 2014 14:31:00 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id B85FAFE077 for ; Fri, 21 Mar 2014 14:31:00 +0000 (GMT) Message-ID: <532C4D24.5060007@akamai.com> Date: Fri, 21 Mar 2014 10:31:00 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> <532C4960.9030005@akamai.com> In-Reply-To: <532C4960.9030005@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vcK69ZUmbnLhg5TL1ni3x9jnlMI Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 14:31:15 -0000 On a separate note, also related to (D)TLS ... It's not completely clear to me how the anycast approach to server discovery would work together with secure data flows. What are the server-side cert requirements in order to make an anycast solution work? I'm not suggesting that it won't work -- just that people (like me) who do have much expertize with cert management may need to have it spelled out in order to evaluate whether the requirements seem reasonable. --Brandon On 03/21/2014 10:14 AM, Brandon Williams wrote: > I think that some type of authentication is necessary, even if all it > provides is the ability to verify that the two ends of the tunnel remain > consistent throughout the life of the allocation. Without at least that, > then the service is open to DOS attacks via message injection. The > network geographic location of the attacker could be limited, but such > attacks could not be prevented entirely. > > Of course, TLS or DTLS could be used for this purpose, but is it > reasonable to require that overhead just for the purpose of > authenticating the TURN control traffic? > > --Brandon > > On 03/21/2014 08:58 AM, Simon Perreault wrote: >> Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a écrit : >>> Yes. It brings few other challenges like if TURN server is provided by ISP then how will authentication and authorization work ? >>> I mean for users logging into a coffee shop, Hotels etc. >>> >>> How will these endpoints know the credentials to use with the TURN servers provided by ISP ? >> >> If the TURN server is provided by the network, couldn't we assume that >> authentication is network-based? That is, if you succeed in talking to >> the server, then that means you're good. TURN servers would effectively >> have "no authentication" in the protocol. >> >> Simon >> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 21 09:07:44 2014 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 A8F031A03FA for ; Fri, 21 Mar 2014 09:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 ZzfjsA5o5jON for ; Fri, 21 Mar 2014 09:07:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 165731A046A for ; Fri, 21 Mar 2014 09:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2026; q=dns/txt; s=iport; t=1395418050; x=1396627650; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vDpqpQoBaoVGDAn0GrAgpttFp275wx71GK3kFY6DFpU=; b=jsOam/1a3NQOp6oJR7J5OvUnF8iRDQtI5+apmYCqtoXYpVA5WlkPPHFa cg3XxLjfRSmuh2xqL8OjMzXfKI3hC6WDoHjbn+iWGl2x7vz11l2df32Yw ANM3oYDRPMj/AOi9+XtuX2IwDcy3kL4+gqSRUObShgRyKoPQ8WjvZRoDd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFADpjLFOtJXG8/2dsb2JhbABZgwaBEsJfgRUWdIIlAQEBAwF+BwYBCBEEAQEBCh05FAkJAQQBEggRh1gIz3YXjhInPoMegRQEiRqhYIMtgWlC X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208";a="308931145" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 21 Mar 2014 16:07:29 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2LG7TN1010830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 16:07:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 11:07:29 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9FH6AnyvOjTEEfSE60ur39gy8x4A== Date: Fri, 21 Mar 2014 16:07:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242DA09E@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.183] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ihq2gS87FlfkiYZU2nHWdQnuySA Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 16:07:41 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Friday, March 21, 2014 7:45 PM > To: Simon Perreault; Tirumaleswar Reddy (tireddy); Prashanth Patil (prasp= ati); > tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > I think that some type of authentication is necessary, even if all it pro= vides is the > ability to verify that the two ends of the tunnel remain consistent throu= ghout the > life of the allocation. Without at least that, then the service is open t= o DOS > attacks via message injection.=20 Agreed, some type of authentication is necessary. > The network geographic location of the attacker > could be limited, but such attacks could not be prevented entirely. >=20 > Of course, TLS or DTLS could be used for this purpose, but is it reasonab= le to > require that overhead just for the purpose of authenticating the TURN con= trol > traffic? D{TLS} would also be required for privacy reasons for example to ensure ea= vesdropper does not find out the remote peer the user is communicating.=20 -Tiru >=20 > --Brandon >=20 > On 03/21/2014 08:58 AM, Simon Perreault wrote: > > Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a =E9crit : > >> Yes. It brings few other challenges like if TURN server is provided by= ISP then > how will authentication and authorization work ? > >> I mean for users logging into a coffee shop, Hotels etc. > >> > >> How will these endpoints know the credentials to use with the TURN ser= vers > provided by ISP ? > > > > If the TURN server is provided by the network, couldn't we assume that > > authentication is network-based? That is, if you succeed in talking to > > the server, then that means you're good. TURN servers would > > effectively have "no authentication" in the protocol. > > > > Simon > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Fri Mar 21 09:11:18 2014 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 2BA7D1A03FD for ; Fri, 21 Mar 2014 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 uRbQmHqqro8y for ; Fri, 21 Mar 2014 09:11:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4AAA1A046A for ; Fri, 21 Mar 2014 09:11:13 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB04D40440; Fri, 21 Mar 2014 12:11:03 -0400 (EDT) Message-ID: <532C6497.4070004@viagenie.ca> Date: Fri, 21 Mar 2014 12:11:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242DA09E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242DA09E@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LKTo27nwT9KoOMR4gsRpWQxjN-I Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 16:11:16 -0000 Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a écrit : >> I think that some type of authentication is necessary, even if all it provides is the >> ability to verify that the two ends of the tunnel remain consistent throughout the >> life of the allocation. Without at least that, then the service is open to DOS >> attacks via message injection. > > Agreed, some type of authentication is necessary. That's not what I would call authentication. [D]TLS without authentication protects against message injection AFAIK. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 09:28:51 2014 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 5E6B31A0470 for ; Fri, 21 Mar 2014 09:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 tyn_7v1MxOUd for ; Fri, 21 Mar 2014 09:28:47 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 554691A03FA for ; Fri, 21 Mar 2014 09:28:47 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9DE74286A7; Fri, 21 Mar 2014 16:28:37 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 8C597286A6; Fri, 21 Mar 2014 16:28:37 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 2F7E22026; Fri, 21 Mar 2014 16:28:37 +0000 (GMT) Message-ID: <532C68B4.2090404@akamai.com> Date: Fri, 21 Mar 2014 12:28:36 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simon Perreault , "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242DA09E@xmb-rcd-x10.cisco.com> <532C6497.4070004@viagenie.ca> In-Reply-To: <532C6497.4070004@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fyeuW4k0azTJ2qzJXGM7QpRYcT8 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 16:28:49 -0000 On 03/21/2014 12:11 PM, Simon Perreault wrote: > Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a écrit : >>> I think that some type of authentication is necessary, even if all it provides is the >>> ability to verify that the two ends of the tunnel remain consistent throughout the >>> life of the allocation. Without at least that, then the service is open to DOS >>> attacks via message injection. >> >> Agreed, some type of authentication is necessary. > > That's not what I would call authentication. [D]TLS without > authentication protects against message injection AFAIK. Agreed. Authentication was probably the wrong word. STUN mixes user authentication together with session-level integrity verification in such a way that if you lose one, you also lose the other. If we assume user authentication via some other mechanism, then we need to define an alternate integrity verification method. I'm not sure that requiring (D)TLS is the right way to do it, but I agree it's an option. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 21 09:32:57 2014 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 B92D51A09C1 for ; Fri, 21 Mar 2014 09:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 iZFN9QaIPt4n for ; Fri, 21 Mar 2014 09:32:54 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 37B721A09BD for ; Fri, 21 Mar 2014 09:32:54 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 93694474C1 for ; Fri, 21 Mar 2014 16:32:44 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 86E8F474C0 for ; Fri, 21 Mar 2014 16:32:44 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 6284EFE054 for ; Fri, 21 Mar 2014 16:32:44 +0000 (GMT) Message-ID: <532C69AC.7030800@akamai.com> Date: Fri, 21 Mar 2014 12:32:44 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242DA09E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242DA09E@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SH0yjzktGCr1dDWA6Sp5EBzZSGo Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 16:32:56 -0000 On 03/21/2014 12:07 PM, Tirumaleswar Reddy (tireddy) wrote: >> Of course, TLS or DTLS could be used for this purpose, but is it reasonable to >> require that overhead just for the purpose of authenticating the TURN control >> traffic? > > D{TLS} would also be required for privacy reasons for example to ensure eavesdropper does not find out the remote peer the user is communicating. I didn't mean to suggest that you don't get other benefits from using secure transport. I simply meant that requiring secure transport in order to get server discovery doesn't seem like it should be necessary. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 21 09:38:49 2014 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 D3A1D1A09EA for ; Fri, 21 Mar 2014 09:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 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.547, 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 Rd_MkfHZOM1d for ; Fri, 21 Mar 2014 09:38:42 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 37F971A09E9 for ; Fri, 21 Mar 2014 09:38:42 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so2794057veb.40 for ; Fri, 21 Mar 2014 09:38:32 -0700 (PDT) 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=XNwsJz5gLBrmfGA5WLVc5p/ainsVUOmuaSx6wPrQyx0=; b=MYDgufmiU41jJCPUg1IN29EMvr0Ns0LLTDntwAS7CI99KrJ7P0YcOXySOS+f2Vvop0 /7zc49c/CYS8p1tcJg5jBqqQss0H9laQcY6IF/5ZIxvlUG4KjhPIAlqYx+hjs7wSgS+G Iv8B1qclFpRm5FkSVlUQnx/Io2BRPjXP6W1H44iuP1C0YRx7AGhZvpS3/sUhgze6yrj6 DPfYOZTozDEbLeKmT4fALjBVifXD2r/xY/+7rdhrn/2Qgx/qjoqknDLySQLeS4yy28Xu kEH/bm9pVwSc0kMGwawJSQXvN7NOikZDKrAt9PeI2lE3RNkaBI+aHDQ0kvtXaroHgbne QZqw== 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=XNwsJz5gLBrmfGA5WLVc5p/ainsVUOmuaSx6wPrQyx0=; b=JanDuuiBazpAv0NpBnyYVJqg8PIgP+4icWY5w3XRb6cYHUzoqyFW75teE1VHxzpbn+ YHx19X/7Z52oTRgG0IpFq9GsucqXDhdOcQATELl1Fj1fuz+5HycnYuirTQKK0BpebtCC 4ZifatP6oanjuhlAM9Vy94PXyPNBV0E4dSc4sGEz/58AE6FWfpeGrhjsOsD3fRDqyLel rdBZxz2iof0Eh0v9DW/upVLoESXK9Wi+POyVn+iqPIKilq5NEOxhS2ZC9WokXgiejHiG WWtJi/zRLOOBwtVDuWkQan4CVMznOM+C02m4CVE4grh52r62Lf8a4VIjhojNoTM6EyJM MGOA== X-Gm-Message-State: ALoCoQlWWT3U2BHVhVLvDaTusU6tjOwkTOB/Rgbl4X2/UHcnhnpNt6P26UwkA7hsTrdP/cY40hqm0Agti4t7ZKRnmf0ZQPiBL+lTokk0a46ZbbtnVze1xTnmhepkuhzx4ADvcELvB80ac4vKGbTxucoFtQA/Na3Wt98Ro8MxUcL8ju2vhqBN9PJmhhIZzTF2RZFLgBk8NZXR X-Received: by 10.52.166.103 with SMTP id zf7mr8098844vdb.30.1395419912543; Fri, 21 Mar 2014 09:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.43 with HTTP; Fri, 21 Mar 2014 09:38:12 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> <561F556D-4F22-43B1-BAF2-DA5E477075C1@vidyo.com> From: Justin Uberti Date: Fri, 21 Mar 2014 09:38:12 -0700 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c2c10233304604f52084cb Archived-At: http://mailarchive.ietf.org/arch/msg/tram/v3RlrinZIlJJIkCDxXVk1gVPCJ4 Cc: Jonathan Lennox , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 21 Mar 2014 16:38:45 -0000 --001a11c2c10233304604f52084cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2014 at 10:29 PM, Oleg Moskalenko wrot= e: > Please see inline: > > > On Thu, Mar 20, 2014 at 9:32 AM, Jonathan Lennox wrot= e: > >> >> On Mar 20, 2014, at 12:26 PM, Justin Uberti wrote: >> >> On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox w= rote: >> >>> I don=E2=80=99t think using XOR-RELAYED-ADDRESS with ANY to mean parti= al >>> failure is a good idea. >>> >>> STUN attributes are cheap. I suggest an a new attribute >>> UNAVAILABLE-ADDRESS-FAMILY, which can be sent in an SSODA success respo= nse. >>> If we want to be able to distinguish reasons for unavailability, the >>> attribute can be formatted as address-family/error-code/reason-phrase. >>> >> >>> In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure >>> responses as well, if people think it would be useful to be able to >>> describe cases where the IPv4 and IPv6 allocations failed for different >>> reasons. >>> >> >> This would be essentially ERROR-CODE with an address family. We could >> make a new attribute as you describe, or we could try to claim some of t= he >> reserved bits in the existing ERROR-CODE. >> >> >> Formatting-wise, yes, I=E2=80=99d use some of the reserved bits in ERRO= R-CODE >> to carry the address family. >> >> I think that giving it a different attribute number would be a good >> idea, though, since it=E2=80=99s semantically different. >> > > [Oleg] That's probably OK. I guess we want it in comprehension-optional > range; then we can try to make it somewhat backward compatible for older > clients. > > >> >> Additionally =E2=80=94 I don=E2=80=99t like SSODA=E2=80=99s mechanism= of deliberately >>> triggering behavior that=E2=80=99s undefined according to RFC 6156. It= seems like >>> this will be fragile. I=E2=80=99d suggest instead that we define a >>> comprehension-optional ADDITIONAL-REQUESTED-ADDRESS-FAMILY attribute, >>> formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSODA-aware = TURN >>> server will use but a strict 6156 TURN server will ignore. >>> >> >> Agree this would be a better approach. >> >> > [Oleg] I actually think that the original proposal of two equally > important "symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" th= an > introducing an "asymmetric" schema of "primary" and "additional" addresse= s > families. I feel that there may be a number of potential behavioral and > compatibility issues if we treat them differently. > > Agree it is semantically cleaner (which is why I liked it), but Jonathan'= s point about undefined behavior is a good one. I would rather have a slightly less clean design that I feel confident will work across all 5766-compliant servers, than a perfect design that fails completely in 1% of cases. --001a11c2c10233304604f52084cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 10:29 PM, Oleg Moskalenko <mom040267@gma= il.com> wrote:
Please see inline:
=


On Thu, Mar 20, 2014 at 9:32 AM, Jonathan Lennox <jonathan@vidyo.com&= gt; wrote:

On Mar 20, 2014, at 12:26 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Mar 20, 2014 at 8:39 AM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:
I don=E2=80=99t think using XOR-RELAYED-ADDRESS with ANY to mean parti= al failure is a good idea.

STUN attributes are cheap. =C2=A0I suggest an a new attribute UNAVAILA= BLE-ADDRESS-FAMILY, which can be sent in an SSODA success response. =C2=A0I= f we want to be able to distinguish reasons for unavailability, the attribu= te can be formatted as address-family/error-code/reason-phrase.=C2=A0

In principle UNAVAILABLE-ADDRESS-FAMILY could be sent in SSODA failure= responses as well, if people think it would be useful to be able to descri= be cases where the IPv4 and IPv6 allocations failed for different reasons.= =C2=A0

This would be essentially ERROR-CODE with an address family. We could = make a new attribute as you describe, or we could try to claim some of the = reserved bits in the existing ERROR-CODE.

Formatting-wise, yes, I=E2=80=99d use some of the reserved bits = in ERROR-CODE to carry the address family.

I think that giving it a different attribute number would be a good id= ea, though, since it=E2=80=99s semantically different.

[Oleg] That's probably OK. I guess = we want it in comprehension-optional range; then we can try to make it some= what backward compatible for older clients.
=C2=A0

Additionally =E2=80=94 I don=E2=80=99t like SSODA=E2=80=99s mechanism = of deliberately triggering behavior that=E2=80=99s undefined according to R= FC 6156. =C2=A0It seems like this will be fragile. =C2=A0I=E2=80=99d sugges= t instead that we define a comprehension-optional ADDITIONAL-REQUESTED-ADDR= ESS-FAMILY attribute, formatted identically to REQUESTED-ADDRESS-FAMILY, which a SSOD= A-aware TURN server will use but a strict 6156 TURN server will ignore.

Agree this would be a better approach.

[Oleg] I actu= ally think that the original proposal of two equally important "symmet= ric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than i= ntroducing an "asymmetric" schema of "primary" and &quo= t;additional" addresses families. I feel that there may be a number of= potential behavioral and compatibility issues if we treat them differently= .

Agree = it is semantically cleaner (which is why I liked it), but Jonathan's po= int about undefined behavior is a good one. I would rather have a slightly = less clean design that I feel confident will work across all 5766-compliant= servers, than a perfect design that fails completely in 1% of cases.
--001a11c2c10233304604f52084cb-- From nobody Fri Mar 21 09:51:18 2014 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 D9A541A0759 for ; Fri, 21 Mar 2014 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 fE9TceeRZfhD for ; Fri, 21 Mar 2014 09:51:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1925F1A0457 for ; Fri, 21 Mar 2014 09:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1395420665; x=1396630265; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=4NJH3lZ04NvVIMikilxVUf2Jwlnc4MXMlQScVSNV/kU=; b=bXUgqFKE2TXNiQWlkHeQlSochDPC2QoPPp0f1C4HLWHChxy0hzDKbHv7 XaGbZA9xpTkva6Z7zWt45XcxMF1WzuC+bnWJTPkuYc8Lfo8Ut6GYZZ2Yq qUQa5TXEz9eIcPtf/gQzjDfMt/O9Xz1FjqVTaSE6y9r8viWkhd267qIPn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJNsLFOtJXG8/2dsb2JhbABZgwY7V8JfgRUWdIIlAQEBAwEnXgYBCBEEAQELHTkUCQkBBAESCBGHWAjPYxeOOT6DHoEUBIkakGGQf4Mtgis X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208";a="311789588" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 21 Mar 2014 16:51:02 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2LGp2AW020220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 16:51:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 11:51:02 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9FJbsFTBkECL+eSXabbZ2qD46QCA== Date: Fri, 21 Mar 2014 16:51:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.183] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sJmDsNlO8P1Ys-J-Uk2Ywmayxzc Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 16:51:16 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Friday, March 21, 2014 9:41 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (pras= pati); > tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a =E9crit : > >> I think that some type of authentication is necessary, even if all it > >> provides is the ability to verify that the two ends of the tunnel > >> remain consistent throughout the life of the allocation. Without at > >> least that, then the service is open to DOS attacks via message inject= ion. > > > > Agreed, some type of authentication is necessary. >=20 > That's not what I would call authentication. [D]TLS without authenticatio= n > protects against message injection AFAIK. DTLS without authentication won't protect the TURN server from clients send= ing huge number of Allocate requests and taking up all the resources in the= TURN server.=20 I think both D{TLS} and authentication is required. -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 10:50:42 2014 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 423E31A08DC for ; Fri, 21 Mar 2014 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 fFioDZbn4E_y for ; Fri, 21 Mar 2014 10:50:38 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id AA6091A03BF for ; Fri, 21 Mar 2014 10:50:38 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/21/2014 1:50:28 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-200/SG:5 3/21/2014 1:50:03 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.955666 p=-0.984796 Source White X-Signature-Violations: 0-0-0-8643-c X-Note-419: 15.6005 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/21/2014 1:50:22 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 108097103; Fri, 21 Mar 2014 13:50:28 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Fri, 21 Mar 2014 12:50:27 -0500 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [tram] SSODA (Single SOcket Dual Allocation with TURN) Thread-Index: Ac9CkqpZJGocJ2jdTwSef3K1BegT6wAckHsAAA27zZAAEZsigAAO6dQAAAnJFIAAJdlvAAABpgAAAAAxLQAAGyYzAAAXWz0AAAKF0QA= Date: Fri, 21 Mar 2014 17:50:27 +0000 Message-ID: <3E97D848-A183-4EBF-8AFE-5F614F47DC8A@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242D6298@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A242D7CC0@xmb-rcd-x10.cisco.com> <4783A5B4-82F6-4DE0-8D62-8865ACAC4EB4@cisco.com> <913383AAA69FF945B8F946018B75898A242D8566@xmb-rcd-x10.cisco.com> <22471A07-2B9F-4AB4-9168-DD4F3DFC21CB@vidyo.com> <561F556D-4F22-43B1-BAF2-DA5E477075C1@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_3E97D848A1834EBF8AFE5F614F47DC8Avidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fzw5ukVXztK2veayfXqIqv8Y48g Cc: Oleg Moskalenko , "Pal Martinsen \(palmarti\)" , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN) 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, 21 Mar 2014 17:50:40 -0000 --_000_3E97D848A1834EBF8AFE5F614F47DC8Avidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 21, 2014, at 12:38 PM, Justin Uberti > wrote: On Thu, Mar 20, 2014 at 10:29 PM, Oleg Moskalenko > wrote: [Oleg] I actually think that the original proposal of two equally important= "symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cleaner" than introduc= ing an "asymmetric" schema of "primary" and "additional" addresses families= . I feel that there may be a number of potential behavioral and compatibili= ty issues if we treat them differently. Agree it is semantically cleaner (which is why I liked it), but Jonathan's = point about undefined behavior is a good one. I would rather have a slightl= y less clean design that I feel confident will work across all 5766-complia= nt servers, than a perfect design that fails completely in 1% of cases. Exactly. The intention is that these two attributes *would* be semanticall= y identical, for a server that supports SSODA; it=92s only the backward-com= patibility case that would be treated differently. Additionally, it would give clients control over what happens (i.e., which = address they get) if they do turn out to be talking to a 5766 (well, 6156) = server, rather than having the result be unpredictable. --_000_3E97D848A1834EBF8AFE5F614F47DC8Avidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6F653A7846B00244A8338C69F7104FEC@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Mar 21, 2014, at 12:38 PM, Justin Uberti <juberti@google.com> wrote:

On Thu, Mar 20, 2014 at 10:29 PM, Oleg Moskalenk= o <mom040267@gmai= l.com> wrote:

[Oleg] I actually think that the original proposal of two equally impo= rtant "symmetric" REQUESTED-ADDRESS-FAMILY attributes is "cl= eaner" than introducing an "asymmetric" schema of "prim= ary" and "additional" addresses families. I feel that there = may be a number of potential behavioral and compatibility issues if we treat them= differently.

Agree it is semantically cleaner (which is why I liked it), but Jonath= an's point about undefined behavior is a good one. I would rather have a sl= ightly less clean design that I feel confident will work across all 5766-co= mpliant servers, than a perfect design that fails completely in 1% of cases.

Exactly.  The intention is that these two attributes *would* be s= emantically identical, for a server that supports SSODA; it=92s only the ba= ckward-compatibility case that would be treated differently.

Additionally, it would give clients control over what happens (i.e., w= hich address they get) if they do turn out to be talking to a 5766 (well, 6= 156) server, rather than having the result be unpredictable.


--_000_3E97D848A1834EBF8AFE5F614F47DC8Avidyocom_-- From nobody Fri Mar 21 13:03:47 2014 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 84A1A1A0808 for ; Fri, 21 Mar 2014 13:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.855 X-Spam-Level: ** X-Spam-Status: No, score=2.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_DISCOUNT=4.455, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7] 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 A-6E0Zys2pbZ for ; Fri, 21 Mar 2014 13:03:44 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id C2CCC1A034F for ; Fri, 21 Mar 2014 13:03:42 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403212103279374; Fri, 21 Mar 2014 21:03:27 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" , "'Brandon Williams'" , "'Prashanth Patil \(praspati\)'" , References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> Date: Fri, 21 Mar 2014 21:03:26 +0100 Message-ID: <014c01cf4540$9f32be00$dd983a00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9FJbsFTBkECL+eSXabbZ2qD46QCAAAeecw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/e0XsLjfl0u4RasrYKgFA8u7xaBU Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 20:03:46 -0000 1) I want to emphasize Simon's view in the authentication discussion: " If the TURN server is provided by the network, couldn't we assume that authentication is network-based? That is, if you succeed in talking to = the server, then that means you're good. TURN servers would effectively have = "no authentication" in the protocol." The need for this milestone mechanism/RFC is for an enterprise or a an = ISP to announce a TURN server for their users of their network. The DHCP = method directly reflects this by responding: "Here are your IP address, your default gateway, your DNS servers and = now the suggested TURN server to use". (The TURN deployed is a networks = resource only available on the local connection - it only has the allocated = public port available to the WAN-side. That is TURN server/router/firewall combination more or less integrated.)=20 So the auto discovered turn-server should only be available and offered = to those allowed to use it - rather than being authenticated (like an application provided TURN server is). The browser should use the auto discovered TURN server without authentication. 2) The opposite - Can the browser trust the TURN server offered (also = raised here)? - is not a problem with the DHCP method (If we get network = resources like our IP address, default gateway via DHCP, we should of course also trust and the same DHCP server with giving us the TURN server address to place our real-time traffic at.) However, that may not be the case with the AnyCast method. Simon = previously raised: "> Suppose we define well-known anycast TURN server addresses. How would = > this not be subject to the same service quality issues that plagued=20 > 6to4? That is, anyone could set up a badly-maintained,=20 > under-provisioned TURN server and announce it over BGP to the world,=20 > as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how=20 > can we prevent triangle routing? There is nothing guaranteeing that=20 > the anycast server you see is being provided to you by your ISP,=20 > rather than a server sitting on the other side of the planet I got an "network-way idea" to address this from a developer of ours = that I have not considered/presented yet and I will also read up on draft draft-patil-tram-turn-serv-disc-00, and see it I have some educated = thoughts to contribute. It would be good if we can avoid having to introduce certificates or similar here and just stick to the network level. A few other points (maybe a better read of draft-patil-tram-turn-serv-disc-00 obsoletes some of these points and I = will know better on Monday, but anyway): 3) Two methods (DHCP and Anycast) are suggested in the draft. I assume = the thought is that browsers must implement both and the ISP can use any. Correct?=20 - But if one is good enough, shall we then drop the other to make life easier?=20 4) In addition to some doubts raised here against the DHCP discovery, = there were plenty in the discussion at the September-October discussion at the [rtcweb]-list (summary in http://www.ietf.org/mail-archive/web/tram/current/msg00132.html), = mainly:=20 a: concerns whether OSs actually forwards such extended DHCP information = for the browser to use - If I remember correctly, only Bernard Aboba from MS confirmed that is = was available in Windows. b: I withdrew my own(!) suggestion to use DHCP to find a network = provider offered TURN server because DHCP is NOT used in many networks, which = instead use (for handing out IP address etc): RA - Router Advertisement - in = IPv6, the IPCP protocol for PPPoE and something else for the mobile OTT = channel. I tend to focus on the Anycast method only (but will read up on draft-patil-tram-turn-serv-disc-00 until Monday and may be more educated then...) /Karl =20 -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Tirumaleswar Reddy = (tireddy) Skickat: den 21 mars 2014 17:51 Till: Simon Perreault; Brandon Williams; Prashanth Patil (praspati); tram@ietf.org =C4mne: Re: [tram] TURN server discovery (please discuss!) > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Friday, March 21, 2014 9:41 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil=20 > (praspati); tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a =E9crit : > >> I think that some type of authentication is necessary, even if all=20 > >> it provides is the ability to verify that the two ends of the=20 > >> tunnel remain consistent throughout the life of the allocation.=20 > >> Without at least that, then the service is open to DOS attacks via message injection. > > > > Agreed, some type of authentication is necessary. >=20 > That's not what I would call authentication. [D]TLS without=20 > authentication protects against message injection AFAIK. DTLS without authentication won't protect the TURN server from clients sending huge number of Allocate requests and taking up all the resources = in the TURN server.=20 I think both D{TLS} and authentication is required. -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Fri Mar 21 13:24:35 2014 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 D13D91A08FA for ; Fri, 21 Mar 2014 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 RMI9Fyh0HLJc for ; Fri, 21 Mar 2014 13:24:30 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 888741A0720 for ; Fri, 21 Mar 2014 13:24:30 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BDF8F286C4; Fri, 21 Mar 2014 20:24:20 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A95ED286C3; Fri, 21 Mar 2014 20:24:20 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 299F18004F; Fri, 21 Mar 2014 20:24:20 +0000 (GMT) Message-ID: <532C9FF3.10305@akamai.com> Date: Fri, 21 Mar 2014 16:24:19 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QSvh5jf-WecOX9K75lRaYJ2jWpc Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 20:24:33 -0000 Since it's a service being provided by the network provider, the provider could easily apply a policy-based solution to the problem you describe (e.g. rate-limiting allocation requests). Are there other specific operations where you think lack of authentication could be a problem to which it's not possible to apply a policy-enforcement solution? --Brandon On 03/21/2014 12:51 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Friday, March 21, 2014 9:41 PM >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (praspati); >> tram@ietf.org >> Subject: Re: [tram] TURN server discovery (please discuss!) >> >> Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a écrit : >>>> I think that some type of authentication is necessary, even if all it >>>> provides is the ability to verify that the two ends of the tunnel >>>> remain consistent throughout the life of the allocation. Without at >>>> least that, then the service is open to DOS attacks via message injection. >>> >>> Agreed, some type of authentication is necessary. >> >> That's not what I would call authentication. [D]TLS without authentication >> protects against message injection AFAIK. > > DTLS without authentication won't protect the TURN server from clients sending huge number of Allocate requests and taking up all the resources in the TURN server. > I think both D{TLS} and authentication is required. > > -Tiru > >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 21 13:49:46 2014 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 372651A0A25 for ; Fri, 21 Mar 2014 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8YQWp5Woo02 for ; Fri, 21 Mar 2014 13:49:43 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 26FBC1A0A1D for ; Fri, 21 Mar 2014 13:49:43 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id bj1so2885230pad.2 for ; Fri, 21 Mar 2014 13:49:33 -0700 (PDT) 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=9INnjcBAAZL0a1oeXbfwLA2KRLPntGZBf4i1DpRcukA=; b=dAjXm7CDf+4A8RUfYS9ea6rPdzWNb8wcDYkn5T1jAStUUitZQnxwHDGgQhBhXss1Ie SYhl0+L6QvjoUQLaAwDYttW3nARYRaqtPdLz4hi65yfVzKDv6mz4dDvu6qoYx/iwV1eI 0vP0LstO/2e7v/y1DwnBFrDHHU1neFFGeDBHmmVt2HO/TW9yLGapXRzGXQVJIU/N6Ixw wEhm/TKFxNqTQe8lmrwr3PVdcBgBe0P5a9KZtji8cLUd7ZX2ZnCgVdAZK+hkxzKnWpul ye61nviLxfM9ApBtTZ2Cl5DVO3Ye+KcrReLzxFkIz5/JUxRmac6BogoQXr26Kyh5XrRm YHRQ== MIME-Version: 1.0 X-Received: by 10.68.241.73 with SMTP id wg9mr58061037pbc.62.1395434973817; Fri, 21 Mar 2014 13:49:33 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 21 Mar 2014 13:49:33 -0700 (PDT) In-Reply-To: <532C9FF3.10305@akamai.com> References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> Date: Fri, 21 Mar 2014 13:49:33 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b33993fec197d04f52405bf Archived-At: http://mailarchive.ietf.org/arch/msg/tram/q6hSrD_61Uh15eHAYxSks39m7do Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 20:49:45 -0000 --047d7b33993fec197d04f52405bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Current situation is that the existing WebRTC clients do not support TURN servers without authentication (no-authentication option). Having a sort of authentication to simplify the DOS attacks defense would be nice. For example, a long-term credentials mechanism with password equals to the username. Then any client will be able to authenticate itself but a DOS attack would be difficult - because a full auth cycle will be happening. A replay attacks will also be addressed, if the TURN server handles the nonces properly. On Fri, Mar 21, 2014 at 1:24 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > Since it's a service being provided by the network provider, the provider > could easily apply a policy-based solution to the problem you describe > (e.g. rate-limiting allocation requests). Are there other specific > operations where you think lack of authentication could be a problem to > which it's not possible to apply a policy-enforcement solution? > > --Brandon > > > On 03/21/2014 12:51 PM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- >>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >>> Sent: Friday, March 21, 2014 9:41 PM >>> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil >>> (praspati); >>> tram@ietf.org >>> Subject: Re: [tram] TURN server discovery (please discuss!) >>> >>> Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a =E9crit : >>> >>>> I think that some type of authentication is necessary, even if all it >>>>> provides is the ability to verify that the two ends of the tunnel >>>>> remain consistent throughout the life of the allocation. Without at >>>>> least that, then the service is open to DOS attacks via message >>>>> injection. >>>>> >>>> >>>> Agreed, some type of authentication is necessary. >>>> >>> >>> That's not what I would call authentication. [D]TLS without >>> authentication >>> protects against message injection AFAIK. >>> >> >> DTLS without authentication won't protect the TURN server from clients >> sending huge number of Allocate requests and taking up all the resources= in >> the TURN server. >> I think both D{TLS} and authentication is required. >> >> -Tiru >> >> >>> Simon >>> -- >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b33993fec197d04f52405bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Current situation is that the existing WebRTC clients= do not support TURN servers without authentication (no-authentication opti= on).

Having a sort of authentication to simplify the DOS attac= ks defense would be nice. For example, a long-term credentials mechanism wi= th password equals to the username. Then any client will be able to authent= icate itself but a DOS attack would be difficult - because a full auth cycl= e will be happening. A replay attacks will also be addressed, if the TURN s= erver handles the nonces properly.


On Fri,= Mar 21, 2014 at 1:24 PM, Brandon Williams <brandon.williams@aka= mai.com> wrote:
Since it's a service being provided by t= he network provider, the provider could easily apply a policy-based solutio= n to the problem you describe (e.g. rate-limiting allocation requests). Are= there other specific operations where you think lack of authentication cou= ld be a problem to which it's not possible to apply a policy-enforcemen= t solution?

--Brandon


On 03/21/2014 12:51 PM, Tirumaleswar Reddy (tireddy) wrote:
-----Original Message-----
From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
Sent: Friday, March 21, 2014 9:41 PM
To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (praspa= ti);
tram@ietf.org
Subject: Re: [tram] TURN server discovery (please discuss!)

Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a =E9crit :
I think that some type of authentication is necessary, even if all it
provides is the ability to verify that the two ends of the tunnel
remain consistent throughout the life of the allocation. Without at
least that, then the service is open to DOS attacks via message injection.<= br>

Agreed, some type of authentication is necessary.

That's not what I would call authentication. [D]TLS without authenticat= ion
protects against message injection AFAIK.

DTLS without authentication won't protect the TURN server from clients = sending huge number of Allocate requests and taking up all the resources in= the TURN server.
I think both D{TLS} and authentication is required.

-Tiru


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b33993fec197d04f52405bf-- From nobody Fri Mar 21 13:59:55 2014 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 E54091A08FA for ; Fri, 21 Mar 2014 13:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 3WV2rh_U_-fJ for ; Fri, 21 Mar 2014 13:59:52 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 33E571A08E2 for ; Fri, 21 Mar 2014 13:59:52 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 476B740440; Fri, 21 Mar 2014 16:59:42 -0400 (EDT) Message-ID: <532CA83D.70005@viagenie.ca> Date: Fri, 21 Mar 2014 16:59:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko , Brandon Williams References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oQTqlwuPIPQHz_n69UK4Jr9yTSc Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 20:59:54 -0000 Le 2014-03-21 16:49, Oleg Moskalenko a écrit : > Current situation is that the existing WebRTC clients do not support > TURN servers without authentication (no-authentication option). If this is indeed the case, wouldn't it be trivial to modify the client's code so that auth-less TURN servers are supported? > Having a sort of authentication to simplify the DOS attacks defense > would be nice. For example, a long-term credentials mechanism with > password equals to the username. Then any client will be able to > authenticate itself but a DOS attack would be difficult - because a full > auth cycle will be happening. Where does the username come from? How would a "full auth cycle" prevent a DoS? > A replay attacks will also be addressed, > if the TURN server handles the nonces properly. I don't see what threat this addresses. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 14:11:36 2014 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 0E4181A08C6 for ; Fri, 21 Mar 2014 14:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOHRmCQzYnEg for ; Fri, 21 Mar 2014 14:11:32 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA0C1A0410 for ; Fri, 21 Mar 2014 14:11:32 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so2816937pdj.34 for ; Fri, 21 Mar 2014 14:11:22 -0700 (PDT) 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=pr1pJ3XHuiahBL/jz6Sc3hjShydQAdqspfvVDxZLH2E=; b=gUVrX4jJjGqLvC0/EBggjcmV3jkMY2fOzMC9gKI903Nld58DgO//I2Zg3e3O2T4KV2 hBox99nxbE946pfWsseJgVsWu/R9vwviqO0wRYY2v1YwiY/ebuOcq5CDfnuAUedZiVu0 lTAzGDJhSDcgYp3Iddvn1etCdVI1ksU8NMUT2ma6D7+xJEggraQpE4TJIn4lFl1LAY6Y ixn1zNYvd/I1bWQv/xJyFJeZi93okkGMqD93I4c/9zm3KRfSJtNlwUkm+ktFhE/0MaWn De+pOg+IchtmtDdDuEZdpqMMhXou8oLmkKr8cO9gB1yLgcRf0cQsWnnb8g7mO1oHDv4a 3e3Q== MIME-Version: 1.0 X-Received: by 10.66.25.203 with SMTP id e11mr56836435pag.76.1395436282902; Fri, 21 Mar 2014 14:11:22 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 21 Mar 2014 14:11:22 -0700 (PDT) In-Reply-To: <532CA83D.70005@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> Date: Fri, 21 Mar 2014 14:11:22 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=bcaec5299c4df2ff1b04f524538f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RLFiFzsVjbPsAWJYeCIQEIiZ5z8 Cc: "Prashanth Patil \(praspati\)" , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 21:11:34 -0000 --bcaec5299c4df2ff1b04f524538f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 21, 2014 at 1:59 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-21 16:49, Oleg Moskalenko a =E9crit : > > Current situation is that the existing WebRTC clients do not support > > TURN servers without authentication (no-authentication option). > > If this is indeed the case, wouldn't it be trivial to modify the > client's code so that auth-less TURN servers are supported? > that's a question for WebRTC platform developers (not application developers, that's part of the core). Hopefully that must be easy. But the existing WebRTC clients will have to be replaced. > > > Having a sort of authentication to simplify the DOS attacks defense > > would be nice. For example, a long-term credentials mechanism with > > password equals to the username. Then any client will be able to > > authenticate itself but a DOS attack would be difficult - because a ful= l > > auth cycle will be happening. > > Where does the username come from? > In the proposed scheme, the TURN client is free to use any username. In the TURN auth challenge reply, clients sends the username in the response. So the TURN server learns the username. Then the TURN server can take that username and assume that the password is equal to the username. Then the server is checking the validity of the reply - going thru the full integrity check. If the nonce is unique, then the dialog will be unique and cannot be copied. > How would a "full auth cycle" prevent a DoS? > The auth dialog will serve the same purpose as the cookie request-response in DTLS negotiations. Each dialog is unique, so a DOS attack is much more difficult - because a stupid simple traffic generator would not work. > > > A replay attacks will also be addressed, > > if the TURN server handles the nonces properly. > > I don't see what threat this addresses. > A simple replay of the client traffic will be rejected by the server. Oleg --bcaec5299c4df2ff1b04f524538f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 21, 2014 at 1:59 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-21 16:49, Oleg Moskalenko a =E9cr= it :
> Current situation is that the existing WebRTC client= s do not support
> TURN servers without authentication (no-authentication option).

If this is indeed the case, wouldn't it be trivial to modify the<= br> client's code so that auth-less TURN servers are supported?

that's a question for WebRTC platform develope= rs (not application developers, that's part of the core). Hopefully tha= t must be easy. But the existing WebRTC clients will have to be replaced.
=A0

> Having a sort of authentication to simplify the DOS attacks defense > would be nice. For example, a long-term credentials mechanism with
> password equals to the username. Then any client will be able to
> authenticate itself but a DOS attack would be difficult - because a fu= ll
> auth cycle will be happening.

Where does the username come from?

In the proposed scheme, the TURN client is free to use any username. In t= he TURN auth challenge reply, clients sends the username in the response. S= o the TURN server learns the username. Then the TURN server can take that u= sername and assume that the password is equal to the username. Then the ser= ver is checking the validity of the reply - going thru the full integrity c= heck. If the nonce is unique, then the dialog will be unique and cannot be = copied.


How would a "full auth cycle" prevent a DoS?

The auth dialog will serve the same purpose as the cookie r= equest-response in DTLS negotiations. Each dialog is unique, so a DOS attac= k is much more difficult - because a stupid simple traffic generator would = not work.

=A0

> A replay attacks will also be addressed,
> if the TURN server handles the nonces properly.

I don't see what threat this addresses.

=
A simple replay of the client traffic will be rejected by the se= rver.
=A0

Oleg
--bcaec5299c4df2ff1b04f524538f-- From nobody Fri Mar 21 14:18:44 2014 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 AF5701A09FD for ; Fri, 21 Mar 2014 14:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 u3faC4NP0eu7 for ; Fri, 21 Mar 2014 14:18:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 153631A09F5 for ; Fri, 21 Mar 2014 14:18:39 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5D7DA40440; Fri, 21 Mar 2014 17:18:29 -0400 (EDT) Message-ID: <532CACA5.6080204@viagenie.ca> Date: Fri, 21 Mar 2014 17:18:29 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/1-l1eYGrAAByhx9qx1Yh0rnCzS4 Cc: "Prashanth Patil \(praspati\)" , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 21:18:41 -0000 Le 2014-03-21 17:11, Oleg Moskalenko a écrit : > Where does the username come from? > > > In the proposed scheme, the TURN client is free to use any username. In > the TURN auth challenge reply, clients sends the username in the > response. So the TURN server learns the username. Then the TURN server > can take that username and assume that the password is equal to the > username. Then the server is checking the validity of the reply - going > thru the full integrity check. If the nonce is unique, then the dialog > will be unique and cannot be copied. > > > How would a "full auth cycle" prevent a DoS? > > > The auth dialog will serve the same purpose as the cookie > request-response in DTLS negotiations. Each dialog is unique, so a DOS > attack is much more difficult - because a stupid simple traffic > generator would not work. So it's all about making the client implementation more complex so that only determined attackers can launch an attack? If that's right then I don't see what this would buy us. Smells like security by obscurity. The server would still need to enforce a usage policy as described by Brandon. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 21 14:54:20 2014 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 DDEB91A0900 for ; Fri, 21 Mar 2014 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfWOQeE_nmSL for ; Fri, 21 Mar 2014 14:54:17 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B92C71A076D for ; Fri, 21 Mar 2014 14:54:17 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fa1so2937124pad.14 for ; Fri, 21 Mar 2014 14:54:08 -0700 (PDT) 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=KUPRU6zM7ca+Ld9KUVNjZX/fPXKq+XX13pP7ni/PYcM=; b=qinO6VH2SCN3kJ8W4CVEb7UE2Y8lhHKZ0ig1LEO+Yk+TH/IbgJVg18dGjV/0bnVFGi Vt/OE5/nmF9HVHAZW97NMkoTV3iJmOnHgShRm8VJkz7teAghRYCdE1W99hg+8AYrqYcs lEQIpfmbN/UAv5UaAGNxtEz6AW8MD5zpdyGYV6296GXUWY3YmKm5xeHRDtuVuYCDLQik ZF858T7bJQPWGlZDFCK13eYwuhkOJHOX4TcFwCBQYOA7Qz24MvFPZXNhs5TLtnD/EmTl 1HAFADTUKFf48DDJ2Dbmy1j+chuBEPP+P1bxwHMCpVwBEaTuK/I5HcNLYbQ2mrymAiH8 yMkQ== MIME-Version: 1.0 X-Received: by 10.69.31.171 with SMTP id kn11mr57356255pbd.47.1395438848417; Fri, 21 Mar 2014 14:54:08 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 21 Mar 2014 14:54:08 -0700 (PDT) In-Reply-To: <532CACA5.6080204@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> <532CACA5.6080204@viagenie.ca> Date: Fri, 21 Mar 2014 14:54:08 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11366d0edda3d704f524ec62 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gVaROb25778AyksnUy9eyhRgFpk Cc: "Prashanth Patil \(praspati\)" , Brandon Williams , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 21 Mar 2014 21:54:19 -0000 --001a11366d0edda3d704f524ec62 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 21, 2014 at 2:18 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > > > > > In the proposed scheme, the TURN client is free to use any username. In > > the TURN auth challenge reply, clients sends the username in the > > response. So the TURN server learns the username. Then the TURN server > > can take that username and assume that the password is equal to the > > username. Then the server is checking the validity of the reply - going > > thru the full integrity check. If the nonce is unique, then the dialog > > will be unique and cannot be copied. > > > > > > How would a "full auth cycle" prevent a DoS? > > > > > > The auth dialog will serve the same purpose as the cookie > > request-response in DTLS negotiations. Each dialog is unique, so a DOS > > attack is much more difficult - because a stupid simple traffic > > generator would not work. > > So it's all about making the client implementation more complex so that > only determined attackers can launch an attack? > No, that's not right. I propose NO CHANGES to the client. That behavior does not introduce anything new. That is using the existing auth mechanism. I just proposed a convention that for the network-secured TURN servers, we use passwords equal to the usernames. That's it. Then the clients will be 100% backward-compatible, we will have cookie-like dialog session protection and the real authentication burden will be on the network infrastructure: if client can connect to the server, then the client is allowed to use the server. We will have the best of two approaches. > > If that's right then I don't see what this would buy us. Smells like > security by obscurity. The server would still need to enforce a usage > policy as described by Brandon. > > --001a11366d0edda3d704f524ec62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 21, 2014 at 2:18 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:

>
> In the proposed scheme, the TURN client is free to use any username. I= n
> the TURN auth challenge reply, clients sends the username in the
> response. So the TURN server learns the username. Then the TURN server=
> can take that username and assume that the password is equal to the > username. Then the server is checking the validity of the reply - goin= g
> thru the full integrity check. If the nonce is unique, then the dialog=
> will be unique and cannot be copied.
>
>
> =A0 =A0 How would a "full auth cycle" prevent a DoS?
>
>
> The auth dialog will serve the same purpose as the cookie
> request-response in DTLS negotiations. Each dialog is unique, so a DOS=
> attack is much more difficult - because a stupid simple traffic
> generator would not work.

So it's all about making the client implementation more complex s= o that
only determined attackers can launch an attack?

No, that's not right. I propose NO CHANGES to the client. That= behavior does not introduce anything new. That is using the existing auth = mechanism. I just proposed a convention that for the network-secured TURN s= ervers, we use passwords equal to the usernames. That's it. Then the cl= ients will be 100% backward-compatible, we will have cookie-like dialog ses= sion protection and the real authentication burden will be on the network i= nfrastructure: if=A0 client can connect to the server, then the client is a= llowed to use the server. We will have the best of two approaches.
=A0

If that's right then I don't see what this would buy us. Smells lik= e
security by obscurity. The server would still need to enforce a usage
policy as described by Brandon.


--001a11366d0edda3d704f524ec62-- From nobody Fri Mar 21 23:20:53 2014 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 3F89D1A086F for ; Fri, 21 Mar 2014 23:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 xHEKEXdiTbRX for ; Fri, 21 Mar 2014 23:20:50 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E21A085B for ; Fri, 21 Mar 2014 23:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1899; q=dns/txt; s=iport; t=1395469241; x=1396678841; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QsovLUvc/I7mmffJ5xmQYPKIYZx8dIqSfONKBnUDOo0=; b=MNO+4Npc1UzgF+PMcYxdx8j/Q0ochGEsCWdAB9UHYK/o6iirTSva5pK/ hxjWxBC5YGFrvQJ6Z6Xp4YI0mXo6o/a6nwP3PkATZXWFPKbhVTY2DRSlo sidyY5nV8K85IWK7wbHkJn0G/jRh0AYPyilIdyycwvFNQCqumPFluKdW0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAN0qLVOtJV2Y/2dsb2JhbABQCYMGO1e7MYc6gRUWdIIlAQEBAwEBAQEkRxcEAgEIEQQBAQsdBycLFAkIAgQBEggBh2gIDc4+F44NBwkCAR4zBQaDHoEUBIkakGKQf4Mtgis X-IronPort-AV: E=Sophos;i="4.97,708,1389744000"; d="scan'208";a="29500263" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 22 Mar 2014 06:20:40 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2M6KeYE005175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 06:20:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sat, 22 Mar 2014 01:20:40 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: AQHPREOE1UDf9oubAkWwBYvhNFfsfZrqYhQAgAALtACAAQzzAIAAWggAgADOxmA= Date: Sat, 22 Mar 2014 06:20:39 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242DA66C@xmb-rcd-x10.cisco.com> References: <532AF25B.4020301@viagenie.ca> <532B0974.1010404@viagenie.ca> <532C3696.1080004@viagenie.ca> In-Reply-To: <532C3696.1080004@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nSIVouf2-DyiKxO1JlXeW3yFsOc Subject: Re: [tram] TURN server discovery (please discuss!) 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, 22 Mar 2014 06:20:52 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Friday, March 21, 2014 6:25 PM > To: Prashanth Patil (praspati); tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Le 2014-03-21 03:32, Prashanth Patil (praspati) a =E9crit : > >>> There was a suggestion that domain name could also be extracted from > >>> own SIP/XMPP/email identity > >>> (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- > >>> which we plan to add to the draft in the next version. > >> > >> But that doesn't work because it would be an application-provided > >> TURN server. We need to discover network-provided TURN servers. > > > > Sure, but should we not provide a means for discovering those? >=20 > The point is that those means already exist. >=20 > > Maybe > > suggest that this should be attempted only if the client is not able > > to discover a network-provided server. The network provided server is > > probably closer, so attempt to discover that first. > > > > How to prioritize if a client discovers more than one TURN server is > > another discussions altogether. >=20 > Right. But IMHO prioritization is an easy problem compared with the actua= l > discovery. Prioritization of TURN server may also involve various parameters like path= characteristics (RTT, loss etc.), features provided by the TURN server (le= t's say with or without Mobility using TURN), =20 trust with the TURN server etc. -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sat Mar 22 02:04:00 2014 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 E84B21A0932 for ; Sat, 22 Mar 2014 02:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 HKolK2cvY803 for ; Sat, 22 Mar 2014 02:03:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id C394F1A039D for ; Sat, 22 Mar 2014 02:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2685; q=dns/txt; s=iport; t=1395479027; x=1396688627; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GqY9wTRXvqRwLslnnphrRl61EcUS/B/tjcNYUYRg1x4=; b=fUemLLA+d95c92MWAjMuFB1r412dIh9M0yUMgeXWuZ6DRuLa8XN6fObq znAOyGoLX3J3AB6FCJaZYcfmziPHdfKnA4Q4erVpZxkr0o4sh7W4/B5hB G1aHV/4q+1e9WDphwLMwlUQThKiWJizGb9DdaX2eFvfLUvoYRRTMcKLfV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAFhRLVOtJXG8/2dsb2JhbABZgwY7V7sxhzqBFRZ0giUBAQEEAQEBaAMbAgEIGC4nCyUBAQQBEhkCh14NzjMTBI4XX4Q4BIkai0SDbJIxgy2BaUI X-IronPort-AV: E=Sophos;i="4.97,708,1389744000"; d="scan'208";a="29512247" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 22 Mar 2014 09:03:46 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2M93kNn008023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 09:03:47 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Sat, 22 Mar 2014 04:03:46 -0500 From: "Prashanth Patil (praspati)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9E19q/TuSDFtQ6w0CH5HnkZEyyrg== Date: Sat, 22 Mar 2014 09:03:45 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> <532C4960.9030005@akamai.com> <532C4D24.5060007@akamai.com> In-Reply-To: <532C4D24.5060007@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.39.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <05AF60098551604580CB74D3AC533395@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5oc4jJczeEU1GAMYbdTIVWjits4 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 22 Mar 2014 09:03:59 -0000 On 3/21/14 8:01 PM, "Brandon Williams" wrote: >On a separate note, also related to (D)TLS ... > >It's not completely clear to me how the anycast approach to server >discovery would work together with secure data flows. What are the >server-side cert requirements in order to make an anycast solution work? >I'm not suggesting that it won't work -- just that people (like me) who >do have much expertize with cert management may need to have it spelled >out in order to evaluate whether the requirements seem reasonable. The response to an anycast request will be a 300 (try alternate) response. The response will contain the unicast address in the ALTERNATE_SERVER attribute. This has been discussed (in another context), and will be included in the next revision. Once you have a definitive address, certificate management (or issues with it) has to be dealt with the same way it's done for addresses learnt any other way. -Prashanth=20 > >--Brandon > >On 03/21/2014 10:14 AM, Brandon Williams wrote: >> I think that some type of authentication is necessary, even if all it >> provides is the ability to verify that the two ends of the tunnel remain >> consistent throughout the life of the allocation. Without at least that, >> then the service is open to DOS attacks via message injection. The >> network geographic location of the attacker could be limited, but such >> attacks could not be prevented entirely. >> >> Of course, TLS or DTLS could be used for this purpose, but is it >> reasonable to require that overhead just for the purpose of >> authenticating the TURN control traffic? >> >> --Brandon >> >> On 03/21/2014 08:58 AM, Simon Perreault wrote: >>> Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a =E9crit : >>>> Yes. It brings few other challenges like if TURN server is provided >>>>by ISP then how will authentication and authorization work ? >>>> I mean for users logging into a coffee shop, Hotels etc. >>>> >>>> How will these endpoints know the credentials to use with the TURN >>>>servers provided by ISP ? >>> >>> If the TURN server is provided by the network, couldn't we assume that >>> authentication is network-based? That is, if you succeed in talking to >>> the server, then that means you're good. TURN servers would effectively >>> have "no authentication" in the protocol. >>> >>> Simon >>> >> > >--=20 >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 24 05:27:08 2014 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 CDB6E1A01F0 for ; Mon, 24 Mar 2014 05:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.811 X-Spam-Level: X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 muSTRGngqyVd for ; Mon, 24 Mar 2014 05:27:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5E1A01EA for ; Mon, 24 Mar 2014 05:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2803; q=dns/txt; s=iport; t=1395664025; x=1396873625; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=otkywxsQ2bKtmNWPUyEwBYvbxAYabrZTFY8O45Rxn08=; b=Ba2DzDi98mwwp21u+ro08BIiAzf2ZC/gI2kLTpoQy+8K4TDzn2MBPmEE +V5eos1K6KmWnRs8rK3fybhxRI931YhONnehlQxmZoJUCTiphAG4pwzv/ JPMMGpNfkSexT/1+DDvXhBDshH73pi8/lhEU/pwesibk7vKQj7NSUD9IC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAFEkMFOtJV2Y/2dsb2JhbABZgwY7V8JygRYWdIIlAQEBAwEnVwcGAQgRBAEBAQodORQJCQEEARIIEQKHVgjNfBeOST6DHoEUBIkakGKQf4MtgWskHA X-IronPort-AV: E=Sophos;i="4.97,720,1389744000"; d="scan'208";a="312225105" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 24 Mar 2014 12:27:05 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2OCR505019444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 12:27:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 07:27:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9HXFnGNi3RciEPTYuYIsggEi2q9g== Date: Mon, 24 Mar 2014 12:27:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242DB0B8@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.67] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/GON_0V4hFRYl77Fl7NB8JkhkNR8 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 12:27:08 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Saturday, March 22, 2014 1:54 AM > To: Tirumaleswar Reddy (tireddy); Simon Perreault; Prashanth Patil (prasp= ati); > tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Since it's a service being provided by the network provider, the provider= could > easily apply a policy-based solution to the problem you describe (e.g. ra= te- > limiting allocation requests).=20 Yes, that will probably solve the problem. But how would the Mobile Node (M= N) trust the TURN server provided by the network when let's say MN is using= Coffee shop WIFI ? It could be a malicious TURN server provided to monitor the user activity. = If certificate validation is not possible then it becomes opportunistic enc= ryption. Further with this restriction, the network provided TURN server ma= y not be able to offer Mobility unlike the application provided TURN server= . -Tiru > Are there other specific operations where you think > lack of authentication could be a problem to which it's not possible to a= pply a > policy-enforcement solution ? >=20 > --Brandon >=20 > On 03/21/2014 12:51 PM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > >> Sent: Friday, March 21, 2014 9:41 PM > >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil > >> (praspati); tram@ietf.org > >> Subject: Re: [tram] TURN server discovery (please discuss!) > >> > >> Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a =E9crit : > >>>> I think that some type of authentication is necessary, even if all > >>>> it provides is the ability to verify that the two ends of the > >>>> tunnel remain consistent throughout the life of the allocation. > >>>> Without at least that, then the service is open to DOS attacks via m= essage > injection. > >>> > >>> Agreed, some type of authentication is necessary. > >> > >> That's not what I would call authentication. [D]TLS without > >> authentication protects against message injection AFAIK. > > > > DTLS without authentication won't protect the TURN server from clients > sending huge number of Allocate requests and taking up all the resources = in the > TURN server. > > I think both D{TLS} and authentication is required. > > > > -Tiru > > > >> > >> Simon > >> -- > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >> STUN/TURN server --> http://numb.viagenie.ca >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Mon Mar 24 05:56:31 2014 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 988561A01F7 for ; Mon, 24 Mar 2014 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8V89S-0wDoHO for ; Mon, 24 Mar 2014 05:56:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9481A01F6 for ; Mon, 24 Mar 2014 05:56:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 66D13401E9; Mon, 24 Mar 2014 08:56:26 -0400 (EDT) Message-ID: <53302B7A.1070701@viagenie.ca> Date: Mon, 24 Mar 2014 08:56:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242DB0B8@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242DB0B8@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wuKts9yf9rTAim4NgTzM0Wxa7y8 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 12:56:29 -0000 Le 2014-03-24 08:27, Tirumaleswar Reddy (tireddy) a écrit : > Yes, that will probably solve the problem. But how would the Mobile Node (MN) trust the TURN server provided by the network when let's say MN is using Coffee shop WIFI ? > It could be a malicious TURN server provided to monitor the user activity. If certificate validation is not possible then it becomes opportunistic encryption. Further with this restriction, the network provided TURN server may not be able to offer Mobility unlike the application provided TURN server. Do you trust the default gateway that is provided to you by DHCP when you log on a coffee shop wi-fi? No, you don't. But you still use it. And maybe you don't even consider this problematic. IMHO, if we dig deep enough we'll find that this problem is basically unfixable. There will always be an untrustworthy infrastructure layer on top of which trustworthy applications are built. I think what we need to do is: 0. Consider any network-provided TURN server as untrustworthy. This is an axiomatic position. 1. Devise a mechanism allowing this piece of untrustworthy infrastructure to be discovered. 2. Show how trustworthy applications can be built on top of this. (i.e., by encrypting media streams using SRTP, DTLS, etc.) The untrustworthy TURN server will be able to know the 5-tuples between the client and the peer. An untrustworthy IP router would equally be able to do it. But with appropriate encryption, it won't be able to discover anything more. So this would not introduce any new attack vector IMHO. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 24 06:04:09 2014 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 B65781A01F6 for ; Mon, 24 Mar 2014 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 o_cqIpi6ULl9 for ; Mon, 24 Mar 2014 06:04:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E029D1A01BA for ; Mon, 24 Mar 2014 06:04:04 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E8073401E9; Mon, 24 Mar 2014 09:04:03 -0400 (EDT) Message-ID: <53302D43.10205@viagenie.ca> Date: Mon, 24 Mar 2014 09:04:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> <532CACA5.6080204@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JPRQzbq8DrzyAzn2kkjEiLWxNTs Cc: "Prashanth Patil \(praspati\)" , Brandon Williams , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 13:04:06 -0000 Le 2014-03-21 17:54, Oleg Moskalenko a écrit : > No, that's not right. I propose NO CHANGES to the client. That behavior > does not introduce anything new. That is using the existing auth > mechanism. I just proposed a convention that for the network-secured > TURN servers, we use passwords equal to the usernames. That's it. Then > the clients will be 100% backward-compatible, we will have cookie-like > dialog session protection and the real authentication burden will be on > the network infrastructure: if client can connect to the server, then > the client is allowed to use the server. We will have the best of two > approaches. I'm sorry, I still don't get it fully. I understand the value of cookies in network protocols in general. But what I don't understand is: - What threat would this proposal be protecting against in STUN specifically? Can you give an example of an attack that this proposal would prevent? - Why is it important that we do not change clients? - Why do you not consider the new client behaviour "generate a username, use it as the password as well" a change to client implementation? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 24 07:51:01 2014 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 CCE0C1A0244; Mon, 24 Mar 2014 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jPTMiE_2wqXt; Mon, 24 Mar 2014 07:50:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9461A019A; Mon, 24 Mar 2014 07:50:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140324145056.18553.29840.idtracker@ietfa.amsl.com> Date: Mon, 24 Mar 2014 07:50:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ebnXKWsPWOkN2PQLnDZNRg-tZUE Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-auth-problems-00.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, 24 Mar 2014 14:50:58 -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 : Problems with STUN Authentication for TURN Authors : Tirumaleswar Reddy Ram Mohan Ravindranath Muthu Arul Mozhi Perumal Alper Yegin Filename : draft-ietf-tram-auth-problems-00.txt Pages : 7 Date : 2014-03-24 Abstract: This document discusses some of the issues with STUN authentication for TURN messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-auth-problems-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/ From nobody Mon Mar 24 07:53:28 2014 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 5C5371A0240 for ; Mon, 24 Mar 2014 07:53:24 -0700 (PDT) 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 WM_DOMDctjRm for ; Mon, 24 Mar 2014 07:53:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A40201A0244 for ; Mon, 24 Mar 2014 07:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2632; q=dns/txt; s=iport; t=1395672800; x=1396882400; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DbEDWgL2PnFgyJO/Z0ry/KmeNtt9OIdhvngHXTLPHlw=; b=PakjPV/mJzUl6DnWyFQG02nrdp/MwCwOGCWsTy2v4ctBEg9bGTJ6f3g1 O7tQV7biFTLsG8FK9EeixjUC8CegkVjQJzwONVOpwu+Y+ylfVcp9ScZLU VtbI2pJLP+KYZwkB3MKOq7Qa9xB9ZcXnY7lozkSLh9/p2ejBeals4Hs8R A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJFGMFOtJV2d/2dsb2JhbABZgwY7V8JtgRgWdIIlAQEBAwEnVwcEAgEIEQQBAQsdBzIUCQgBAQQBEgiHaQjOQheOSTgGgx6BFASJGpBikH+DLYFrJBw X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208";a="312537977" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 24 Mar 2014 14:53:19 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2OErJk9023728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 14:53:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 09:53:19 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9HXFnGNi3RciEPTYuYIsggEi2q9gALgZMAAAd2OMA= Date: Mon, 24 Mar 2014 14:53:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242DB1D0@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242DB0B8@xmb-rcd-x10.cisco.com> <53302B7A.1070701@viagenie.ca> In-Reply-To: <53302B7A.1070701@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.61.253] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lmA79q_ip1TVEc5Erw2c5at8RjM Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 14:53:24 -0000 Hi Simon, Please see inline > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Monday, March 24, 2014 6:26 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (pras= pati); > tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Le 2014-03-24 08:27, Tirumaleswar Reddy (tireddy) a =E9crit : > > Yes, that will probably solve the problem. But how would the Mobile Nod= e > (MN) trust the TURN server provided by the network when let's say MN is u= sing > Coffee shop WIFI ? > > It could be a malicious TURN server provided to monitor the user activi= ty. If > certificate validation is not possible then it becomes opportunistic encr= yption. > Further with this restriction, the network provided TURN server may not b= e able > to offer Mobility unlike the application provided TURN server. >=20 > Do you trust the default gateway that is provided to you by DHCP when you= log > on a coffee shop wi-fi? No, you don't. But you still use it. And maybe yo= u don't > even consider this problematic. IMHO, if we dig deep enough we'll find th= at this > problem is basically unfixable. There will always be an untrustworthy > infrastructure layer on top of which trustworthy applications are built. >=20 > I think what we need to do is: >=20 > 0. Consider any network-provided TURN server as untrustworthy. This is an > axiomatic position. >=20 > 1. Devise a mechanism allowing this piece of untrustworthy infrastructure= to be > discovered. >=20 > 2. Show how trustworthy applications can be built on top of this. (i.e., = by > encrypting media streams using SRTP, DTLS, etc.) >=20 > The untrustworthy TURN server will be able to know the 5-tuples between t= he > client and the peer.=20 TURN is useful to provide privacy just like TOR. Using TOR ensures that eve= n if the traffic is subjected to pervasive monitoring, attacker cannot find= out the remote server with which the user is communicating. TURN can also = be used to solve the same problem. If attacker can act as TURN server then = this benefit of providing privacy will be lost. -Tiru > An untrustworthy IP router would equally be able to do it. > But with appropriate encryption, it won't be able to discover anything mo= re. So > this would not introduce any new attack vector IMHO. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 24 07:59:51 2014 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 4B4A01A0204 for ; Mon, 24 Mar 2014 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xqwSDxOzRlI4 for ; Mon, 24 Mar 2014 07:59:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 675371A0221 for ; Mon, 24 Mar 2014 07:59:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140324145946.18224.69567.idtracker@ietfa.amsl.com> Date: Mon, 24 Mar 2014 07:59:46 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/UME6wA5GoGP6Q7WiQOuHRAfatxQ Subject: [tram] Milestones changed for tram WG 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, 24 Mar 2014 14:59:48 -0000 Changed milestone "Send analysis of problems with current TURN authentication to IESG for publication as Informational", added draft-ietf-tram-auth-problems to milestone. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Mon Mar 24 08:31:54 2014 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 AA3691A0232; Mon, 24 Mar 2014 08:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PSYNrwJGyjVK; Mon, 24 Mar 2014 08:31:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1581A01AB; Mon, 24 Mar 2014 08:31:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140324153144.22586.15517.idtracker@ietfa.amsl.com> Date: Mon, 24 Mar 2014 08:31:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KGealpBGNOYpQ7PYFfCLBsmLf9w Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-00.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, 24 Mar 2014 15:31:45 -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 : Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-dtls-00.txt Pages : 14 Date : 2014-03-24 Abstract: This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-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/ From nobody Mon Mar 24 08:33:03 2014 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 3C5C81A0188 for ; Mon, 24 Mar 2014 08:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qiDg4c_dj5Qq for ; Mon, 24 Mar 2014 08:32:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09C1A01B9 for ; Mon, 24 Mar 2014 08:32:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140324153259.23883.53339.idtracker@ietfa.amsl.com> Date: Mon, 24 Mar 2014 08:32:59 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AArS-iV74QuPe2S-FptLujpliaY Subject: [tram] Milestones changed for tram WG 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, 24 Mar 2014 15:33:01 -0000 Changed milestone "Send draft adding DTLS as a transport for STUN/TURN to IESG for publication as Proposed Standard", added draft-ietf-tram-stun-dtls to milestone. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Mon Mar 24 09:29:43 2014 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 86A571A0236 for ; Mon, 24 Mar 2014 09:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 HOaC_7w8RB3K for ; Mon, 24 Mar 2014 09:29:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 33CE51A01CD for ; Mon, 24 Mar 2014 09:29:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F375D285B4; Mon, 24 Mar 2014 16:29:35 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id D7D402856A; Mon, 24 Mar 2014 16:29:35 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id BC35880045; Mon, 24 Mar 2014 16:29:35 +0000 (GMT) Message-ID: <53305D6F.7050000@akamai.com> Date: Mon, 24 Mar 2014 12:29:35 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> <532C4960.9030005@akamai.com> <532C4D24.5060007@akamai.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SKynUjYvujNdeJMR5O-caulQKKg Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 16:29:39 -0000 On 03/22/2014 05:03 AM, Prashanth Patil (praspati) wrote: > > > On 3/21/14 8:01 PM, "Brandon Williams" wrote: > >> On a separate note, also related to (D)TLS ... >> >> It's not completely clear to me how the anycast approach to server >> discovery would work together with secure data flows. What are the >> server-side cert requirements in order to make an anycast solution work? >> I'm not suggesting that it won't work -- just that people (like me) who >> do have much expertize with cert management may need to have it spelled >> out in order to evaluate whether the requirements seem reasonable. > > The response to an anycast request will be a 300 (try alternate) response. > The response will contain the unicast address in the ALTERNATE_SERVER > attribute. This has been discussed (in another context), and will be > included in the next revision. > Once you have a definitive address, certificate management (or issues with > it) has to be dealt with the same way it's done for addresses learnt any > other way. I see a typo in my previous message ... "people who _do_ have much expertize with cert management" should have been "people who _don't_ have much expertize with cert management". I think that was obvious from the context, but it still seemed worth pointing out, since when I suggested that it may need to be spelled out, I really meant that. You've described the response to the anycast request, but that assumes that a DTLS session has already been negotiated. I'm interested in the cert requirements for getting that DTLS session set up in the first place. Are they self-signed certificates? How can the client know that it has connected to a trusted TURN server? Is there an assumption that DTLS in this context will really only be useful for protecting against passive eavesdropping and man-in-the-middle attacks after session establishment, not potentially malicious TURN servers? Will the TURN client be required to accept certs in this context that it would not accept in other contexts? --Brandon > > -Prashanth > > >> >> --Brandon >> >> On 03/21/2014 10:14 AM, Brandon Williams wrote: >>> I think that some type of authentication is necessary, even if all it >>> provides is the ability to verify that the two ends of the tunnel remain >>> consistent throughout the life of the allocation. Without at least that, >>> then the service is open to DOS attacks via message injection. The >>> network geographic location of the attacker could be limited, but such >>> attacks could not be prevented entirely. >>> >>> Of course, TLS or DTLS could be used for this purpose, but is it >>> reasonable to require that overhead just for the purpose of >>> authenticating the TURN control traffic? >>> >>> --Brandon >>> >>> On 03/21/2014 08:58 AM, Simon Perreault wrote: >>>> Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a écrit : >>>>> Yes. It brings few other challenges like if TURN server is provided >>>>> by ISP then how will authentication and authorization work ? >>>>> I mean for users logging into a coffee shop, Hotels etc. >>>>> >>>>> How will these endpoints know the credentials to use with the TURN >>>>> servers provided by ISP ? >>>> >>>> If the TURN server is provided by the network, couldn't we assume that >>>> authentication is network-based? That is, if you succeed in talking to >>>> the server, then that means you're good. TURN servers would effectively >>>> have "no authentication" in the protocol. >>>> >>>> Simon >>>> >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer >> Emerging Products Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Mar 24 09:40:40 2014 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 6E8FA1A0255 for ; Mon, 24 Mar 2014 09:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 p0AJY9HB08M2 for ; Mon, 24 Mar 2014 09:40:35 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A5CA91A0236 for ; Mon, 24 Mar 2014 09:40:35 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 82DFA47474; Mon, 24 Mar 2014 16:40:34 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1C85947473; Mon, 24 Mar 2014 16:40:34 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 88D74FE06B; Mon, 24 Mar 2014 16:40:33 +0000 (GMT) Message-ID: <53306001.3090204@akamai.com> Date: Mon, 24 Mar 2014 12:40:33 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A242DB0B8@xmb-rcd-x10.cisco.com> <53302B7A.1070701@viagenie.ca> <913383AAA69FF945B8F946018B75898A242DB1D0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242DB1D0@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/T63VBZgrcy4YHVRxQCqJ67SU-bE Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 16:40:38 -0000 Hi Tiru, I'm not sure that it would be reasonable to expect the degree of privacy that you are describing from an auto-discovered TURN server. Even with certs to authenticate the TURN server, you are still trusting the random coffee shop's network provider. I think that Simon's axiom is entirely correct in this context ... don't trust the network provided server, and thus don't rely on it for privacy. As long as the TURN client allows the user to select an appropriate security policy, I think it's OK. --Brandon On 03/24/2014 10:53 AM, Tirumaleswar Reddy (tireddy) wrote: > Hi Simon, > > Please see inline > >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Monday, March 24, 2014 6:26 PM >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (praspati); >> tram@ietf.org >> Subject: Re: [tram] TURN server discovery (please discuss!) >> >> Le 2014-03-24 08:27, Tirumaleswar Reddy (tireddy) a écrit : >>> Yes, that will probably solve the problem. But how would the Mobile Node >> (MN) trust the TURN server provided by the network when let's say MN is using >> Coffee shop WIFI ? >>> It could be a malicious TURN server provided to monitor the user activity. If >> certificate validation is not possible then it becomes opportunistic encryption. >> Further with this restriction, the network provided TURN server may not be able >> to offer Mobility unlike the application provided TURN server. >> >> Do you trust the default gateway that is provided to you by DHCP when you log >> on a coffee shop wi-fi? No, you don't. But you still use it. And maybe you don't >> even consider this problematic. IMHO, if we dig deep enough we'll find that this >> problem is basically unfixable. There will always be an untrustworthy >> infrastructure layer on top of which trustworthy applications are built. >> >> I think what we need to do is: >> >> 0. Consider any network-provided TURN server as untrustworthy. This is an >> axiomatic position. >> >> 1. Devise a mechanism allowing this piece of untrustworthy infrastructure to be >> discovered. >> >> 2. Show how trustworthy applications can be built on top of this. (i.e., by >> encrypting media streams using SRTP, DTLS, etc.) >> >> The untrustworthy TURN server will be able to know the 5-tuples between the >> client and the peer. > > TURN is useful to provide privacy just like TOR. Using TOR ensures that even if the traffic is subjected to pervasive monitoring, attacker cannot find out the remote server with which the user is communicating. TURN can also be used to solve the same problem. If attacker can act as TURN server then this benefit of providing privacy will be lost. > > -Tiru > >> An untrustworthy IP router would equally be able to do it. >> But with appropriate encryption, it won't be able to discover anything more. So >> this would not introduce any new attack vector IMHO. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Mar 24 09:59:04 2014 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 672D21A0227 for ; Mon, 24 Mar 2014 09:59:03 -0700 (PDT) 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 qxt8ijGlWMIy for ; Mon, 24 Mar 2014 09:59:01 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 685EA1A0297 for ; Mon, 24 Mar 2014 09:59:01 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so3654190wgh.29 for ; Mon, 24 Mar 2014 09:59:00 -0700 (PDT) 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=Mf+dD15xuxwB4qo9SY+Hk5R8JirdmmRYgInOxP2tru0=; b=hMgegx72Y3BSipMxER/bFh84sRPcteG29MzP/3iXIqCmbtdcy5DZ2/j/8PswoelQl8 bPz8ptvd716/uz9EJifUaHStBmE5fgWCoDfSr5TDllb6TdyKIXmmOhDd3RQhyWnLjnSa dz72bLd1j7v06dou/tJvD2J35nnIgE+OxX8nMNHtlvI4d2GImV0iSqoCDY/rlC+7His0 kgLAPn7O9RwixDW272xxK3TTAqbUnsknuhDnmDbzdQvfl0GQI1MBBPZUWKSHQRf6fp90 SBg0KZTyAFB7WmUgt9j1VcT5qqwLCCz37mFH1LAVd+eBepTutzzeVg+5N15/yShdYtL3 OE3A== MIME-Version: 1.0 X-Received: by 10.180.106.134 with SMTP id gu6mr16949682wib.61.1395680337914; Mon, 24 Mar 2014 09:58:57 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 24 Mar 2014 09:58:57 -0700 (PDT) In-Reply-To: <532AF25B.4020301@viagenie.ca> References: <532AF25B.4020301@viagenie.ca> Date: Mon, 24 Mar 2014 09:58:57 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BgPRwwE0s4ejCxLwdsetJHePYG8 Cc: "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 16:59:03 -0000 Re: WPAD: This is causing HTTPBIS considerable pain. If you feel particularly masochistic, or desperate, then perhaps it can be remembered, but any attempt to use WPAD will be sorely regretted. On 20 March 2014 06:51, Simon Perreault wrote: > Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for > inspiration. As I understand it, that solution relies on the client's IP > address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse > zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records > pointing to the network-provided TURN server. Can this work? This is a > new idea for which I have not seen any discussion yet. ALTO have been covering a lot of the same ground as GEOPRIV. draft-ietf-geopriv-res-gw-lis-discovery sits in the RFC editor's queue. It's the same mechanism. That said, this is only useful to the extent that the owner of the network you are using is also the one providing the TURN service. Is this the operating assumption here? Or are there other avenues that need to be explored? From nobody Mon Mar 24 10:07:07 2014 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 BD23C1A02A4 for ; Mon, 24 Mar 2014 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZgNg8kgLO-yX for ; Mon, 24 Mar 2014 10:07:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A8E281A02A1 for ; Mon, 24 Mar 2014 10:07:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9EF694037C; Mon, 24 Mar 2014 13:07:01 -0400 (EDT) Message-ID: <53306635.40103@viagenie.ca> Date: Mon, 24 Mar 2014 13:07:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <532AF25B.4020301@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/rGQNEnJS2foK0fGnWi-48Hfyygw Cc: "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 17:07:05 -0000 Le 2014-03-24 12:58, Martin Thomson a écrit : > Re: WPAD: This is causing HTTPBIS considerable pain. If you feel > particularly masochistic, or desperate, then perhaps it can be > remembered, but any attempt to use WPAD will be sorely regretted. Duly noted. > On 20 March 2014 06:51, Simon Perreault wrote: >> Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for >> inspiration. As I understand it, that solution relies on the client's IP >> address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse >> zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records >> pointing to the network-provided TURN server. Can this work? This is a >> new idea for which I have not seen any discussion yet. > > ALTO have been covering a lot of the same ground as GEOPRIV. > draft-ietf-geopriv-res-gw-lis-discovery sits in the RFC editor's > queue. It's the same mechanism. Thanks for the pointer! > That said, this is only useful to the extent that the owner of the > network you are using is also the one providing the TURN service. Couldn't the NAPTR record point to a third-party TURN server? > Is this the operating assumption here? Or are there other avenues that > need to be explored? Maybe, but I can't think of any. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 24 10:12:34 2014 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 643B41A0254 for ; Mon, 24 Mar 2014 10:12:32 -0700 (PDT) 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 HeDTUTvEGpjV for ; Mon, 24 Mar 2014 10:12:31 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B40871A0251 for ; Mon, 24 Mar 2014 10:12:30 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so3574399wgg.25 for ; Mon, 24 Mar 2014 10:12:29 -0700 (PDT) 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=YNNdB6mSLsVhFTdMQLWVx0OJopPlfG8vFJwsjx7GWvc=; b=Ayh9wbDvxh8u01g4lbh6++A7HC2fLe3rgUY6QZCKF2V9Px8SGFf5iRMZ4nbvjwNX0a qBoMHfoFGdXBYvu0Vwyl9asChCwpTj0Yc0Am22gu8XFYeZJ7dTM5LlrtAld43kjyNMm4 2wAyz9bTpTBywiFtXS3qtE7+yUbkou5oC9xzZpXA+tE4bQzLCGTEzdU0Ra/Qvf/rEFRj FAI6ywJ6OsA/Ci9DZZSPHSto3bV4PXMdKDnaKFf/n8uP+J6CebyRMwt1YGF1TFo1TOvc jPcMuUFlEsL8oqY9WDg7e2WkBDaNeRgqM4gfpw0X4y/mOfwNbf3iWZZhjeNbUj13nu7e 8yAA== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr16207296wiw.56.1395681149408; Mon, 24 Mar 2014 10:12:29 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 24 Mar 2014 10:12:29 -0700 (PDT) In-Reply-To: <53306635.40103@viagenie.ca> References: <532AF25B.4020301@viagenie.ca> <53306635.40103@viagenie.ca> Date: Mon, 24 Mar 2014 10:12:29 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Wdq8tEwrMLaVKuMa9KjoQpmKO10 Cc: "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 17:12:32 -0000 On 24 March 2014 10:07, Simon Perreault wrote: >> That said, this is only useful to the extent that the owner of the >> network you are using is also the one providing the TURN service. > > Couldn't the NAPTR record point to a third-party TURN server? That's definitely the case, though the network operator still assumes a critical responsibility for the service (namely: discovery). From nobody Mon Mar 24 10:39:20 2014 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 23B2A1A0268 for ; Mon, 24 Mar 2014 10:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCOKauDMxroc for ; Mon, 24 Mar 2014 10:39:13 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 49DF11A0254 for ; Mon, 24 Mar 2014 10:39:13 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so5739305pab.41 for ; Mon, 24 Mar 2014 10:39:12 -0700 (PDT) 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=rypkO3qqlUnvUVdX6rCtMNvEhXhm3oI/0rEYR6gMXMQ=; b=i/i6Wt/DnUbZR5pyRz6LmY0aLgpYIDKgmlWa4EZUGfgRaKTIIw5x77Dlw79KKjIa9e K+wHtCtXUGjGYJ/HXT/UEsxzvxKFONEDf+6rXG+w0fj+Yy+nh5NUJBSsd/43sjeut/2O Q5sY5GZf/vX3aAl8MJxZj2fgUVpSCcYjKO848C0xjyoY8KaVBtMkuV6G5Xg7Q+Yswytx gnbPMoaiEfVUONEAVRLt9SxwFBnckcuRSktQ5KXIN8k3NTqsUc3hNNAByJ7QmQgyr/93 mk/DKqwp+LBgDkYonrUttaMmV6LT5tVN0ujVG/gdSY6tWv6y3IeglPkLRpVws1FPQTVr Lb+A== MIME-Version: 1.0 X-Received: by 10.68.178.1 with SMTP id cu1mr72195388pbc.34.1395682752618; Mon, 24 Mar 2014 10:39:12 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Mon, 24 Mar 2014 10:39:12 -0700 (PDT) In-Reply-To: <53302D43.10205@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> <532CACA5.6080204@viagenie.ca> <53302D43.10205@viagenie.ca> Date: Mon, 24 Mar 2014 10:39:12 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b86f76ab0677d04f55db6b2 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YLMGcAcpxDZbJ76YTjWnBh_Ruks Cc: "Prashanth Patil \(praspati\)" , Brandon Williams , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 17:39:15 -0000 --047d7b86f76ab0677d04f55db6b2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2014 at 6:04 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-21 17:54, Oleg Moskalenko a =E9crit : > > No, that's not right. I propose NO CHANGES to the client. That behavior > > does not introduce anything new. That is using the existing auth > > mechanism. I just proposed a convention that for the network-secured > > TURN servers, we use passwords equal to the usernames. That's it. Then > > the clients will be 100% backward-compatible, we will have cookie-like > > dialog session protection and the real authentication burden will be on > > the network infrastructure: if client can connect to the server, then > > the client is allowed to use the server. We will have the best of two > > approaches. > > I'm sorry, I still don't get it fully. > > I understand the value of cookies in network protocols in general. But > what I don't understand is: > > - What threat would this proposal be protecting against in STUN > specifically? Can you give an example of an attack that this proposal > would prevent? > I was talking about TURN ALLOCATE - not STUN BINDING - requests. If you take a look at the ALLOCATE dialog, you will see that a simple traffic-generator client just in a few seconds can exhaust the whole TURN server capacity - if no authentication is used. Many thousands allocations can be created in a few seconds if the client sends the same request from different local ports - and the client even does not have to listen to the replies. Or even a simple software error can cause the same effect. You come with a laptop to a coffee shop and after a few seconds you shutdown the coffee shop's network TURN server. Nice. With a sort of authentication (even a bogus one) that task will be much more difficult for a malicious client - it will buy some time for the network equipment to determine wrong situation, at least. If TLS or DTLS is used as the protocol, that "bogus authentication" would be not necessary, the TLS/DTLS handshake would serve the same purpose. Another reason for a "bogus authentication" is to provide some voluntary information to the server for logging. > > - Why is it important that we do not change clients? > backward compatibility is a good thing > > - Why do you not consider the new client behaviour "generate a username, > use it as the password as well" a change to client implementation? > that's a minor application-level change. Still a change, I admit. Oleg --047d7b86f76ab0677d04f55db6b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 24, 2014 at 6:04 AM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-21 17:54, Oleg Moskalenko a =E9cr= it :
> No, that's not right. I propose NO CHANGES to the = client. That behavior
> does not introduce anything new. That is using the existing auth
> mechanism. I just proposed a convention that for the network-secured > TURN servers, we use passwords equal to the usernames. That's it. = Then
> the clients will be 100% backward-compatible, we will have cookie-like=
> dialog session protection and the real authentication burden will be o= n
> the network infrastructure: if =A0client can connect to the server, th= en
> the client is allowed to use the server. We will have the best of two<= br> > approaches.

I'm sorry, I still don't get it fully.

I understand the value of cookies in network protocols in general. But
what I don't understand is:

- What threat would this proposal be protecting against in STUN
specifically? Can you give an example of an attack that this proposal
would prevent?

I was talking about TURN= ALLOCATE - not STUN BINDING - requests. If you take a look at the ALLOCATE= dialog, you will see that a simple traffic-generator client just in a few = seconds can exhaust the whole TURN server capacity - if no authentication i= s used. Many thousands allocations can be created in a few seconds if the c= lient sends the same request from different local ports - and the client ev= en does not have to listen to the replies. Or even a simple software error = can cause the same effect. You come with a laptop to a coffee shop and afte= r a few seconds you shutdown the coffee shop's network TURN server. Nic= e. With a sort of authentication (even a bogus one) that task will be much = more difficult for a malicious client - it will buy some time for the netwo= rk equipment to determine wrong situation, at least.

If TLS or DTLS is used as the protocol, that "bogus aut= hentication" would be not necessary, the TLS/DTLS handshake would serv= e the same purpose.

Another reason for a "= ;bogus authentication" is to provide some voluntary information to the= server for logging.=A0
=A0

- Why is it important that we do not change clients?
<= br>
backward compatibility is a good thing
=A0

- Why do you not consider the new client behaviour "generate a usernam= e,
use it as the password as well" a change to client implementation?
=

that's a minor application-level chang= e. Still a change, I admit.
=A0
Oleg



--047d7b86f76ab0677d04f55db6b2-- From nobody Mon Mar 24 11:19:07 2014 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 E84401A0272 for ; Mon, 24 Mar 2014 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ssBSWqNreYEf for ; Mon, 24 Mar 2014 11:19:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 400011A026A for ; Mon, 24 Mar 2014 11:19:01 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3F6A74037C for ; Mon, 24 Mar 2014 14:19:00 -0400 (EDT) Message-ID: <53307713.4000100@viagenie.ca> Date: Mon, 24 Mar 2014 14:18:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HdtbJASxCA10tpL_qRaF88D6yg0 Subject: [tram] STUN hash agility 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, 24 Mar 2014 18:19:05 -0000 I don't see this problem listed in draft-ietf-tram-auth-problems. Does it need to be? Here's a naive attempt at a summary. Please feel free to suggest improvements. 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no mechanism for hash agility in the protocol itself, although Section 16.3 of [RFC5389] does discuss a plan for migrating to a more secure algorithm in case HMAC-SHA1 is found to be compromised. In addition, STUN passwords are stored server-side using unsalted MD5 hashes, which is not considered best current practice. [RFC6151] Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 24 12:26:16 2014 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 1E7371A02B2; Mon, 24 Mar 2014 12:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wlLXFzOZGU96; Mon, 24 Mar 2014 12:26:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1327A1A02AF; Mon, 24 Mar 2014 12:26:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> Date: Mon, 24 Mar 2014 12:26:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WZcJhHc3iMAnb-jTZFZ8mlxZCh4 Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-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: Mon, 24 Mar 2014 19:26: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 : Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-dtls-01.txt Pages : 14 Date : 2014-03-24 Abstract: This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-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 Mon Mar 24 12:37:54 2014 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 278761A0299 for ; Mon, 24 Mar 2014 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 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, MANGLED_TOOL=2.3, 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 plS3jqmMKe4r for ; Mon, 24 Mar 2014 12:37:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B80751A027C for ; Mon, 24 Mar 2014 12:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7127; q=dns/txt; s=iport; t=1395689869; x=1396899469; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=n9Zr/im5h7rc/A6gWyzEkJIoCs+5zG5D2HecavoHUe4=; b=FlNCO6A0ebJUoTS2IL5ZyNbLFrBMePkcKMl2/+QJCK5y/a/hRmfWMTLl lWlPn6wqJKnCJ3DaWLJbDSPWzvZV/z4+M4388ZDr7+pM8aGxmqj7s+mMK hr3TJUAauCXLnXcMCr8aVrq/cEHTL68fceAZrKAJEpdrcdWIuZna7DGzD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAIADCJMFOtJV2Y/2dsb2JhbABZgwY7UQaEJbcVhzWBIBZ0giYBAQQBAQFrGwIBCD8HJwsUEQIEEwmHcAgFzz0XjiZQC4MkgRQEmEqBMpB/gy2CKw X-IronPort-AV: E=Sophos;i="4.97,722,1389744000"; d="scan'208,217";a="312327669" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 24 Mar 2014 19:37:48 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2OJbm0r011162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 19:37:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.92]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 14:37:47 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-stun-dtls-01.txt Thread-Index: AQHPR5iJMi16c/79VEiBasUjE4a08g== Date: Mon, 24 Mar 2014 19:37:47 +0000 Message-ID: References: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> In-Reply-To: <20140324192612.22618.40854.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.163] Content-Type: multipart/alternative; boundary="_000_ACBD13C5D34E4911BB1FA673673DC718ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/i_f4f65CsiNy9z1xQPEHe5ytnrM Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-dtls-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: Mon, 24 Mar 2014 19:37:52 -0000 --_000_ACBD13C5D34E4911BB1FA673673DC718ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi - We have posted two new versions of the draft today. The -00 was the WG adop= ted with text unchanged from draft-petithuguenin-tram-stun-dtls-00. This -01 version addresses the open issues we came to consensus on during t= he meeting in London. Changes fr= om -00 to -01 are: - Updated the mandatory cipher suites. - Added a new open item to determine if we want to specify favoring cipher = suites which support PFS over non-PFS cipher suites. - Closed remaining opening items from previous draft. We will be sending some emails shortly to discuss a few open issues we'd li= ke to tackle before an -02. Thanks, Gonzalo On Mar 24, 2014, at 3:26 PM, 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 : Datagram Transport Layer Security (DTLS) as Transp= ort for Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-dtls-01.txt Pages : 14 Date : 2014-03-24 Abstract: This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stun-dtls-01 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_ACBD13C5D34E4911BB1FA673673DC718ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <326FB7033923EC40BC6FF59982449BD3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi - 

We have posted two new versions of the draft today. The -00 was the WG= adopted with text unchanged from draft-petithuguenin-tram-stun-dtls-00.

This -01 version addresses the open issues we came to consensus on dur= ing the meeting in London.

Changes from -00 to -01 are:

- Updated the mandatory cipher suites.
- Added a new open item to determine if we want to specify favoring&nb= sp;cipher suites which support PFS over non-PFS cipher suites.
- Closed remaining opening items from previous draft.

We will be sending some emails shortly to discuss a few open issues we= 'd like to tackle before an -02.

Thanks,

Gonzalo

On Mar 24, 2014, at 3:26 PM, in= ternet-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           : Datag= ram Transport Layer Security (DTLS) as Transport for Session Traversal Util= ities for NAT (STUN)
       Authors         : Marc Petit= -Huguenin
                     = ;    Gonzalo Salgueiro
Filename &n= bsp;      : draft-ietf-tram-stun-dtls-01.txt
Pages  = ;         : 14
Date  =          : 2014-03-24

Abstract:
  This document specifies the usage of Datagram Transport Layer
  Security (DTLS) as a transport protocol for Session Traversal
  Utilities for NAT (STUN).  It provides guidances on when and ho= w to
  use DTLS with the currently standardized STUN Usages.  It also<= br>   specifies modifications to the STUN URIs and TURN URIs and to the   TURN resolution mechanism to facilitate the resolution of STUN URIs<= br>   and TURN URIs into the IP address and port of STUN and TURN servers<= br>   supporting DTLS as a transport protocol.


The IETF datatracker status page for this draft is:
htt= ps://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stun-dtls-01


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_ACBD13C5D34E4911BB1FA673673DC718ciscocom_-- From nobody Mon Mar 24 12:53:13 2014 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 BCB2E1A02BF for ; Mon, 24 Mar 2014 12:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 2AhgRpCamGGM for ; Mon, 24 Mar 2014 12:53:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7068D1A02E0 for ; Mon, 24 Mar 2014 12:53:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 53E4C28689; Mon, 24 Mar 2014 19:53:10 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 35B8128680; Mon, 24 Mar 2014 19:53:10 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 01A02FE054; Mon, 24 Mar 2014 19:53:09 +0000 (GMT) Message-ID: <53308D25.9070403@akamai.com> Date: Mon, 24 Mar 2014 15:53:09 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko , Simon Perreault References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> <532CACA5.6080204@viagenie.ca> <53302D43.10205@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BmBlDU6F3CUlUzQ0-mgAZS2NGPY Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 19:53:12 -0000 Hi Oleg, I'm not seeing how the mechanism you propose would help in the attack scenario you describe. Why would a traffic generator client looking to exhaust the TURN server capacity not just send bogus usernames in the attack packets? --Brandon On 03/24/2014 01:39 PM, Oleg Moskalenko wrote: > > > > On Mon, Mar 24, 2014 at 6:04 AM, Simon Perreault > > wrote: > > Le 2014-03-21 17:54, Oleg Moskalenko a écrit : > > No, that's not right. I propose NO CHANGES to the client. That > behavior > > does not introduce anything new. That is using the existing auth > > mechanism. I just proposed a convention that for the network-secured > > TURN servers, we use passwords equal to the usernames. That's it. > Then > > the clients will be 100% backward-compatible, we will have > cookie-like > > dialog session protection and the real authentication burden will > be on > > the network infrastructure: if client can connect to the server, > then > > the client is allowed to use the server. We will have the best of two > > approaches. > > I'm sorry, I still don't get it fully. > > I understand the value of cookies in network protocols in general. But > what I don't understand is: > > - What threat would this proposal be protecting against in STUN > specifically? Can you give an example of an attack that this proposal > would prevent? > > > I was talking about TURN ALLOCATE - not STUN BINDING - requests. If you > take a look at the ALLOCATE dialog, you will see that a simple > traffic-generator client just in a few seconds can exhaust the whole > TURN server capacity - if no authentication is used. Many thousands > allocations can be created in a few seconds if the client sends the same > request from different local ports - and the client even does not have > to listen to the replies. Or even a simple software error can cause the > same effect. You come with a laptop to a coffee shop and after a few > seconds you shutdown the coffee shop's network TURN server. Nice. With a > sort of authentication (even a bogus one) that task will be much more > difficult for a malicious client - it will buy some time for the network > equipment to determine wrong situation, at least. > > If TLS or DTLS is used as the protocol, that "bogus authentication" > would be not necessary, the TLS/DTLS handshake would serve the same purpose. > > Another reason for a "bogus authentication" is to provide some voluntary > information to the server for logging. > > > - Why is it important that we do not change clients? > > > backward compatibility is a good thing > > > - Why do you not consider the new client behaviour "generate a username, > use it as the password as well" a change to client implementation? > > > that's a minor application-level change. Still a change, I admit. > > Oleg > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Mar 24 12:59:01 2014 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 F37FA1A02DC for ; Mon, 24 Mar 2014 12:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 e7MeuStHQ5Ik for ; Mon, 24 Mar 2014 12:58:59 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE81A02D4 for ; Mon, 24 Mar 2014 12:58:58 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E35F84753E for ; Mon, 24 Mar 2014 19:58:57 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D73574753B for ; Mon, 24 Mar 2014 19:58:57 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B83642029 for ; Mon, 24 Mar 2014 19:58:57 +0000 (GMT) Message-ID: <53308E81.6000309@akamai.com> Date: Mon, 24 Mar 2014 15:58:57 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <53307713.4000100@viagenie.ca> In-Reply-To: <53307713.4000100@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2RZakHQyXYa19ln4i3nfrdU7B_U Subject: Re: [tram] STUN hash agility 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, 24 Mar 2014 19:59:00 -0000 These two problems might want separate bullets, but they are definitely both important issues with the authentication mechanism in the RFC. --Brandon On 03/24/2014 02:18 PM, Simon Perreault wrote: > I don't see this problem listed in draft-ietf-tram-auth-problems. Does > it need to be? > > Here's a naive attempt at a summary. Please feel free to suggest > improvements. > > 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no > mechanism for hash agility in the protocol itself, although Section 16.3 > of [RFC5389] does discuss a plan for migrating to a more secure > algorithm in case HMAC-SHA1 is found to be compromised. In addition, > STUN passwords are stored server-side using unsalted MD5 hashes, which > is not considered best current practice. [RFC6151] > > Simon > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Mar 24 13:14:07 2014 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 B7F001A02D2 for ; Mon, 24 Mar 2014 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY5rolfveDlY for ; Mon, 24 Mar 2014 13:13:59 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A46C01A02BF for ; Mon, 24 Mar 2014 13:13:59 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so5902232pbc.6 for ; Mon, 24 Mar 2014 13:13:59 -0700 (PDT) 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=Ohbz4TudA71tTS5HAk+iGJgVgFbOgKleTsCG4nhYebs=; b=nFdzkCxQ4odY+h9uFbut6d943CnAJPMsyY+aEIxpqtl+f8QJ5g8zui8ZxsG9qTNRpB cHqZ2R74mY7wQ2MjAw2F81QZCy2r8O/iORysNb9TST2Cj9Rku0Hdz1qrPWwmWOkT6L5R XNnyzRLHLrHZCsPUzxZLfdKd0QRlG0NP4T8B6c3f09LJM0v0QZJGou332kVbZmVbKl9y KI0+DtK8CCVOJPzyYXHvueC7PNmFa0+IpQ22bO2J1g65uBX7J1z/D9nbl1Emf/Xe2Y5W VHlvavaE+mbFWHIo7nI8Y190b0DKt8Az+EamkKEH9Vdm3qaevbsNYZ5diQmdXx+cuJub cJxw== MIME-Version: 1.0 X-Received: by 10.68.237.133 with SMTP id vc5mr73231594pbc.92.1395692038910; Mon, 24 Mar 2014 13:13:58 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Mon, 24 Mar 2014 13:13:58 -0700 (PDT) In-Reply-To: <53308D25.9070403@akamai.com> References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> <532C9FF3.10305@akamai.com> <532CA83D.70005@viagenie.ca> <532CACA5.6080204@viagenie.ca> <53302D43.10205@viagenie.ca> <53308D25.9070403@akamai.com> Date: Mon, 24 Mar 2014 13:13:58 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b338f1d31f6e204f55fe079 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/p2y-WrEVbIaXRBa6WhjXVFC3uvk Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] TURN server discovery (please discuss!) 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, 24 Mar 2014 20:14:02 -0000 --047d7b338f1d31f6e204f55fe079 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is somewhat similar to, say, the cookie mechanism in DTLS. In the "bogs authentication" scheme, the client must be statefull - it must examine every response packet and it must invoke real digest calculation algorithms to construct the authenticated ALLOCATE request (after the challenge response). So it is like 100 or 1000 times more calculation-heavy than sending thousands similar initial ALLOCATION requests with a "traffic generator" tool. This is a cheap simple first-line defense against a naive DoS attack. A TURN server may invoke another defense mechanism - an allocation rate control limitation. But still the effect of a DoS attack would be similar - the "real" clients will not be able to connect to the TURN server if a malicious "traffic generator" client is active. On Mon, Mar 24, 2014 at 12:53 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > Hi Oleg, > > I'm not seeing how the mechanism you propose would help in the attack > scenario you describe. Why would a traffic generator client looking to > exhaust the TURN server capacity not just send bogus usernames in the > attack packets? > > --Brandon > > > On 03/24/2014 01:39 PM, Oleg Moskalenko wrote: > >> >> >> >> On Mon, Mar 24, 2014 at 6:04 AM, Simon Perreault >> > wrote= : >> >> Le 2014-03-21 17:54, Oleg Moskalenko a =E9crit : >> > No, that's not right. I propose NO CHANGES to the client. That >> behavior >> > does not introduce anything new. That is using the existing auth >> > mechanism. I just proposed a convention that for the >> network-secured >> > TURN servers, we use passwords equal to the usernames. That's it. >> Then >> > the clients will be 100% backward-compatible, we will have >> cookie-like >> > dialog session protection and the real authentication burden will >> be on >> > the network infrastructure: if client can connect to the server, >> then >> > the client is allowed to use the server. We will have the best of >> two >> > approaches. >> >> I'm sorry, I still don't get it fully. >> >> I understand the value of cookies in network protocols in general. B= ut >> what I don't understand is: >> >> - What threat would this proposal be protecting against in STUN >> specifically? Can you give an example of an attack that this proposa= l >> would prevent? >> >> >> I was talking about TURN ALLOCATE - not STUN BINDING - requests. If you >> take a look at the ALLOCATE dialog, you will see that a simple >> traffic-generator client just in a few seconds can exhaust the whole >> TURN server capacity - if no authentication is used. Many thousands >> allocations can be created in a few seconds if the client sends the same >> request from different local ports - and the client even does not have >> to listen to the replies. Or even a simple software error can cause the >> same effect. You come with a laptop to a coffee shop and after a few >> seconds you shutdown the coffee shop's network TURN server. Nice. With a >> sort of authentication (even a bogus one) that task will be much more >> difficult for a malicious client - it will buy some time for the network >> equipment to determine wrong situation, at least. >> >> If TLS or DTLS is used as the protocol, that "bogus authentication" >> would be not necessary, the TLS/DTLS handshake would serve the same >> purpose. >> >> Another reason for a "bogus authentication" is to provide some voluntary >> information to the server for logging. >> >> >> - Why is it important that we do not change clients? >> >> >> backward compatibility is a good thing >> >> >> - Why do you not consider the new client behaviour "generate a >> username, >> use it as the password as well" a change to client implementation? >> >> >> that's a minor application-level change. Still a change, I admit. >> >> Oleg >> >> >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > --047d7b338f1d31f6e204f55fe079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is somewhat similar to, say, the cookie mechanis= m in DTLS. In the "bogs authentication" scheme, the client must b= e statefull - it must examine every response packet and it must invoke real= digest calculation algorithms to construct the authenticated ALLOCATE requ= est (after the challenge response). So it is like 100 or 1000 times more ca= lculation-heavy than sending thousands similar initial ALLOCATION requests = with a "traffic generator" tool. This is a cheap simple first-lin= e defense against a naive DoS attack.

A TURN server may invoke another defense mechanism - an allocatio= n rate control limitation. But still the effect of a DoS attack would be si= milar - the "real" clients will not be able to connect to the TUR= N server if a malicious=A0 "traffic generator" client
is active.




On Mon, Mar 24, 2014 at 12:53 PM, Brandon Williams <brandon.williams@akamai.com> wrote:
Hi Oleg,

I'm not seeing how the mechanism you propose would help in the attack s= cenario you describe. Why would a traffic generator client looking to exhau= st the TURN server capacity not just send bogus usernames in the attack pac= kets?

--Brandon


On 03/24/2014 01:39 PM, Oleg Moskalenko wrote:



On Mon, Mar 24, 2014 at 6:04 AM, Simon Perreault
<simon.= perreault@viagenie.ca <mailto:simon.perreault@viagenie.ca>> w= rote:

=A0 =A0 Le 2014-03-21 17:54, Oleg Moskalenko a =E9crit :
=A0 =A0 =A0> No, that's not right. I propose NO CHANGES to the clien= t. That
=A0 =A0 behavior
=A0 =A0 =A0> does not introduce anything new. That is using the existing= auth
=A0 =A0 =A0> mechanism. I just proposed a convention that for the networ= k-secured
=A0 =A0 =A0> TURN servers, we use passwords equal to the usernames. That= 's it.
=A0 =A0 Then
=A0 =A0 =A0> the clients will be 100% backward-compatible, we will have<= br> =A0 =A0 cookie-like
=A0 =A0 =A0> dialog session protection and the real authentication burde= n will
=A0 =A0 be on
=A0 =A0 =A0> the network infrastructure: if =A0client can connect to the= server,
=A0 =A0 then
=A0 =A0 =A0> the client is allowed to use the server. We will have the b= est of two
=A0 =A0 =A0> approaches.

=A0 =A0 I'm sorry, I still don't get it fully.

=A0 =A0 I understand the value of cookies in network protocols in general. = But
=A0 =A0 what I don't understand is:

=A0 =A0 - What threat would this proposal be protecting against in STUN
=A0 =A0 specifically? Can you give an example of an attack that this propos= al
=A0 =A0 would prevent?


I was talking about TURN ALLOCATE - not STUN BINDING - requests. If you
take a look at the ALLOCATE dialog, you will see that a simple
traffic-generator client just in a few seconds can exhaust the whole
TURN server capacity - if no authentication is used. Many thousands
allocations can be created in a few seconds if the client sends the same request from different local ports - and the client even does not have
to listen to the replies. Or even a simple software error can cause the
same effect. You come with a laptop to a coffee shop and after a few
seconds you shutdown the coffee shop's network TURN server. Nice. With = a
sort of authentication (even a bogus one) that task will be much more
difficult for a malicious client - it will buy some time for the network equipment to determine wrong situation, at least.

If TLS or DTLS is used as the protocol, that "bogus authentication&quo= t;
would be not necessary, the TLS/DTLS handshake would serve the same purpose= .

Another reason for a "bogus authentication" is to provide some vo= luntary
information to the server for logging.


=A0 =A0 - Why is it important that we do not change clients?


backward compatibility is a good thing


=A0 =A0 - Why do you not consider the new client behaviour "generate a= username,
=A0 =A0 use it as the password as well" a change to client implementat= ion?


that's a minor application-level change. Still a change, I admit.

Oleg




--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

--047d7b338f1d31f6e204f55fe079-- From nobody Mon Mar 24 13:17:40 2014 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 2C7AE1A02AC for ; Mon, 24 Mar 2014 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GaHP6YIfAhJ for ; Mon, 24 Mar 2014 13:17:34 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCAC1A02DD for ; Mon, 24 Mar 2014 13:17:34 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p10so5747883pdj.26 for ; Mon, 24 Mar 2014 13:17:33 -0700 (PDT) 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=R6OaUjjBvw6DyJrMV6cWhwPc+tTSljLwcm464S6FxMM=; b=BxHePEaroiuaGuhO42SyFsiB42K20K6MLWI/sHRXnJ5mtJdaj9aGfyt1s5+Ep1NliH dJ+KUBcn2M4xE0qI95xl4ghvCcjRakLAYyjB2uhHY8xv8bzbN1rFUcDa0Wrl3Pp3P2D8 DWfKN0yWFxSfn0zW7KkBVVd91sKCaYQsp/XYebXLAwX5hpNIlgQIafavUpkF0S/q/oTe k73MozhlNEJYgJtENkXc5YsV2vltehLbVNUVziZ2x8Bi4pV4sV0SJWv0zjDuYw7Z3Jhy f5oXQ3jkC1gzAu5kq2uFNUgPoE79ESj7CLftGsAMs9s4QsXpVg3sTjVqzpUboK2yNjq2 VvrA== MIME-Version: 1.0 X-Received: by 10.66.144.227 with SMTP id sp3mr74571674pab.100.1395692253729; Mon, 24 Mar 2014 13:17:33 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Mon, 24 Mar 2014 13:17:33 -0700 (PDT) In-Reply-To: <53308E81.6000309@akamai.com> References: <53307713.4000100@viagenie.ca> <53308E81.6000309@akamai.com> Date: Mon, 24 Mar 2014 13:17:33 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b6d8270ffd7bb04f55fec8d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/m6yQUudzgHpVlR9AQeFTRweIKgw Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 24 Mar 2014 20:17:36 -0000 --047d7b6d8270ffd7bb04f55fec8d Content-Type: text/plain; charset=ISO-8859-1 I suppose that that summary is good enough - it describes the problem without suggesting a particular solution. On Mon, Mar 24, 2014 at 12:58 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > These two problems might want separate bullets, but they are definitely > both important issues with the authentication mechanism in the RFC. > > --Brandon > > > On 03/24/2014 02:18 PM, Simon Perreault wrote: > >> I don't see this problem listed in draft-ietf-tram-auth-problems. Does >> it need to be? >> >> Here's a naive attempt at a summary. Please feel free to suggest >> improvements. >> >> 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no >> mechanism for hash agility in the protocol itself, although Section 16.3 >> of [RFC5389] does discuss a plan for migrating to a more secure >> algorithm in case HMAC-SHA1 is found to be compromised. In addition, >> STUN passwords are stored server-side using unsalted MD5 hashes, which >> is not considered best current practice. [RFC6151] >> >> Simon >> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b6d8270ffd7bb04f55fec8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I suppose that that summary is good enough - it describes = the problem without suggesting a particular solution.


On Mon, Mar 24, 2014 at= 12:58 PM, Brandon Williams <brandon.williams@akamai.com>= wrote:
These two problems might want separate bulle= ts, but they are definitely both important issues with the authentication m= echanism in the RFC.

--Brandon


On 03/24/2014 02:18 PM, Simon Perreault wrote:
I don't see this problem listed in draft-ietf-tram-auth-problems. Does<= br> it need to be?

Here's a naive attempt at a summary. Please feel free to suggest
improvements.

7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no
mechanism for hash agility in the protocol itself, although Section 16.3 of [RFC5389] does discuss a plan for migrating to a more secure
algorithm in case HMAC-SHA1 is found to be compromised. In addition,
STUN passwords are stored server-side using unsalted MD5 hashes, which
is not considered best current practice. [RFC6151]

Simon


--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b6d8270ffd7bb04f55fec8d-- From nobody Mon Mar 24 20:37:30 2014 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 2F8741A0334 for ; Mon, 24 Mar 2014 20:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LNMRtHeK6UTq for ; Mon, 24 Mar 2014 20:37:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 774B61A0333 for ; Mon, 24 Mar 2014 20:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4469; q=dns/txt; s=iport; t=1395718644; x=1396928244; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5gl1qZZbsgEVeOResuU/3I5Dzkl5chDtGiRCdoqk92Q=; b=e+Iuw05TNHc6aR9QC2nyaYoHqLI9HRPtydOv42wT3P29lij8o4agYny4 I8nPIpbJNlZGT1rxtuWC4DIrlLdQliZjqPKt0FK6tC+7WUwktZYWUMcab jaxwsMvEgK/sN2ctffoGaoxW9DW+BsmpTNKYAUlJtD6sFYmscB6GeTTNI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAC35MFOtJXG+/2dsb2JhbABZgwY7V7sxhzWBIhZ0giUBAQEDAQEBASRHEAcGAQgRBAEBAQodLgsUCQkBBAESCIdpCA3PDBeOST6DHoEUBIkakGKQf4MtgWskHA X-IronPort-AV: E=Sophos;i="4.97,725,1389744000"; d="scan'208";a="30059934" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 25 Mar 2014 03:37:24 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2P3bOfN008312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 03:37:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 22:37:24 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9H24VO210rwg0PSICRzPX4miSmlA== Date: Tue, 25 Mar 2014 03:37:23 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242DB9B0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hL4HcuYfTPeeOQTB-W1ayE-Mrz8 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 25 Mar 2014 03:37:28 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Monday, March 24, 2014 10:11 PM > To: Tirumaleswar Reddy (tireddy); Simon Perreault; Prashanth Patil (prasp= ati); > tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Hi Tiru, >=20 > I'm not sure that it would be reasonable to expect the degree of privacy = that you > are describing from an auto-discovered TURN server. Even with certs to > authenticate the TURN server, you are still trusting the random coffee sh= op's > network provider. >=20 > I think that Simon's axiom is entirely correct in this context ... don't = trust the > network provided server, and thus don't rely on it for privacy.=20 If the same TURN server is auto-discovered in Enterprise network then mutua= l authentication will happen b/w the client and TURN server. In this case t= he client can rely on the TURN server provided by the Enterprise for privac= y but not in the coffee shop scenario. Security Considerations section in t= he draft should explain that if the user selects privacy then trusted TURN = server should be selected among the list of servers available. -Tiru > As long as the > TURN client allows the user to select an appropriate security policy, I t= hink it's > OK. >=20 > --Brandon >=20 > On 03/24/2014 10:53 AM, Tirumaleswar Reddy (tireddy) wrote: > > Hi Simon, > > > > Please see inline > > > >> -----Original Message----- > >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > >> Sent: Monday, March 24, 2014 6:26 PM > >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil > >> (praspati); tram@ietf.org > >> Subject: Re: [tram] TURN server discovery (please discuss!) > >> > >> Le 2014-03-24 08:27, Tirumaleswar Reddy (tireddy) a =E9crit : > >>> Yes, that will probably solve the problem. But how would the Mobile > >>> Node > >> (MN) trust the TURN server provided by the network when let's say MN > >> is using Coffee shop WIFI ? > >>> It could be a malicious TURN server provided to monitor the user > >>> activity. If > >> certificate validation is not possible then it becomes opportunistic > encryption. > >> Further with this restriction, the network provided TURN server may > >> not be able to offer Mobility unlike the application provided TURN ser= ver. > >> > >> Do you trust the default gateway that is provided to you by DHCP when > >> you log on a coffee shop wi-fi? No, you don't. But you still use it. > >> And maybe you don't even consider this problematic. IMHO, if we dig > >> deep enough we'll find that this problem is basically unfixable. > >> There will always be an untrustworthy infrastructure layer on top of w= hich > trustworthy applications are built. > >> > >> I think what we need to do is: > >> > >> 0. Consider any network-provided TURN server as untrustworthy. This > >> is an axiomatic position. > >> > >> 1. Devise a mechanism allowing this piece of untrustworthy > >> infrastructure to be discovered. > >> > >> 2. Show how trustworthy applications can be built on top of this. > >> (i.e., by encrypting media streams using SRTP, DTLS, etc.) > >> > >> The untrustworthy TURN server will be able to know the 5-tuples > >> between the client and the peer. > > > > TURN is useful to provide privacy just like TOR. Using TOR ensures that= even if > the traffic is subjected to pervasive monitoring, attacker cannot find ou= t the > remote server with which the user is communicating. TURN can also be used= to > solve the same problem. If attacker can act as TURN server then this bene= fit of > providing privacy will be lost. > > > > -Tiru > > > >> An untrustworthy IP router would equally be able to do it. > >> But with appropriate encryption, it won't be able to discover > >> anything more. So this would not introduce any new attack vector IMHO. > >> > >> Simon > >> -- > >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca > >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > >> STUN/TURN server --> http://numb.viagenie.ca > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Tue Mar 25 04:58:36 2014 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 366D91A0078 for ; Tue, 25 Mar 2014 04:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 y-bb7U-wOa0R for ; Tue, 25 Mar 2014 04:58:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6967D1A0070 for ; Tue, 25 Mar 2014 04:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7457; q=dns/txt; s=iport; t=1395748686; x=1396958286; h=from:to:cc:subject:date:message-id:mime-version; bh=b5oB0ukIpZQsOWvZGDQpz4AEBOE3U23rwl8zs3UxPS0=; b=GRZh0eKnpQpLWpejyNMg1D7TmD6kmw6zVqb8ivNJ0u1k+crCOtOuC8ve dMjfzSuF73F9pw1fcIBVZLoVeDpccQap8qecsQuRPl0byNwRG0JMQh3dY gbUgo73Im+AmzruHTvjOXQSJm0YINv2hhYmPFm2Ps/QxtIK9A2SfoIDTF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFACFuMVOtJV2d/2dsb2JhbABZgkJEO1e7Noc1gSIWdIIlAQEBBAEBASpBCxIBCA4DBAEBCx0uCxQJCQEEAQ0FCBOHXg3OfBMEjj0tBAaDJYEUBKp/gy6CKw X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208,217";a="312491425" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 25 Mar 2014 11:58:06 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2PBw67F025164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 11:58:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 06:58:06 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Brandon Williams Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9IIXe8YezEAY3fQUeZ9y0eIVem7A== Date: Tue, 25 Mar 2014 11:58:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242ED668@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.147] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242ED668xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KIe8fS9zYwKWKWNA9G7_Z94dwNQ Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 25 Mar 2014 11:58:09 -0000 --_000_913383AAA69FF945B8F946018B75898A242ED668xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good points, will update add them to draft-ietf-tram-auth-problems. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Tuesday, March 25, 2014 1:48 AM To: Brandon Williams Cc: tram@ietf.org Subject: Re: [tram] STUN hash agility I suppose that that summary is good enough - it describes the problem witho= ut suggesting a particular solution. On Mon, Mar 24, 2014 at 12:58 PM, Brandon Williams > wrote: These two problems might want separate bullets, but they are definitely bot= h important issues with the authentication mechanism in the RFC. --Brandon On 03/24/2014 02:18 PM, Simon Perreault wrote: I don't see this problem listed in draft-ietf-tram-auth-problems. Does it need to be? Here's a naive attempt at a summary. Please feel free to suggest improvements. 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no mechanism for hash agility in the protocol itself, although Section 16.3 of [RFC5389] does discuss a plan for migrating to a more secure algorithm in case HMAC-SHA1 is found to be compromised. In addition, STUN passwords are stored server-side using unsalted MD5 hashes, which is not considered best current practice. [RFC6151] Simon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A242ED668xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good points, will update = add them to draft-ietf-tram-auth-problems.

 <= /p>

-Tiru

 <= /p>

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Tuesday, March 25, 2014 1:48 AM
To: Brandon Williams
Cc: tram@ietf.org
Subject: Re: [tram] STUN hash agility

 

I suppose that that summary is good enough - it desc= ribes the problem without suggesting a particular solution.

 

On Mon, Mar 24, 2014 at 12:58 PM, Brandon Williams &= lt;brandon= .williams@akamai.com> wrote:

These two problems might want separate bullets, but = they are definitely both important issues with the authentication mechanism= in the RFC.

--Brandon



On 03/24/2014 02:18 PM, Simon Perreault wrote:

I don't see this prob= lem listed in draft-ietf-tram-auth-problems. Does
it need to be?

Here's a naive attempt at a summary. Please feel free to suggest
improvements.

7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no
mechanism for hash agility in the protocol itself, although Section 16.3 of [RFC5389] does discuss a plan for migrating to a more secure
algorithm in case HMAC-SHA1 is found to be compromised. In addition,
STUN passwords are stored server-side using unsalted MD5 hashes, which
is not considered best current practice. [RFC6151]

Simon


--

Brandon Williams; Senior Principal Software Engineer=
Emerging Products Engineering; Akamai Technologies Inc.



_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

--_000_913383AAA69FF945B8F946018B75898A242ED668xmbrcdx10ciscoc_-- From nobody Tue Mar 25 05:13:02 2014 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 0723C1A0097 for ; Tue, 25 Mar 2014 05:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MWLm2mvNxEiL for ; Tue, 25 Mar 2014 05:12:31 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9241A009E for ; Tue, 25 Mar 2014 05:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4739; q=dns/txt; s=iport; t=1395749550; x=1396959150; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=v4xE5zHzxzEQSpnP1Ff38cedcEFI1Y/TRoMZJGyA+wU=; b=BS5zX8xOq+H/H5ljBdUv2op7q/yHq8jwFOFt/TEU8Ym33qzVNh0Bpptn 5ANmJm9wLl9BcalJgHiPGLR+UXRJPxaDpKPrdrAfW+XpRijySgILRbp7K YeQQsq8+VhakdbBS8ZD4MA4acm7OYjXPLsmUpkVPdHBsSFLWFVwEqzrh2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAK1xMVOtJXG+/2dsb2JhbABZgwY7V7s2hzWBIhZ0giUBAQEEAQEBaAMbAgEIGC4nCyUBAQQBEhkCh14Nzn8TBI4WX4Q4BIkai0eDbJIygy6BaUI X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208";a="30153282" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 25 Mar 2014 12:12:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2PCCT1g027184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 12:12:29 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 07:12:29 -0500 From: "Prashanth Patil (praspati)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9E19q/TuSDFtQ6w0CH5HnkZEyyrgAV2FKAAAKnDAAAkRs58wA/TQuA Date: Tue, 25 Mar 2014 12:12:28 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> <532C4960.9030005@akamai.com> <532C4D24.5060007@akamai.com> <53305D6F.7050000@akamai.com> In-Reply-To: <53305D6F.7050000@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.127.18.26] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5EE8C495670755478454D57AE207C59A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Ki6Pa5NCU2SO15Y5lmQEaAtIoHI Subject: Re: [tram] TURN server discovery (please discuss!) 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, 25 Mar 2014 12:12:34 -0000 On 3/24/14 9:59 PM, "Brandon Williams" wrote: >On 03/22/2014 05:03 AM, Prashanth Patil (praspati) wrote: >> >> >> On 3/21/14 8:01 PM, "Brandon Williams" >>wrote: >> >>> On a separate note, also related to (D)TLS ... >>> >>> It's not completely clear to me how the anycast approach to server >>> discovery would work together with secure data flows. What are the >>> server-side cert requirements in order to make an anycast solution >>>work? >>> I'm not suggesting that it won't work -- just that people (like me) who >>> do have much expertize with cert management may need to have it spelled >>> out in order to evaluate whether the requirements seem reasonable. >> >> The response to an anycast request will be a 300 (try alternate) >>response. >> The response will contain the unicast address in the ALTERNATE_SERVER >> attribute. This has been discussed (in another context), and will be >> included in the next revision. >> Once you have a definitive address, certificate management (or issues >>with >> it) has to be dealt with the same way it's done for addresses learnt any >> other way. > >I see a typo in my previous message ... "people who _do_ have much >expertize with cert management" should have been "people who _don't_ >have much expertize with cert management". I think that was obvious from >the context, but it still seemed worth pointing out, since when I >suggested that it may need to be spelled out, I really meant that. > >You've described the response to the anycast request, but that assumes >that a DTLS session has already been negotiated. Im assuming anycast is not secured. DTLS will only be negotiated for communication with the unicast IP address obtained in the anycast response. It probably needs to be this way, so that servers that do not support DTLS can also respond to anycast requests. >I'm interested in the >cert requirements for getting that DTLS session set up in the first >place. Are they self-signed certificates? How can the client know that >it has connected to a trusted TURN server? Is there an assumption that >DTLS in this context will really only be useful for protecting against >passive eavesdropping and man-in-the-middle attacks after session >establishment, not potentially malicious TURN servers? Trust management is indeed tricky. In its absence, opportunistic encryption is probably what we'll end up. -Prashanth >Will the TURN=20 >client be required to accept certs in this context that it would not >accept in other contexts? > >--Brandon > >> >> -Prashanth >> >> >>> >>> --Brandon >>> >>> On 03/21/2014 10:14 AM, Brandon Williams wrote: >>>> I think that some type of authentication is necessary, even if all it >>>> provides is the ability to verify that the two ends of the tunnel >>>>remain >>>> consistent throughout the life of the allocation. Without at least >>>>that, >>>> then the service is open to DOS attacks via message injection. The >>>> network geographic location of the attacker could be limited, but such >>>> attacks could not be prevented entirely. >>>> >>>> Of course, TLS or DTLS could be used for this purpose, but is it >>>> reasonable to require that overhead just for the purpose of >>>> authenticating the TURN control traffic? >>>> >>>> --Brandon >>>> >>>> On 03/21/2014 08:58 AM, Simon Perreault wrote: >>>>> Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a =E9crit : >>>>>> Yes. It brings few other challenges like if TURN server is provided >>>>>> by ISP then how will authentication and authorization work ? >>>>>> I mean for users logging into a coffee shop, Hotels etc. >>>>>> >>>>>> How will these endpoints know the credentials to use with the TURN >>>>>> servers provided by ISP ? >>>>> >>>>> If the TURN server is provided by the network, couldn't we assume >>>>>that >>>>> authentication is network-based? That is, if you succeed in talking >>>>>to >>>>> the server, then that means you're good. TURN servers would >>>>>effectively >>>>> have "no authentication" in the protocol. >>>>> >>>>> Simon >>>>> >>>> >>> >>> -- >>> Brandon Williams; Senior Principal Software Engineer >>> Emerging Products Engineering; Akamai Technologies Inc. >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >> > >--=20 >Brandon Williams; Senior Principal Software Engineer >Emerging Products Engineering; Akamai Technologies Inc. > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Tue Mar 25 07:32:30 2014 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 A300C1A0145 for ; Tue, 25 Mar 2014 07:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NPF3jn1UUqk1 for ; Tue, 25 Mar 2014 07:32:26 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D185D1A011C for ; Tue, 25 Mar 2014 07:32:26 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 41FBE40379 for ; Tue, 25 Mar 2014 10:32:25 -0400 (EDT) Message-ID: <53319378.8080203@viagenie.ca> Date: Tue, 25 Mar 2014 10:32:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> <532C4960.9030005@akamai.com> <532C4D24.5060007@akamai.com> <53305D6F.7050000@akamai.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/b0e8fYfZ46cXTqN_Rtm65KNs1HY Subject: Re: [tram] TURN server discovery (please discuss!) 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, 25 Mar 2014 14:32:28 -0000 Le 2014-03-25 08:12, Prashanth Patil (praspati) a écrit : > Im assuming anycast is not secured. Do you mean a TURN server responding to the *well-known* anycast address, or any anycast address at all? I can imagine an application provider using anycast for its own TURN server cloud, but not using the well-known anycast address. I would expect this to be secured. A concrete example: a WebRTC application provider, let's name it callyourmom.com, sets up 3 TURN servers located in America, Europe, and Asia. It sets up anycast with IP addresses it owns (not the well-known addresses). The name turn.callyourmom.com resolves to those anycast addresses. When a (D)TLS connection is attempted to turn.callyourmom.com, I would expect the server certificate to be verified by the client to ensure it is signed by a trusted CA and matches the turn.callyourmom.com domain name. Then when it receives the ALTERNATE-SERVER IP address, a new (D)TLS connection would be made, and once again the server certificate should be verified to match the turn.callyourmom.com domain name. So even though the ALTERNATE-SERVER attribute only contains an IP address, the original domain name used for the first connection is used for validating the server certificate. Did I get that right? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 25 07:32:41 2014 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 4395B1A0152 for ; Tue, 25 Mar 2014 07:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dENO2MGwEmr0 for ; Tue, 25 Mar 2014 07:32:39 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 021D11A0150 for ; Tue, 25 Mar 2014 07:32:38 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/25/2014 10:32:36 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-152/SG:2 3/25/2014 10:31:57 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.877286 p=-0.97751 Source White X-Signature-Violations: 0-0-0-4065-c X-Note-419: 15.6005 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/25/2014 10:32:17 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 82920724; Tue, 25 Mar 2014 10:32:36 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 25 Mar 2014 09:32:35 -0500 From: Jonathan Lennox To: Simon Perreault Thread-Topic: [tram] STUN hash agility Thread-Index: AQHPSDTHpDvk2TE2/kuLWQAd3HLhsJryMYqA Date: Tue, 25 Mar 2014 14:32:34 +0000 Message-ID: <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> References: <53307713.4000100@viagenie.ca> In-Reply-To: <53307713.4000100@viagenie.ca> 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="Windows-1252" Content-ID: <83C3D6DBA9B49D459BDCBC622B619A6F@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AUY0tQ4Kxj6DK1LLSLZU0DtnDHo Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 25 Mar 2014 14:32:40 -0000 On Mar 24, 2014, at 2:18 PM, Simon Perreault = wrote: > I don't see this problem listed in draft-ietf-tram-auth-problems. Does > it need to be? >=20 > Here's a naive attempt at a summary. Please feel free to suggest > improvements. >=20 > 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no > mechanism for hash agility in the protocol itself, although Section 16.3 > of [RFC5389] does discuss a plan for migrating to a more secure > algorithm in case HMAC-SHA1 is found to be compromised. In addition, > STUN passwords are stored server-side using unsalted MD5 hashes, which > is not considered best current practice. [RFC6151] I would amplify the second point to say that it=92s currently not possible = use STUN long-term credentials in FIPS 140-2 compliant implementations, sin= ce MD5 isn=92t an approved algorithm. For a solution (and thus getting off the direct topic of draft-ietf-tram-au= th-problems), one possibility would be to change the long-term credential m= echanism to be able to use SHA-256 instead of MD5 (and thus inheriting the = mechanisms of draft-ietf-httpauth-digest in the same way that STUN inherits= those of RFC 2617), and I believe Oleg=92s rfc5766-turn-server implements = something like this. However, it sounds like people might think that long-term credentials are b= roken for deeper reasons than just the choice of the hash algorithm, which = would imply that a deeper mechanism change would be needed. = From nobody Tue Mar 25 08:15:57 2014 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 D4CCE1A0160 for ; Tue, 25 Mar 2014 08:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8mReAR7LvEA5 for ; Tue, 25 Mar 2014 08:15:24 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id C13E91A0191 for ; Tue, 25 Mar 2014 08:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2048; q=dns/txt; s=iport; t=1395760523; x=1396970123; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FQAzQIy2jIl+PC9NK+iGwZK4uGZ3Z3F33l2GXblmBL8=; b=Tc5+grluD9C4fNx9tlwjbwqfiHi7c7m2njyE9D5GYoUwfkHM1tP/Br6w /Ok8wD/VvjhyiqNv/oZhOl5M2qEVSenY3knCt6PLTij+OVKpVR/x2CJpI U9+2RaoDMnWcLHyoZt30h50PgR4wzjMK1RTsbBEXVzyjSU/WdAB3oW5yx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAEGdMVOtJV2Z/2dsb2JhbABZgwY7V7s4hzWBGhZ0giYBAQQBAQEkRxsCAQhGJwslAQEEARKHeQ3POBeOdYQ4BIkajzOBMpEAgy6BayQc X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208";a="30197408" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 25 Mar 2014 15:15:22 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2PFFM1s031523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 15:15:22 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 10:15:22 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] TURN server discovery (please discuss!) Thread-Index: Ac9E19q/TuSDFtQ6w0CH5HnkZEyyrg== Date: Tue, 25 Mar 2014 15:15:21 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A242D98DE@xmb-rcd-x10.cisco.com> <532C3793.9050203@viagenie.ca> <532C4960.9030005@akamai.com> <532C4D24.5060007@akamai.com> <53305D6F.7050000@akamai.com> <53319378.8080203@viagenie.ca> In-Reply-To: <53319378.8080203@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.67.47] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E0198839876ED45AF16E04B61A275D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YZT_ZH9LVmq-wj2rnQZTn7AETa8 Subject: Re: [tram] TURN server discovery (please discuss!) 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, 25 Mar 2014 15:15:33 -0000 On 3/25/14 8:02 PM, "Simon Perreault" wrote: >Le 2014-03-25 08:12, Prashanth Patil (praspati) a =E9crit : >> Im assuming anycast is not secured. > >Do you mean a TURN server responding to the *well-known* anycast >address, or any anycast address at all? I meant *well known*, an address assigned by IANA as suggested in the draft. > >I can imagine an application provider using anycast for its own TURN >server cloud, but not using the well-known anycast address. I would >expect this to be secured. > >A concrete example: a WebRTC application provider, let's name it >callyourmom.com, sets up 3 TURN servers located in America, Europe, and >Asia. It sets up anycast with IP addresses it owns (not the well-known >addresses). The name turn.callyourmom.com resolves to those anycast >addresses. When a (D)TLS connection is attempted to >turn.callyourmom.com, I would expect the server certificate to be >verified by the client to ensure it is signed by a trusted CA and >matches the turn.callyourmom.com domain name. Then when it receives the >ALTERNATE-SERVER IP address, a new (D)TLS connection would be made, and >once again the server certificate should be verified to match the >turn.callyourmom.com domain name. So even though the ALTERNATE-SERVER >attribute only contains an IP address, the original domain name used for >the first connection is used for validating the server certificate. > >Did I get that right? Yes, and it's easier because the client already knows or has discovered the domain name, which can be verified. Complicated when the client discovers an IP address from a well known anycast. -Prashanth > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Tue Mar 25 22:58:02 2014 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 751BE1A0298 for ; Tue, 25 Mar 2014 22:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXDuPFF3o1qE for ; Tue, 25 Mar 2014 22:57:56 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CB6BA1A021B for ; Tue, 25 Mar 2014 22:57:56 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fa1so1472373pad.28 for ; Tue, 25 Mar 2014 22:57:55 -0700 (PDT) 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=qR6oGONQTEFZdLNcMqonx6b5ZT9tkCSOqLKxll83TLs=; b=u0CXOklZljYcypwrluoD3SBCgKpXWHQAadTjeEYkWhCZmXkaSrqLfNyY95KJMnY2qv GPEg4YESUcs6d0gQb8vU5vqugPDI51gSGhspr4L9ZX9LvH7zPGjtjnbq4y9BrvRvLNZF 4ADm1N/5KFAk6CM2cYlIjNsN13+frbTx1Jl3Mn/ZleO8FJJEAymQ9SYLEXeYSI15yyAT s5Anwyr7r+gWCdTmA7syTd1IWA/jn5Qm4oQVbHdl5m5iDzkuFx4KyYyVh4Y3B1ZkLcup ZZHLXU8wlWPaqFYpFGEBqvSuA+N1oDCGzrq+O4D8ke6mj+EszU5G/EfDXvyJeubRZoXv J5jg== MIME-Version: 1.0 X-Received: by 10.68.237.133 with SMTP id vc5mr83428185pbc.92.1395813475542; Tue, 25 Mar 2014 22:57:55 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Tue, 25 Mar 2014 22:57:55 -0700 (PDT) In-Reply-To: <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> References: <53307713.4000100@viagenie.ca> <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> Date: Tue, 25 Mar 2014 22:57:55 -0700 Message-ID: From: Oleg Moskalenko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7b338f1d61ec7e04f57c269a Archived-At: http://mailarchive.ietf.org/arch/msg/tram/A2Ah86mvN4Fg04jsGFLhGUDuGuI Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 26 Mar 2014 05:58:00 -0000 --047d7b338f1d61ec7e04f57c269a Content-Type: text/plain; charset=ISO-8859-1 Jonathan, please see below inline: On Tue, Mar 25, 2014 at 7:32 AM, Jonathan Lennox wrote: > > On Mar 24, 2014, at 2:18 PM, Simon Perreault > wrote: > > > I don't see this problem listed in draft-ietf-tram-auth-problems. Does > > it need to be? > > > > Here's a naive attempt at a summary. Please feel free to suggest > > improvements. > > > > 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no > > mechanism for hash agility in the protocol itself, although Section 16.3 > > of [RFC5389] does discuss a plan for migrating to a more secure > > algorithm in case HMAC-SHA1 is found to be compromised. In addition, > > STUN passwords are stored server-side using unsalted MD5 hashes, which > > is not considered best current practice. [RFC6151] > > I would amplify the second point to say that it's currently not possible > use STUN long-term credentials in FIPS 140-2 compliant implementations, > since MD5 isn't an approved algorithm. > > For a solution (and thus getting off the direct topic of > draft-ietf-tram-auth-problems), one possibility would be to change the > long-term credential mechanism to be able to use SHA-256 instead of MD5 > (and thus inheriting the mechanisms of draft-ietf-httpauth-digest in the > same way that STUN inherits those of RFC 2617), and I believe Oleg's > rfc5766-turn-server implements something like this. > I did not get the part SHA256 vs MD5. SHA1 algorithm (and optionally SHA256 in our implementation) is used for the message digest calculation. MD5 is used totally independently of SHA1 (and SHA256) for a different purpose - for the key calculation (and storage). Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably, for FIPS, it would indeed make sense. We are currently still using MD5 for the key storage, and SHA256 only for the message digest. Oleg --047d7b338f1d61ec7e04f57c269a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jonathan, please see below inline:


On Tue, Mar 25, 2014 at 7:32= AM, Jonathan Lennox <jonathan@vidyo.com> wrote:

On Mar 24, 2014, at 2:18 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> I don't see this problem listed in draft-ietf-tram-auth-problems. = Does
> it need to be?
>
> Here's a naive attempt at a summary. Please feel free to suggest > improvements.
>
> 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no
> mechanism for hash agility in the protocol itself, although Section 16= .3
> of [RFC5389] does discuss a plan for migrating to a more secure
> algorithm in case HMAC-SHA1 is found to be compromised. In addition, > STUN passwords are stored server-side using unsalted MD5 hashes, which=
> is not considered best current practice. [RFC6151]

I would amplify the second point to say that it’s currently not= possible use STUN long-term credentials in FIPS 140-2 compliant implementa= tions, since MD5 isn’t an approved algorithm.

For a solution (and thus getting off the direct topic of draft-ietf-tram-au= th-problems), one possibility would be to change the long-term credential m= echanism to be able to use SHA-256 instead of MD5 (and thus inheriting the = mechanisms of draft-ietf-httpauth-digest in the same way that STUN inherits= those of RFC 2617), and I believe Oleg’s rfc5766-turn-server impleme= nts something like this.

I did not get the part SHA256 vs MD5.
=
SHA1 algorithm (and optionally SHA256 in our implementation) is used fo= r the message digest calculation. MD5 is used totally independently of SHA1= (and SHA256) for a different purpose - for the key calculation (and storag= e). Are you suggesting usage of SHA256 for the key calculation, too (in pla= ce of MD5) ? Probably, for FIPS, it would indeed make sense. We are current= ly still using MD5 for the key storage, and SHA256 only for the message dig= est.

Oleg
--047d7b338f1d61ec7e04f57c269a-- From nobody Wed Mar 26 05:24:12 2014 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 2B1201A0084 for ; Wed, 26 Mar 2014 05:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CjeD1jFxd1JU for ; Wed, 26 Mar 2014 05:24:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A82061A01A5 for ; Wed, 26 Mar 2014 05:24:01 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 06E254037A; Wed, 26 Mar 2014 08:23:59 -0400 (EDT) Message-ID: <5332C6DF.5060704@viagenie.ca> Date: Wed, 26 Mar 2014 08:23:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko , Jonathan Lennox References: <53307713.4000100@viagenie.ca> <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LWQtxkhlRCZ47nPe4Ci0XN-E7Yo Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 26 Mar 2014 12:24:08 -0000 Le 2014-03-26 01:57, Oleg Moskalenko a écrit : > > 7. STUN authentication relies on HMAC-SHA1 [RFC2104]. There is no > > mechanism for hash agility in the protocol itself, although > Section 16.3 > > of [RFC5389] does discuss a plan for migrating to a more secure > > algorithm in case HMAC-SHA1 is found to be compromised. In addition, > > STUN passwords are stored server-side using unsalted MD5 hashes, which > > is not considered best current practice. [RFC6151] > > I would amplify the second point to say that it’s currently not > possible use STUN long-term credentials in FIPS 140-2 compliant > implementations, since MD5 isn’t an approved algorithm. > > I did not get the part SHA256 vs MD5. > > SHA1 algorithm (and optionally SHA256 in our implementation) is used for > the message digest calculation. MD5 is used totally independently of > SHA1 (and SHA256) for a different purpose - for the key calculation (and > storage). Are you suggesting usage of SHA256 for the key calculation, > too (in place of MD5) ? Probably, for FIPS, it would indeed make sense. > We are currently still using MD5 for the key storage, and SHA256 only > for the message digest. The situation with MD5 as I understand it is the following. I'm not a cryptographer, so please anyone feel free to correct me. This is all from memory, so I'm not going to cite sources. - There are known attacks against MD5 and, to a lesser extent, SHA1. A better hash algorithm is to be preferred when possible. - Those attacks don't carry over to HMAC-SHA1, which is still believed to be secure for now. However, planning a migration to HMAC-SHA256 (or whatever else) would be justified. - The special case of HMAC-SHA1 used with a key resulting from MD5 is also believed to be secure for now. - In STUN, the server stores MD5(username:realm:password). This is problematic today because MD5 is known to be weak and there is no salt. So if the password database gets stolen, an attacker could recover passwords more easily than if a better hash algorithm was used with salt. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Mar 26 09:08:41 2014 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 CA4B81A033D for ; Wed, 26 Mar 2014 09:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uF0EZVSUlqbM for ; Wed, 26 Mar 2014 09:08:17 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0101A02D8 for ; Wed, 26 Mar 2014 09:08:14 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/26/2014 12:08:12 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-255/SG:5 3/26/2014 12:08:03 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.869532 p=-0.983113 Source White X-Signature-Violations: 0-0-0-11821-c X-Note-419: 15.6005 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/26/2014 12:07:54 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 83356402; Wed, 26 Mar 2014 12:08:11 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Wed, 26 Mar 2014 11:08:11 -0500 From: Jonathan Lennox To: Oleg Moskalenko Thread-Topic: [tram] STUN hash agility Thread-Index: AQHPSDTHpDvk2TE2/kuLWQAd3HLhsJryMYqAgAECh4CAAKqBAA== Date: Wed, 26 Mar 2014 16:08:10 +0000 Message-ID: <3D76C0B1-4451-46F9-B687-09DF0729F0EF@vidyo.com> References: <53307713.4000100@viagenie.ca> <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_3D76C0B1445146F9B68709DF0729F0EFvidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Y-q5QE3ksJ8P3fBz38niLoWR7qY Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 26 Mar 2014 16:08:20 -0000 --_000_3D76C0B1445146F9B68709DF0729F0EFvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 26, 2014, at 1:57 AM, Oleg Moskalenko > wrote: On Tue, Mar 25, 2014 at 7:32 AM, Jonathan Lennox > wrote: For a solution (and thus getting off the direct topic of draft-ietf-tram-au= th-problems), one possibility would be to change the long-term credential m= echanism to be able to use SHA-256 instead of MD5 (and thus inheriting the = mechanisms of draft-ietf-httpauth-digest in the same way that STUN inherits= those of RFC 2617), and I believe Oleg=92s rfc5766-turn-server implements = something like this. I did not get the part SHA256 vs MD5. SHA1 algorithm (and optionally SHA256 in our implementation) is used for th= e message digest calculation. MD5 is used totally independently of SHA1 (an= d SHA256) for a different purpose - for the key calculation (and storage). = Are you suggesting usage of SHA256 for the key calculation, too (in place o= f MD5) ? Probably, for FIPS, it would indeed make sense. We are currently s= till using MD5 for the key storage, and SHA256 only for the message digest. Yes, I=92m saying that we'd want to be able to use SHA256 for the key calcu= lation. This is partially motivated by the FIPS compliance problem. Additionally, however, one motivation for the specific design of STUN=92s c= urrent long-term credential mechanism was to let service providers re-use t= heir existing RFC 2617 password databases for their TURN servers. As draft-ietf-httpauth-digest=92s update to RFC 2617 is adding the ability = to use SHA-256 (and SHA-512/256) for digest authentication, and deprecating= MD5, if this is still a use case that TRAM wants to support we need to sup= port key calculation hash agility matching digest authentication=92s update= d hash agility. That said, I believe the service providers of interest in STUN's design wer= e not actually using RFC 2617 for HTTP Digest, but rather for SIP authentic= ation. So I think TRAM=92s decision may want to depend on whether the SIPC= ORE working group decides to adopt draft-yusef-sipcore-digest-scheme (which= adapts draft-ietf-httpauth-digest to SIP), or instead goes for a more thor= ough redesign of SIP authentication, which some people were advocating in t= he working group meeting in London. --_000_3D76C0B1445146F9B68709DF0729F0EFvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 26, 2014, at 1:57 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

On Tue, Mar 25, 2014 at 7:32 AM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:

For a solution (and thus getting off the direct topic of draft-ietf-tram-au= th-problems), one possibility would be to change the long-term credential m= echanism to be able to use SHA-256 instead of MD5 (and thus inheriting the = mechanisms of draft-ietf-httpauth-digest in the same way that STUN inherits those of RFC 2617), and I believe Oleg= =92s rfc5766-turn-server implements something like this.

I did not get the part SHA256 vs MD5.

SHA1 algorithm (and optionally SHA256 in our implementation) is used for th= e message digest calculation. MD5 is used totally independently of SHA1 (an= d SHA256) for a different purpose - for the key calculation (and storage). = Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably, for FIPS, it wo= uld indeed make sense. We are currently still using MD5 for the key storage= , and SHA256 only for the message digest.

Yes, I=92m saying that we'd want to be able to use SHA256 for the key = calculation.

This is partially motivated by the FIPS compliance problem.

Additionally, however, one motivation for the specific design of STUN= =92s current long-term credential mechanism was to let service providers re= -use their existing RFC 2617 password databases for their TURN servers.

As draft-ietf-httpauth-digest=92s update to RFC 2617 is adding the abi= lity to use SHA-256 (and SHA-512/256) for digest authentication, and deprec= ating MD5, if this is still a use case that TRAM wants to support we need t= o support key calculation hash agility matching digest authentication=92s updated hash agility.

That said, I believe the service providers of interest in STUN's desig= n were not actually using RFC 2617 for HTTP Digest, but rather for SIP auth= entication.  So I think TRAM=92s decision may want to depend on whethe= r the SIPCORE working group decides to adopt draft-yusef-sipcore-digest-scheme (which adapts draft-ietf-http= auth-digest to SIP), or instead goes for a more thorough redesign of SIP au= thentication, which some people were advocating in the working group meetin= g in London.
--_000_3D76C0B1445146F9B68709DF0729F0EFvidyocom_-- From nobody Thu Mar 27 15:26:21 2014 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 535BA1A03DA for ; Thu, 27 Mar 2014 15:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNfrUOSVROvs for ; Thu, 27 Mar 2014 15:26:17 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 18D111A0252 for ; Thu, 27 Mar 2014 15:26:17 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so4076740pbb.22 for ; Thu, 27 Mar 2014 15:26:15 -0700 (PDT) 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=Uv746hhf4Q/zIi3ORRP0R1DE7UuS/yW+CLpYyX9Jgxw=; b=Zmhms624r0wtwfwD/HzhBsjMOJyB1Q+qq2SAiFP9DV8c7BGiQvmx0fyjiaAWynO+Ww SS26FWRGN5h2ybfwTQZjShzah+6aXVoRXu1GIelKR/ykVUGSnpwoRd75IrIf4WY8JFiq vlBkNIYgkLfXe1tJQVDFj56sYqZe8hWo/i3CBGezUuoWVlk7wCWa+/F4qOZkjroio9UI M//Ww4SzK3lXYCDDEBaTVdWZUmP8yxPPf4kVQrRQXh0tZH0BYjsqVJI4x6mjkdf8hTvL o8BgD2egYlCRvefwt6a6yPh9QR8xAE6HArigxJ3oFd79SpLa/V/LDIsl7ZYHtbtuR0qY 8ciQ== MIME-Version: 1.0 X-Received: by 10.66.181.70 with SMTP id du6mr4532146pac.23.1395959175252; Thu, 27 Mar 2014 15:26:15 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Thu, 27 Mar 2014 15:26:15 -0700 (PDT) In-Reply-To: <3D76C0B1-4451-46F9-B687-09DF0729F0EF@vidyo.com> References: <53307713.4000100@viagenie.ca> <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> <3D76C0B1-4451-46F9-B687-09DF0729F0EF@vidyo.com> Date: Thu, 27 Mar 2014 15:26:15 -0700 Message-ID: From: Oleg Moskalenko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7bd6b828c312a904f59e12f2 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/IFotLzRbwYTa_zrKNBrP4k6-Tms Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 27 Mar 2014 22:26:19 -0000 --047d7bd6b828c312a904f59e12f2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox wrote: > > > SHA1 algorithm (and optionally SHA256 in our implementation) is used for > the message digest calculation. MD5 is used totally independently of SHA1 > (and SHA256) for a different purpose - for the key calculation (and > storage). Are you suggesting usage of SHA256 for the key calculation, too > (in place of MD5) ? Probably, for FIPS, it would indeed make sense. We are > currently still using MD5 for the key storage, and SHA256 only for the > message digest. > > > Yes, I'm saying that we'd want to be able to use SHA256 for the key > calculation. > > This is partially motivated by the FIPS compliance problem. > > > I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I found no suggestion on the key storage and calculation algorithms. The problem is that I do not think that we can use the "classic" HMAC-SHA approach with a salt word, or a shared secret, as the keys for the HMAC functions - because then we have an immediate problem: how the client (person or application) will know that salt value or the secret value ? The client application must be able to calculate the same hash key value. May be I am missing something (I am not a security expert), but if we do want to use HMAC-SHA256 for the keys, then I see only one realistic approach (or a variation): hmac-key = username:realm:password long-term-credentials-key = HMAC-SHA256(hmac-key)[hmac-key], where hmac-key is used both as the key and as the input string to the HMAC algorithm. STUN-message-integrity-digest = HMAC-SHA256(message)[long-term-credentials-key] (similar to the existing long-term-credentials mechanism) With this approach, we are having about the same advantages as the "salt scheme" has, but we do not have a problem how to distribute the "salt" or the extra "secret" to the client application. Oleg --047d7bd6b828c312a904f59e12f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:


SHA1 algorithm (and optionally SHA256 in our implementation) is used for th= e message digest calculation. MD5 is used totally independently of SHA1 (an= d SHA256) for a different purpose - for the key calculation (and storage). = Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably, for FIPS, it wo= uld indeed make sense. We are currently still using MD5 for the key storage= , and SHA256 only for the message digest.

Yes, I’m saying that we'd want to be able to use SHA256 for = the key calculation.

This is partially motivated by the FIPS compliance problem.



I checked the document ht= tp://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I fou= nd no suggestion on the key storage and calculation algorithms.

The problem is that I do not think that we can use the "= ;classic" HMAC-SHA approach with a salt word, or a shared secret, as t= he keys for the HMAC functions - because then we have an immediate problem:= how the client (person or application) will know that salt value or the se= cret value ? The client application must be able to calculate the same hash= key value.

May be I am missing something (I am not a security expert), but if we d= o want to use HMAC-SHA256 for the keys, then I see only one realistic appro= ach (or a variation):

hmac-key =3D username:realm:passwor= d

long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key= ], where hmac-key is used both as the key and as the input string to the HM= AC algorithm.

STUN-message-integrity-digest =3D HMAC-SHA2= 56(message)[long-term-credentials-key] (similar to the existing long-term-c= redentials mechanism)

With this approach, we are having about the same advantages = as the "salt scheme" has, but we do not have a problem how to dis= tribute the "salt" or the extra "secret" to the client = application.

Oleg

--047d7bd6b828c312a904f59e12f2-- From nobody Thu Mar 27 15:35:00 2014 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 5AA3D1A024E for ; Thu, 27 Mar 2014 15:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.27 X-Spam-Level: X-Spam-Status: No, score=0.27 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 i9RZeb8ABtOD for ; Thu, 27 Mar 2014 15:34:55 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 334891A0252 for ; Thu, 27 Mar 2014 15:34:55 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/27/2014 6:34:52 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-175/SG:5 3/27/2014 6:34:10 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.946255 p=-0.982931 Source White X-Signature-Violations: 0-0-0-14331-c X-Note-419: 15.6005 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/27/2014 6:34:32 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 109860806; Thu, 27 Mar 2014 18:34:51 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 27 Mar 2014 17:34:51 -0500 From: Jonathan Lennox To: Oleg Moskalenko Thread-Topic: [tram] STUN hash agility Thread-Index: AQHPSDTHpDvk2TE2/kuLWQAd3HLhsJryMYqAgAECh4CAAKqBAIAB+/eAgAACZgA= Date: Thu, 27 Mar 2014 22:34:50 +0000 Message-ID: References: <53307713.4000100@viagenie.ca> <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> <3D76C0B1-4451-46F9-B687-09DF0729F0EF@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_FCD72E214141486C98BF21C256E0D904vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/k8MIZY5ugzk6nJfDgT9HfY5xpMw Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 27 Mar 2014 22:34:57 -0000 --_000_FCD72E214141486C98BF21C256E0D904vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko > wrote: On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox > wrote: SHA1 algorithm (and optionally SHA256 in our implementation) is used for th= e message digest calculation. MD5 is used totally independently of SHA1 (an= d SHA256) for a different purpose - for the key calculation (and storage). = Are you suggesting usage of SHA256 for the key calculation, too (in place o= f MD5) ? Probably, for FIPS, it would indeed make sense. We are currently s= till using MD5 for the key storage, and SHA256 only for the message digest. Yes, I=92m saying that we'd want to be able to use SHA256 for the key calcu= lation. This is partially motivated by the FIPS compliance problem. I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-diges= t-update-05 and I found no suggestion on the key storage and calculation al= gorithms. That document has been replaced by http://tools.ietf.org/html/draft-ietf-ht= tpauth-digest-05 =97 they decided to re-write it as a replacement for RFC 2= 617, not an update to it. Apologies if I had the wrong link in an earlier = e-mail. In that document, the key is H(A1), as described in section 5.12 =97 i.e., = hash(username:realm:password). (Section 5.12 is poorly worded, because the= re are two different versions of A1 =97 but in either case, what the databa= se has to store is exactly hash(username:realm:password).) The problem is that I do not think that we can use the "classic" HMAC-SHA a= pproach with a salt word, or a shared secret, as the keys for the HMAC func= tions - because then we have an immediate problem: how the client (person o= r application) will know that salt value or the secret value ? The client a= pplication must be able to calculate the same hash key value. May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation): hmac-key =3D username:realm:password long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm. STUN-message-integrity-digest =3D HMAC-SHA256(message)[long-term-credential= s-key] (similar to the existing long-term-credentials mechanism) With this approach, we are having about the same advantages as the "salt sc= heme" has, but we do not have a problem how to distribute the "salt" or the= extra "secret" to the client application. I don=92t see any benefits to using HMAC for the long-term-credentials-key = over using SHA256(username:realm:password) directly. --_000_FCD72E214141486C98BF21C256E0D904vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <63120FF6D5031E4580743B70DC82FF40@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:

On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <jonath= an@vidyo.com> wrote:


SHA1 algorithm (and optionally SHA256 in our implementation) is used f= or the message digest calculation. MD5 is used totally independently of SHA= 1 (and SHA256) for a different purpose - for the key calculation (and stora= ge). Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably, for FIPS= , it would indeed make sense. We are currently still using MD5 for the key = storage, and SHA256 only for the message digest.

Yes, I=92m saying that we'd want to be able to use SHA256 for the key = calculation.

This is partially motivated by the FIPS compliance problem.

I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I f= ound no suggestion on the key storage and calculation algorithms.

That document has been replaced by http://tools.ietf.org/html/draft-iet= f-httpauth-digest-05 =97 they decided to re-write it as a replacement f= or RFC 2617, not an update to it.  Apologies if I had the wrong link in an earlier e-mail.

In that document, the key is H(A1), as described in section 5.12 =97 i= .e., hash(username:realm:password).  (Section 5.12 is poorly worded, b= ecause there are two different versions of A1 =97 but in either case, what = the database has to store is exactly hash(username:realm:password).)

The problem is that I do not think that we can use the "classic&q= uot; HMAC-SHA approach with a salt word, or a shared secret, as the keys fo= r the HMAC functions - because then we have an immediate problem: how the c= lient (person or application) will know that salt value or the secret value ? The client application must be able to ca= lculate the same hash key value.

May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation):

hmac-key =3D username:realm:password

long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm.

STUN-message-integrity-digest =3D HMAC-SHA256(message)[long-term-crede= ntials-key] (similar to the existing long-term-credentials mechanism)

With this approach, we are having about the same advantages as the &qu= ot;salt scheme" has, but we do not have a problem how to distribute th= e "salt" or the extra "secret" to the client applicatio= n.

I don=92t see any benefits to using HMAC for the long-term-credentials= -key over using SHA256(username:realm:password) directly.

--_000_FCD72E214141486C98BF21C256E0D904vidyocom_-- From nobody Thu Mar 27 15:44:23 2014 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 3F2A01A0707 for ; Thu, 27 Mar 2014 15:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ9cucV5fDPB for ; Thu, 27 Mar 2014 15:44:18 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D58AF1A06F0 for ; Thu, 27 Mar 2014 15:44:18 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id z10so3969070pdj.18 for ; Thu, 27 Mar 2014 15:44:17 -0700 (PDT) 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=kMyV1O3OUaumswZJhN2lcRE8MPtPOQZeRz2pU2OvWik=; b=brQSdF3R2jjN+U23bYc/R3Jqf9Zl3J7wrEFi5eXFg5HGrOyOI8RXQ3whmqJwGPL2g5 eHpM0Vc1aZhUVKdPL5VEvalMUWey5mvAiX3iw+l2PB3WXYwlD/DjB3tgTR2RhRABYgu8 Edf7Ofm47YlcOivKWTMO3rxmcT/qCL/Itg6mzBtAJmK2aUo5tWIy0nx2fc7TBAVF6RFP TmaisFgt2FBjwh9xARiVANoQ5O3HRI6m2jwOJdMMashBhQHaMU3TSZDSR10YA9UrgOLI wE1M2ynGVbEpxLzTypSLvUF208/wJrxAbrkdhxnRZEcoaLVRPWoQRkYAAnIqsGt3GAvQ 0kow== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr4469700pad.115.1395960257059; Thu, 27 Mar 2014 15:44:17 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Thu, 27 Mar 2014 15:44:16 -0700 (PDT) In-Reply-To: References: <53307713.4000100@viagenie.ca> <6D09C4C9-8305-4738-98AF-54EEF32A41F3@vidyo.com> <3D76C0B1-4451-46F9-B687-09DF0729F0EF@vidyo.com> Date: Thu, 27 Mar 2014 15:44:16 -0700 Message-ID: From: Oleg Moskalenko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a113453ec3e251b04f59e53ef Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YmA0LcIFVNTfkieWyEWm0MSfMys Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 27 Mar 2014 22:44:21 -0000 --001a113453ec3e251b04f59e53ef Content-Type: text/plain; charset=ISO-8859-1 OK, thanks for the link. I agree that SHA256(username:realm:password) is better (simpler) here than HMAC-SHA256(username:realm:password)[username:realm:password]. I'll update our experimental implementation so it will be using SHA256 for the key storage. Oleg On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox wrote: > > On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko wrote: > > On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox wrote: > >> >> >> SHA1 algorithm (and optionally SHA256 in our implementation) is used >> for the message digest calculation. MD5 is used totally independently of >> SHA1 (and SHA256) for a different purpose - for the key calculation (and >> storage). Are you suggesting usage of SHA256 for the key calculation, too >> (in place of MD5) ? Probably, for FIPS, it would indeed make sense. We are >> currently still using MD5 for the key storage, and SHA256 only for the >> message digest. >> >> >> Yes, I'm saying that we'd want to be able to use SHA256 for the key >> calculation. >> >> This is partially motivated by the FIPS compliance problem. >> >> I checked the document > http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I > found no suggestion on the key storage and calculation algorithms. > > > That document has been replaced by > http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 -- they decided > to re-write it as a replacement for RFC 2617, not an update to it. > Apologies if I had the wrong link in an earlier e-mail. > > In that document, the key is H(A1), as described in section 5.12 -- i.e., > hash(username:realm:password). (Section 5.12 is poorly worded, because > there are two different versions of A1 -- but in either case, what the > database has to store is exactly hash(username:realm:password).) > > The problem is that I do not think that we can use the "classic" > HMAC-SHA approach with a salt word, or a shared secret, as the keys for the > HMAC functions - because then we have an immediate problem: how the client > (person or application) will know that salt value or the secret value ? The > client application must be able to calculate the same hash key value. > > May be I am missing something (I am not a security expert), but if we do > want to use HMAC-SHA256 for the keys, then I see only one realistic > approach (or a variation): > > hmac-key = username:realm:password > > long-term-credentials-key = HMAC-SHA256(hmac-key)[hmac-key], where > hmac-key is used both as the key and as the input string to the HMAC > algorithm. > > > STUN-message-integrity-digest = > HMAC-SHA256(message)[long-term-credentials-key] (similar to the existing > long-term-credentials mechanism) > > With this approach, we are having about the same advantages as the "salt > scheme" has, but we do not have a problem how to distribute the "salt" or > the extra "secret" to the client application. > > > I don't see any benefits to using HMAC for the long-term-credentials-key > over using SHA256(username:realm:password) directly. > > --001a113453ec3e251b04f59e53ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OK, thanks for the link.

I agree t= hat SHA256(username:realm:password) is better (simpler) here than HMAC-SHA2= 56(username:realm:password)[username:realm:password].

I&#= 39;ll update our experimental implementation so it will be using SHA256 for= the key storage.

Oleg



<= div class=3D"gmail_quote">On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox = <jonathan@vidyo.com> wrote:

On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <jonath= an@vidyo.com> wrote:


SHA1 algorithm (and optionally SHA256 in our implementation) is used f= or the message digest calculation. MD5 is used totally independently of SHA= 1 (and SHA256) for a different purpose - for the key calculation (and stora= ge). Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably, for FIPS= , it would indeed make sense. We are currently still using MD5 for the key = storage, and SHA256 only for the message digest.

Yes, I’m saying that we'd want to be able to use SHA256 for = the key calculation.

This is partially motivated by the FIPS compliance problem.

I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I f= ound no suggestion on the key storage and calculation algorithms.

That document has been replaced by http://tools= .ietf.org/html/draft-ietf-httpauth-digest-05 — they decided to re= -write it as a replacement for RFC 2617, not an update to it.  Apologi= es if I had the wrong link in an earlier e-mail.

In that document, the key is H(A1), as described in section 5.12 &mdas= h; i.e., hash(username:realm:password).  (Section 5.12 is poorly worde= d, because there are two different versions of A1 — but in either cas= e, what the database has to store is exactly hash(username:realm:password).= )

The problem is that I do not think that we can use the "classic&q= uot; HMAC-SHA approach with a salt word, or a shared secret, as the keys fo= r the HMAC functions - because then we have an immediate problem: how the c= lient (person or application) will know that salt value or the secret value ? The client application must be able to ca= lculate the same hash key value.

May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation):

hmac-key =3D username:realm:password

long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm.

STUN-message-integrity-digest =3D HMAC-SHA256(message)[long-term-crede= ntials-key] (similar to the existing long-term-credentials mechanism)

With this approach, we are having about the same advantages as the &qu= ot;salt scheme" has, but we do not have a problem how to distribute th= e "salt" or the extra "secret" to the client applicatio= n.

I don’t see any benefits to using HMAC for the long-term-credent= ials-key over using SHA256(username:realm:password) directly.


--001a113453ec3e251b04f59e53ef-- From nobody Fri Mar 28 02:16:29 2014 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 3C7DA1A04A6 for ; Fri, 28 Mar 2014 02:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, 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 m95VRELxaE30 for ; Fri, 28 Mar 2014 02:16:24 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE3E1A02CB for ; Fri, 28 Mar 2014 02:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16972; q=dns/txt; s=iport; t=1395998182; x=1397207782; h=from:to:cc:subject:date:message-id:mime-version; bh=Ri59t2znJ/0X6LNCYwngIWdg66Vj672xdhhfx4CinwQ=; b=Kwr8MpJ25YhU7NPzlv4Ai73zYwE9iqBP26waQ0OlAmLzGb9yOvUsiawY nYe3mATm6ozB6qzzdxnvlRim4WVg1yjeekfOoZtEJpO07PYbfDHduiXxf YS7W8luzXRDygjYBUTTaRqgdSNo+G1mK9aD4r9oDqJwdLi6wNjOQxC595 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFAHY8NVOtJXG//2dsb2JhbABZgkJEO1e5d4h2gRoWdIIlAQEBBC0+DhIBCA4DBAEBCw4PKBEUCQkBBAENBQiHXQMRDcoiDYcvF4xegVQYMQYHEoMMgRQElmCDIIs4hUqDMIFqQQ X-IronPort-AV: E=Sophos; i="4.97,749,1389744000"; d="scan'208,217"; a="31092360" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 28 Mar 2014 09:16:20 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2S9GKwn029118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Mar 2014 09:16:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 28 Mar 2014 04:16:20 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Jonathan Lennox Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9KZl423otf3PaqQwuSCXApnFgFzw== Date: Fri, 28 Mar 2014 09:16:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.236] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242EFAA3xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LrNOTpx45rrw5x6BzfgIiWnYV1A Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 09:16:28 -0000 --_000_913383AAA69FF945B8F946018B75898A242EFAA3xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition to the MD5 security problem that Simon had mentioned in previou= s mails. The other problems that will not be resolved with SHA256 are: 1)TURN Server has to maintain the {username/realm/password} database just l= ike the AD server which is an overhead. 2)In a large Enterprise Network (for e.g. consider a large service company)= where NNN number of new users join, MMM users leave every day. It seems di= fficult to manage this credential database on the TURN server to be in sync= with the AD. 3)If each branch office in an large enterprise network wants to deploy TURN= servers, then the cost of TURN server includes additional storage space an= d operational issues which may be a concern of the I.T. 4)AD server maintained in the Data Center usually has better physical secur= ity than branch offices - what if someone breaks into the branch office and= steals all the username + password ? (I am assuming the username, password= are the same credentials used to access other critical enterprise resource= s) -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Friday, March 28, 2014 4:14 AM To: Jonathan Lennox Cc: Simon Perreault; tram@ietf.org Subject: Re: [tram] STUN hash agility OK, thanks for the link. I agree that SHA256(username:realm:password) is better (simpler) here than = HMAC-SHA256(username:realm:password)[username:realm:password]. I'll update our experimental implementation so it will be using SHA256 for = the key storage. Oleg On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox > wrote: On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko > wrote: On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox > wrote: SHA1 algorithm (and optionally SHA256 in our implementation) is used for th= e message digest calculation. MD5 is used totally independently of SHA1 (an= d SHA256) for a different purpose - for the key calculation (and storage). = Are you suggesting usage of SHA256 for the key calculation, too (in place o= f MD5) ? Probably, for FIPS, it would indeed make sense. We are currently s= till using MD5 for the key storage, and SHA256 only for the message digest. Yes, I'm saying that we'd want to be able to use SHA256 for the key calcula= tion. This is partially motivated by the FIPS compliance problem. I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-diges= t-update-05 and I found no suggestion on the key storage and calculation al= gorithms. That document has been replaced by http://tools.ietf.org/html/draft-ietf-ht= tpauth-digest-05 - they decided to re-write it as a replacement for RFC 261= 7, not an update to it. Apologies if I had the wrong link in an earlier e-= mail. In that document, the key is H(A1), as described in section 5.12 - i.e., ha= sh(username:realm:password). (Section 5.12 is poorly worded, because there= are two different versions of A1 - but in either case, what the database h= as to store is exactly hash(username:realm:password).) The problem is that I do not think that we can use the "classic" HMAC-SHA a= pproach with a salt word, or a shared secret, as the keys for the HMAC func= tions - because then we have an immediate problem: how the client (person o= r application) will know that salt value or the secret value ? The client a= pplication must be able to calculate the same hash key value. May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation): hmac-key =3D username:realm:password long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm. STUN-message-integrity-digest =3D HMAC-SHA256(message)[long-term-credential= s-key] (similar to the existing long-term-credentials mechanism) With this approach, we are having about the same advantages as the "salt sc= heme" has, but we do not have a problem how to distribute the "salt" or the= extra "secret" to the client application. I don't see any benefits to using HMAC for the long-term-credentials-key ov= er using SHA256(username:realm:password) directly. --_000_913383AAA69FF945B8F946018B75898A242EFAA3xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In addition to the MD5 security proble= m that Simon had mentioned in previous mails. The other problems that will = not be resolved with SHA256 are:

 

1)TURN Server has to maintain the {use= rname/realm/password} database just like the AD server which is an overhead= .

2)In a large Enterprise Network (for e= .g. consider a large service company) where NNN number of new users join, M= MM users leave every day. It seems difficult to manage this credential database on the TURN server to be in sync with the AD.

3)If each branch office in an large en= terprise network wants to deploy TURN servers, then the cost of TURN server= includes additional storage space and operational issues which may be a concern of the I.T.      &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            

4)AD server maintained in the Data Cen= ter usually has better physical security than branch offices – what i= f someone breaks into the branch office and steals all the username + password ? (I am assuming the username, password are the same creden= tials used to access other critical enterprise resources)=

 

-Tiru

 

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, March 28, 2014 4:14 AM
To: Jonathan Lennox
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] STUN hash agility

 

OK, thanks for the li= nk.

I agree that SHA256(u= sername:realm:password) is better (simpler) here than HMAC-SHA256(username:= realm:password)[username:realm:password].

I'll update our experimental implementation so it wi= ll be using SHA256 for the key storage.

 

Oleg

 

On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox <= ;jonathan@vidyo.com= > wrote:

 

On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:



On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <= ;jonathan@vidyo.com= > wrote:

 



SHA1 algorithm (and optionally SHA256 in our impleme= ntation) is used for the message digest calculation. MD5 is used totally in= dependently of SHA1 (and SHA256) for a different purpose - for the key calc= ulation (and storage). Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably,= for FIPS, it would indeed make sense. We are currently still using MD5 for= the key storage, and SHA256 only for the message digest.

 

Yes, I’m saying that we'd want to be able to u= se SHA256 for the key calculation.

 

This is partially motivated by the FIPS compliance p= roblem.

 

I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I f= ound no suggestion on the key storage and calculation algorithms.

 

That document has been replaced by = http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 — they d= ecided to re-write it as a replacement for RFC 2617, not an update to it.  Apologies if I had the wrong link in an earlier= e-mail.

 

In that document, the key is H(A1), as described in = section 5.12 — i.e., hash(username:realm:password).  (Section 5.= 12 is poorly worded, because there are two different versions of A1 —= but in either case, what the database has to store is exactly hash(username:realm:password).)



The problem is that I= do not think that we can use the "classic" HMAC-SHA approach wit= h a salt word, or a shared secret, as the keys for the HMAC functions - bec= ause then we have an immediate problem: how the client (person or application) will know that salt value or the secret val= ue ? The client application must be able to calculate the same hash key val= ue.

May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation):

hmac-key =3D username:realm:password


long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm.

 

STUN-message-integrit= y-digest =3D HMAC-SHA256(message)[long-term-credentials-key] (similar to th= e existing long-term-credentials mechanism)

With this approach, we are having about the same adv= antages as the "salt scheme" has, but we do not have a problem ho= w to distribute the "salt" or the extra "secret" to the= client application.

 

I don’t see any benefits to using HMAC for the= long-term-credentials-key over using SHA256(username:realm:password) direc= tly.

 

 

--_000_913383AAA69FF945B8F946018B75898A242EFAA3xmbrcdx10ciscoc_-- From nobody Fri Mar 28 02:56:04 2014 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 48F081A08B2 for ; Fri, 28 Mar 2014 02:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taEoeA-SNZxs for ; Fri, 28 Mar 2014 02:56:00 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 97FDD1A08A6 for ; Fri, 28 Mar 2014 02:56:00 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so4757060pab.24 for ; Fri, 28 Mar 2014 02:55:58 -0700 (PDT) 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=JyWRxCZFGmqa+Qp3GMcir+xy+/wsXflV5DazeBjNTMg=; b=n9ZrMggfTyP1G1jsAF68LTHvK2lFEJHHpF72ea9aKzR4sLMLb4/w0pdxSFMDCvR0Ub lWXQYJd/ySnNw46i8d8oLrG5iGa/96zrMWsjbO++PBhb5mDxkBWAzSibaq19/pmhQ4IC xIsdQFpgae1zyc9u7+ToOJq0AQjhzfAACK7uxwIRmrkY6+sW1LPd3qowO6jaLEIKY3V5 phNKDBxaxPEAF7EnXG91jqLuKl564UWsAxuvBPIrWzLw88JF6glyI9zPjVernxP8N7kP P6ljzmwBNTvviP03Z4lKWsW8vg+spSmjHwJyUtZpvc6IRvhGcFSKBk+E5v7pn4ViOn+Z 3W+A== MIME-Version: 1.0 X-Received: by 10.68.178.1 with SMTP id cu1mr7550188pbc.34.1396000558587; Fri, 28 Mar 2014 02:55:58 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 28 Mar 2014 02:55:58 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> Date: Fri, 28 Mar 2014 02:55:58 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b86f76a66a5f104f5a7b507 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FLTwJ5Pt8T7-FfAwi4puibf917w Cc: Jonathan Lennox , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 09:56:03 -0000 --047d7b86f76a66a5f104f5a7b507 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru I hope that those problems can be mostly addressed by the new OAuth mechanism for TURN. Regards, Oleg On Fri, Mar 28, 2014 at 2:16 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > In addition to the MD5 security problem that Simon had mentioned in > previous mails. The other problems that will not be resolved with SHA256 > are: > > > > 1)TURN Server has to maintain the {username/realm/password} database just > like the AD server which is an overhead. > > 2)In a large Enterprise Network (for e.g. consider a large service > company) where NNN number of new users join, MMM users leave every day. It > seems difficult to manage this credential database on the TURN server to be > in sync with the AD. > > 3)If each branch office in an large enterprise network wants to deploy > TURN servers, then the cost of TURN server includes additional storage > space and operational issues which may be a concern of the > I.T. > > > 4)AD server maintained in the Data Center usually has better physical > security than branch offices - what if someone breaks into the branch > office and steals all the username + password ? (I am assuming the > username, password are the same credentials used to access other critical > enterprise resources) > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenko > *Sent:* Friday, March 28, 2014 4:14 AM > *To:* Jonathan Lennox > *Cc:* Simon Perreault; tram@ietf.org > > *Subject:* Re: [tram] STUN hash agility > > > > OK, thanks for the link. > > I agree that SHA256(username:realm:password) is better (simpler) here than > HMAC-SHA256(username:realm:password)[username:realm:password]. > > I'll update our experimental implementation so it will be using SHA256 for > the key storage. > > > > Oleg > > > > On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox > wrote: > > > > On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko wrote: > > > > On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox > wrote: > > > > > > SHA1 algorithm (and optionally SHA256 in our implementation) is used > for the message digest calculation. MD5 is used totally independently of > SHA1 (and SHA256) for a different purpose - for the key calculation (and > storage). Are you suggesting usage of SHA256 for the key calculation, too > (in place of MD5) ? Probably, for FIPS, it would indeed make sense. We are > currently still using MD5 for the key storage, and SHA256 only for the > message digest. > > > > Yes, I'm saying that we'd want to be able to use SHA256 for the key > calculation. > > > > This is partially motivated by the FIPS compliance problem. > > > > I checked the document > http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I > found no suggestion on the key storage and calculation algorithms. > > > > That document has been replaced by > http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 -- they decided > to re-write it as a replacement for RFC 2617, not an update to it. > Apologies if I had the wrong link in an earlier e-mail. > > > > In that document, the key is H(A1), as described in section 5.12 -- i.e., > hash(username:realm:password). (Section 5.12 is poorly worded, because > there are two different versions of A1 -- but in either case, what the > database has to store is exactly hash(username:realm:password).) > > > > The problem is that I do not think that we can use the "classic" > HMAC-SHA approach with a salt word, or a shared secret, as the keys for the > HMAC functions - because then we have an immediate problem: how the client > (person or application) will know that salt value or the secret value ? The > client application must be able to calculate the same hash key value. > > May be I am missing something (I am not a security expert), but if we do > want to use HMAC-SHA256 for the keys, then I see only one realistic > approach (or a variation): > > hmac-key = username:realm:password > > > long-term-credentials-key = HMAC-SHA256(hmac-key)[hmac-key], where > hmac-key is used both as the key and as the input string to the HMAC > algorithm. > > > > STUN-message-integrity-digest = > HMAC-SHA256(message)[long-term-credentials-key] (similar to the existing > long-term-credentials mechanism) > > With this approach, we are having about the same advantages as the "salt > scheme" has, but we do not have a problem how to distribute the "salt" or > the extra "secret" to the client application. > > > > I don't see any benefits to using HMAC for the long-term-credentials-key > over using SHA256(username:realm:password) directly. > > > > > --047d7b86f76a66a5f104f5a7b507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

I hope that those problems = can be mostly addressed by the new OAuth mechanism for TURN.

R= egards,
Oleg


On Fri, Mar 28, 2014 at 2:16 AM, Tirumaleswar Reddy (tireddy) <tireddy@cis= co.com> wrote:

In addition to the MD5 security problem that Simon had mentio= ned in previous mails. The other problems that will not be resolved with SH= A256 are:

 

1)TURN Server has to maintain the {username/realm/password} d= atabase just like the AD server which is an overhead.<= /p>

2)In a large Enterprise Network (for e.g. consider a large se= rvice company) where NNN number of new users join, MMM users leave every da= y. It seems difficult to manage this credential database on the TURN server to be in sync with the AD.

3)If each branch office in an large enterprise network wants = to deploy TURN servers, then the cost of TURN server includes additional st= orage space and operational issues which may be a concern of the I.T.      &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            

4)AD server maintained in the Data Center usually has better = physical security than branch offices – what if someone breaks into t= he branch office and steals all the username + password ? (I am assuming the username, password are the same credential= s used to access other critical enterprise resources)<= /p>

 

-Tiru

 

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, March 28, 2014 4:14 AM
To: Jonathan Lennox
Cc: Simon Perreault; tram@ietf.org


Subject: Re: [tram] STUN hash agility

 

OK, thanks for the li= nk.

I agree that SHA256(u= sername:realm:password) is better (simpler) here than HMAC-SHA256(username:= realm:password)[username:realm:password].

I'll update our experimental implementation so i= t will be using SHA256 for the key storage.

 

Oleg

 <= /p>

On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox <= ;jonathan@vidyo.com= > wrote:

 

On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:



On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <= ;jonathan@vidyo.com= > wrote:

 



SHA1 algorithm (and optionally SHA256 in our impleme= ntation) is used for the message digest calculation. MD5 is used totally in= dependently of SHA1 (and SHA256) for a different purpose - for the key calc= ulation (and storage). Are you suggesting usage of SHA256 for the key calculation, too (in place of MD5) ? Probably,= for FIPS, it would indeed make sense. We are currently still using MD5 for= the key storage, and SHA256 only for the message digest.

 

Yes, I’m saying that we'd want to be able = to use SHA256 for the key calculation.

 

This is partially motivated by the FIPS compliance p= roblem.

 

I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I f= ound no suggestion on the key storage and calculation algorithms.=

 

That document has been replaced by = http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 — they d= ecided to re-write it as a replacement for RFC 2617, not an update to it.  Apologies if I had the wrong link in an earlier= e-mail.

 

In that document, the key is H(A1), as described in = section 5.12 — i.e., hash(username:realm:password).  (Section 5.= 12 is poorly worded, because there are two different versions of A1 —= but in either case, what the database has to store is exactly hash(username:realm:password).)



The problem is that I= do not think that we can use the "classic" HMAC-SHA approach wit= h a salt word, or a shared secret, as the keys for the HMAC functions - bec= ause then we have an immediate problem: how the client (person or application) will know that salt value or the secret val= ue ? The client application must be able to calculate the same hash key val= ue.

May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation):

hmac-key =3D username:realm:password


long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm.

 

STUN-message-integrit= y-digest =3D HMAC-SHA256(message)[long-term-credentials-key] (similar to th= e existing long-term-credentials mechanism)

With this approach, we are having about the same adv= antages as the "salt scheme" has, but we do not have a problem ho= w to distribute the "salt" or the extra "secret" to the= client application.

 

I don’t see any benefits to using HMAC for the= long-term-credentials-key over using SHA256(username:realm:password) direc= tly.

 

 


--047d7b86f76a66a5f104f5a7b507-- From nobody Fri Mar 28 03:44:35 2014 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 3FE351A04B7 for ; Fri, 28 Mar 2014 03:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, 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 h8edZifghu4F for ; Fri, 28 Mar 2014 03:44:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58C1A0301 for ; Fri, 28 Mar 2014 03:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22344; q=dns/txt; s=iport; t=1396003467; x=1397213067; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=whnU00//47lcU3j9fmFeKdbVXJ9W1v5Y3OqE7bqMNTU=; b=Ntkiu64KuGTsjw6EAaHlTIwVi05U/ZxDHTICke3rmX7j6bpIkLEq/gsZ HkVqclVNAilAALv3SGtAyG7rLT4kYoagYxXXhBzJcawMy29dY0t5ESGO2 PqHAwaOF5RxmY7kPmn8gYRIaedU8KjBLLmrJoXbR9nzNzKMV1KqnNkaH6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFAD9SNVOtJXG+/2dsb2JhbABZgkJEO1e5d4h2gRsWdIIlAQEBBC0+DhACAQgOAwQBAQsOCAcHIREUCQgBAQQOBQiHXQMRDcoeDYcvF4xegVQYMQYBBhKDDIEUBJZggyCLOIVKgzCBakE X-IronPort-AV: E=Sophos;i="4.97,750,1389744000"; d="scan'208,217";a="313536621" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 28 Mar 2014 10:44:16 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2SAiFnO003107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Mar 2014 10:44:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 28 Mar 2014 05:44:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9KZl423otf3PaqQwuSCXApnFgFzwAL3WEAAAjQTgA= Date: Fri, 28 Mar 2014 10:44:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242EFB59@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.236] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242EFB59xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kmucy9qyoQILUOA2U4N3NpqVDAI Cc: Jonathan Lennox , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 10:44:33 -0000 --_000_913383AAA69FF945B8F946018B75898A242EFB59xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, Yes, 3rd party with solve this problem. But, should first party auth be enh= anced somehow to solve the below problems ? Cheers -Tiru From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Friday, March 28, 2014 3:26 PM To: Tirumaleswar Reddy (tireddy) Cc: Jonathan Lennox; Simon Perreault; tram@ietf.org Subject: Re: [tram] STUN hash agility Hi Tiru I hope that those problems can be mostly addressed by the new OAuth mechani= sm for TURN. Regards, Oleg On Fri, Mar 28, 2014 at 2:16 AM, Tirumaleswar Reddy (tireddy) > wrote: In addition to the MD5 security problem that Simon had mentioned in previou= s mails. The other problems that will not be resolved with SHA256 are: 1)TURN Server has to maintain the {username/realm/password} database just l= ike the AD server which is an overhead. 2)In a large Enterprise Network (for e.g. consider a large service company)= where NNN number of new users join, MMM users leave every day. It seems di= fficult to manage this credential database on the TURN server to be in sync= with the AD. 3)If each branch office in an large enterprise network wants to deploy TURN= servers, then the cost of TURN server includes additional storage space an= d operational issues which may be a concern of the I.T. 4)AD server maintained in the Data Center usually has better physical secur= ity than branch offices - what if someone breaks into the branch office and= steals all the username + password ? (I am assuming the username, password= are the same credentials used to access other critical enterprise resource= s) -Tiru From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Oleg Moskalenko Sent: Friday, March 28, 2014 4:14 AM To: Jonathan Lennox Cc: Simon Perreault; tram@ietf.org Subject: Re: [tram] STUN hash agility OK, thanks for the link. I agree that SHA256(username:realm:password) is better (simpler) here than = HMAC-SHA256(username:realm:password)[username:realm:password]. I'll update our experimental implementation so it will be using SHA256 for = the key storage. Oleg On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox > wrote: On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko > wrote: On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox > wrote: SHA1 algorithm (and optionally SHA256 in our implementation) is used for th= e message digest calculation. MD5 is used totally independently of SHA1 (an= d SHA256) for a different purpose - for the key calculation (and storage). = Are you suggesting usage of SHA256 for the key calculation, too (in place o= f MD5) ? Probably, for FIPS, it would indeed make sense. We are currently s= till using MD5 for the key storage, and SHA256 only for the message digest. Yes, I'm saying that we'd want to be able to use SHA256 for the key calcula= tion. This is partially motivated by the FIPS compliance problem. I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-diges= t-update-05 and I found no suggestion on the key storage and calculation al= gorithms. That document has been replaced by http://tools.ietf.org/html/draft-ietf-ht= tpauth-digest-05 - they decided to re-write it as a replacement for RFC 261= 7, not an update to it. Apologies if I had the wrong link in an earlier e-= mail. In that document, the key is H(A1), as described in section 5.12 - i.e., ha= sh(username:realm:password). (Section 5.12 is poorly worded, because there= are two different versions of A1 - but in either case, what the database h= as to store is exactly hash(username:realm:password).) The problem is that I do not think that we can use the "classic" HMAC-SHA a= pproach with a salt word, or a shared secret, as the keys for the HMAC func= tions - because then we have an immediate problem: how the client (person o= r application) will know that salt value or the secret value ? The client a= pplication must be able to calculate the same hash key value. May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation): hmac-key =3D username:realm:password long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm. STUN-message-integrity-digest =3D HMAC-SHA256(message)[long-term-credential= s-key] (similar to the existing long-term-credentials mechanism) With this approach, we are having about the same advantages as the "salt sc= heme" has, but we do not have a problem how to distribute the "salt" or the= extra "secret" to the client application. I don't see any benefits to using HMAC for the long-term-credentials-key ov= er using SHA256(username:realm:password) directly. --_000_913383AAA69FF945B8F946018B75898A242EFB59xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 

Yes, 3rd party with solve this problem.= But, should first party auth be enhanced somehow to solve the below proble= ms ?

 

Cheers

-Tiru=

 <= /p>

From: Oleg Mos= kalenko [mailto:mom040267@gmail.com]
Sent: Friday, March 28, 2014 3:26 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; Simon Perreault; tram@ietf.org
Subject: Re: [tram] STUN hash agility

 

Hi Tiru

I hope that those pro= blems can be mostly addressed by the new OAuth mechanism for TURN.

Regards,
Oleg

 

On Fri, Mar 28, 2014 at 2:16 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

In addition to the MD5 security problem that Simon had mentio= ned in previous mails. The other problems that will not be resolved with SH= A256 are:

 

1)TURN Server has to maintain the {username/realm/password} d= atabase just like the AD server which is an overhead.

2)In a large Enterprise Network (for e.g. consider a large se= rvice company) where NNN number of new users join, MMM users leave every da= y. It seems difficult to manage this credential database on the TURN server to be in sync with the AD.

3)If each branch office in an large enterprise network wants = to deploy TURN servers, then the cost of TURN server includes additional st= orage space and operational issues which may be a concern of the I.T.          &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;        

4)AD server maintained in the Data Center usually has better = physical security than branch offices – what if someone breaks into t= he branch office and steals all the username + password ? (I am assuming the username, password are the same credentials used to access= other critical enterprise resources)

 

-Tiru

 

 

OK, thanks for the link.

I agree that SHA256(username:realm:password) is better (simpler) here th= an HMAC-SHA256(username:realm:password)[username:realm:password].

I'll update our experimental implementation so it will be using SH= A256 for the key storage.

 

Oleg

 

On Thu, Mar 27, 2014 at 3:34 PM, Jonathan Lennox <jonathan@vidyo.com> wrote= :

 

On Mar 27, 2014, at 6:26 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:<= o:p>

 

On Wed, Mar 26, 2014 at 9:08 AM, Jonathan Lennox <jonathan@vidyo.com> wrote= :

 

 

SHA1 algorithm (and optionally SHA256 in our implementation) is us= ed for the message digest calculation. MD5 is used totally independently of= SHA1 (and SHA256) for a different purpose - for the key calculation (and storage). Are you suggesting usage of SHA25= 6 for the key calculation, too (in place of MD5) ? Probably, for FIPS, it w= ould indeed make sense. We are currently still using MD5 for the key storag= e, and SHA256 only for the message digest.

 

Yes, I’m saying that we'd want to be able to use SHA256 for = the key calculation.

 

This is partially motivated by the FIPS compliance problem.

 

I checked the document http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-05 and I f= ound no suggestion on the key storage and calculation algorithms.

 

That document has been replaced by http://tools.i= etf.org/html/draft-ietf-httpauth-digest-05 — they decided to re-write it as a replacement for RFC 2617, not an = update to it.  Apologies if I had the wrong link in an earlier e-mail.=

 

In that document, the key is H(A1), as described in section 5.12 &= #8212; i.e., hash(username:realm:password).  (Section 5.12 is poorly w= orded, because there are two different versions of A1 — but in either case, what the database has to store is exactl= y hash(username:realm:password).)

 

The problem is that I do not think that we can use the "classic&quo= t; HMAC-SHA approach with a salt word, or a shared secret, as the keys for = the HMAC functions - because then we have an immediate problem: how the client (person or application) will know that salt value = or the secret value ? The client application must be able to calculate the = same hash key value.

May be I am missing something (I am not a security expert), but if we do wa= nt to use HMAC-SHA256 for the keys, then I see only one realistic approach = (or a variation):

hmac-key =3D username:realm:password


long-term-credentials-key =3D HMAC-SHA256(hmac-key)[hmac-key], where hmac-k= ey is used both as the key and as the input string to the HMAC algorithm.

 

STUN-message-integrity-digest =3D HMAC-SHA256(message)[long-term-credent= ials-key] (similar to the existing long-term-credentials mechanism)

With this approach, we are having about the same advantages as the= "salt scheme" has, but we do not have a problem how to distribut= e the "salt" or the extra "secret" to the client application.

 

I don’t see any benefits to using HMAC for the long-term-cre= dentials-key over using SHA256(username:realm:password) directly.

 

 

 

--_000_913383AAA69FF945B8F946018B75898A242EFB59xmbrcdx10ciscoc_-- From nobody Fri Mar 28 05:47:08 2014 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 9680E1A063B for ; Fri, 28 Mar 2014 05:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VNiJxTM5rEcn for ; Fri, 28 Mar 2014 05:47:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0747B1A063A for ; Fri, 28 Mar 2014 05:47:04 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:14e0:aba7:5933:f5db]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94222403FC; Fri, 28 Mar 2014 08:47:01 -0400 (EDT) Message-ID: <53356F45.4020607@viagenie.ca> Date: Fri, 28 Mar 2014 08:47:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko , Jonathan Lennox References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4ocUJPHI7r07HoFf3LXQtQ4QVVQ Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 12:47:06 -0000 Oooooh! I love playing the devil's advocate... :) Le 2014-03-28 05:16, Tirumaleswar Reddy (tireddy) a écrit : > 1)TURN Server has to maintain the {username/realm/password} database > just like the AD server which is an overhead. Are you assuming that the TURN server cannot query the AD server instead of maintaining a duplicate database? In any case, database replication is easy and well understood. You need to have *lots* of accounts for e.g. dead-simple MySQL replication to not be sufficient. > 2)In a large Enterprise Network (for e.g. consider a large service > company) where NNN number of new users join, MMM users leave every day. > It seems difficult to manage this credential database on the TURN server > to be in sync with the AD. Really? MySQL replication (for example) is dead simple. > 3)If each branch office in an large enterprise network wants to deploy > TURN servers, then the cost of TURN server includes additional storage > space and operational issues which may be a concern of the > I.T. I doubt this very much. You would need *lots* of user accounts for the password database to not fit on any regular-sized hard drive. About operations: once again, database replication is well understood and very common. > 4)AD server maintained in the Data Center usually has better physical > security than branch offices – what if someone breaks into the branch > office and steals all the username + password ? (I am assuming the > username, password are the same credentials used to access other > critical enterprise resources) Now this I totally buy. We need something better than MD5(username:realm:password). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 28 07:40:21 2014 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 E41C61A06D3 for ; Fri, 28 Mar 2014 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cpTnmgwKxZVP for ; Fri, 28 Mar 2014 07:40:17 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8701A0639 for ; Fri, 28 Mar 2014 07:40:17 -0700 (PDT) X-Note-AR-ScanTimeLocal: 3/28/2014 10:40:11 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-36/SG:2 3/28/2014 10:39:28 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.963576 p=-0.984876 Source White X-Signature-Violations: 0-0-0-3622-c X-Note-419: 0 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 3/28/2014 10:39:59 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 109993174; Fri, 28 Mar 2014 10:40:11 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Fri, 28 Mar 2014 09:40:10 -0500 From: Jonathan Lennox To: Simon Perreault Thread-Topic: [tram] STUN hash agility Thread-Index: Ac9KZl42pDvk2TE2/kuLWQAd3HLhsAAR1rCAAAPzowA= Date: Fri, 28 Mar 2014 14:40:10 +0000 Message-ID: <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> <53356F45.4020607@viagenie.ca> In-Reply-To: <53356F45.4020607@viagenie.ca> 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="Windows-1252" Content-ID: <7BAB2902F628BB49AC52527E6F869E37@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tVHfcV9NEppymoGkSBExx9A3KdQ Cc: Oleg Moskalenko , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 14:40:19 -0000 On Mar 28, 2014, at 8:47 AM, Simon Perreault = wrote: >> 4)AD server maintained in the Data Center usually has better physical >> security than branch offices =96 what if someone breaks into the branch >> office and steals all the username + password ? (I am assuming the >> username, password are the same credentials used to access other >> critical enterprise resources) >=20 > Now this I totally buy. We need something better than > MD5(username:realm:password). If TRAM wants to keep TURN password database compatibility with rfc2617bis,= we=92ll have to keep the key generation hash the same, since draft-ietf-ht= tpauth-digest uses SHA256(username:realm:password). That said, the security flaws that you have correctly identified with that = scheme (notably, unsalted passwords) are exactly why some SIPCORE members w= ere advocating moving away from 2617bis when updating SIP authentication. I think the useful requirement (and this is a point that should probably be= in the tram-auth-requirements draft) is to be able to keep password databa= se compatibility with *SIP* as it defines new mechanisms, not necessarily w= ith HTTP. = From nobody Fri Mar 28 11:46:15 2014 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 BE58E1A0941 for ; Fri, 28 Mar 2014 11:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7IawPHmS1V7 for ; Fri, 28 Mar 2014 11:46:10 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 568961A073E for ; Fri, 28 Mar 2014 11:46:10 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so5392484pbc.30 for ; Fri, 28 Mar 2014 11:46:08 -0700 (PDT) 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=jbAnLkOnTAx0xEroB6EDIiz2/s9ka7bDVRqGP6JBHrg=; b=RZt6WL6zQrIWavGEj8nZzhOzryrIB2OmEi+cr6LC9irUMXs4anN6KbSCMGE5cW4jhn E5aZTlLf9wxYkAGBaxea1lTd8z+3WRc34QSADtSf1K+d7fWQVcL7ZC1QFpCKNlZYBTvJ yBFO8phcWJ7vsJaMim8yH0G4HEMTHeGNCfA0saIX9qcVrcvAK18hx/tvJinbE+bA6h2w 2MQGHeHCLwNmG6OptLm+c+Vodq8sesG73zMQSO8pkufY3PlrFJvHLIGACm/V/Byrltgp AK4tqAIu01RrSD23b/a9Mw988dZ4H3RKfuHQkqtOzxdSIHeGCTu8Rlo7rh0ESSfXbd2a kEOw== MIME-Version: 1.0 X-Received: by 10.68.237.133 with SMTP id vc5mr10280060pbc.92.1396032368138; Fri, 28 Mar 2014 11:46:08 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 28 Mar 2014 11:46:08 -0700 (PDT) In-Reply-To: <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> <53356F45.4020607@viagenie.ca> <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> Date: Fri, 28 Mar 2014 11:46:08 -0700 Message-ID: From: Oleg Moskalenko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7b338f1d65e2a104f5af1d0f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-LpUFQ2dKswQ1OqaAfkygK7wj8I Cc: Simon Perreault , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 18:46:13 -0000 --047d7b338f1d65e2a104f5af1d0f Content-Type: text/plain; charset=ISO-8859-1 see below inline: On Fri, Mar 28, 2014 at 7:40 AM, Jonathan Lennox wrote: > > On Mar 28, 2014, at 8:47 AM, Simon Perreault > wrote: > > >> 4)AD server maintained in the Data Center usually has better physical > >> security than branch offices - what if someone breaks into the branch > >> office and steals all the username + password ? (I am assuming the > >> username, password are the same credentials used to access other > >> critical enterprise resources) > > > > Now this I totally buy. We need something better than > > MD5(username:realm:password). > > If TRAM wants to keep TURN password database compatibility with > rfc2617bis, we'll have to keep the key generation hash the same, since > draft-ietf-httpauth-digest uses SHA256(username:realm:password). > > That said, the security flaws that you have correctly identified with that > scheme (notably, unsalted passwords) I cannot agree that the scheme HASH(username:realm:password) can be regarded as "unsalted passwords". An unsalted password would be something like: 1) HASH(password) 2) HMAC-HASH()[password] The scheme HASH(username:realm:password) has good qualities of a salted password: 1) If two users of the same realm have the same password then their hashes will be different; 2) If two users of different realms have the same name and the same password, their hashes will be different. 3) Computationally, an attack is difficult. Basically, all records in the database will have different hashes. Computationally, an attack will be about as difficult as an attack on a "salted" password database. The problem with "salted" passwords is that the client must know that "salt". I have no idea how to make that happen. I think that if we do want to deal with a hashed password database, then SHA256(username:realm:password) is a good scheme. > are exactly why some SIPCORE members were advocating moving away from > 2617bis when updating SIP authentication. > > I think the useful requirement (and this is a point that should probably > be in the tram-auth-requirements draft) is to be able to keep password > database compatibility with *SIP* as it defines new mechanisms, not > necessarily with HTTP. > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b338f1d65e2a104f5af1d0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
see below inline:

<= br>
On Fri, Mar 28, 2014 at 7:40 AM, Jonathan Len= nox <jonathan@vidyo.com> wrote:

On Mar 28, 2014, at 8:47 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:

>> 4)AD server maintained in the Data Center usually has better physi= cal
>> security than branch offices – what if someone breaks into t= he branch
>> office and steals all the username + password ? (I am assuming the=
>> username, password are the same credentials used to access other >> critical enterprise resources)
>
> Now this I totally buy. We need something better than
> MD5(username:realm:password).

If TRAM wants to keep TURN password database compatibility with rfc26= 17bis, we’ll have to keep the key generation hash the same, since dra= ft-ietf-httpauth-digest uses SHA256(username:realm:password).

That said, the security flaws that you have correctly identified with that = scheme (notably, unsalted passwords)

I can= not agree that the scheme HASH(username:realm:password) can be regarded as = "unsalted passwords". An unsalted password would be something lik= e:

1) HASH(password)
2) HMAC-HASH(<some_long_s= tring>)[password]

The scheme HASH(username:realm:passw= ord) has good qualities of a salted password:

1) If two u= sers of the same realm have the same password then their hashes will be dif= ferent;
2) If two users of different realms have the same name and the s= ame password, their hashes will be different.
3) Computationa= lly, an attack is difficult.

Basically, all re= cords in the database will have different hashes. Computationally, an attac= k will be about as difficult as an attack on a "salted" password = database.

The problem with "salted" passwords is that the cl= ient must know that "salt". I have no idea how to make that happe= n.

I think that if we do want to deal with a hashed passw= ord database, then SHA256(username:realm:password) is a good scheme.



 
are exac= tly why some SIPCORE members were advocating moving away from 2617bis when = updating SIP authentication.

I think the useful requirement (and this is a point that should probably be= in the tram-auth-requirements draft) is to be able to keep password databa= se compatibility with *SIP* as it defines new mechanisms, not necessarily w= ith HTTP.
___________________________________= ____________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b338f1d65e2a104f5af1d0f-- From nobody Fri Mar 28 12:03:51 2014 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 A9B751A095B for ; Fri, 28 Mar 2014 12:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oObKXX-wXHdY for ; Fri, 28 Mar 2014 12:03:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D4F571A0961 for ; Fri, 28 Mar 2014 12:03:41 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:59:db2b:61af:a63c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5E3FD40D17; Fri, 28 Mar 2014 15:03:39 -0400 (EDT) Message-ID: <5335C78B.9020802@viagenie.ca> Date: Fri, 28 Mar 2014 15:03:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko , Jonathan Lennox References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> <53356F45.4020607@viagenie.ca> <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PHem83wbRvEwZIibPjNbTwxfaYo Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN hash agility 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, 28 Mar 2014 19:03:47 -0000 Le 2014-03-28 14:46, Oleg Moskalenko a écrit : > The problem with "salted" passwords is that the client must know that > "salt". I have no idea how to make that happen. I suppose we could put the salt in a new STUN attribute. I agree that the addition of salt would not change much. The only two advantages to salt that I can see are: - "username:realm" might not provide enough entropy compared to salt. - Across different servers, the same "username:realm" would be hashed according to the passwords only. No entropy at all. In particular, using the same password would result in the same hash. I don't know how strong those arguments are... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 28 17:26:46 2014 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 618851A03FA for ; Fri, 28 Mar 2014 17:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc13hmm0REtm for ; Fri, 28 Mar 2014 17:26:42 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E55C01A03F7 for ; Fri, 28 Mar 2014 17:26:41 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kx10so191137pab.33 for ; Fri, 28 Mar 2014 17:26:39 -0700 (PDT) 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=zjDh45gmEZeAAZHxIp6pLKBn+j7bcaOadtlSQz2Itco=; b=t1b3qJyV6MoCVW7l0EuLQ4wxgpqD9j7Rxz9Pw0Y5O7c5bJHz4aHUaW6cyRG6uvtIWk YW9n7c0V+PfdEc+w28TCKwhu8hwXYaHFON35iNbW1MNilFLme6qcg+lsgwHmnWakDky+ qWg2XwHxgfJtzsxjEvIaHfb+Ytn7M9TRA7T4DUe5Judaa3eOLV0aqoqaKBLCaWA6OkK4 KrAwdvhOdrjsUBHT36SZr3hhKMJXAF1Lj9Hg+BYez6znf1+58dKteCAs0c9tdt3+Zt3Z VqHTgfw/qwirtZV9APer2sWUaOUHSTOe8nBpvUsGxPzrJlHsoZXtK+iodkPtRhozFafU X/3Q== MIME-Version: 1.0 X-Received: by 10.68.237.99 with SMTP id vb3mr11667461pbc.76.1396052799797; Fri, 28 Mar 2014 17:26:39 -0700 (PDT) Received: by 10.68.147.131 with HTTP; Fri, 28 Mar 2014 17:26:39 -0700 (PDT) In-Reply-To: <5335C78B.9020802@viagenie.ca> References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> <53356F45.4020607@viagenie.ca> <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> <5335C78B.9020802@viagenie.ca> Date: Fri, 28 Mar 2014 17:26:39 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b33c8de383f6d04f5b3df48 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NH-leIoD4lPAP2M1z_qYT2TY0BU Cc: Jonathan Lennox , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN hash agility 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, 29 Mar 2014 00:26:43 -0000 --047d7b33c8de383f6d04f5b3df48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please see inline: On Fri, Mar 28, 2014 at 12:03 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-28 14:46, Oleg Moskalenko a =E9crit : > > The problem with "salted" passwords is that the client must know that > > "salt". I have no idea how to make that happen. > > I suppose we could put the salt in a new STUN attribute. > > I agree that the addition of salt would not change much. The only two > advantages to salt that I can see are: > > - "username:realm" might not provide enough entropy compared to salt. > That concern might be valid only when a cryptographically weak hash function is used. If the function is good enough (like SHA256) then any minor difference in the input string must yield a new hash value as dramatically new as a totally different input. For a good hash function the difference between hash("Marissa1") and hash("Marissa2") must be as significant as the difference between hash("Alice") and hash("Bob") - and equally unpredictable. > > - Across different servers, the same "username:realm" would be hashed > according to the passwords only. No entropy at all. In particular, using > the same password would result in the same hash. > If those different servers are parts of the same realm and they are using the same user database then, as you explained before, they will be using database replication and the data will not be similar - the data will be just the same, so an attacker will have as much extra information as if the attacker would simply copy the stolen database multiple times over his hard disk. Multiple copies of the same database do not give any extra information. If the applications are different then either the realm or the password must be different, and the hash values are to be different. Oleg --047d7b33c8de383f6d04f5b3df48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Please see inline:

On Fri, Mar 28, = 2014 at 12:03 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-03-28 14:46, Oleg Moskalenko a =E9cr= it :
> The problem with "salted" passwords is tha= t the client must know that
> "salt". I have no idea how to make that happen.

I suppose we could put the salt in a new STUN attribute.

I agree that the addition of salt would not change much. The only two
advantages to salt that I can see are:

- "username:realm" might not provide enough entropy compared to s= alt.

That concern might be valid only w= hen a cryptographically weak hash function is used. If the function is good= enough (like SHA256) then any minor difference in the input string must yi= eld a new hash value as dramatically new as a totally different input. For = a good hash function the difference between hash("Marissa1") and = hash("Marissa2") must be as significant as the difference between= hash("Alice") and hash("Bob") - and equally unpredicta= ble.
=A0

- Across different servers, the same "username:realm" would be ha= shed
according to the passwords only. No entropy at all. In particular, using the same password would result in the same hash.

<= /div>
If those different servers are parts of the same realm and they a= re using the same user database then, as you explained before, they will be= using database replication and the data will not be similar - the data wil= l be just the same, so an attacker will have as much extra information as i= f the attacker would simply copy the stolen database multiple times over hi= s hard disk. Multiple copies of the same database do not give any extra inf= ormation.

If the applications are different then either the realm or t= he password must be different, and the hash values are to be different.
=
=A0
Oleg
--047d7b33c8de383f6d04f5b3df48-- From nobody Sun Mar 30 23:50:07 2014 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 EB4A51A081D for ; Sun, 30 Mar 2014 23:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] 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 1dP2La8PKQjU for ; Sun, 30 Mar 2014 23:50:02 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 288511A081E for ; Sun, 30 Mar 2014 23:50:00 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403310849558412; Mon, 31 Mar 2014 08:49:55 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , "'Martin Thomson'" References: <532AF25B.4020301@viagenie.ca> <53306635.40103@viagenie.ca> In-Reply-To: <53306635.40103@viagenie.ca> Date: Mon, 31 Mar 2014 08:49:51 +0200 Message-ID: <04fe01cf4cad$6a98dd90$3fca98b0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9Hg34pfK1NJ24QSVGkhRtBbTwMZwE/LkoA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Sir56Hxkns3tTc5yhnyeCJ9Xur0 Cc: tram@ietf.org Subject: Re: [tram] TURN server discovery (please discuss!) 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, 31 Mar 2014 06:50:06 -0000 Two comments inline below /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 24 mars 2014 18:07 Till: Martin Thomson Kopia: tram@ietf.org =C3=84mne: Re: [tram] TURN server discovery (please discuss!) Le 2014-03-24 12:58, Martin Thomson a =C3=A9crit : > Re: WPAD: This is causing HTTPBIS considerable pain. If you feel=20 > particularly masochistic, or desperate, then perhaps it can be=20 > remembered, but any attempt to use WPAD will be sorely regretted. Duly noted. [Karl] And an ISP can hardly provision WPAD, can he? > On 20 March 2014 06:51, Simon Perreault = wrote: >> Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc=20 >> for inspiration. As I understand it, that solution relies on the=20 >> client's IP address "owner" (e.g. the ISP or enterprise) to populate=20 >> the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) with=20 >> appropriate NAPTR records pointing to the network-provided TURN=20 >> server. Can this work? This is a new idea for which I have not seen = any discussion yet. [Karl] Doesn't all reverse DNS lookup methods require that the browser = finds its global ip address to begin with - for which you need a stun = server? That is the bootstrap problem (how do you find a stun server to = find the turn server) where the October discussion on the rtcweb = terminated such track. >=20 > ALTO have been covering a lot of the same ground as GEOPRIV. > draft-ietf-geopriv-res-gw-lis-discovery sits in the RFC editor's=20 > queue. It's the same mechanism. Thanks for the pointer! > That said, this is only useful to the extent that the owner of the=20 > network you are using is also the one providing the TURN service. Couldn't the NAPTR record point to a third-party TURN server? > Is this the operating assumption here? Or are there other avenues=20 > that need to be explored? Maybe, but I can't think of any. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Sun Mar 30 23:51:08 2014 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 DB67C1A096D for ; Sun, 30 Mar 2014 23:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] 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 dcD_qZFETL2y for ; Sun, 30 Mar 2014 23:51:04 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 027BE1A081D for ; Sun, 30 Mar 2014 23:51:03 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403310850598587; Mon, 31 Mar 2014 08:50:59 +0200 From: "Karl Stahl" To: "'Brandon Williams'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" , "'Prashanth Patil \(praspati\)'" , References: <913383AAA69FF945B8F946018B75898A242DB0B8@xmb-rcd-x10.cisco.com> <53302B7A.1070701@viagenie.ca> <913383AAA69FF945B8F946018B75898A242DB1D0@xmb-rcd-x10.cisco.com> <53306001.3090204@akamai.com> In-Reply-To: <53306001.3090204@akamai.com> Date: Mon, 31 Mar 2014 08:50:55 +0200 Message-ID: <04ff01cf4cad$90d539e0$b27fada0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9Hf8ukg2GIe5paSn+CEgqjd2W6hQFAJMpw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oiYVQ49TM_9TJBuSYFfY4LOKQLY Subject: Re: [tram] TURN server discovery (please discuss!) 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, 31 Mar 2014 06:51:06 -0000 I also agree with Simon's 0, 1, 2 even though I tend to call the "untrustworthy" turn server trusted... (because we use it, just like we = use the IP address and default gateway we get). Security/privacy comes in step 2, not in the discovery. /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Brandon Williams Skickat: den 24 mars 2014 17:41 Till: Tirumaleswar Reddy (tireddy); Simon Perreault; Prashanth Patil (praspati); tram@ietf.org =C4mne: Re: [tram] TURN server discovery (please discuss!) Hi Tiru, I'm not sure that it would be reasonable to expect the degree of privacy that you are describing from an auto-discovered TURN server. Even with = certs to authenticate the TURN server, you are still trusting the random = coffee shop's network provider. I think that Simon's axiom is entirely correct in this context ... don't trust the network provided server, and thus don't rely on it for = privacy. As long as the TURN client allows the user to select an appropriate = security policy, I think it's OK. --Brandon On 03/24/2014 10:53 AM, Tirumaleswar Reddy (tireddy) wrote: > Hi Simon, > > Please see inline > >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Monday, March 24, 2014 6:26 PM >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil=20 >> (praspati); tram@ietf.org >> Subject: Re: [tram] TURN server discovery (please discuss!) >> >> Le 2014-03-24 08:27, Tirumaleswar Reddy (tireddy) a =E9crit : >>> Yes, that will probably solve the problem. But how would the Mobile=20 >>> Node >> (MN) trust the TURN server provided by the network when let's say MN=20 >> is using Coffee shop WIFI ? >>> It could be a malicious TURN server provided to monitor the user=20 >>> activity. If >> certificate validation is not possible then it becomes opportunistic encryption. >> Further with this restriction, the network provided TURN server may=20 >> not be able to offer Mobility unlike the application provided TURN server. >> >> Do you trust the default gateway that is provided to you by DHCP when = >> you log on a coffee shop wi-fi? No, you don't. But you still use it.=20 >> And maybe you don't even consider this problematic. IMHO, if we dig=20 >> deep enough we'll find that this problem is basically unfixable.=20 >> There will always be an untrustworthy infrastructure layer on top of which trustworthy applications are built. >> >> I think what we need to do is: >> >> 0. Consider any network-provided TURN server as untrustworthy. This=20 >> is an axiomatic position. >> >> 1. Devise a mechanism allowing this piece of untrustworthy=20 >> infrastructure to be discovered. >> >> 2. Show how trustworthy applications can be built on top of this.=20 >> (i.e., by encrypting media streams using SRTP, DTLS, etc.) >> >> The untrustworthy TURN server will be able to know the 5-tuples=20 >> between the client and the peer. > > TURN is useful to provide privacy just like TOR. Using TOR ensures = that even if the traffic is subjected to pervasive monitoring, attacker = cannot find out the remote server with which the user is communicating. TURN = can also be used to solve the same problem. If attacker can act as TURN = server then this benefit of providing privacy will be lost. > > -Tiru > >> An untrustworthy IP router would equally be able to do it. >> But with appropriate encryption, it won't be able to discover=20 >> anything more. So this would not introduce any new attack vector = IMHO. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 31 06:39:02 2014 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 576341A09BA for ; Mon, 31 Mar 2014 06:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 P1aU_wdLjmYf for ; Mon, 31 Mar 2014 06:38:58 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC6031A09C8 for ; Mon, 31 Mar 2014 06:38:47 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:59:db2b:61af:a63c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8630540222; Mon, 31 Mar 2014 09:38:44 -0400 (EDT) Message-ID: <53396FE4.7040502@viagenie.ca> Date: Mon, 31 Mar 2014 09:38:44 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl , 'Martin Thomson' References: <532AF25B.4020301@viagenie.ca> <53306635.40103@viagenie.ca> <04fe01cf4cad$6a98dd90$3fca98b0$@stahl@intertex.se> In-Reply-To: <04fe01cf4cad$6a98dd90$3fca98b0$@stahl@intertex.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/uLJTbPzTJTdKhhBLLDAYpKau4HE Cc: tram@ietf.org Subject: Re: [tram] TURN server discovery (please discuss!) 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, 31 Mar 2014 13:39:00 -0000 Le 2014-03-31 02:49, Karl Stahl a écrit : > [Karl] And an ISP can hardly provision WPAD, can he? Right, WPAD would not work for an ISP. >> On 20 March 2014 06:51, Simon Perreault wrote: >>> Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc >>> for inspiration. As I understand it, that solution relies on the >>> client's IP address "owner" (e.g. the ISP or enterprise) to populate >>> the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) with >>> appropriate NAPTR records pointing to the network-provided TURN >>> server. Can this work? This is a new idea for which I have not seen any discussion yet. > > [Karl] Doesn't all reverse DNS lookup methods require that the browser finds its global ip address to begin with - for which you need a stun server? That is the bootstrap problem (how do you find a stun server to find the turn server) where the October discussion on the rtcweb terminated such track. This provides some inspiration: http://tools.ietf.org/html/draft-ietf-geopriv-res-gw-lis-discovery-08#section-4.1 I suppose that the browser-default or application-provided STUN server could be used for bootstrapping. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 31 06:57:16 2014 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 7F4151A6EED for ; Mon, 31 Mar 2014 06:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 55bgqi-pfDe6 for ; Mon, 31 Mar 2014 06:57:13 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 43BED1A6EE2 for ; Mon, 31 Mar 2014 06:57:13 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C0C4C2855D for ; Mon, 31 Mar 2014 13:57:09 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id AF85B2855A for ; Mon, 31 Mar 2014 13:57:09 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 99A17203B for ; Mon, 31 Mar 2014 13:57:09 +0000 (GMT) Message-ID: <53397435.9070503@akamai.com> Date: Mon, 31 Mar 2014 09:57:09 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> <53356F45.4020607@viagenie.ca> <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> <5335C78B.9020802@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W8w9hetpV1-jPC7ecluab_zi6kg Subject: Re: [tram] STUN hash agility 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, 31 Mar 2014 13:57:14 -0000 On 03/28/2014 08:26 PM, Oleg Moskalenko wrote: > > On Fri, Mar 28, 2014 at 12:03 PM, Simon Perreault wrote: >> - Across different servers, the same "username:realm" would be hashed >> according to the passwords only. No entropy at all. In particular, using >> the same password would result in the same hash. > > > If those different servers are parts of the same realm and they are > using the same user database then, as you explained before, they will be > using database replication and the data will not be similar - the data > will be just the same, so an attacker will have as much extra > information as if the attacker would simply copy the stolen database > multiple times over his hard disk. Multiple copies of the same database > do not give any extra information. I think that Simon's point is that, without some entropy, access to the result of the hash on one machine for one session compromises the user's credentials for future sessions, even if the attacker has not determined the user's actual password. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Mar 31 09:13:40 2014 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 771261A0892 for ; Mon, 31 Mar 2014 09:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 mFU3hr5zCNBC for ; Mon, 31 Mar 2014 09:13:36 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF751A088C for ; Mon, 31 Mar 2014 09:13:36 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id rp16so8380050pbb.40 for ; Mon, 31 Mar 2014 09:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PMp3U2FMAot2zlcUX0WQ3pfqHCBVsfHoM0kWAJSFpxA=; b=Cm4WLASuyD61NIc5WPUACy/XSERUsm+BzdpMnU83JmtPUV+nhPGLlQoWj+Bnx6ZNWL d3iu3rMfR6YsWezN/BZI5xLi5DF+XRQJnQY16sTfl7E1k+3lbCq+nF77M5nNK6mkZZo/ uzoCVZsjUE31Ply0npP9H0ERhhGLieTTttWZasMY6JYdI+ZHmOnphrFukqx91ToSFPWJ YVEENx41iuU9tQ567nef7F4MJCGQ9G7OrvUV/VSg3yf23Fge1rZ3lYf9oIWxQJlJAzx9 b8qpdSFugJMW2sBUffVuJJ6EY486VVA6aw7Taf2EPKcYyS5S9GU4ap1HUb1wj0C5qqvO VnFw== X-Received: by 10.66.141.12 with SMTP id rk12mr4402020pab.152.1396282413076; Mon, 31 Mar 2014 09:13:33 -0700 (PDT) Received: from [10.174.90.179] (106.sub-70-197-7.myvzw.com. [70.197.7.106]) by mx.google.com with ESMTPSA id iu10sm44236662pbd.71.2014.03.31.09.13.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 09:13:31 -0700 (PDT) References: <913383AAA69FF945B8F946018B75898A242EFAA3@xmb-rcd-x10.cisco.com> <53356F45.4020607@viagenie.ca> <15E114D0-BA3D-4020-9935-7AED30E2774B@vidyo.com> <5335C78B.9020802@viagenie.ca> <53397435.9070503@akamai.com> Mime-Version: 1.0 (1.0) In-Reply-To: <53397435.9070503@akamai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9623DAB0-3900-4886-ADBD-49BB7F9D0735@gmail.com> X-Mailer: iPhone Mail (11B651) From: Oleg Moskalenko Date: Mon, 31 Mar 2014 09:13:30 -0700 To: Brandon Williams Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wUy59IYbz_XbD-wDGMOBqWvgufU Cc: "tram@ietf.org" Subject: Re: [tram] STUN hash agility 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, 31 Mar 2014 16:13:37 -0000 Yes that's a valid concern. Oleg Sent from my iPhone > On Mar 31, 2014, at 6:57 AM, Brandon Williams wrote: >=20 >> On 03/28/2014 08:26 PM, Oleg Moskalenko wrote: >>=20 > > On Fri, Mar 28, 2014 at 12:03 PM, Simon Perreault wrote: >>> - Across different servers, the same "username:realm" would be hashed= >>> according to the passwords only. No entropy at all. In particular, us= ing >>> the same password would result in the same hash. >>=20 >>=20 >> If those different servers are parts of the same realm and they are >> using the same user database then, as you explained before, they will be >> using database replication and the data will not be similar - the data >> will be just the same, so an attacker will have as much extra >> information as if the attacker would simply copy the stolen database >> multiple times over his hard disk. Multiple copies of the same database >> do not give any extra information. >=20 > I think that Simon's point is that, without some entropy, access to the re= sult of the hash on one machine for one session compromises the user's crede= ntials for future sessions, even if the attacker has not determined the user= 's actual password. >=20 > --Brandon >=20 > --=20 > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 31 14:01:20 2014 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 14BF11A70FF for ; Mon, 31 Mar 2014 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.955 X-Spam-Level: **** X-Spam-Status: No, score=4.955 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_DISCOUNT=4.455, MSGID_MULTIPLE_AT=1] 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 hn31rvW2ZfqC for ; Mon, 31 Mar 2014 14:01:16 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id E1DC31A7035 for ; Mon, 31 Mar 2014 14:01:14 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403312301080079; Mon, 31 Mar 2014 23:01:08 +0200 From: "Karl Stahl" To: "'Prashanth Patil \(praspati\)'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" References: <913383AAA69FF945B8F946018B75898A242DA18A@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Mon, 31 Mar 2014 23:01:09 +0200 Message-ID: <059901cf4d24$578a5a40$069f0ec0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9FJbsFTBkECL+eSXabbZ2qD46QCAAAeecwAYhuP1AAdoDgAA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Z3heIRPL901_0jmOSyoSyZzdiSU Cc: tram@ietf.org Subject: Re: [tram] TURN server discovery (please discuss!) 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, 31 Mar 2014 21:01:19 -0000 I read the turn server discovery draft more thoroughly now and think it = does the job well, with the following remarks: A) The problem 2) below (With the anycast method, can we know that it = really is our trusted enterprise or ISP providing the TURN server, i.e. is it close?). You have the solution (actually same as the "network-way idea" = I mentioned below) in 8.2 already (although spelled out for other = reasons): "Sensitive clients that do not wish to leak information about their = presence can set an IP TTL on their TURN requests that limits how far they can = travel into the public Internet." I suggest that this TTL limitation with the anycast method is specified (e.g. Don't look further than 3 steps - local firewall + max 2 ISP = routers) and brought into section 3. Discovery Procedure, step 3 of the draft. B) Shall we have more than one method (see 3 and 4 below)? If the = Anycast method can be used by everyone, why then also have DHCP? I have heard more fears that DHCP options are not available in common = OSs. If so, the DHCP method should be skipped. If a service provider deploys = DHCP discovered TURN servers, but some webrtc browser don't find/can use = them, it would just be bad. C) I saw Patil's advertised change to the Anycast method http://www.ietf.org/mail-archive/web/tram/current/msg00433.html and = agree it is better: "The response to an anycast request will be a 300 (try alternate) = response. The response will contain the unicast address in the ALTERNATE_SERVER attribute. This has been discussed (in another context), and will be included in the next revision." /Karl -----Ursprungligt meddelande----- Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se] Skickat: den 21 mars 2014 21:03 Till: 'Tirumaleswar Reddy (tireddy)'; 'Simon Perreault'; 'Brandon = Williams'; 'Prashanth Patil (praspati)'; 'tram@ietf.org' =C4mne: SV: [tram] TURN server discovery (please discuss!) 1) I want to emphasize Simon's view in the authentication discussion: " If the TURN server is provided by the network, couldn't we assume that authentication is network-based? That is, if you succeed in talking to = the server, then that means you're good. TURN servers would effectively have = "no authentication" in the protocol." The need for this milestone mechanism/RFC is for an enterprise or a an = ISP to announce a TURN server for their users of their network. The DHCP = method directly reflects this by responding: "Here are your IP address, your default gateway, your DNS servers and = now the suggested TURN server to use". (The TURN deployed is a networks = resource only available on the local connection - it only has the allocated = public port available to the WAN-side. That is TURN server/router/firewall combination more or less integrated.)=20 So the auto discovered turn-server should only be available and offered = to those allowed to use it - rather than being authenticated (like an application provided TURN server is). The browser should use the auto discovered TURN server without authentication. 2) The opposite - Can the browser trust the TURN server offered (also = raised here)? - is not a problem with the DHCP method (If we get network = resources like our IP address, default gateway via DHCP, we should of course also trust and the same DHCP server with giving us the TURN server address to place our real-time traffic at.) However, that may not be the case with the AnyCast method. Simon = previously raised: "> Suppose we define well-known anycast TURN server addresses. How would = > this not be subject to the same service quality issues that plagued=20 > 6to4? That is, anyone could set up a badly-maintained,=20 > under-provisioned TURN server and announce it over BGP to the world,=20 > as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how=20 > can we prevent triangle routing? There is nothing guaranteeing that=20 > the anycast server you see is being provided to you by your ISP,=20 > rather than a server sitting on the other side of the planet I got an "network-way idea" to address this from a developer of ours = that I have not considered/presented yet and I will also read up on draft draft-patil-tram-turn-serv-disc-00, and see it I have some educated = thoughts to contribute. It would be good if we can avoid having to introduce certificates or similar here and just stick to the network level. A few other points (maybe a better read of draft-patil-tram-turn-serv-disc-00 obsoletes some of these points and I = will know better on Monday, but anyway): 3) Two methods (DHCP and Anycast) are suggested in the draft. I assume = the thought is that browsers must implement both and the ISP can use any. Correct?=20 - But if one is good enough, shall we then drop the other to make life easier?=20 4) In addition to some doubts raised here against the DHCP discovery, = there were plenty in the discussion at the September-October discussion at the [rtcweb]-list (summary in http://www.ietf.org/mail-archive/web/tram/current/msg00132.html), = mainly:=20 a: concerns whether OSs actually forwards such extended DHCP information = for the browser to use - If I remember correctly, only Bernard Aboba from MS confirmed that is = was available in Windows. b: I withdrew my own(!) suggestion to use DHCP to find a network = provider offered TURN server because DHCP is NOT used in many networks, which = instead use (for handing out IP address etc): RA - Router Advertisement - in = IPv6, the IPCP protocol for PPPoE and something else for the mobile OTT = channel. I tend to focus on the Anycast method only (but will read up on draft-patil-tram-turn-serv-disc-00 until Monday and may be more educated then...) /Karl =20 -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Tirumaleswar Reddy = (tireddy) Skickat: den 21 mars 2014 17:51 Till: Simon Perreault; Brandon Williams; Prashanth Patil (praspati); tram@ietf.org =C4mne: Re: [tram] TURN server discovery (please discuss!) > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Friday, March 21, 2014 9:41 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil=20 > (praspati); tram@ietf.org > Subject: Re: [tram] TURN server discovery (please discuss!) >=20 > Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a =E9crit : > >> I think that some type of authentication is necessary, even if all=20 > >> it provides is the ability to verify that the two ends of the=20 > >> tunnel remain consistent throughout the life of the allocation. > >> Without at least that, then the service is open to DOS attacks via message injection. > > > > Agreed, some type of authentication is necessary. >=20 > That's not what I would call authentication. [D]TLS without=20 > authentication protects against message injection AFAIK. DTLS without authentication won't protect the TURN server from clients sending huge number of Allocate requests and taking up all the resources = in the TURN server.=20 I think both D{TLS} and authentication is required. -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 31 14:42:09 2014 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 D249F1A797C for ; Mon, 31 Mar 2014 14:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 VQXtKMpNsr8e for ; Mon, 31 Mar 2014 14:42:03 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0598B1A70FD for ; Mon, 31 Mar 2014 14:42:02 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so6416949wgg.33 for ; Mon, 31 Mar 2014 14:41:59 -0700 (PDT) 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 :content-type; bh=f2/FoeBTtUvdNfQrugim2cMgF0o1bJhTSqlVroJqCSI=; b=YdGbTV3C+Or5E6fcst7hKsW/STYWL6cdZ9lkNBE1p1vUOQOQaz1CIu2MWPVFj98E/K Ik4sqaZvVPfWkRp5ktoEyt+Wd8+NsZbjBfCD0xlHI9aOR0Dlo/TLG0Bs/GWeVuBqa2o5 pPRhUUJZnauI8OBSnCrY9j7y5r5JkGmovbwe5iczx1ZUBvbh9JsQeaeGOSWVGUeG6f0H /5+mwhLmioI9ckdSptkvQyJxriijxWh4wOqgKFalgOfAYqxFNeE2SX4FIJsKxyg43PgL sKKKCQ5qLn0s6GpguwygbulpJMXIjc8HoV+SRn3U8CdkiOIB5LOk3qUHvgULswKcDbUY WdGQ== MIME-Version: 1.0 X-Received: by 10.180.106.167 with SMTP id gv7mr15440566wib.40.1396302119319; Mon, 31 Mar 2014 14:41:59 -0700 (PDT) Received: by 10.217.152.10 with HTTP; Mon, 31 Mar 2014 14:41:59 -0700 (PDT) In-Reply-To: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> References: <20140331214024.15420.9235.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 16:41:59 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f235729d23f6f04f5edeb46 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5Bf5V5mtVrZ7bLF-lnKyLpdiYlo Subject: [tram] Fwd: I-D Action: draft-johnston-tram-stun-origin-02.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, 31 Mar 2014 21:42:06 -0000 --e89a8f235729d23f6f04f5edeb46 Content-Type: text/plain; charset=ISO-8859-1 All, We have revised the STUN Origin draft based on feedback on the list and from London. Comments most welcome. - Alan - ---------- Forwarded message ---------- From: Date: Mon, Mar 31, 2014 at 4:40 PM Subject: I-D Action: draft-johnston-tram-stun-origin-02.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Origin Attribute for the STUN Protocol Authors : Alan Johnston Justin Uberti John Yoakum Kundan Singh Filename : draft-johnston-tram-stun-origin-02.txt Pages : 10 Date : 2014-03-31 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web and SIP contexts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-02 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/ _______________________________________________ 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 --e89a8f235729d23f6f04f5edeb46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

We have revised the STUN Origin dr= aft based on feedback on the list and from London.

Comments most welcome.

- Alan -

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Mar 31, 2014 at 4:40 = PM
Subject: I-D Action: draft-johnston-tram-stun-origin-02.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : An Origin Attribute for the STU= N Protocol
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Alan Johnston
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Justin Uberti
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 John Yoakum
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kundan Singh
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-johnston-tram-stun-origin-0= 2.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 10
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-03-31

Abstract:
=A0 =A0STUN, or Session Traversal Utilities for NAT, is a protocol used to<= br> =A0 =A0assist other protocols traverse Network Address Translators or NATs.=
=A0 =A0STUN, and STUN extensions such as TURN, or Traversal Using Relays =A0 =A0around NAT, and ICE, Interactive Communications Establishment, have<= br> =A0 =A0been around for many years but with WebRTC, Web Real-Time
=A0 =A0Communications, STUN and related extensions are about to see major =A0 =A0deployments and implementation due to these protocols being
=A0 =A0implemented in browsers. =A0This specification defines an ORIGIN
=A0 =A0attribute for STUN that can be used in similar ways to the HTTP
=A0 =A0header field of the same name. =A0WebRTC browsers utilizing STUN and=
=A0 =A0TURN would include this attribute which would provide servers with =A0 =A0additional information about the STUN and TURN requests they receive= .
=A0 =A0This specification defines the usage of the STUN ORIGIN attribute fo= r
=A0 =A0web and SIP contexts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-johnston-tram-s= tun-origin/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-johnston-tram-stun-origin= -02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-johnston-= tram-stun-origin-02


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/

_______________________________________________
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

--e89a8f235729d23f6f04f5edeb46--