X-List-Received-Date: Mon, 02 Mar 2015 18:54:48 -0000 --001a1142999047e0b2051052c0ef Content-Type: text/plain; charset=UTF-8 Howdy, We're coming up on IETF 92, and RTCWEB currently has two sessions planned. In the preliminary schedule we are Wednesday 13:00-15:00 and Thursday 17:40-18:40. This is a much smaller amount of time that we've previously requested, reflecting the progress we've made on a number of fronts. Our current thought on divvying up the time is: Wednesday: Administrivia: 5 minutes Chair Doc Review: 15 minutes JSEP: 60 minutes FEC: 30 minutes Thursday: Transports: 20 minutes WGLC resolutions: 40 minutes Let the chairs know if you have a request for time and we can adjust. Ted, Sean, Cullen --001a1142999047e0b2051052c0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Howdy,

We'r= e coming up on IETF 92, and RTCWEB currently has two sessions planned.=C2=A0= =20 In the preliminary schedule we are Wednesday 13:00-15:00 and Thursday=20 17:40-18:40.=C2=A0 This is a much smaller amount of time that we've=20 previously requested, reflecting the progress we've made on a number of= =20 fronts.=C2=A0 Our current thought on divvying up the time is:

Wednesday:

Administrivia:=C2=A0 5 minutes=
Chair Doc Review: 15 minutes

JSEP:=C2=A0 60 minutes<= br>

FEC: 30 minutes

Thursday:

=

Transports: 20 minutes

WGLC resolutions:= 40 minutes

Let the chairs know if you have a reques= t for time and we can adjust.

Ted, Sean, Cullen

--001a1142999047e0b2051052c0ef-- From nobody Wed Mar 4 10:12:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79E31A9308 for ; Wed, 4 Mar 2015 10:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jvmn5-VQUFtx for ; Wed, 4 Mar 2015 10:12:21 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6361A9302 for ; Wed, 4 Mar 2015 10:12:21 -0800 (PST) Received: by qcyl6 with SMTP id l6so38915426qcy.2 for ; Wed, 04 Mar 2015 10:12:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZfnwfHaX+cVp2D+iKqcquTtCGk8wbKZU54Tp0r7yzSs=; b=loO5GfPA/EJD/rtzVAAs60zGd8kanZ7wsXJ1anTTRSWpb6LlscD5x+kDtG4ko2dKut Q4Ys4fG0RUUiT9oV1gLVvN5blYS8CItTmIwoRbn1eFQkONKf2MPylGZlqTZSz6SwGskl lbJOoXNVUUqBl4XFyAxqtvXCOsuuQHwNsETQl4vC8sY/u9IyiERGaICugtsvwk1jax5E vD4Qn2fJ1FIguZRgWSe+QFNRofzAs9g6DNCm0DkTJ+VXlwfVyJ/FoPvSiKq8YCf7fIoK BA7I3/PnUvZHLMafRyfNT0nJP1rSPrYiuyyMvcmCHTt6SIwSuq6oareO5BO9u08lCM7A DQYQ== X-Gm-Message-State: ALoCoQmKCrORdlxYuH82rogRTSeTFpUYVGzFt9iJ5joIgPk+byjS3VbtliGZ3PgdnrTB7oGD/o8b X-Received: by 10.140.33.164 with SMTP id j33mr7362589qgj.10.1425492740587; Wed, 04 Mar 2015 10:12:20 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 86sm1464635qkw.13.2015.03.04.10.12.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 10:12:19 -0800 (PST) Message-ID: <54F74B02.1070902@jive.com> Date: Wed, 04 Mar 2015 13:12:18 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:12:23 -0000 This is a follow-up to this thread on discuss-webrtc: https://groups.google.com/forum/#!topic/discuss-webrtc/i67xq-FWtoM I see two distinct problems: 1. It must be possible for a DTLS connection to jump from one ICE candidate to another. That is, a DTLS connection must not be bound to a single 5-tuple. This can be deduced from a good understanding of ICE, but it could certainly be stated more clearly. 2. SRTP keying material extracted from a DTLS connection must also not be bound to a single 5-tuple, in case media jumps from one ICE candidate to another. That's more problematic because RFC 5764 states very clearly that keying material is to be bound to the DTLS 5-tuple, modulo forking. If I'm not mistaken, the right thing to do would be to bind keying material to all local ICE candidates (multiple 3-tuples), and treat any incoming media flow as indicated in RFC 5764 page 15, with one mapping table per 3-tuple. For outgoing flows, I guess it would make most sense to bind keying material to the 5-tuples for which the sender has obtained consent. Is this correct? If so, would it be useful to add text explaining this in detail? Simon From nobody Wed Mar 4 10:54:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333DF1ACE07 for ; Wed, 4 Mar 2015 10:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 IYmVVFbZPVJb for ; Wed, 4 Mar 2015 10:54:19 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB391ACE01 for ; Wed, 4 Mar 2015 10:54:19 -0800 (PST) Received: by iery20 with SMTP id y20so16248215ier.13 for ; Wed, 04 Mar 2015 10:54:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XjVPe7CeXYKv2HjwUD9w48qMoKK7l78/HiR78dpfDQM=; b=Sk9LeSln2j8tkgUsl17GUJOD10eEC9h6UwWtak1k8NE4m6nkG9/+gWhPOT6DdqhtmP S9D9mcjI++9vQ/5Qh5UJFuh5ujh56CwSnW0giu16dhM5uhzfk0a+oYdWnbCa1azJXGcV /BDx00c3O+006m7UojHx1OZ64pA+UAMg+JEd7OH//pyfrYDiZkU9fNEx9pq+96WyjHAa DNIOpjN+M/7i6jpLdMFDUk3IDSm+1TRpBuf5L1gDkbJ+3njSWTwW5iRVreWu/DppGoWr secysze4r4fxu+DGWZpFmNWFhgasv5FZ+YrAVN7qukwCX2kkfQbG8G9/CEUUIx+G3jTW d7jA== X-Gm-Message-State: ALoCoQlBzTnuMsssHgf9oTTSFqvn2TmlIdgdRdJdfmb6gnKqGcfTrec0EIFXlUh30sJp4ld59p4t X-Received: by 10.107.137.226 with SMTP id t95mr14260555ioi.10.1425495258789; Wed, 04 Mar 2015 10:54:18 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com. [209.85.223.178]) by mx.google.com with ESMTPSA id c4sm3376220igt.19.2015.03.04.10.54.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 10:54:17 -0800 (PST) Received: by iecat20 with SMTP id at20so16270789iec.6 for ; Wed, 04 Mar 2015 10:54:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.138.68 with SMTP id qo4mr39986072igb.33.1425495256693; Wed, 04 Mar 2015 10:54:16 -0800 (PST) Received: by 10.36.20.10 with HTTP; Wed, 4 Mar 2015 10:54:16 -0800 (PST) In-Reply-To: <54F74B02.1070902@jive.com> References: <54F74B02.1070902@jive.com> Date: Wed, 4 Mar 2015 13:54:16 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1134bd8067847605107afa09 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:54:21 -0000 --001a1134bd8067847605107afa09 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 4, 2015 at 1:12 PM, Simon Perreault wrote: > This is a follow-up to this thread on discuss-webrtc: > https://groups.google.com/forum/#!topic/discuss-webrtc/i67xq-FWtoM > > If I'm not mistaken, the right thing to do would be to bind keying > material to all local ICE candidates (multiple 3-tuples), and treat any > incoming media flow as indicated in RFC 5764 page 15, with one mapping > table per 3-tuple. For outgoing flows, I guess it would make most sense to > bind keying material to the 5-tuples for which the sender has obtained > consent. > > Is this correct? If so, would it be useful to add text explaining this in > detail? > > This is not correct. End point can have multiple flows with different keying material or different DTLS sessions on the same local ICE 3-tuple due to forking. More correct implementation would be to associate multiple 5-tuples with the same logical transport stream based on ICE connectivity checks using ICE ufrag to identify which logical stream to associate with each 5-tuple. There is also another interesting consequence of this -- end point should not re-use the same ICE candidate IP/port with a different ufrag during session update offer/answer exchange. Otherwise you might end up with ambiguous association between the logical streams and keying material or DTLS session. All of this probably needs to be defined somewhere and I am not aware which RFC or draft defines this at this time. _____________ Roman Shpount --001a1134bd8067847605107afa09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On W= ed, Mar 4, 2015 at 1:12 PM, Simon Perreault <sperreault@jive.com&g= t; wrote:

This is a follow-up to this thread on = discuss-webrtc:
https://groups.google.com/forum/#!topic/discus= s-webrtc/i67xq-FWtoM

If I'm not mistaken, the right thing to do would be to bind keying = material to all local ICE candidates (multiple 3-tuples), and treat any inc= oming media flow as indicated in RFC 5764 page 15, with one mapping table p= er 3-tuple. For outgoing flows, I guess it would make most sense to bind ke= ying material to the 5-tuples for which the sender has obtained consent.
Is this correct? If so, would it be useful to add text explaining this in d= etail?

This is not correct. End point can hav= e multiple flows with different keying material or different DTLS sessions = on the same local ICE 3-tuple due to forking. More correct implementation w= ould be to associate multiple 5-tuples with the same logical transport stre= am based on ICE connectivity checks using ICE ufrag to identify which logic= al stream to associate with each 5-tuple.

There is= also another interesting consequence of this -- end point should not re-us= e the same ICE candidate IP/port with a different ufrag during session upda= te offer/answer exchange. Otherwise you might end up with ambiguous associa= tion between the logical streams and keying material or DTLS session.=C2=A0=

All of this probably needs to be defined somewher= e and I am not aware which RFC or draft defines this at this time.

_____________
Roman Shpount

=C2=A0

--001a1134bd8067847605107afa09-- From nobody Wed Mar 4 11:02:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10221ACE24 for ; Wed, 4 Mar 2015 11:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 88JvEnvGYluP for ; Wed, 4 Mar 2015 11:02:13 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CA01ACE22 for ; Wed, 4 Mar 2015 11:02:13 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id v8so7024214qal.13 for ; Wed, 04 Mar 2015 11:02:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wsh5xySq49wsAXhNvTgHxyKtoLcM9/1xezTxh9gYJuE=; b=BEy1XF1w0FY8s9h9E/tJV3j/FHtU6vzNXeIDPX8q0vGsi9EY7JpS4ReeNVfqQUEvSX +UNvQh8UW79/zqPXk24W4mai8783sWS2ioE+dy5xyYZRDm9QNami+QRNR2YJqDid+gTM CURZkdNQz0A+3KSpcfl0xC7StXK3ARJ6WiAs2leXxhAT3/1vpy96yskO0f7gRlicTWmd m9bRODDbs+54mYDqmHxy+2SkM9ePIHZPWRjNc7PlZAGpo2FG/Mvc+hoodeBN/VVtoyWK 0Cu9l3z6a9DMDZKreqrNRteJwNgdJfAvUt+UzGNaz6IISH7L7/0DlXtiOrK6k6zld77G M1Bw== X-Gm-Message-State: ALoCoQmVY+PbWxG7WB2rGiitQuoNCP6EytKMk5WWsxSlae1H6fTCckbUYydqZNIp1VS5olhF1xCo X-Received: by 10.140.84.116 with SMTP id k107mr7314429qgd.45.1425495732964; Wed, 04 Mar 2015 11:02:12 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id h6sm2646412qgh.32.2015.03.04.11.02.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 11:02:12 -0800 (PST) Message-ID: <54F756B2.60408@jive.com> Date: Wed, 04 Mar 2015 14:02:10 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Roman Shpount References: <54F74B02.1070902@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:02:15 -0000 Le 2015-03-04 13:54, Roman Shpount a écrit : > This is not correct. End point can have multiple flows with different > keying material or different DTLS sessions on the same local ICE 3-tuple > due to forking. More correct implementation would be to associate > multiple 5-tuples with the same logical transport stream based on ICE > connectivity checks using ICE ufrag to identify which logical stream to > associate with each 5-tuple. Agreed. > There is also another interesting consequence of this -- end point > should not re-use the same ICE candidate IP/port with a different ufrag > during session update offer/answer exchange. Otherwise you might end up > with ambiguous association between the logical streams and keying > material or DTLS session. Right. And wait MSL seconds before reusing a candidate to let the pipes drain. > All of this probably needs to be defined somewhere and I am not aware > which RFC or draft defines this at this time. I guess for DTLS/DTLS-SRTP the obvious target would be -security... Simon From nobody Wed Mar 4 11:54:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692291A88A4 for ; Wed, 4 Mar 2015 11:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 QMSSjEOs1RjU for ; Wed, 4 Mar 2015 11:54:07 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B7D1A8762 for ; Wed, 4 Mar 2015 11:54:06 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-56-54f762dc5ba1 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.06.16191.CD267F45; Wed, 4 Mar 2015 20:54:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 20:54:04 +0100 From: Christer Holmberg To: Simon Perreault , Roman Shpount Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Thread-Index: AQHQVqbHfYSbCv5RRE+VguSZdJaU4Z0MmygAgAACNQCAAB9EuA== Date: Wed, 4 Mar 2015 19:54:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> , <54F756B2.60408@jive.com> In-Reply-To: <54F756B2.60408@jive.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D726AD8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RvdO0vcQg0VbrC1mXJjKbLH2Xzu7 xfUroQ7MHkuW/GTy+DfnKbPHrSkFAcxRXDYpqTmZZalF+nYJXBnTXjxmKliuXdH6ayJ7A+Ni 1S5GTg4JAROJqSe3sUDYYhIX7q1nA7GFBI4wSiw5K9zFyAVkL2aUmNcyD6iIg4NNwEKi+582 SI2IgI/EkicNTCA2s4C6xJ3F59hBbGEBY4lvM58wQtSYSGx8/pwJwnaSmHFtFZjNIqAi0fN3 BxvISF4BX4md32UgVnUwSkzbMB+shlNATWLWgX6wOYxAt30/tQZql7hE05eVrBA3C0gs2XOe GcIWlXj5+B8rRE2+xMo9W8DivAKCEidnPmGZwCgyC0n7LCRls5CUQcQNJL68vw1la0ssW/ia GcLWl+h+f5oJWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAoO7jlt+oOxstvHA8x CnAwKvHwGpR+CxFiTSwrrsw9xCjNwaIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A2Oo1JRONrHOoI/+knbnbxxSFH71/PelhdbK+zZwPV8bX7LrkVnqpIo/i5lUuifabu//2j6d efqOT7dWaqUsPOx3Qo7d+WXfmxtf3m39ynL046lEW55qWbeiP2/u7WK1ECnI9jk2UaajJmvP x1NfVh5crcy6WqtQc9s+kXdMl7lfF1w79KZIc+EfJZbijERDLeai4kQArWs51JMCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:54:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D726AD8ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, Didn't we last week agree that, if the underlying transport changes, the DT= LS connection MUST be re-established? Jumping from one candidate to another is a transport change, isn't it? Regards, Christer Sent from my Windows Phone ________________________________ From: Simon Perreault Sent: =FD04/=FD03/=FD2015 21:02 To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Le 2015-03-04 13:54, Roman Shpount a =E9crit : > This is not correct. End point can have multiple flows with different > keying material or different DTLS sessions on the same local ICE 3-tuple > due to forking. More correct implementation would be to associate > multiple 5-tuples with the same logical transport stream based on ICE > connectivity checks using ICE ufrag to identify which logical stream to > associate with each 5-tuple. Agreed. > There is also another interesting consequence of this -- end point > should not re-use the same ICE candidate IP/port with a different ufrag > during session update offer/answer exchange. Otherwise you might end up > with ambiguous association between the logical streams and keying > material or DTLS session. Right. And wait MSL seconds before reusing a candidate to let the pipes drain. > All of this probably needs to be defined somewhere and I am not aware > which RFC or draft defines this at this time. I guess for DTLS/DTLS-SRTP the obvious target would be -security... Simon _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1D726AD8ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

Hi,

Didn't we last week agree that, if the underlying transport changes, the DT= LS connection MUST be re-established?

Jumping from one candidate to another is a transport change, isn't it?

Regards,

Christer

Sent from my Windows Phone

From: Simon Perreault
Sent: =FD04= /=FD03/=FD2015 21:02
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Le 2015-03-04 13:54, Roman Shpount a =E9crit :
> This is not correct. End point can have multiple flows with different<= br> > keying material or different DTLS sessions on the same local ICE 3-tup= le
> due to forking. More correct implementation would be to associate
> multiple 5-tuples with the same logical transport stream based on ICE<= br> > connectivity checks using ICE ufrag to identify which logical stream t= o
> associate with each 5-tuple.

Agreed.

> There is also another interesting consequence of this -- end point
> should not re-use the same ICE candidate IP/port with a different ufra= g
> during session update offer/answer exchange. Otherwise you might end u= p
> with ambiguous association between the logical streams and keying
> material or DTLS session.

Right. And wait MSL seconds before reusing a candidate to let the pipes drain.

> All of this probably needs to be defined somewhere and I am not aware<= br> > which RFC or draft defines this at this time.

I guess for DTLS/DTLS-SRTP the obvious target would be -security...

Simon

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb

--_000_7594FB04B1934943A5C02806D1A2204B1D726AD8ESESSMB209erics_-- From nobody Wed Mar 4 11:59:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEAC1ACE46 for ; Wed, 4 Mar 2015 11:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 gvxge1sgSawY for ; Wed, 4 Mar 2015 11:59:45 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911091AC42A for ; Wed, 4 Mar 2015 11:59:45 -0800 (PST) Received: by iecrp18 with SMTP id rp18so2405839iec.10 for ; Wed, 04 Mar 2015 11:59:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tGaCZnC4pYpSstHl417RmGTWU/wo26uGy2WzCB7++4k=; b=mlfkSz/D/gUdTcSrup8zlJU+ZYWGArnRBK0cQbKONr9fMWvD34rqx+DgszW+aDOuxC SiTkeYel4LzA14VurjmfvcdEgvjiBadzZi72xiWAPPAuYmW2ttp+CvOzxD2ABA6aCaky JZdVd5ZFYIjNAquf4coHpMbATXtF0LA5sEcTYDMqbfz+f0j8aUghL7/HRRWaUuaYaHQq X9LCDs6+PCwpxZGGtVGT//8BgO9StKai6qCI3Ln9OsIMNMjW4MBZVgaDe/QHD87TNORD 46ItiHxjxfHJMFeRHwbbqbOAsWv/o55Vof8QEnwfz6uwgersrNkJEhboT707jevydz/q 0etA== X-Gm-Message-State: ALoCoQm37GHvHar2d5M5h0ckTRR4QQ9wqD+405ypLjuTKqT5vGDxSwbnp9ROMEJGnnkrcIxbXQKX X-Received: by 10.107.153.193 with SMTP id b184mr14710544ioe.85.1425499184907; Wed, 04 Mar 2015 11:59:44 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com. [209.85.223.170]) by mx.google.com with ESMTPSA id m5sm3503123ige.5.2015.03.04.11.59.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 11:59:43 -0800 (PST) Received: by iecat20 with SMTP id at20so16783407iec.6 for ; Wed, 04 Mar 2015 11:59:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr14328573igx.33.1425499182828; Wed, 04 Mar 2015 11:59:42 -0800 (PST) Received: by 10.36.20.10 with HTTP; Wed, 4 Mar 2015 11:59:42 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> Date: Wed, 4 Mar 2015 14:59:42 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e01229aaa6ba18c05107be472 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:59:47 -0000 --089e01229aaa6ba18c05107be472 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Didn't we last week agree that, if the underlying transport changes, > the DTLS connection MUST be re-established? > > Jumping from one candidate to another is a transport change, isn't it? > > In cases where ICE is used jump from on candidate to another should not constitute a transport change. A change in ICE ufrag should constitute the transport change. All ICE candidates are a single virtual transport channel. Without this a lot of ICE setup scenarios, such as rapid nomination, break down. Even changes in the c= line address, m=line port port, or list of candidates is not a transport change if ufrag stays the same. In cases where ICE is not used, changes of address in c= line or port in m= line are a transport change. _____________ Roman Shpount --089e01229aaa6ba18c05107be472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On W= ed, Mar 4, 2015 at 2:54 PM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:

Didn't we = last week agree that, if the underlying transport changes, the DTLS connect= ion MUST be re-established?

Jumping from one candidate to another is a transport change, isn't it?<= br>

In cases where= ICE is used jump from on candidate to another should not constitute a tran= sport change. A change in ICE ufrag should constitute the transport change.= All ICE candidates are a single virtual transport channel. Without this a = lot of ICE setup scenarios, such as rapid nomination, break down. Even chan= ges in the c=3D line address, m=3Dline port port, or list of candidates is = not a transport change if ufrag stays the same.

In= cases where ICE is not used, changes of address in c=3D line or port in m= =3D line are a transport change.

_= ____________
Roman Shpount

=C2=A0

--089e01229aaa6ba18c05107be472-- From nobody Wed Mar 4 12:02:19 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856171ACE3F for ; Wed, 4 Mar 2015 12:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 cMlphYYaoHQ2 for ; Wed, 4 Mar 2015 12:02:16 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31531AC42A for ; Wed, 4 Mar 2015 12:01:50 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so35391294qac.8 for ; Wed, 04 Mar 2015 12:01:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jmTcSzOlwmC46UfrRTWs36PFcpo18w1oNR9TFDo56GE=; b=fpCInBPU3DYXt+pbU/lRwn5q9+/0w7WlXr6qKqCoQ8XYpDNiND4ClNBNyPZoSTdSEF T4tbBeC+S2mqJkFOvzoV3q5smVaXZ3Z7AebGNk+ioefBT/xBZcuRhf8/cS2dW7aebKh9 upet7D3oWrSbf8x8fD+cAgOibwzgCydVc87ULBKA78WG91ZkGsedhcMw2HtrKig2Olo4 +K23ymgmlyc0a7/XGwBm8+0xrhbBxXGK8jMF4Iwy0nQnkENXUML+0ooBWaWFEh4DDBQl eqN8iw+wam4WdiLk47LQZA0cnFi0n9/MwcHOk276cFxHk3Pw0tT7dC8kqYTDaJUIACtM aeXA== X-Gm-Message-State: ALoCoQlous4F/kZ5Bn6AYE4/N8P5U5Im6eNnfq8EoTkIp8F19M6iYjoNDaU/diU2Dqi2vbAeT1bB X-Received: by 10.140.147.131 with SMTP id 125mr8041153qht.81.1425499309816; Wed, 04 Mar 2015 12:01:49 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id w1sm2764330qal.0.2015.03.04.12.01.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 12:01:48 -0800 (PST) Message-ID: <54F764AB.40408@jive.com> Date: Wed, 04 Mar 2015 15:01:47 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Roman Shpount , Christer Holmberg References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:02:17 -0000 Le 2015-03-04 14:59, Roman Shpount a écrit : > On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg > > > wrote: > > Didn't we last week agree that, if the underlying transport changes, > the DTLS connection MUST be re-established? > > Jumping from one candidate to another is a transport change, isn't it? > > > In cases where ICE is used jump from on candidate to another should not > constitute a transport change. A change in ICE ufrag should constitute > the transport change. All ICE candidates are a single virtual transport > channel. Without this a lot of ICE setup scenarios, such as rapid > nomination, break down. Even changes in the c= line address, m=line port > port, or list of candidates is not a transport change if ufrag stays the > same. > > In cases where ICE is not used, changes of address in c= line or port in > m= line are a transport change. I'm in full agreement. Simon From nobody Wed Mar 4 12:04:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1391A0AF7 for ; Wed, 4 Mar 2015 12:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 Ls-4Z3uXqXK8 for ; Wed, 4 Mar 2015 12:04:54 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73F21A0390 for ; Wed, 4 Mar 2015 12:04:53 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-e6-54f7656360a8 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.8C.04032.36567F45; Wed, 4 Mar 2015 21:04:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 21:04:51 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Thread-Index: AQHQVqbHfYSbCv5RRE+VguSZdJaU4Z0MmygAgAACNQCAAB9EuP//8M8AgAASNNg= Date: Wed, 4 Mar 2015 20:04:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D726B71ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rjc59XuIwbb/ZhYzLkxltlj7r53d 4vqVUAdmjyVLfjJ5/JvzlNnj1pSCAOYoLpuU1JzMstQifbsEroy+AzwFxzQqnmy4z9rA+Fep i5GTQ0LAROLZq8tsELaYxIV764FsLg4hgSOMEp+33mWHcBYzShyc8ZS1i5GDg03AQqL7nzZI g4iAqsTf75OZQGxmAT+Jnf2v2UFsYQFjiW8znzBC1JhIbHz+nAnC9pPYvWsr2DIWARWJ/xPX sIDYvAK+Ep9OPWOC2DWZSWLex2ZmkASnQKDEyinfwGxGoOu+n1oDtUxcounLSlaIqwUkluw5 zwxhi0q8fPyPFaImX+LZ11Z2iAWCEidnPmGZwCgyC0n7LCRls5CUQcQNJL68vw1la0ssW/ia GcLWl+h+f5oJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMA4O7jlt8EOxpfPHQ8x CnAwKvHwGpR+CxFiTSwrrsw9xCjNwaIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A2OYVaqG9YPZDHP4pyQ6XSkxsLC0er1o2QHnCSe2PZBkDjxqeZG16Gb6lJUnzbRUkt0Xzj50 5XCgp+5rj9dTtp78yHetIVMtZRbXK6dD5q/DZ73pjvL02HP4RhYTZ7DCTEPhX9LPT+pmHkn4 9+2VnGHccqWZk6SWi5eLtm4zSn77bIIcY/5VwTIlluKMREMt5qLiRABdcV8+lAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:04:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D726B71ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, What if you jump from an UDP candidate to a TCP candidate? At the same time= you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only u= sed for key management). Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD04/=FD03/=FD2015 21:59 To: Christer Holmberg Cc: Simon Perreault; rtcweb@ietf.org Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg > wrote: Didn't we last week agree that, if the underlying transport changes, the DT= LS connection MUST be re-established? Jumping from one candidate to another is a transport change, isn't it? In cases where ICE is used jump from on candidate to another should not con= stitute a transport change. A change in ICE ufrag should constitute the tra= nsport change. All ICE candidates are a single virtual transport channel. W= ithout this a lot of ICE setup scenarios, such as rapid nomination, break d= own. Even changes in the c=3D line address, m=3Dline port port, or list of = candidates is not a transport change if ufrag stays the same. In cases where ICE is not used, changes of address in c=3D line or port in = m=3D line are a transport change. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B1D726B71ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

Hi,

What if you jump from an UDP candidate to a TCP candidate? At the same time= you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only u= sed for key management).

Regards,

Christer

Sent from my Windows Phone

From: Roman Shpount
Sent: =FD04= /=FD03/=FD2015 21:59
To: Christer Holmberg Cc: Simon Perreault; rtcweb@ietf.org
Subject: Re: [= rtcweb] DTLS, DTLS-SRTP, and 5-tuples

On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:

Didn't we las= t week agree that, if the underlying transport changes, the DTLS connection= MUST be re-established?

Jumping from one candidate to another is a transport change, isn't it?

In cases where ICE is used jump from on candidate to another should no= t constitute a transport change. A change in ICE ufrag should constitute th= e transport change. All ICE candidates are a single virtual transport chann= el. Without this a lot of ICE setup scenarios, such as rapid nomination, break down. Even changes in the c=3D = line address, m=3Dline port port, or list of candidates is not a transport = change if ufrag stays the same.

In cases where ICE is not used, changes of address in c=3D line or por= t in m=3D line are a transport change.

_____________
Roman Shpount

--_000_7594FB04B1934943A5C02806D1A2204B1D726B71ESESSMB209erics_-- From nobody Wed Mar 4 12:06:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5F21A886F for ; Wed, 4 Mar 2015 12:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 KQY69zDsWBwr for ; Wed, 4 Mar 2015 12:06:50 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BE21A889C for ; Wed, 4 Mar 2015 12:06:49 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-1c-54f765d70265 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FD.57.07828.7D567F45; Wed, 4 Mar 2015 21:06:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 21:06:46 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Thread-Index: AQHQVqbHfYSbCv5RRE+VguSZdJaU4Z0MmygAgAACNQCAAB9EuP//8M8AgAASNNiAAACK+A== Date: Wed, 4 Mar 2015 20:06:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D726BFE@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D726BFEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje711O8hBv2vlC1mXJjKbLH2Xzu7 A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgytgwexpbQY95xZUVB5gbGP/odzFyckgImEis eP2cDcIWk7hwbz2QzcUhJHCEUeLg3BOMEM5iRok1u1aydjFycLAJWEh0/9MGaRARiJb48GEB E4jNLKAucWfxOXYQW1jAWOLbzCeMEDUmEhufP2eCsMMkZs29xQpiswioSFy6cQ2snlfAV2Li 8VvsELtuMElcvPcYrIFTwE+i/d03MJsR6Lrvp9ZALROXaPqykhXiagGJJXvOM0PYohIvH/9j hajJl7ix9QQbxAJBiZMzn7BMYBSZhaR9FpKyWUjKIOIGEl/e34aytSWWLXzNDGHrS3S/P82E LL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmBcHdzy22oH48HnjocYBTgYlXh4DUq/ hQixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHGn5vWTzc0 shr8n6XBkpSXfUJDdJakgWKucWbpm72FD30eMZTp9W7POBX147eZ+NzNt048l7TOPjZPKTGH YWb1m9/zLSfuFSo1e7Hm5rxvt1clFeVbfxH9bNA6VXRy4726N+uDy95qSN92XRmxtHbeae3g Dj6uW9vKCxZfXzON77WN4cq2kBlKLMUZiYZazEXFiQC3GWOQjAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:06:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D726BFEESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Correction. You are not jumping to TLS, if you use framing for DTLS when TC= P is used. Regards, Christer Sent from my Windows Phone ________________________________ From: Christer Holmberg Sent: =FD04/=FD03/=FD2015 22:05 To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Hi, What if you jump from an UDP candidate to a TCP candidate? At the same time= you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only u= sed for key management). Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD04/=FD03/=FD2015 21:59 To: Christer Holmberg Cc: Simon Perreault; rtcweb@ietf.org Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg > wrote: Didn't we last week agree that, if the underlying transport changes, the DT= LS connection MUST be re-established? Jumping from one candidate to another is a transport change, isn't it? In cases where ICE is used jump from on candidate to another should not con= stitute a transport change. A change in ICE ufrag should constitute the tra= nsport change. All ICE candidates are a single virtual transport channel. W= ithout this a lot of ICE setup scenarios, such as rapid nomination, break d= own. Even changes in the c=3D line address, m=3Dline port port, or list of = candidates is not a transport change if ufrag stays the same. In cases where ICE is not used, changes of address in c=3D line or port in = m=3D line are a transport change. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B1D726BFEESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

Correction. Y= ou are not jumping to TLS, if you use framing for DTLS when TCP is used.
Regards,

Christer

Sent from my Windows Phone

From: Christer Holmberg Sent: =FD04= /=FD03/=FD2015 22:05
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] DTLS, DTLS-SRTP, and 5-tuples

From: Roman Shpount
Sent: =FD04= /=FD03/=FD2015 21:59
To: Christer Holmberg Cc: Simon Perreault; rtcweb@ietf.org
Subject: Re: [= rtcweb] DTLS, DTLS-SRTP, and 5-tuples

On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:

Didn't we las= t week agree that, if the underlying transport changes, the DTLS connection= MUST be re-established?

Jumping from one candidate to another is a transport change, isn't it?

In cases where ICE is not used, changes of address in c=3D line or por= t in m=3D line are a transport change.

_____________
Roman Shpount

--_000_7594FB04B1934943A5C02806D1A2204B1D726BFEESESSMB209erics_-- From nobody Wed Mar 4 12:08:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F701A889C for ; Wed, 4 Mar 2015 12:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 ofsIr_vnZ2BX for ; Wed, 4 Mar 2015 12:08:04 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCEA1A886F for ; Wed, 4 Mar 2015 12:08:03 -0800 (PST) Received: by wibhm9 with SMTP id hm9so10398740wib.2 for ; Wed, 04 Mar 2015 12:08:02 -0800 (PST) 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=SM4aY1rW7/HEGsGeD9IxUtw3r+cBuA6tLfyngX4PUcg=; b=dAskZJynShzufLVNbB9xyhLEfjQGezcxWWUB7Ruay4jzWLM3mwlQEXKuwOAQelNpTS 9jzU+uYFLodIeympb/TDxahhLA+4xLpULzsjCskvsL+J9HnNfo+helUlaEFdYwM072xd 3+EwkiFoc5yhsWs6HHj3U4nvUKXC2df2QzAkLy5uRNdwk+X36YP6lJfG8vP7tbN6pA5A BWaexpPIKs00+G4hFSZ7VdE8vZD1Z/GQl+fyzQ8l6FslzEBaNdV96lUTHo0BYRbXLsdL b6/yibnPOprvi689gzQZNZEGpYUSkvdi9m1wpIOhMN54a5UiVcT4f5wJJQgCDYK1+D3U r+ZQ== X-Gm-Message-State: ALoCoQk/3/0a8RDkYjft4xZtU8lgRT025BQ0/91hUb57HdL6lXPqxuJ+U+X14pxLbvJcSAONHo+Y X-Received: by 10.180.105.131 with SMTP id gm3mr59766075wib.11.1425499682697; Wed, 04 Mar 2015 12:08:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.214.203 with HTTP; Wed, 4 Mar 2015 12:07:22 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Wed, 4 Mar 2015 12:07:22 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d0418257c3709b305107c024b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:08:05 -0000 --f46d0418257c3709b305107c024b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 4, 2015 at 12:04 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > What if you jump from an UDP candidate to a TCP candidate? At the same > time you would be jumping from DTLS to TLS (even for SRTP, where DTLS is > only used for key management). > No. You do DTLS even with TCP. -Ekr > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Roman Shpount > Sent: =E2=80=8E04/=E2=80=8E03/=E2=80=8E2015 21:59 > To: Christer Holmberg > Cc: Simon Perreault ; rtcweb@ietf.org > Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples > > On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Didn't we last week agree that, if the underlying transport changes, >> the DTLS connection MUST be re-established? >> >> Jumping from one candidate to another is a transport change, isn't it? >> >> > In cases where ICE is used jump from on candidate to another should not > constitute a transport change. A change in ICE ufrag should constitute th= e > transport change. All ICE candidates are a single virtual transport > channel. Without this a lot of ICE setup scenarios, such as rapid > nomination, break down. Even changes in the c=3D line address, m=3Dline p= ort > port, or list of candidates is not a transport change if ufrag stays the > same. > > In cases where ICE is not used, changes of address in c=3D line or port = in > m=3D line are a transport change. > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0418257c3709b305107c024b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 4, 2015 at 12:04 PM, Christer Holmberg <christer.= holmberg@ericsson.com> wrote:

Hi,

What if you jump from an UDP candidate to a TCP candidate? At the same time= you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only u= sed for key management).

= No. You do DTLS even with TCP.

-Ekr

=C2= =A0

Regards,

Christer

Sent from my Windows Phone

From: Roman Shpount Sent: =E2=80= =8E04/=E2=80=8E03/=E2=80=8E2015 21:59
To: Christer Holm= berg
Cc: Simon Perreault; rtcweb@ietf.org
Subject: Re: [r= tcweb] DTLS, DTLS-SRTP, and 5-tuples

On Wed, Mar 4, 2015 at 2:54 PM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:

Didn't we = last week agree that, if the underlying transport changes, the DTLS connect= ion MUST be re-established?

Jumping from one candidate to another is a transport change, isn't it?<= br>

In cases where ICE is used jump from on candidate to another should no= t constitute a transport change. A change in ICE ufrag should constitute th= e transport change. All ICE candidates are a single virtual transport chann= el. Without this a lot of ICE setup scenarios, such as rapid nomination, break down. Even changes in the c=3D = line address, m=3Dline port port, or list of candidates is not a transport = change if ufrag stays the same.

In cases where ICE is not used, changes of address in c=3D line or por= t in m=3D line are a transport change.

_____________
Roman Shpount

=C2=A0

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

--f46d0418257c3709b305107c024b-- From nobody Wed Mar 4 12:51:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730891A88EB for ; Wed, 4 Mar 2015 12:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dW28nh8c0jtH for ; Wed, 4 Mar 2015 12:51:34 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DA71A88D9 for ; Wed, 4 Mar 2015 12:51:34 -0800 (PST) Received: by igbhl2 with SMTP id hl2so40022489igb.3 for ; Wed, 04 Mar 2015 12:51:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bxvB6IZXBtMAFftLxlDS9kx/l1FqYzD6gPqBH9WNci4=; b=R2V9YHz3szGasRqSQELnaifZn/HlK97UlcEZXBtdQh8QJQOLjvnZ3qW61T45672ZvR db2Pf+YUQ07JvqB0UXKByRt3sJWc2a81Nxl+sAL115FufAnHA26PFIh6u4GDio2MYvCO RIvf+ltK78TC1OTx+EMkcTTRC8UZw2BiMXxeDAXbBtu2bNgKOCxdcoLe53FrQ7Kh+zmi frghJ1P4EkDoHs4RHAR4/t9MUqyhD2Us1kPG/gDJXv/Xms0jY34tPLY8ULSGkb4iAWId IgpSt6l9vcoTcCPuokCDT+gKCbsHyeyXR2fYl72f4mfWBx9SKLYwyajQ2A+FipM7gPNF RXFw== X-Gm-Message-State: ALoCoQl6uCVVhys31L8CYoqGGkrGwHi2bMQbvuuiIQ8PmapUc2ZPU/wCaDiiWb/5ekVg9SzYwmhh X-Received: by 10.50.66.212 with SMTP id h20mr18626696igt.43.1425502293614; Wed, 04 Mar 2015 12:51:33 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by mx.google.com with ESMTPSA id h19sm11385574igq.10.2015.03.04.12.51.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 12:51:32 -0800 (PST) Received: by igal13 with SMTP id l13so40279527iga.0 for ; Wed, 04 Mar 2015 12:51:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr14765912igx.33.1425502291400; Wed, 04 Mar 2015 12:51:31 -0800 (PST) Received: by 10.36.20.10 with HTTP; Wed, 4 Mar 2015 12:51:31 -0800 (PST) In-Reply-To: References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> Date: Wed, 4 Mar 2015 15:51:31 -0500 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e01229aaab49ffe05107c9d28 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:51:35 -0000 --089e01229aaab49ffe05107c9d28 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 4, 2015 at 3:07 PM, Eric Rescorla wrote: > > On Wed, Mar 4, 2015 at 12:04 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> What if you jump from an UDP candidate to a TCP candidate? At the same >> time you would be jumping from DTLS to TLS (even for SRTP, where DTLS is >> only used for key management). >> > > No. You do DTLS even with TCP. > And this is still continues to be the same logical channel, i.e. this does not constitute a transport change. _____________ Roman Shpount --089e01229aaab49ffe05107c9d28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On W= ed, Mar 4, 2015 at 3:07 PM, Eric Rescorla <ekr@rtfm.com> wrote:

On Wed, Mar 4, 2015 at 12:04 PM, Christ= er Holmberg <christer.holmberg@ericsson.com> wr= ote:

What if you ju= mp from an UDP candidate to a TCP candidate? At the same time you would be = jumping from DTLS to TLS (even for SRTP, where DTLS is only used for key ma= nagement).

No. You= do DTLS even with TCP.

=C2=A0

And this is still continues to be the same logical channel, i.e. thi= s does not constitute a transport change.

_____________
Roman Shpount

=C2=A0

--089e01229aaab49ffe05107c9d28-- From nobody Wed Mar 4 14:05:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3961A898F for ; Wed, 4 Mar 2015 14:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 p7hOf0ciFHyK for ; Wed, 4 Mar 2015 14:05:51 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1F41A893E for ; Wed, 4 Mar 2015 14:05:50 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-be-54f781bce935 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.DF.07828.CB187F45; Wed, 4 Mar 2015 23:05:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 23:05:47 +0100 From: Christer Holmberg To: Roman Shpount , Eric Rescorla Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Thread-Index: AQHQVqbHfYSbCv5RRE+VguSZdJaU4Z0MmygAgAACNQCAAB9EuP//8M8AgAASNNj//+/xAIAADFaAgAAlg8Q= Date: Wed, 4 Mar 2015 22:05:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D726DC1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RndP4/cQg6MPbCxWvD7HbjHjwlRm i7X/2tkdmD2WLPnJ5DH5cRuzx60pBQHMUVw2Kak5mWWpRfp2CVwZb7ctZCtYr1Yx//5XxgbG g4pdjJwcEgImEvMu3maDsMUkLtxbD2YLCRxhlLj5VKqLkQvIXswoMX/KcZYuRg4ONgELie5/ 2iA1IgLOEl2991hBbGYBdYk7i8+xg9jCAsYS32Y+YYSoMZHY+Pw5E4SdJNF0/SbYfBYBFYkn 75+CxXkFfCUWHdnJDLH3KbPEjkNyIKs4BQIl2ncbg4QZgU77fmoNE8QqcYmmLytZIU4WkFiy 5zwzhC0q8fLxP6hz8iU+fV7OCjFeUOLkzCcsExhFZiFpn4WkbBaSMoi4gcSX97ehbG2JZQtf M0PY+hLd708zIYsvYGRfxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYZQe3/LbawXjwueMh RgEORiUeXoPSbyFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amCMDOjy2ORz5izPUq9VQd+0VVn1fZfGKfXtLr3sL6Cmw3146yfVrTqKpc/ePpo7md1QmWWH quziM8YpZeKWV3c8Phw/4b/R3kod8fWNM3r+G56pzV2nIDOxbO58jqwKnfVzGPYUbRNbXc19 rz012Tsj5Zb8wz2HODuebZSrnzRvlUr0TJbT+cxKLMUZiYZazEXFiQDhsYe1kwIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 22:05:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D726DC1ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I am not objecting to the idea, but as far as I know this "logical channel"= concept is not defined anywhere, so before we can start referring to it it= needs to be anchored somewhere on DTLS level. Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD04/=FD03/=FD2015 22:51 To: Eric Rescorla Cc: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples On Wed, Mar 4, 2015 at 3:07 PM, Eric Rescorla > wrote: On Wed, Mar 4, 2015 at 12:04 PM, Christer Holmberg > wrote: What if you jump from an UDP candidate to a TCP candidate? At the same time= you would be jumping from DTLS to TLS (even for SRTP, where DTLS is only u= sed for key management). No. You do DTLS even with TCP. And this is still continues to be the same logical channel, i.e. this does = not constitute a transport change. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B1D726DC1ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

Hi,

I am not objecting to the idea, but as far as I know this "logical cha= nnel" concept is not defined anywhere, so before we can start referrin= g to it it needs to be anchored somewhere on DTLS level.

Regards,

Christer

Sent from my Windows Phone

From: Roman Shpount
Sent: =FD04= /=FD03/=FD2015 22:51
To: Eric Rescorla
Cc: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [= rtcweb] DTLS, DTLS-SRTP, and 5-tuples

On Wed, Mar 4, 2015 at 3:07 PM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:

On Wed, Mar 4, 2015 at 12:04 PM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:

What if you j= ump from an UDP candidate to a TCP candidate? At the same time you would be= jumping from DTLS to TLS (even for SRTP, where DTLS is only used for key m= anagement).

No. You do DTLS even with TCP.

And this is still continues to be the same logical channel, i.e. this = does not constitute a transport change.

_____________
Roman Shpount

--_000_7594FB04B1934943A5C02806D1A2204B1D726DC1ESESSMB209erics_-- From nobody Wed Mar 4 16:44:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384831A1BE5 for ; Wed, 4 Mar 2015 16:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 Xf4iNwOa35XP for ; Wed, 4 Mar 2015 16:44:22 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAED1A1BF8 for ; Wed, 4 Mar 2015 16:44:21 -0800 (PST) Received: by qcyl6 with SMTP id l6so40741743qcy.2 for ; Wed, 04 Mar 2015 16:44:21 -0800 (PST) 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:content-transfer-encoding; bh=hLn1zi8mnExFJ/T70w2X9/X2OOiCyo2KnycdlJUYEcU=; b=RHx+DuhmWm8cla3BhtNV7U0SSCPxP28miN777et8K2vfIMmZAfhOgKckrMhW9tgT4Z 8scEHMhympbOts0Js6Ffw+kYU06HhQjzIjlJzB08ELPBVrPa34x2s2Rn4N/EF51+a/wL SS50cfTFD4VHikjbcAhMGa6e5LJtLLIOGmWV1e4lxoy+LXGG9oie3G1ettLvLoF6NQHL ku9HpwtO0VO/rPzTbOKXH/J5feGP1vPq0BDDS4uSLpB9wh69EC1F9L3qBGpR0EcOVEB5 7G10KrHSJp3SoLBWsUGq/g6XykdBmgjKTwiWc5D1v8c1JSMFmHnORQUBjxwyajlROua8 C7+g== X-Gm-Message-State: ALoCoQko+DRyP9KFg90DGC/tRKXyEBUsW0ZB/X8vIc69xHEEyxOGuVHMgTYrGb0Jakn6zZ3RwclN X-Received: by 10.55.23.83 with SMTP id i80mr7332144qkh.104.1425516261234; Wed, 04 Mar 2015 16:44:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.200.4 with HTTP; Wed, 4 Mar 2015 16:44:01 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Mar 2015 01:44:01 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 00:44:23 -0000 2015-03-04 23:05 GMT+01:00 Christer Holmberg : > I am not objecting to the idea, but as far as I know this "logical channe= l" > concept is not defined anywhere, so before we can start referring to it i= t > needs to be anchored somewhere on DTLS level. Take into account that when aggressive ICE nomination is being done, a peer sends multiple STUN requests with USE-CANDIDATE at the same time and DTLS ClientHello after each of them. At the end this means that the receiver must be ready to receive DTLS packets via different 5-tuples at the same time, all of them belonging to the same DTLS association/connection. So stating that "if the underlying transport changes the DTLS connection MUST be re-established" seems a unfortunate simplification to me. Said that, I fully agree with you. This kind of "virtual transport" created by ICE must be defined somewhere because existing specs (for example DTLS-SRTP RFC) do not mention ICE at all. --=20 I=C3=B1aki Baz Castillo From nobody Wed Mar 4 22:58:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFD61B29E9 for ; Wed, 4 Mar 2015 22:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 BW1-OPsU4Vlg for ; Wed, 4 Mar 2015 22:58:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646581B29E6 for ; Wed, 4 Mar 2015 22:58:29 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-c0-54f7fe932541 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.9B.07828.39EF7F45; Thu, 5 Mar 2015 07:58:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 07:58:27 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Thread-Index: AQHQVqbHfYSbCv5RRE+VguSZdJaU4Z0MmygAgAACNQCAAB9EuP//8M8AgAASNNj//+/xAIAADFaAgAAlg8SAABtygIAAeWFL Date: Thu, 5 Mar 2015 06:58:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D727570ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3Rnfyv+8hBqc+2ViseH2O3WL6PhuL GRemMlus/dfO7sDica7hPbvHkiU/mTwmP25j9rg1pSCAJYrLJiU1J7MstUjfLoErY+3VxUwF k2wrbmy+y9bAuMW6i5GTQ0LARKKpfwEbhC0mceHeeiCbi0NI4AijxPsd/5kgnMWMEu96drN3 MXJwsAlYSHT/0wZpEBGwkfh34QI7iM0skCWxfv1/ZhBbWMBY4tvMJ4wQNSYSG58/Z4Kw8yR6 ll8Fq2ERUJH42nKWBcTmFfCVeLpzKjPErg8sEsduXQMr4hQIlGjZ+gZsASPQdd9PrWGCWCYu 0fRlJSvE1QISS/acZ4awRSVePv7HClGTL7HxdDsjxAJBiZMzn7BMYBSZhaR9FpKyWUjKZgG9 ySygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgTG3sEtv612MB587niIUYCDUYmHd8Ox7yFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamAs9L/jbPr0fOS7X8uyWy/sWaRcXmNZtfb9ghPOc/Pmv8p0FWfd szt+h9oXx7tmZYZR28WCFwWtnHF11s2bbg/y2t9KifMeWuof9VOho9bwR+zzpG+Wd+crhRgX PLjrfdqF7cPnqL5I1eNW4We/9Xy9vrzZsob1H0tJuFHptUk8Kz/9u5Vxeg6nEktxRqKhFnNR cSIAXYVF7Z4CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:58:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D727570ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHNlbmRpbmcgb2YgbXVsdGlwbGUgQ2xpZW50 SGVsbG9zLCBvbiBkaWZmZXJlbnQgNS10dXBsZXMsIHdvdWxkIHJlcXVpcmUgYSBjaGFuZ2UgdG8g Y29yZSBEVExTIChub3Qgb25seSBEVExTLVNSVFApLCBhbmQgd2hvIGtub3dzIGhvdyBsb25nIHN1 Y2ggd29yayB3b3VsZCB0YWtlLiBEbyB3ZSByZWFsbHkgd2FudCB0byBhZGQgc3VjaCBkZXBlbmRl bmN5IHRvIG91ciBkZWxpdmVyaWVzIGF0IHRoaXMgcG9pbnQ/DQoNCkluIGFkZGl0aW9uLCBkbyB3 ZSBleHBlY3QgZXhpc3RpbmcgRFRMUyBpbXBsZW1lbnRhdGlvbnMgdG8gc3VwcG9ydCB0aGlzPw0K DQpJZiBvbmUgZG9lc24ndCB3YW50IHRvIHJlLWVzdGFibGlzaCBEVExTIHdoZW4ganVtcGluZyBi ZXR3ZWVuIGNhbmRpZGF0ZXMsIGRvZXNuJ3QgaXQgd29yayBieSBjcmVhdGluZyBzZXBhcmF0ZSBE VExTIGNvbm5lY3Rpb25zIGZvciBlYWNoIGNhbmRpZGF0ZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvPG1haWx0bzppYmNAYWxpYXgubmV0 Pg0KU2VudDog4oCOMDUv4oCOMDMv4oCOMjAxNSAwMjo0NA0KVG86IENocmlzdGVyIEhvbG1iZXJn PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogUm9tYW4gU2hwb3Vu dDxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+OyBFcmljIFJlc2NvcmxhPG1haWx0bzpla3JAcnRm bS5jb20+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBEVExTLCBEVExTLVNSVFAsIGFuZCA1LXR1cGxlcw0KDQoyMDE1LTAzLTA0 IDIzOjA1IEdNVCswMTowMCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPjoNCj4gSSBhbSBub3Qgb2JqZWN0aW5nIHRvIHRoZSBpZGVhLCBidXQgYXMgZmFy IGFzIEkga25vdyB0aGlzICJsb2dpY2FsIGNoYW5uZWwiDQo+IGNvbmNlcHQgaXMgbm90IGRlZmlu ZWQgYW55d2hlcmUsIHNvIGJlZm9yZSB3ZSBjYW4gc3RhcnQgcmVmZXJyaW5nIHRvIGl0IGl0DQo+ IG5lZWRzIHRvIGJlIGFuY2hvcmVkIHNvbWV3aGVyZSBvbiBEVExTIGxldmVsLg0KDQpUYWtlIGlu dG8gYWNjb3VudCB0aGF0IHdoZW4gYWdncmVzc2l2ZSBJQ0Ugbm9taW5hdGlvbiBpcyBiZWluZyBk b25lLCBhDQpwZWVyIHNlbmRzIG11bHRpcGxlIFNUVU4gcmVxdWVzdHMgd2l0aCBVU0UtQ0FORElE QVRFIGF0IHRoZSBzYW1lIHRpbWUNCmFuZCBEVExTIENsaWVudEhlbGxvIGFmdGVyIGVhY2ggb2Yg dGhlbS4gQXQgdGhlIGVuZCB0aGlzIG1lYW5zIHRoYXQNCnRoZSByZWNlaXZlciBtdXN0IGJlIHJl YWR5IHRvIHJlY2VpdmUgRFRMUyBwYWNrZXRzIHZpYSBkaWZmZXJlbnQNCjUtdHVwbGVzIGF0IHRo ZSBzYW1lIHRpbWUsIGFsbCBvZiB0aGVtIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBEVExTDQphc3Nv Y2lhdGlvbi9jb25uZWN0aW9uLg0KDQpTbyBzdGF0aW5nIHRoYXQgImlmIHRoZSB1bmRlcmx5aW5n IHRyYW5zcG9ydCBjaGFuZ2VzIHRoZSBEVExTDQpjb25uZWN0aW9uIE1VU1QgYmUgcmUtZXN0YWJs aXNoZWQiIHNlZW1zIGEgdW5mb3J0dW5hdGUgc2ltcGxpZmljYXRpb24NCnRvIG1lLg0KDQpTYWlk IHRoYXQsIEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UuIFRoaXMga2luZCBvZiAidmlydHVhbCB0cmFu c3BvcnQiDQpjcmVhdGVkIGJ5IElDRSBtdXN0IGJlIGRlZmluZWQgc29tZXdoZXJlIGJlY2F1c2Ug ZXhpc3Rpbmcgc3BlY3MgKGZvcg0KZXhhbXBsZSBEVExTLVNSVFAgUkZDKSBkbyBub3QgbWVudGlv biBJQ0UgYXQgYWxsLg0KDQotLQ0KScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D727570ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGksPGJyPg0KPGJyPg0KQXMgZmFyIGFz IEkgdW5kZXJzdGFuZCwgc2VuZGluZyBvZiBtdWx0aXBsZSBDbGllbnRIZWxsb3MsIG9uIGRpZmZl cmVudCA1LXR1cGxlcywgd291bGQgcmVxdWlyZSBhIGNoYW5nZSB0byBjb3JlIERUTFMgKG5vdCBv bmx5IERUTFMtU1JUUCksIGFuZCB3aG8ga25vd3MgaG93IGxvbmcgc3VjaCB3b3JrIHdvdWxkIHRh a2UuIERvIHdlIHJlYWxseSB3YW50IHRvIGFkZCBzdWNoIGRlcGVuZGVuY3kgdG8gb3VyIGRlbGl2 ZXJpZXMgYXQgdGhpcyBwb2ludD88YnI+DQo8YnI+DQpJbiBhZGRpdGlvbiwgZG8gd2UgZXhwZWN0 IGV4aXN0aW5nIERUTFMgaW1wbGVtZW50YXRpb25zIHRvIHN1cHBvcnQgdGhpcz8gPGJyPg0KPGJy Pg0KSWYgb25lIGRvZXNuJ3Qgd2FudCB0byByZS1lc3RhYmxpc2ggRFRMUyB3aGVuIGp1bXBpbmcg YmV0d2VlbiBjYW5kaWRhdGVzLCBkb2Vzbid0IGl0IHdvcmsgYnkgY3JlYXRpbmcgc2VwYXJhdGUg RFRMUyBjb25uZWN0aW9ucyBmb3IgZWFjaCBjYW5kaWRhdGU/DQo8YnI+DQo8YnI+DQpSZWdhcmRz LDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6 Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiPknD sWFraSBCYXogQ2FzdGlsbG88L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5T ZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMXB0Ij7igI4wNS/igI4wMy/igI4yMDE1IDAyOjQ0PC9zcGFuPjxicj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 OyBmb250LXdlaWdodDpib2xkIj5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+PC9zcGFuPjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRv OnJvbWFuQHRlbHVyaXguY29tIj5Sb21hbiBTaHBvdW50PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iPkVyaWMgUmVzY29ybGE8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbcnRjd2ViXSBEVExTLCBEVExTLVNSVFAs IGFuZCA1LXR1cGxlczwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRl eHQiPjIwMTUtMDMtMDQgMjM6MDUgR01UJiM0MzswMTowMCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozo8YnI+DQomZ3Q7IEkgYW0gbm90IG9i amVjdGluZyB0byB0aGUgaWRlYSwgYnV0IGFzIGZhciBhcyBJIGtub3cgdGhpcyAmcXVvdDtsb2dp Y2FsIGNoYW5uZWwmcXVvdDs8YnI+DQomZ3Q7IGNvbmNlcHQgaXMgbm90IGRlZmluZWQgYW55d2hl cmUsIHNvIGJlZm9yZSB3ZSBjYW4gc3RhcnQgcmVmZXJyaW5nIHRvIGl0IGl0PGJyPg0KJmd0OyBu ZWVkcyB0byBiZSBhbmNob3JlZCBzb21ld2hlcmUgb24gRFRMUyBsZXZlbC48YnI+DQo8YnI+DQpU YWtlIGludG8gYWNjb3VudCB0aGF0IHdoZW4gYWdncmVzc2l2ZSBJQ0Ugbm9taW5hdGlvbiBpcyBi ZWluZyBkb25lLCBhPGJyPg0KcGVlciBzZW5kcyBtdWx0aXBsZSBTVFVOIHJlcXVlc3RzIHdpdGgg VVNFLUNBTkRJREFURSBhdCB0aGUgc2FtZSB0aW1lPGJyPg0KYW5kIERUTFMgQ2xpZW50SGVsbG8g YWZ0ZXIgZWFjaCBvZiB0aGVtLiBBdCB0aGUgZW5kIHRoaXMgbWVhbnMgdGhhdDxicj4NCnRoZSBy ZWNlaXZlciBtdXN0IGJlIHJlYWR5IHRvIHJlY2VpdmUgRFRMUyBwYWNrZXRzIHZpYSBkaWZmZXJl bnQ8YnI+DQo1LXR1cGxlcyBhdCB0aGUgc2FtZSB0aW1lLCBhbGwgb2YgdGhlbSBiZWxvbmdpbmcg dG8gdGhlIHNhbWUgRFRMUzxicj4NCmFzc29jaWF0aW9uL2Nvbm5lY3Rpb24uPGJyPg0KPGJyPg0K U28gc3RhdGluZyB0aGF0ICZxdW90O2lmIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBjaGFuZ2Vz IHRoZSBEVExTPGJyPg0KY29ubmVjdGlvbiBNVVNUIGJlIHJlLWVzdGFibGlzaGVkJnF1b3Q7IHNl ZW1zIGEgdW5mb3J0dW5hdGUgc2ltcGxpZmljYXRpb248YnI+DQp0byBtZS48YnI+DQo8YnI+DQpT YWlkIHRoYXQsIEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UuIFRoaXMga2luZCBvZiAmcXVvdDt2aXJ0 dWFsIHRyYW5zcG9ydCZxdW90Ozxicj4NCmNyZWF0ZWQgYnkgSUNFIG11c3QgYmUgZGVmaW5lZCBz b21ld2hlcmUgYmVjYXVzZSBleGlzdGluZyBzcGVjcyAoZm9yPGJyPg0KZXhhbXBsZSBEVExTLVNS VFAgUkZDKSBkbyBub3QgbWVudGlvbiBJQ0UgYXQgYWxsLjxicj4NCjxicj4NCi0tIDxicj4NCknD sWFraSBCYXogQ2FzdGlsbG88YnI+DQombHQ7aWJjQGFsaWF4Lm5ldCZndDs8YnI+DQo8L2Rpdj4N Cjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D727570ESESSMB209erics_-- From nobody Thu Mar 5 01:53:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3051A8783 for ; Thu, 5 Mar 2015 01:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 Y0AIz5pFWRzQ for ; Thu, 5 Mar 2015 01:53:05 -0800 (PST) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA621A8776 for ; Thu, 5 Mar 2015 01:53:05 -0800 (PST) Received: by qgdz60 with SMTP id z60so4264257qgd.1 for ; Thu, 05 Mar 2015 01:53:05 -0800 (PST) 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:content-transfer-encoding; bh=jsHm7LeuiKMD0J8bwWeClwkPgnqUNj36NwdzIeaw1YQ=; b=KxEJ9FHY61E1BMisW3M1/BTtSp+kLtBEDLQVt7sZcwzIgfuWxfQWrDXHBocHFkuoOe 46/+frZJEzxbPYv/ESnFOu8k0pOs+B9k/WVB0N06WAHU8IFOsr5+OJv0JtDOV0zZVBh+ LKkUEmniw8PbAfUNmegD86K4+sMtICEqpIXwvqXSjZeUKfl/QMf/4cihaAG+Vef0Q0OE 2kCQOp1IxHq1nkz73WjjTcYtOtgpfFeQxfRghwKMe4CcSuQUGZg8duHo1kJd2vIUhgMf bNXyD8fG2u0Nz3csmrm5SCS5EQlaWu0lIroNjSqveQxu9AwZj0Hk6qjRCOzmeOshJubg BrGA== X-Gm-Message-State: ALoCoQkhaYZG1dzqT9ugzHSdgoyNAlTHSPc4GvZaUcSjWwev+hRVhsNujLCHACl0TfmR7AicLltf X-Received: by 10.229.139.194 with SMTP id f2mr11723371qcu.14.1425549184912; Thu, 05 Mar 2015 01:53:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.200.4 with HTTP; Thu, 5 Mar 2015 01:52:44 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Mar 2015 10:52:44 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 09:53:07 -0000 2015-03-05 7:58 GMT+01:00 Christer Holmberg : > As far as I understand, sending of multiple ClientHellos, on different > 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), and w= ho > knows how long such work would take. Do we really want to add such > dependency to our deliveries at this point? Sorry, I think I didn't explain well. It is not about multiple DTLS connections, but about the fact that DTLS packets belonging to the *same* DTLS connection/association can be carried over different 5-tuples. This may happen during agressive ICE nomination in which media (so the DTLS ClientHello) follows the USE-CANDIDATE Binding request without even waiting for a response. > In addition, do we expect existing DTLS implementations to support this? There is nothing new to implement in DTLS libraries. It is just the the DTLS user must not assume a single and fixed 5-tuple > If one doesn't want to re-establish DTLS when jumping between candidates, > doesn't it work by creating separate DTLS connections for each candidate? This subject has been heavily discussed time ago: http://www.ietf.org/mail-archive/web/mmusic/current/msg13637.html No, there MUST NOT be separate DTLS connection for each candidate-pair. Regards. --=20 I=C3=B1aki Baz Castillo From nobody Thu Mar 5 02:10:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863261A0383 for ; Thu, 5 Mar 2015 02:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 B3LeD_ggLsmZ for ; Thu, 5 Mar 2015 02:10:20 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2141A017F for ; Thu, 5 Mar 2015 02:10:20 -0800 (PST) Received: by iecar1 with SMTP id ar1so75060931iec.11 for ; Thu, 05 Mar 2015 02:10:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JuwSloeldw/7Y239FjGBy5xRrPpVT6iUm2f9DEO995c=; b=Iiuo3RU5WDeEMvSrZBbS49M7OFPGTOrAJn8yu7Aj5TE4EUgSDlKaaL4hW/gBuNyKyQ 9WVFNHhsWdIpZHVStHeHHL8AUDISHHCoDaV7AsmY5eFMEfyq+0MELSZKRZRvI8l3+By3 fD6KX4945NapwLubM50Y0172nLGE2cTWc3h8AJReD/yyQTzmXhWD9nZ90pYcrehqv73i sU0VEOdGQndwzEri8ouqEKTRBLGnAzvsnbmP2EZWRkdBBg5QjbvmarDD2VF8juvpNvKS ff6S0cJTya7BpeeybmY0jZAuLFSZmWVY6jQfF6ZxQKJDD7cHxR4BsQdqtBp/3d4DGhDf 8wBA== X-Gm-Message-State: ALoCoQkR7cL2T6tUkYzYTweu0vLxvJHTn3QvABPj/Vt6IMFgUwwiT18CAACaE1V9VwaxwlEsIubI X-Received: by 10.50.79.161 with SMTP id k1mr18898922igx.14.1425550219657; Thu, 05 Mar 2015 02:10:19 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id h15sm4688803ioh.27.2015.03.05.02.10.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 02:10:18 -0800 (PST) Received: by igbhn18 with SMTP id hn18so44564953igb.2 for ; Thu, 05 Mar 2015 02:10:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.247.68 with SMTP id mb4mr2613401icb.2.1425550217313; Thu, 05 Mar 2015 02:10:17 -0800 (PST) Received: by 10.36.20.10 with HTTP; Thu, 5 Mar 2015 02:10:17 -0800 (PST) In-Reply-To: References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> Date: Thu, 5 Mar 2015 05:10:17 -0500 Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=90e6ba1ef2ea50071a051087c63d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:10:21 -0000 --90e6ba1ef2ea50071a051087c63d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 4, 2015 at 7:44 PM, I=C3=B1aki Baz Castillo wro= te: > Take into account that when aggressive ICE nomination is being done, a > peer sends multiple STUN requests with USE-CANDIDATE at the same time > and DTLS ClientHello after each of them. At the end this means that > the receiver must be ready to receive DTLS packets via different > 5-tuples at the same time, all of them belonging to the same DTLS > association/connection. > I am not sure this is entirely correct. My assumption was that during aggressive ICE nomination, an end point will send DTLS ClientHello over the first candidate pair where ICE connectivity check succeeds. The end point should be ready to receive DTLS messages over any ICE candidate pair. If end point does not receive response to DTLS ClientHello it should re-transmit ClientHello over the highest priority ICE candidate pair at the time of the re-transmission. I do not think there is any need to send multiple DTLS ClientHello messages at the same time over multiple candidate pairs. In other words, an end point should treat ICE as a single virtual channel, where data is transmitted over the highest priority ICE candidate pair for which the connectivity check succeeded and process data received from any non-pruned ICE candidate pair. There is no need to trombone the data over all the candidate pairs when it is being sent out. This should fit nicely with existing DTLS implementations. _____________ Roman Shpount --90e6ba1ef2ea50071a051087c63d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On W= ed, Mar 4, 2015 at 7:44 PM, I=C3=B1aki Baz Castillo <<= a href=3D"mailto:ibc@aliax.net" target=3D"_blank">ibc@aliax.net> wrote:

Take into account that when aggressive ICE n= omination is being done, a
peer sends multiple STUN requests with USE-CANDIDATE at the same time
and DTLS ClientHello after each of them. At the end this means that
the receiver must be ready to receive DTLS packets via different
5-tuples at the same time, all of them belonging to the same DTLS
association/connection.

I am not sure t= his is entirely correct.=C2=A0 My assumption was that during aggressive ICE= nomination, an end point will send DTLS ClientHello over the first candida= te pair where ICE connectivity check succeeds. The end point should be read= y to receive DTLS messages over any ICE candidate pair. If end point does n= ot receive response to DTLS ClientHello it should re-transmit ClientHello o= ver the highest priority ICE candidate pair at the time of the re-transmiss= ion. I do not think there is any need to send multiple DTLS ClientHello mes= sages at the same time over multiple candidate pairs. In other words, an en= d point should treat ICE as a single virtual channel, where data is transmi= tted over the highest priority ICE candidate pair for which the connectivit= y check succeeded and process data received from any non-pruned ICE candida= te pair. There is no need to trombone the data over all the candidate pairs= when it is being sent out. This should fit nicely with existing DTLS imple= mentations.

_____________
Roman= Shpount

=C2=A0

--90e6ba1ef2ea50071a051087c63d-- From nobody Thu Mar 5 02:14:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5A11A8773 for ; Thu, 5 Mar 2015 02:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 LaH74yyf3chp for ; Thu, 5 Mar 2015 02:14:43 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3494F1A8748 for ; Thu, 5 Mar 2015 02:14:43 -0800 (PST) Received: by iecar1 with SMTP id ar1so75085433iec.11 for ; Thu, 05 Mar 2015 02:14:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P548fOQGJZTLNn80QMtprkcWGgz/m7sxm1Ors7kwP2o=; b=HK0aO09E/vi3J1tVWKOU9TFTtiOJ95ja3rmKxhIF1QkGs2btZihlRB8OocUrDhGgO4 +Xae1FV9DB6BuWZ+IbgAs6F8Y16IiIqOkZZGVxu+1OGoZ+/ditw41IZeSEcbXozIx5Tr BVgYxA0UmcYM9nQFgWlGoJ+CLHa90DesXjieuwqBAs8SfRjRVCS0dR45RWTuecUT8stD d//FeVIYW2I0G1aPEJr34CE1CA1tRLv+e/jrI7W3DYil+f70cSrx0dcoPgHEfJWoeB20 bjvYnuqgHHwq4oMbrBVQF51sczekBfNGmzO1SJC/qlXwF+kFWZyudRTwVGmuO4J555qC yf8A== X-Gm-Message-State: ALoCoQm7OSZ6vFxyRDI7ymAElS49tDUvORx/rnNZZe2dBFRrj+DjYgJBlDj5gi0O8GZhz22Zyb/A X-Received: by 10.50.49.43 with SMTP id r11mr46246383ign.18.1425550482653; Thu, 05 Mar 2015 02:14:42 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by mx.google.com with ESMTPSA id 130sm4707635ioz.10.2015.03.05.02.14.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 02:14:42 -0800 (PST) Received: by igal13 with SMTP id l13so40722498iga.1 for ; Thu, 05 Mar 2015 02:14:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.167.3 with SMTP id q3mr18798493ioe.18.1425550479891; Thu, 05 Mar 2015 02:14:39 -0800 (PST) Received: by 10.36.20.10 with HTTP; Thu, 5 Mar 2015 02:14:39 -0800 (PST) In-Reply-To: References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se> Date: Thu, 5 Mar 2015 05:14:39 -0500 Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a1141ca9ef6a4ff051087d5fe Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:14:44 -0000 --001a1141ca9ef6a4ff051087d5fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 5, 2015 at 4:52 AM, I=C3=B1aki Baz Castillo wro= te: > 2015-03-05 7:58 GMT+01:00 Christer Holmberg < > christer.holmberg@ericsson.com>: > > As far as I understand, sending of multiple ClientHellos, on different > > 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), and > who > > knows how long such work would take. Do we really want to add such > > dependency to our deliveries at this point? > > Sorry, I think I didn't explain well. > > It is not about multiple DTLS connections, but about the fact that > DTLS packets belonging to the *same* DTLS connection/association can > be carried over different 5-tuples. This may happen during agressive > ICE nomination in which media (so the DTLS ClientHello) follows the > USE-CANDIDATE Binding request without even waiting for a response. > When was it agreed that DTLS ClientHello can be sent before the connectivity check succeeded? I understand that this will increase the connection setup time, but I though that no data should be sent before the connectivity check response (consent) from the remote party. > In addition, do we expect existing DTLS implementations to support this? > > There is nothing new to implement in DTLS libraries. It is just the > the DTLS user must not assume a single and fixed 5-tuple > > > > If one doesn't want to re-establish DTLS when jumping between candidate= s, > > doesn't it work by creating separate DTLS connections for each candidat= e? > > This subject has been heavily discussed time ago: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg13637.html > > No, there MUST NOT be separate DTLS connection for each candidate-pair. > Agreed _____________ Roman Shpount --001a1141ca9ef6a4ff051087d5fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= hu, Mar 5, 2015 at 4:52 AM, I=C3=B1aki Baz Castillo <<= a href=3D"mailto:ibc@aliax.net" target=3D"_blank">ibc@aliax.net> wrote:

2015-03-05 7:58 GMT+01:00 C= hrister Holmberg <chri= ster.holmberg@ericsson.com>:
> As far as I understand, sending of multiple ClientHellos, on different=
> 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), an= d who
> knows how long such work would take. Do we really want to add such
> dependency to our deliveries at this point?

Sorry, I think I didn't explain well.

It is not about multiple DTLS connections, but about the fact that
DTLS packets belonging to the *same* DTLS connection/association can
be carried over different 5-tuples. This may happen during agressive
ICE nomination in which media (so the DTLS ClientHello) follows the
USE-CANDIDATE Binding request without even waiting for a response.

When was it agreed that DTLS ClientHello can be= sent before the connectivity check succeeded? I understand that this will = increase the connection setup time, but I though that no data should be sen= t before the connectivity check response (consent) from the remote party.

> In addition, do we expect existing DTLS implementations to support thi= s?

There is nothing new to implement in DTLS libraries. It is just the<= br> the DTLS user must not assume a single and fixed 5-tuple

> If one doesn't want to re-establish DTLS when jumping between cand= idates,
> doesn't it work by creating separate DTLS connections for each can= didate?

This subject has been heavily discussed time ago:

http://www.ietf.org/mail-archive/web/mmusic/current/ms= g13637.html

No, there MUST NOT be separate DTLS connection for each candidate-pair.
=

Agreed
_____________
Roman Shpount
=C2=A0

--001a1141ca9ef6a4ff051087d5fe-- From nobody Thu Mar 5 02:25:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2E71A1A92 for ; Thu, 5 Mar 2015 02:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 v3cUKAFiPgRt for ; Thu, 5 Mar 2015 02:25:10 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637C11A1A6C for ; Thu, 5 Mar 2015 02:25:09 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-3d-54f82f037a74 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 16.0E.04032.30F28F45; Thu, 5 Mar 2015 11:25:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 11:25:06 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples Thread-Index: AQHQVqbHfYSbCv5RRE+VguSZdJaU4Z0MmygAgAACNQCAAB9EuP//8M8AgAASNNj//+/xAIAADFaAgAAlg8SAABtygIAAeWFLgAAf7wCAABaJgA== Date: Thu, 5 Mar 2015 10:25:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D728258@ESESSMB209.ericsson.se> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+JvjS6z/o8Qg91flS1WvD7HbjF9n43F jAtTmS3W/mtnd2DxONfwnt1jyZKfTB6TH7cxe9yaUhDAEsVlk5Kak1mWWqRvl8CVMXnZYdaC DRwVL/uDGhincHQxcnJICJhIfHjzix3CFpO4cG89WxcjF4eQwBFGiVV72pkgnMWMEvd272Pu YuTgYBOwkOj+pw3SICJgI/HvwgWwZmaBLIn16/8zg9jCAsYS32Y+YYSoMZHY+Pw5E4RdJ/Fm xm6wGhYBFYnO7zvBbF4BX4ktt7qgdv1llZg49wUTyC5OgUCJ3XuKQWoYgY77fmoNE8QucYlb T+YzQRwtILFkz3lmCFtU4uXjf6wQtpLE2sPbWUDGMAtoSqzfpQ/RqigxpfshO8RaQYmTM5+w TGAUm4Vk6iyEjllIOmYh6VjAyLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzC6Dm75bbCD 8eVzx0OMAhyMSjy8G459DxFiTSwrrsw9xCjNwaIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2Nq78XszhvrfpmGXL5YHW1R3nV4aVP2ahdHGTUfrVkeorkvD/aw/J8edsD6wHXH MN7n2zviY3t3sbRsfFgfMXWy9a0tzvLHTUo/alkFhHz7vzvBTeWJ7drKRr7ty/Ivy08oE9r1 j6HEbtkb7eCrG3T2ThcNyfpivPj3W/ZN63X8xZgmqjAnf1JiKc5INNRiLipOBABm1pv4jwIA AA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe:

<= div class=3D"gmail_extra">
Thanks=

--
Jos=C3=A9 Luis Mill=C3=A1n

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

--20cf301d3a286738200510de8ab7-- From nobody Mon Mar 9 10:48:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FCF1A8AA7 for ; Mon, 9 Mar 2015 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.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, 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 xiEFEKYp8k3e for ; Mon, 9 Mar 2015 10:48:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843531A908C for ; Mon, 9 Mar 2015 10:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1767; q=dns/txt; s=iport; t=1425923305; x=1427132905; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hh+9qmXv86O4BhIbu0yePX9jIBYc2Ovx0xdYi4H6cqU=; b=UdoZ4Zwsn7zjmL7wJLE83ZI1NcrbX/ay9t4EcQmUqZRtif17mspr8Axm +Vue8zUEelxdrKM9P5qffQXn65Mm+A8E/SJwq8WzQYSjxj3yhcNFfV7KM HzYQCynDv0/MBQ0d5ToG+61OqmbX/War5kakeMuMzJwEzlOFiOkkdruAK w=; X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208";a="130297597" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 09 Mar 2015 17:48:25 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29Hm6hJ026665; Mon, 9 Mar 2015 17:48:23 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Mon, 9 Mar 2015 09:28:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2F467A7E-7A6C-4B1B-985A-0D9C089BE973@cisco.com> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se>

To: Jonathan Lennox X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:48:26 -0000 > On Mar 5, 2015, at 8:22 AM, Jonathan Lennox = wrote: >=20 >=20 > On Mar 5, 2015, at 5:14 AM, Roman Shpount wrote: >=20 >> On Thu, Mar 5, 2015 at 4:52 AM, I=F1aki Baz Castillo = wrote: >> 2015-03-05 7:58 GMT+01:00 Christer Holmberg = : >> > As far as I understand, sending of multiple ClientHellos, on = different >> > 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), = and who >> > knows how long such work would take. Do we really want to add such >> > dependency to our deliveries at this point? >>=20 >> Sorry, I think I didn't explain well. >>=20 >> It is not about multiple DTLS connections, but about the fact that >> DTLS packets belonging to the *same* DTLS connection/association can >> be carried over different 5-tuples. This may happen during agressive >> ICE nomination in which media (so the DTLS ClientHello) follows the >> USE-CANDIDATE Binding request without even waiting for a response. >>=20 >> When was it agreed that DTLS ClientHello can be sent before the = connectivity check succeeded? I understand that this will increase the = connection setup time, but I though that no data should be sent before = the connectivity check response (consent) from the remote party. >=20 > As I understand the current rough consensus, the endpoint has to have = received a successful response to a connectivity check on the 5-tuple, = proving consent, but it doesn=92t have to have received (or sent) a = check with a USE-CANDIDATE attribute in it yet. >=20 > This was the outcome of our discussion =93merging" regular and = aggressive ICE nomination. That matches my understanding of how things work.=20= From nobody Mon Mar 9 16:24:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219DA1ACDE4; Mon, 9 Mar 2015 16:24:04 -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 YUp9a5zGuFWI; Mon, 9 Mar 2015 16:24:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB79D1A89A5; Mon, 9 Mar 2015 16:24:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309232402.3275.41912.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 16:24:02 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:24:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-09.txt Pages : 73 Date : 2015-03-09 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-09 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 9 16:36:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7406C1A90BC for ; Mon, 9 Mar 2015 16:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vzqFP8gWxmxA for ; Mon, 9 Mar 2015 16:36:23 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60F31ACDAE for ; Mon, 9 Mar 2015 16:36:21 -0700 (PDT) Received: by iecrp18 with SMTP id rp18so40026242iec.7 for ; Mon, 09 Mar 2015 16:36:21 -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=5k6ZhCEWaan3eRjQyl9z0kqBUtKj8SR8HglPR5dTFME=; b=NXD1Dzx8ml8n+W8FN/Q4bsenF4sdDhlVwOK8jSxa5P7vBRNfbo2qFnS/h3dNBx8XH4 AStzZVQvN/RmfYewlzOPyUkCrrPFoPgtfTlJHjOo03ZT5OjrnaAiC6qdAWjd8hFR9vRC QYvEZIMDLNeu3C4P4k/s/vh9o59amvPAHsDY3gLeDPdP5WQAd8Fd9t9Nkqiw3bi2rOYz 08MxjX4kTNrQTX+eUg8eeP1i9h51WB2QjOLxCaU6X4GXtLCYGy+nWz0q7lhiA6OJ0CL0 NFxN0NTmayKcD4xWsy28ZMR9W4UUSOnVRGJYaCrwOWCmaan6gIhq5SlbI42ONq3FJE3/ N/Pg== 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=5k6ZhCEWaan3eRjQyl9z0kqBUtKj8SR8HglPR5dTFME=; b=RPtsDGkSuSM+91m6v9wHbuzBlh8CtkXHlSAIEMtcmBoCCDD4CgdDRJcV7b5EXVHFJz +yn3SzwPSWQKJGxc44iMYvf+y0UIpPKNmKJDeZwPDtLq99mp1i4Wf/413LubJWyjPtQB CZtaXvQa+COQ16LE0Oc+Qhq2t67z+DQ9WMeiIxy7wyJH8GE+BNzjyDzf9vBRxp2eLlLk tn3ODamamw6fbWRQtFTd9Kp7tIqH2EamRLzWMR7Z9emCKKlZXvYshn0Y+oItYDDiV3nH Z+7Qpr+YJRvLuaTcGi8pHN1T0McpFbkcYn53Fe7+bQJH0wHQveq0y3bE68OI1MR5UNv8 Ri0Q== X-Gm-Message-State: ALoCoQnUxP3wLb9CroIUK0oRe+B8wCFDe7XGqh1MHZRLyxCqlQx0C52eAVGsrGO2PWgQ0lc+OED2 X-Received: by 10.42.119.202 with SMTP id c10mr23655448icr.4.1425944181148; Mon, 09 Mar 2015 16:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Mon, 9 Mar 2015 16:36:01 -0700 (PDT) In-Reply-To: <20150309044740.4941.89516.idtracker@ietfa.amsl.com> References: <20150309044740.4941.89516.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 9 Mar 2015 16:36:01 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=90e6ba61465a6336970510e38028 Archived-At: Cc: "rtcweb@ietf.org" , i-d-announce@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:36:24 -0000 --90e6ba61465a6336970510e38028 Content-Type: text/plain; charset=UTF-8 This version incorporates the feedback from Honolulu, as well as several comments from the list. The Honolulu feedback suggested removing support for redundant audio with codecs like PCMU, but I did get a request for this on the list, so I left it in. On Sun, Mar 8, 2015 at 9:47 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : WebRTC Forward Error Correction Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-fec-01.txt > Pages : 7 > Date : 2015-03-08 > > Abstract: > This document provides information and requirements for how Forward > Error Correction (FEC) should be used by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --90e6ba61465a6336970510e38028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This version incorporates the feedback from Honolulu, as w= ell as several comments from the list.

The Honolulu feed= back suggested removing support for redundant audio with codecs like PCMU, = but I did get a request for this on the list, so I left it in.

<= div class=3D"gmail_extra">

On Sun, Mar 8, 201= 5 at 9:47 PM, <internet-drafts@ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-08

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-fec-01<= /a>

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/

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

--90e6ba61465a6336970510e38028-- From nobody Mon Mar 9 16:41:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7B21A01D5 for ; Mon, 9 Mar 2015 16:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mKTe8q4kNVsr for ; Mon, 9 Mar 2015 16:41:56 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7AA1A88A6 for ; Mon, 9 Mar 2015 16:41:56 -0700 (PDT) Received: by iecrl12 with SMTP id rl12so25303473iec.8 for ; Mon, 09 Mar 2015 16:41:55 -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=CWoPYczfWhLPlwvEaa5sr7Iwbu78VP5Uu/X7XcetI0A=; b=iPhxncb83lnI5OPhDwy2+inx4hoez0PH+9LReUuADW/V5LJkYdT8Adlz9SBZaw3epw HnttXA/VDB1peiAod/nZQFBxaLVNc+TldwyBDs31Dag/2cGKf4/4iTdrcUrSBaFnxUFr +d8M6DXdf8JD0ea73hOYShP7LvziXVWAgFXPd+grgRz2bWuzoAxWFQeI1FmtIGyl5aaM wFZM/oJyuRMyprNmIf6PuysyH7ClWgICYSdY8Z1rl6hTpjgkwuijRVKFa3Xp/u+GlwAQ 3iJQw0fhjAQH77QYXcWp2MNjH0N81G6COEURrCDebHVAsbYaIvY70TE5VmgXn7DTazWz yqvA== 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=CWoPYczfWhLPlwvEaa5sr7Iwbu78VP5Uu/X7XcetI0A=; b=N6uHeAci5vDNhjnKawt0xYSeW6CG1zc5JazKPMVuFbtQxC7W5SJdOl+J7BKAPjBAP/ hbklQABqCpIkR33FZIlJspUUNZjtpcdl/uWxeyZcsM7nH5JKpttVXSROxQbPBlCN7IG7 vxqlqIwI11BXkkdYAFgcxovGcsbnDxRdP1bWYW02FO7dA5xaAq5E1CQ9MSfrvEOyQppE 0bWFOif0B+BPIiz5iZW4CUbc/WWHAwFes4xysYfz5KF8v5N8gTIjgy3nf9mCwvj4zspB JqOSgFEl2R6+wBvmkd1Xx1OLonYU+8n0hxpKfhdW810n5U1qQMr6Co7xWIQyJLhEIxQu uKVg== X-Gm-Message-State: ALoCoQmPL7b/NiWrF8E3DaaLMSabIElQI8v8Nl2C5IW5rMOLuq0rjASSjbyQKAn2X7UbPNo/tAcc X-Received: by 10.107.15.155 with SMTP id 27mr33765171iop.49.1425944515804; Mon, 09 Mar 2015 16:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Mon, 9 Mar 2015 16:41:34 -0700 (PDT) In-Reply-To: <2F467A7E-7A6C-4B1B-985A-0D9C089BE973@cisco.com> References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se>

<2F467A7E-7A6C-4B1B-985A-0D9C089BE973@cisco.com> From: Justin Uberti Date: Mon, 9 Mar 2015 16:41:34 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a113eeca855a22a0510e3940e Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:41:58 -0000 --001a113eeca855a22a0510e3940e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2015 at 8:28 AM, Cullen Jennings wrote: > > > On Mar 5, 2015, at 8:22 AM, Jonathan Lennox wrote: > > > > > > On Mar 5, 2015, at 5:14 AM, Roman Shpount wrote: > > > >> On Thu, Mar 5, 2015 at 4:52 AM, I=C3=B1aki Baz Castillo > wrote: > >> 2015-03-05 7:58 GMT+01:00 Christer Holmberg < > christer.holmberg@ericsson.com>: > >> > As far as I understand, sending of multiple ClientHellos, on differe= nt > >> > 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), > and who > >> > knows how long such work would take. Do we really want to add such > >> > dependency to our deliveries at this point? > >> > >> Sorry, I think I didn't explain well. > >> > >> It is not about multiple DTLS connections, but about the fact that > >> DTLS packets belonging to the *same* DTLS connection/association can > >> be carried over different 5-tuples. This may happen during agressive > >> ICE nomination in which media (so the DTLS ClientHello) follows the > >> USE-CANDIDATE Binding request without even waiting for a response. > >> > >> When was it agreed that DTLS ClientHello can be sent before the > connectivity check succeeded? I understand that this will increase the > connection setup time, but I though that no data should be sent before th= e > connectivity check response (consent) from the remote party. > > > > As I understand the current rough consensus, the endpoint has to have > received a successful response to a connectivity check on the 5-tuple, > proving consent, but it doesn=E2=80=99t have to have received (or sent) a= check > with a USE-CANDIDATE attribute in it yet. > > > > This was the outcome of our discussion =E2=80=9Cmerging" regular and ag= gressive > ICE nomination. > > That matches my understanding of how things work. > > That discussion is now codified in a new draft, https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00. To handle the issue raised by the OP, I think we should either 1) Fix the DTLS draft (and any others) to not be bound to a 5-tuple when ICE is used 2) Update ICE-bis to say that any language about 5-tuples is invalidated by ICE, and should be treated as a virtual transport. #2 seems like the simplest path at this point, given that ICE-bis work is underway. --001a113eeca855a22a0510e3940e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2015 at 8:28 AM, Cullen Jennings <<= a href=3D"mailto:fluffy@cisco.com" target=3D"_blank">fluffy@cisco.com&g= t; wrote:

> On Mar 5, 2015, at 8:22 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>
> On Mar 5, 2015, at 5:14 AM, Roman Shpount <roman@telurix.com> wrote:
>
>> On Thu, Mar 5, 2015 at 4:52 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote: >> 2015-03-05 7:58 GMT+01:00 Christer Holmberg <christer.holmberg@ericsso= n.com>:
>> > As far as I understand, sending of multiple ClientHellos, on = different
>> > 5-tuples, would require a change to core DTLS (not only DTLS-= SRTP), and who
>> > knows how long such work would take. Do we really want to add= such
>> > dependency to our deliveries at this point?
>>
>> Sorry, I think I didn't explain well.
>>
>> It is not about multiple DTLS connections, but about the fact that=
>> DTLS packets belonging to the *same* DTLS connection/association c= an
>> be carried over different 5-tuples. This may happen during agressi= ve
>> ICE nomination in which media (so the DTLS ClientHello) follows th= e
>> USE-CANDIDATE Binding request without even waiting for a response.=
>>
>> When was it agreed that DTLS ClientHello can be sent before the co= nnectivity check succeeded? I understand that this will increase the connec= tion setup time, but I though that no data should be sent before the connec= tivity check response (consent) from the remote party.
>
> As I understand the current rough consensus, the endpoint has to have = received a successful response to a connectivity check on the 5-tuple, prov= ing consent, but it doesn=E2=80=99t have to have received (or sent) a check= with a USE-CANDIDATE attribute in it yet.
>
> This was the outcome of our discussion =E2=80=9Cmerging" regular = and aggressive ICE nomination.

That matches my understanding of how things work.

=C2=A0

That discussio= n is now codified in a new draft, https://tools.ietf.org/html/= draft-uberti-mmusic-nombis-00.

To handle the i= ssue raised by the OP, I think we should either

1) Fix the DTLS d= raft (and any others) to not be bound to a 5-tuple when ICE is used

2) Update ICE-bis to say that any language about 5-tuples is invalidated= by ICE, and should be treated as a virtual transport.

#2 seems like the simplest path at this point, given that ICE-bis work= is underway.

--001a113eeca855a22a0510e3940e-- From nobody Mon Mar 9 17:37:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777F1ABC10 for ; Mon, 9 Mar 2015 17:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 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, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UTuGpsmk5-KN for ; Mon, 9 Mar 2015 17:37:05 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674371ACE56 for ; Mon, 9 Mar 2015 17:36:58 -0700 (PDT) Received: by igbhn18 with SMTP id hn18so26491886igb.2 for ; Mon, 09 Mar 2015 17:36:57 -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:cc :content-type; bh=Nd2Cv0TFi/jjWssTSCD8XofFXPryUARPmpbVs/Nws4Q=; b=XYWvm5bw7R4v35HlTZ2p4lIKfdmI2ULEcIKtKS/am7/DFJ3Gtc0Jf6MELfoT5LRfaf GxABQkIO409Oz0ptZJXTDW+5IoDbk7rWgtW2ZeVwiyALTHEvRvlFwoQzOVT2tTRgdUF6 oa0lMyL7ykIZY6IKs+s5lftP/fEKL9L3/ZkUp3rfY4QRSqWmVWoU9H0edkxYrHxLZHpb zjuU5iqzLjbwMX3DfrwQmy2cTI3RUBY23/ccB7Eu7wYGu1f6c9LeyeDKBSiVGMYv9+2s vNVjOZ0YtJXMlpXM2equhxFXjdIiw1dsea3dssYfQpbd8h+jJxoGJkbMIbeiycbdWCvi Fb1g== 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:cc:content-type; bh=Nd2Cv0TFi/jjWssTSCD8XofFXPryUARPmpbVs/Nws4Q=; b=WFbnmoV95C1XCjgnkSx2+2vxWDXvS5loHvSOvhV27YSNq8ImPa7pBSfTJTUpljeova dGWvUSYUQLstu0OEc9HrchppIsSGQAP7Ch6lRWx8EnyWRd7uyGfdpTSNmlYSxq6k7l3V RqhTtY9ox7e5XFN0rPMgYL/Gw5Jx99IWoR2nZBjxTHUzd9F9Lrb2utX0JlkMbPTUk75Z +3jUeKoveC73oviF2/G/bMLy/dNYAuKMOpaq0VeKp/Kq8F8LEI3oUGCSnX/Wid9CUELR dDTpSG4BgC7XZyXzKhlbzofKMQl3hr5jlCGzT/+8FjcwlXgfFMkGoY708w/Adta+yRA6 Lj6g== X-Gm-Message-State: ALoCoQkZXmT7AGUiHowEX+bafqBr8C6uLen0DhZQ5qvQPDUrMpZBjy/U8OTI+UC+G30fsDhq3diY X-Received: by 10.107.15.155 with SMTP id 27mr33992575iop.49.1425947817786; Mon, 09 Mar 2015 17:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Mon, 9 Mar 2015 17:36:36 -0700 (PDT) In-Reply-To: References: <20150309044740.4941.89516.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 9 Mar 2015 17:36:36 -0700 Message-ID: Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113eeca825f6e30510e45904 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:37:07 -0000 --001a113eeca825f6e30510e45904 Content-Type: text/plain; charset=UTF-8 [fixing cc list] On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti wrote: > This version incorporates the feedback from Honolulu, as well as several > comments from the list. > > The Honolulu feedback suggested removing support for redundant audio with > codecs like PCMU, but I did get a request for this on the list, so I left > it in. > > On Sun, Mar 8, 2015 at 9:47 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Real-Time Communication in WEB-browsers >> Working Group of the IETF. >> >> Title : WebRTC Forward Error Correction Requirements >> Author : Justin Uberti >> Filename : draft-ietf-rtcweb-fec-01.txt >> Pages : 7 >> Date : 2015-03-08 >> >> Abstract: >> This document provides information and requirements for how Forward >> Error Correction (FEC) should be used by WebRTC applications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-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/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --001a113eeca825f6e30510e45904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

[fixing cc list]

On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti <jube= rti@google.com> wrote:

This version incorporates the feedback from Honolulu, as well = as several comments from the list.

The Honolulu feedback= suggested removing support for redundant audio with codecs like PCMU, but = I did get a request for this on the list, so I left it in.

On Sun, Mar 8, 2015 at 9:47 PM, <internet-drafts= @ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-08

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-fec-01<= /a>

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/

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

--001a113eeca825f6e30510e45904-- From nobody Mon Mar 9 17:49:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044561AC41F for ; Mon, 9 Mar 2015 17:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 4pPDwjromOZq for ; Mon, 9 Mar 2015 17:49:50 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423B81A8A84 for ; Mon, 9 Mar 2015 17:49:50 -0700 (PDT) Received: by widfb4 with SMTP id fb4so14982116wid.0 for ; Mon, 09 Mar 2015 17:49:49 -0700 (PDT) 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=fPCfoKtkIp88UtNnMcl1qz7ECU0GV/i23qDb2P9AHZk=; b=R0gqH2BgbNR0niuJHrmZvimhLrg2iSC+qB2LqAz7q5yt3uoWqxXHHx15Ldaoxp0aG8 4I2611G9D7wy1R9iGru/ignpkDbopyZlvyR+4IQM3v6bnM0wM8jUapXXhYWu6Du2YePP WCjz6uTyRK/NiScuLRlx01c8+nx037Ext91cg1uPgH160Ls/2yvNWuiY1Cc0JOGhKfQU mS5onomBSRavdE4FInuYlVVaFfcxo5KX2/AP2wcWJOECSi3uvWdY6q8TzvrqMisxGGnn mOXHHbZcDZW10FiHEkZJM2mz9WCr80/C/GzeNkhLmAZwYAmvfFqoiu0Gr8uThMKyXVd5 FOWg== X-Gm-Message-State: ALoCoQnbj+/CvpULTwgpqOdXS8SljAYEJnR19Smff6m4qoSMzHAR6eQbopeyY7ClOWrvbxPlv3iq X-Received: by 10.194.191.228 with SMTP id hb4mr64515740wjc.116.1425948588996; Mon, 09 Mar 2015 17:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 9 Mar 2015 17:49:08 -0700 (PDT) In-Reply-To: References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se>

<2F467A7E-7A6C-4B1B-985A-0D9C089BE973@cisco.com> From: Eric Rescorla Date: Mon, 9 Mar 2015 17:49:08 -0700 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b8750be1d91740510e487cb Archived-At: Cc: Cullen Jennings , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:49:53 -0000 --047d7b8750be1d91740510e487cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2015 at 4:41 PM, Justin Uberti wrote: > > > On Mon, Mar 9, 2015 at 8:28 AM, Cullen Jennings wrote: > >> >> > On Mar 5, 2015, at 8:22 AM, Jonathan Lennox wrote= : >> > >> > >> > On Mar 5, 2015, at 5:14 AM, Roman Shpount wrote: >> > >> >> On Thu, Mar 5, 2015 at 4:52 AM, I=C3=B1aki Baz Castillo >> wrote: >> >> 2015-03-05 7:58 GMT+01:00 Christer Holmberg < >> christer.holmberg@ericsson.com>: >> >> > As far as I understand, sending of multiple ClientHellos, on >> different >> >> > 5-tuples, would require a change to core DTLS (not only DTLS-SRTP), >> and who >> >> > knows how long such work would take. Do we really want to add such >> >> > dependency to our deliveries at this point? >> >> >> >> Sorry, I think I didn't explain well. >> >> >> >> It is not about multiple DTLS connections, but about the fact that >> >> DTLS packets belonging to the *same* DTLS connection/association can >> >> be carried over different 5-tuples. This may happen during agressive >> >> ICE nomination in which media (so the DTLS ClientHello) follows the >> >> USE-CANDIDATE Binding request without even waiting for a response. >> >> >> >> When was it agreed that DTLS ClientHello can be sent before the >> connectivity check succeeded? I understand that this will increase the >> connection setup time, but I though that no data should be sent before t= he >> connectivity check response (consent) from the remote party. >> > >> > As I understand the current rough consensus, the endpoint has to have >> received a successful response to a connectivity check on the 5-tuple, >> proving consent, but it doesn=E2=80=99t have to have received (or sent) = a check >> with a USE-CANDIDATE attribute in it yet. >> > >> > This was the outcome of our discussion =E2=80=9Cmerging" regular and a= ggressive >> ICE nomination. >> >> That matches my understanding of how things work. >> >> > That discussion is now codified in a new draft, > https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00. > > To handle the issue raised by the OP, I think we should either > 1) Fix the DTLS draft (and any others) to not be bound to a 5-tuple when > ICE is used > 2) Update ICE-bis to say that any language about 5-tuples is invalidated > by ICE, and should be treated as a virtual transport. > > #2 seems like the simplest path at this point, given that ICE-bis work is > underway. > #2 seems like the right answer to me. -Ekr _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b8750be1d91740510e487cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2015 at 4:41 PM, Justin Uberti <juberti@google.com= > wrote:

<= div class=3D"gmail_extra">
On Mon, Mar 9, 2015 at 8:28 AM, Cullen Jennings <= fluffy@cisco.com&= gt; wrote:

> On Mar 5, 2015, at 8:22 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>
> On Mar 5, 2015, at 5:14 AM, Roman Shpount <roman@telurix.com> wrote:
>
>> On Thu, Mar 5, 2015 at 4:52 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote: >> 2015-03-05 7:58 GMT+01:00 Christer Holmberg <christer.holmberg@ericsso= n.com>:
>> > As far as I understand, sending of multiple ClientHellos, on = different
>> > 5-tuples, would require a change to core DTLS (not only DTLS-= SRTP), and who
>> > knows how long such work would take. Do we really want to add= such
>> > dependency to our deliveries at this point?
>>
>> Sorry, I think I didn't explain well.
>>
>> It is not about multiple DTLS connections, but about the fact that=
>> DTLS packets belonging to the *same* DTLS connection/association c= an
>> be carried over different 5-tuples. This may happen during agressi= ve
>> ICE nomination in which media (so the DTLS ClientHello) follows th= e
>> USE-CANDIDATE Binding request without even waiting for a response.=
>>
>> When was it agreed that DTLS ClientHello can be sent before the co= nnectivity check succeeded? I understand that this will increase the connec= tion setup time, but I though that no data should be sent before the connec= tivity check response (consent) from the remote party.
>
> As I understand the current rough consensus, the endpoint has to have = received a successful response to a connectivity check on the 5-tuple, prov= ing consent, but it doesn=E2=80=99t have to have received (or sent) a check= with a USE-CANDIDATE attribute in it yet.
>
> This was the outcome of our discussion =E2=80=9Cmerging" regular = and aggressive ICE nomination.

That matches my understanding of how things work.

=C2=A0
Th= at discussion is now codified in a new draft, https://tools.ie= tf.org/html/draft-uberti-mmusic-nombis-00.

To = handle the issue raised by the OP, I think we should either
1) Fi= x the DTLS draft (and any others) to not be bound to a 5-tuple when ICE is = used
2) Update ICE-bis to say that any language about 5-tuples is= invalidated by ICE, and should be treated as a virtual transport.

#2 seems like the simplest path at this point, given that = ICE-bis work is underway.

#2 seems like the right answer to me.

-Ekr<= /div>

________________________= _______________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b8750be1d91740510e487cb-- From nobody Mon Mar 9 20:20:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CD1AD151 for ; Mon, 9 Mar 2015 20:20:47 -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 qnQ06sOiWFJr for ; Mon, 9 Mar 2015 20:20:44 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562391AD0D2 for ; Mon, 9 Mar 2015 20:20:44 -0700 (PDT) Received: by lams18 with SMTP id s18so13360768lam.9 for ; Mon, 09 Mar 2015 20:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VTuTEbuIfJDKqQaoD1jiljeGjuKgXCkne3eTiKTjpXg=; b=G7tDicXD2JOSXDixdXu4G0lb+ZGDgJps82nP+WS/EujEkDb+yFyjwm4WT/9WYPX9xS Qx5CcDzhvYaAG+Cg9a7khbYMWhx9/1zRR7qmoSrtTCBlFPUesDAmXQKGn2CfRU3U/zkr 04vkwTwDW3H5XpFEU/DkpiJ2fLU5o5HmRoyk02+AhqDIbRcVHeyoPWOyzBodVRN8mgnp imDiNsCEzgL87HddvVhIy6shlvDCS4wwENC3JozbT8jeicxCXyyOrgr6ptlhWBV6rmyc kzzBnN4bOOCkbDysDMbaq2RmDMwyGg5nXGbxwvI050hB0S9PzewOHACZcmYcXg8hMymO LdpA== X-Received: by 10.152.179.139 with SMTP id dg11mr22753069lac.28.1425957642841; Mon, 09 Mar 2015 20:20:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.41.4 with HTTP; Mon, 9 Mar 2015 20:20:22 -0700 (PDT) In-Reply-To: References: <20150309044740.4941.89516.idtracker@ietfa.amsl.com>

From: Barry Dingle Date: Tue, 10 Mar 2015 14:20:22 +1100 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11349192c435940510e6a27c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 03:20:47 -0000 --001a11349192c435940510e6a27c Content-Type: text/plain; charset=UTF-8 Was the suggestion to change the Title to "WebRTC *Media* Forward Error Correction Requirements" - because there is no mention of Data Channel FEC in this draft - accepted? If not, why not? Barry Dingle = = = On Tue, Mar 10, 2015 at 11:36 AM, Justin Uberti wrote: > [fixing cc list] > > On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti wrote: > >> This version incorporates the feedback from Honolulu, as well as several >> comments from the list. >> >> The Honolulu feedback suggested removing support for redundant audio with >> codecs like PCMU, but I did get a request for this on the list, so I left >> it in. >> >> On Sun, Mar 8, 2015 at 9:47 PM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Real-Time Communication in >>> WEB-browsers Working Group of the IETF. >>> >>> Title : WebRTC Forward Error Correction Requirements >>> Author : Justin Uberti >>> Filename : draft-ietf-rtcweb-fec-01.txt >>> Pages : 7 >>> Date : 2015-03-08 >>> >>> Abstract: >>> This document provides information and requirements for how Forward >>> Error Correction (FEC) should be used by WebRTC applications. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-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/ >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11349192c435940510e6a27c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Was the suggestion to change the Title to "WebRT= C Media Forward Error Correction Requirements" - because there = is no mention of Data Channel FEC in this draft - accepted?

I= f not, why not?

Barry Dingle

=3D =3D =3D

On Tue, Mar 10, 2015 at 11:= 36 AM, Justin Uberti <juberti@google.com> wrote:

[fixing cc list]

On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti <juberti@googl= e.com> wrote:

This version incorporates the feedback from Honolulu, as well as severa= l comments from the list.

The Honolulu feedback suggeste= d removing support for redundant audio with codecs like PCMU, but I did get= a request for this on the list, so I left it in.

On Sun, Mar 8, 2015 a= t 9:47 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-08

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-fec-01<= /a>

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/

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

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

--001a11349192c435940510e6a27c-- From nobody Mon Mar 9 22:46:52 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977801A1BB1 for ; Mon, 9 Mar 2015 22:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EucvBwXeBOCv for ; Mon, 9 Mar 2015 22:46:48 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1781A1BB4 for ; Mon, 9 Mar 2015 22:46:48 -0700 (PDT) Received: by iecsf10 with SMTP id sf10so321493iec.2 for ; Mon, 09 Mar 2015 22:46:47 -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=rrX2I7xM+ovkskmxET5/xT0L9c43oPWnLwBKvZRNpSU=; b=VZyOySibzTz0T1bMh1HtRuptkfhpHTGv0m3YZrAW5MMQbeDdF1/YxGrVU4OQ+ze8Mm cTjrF+9B9my2Qz/j6MeE/X4bDMRFjNEUx0ceCjz3cnNmWwo7ruGcb99SIInKTS9Dyu+H /BpsbYp4miK1GkgAyARr4VTD2yhkEDFeoNYwQ2VJojpHQuiuvgraMtY+dMUsfH5chNdn YqaUXYULEawXyTufYoSJAkiMlsg8LAYavLiYCYrjrgVnvmvOspAZAvEwbrG9IE32ias0 yIPJ3vk0kdEGzUiqnK+RQXJiBEcR6NW+DeWVPP7z9HUigComGBhh+0YIz2nBK9w2zyFJ lEfw== 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=rrX2I7xM+ovkskmxET5/xT0L9c43oPWnLwBKvZRNpSU=; b=FtnUfOeE1kIb9pUcPdYrjsgTYuJN2vnL0fYUWOQN0azsSTKmK6uwALQq+1TgZbpqY5 gNJMofetQqJBGPpg+eQLhazojrkHuBXjS3SQjE1PndmNP/ANLLquH0cz9B5kzdNTMa1C jPGlK3uDXNTkuZrJCSLtZtBmG4qNYhOvONtwg6yxC/B3LNypizQojcaWSkcd3kUzZaBQ rghxSoNPhPOYlhaTa/eLhyhL/YN4X9kD9Mk9EVaNPXFEEe5R/RpnKjyX609HB+2z31Ga 6heYVwoecqwQQQSw76Ww6yZEUOpUGdMgo86Lt7KLd6IIvb4ryAJbouksBDCJxq8hCQiN VU3w== X-Gm-Message-State: ALoCoQmmFAwnacR5nTgwJfadwftjktrDLFUJsOCQcYVVc8KkkN0Q/6qjqB2YDzRpzdD4Hrkceg/s X-Received: by 10.107.132.158 with SMTP id o30mr16944263ioi.9.1425966407552; Mon, 09 Mar 2015 22:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Mon, 9 Mar 2015 22:46:27 -0700 (PDT) In-Reply-To: References: <20150309044740.4941.89516.idtracker@ietfa.amsl.com>

From: Justin Uberti Date: Mon, 9 Mar 2015 22:46:27 -0700 Message-ID: To: Barry Dingle Content-Type: multipart/alternative; boundary=001a113f29bc2f31b50510e8ad9e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 05:46:50 -0000 --001a113f29bc2f31b50510e8ad9e Content-Type: text/plain; charset=UTF-8 Based on the discussion on the list, I elected to include a section on Application FEC: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-01#section-6 On Mon, Mar 9, 2015 at 8:20 PM, Barry Dingle wrote: > Was the suggestion to change the Title to "WebRTC *Media* Forward Error > Correction Requirements" - because there is no mention of Data Channel FEC > in this draft - accepted? > > If not, why not? > > Barry Dingle > = = = > > On Tue, Mar 10, 2015 at 11:36 AM, Justin Uberti > wrote: > >> [fixing cc list] >> >> On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti wrote: >> >>> This version incorporates the feedback from Honolulu, as well as several >>> comments from the list. >>> >>> The Honolulu feedback suggested removing support for redundant audio >>> with codecs like PCMU, but I did get a request for this on the list, so I >>> left it in. >>> >>> On Sun, Mar 8, 2015 at 9:47 PM, wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Real-Time Communication in >>>> WEB-browsers Working Group of the IETF. >>>> >>>> Title : WebRTC Forward Error Correction Requirements >>>> Author : Justin Uberti >>>> Filename : draft-ietf-rtcweb-fec-01.txt >>>> Pages : 7 >>>> Date : 2015-03-08 >>>> >>>> Abstract: >>>> This document provides information and requirements for how Forward >>>> Error Correction (FEC) should be used by WebRTC applications. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-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/ >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a113f29bc2f31b50510e8ad9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Based on the discussion on the list, I elected to include = a section on Application FEC:=C2=A0https://tools.ietf.org/html/draft-ietf-r= tcweb-fec-01#section-6

On Mon, Mar 9, 2015 at 8:20 PM, Barry Dingle <btdingle@g= mail.com> wrote:

Was the suggestion to change the Title to "WebRTC Med= ia Forward Error Correction Requirements" - because there is no me= ntion of Data Channel FEC in this draft - accepted?

If not, w= hy not?

Barry Dingle
= =3D =3D =3D

On Tue, Mar 10, 2015 at 11:36 AM, Justin Uberti = <juberti@google.= com> wrote:
[fixing cc list]

On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti <juberti@g= oogle.com> wrote:
This version incorporates the feedback from Honolulu, as well as s= everal comments from the list.

The Honolulu feedback sug= gested removing support for redundant audio with codecs like PCMU, but I di= d get a request for this on the list, so I left it in.

On Sun, Mar 8, 2= 015 at 9:47 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-08

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-fec-01<= /a>

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/

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

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

--001a113f29bc2f31b50510e8ad9e-- From nobody Mon Mar 9 23:44:04 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95F91B29FB for ; Mon, 9 Mar 2015 23:44:02 -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 R3C5PLM-xI4d for ; Mon, 9 Mar 2015 23:44:00 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548BC1A1B83 for ; Mon, 9 Mar 2015 23:44:00 -0700 (PDT) Received: by labgm9 with SMTP id gm9so6636943lab.13 for ; Mon, 09 Mar 2015 23:43: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:from:date:message-id:subject:to :cc:content-type; bh=Sgp31PGGqweDirY7bCbDK0ts0U6Zy9tlO1A2K63lmdw=; b=tfPolWgLbYqnmfrdNc3dZCkqfig/8WlpEn5Lug4vvQK8xd2r0KwihqJrIGwe8hlDB1 Nx0tjg8nsFfWDujeylaZDjFcx7NBitRTGi0/BG7qDlYl4oOuLzJsbMUKHGP7IzauFhmp WOK9PcymWien7yLq2K9KPrAHouOlsmWIGjDLvzQ42blTP7Vs8hlRvyoQO4nGffp+hLPT daZ6poUD9atUDrOMlnMaPKKbfGVg2c4tpCx+rOjE+QD6ExE47+RpqAAM5lfeMN/S+moo iFJQWpFsRkPVh4mWUUjmaGHguTXodX8bLa7N9LUs8PF3HAMMtXE2FpEFys9oQzypIT48 GBtA== X-Received: by 10.112.145.230 with SMTP id sx6mr1766022lbb.70.1425969838712; Mon, 09 Mar 2015 23:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.41.4 with HTTP; Mon, 9 Mar 2015 23:43:38 -0700 (PDT) In-Reply-To: References: <20150309044740.4941.89516.idtracker@ietfa.amsl.com>

From: Barry Dingle Date: Tue, 10 Mar 2015 17:43:38 +1100 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b3a7d92b26f110510e97936 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 06:44:03 -0000 --047d7b3a7d92b26f110510e97936 Content-Type: text/plain; charset=UTF-8 Thanks Justin. Barry Dingle On Tue, Mar 10, 2015 at 4:46 PM, Justin Uberti wrote: > Based on the discussion on the list, I elected to include a section on > Application FEC: > https://tools.ietf.org/html/draft-ietf-rtcweb-fec-01#section-6 > > On Mon, Mar 9, 2015 at 8:20 PM, Barry Dingle wrote: > >> Was the suggestion to change the Title to "WebRTC *Media* Forward Error >> Correction Requirements" - because there is no mention of Data Channel FEC >> in this draft - accepted? >> >> If not, why not? >> >> Barry Dingle >> = = = >> >> On Tue, Mar 10, 2015 at 11:36 AM, Justin Uberti >> wrote: >> >>> [fixing cc list] >>> >>> On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti >>> wrote: >>> >>>> This version incorporates the feedback from Honolulu, as well as >>>> several comments from the list. >>>> >>>> The Honolulu feedback suggested removing support for redundant audio >>>> with codecs like PCMU, but I did get a request for this on the list, so I >>>> left it in. >>>> >>>> On Sun, Mar 8, 2015 at 9:47 PM, wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Real-Time Communication in >>>>> WEB-browsers Working Group of the IETF. >>>>> >>>>> Title : WebRTC Forward Error Correction Requirements >>>>> Author : Justin Uberti >>>>> Filename : draft-ietf-rtcweb-fec-01.txt >>>>> Pages : 7 >>>>> Date : 2015-03-08 >>>>> >>>>> Abstract: >>>>> This document provides information and requirements for how Forward >>>>> Error Correction (FEC) should be used by WebRTC applications. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-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/ >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > --047d7b3a7d92b26f110510e97936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks Justin.

Barry Dingle
<= br>

On Tue, Mar 10, 2015 at 4:46 PM, Justin Uber= ti <juberti@google.com> wrote:

Based on the discussion on the list, I elected to in= clude a section on Application FEC:=C2=A0https://tools.ie= tf.org/html/draft-ietf-rtcweb-fec-01#section-6

On Mon, Mar 9, 2015 at 8:20 PM, Barry Dingle <btdingle@gmail.com&= gt; wrote:
W= as the suggestion to change the Title to "WebRTC Media Forward = Error Correction Requirements" - because there is no mention of Data C= hannel FEC in this draft - accepted?

If not, why not?

Barry Di= ngle
=3D =3D =3D

On Tue, Mar 10, 2015 at 11:36 AM, Justin Uberti <ju= berti@google.com> wrote:
[fixing cc list]
<= br>
On Mon, Mar 9, 2015 at 4:36 PM, Justin Uberti= <juberti@google.com> wrote:
This version incorporates the feedback from Honolulu, = as well as several comments from the list.

The Honolulu = feedback suggested removing support for redundant audio with codecs like PC= MU, but I did get a request for this on the list, so I left it in.

On S= un, Mar 8, 2015 at 9:47 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-08

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-fec-01<= /a>

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/

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

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

--047d7b3a7d92b26f110510e97936-- From nobody Tue Mar 10 06:39:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883EB1A00E0 for ; Tue, 10 Mar 2015 06:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0QCyjetN5BYa for ; Tue, 10 Mar 2015 06:39:29 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA451A701C for ; Tue, 10 Mar 2015 06:39:29 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 94C7C23F043A; Tue, 10 Mar 2015 14:39:28 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.173]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Tue, 10 Mar 2015 14:39:28 +0100 From: "Hutton, Andrew" To: Alan Johnston , Benjamin Schwartz Thread-Topic: [rtcweb] RETURN-05 Thread-Index: AQHQWo//VgK643MHBUGx5Z9tOb8cc50VuadA Date: Tue, 10 Mar 2015 13:39:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67@MCHP04MSX.global-ad.net> References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RETURN-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 13:39:31 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEFsYW7igJlzIGFzc2Vzc21lbnQgYW5kIGFsc28gYmVsaWV2ZSB0aGF0IHdl IHNob3VsZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGlzIGRyYWZ0Lg0KDQpSZWdhcmRzDQpBbmR5DQoN CkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxhbiBKb2huc3Rvbg0KU2VudDogMDkgTWFyY2ggMjAxNSAxNzozOQ0KVG86IEJlbmphbWlu IFNjaHdhcnR6DQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gUkVU VVJOLTA1DQoNCkkgdGhpbmsgUkVUVVJOIGlzIGVzc2VudGlhbCBmb3IgV2ViUlRDIHRvIHdvcmsg d2VsbCBhY3Jvc3MgZW50ZXJwcmlzZSBib3JkZXJzLiAgV2Ugd2lsbCBpbmNyZWFzaW5nbHkgc2Vl IGJvcmRlciBUVVJOIHNlcnZlcnMgdXNlZCBieSBlbnRlcnByaXNlcyB0byBtYW5hZ2UgYW5kIGNv bnRyb2wgV2ViUlRDIHVzYWdlLCBtb3N0IGxpa2VseSBhcyBhZGRpdGlvbnMgdG8gZXhpc3Rpbmcg ZmlyZXdhbGxzIGFuZCBTQkNzLiAgV2l0aG91dCBSRVRVUk4sIHRoZSB1c2FnZSBvZiBib3JkZXIg VFVSTiBzZXJ2ZXJzIHdpbGwgcmVzdWx0IGluIGxvc3Mgb2YgZnVuY3Rpb25hbGl0eSBpbiBXZWJS VEMgYXBwbGljYXRpb25zIHRoYXQgdXNlIGEgVFVSTiBzZXJ2ZXIgdG8gcHJvdmlkZSBmZWF0dXJl cyBpbiBhZGRpdGlvbiB0byBzaW1wbGUgTkFUIHRyYXZlcnNhbC4gIFJFVFVSTiBzaG91bGQgd29y ayBwZXJmZWN0bHkgdG8gYWxsb3cgYm90aCBUVVJOIHNlcnZlcnMgdG8gd29yaywgd2hpbGUgc3Rp bGwgYWxsb3dpbmcgZW5kLXRvLWVuZCBlbmNyeXB0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgbWVkaWEg Zmxvd3MuDQoNCknigJltIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgc29sdXRpb25zIHRvIHRoZSBl bnRlcnByaXNlIHJlcXVpcmVtZW50cyBpZGVudGlmaWVkIGluIFNlY3Rpb24gMy4zLjUgb2YgZHJh ZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMuICBJIHRoaW5rIHdlIG5l ZWQgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhpcyBkcmFmdCBpbiBSVENXRUIuDQoNCi0gQWxhbiAt DQoNCk9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgOToxOSBBTSwgQmVuamFtaW4gU2Nod2FydHogPGJl bWFzY0B3ZWJydGMub3JnPG1haWx0bzpiZW1hc2NAd2VicnRjLm9yZz4+IHdyb3RlOg0KTmV3IGRy YWZ0IG9mIFJFVFVSTiBpcyB1cDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNj aHdhcnR6LXJ0Y3dlYi1yZXR1cm4tMDUNCg0KVGhpcyBkcmFmdCBjb250YWlucyBhIHZhcmlldHkg b2YgY2xhcmlmaWNhdGlvbnMgYW5kIGNoYW5nZXMgb2YgZW1waGFzaXMsIGFuZCBzaG91bGQgaG9w ZWZ1bGx5IG5vdyBiZSBlYXNpZXIgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZC4NCg0KVGhhbmtzIHRv IEFsYW4gSm9obnN0b24gYW5kIEpvaG4gWW9ha3VtIGZvciBjb250cmlidXRpbmcgbmV3IGZpZ3Vy ZXMgYW5kIGRldGFpbGVkIHRleHQgcmV2aWV3IGZvciB0aGlzIHJldmlzaW9uLg0KDQotLUJlbg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2Vi IG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEFsYW7igJlzIGFzc2Vz c21lbnQgYW5kIGFsc28gYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBtb3ZlIGZvcndhcmQgd2l0aCB0 aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5B bGFuIEpvaG5zdG9uPGJyPg0KPGI+U2VudDo8L2I+IDA5IE1hcmNoIDIwMTUgMTc6Mzk8YnI+DQo8 Yj5Ubzo8L2I+IEJlbmphbWluIFNjaHdhcnR6PGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFJFVFVSTi0wNTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayBSRVRVUk4gaXMgZXNzZW50aWFsIGZvciBXZWJSVEMgdG8gd29yayB3ZWxsIGFjcm9zcyBlbnRl cnByaXNlIGJvcmRlcnMuJm5ic3A7IFdlIHdpbGwgaW5jcmVhc2luZ2x5IHNlZSBib3JkZXIgVFVS TiBzZXJ2ZXJzIHVzZWQgYnkgZW50ZXJwcmlzZXMgdG8gbWFuYWdlIGFuZCBjb250cm9sIFdlYlJU QyB1c2FnZSwgbW9zdCBsaWtlbHkgYXMgYWRkaXRpb25zIHRvIGV4aXN0aW5nIGZpcmV3YWxscyBh bmQgU0JDcy4mbmJzcDsNCiBXaXRob3V0IFJFVFVSTiwgdGhlIHVzYWdlIG9mIGJvcmRlciBUVVJO IHNlcnZlcnMgd2lsbCByZXN1bHQgaW4gbG9zcyBvZiBmdW5jdGlvbmFsaXR5IGluIFdlYlJUQyBh cHBsaWNhdGlvbnMgdGhhdCB1c2UgYSBUVVJOIHNlcnZlciB0byBwcm92aWRlIGZlYXR1cmVzIGlu IGFkZGl0aW9uIHRvIHNpbXBsZSBOQVQgdHJhdmVyc2FsLiZuYnNwOyBSRVRVUk4gc2hvdWxkIHdv cmsgcGVyZmVjdGx5IHRvIGFsbG93IGJvdGggVFVSTiBzZXJ2ZXJzIHRvIHdvcmssIHdoaWxlDQog c3RpbGwgYWxsb3dpbmcgZW5kLXRvLWVuZCBlbmNyeXB0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgbWVk aWEgZmxvd3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJltIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgc29sdXRpb25zIHRvIHRoZSBlbnRl cnByaXNlIHJlcXVpcmVtZW50cyBpZGVudGlmaWVkIGluIFNlY3Rpb24gMy4zLjUgb2YgZHJhZnQt aWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMuJm5ic3A7IEkgdGhpbmsgd2Ug bmVlZCB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGlzIGRyYWZ0IGluIFJUQ1dFQi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBBbGFuIC08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJp LCBNYXIgNiwgMjAxNSBhdCA5OjE5IEFNLCBCZW5qYW1pbiBTY2h3YXJ0eiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJlbWFzY0B3ZWJydGMub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmVtYXNjQHdlYnJ0Yy5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5OZXcgZHJhZnQgb2YgUkVUVVJOIGlz IHVwOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTA1IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0w NTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij5UaGlzIGRyYWZ0IGNvbnRhaW5zIGEgdmFyaWV0eSBvZiBjbGFy aWZpY2F0aW9ucyBhbmQgY2hhbmdlcyBvZiBlbXBoYXNpcywgYW5kIHNob3VsZCBob3BlZnVsbHkg bm93IGJlIGVhc2llciB0byByZWFkIGFuZCB1bmRlcnN0YW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoYW5r cyB0byBBbGFuIEpvaG5zdG9uIGFuZCBKb2huIFlvYWt1bSBmb3IgY29udHJpYnV0aW5nIG5ldyBm aWd1cmVzIGFuZCBkZXRhaWxlZCB0ZXh0IHJldmlldyBmb3IgdGhpcyByZXZpc2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0Ij4tLUJlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67MCHP04MSXglobal_-- From nobody Tue Mar 10 06:40:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0344C1A00E0 for ; Tue, 10 Mar 2015 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 FSfXo_u2EI77 for ; Tue, 10 Mar 2015 06:40:15 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AE31A87E2 for ; Tue, 10 Mar 2015 06:40:14 -0700 (PDT) Received: by oifu20 with SMTP id u20so1320375oif.12 for ; Tue, 10 Mar 2015 06:40:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CO0sgu64wD6MkQTaCoAeULt8Zw+0wk4qPH4GDuaVbag=; b=PfUWrNRhOMo1Mjcg7qlDZAZm6/vicJSe79Q1k44BmtyyBfBN+mKUOcE2+7Omn0InoZ dboDYoDpZi5S6A7bs7QcKVFfeq42TMuWU6LO65/YsSml3hgClpSLRpSg3BCxTYI/jwtX 4nXIiIBaGo/g9HhhneHUKChSu75kpHE2A5z2uKZEUHFoJ+d9qLvVQ/5zYmGsky0Qaus1 6oFUWmojs6okrzjf6rtR1MCkVdUib3vAoMq7rctpWtE3EhXHcXtmVPZ94nvT5ZbEaYcU 9SkdVRcJV8QteqJ5zz46kjOhj8n5T+syGfKAjUluzUXGcUvpHJSPh8uqLukHbfuJSN+R gH9g== X-Gm-Message-State: ALoCoQkW9rm1Pcwn4yi90n9yvZKUIfUrspbShSWmflAc4DgqA4OUO4w29qIZ0Modj+42kijWJsTa X-Received: by 10.202.1.200 with SMTP id 191mr24523357oib.82.1425994814350; Tue, 10 Mar 2015 06:40:14 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id u135sm324289oif.24.2015.03.10.06.40.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 06:40:13 -0700 (PDT) Message-ID: <54FEF43B.50604@jive.com> Date: Tue, 10 Mar 2015 09:40:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Hutton, Andrew" , Alan Johnston , Benjamin Schwartz References:

<9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E6F0F67@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RETURN-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 13:40:17 -0000 Le 2015-03-10 09:39, Hutton, Andrew a �crit : > I agree with Alan�s assessment and also believe that we should move > forward with this draft. +1 Simon From nobody Tue Mar 10 06:46:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22E71A875C for ; Tue, 10 Mar 2015 06:46:08 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb4Kdq73HfvW for ; Tue, 10 Mar 2015 06:46:07 -0700 (PDT) Received: from relay.mailchannels.net (tkt-001-i354.relay.mailchannels.net [174.136.5.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDF51A88A4 for ; Tue, 10 Mar 2015 06:46:01 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id CF25A41DD for ; Tue, 10 Mar 2015 13:45:56 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.254.9.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 10 Mar 2015 13:46:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1425995160159:3146556388 X-MC-Ingress-Time: 1425995160159 Received: from pool-173-49-141-196.phlapa.fios.verizon.net ([173.49.141.196]:56033 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YVKTr-000Gnh-Ts for rtcweb@ietf.org; Tue, 10 Mar 2015 08:45:55 -0500 Message-ID: <54FEF599.5030002@jesup.org> Date: Tue, 10 Mar 2015 09:46:01 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References:

In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] RETURN-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 13:46:09 -0000 On 3/9/2015 1:39 PM, Alan Johnston wrote: > I think RETURN is essential for WebRTC to work well across enterprise=20 > borders. We will increasingly see border TURN servers used by=20 > enterprises to manage and control WebRTC usage, most likely as=20 > additions to existing firewalls and SBCs. Without RETURN, the usage=20 > of border TURN servers will result in loss of functionality in WebRTC=20 > applications that use a TURN server to provide features in addition to=20 > simple NAT traversal. RETURN should work perfectly to allow both TURN=20 > servers to work, while still allowing end-to-end encrypted and=20 > authenticated media flows. > > I=92m not aware of any other solutions to the enterprise requirements=20 > identified in Section 3.3.5 of=20 > draft-ietf-rtcweb-use-cases-and-requirements. I think we need to move=20 > forward with this draft in RTCWEB. I agree. I'll note that RETURN covers the auto-configuration portion of=20 3.3.5, but browsers (and other WebRTC-compatible devices by implication)=20 should handle manual configurations as well. (Just a note, it doesn't=20 affect the spec or RETURN I believe.) It must be possible to configure the browsers used in the enterprise=20 with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. --=20 Randell Jesup -- rjesup a t mozilla d o t com From nobody Tue Mar 10 08:27:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1091B1A0021 for ; Tue, 10 Mar 2015 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 x6uF0HPSy9jm for ; Tue, 10 Mar 2015 08:27:02 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9421A00B2 for ; Tue, 10 Mar 2015 08:26:52 -0700 (PDT) Received: by qgdz107 with SMTP id z107so2699220qgd.3 for ; Tue, 10 Mar 2015 08:26:51 -0700 (PDT) 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:content-transfer-encoding; bh=zm48I10ygsvMfdKgnZWRaYXFwJOeRekce8PR2bM2iy0=; b=C5ttdhtPRDYsaOCV/fEzUxofJbqTyoMs/sBFPLJpG04mxfpZ45e8ijGi9nISYPz8eG I6GCqF8YMFtHokUI9mY+MzJORBookp1VLCPsfuGVUacfO1Qg3d+QhzcORzJYW6O9n1Ln 8SELpJC4xI/vxztK/2qNce9eeDUekEepx6v//KR3UyP+bQWJ9nhovl/3H8ZGUMwxQntG JXuaWxPJvAzbww3VVlH5QqFzs9hTb8ShLlJXeHr+qCBA13mNsh3FQSqfgAbNY4TLQpme YXf8/U9lAL1ctMAtTbZonjDSK2GObsAmrGYfDZJVoVRA1GMMXx2vrJi9OCBnUaoMegRz 4YVw== X-Gm-Message-State: ALoCoQljiH5LFp54ZZ9U17UqYmN1DAh3LTFXKdIgj4xd9zmC/27NTVoXChjj1L6hN7XcrRzZ0aLB X-Received: by 10.55.23.83 with SMTP id i80mr60956441qkh.104.1426001211641; Tue, 10 Mar 2015 08:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.214.137 with HTTP; Tue, 10 Mar 2015 08:26:31 -0700 (PDT) In-Reply-To: References: <54F74B02.1070902@jive.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se>

<7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se>

<2F467A7E-7A6C-4B1B-985A-0D9C089BE973@cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 10 Mar 2015 16:26:31 +0100 Message-ID: To: Eric Rescorla

7.2. Congestion Control Interoperability and Legacy Systems

7.1. Boundary Conditions and Circuit Breakers

7.2. Congestion Control Interope= rability and Legacy Systems

7.2. Congesti= on Control Interoperability and Legacy Systems

7.2. Congestion Control = Interoperability and Legacy Systems

7.1. Boundary Conditions and Circuit= Breakers

= 7.2. Congestion Control Interoperability and Legacy Systems

7.1. Bound= ary Conditions and Circuit Breakers

= 7.2. Congestion Control Interoperability and Legacy Systems

7.1. Bound= ary Conditions and Circuit Breakers

6.7.1. ICE Interaction

6.7.1. ICE Interaction

6.7.1. ICE Interaction

6.7.1. ICE Interaction

7.2. = Congestion Control Interoperability and Legacy Systems