From nobody Mon Apr 4 12:28:44 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C26012D831 for ; Mon, 4 Apr 2016 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-iNQP97imZo for ; Mon, 4 Apr 2016 12:28:40 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 5C03C12D82E for ; Mon, 4 Apr 2016 12:28:39 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id e185so193374545vkb.1 for ; Mon, 04 Apr 2016 12:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=h12Aa23+0zy7Ml9SsK+2Il+71Pv/tl1fCWWtZWh2U8M=; b=szgo2U/lSOCzChVa6wHxKD0fVAyRTmW90LGeR46a1BBqik/fU4/3eN3X0eitn1NBnK NMgbC6n6p7SCjirxwJHmL9bL6MVjFpkPf1CQa6Suxwnanmp1EB1XDaFnvsXVwrWWu04f Xeqx/6+76tf9Gkq/MMBEgG0aarzgUeZJkfMIwHVkzAcvZJhzxAMoxXd9qIwF/BLYujFL rNB+DyF9DNaqCw40AVCvGjjQZu+uhtIzZ9q1GYOXDr0JBvBIdaqAeXS5rvIki388MlPs pRTh95mXllGswPK+kpUDBczO4odib6Hy8JPO0/9fgCwoX6wzffciNrU4VL8n1Z5SegNV RmlQ== 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; bh=h12Aa23+0zy7Ml9SsK+2Il+71Pv/tl1fCWWtZWh2U8M=; b=YWV4nWjYyh/c4CvNXhCA+/Y4Gk3WlAZn4lPiXfb8XcbZg0G81W6laATSllFt4jtgyM DT0vBjU21c06sOEaqin91bL3lPDBXo+/dGKARIzNlCH+O2vhiHs8zRyrFTVJGVQsPa9R vYOS+iSasGZeLSmGvG1Y+Vkf7Xb/MgSr/YGGqAz1bKvreHLCdCwtMcur2dEbToCJQ2mr cXAxhpUsyvyIGegGP98+enzVq42AlqoS+KJo6+rZN4vonYxBA3mBXNd0L4bx53CMlei7 zaDN++F846st+YafRIe3rSIf0VuM+wRa2fjSRKdEah93UHZt6NXne2De9FRbyS0IObQw V9nw== X-Gm-Message-State: AD7BkJKub/ksiG9+mkztWtXXvr907okDjZVtelWdpc7svZuuxRmhE9Gmt2UveaD+YusgkuGOs/EwFlqk8zd2NQ== MIME-Version: 1.0 X-Received: by 10.31.3.213 with SMTP id f82mr5681326vki.27.1459798118415; Mon, 04 Apr 2016 12:28:38 -0700 (PDT) Received: by 10.31.151.85 with HTTP; Mon, 4 Apr 2016 12:28:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 16:28:38 -0300 Message-ID: From: Richard Barnes To: perc@ietf.org, Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11426cde4b23f9052fadbccf Archived-At: Subject: Re: [Perc] Minutes from Design Team call #3 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:28:42 -0000 --001a11426cde4b23f9052fadbccf Content-Type: text/plain; charset=UTF-8 Magnus: Note the SSRC line below: Field Can be modified? Send original? ... SSRC No --- On Wed, Dec 2, 2015 at 8:36 PM, Richard Barnes wrote: > Hey all, > > Please find below the chairs' notes from the design team call we had on > Monday. > > --Richard > > > PERC Design Team Call #3 > > # Chairs introduction > > * Future calls will follow Virtual Interim process > * This call is focused on figuring out what capabilities the MDD needs > to modify header fields > > > # Discussion of Header Fields > > Summary of conclusions on call: > > Field Can be modified? Send original? > V No --- > X Yes Maybe (see extn) > M No --- > PT Yes Yes > SEQ Yes Yes > Timestamp No --- > SSRC No --- > CSRC/CC No --- > Extension Yes TBD > > --- > > V - MDD MUST NOT change > > P - MDD MUST NOT change > > X - MDD needs to be able to change > -- Original value may be necessary for E2E integrity-protected extns > > M - MDD MUST NOT change > -- M is used to signal to endpoints to reset jitter buffers > -- ... but it's tied to SSRC, so switching SSRC could be the signal > -- Might need to document how this relates to SSRC / source indication > > PT - MDD needs to be able to change > -- MDD can always trash the conference > -- needs changing to match PTs across individual sessions > -- Security considerations about malicious PT changes > -- No immediate need for the original value at the receiver > -- ... but we should keep the option open > > SEQ - MDD needs to be able to change > > -- For, e.g., consistent loss detection with stream on/off behavior > > -- Different from network attacker b/c long silences are normal > > -- Replay attacks might need extra mechanism > > -- e.g., authenticated ROC in EKT > > -- Delay attack might be better handled with timestamp / RTCP > > -- Original value needed at the endpoint > > > Timestamp - MDD MUST NOT change > > -- MDD might want to change if MSM are used > > -- No MSM , no need to fudge the timespatmp > > -- When changed needs to preserve the original value > > -- No need to change if SSRC is immutable > > > SSRC - MDD MUST NOT change > > -- Splicing attack - needs source to be verified ? > > -- Need higher level layer to ensure SSRCs are end to end > authenticated somehow [[ or otherwise have the right properties ]] > > -- Might need to come back and make it mutable later > > -- Need to better express to the list why this design is simpler > (Magnus/Adam) > > -- Might be making some topologies incompatible with this decision > > -- ... and we should be explicit about this > > > CSRC - MDD MUST NOT change > > -- ... and by implication, CSRC Count (CC) > > > Header Extensions > > -- ID values behave similar to PT (signaling based assignment) > > -- ... so MDD might need to align them > > -- Needs more discussion of how > > -- RFC5450 > > -- MDD MUST NOT change > > -- Not used widely today and might not be in future (ref RMCAT ) > > -- RFC6051 > > -- MDD MUST NOT change, might need more discussions > > -- no timestamp rewriting implies no changing of this value > > -- Tied to E2E RTCP decision > > -- RFC6464 > > -- removing or not removing might not matter > > -- b/w might force to remove but having it allows end-point to verify > the authenticity of source reporting its audio level > > -- RFC6465 > > -- MDD MUST NOT Modify > > -- Encrypted or not ( needs more discussion for all the audio > levels). Use HBH as the baseline to drive these discussions. > > -- CVO > > -- MUST NOT MODIFY > > -- [[ Ran out of time here ]] > > > Path Forward: > > -- Work through existing extensions to see what capabilities are needed > > -- Write protocol mechanism for capabilities, handling guidlines per header > --001a11426cde4b23f9052fadbccf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus: Note the SSRC line below:

=C2=A0 Field=C2=A0 =C2=A0 =C2=A0 =C2=A0Can= be modified?=C2=A0 =C2=A0 Send original?
=C2=A0 ...
=C2=A0=C2=A0SSRC=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 No=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0---

On Wed, Dec 2, 2015 at 8:36 PM, Richard Barnes <rlb@ipv.sx= > wrote:
Hey all,

Please find below the chairs' notes from the design team call we had on= Monday.

--Richard


PERC Design Team Call #3

# Chairs introduction

* Future calls will follow Virtual Interim process
* This call is focused on figuring out what capabilities the MDD needs
to modify header fields


# Discussion of Header Fields

Summary of conclusions on call:

=C2=A0 Field=C2=A0 =C2=A0 =C2=A0 =C2=A0Can be modified?=C2=A0 =C2=A0 Send o= riginal?
=C2=A0 V=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
=C2=A0 X=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maybe (see extn)
=C2=A0 M=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
=C2=A0 PT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes
=C2=A0 SEQ=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes
=C2=A0 Timestamp=C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
=C2=A0 SSRC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 No=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
=C2=A0 CSRC/CC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
=C2=A0 Extension=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TBD

---

V - MDD MUST NOT change

P - MDD MUST NOT change

X - MDD needs to be able to change
=C2=A0 =C2=A0 -- Original value may be necessary for E2E integrity-protecte= d extns

M - MDD MUST NOT change
=C2=A0 =C2=A0 -- M is used to signal to endpoints to reset jitter buffers =C2=A0 =C2=A0 -- ... but it's tied to SSRC, so switching SSRC could be = the signal
=C2=A0 =C2=A0 -- Might need to document how this relates to SSRC / source i= ndication

PT - MDD needs to be able to change
=C2=A0 =C2=A0-- MDD can always trash the conference
=C2=A0 =C2=A0-- needs changing to match PTs across individual sessions
=C2=A0 =C2=A0-- Security considerations about malicious PT changes
=C2=A0 =C2=A0-- No immediate need for the original value at the receiver =C2=A0 =C2=A0-- ... but we should keep the option open

SEQ - MDD needs to be able to change

-- For, e.g., consistent loss detection with stream on/off behavior

-- Different from network attacker b/c long silences are normal

-- Replay attacks might need extra mechanism

-- e.g., authenticated ROC in EKT

-- Delay attack might be better handled with timestamp / RTCP

-- Original value needed at the endpoint


Timestamp - MDD MUST NOT change

-- MDD might want to change if MSM are used

-- No MSM , no need to fudge the timespatmp

-- When changed needs to preserve the original value

-- No need to change if SSRC is immutable


SSRC - MDD MUST NOT change

-- Splicing attack - needs source to be verified ?

-- Need higher level layer to ensure SSRCs are end to end
authenticated somehow [[ or otherwise have the right properties ]]

-- Might need to come back and make it mutable later

-- Need to better express to the list why this design is simpler (Magnus/Ad= am)

-- Might be making some topologies incompatible with this decision

-- ... and we should be explicit about this


CSRC - MDD MUST NOT change

-- ... and by implication, CSRC Count (CC)


Header Extensions

-- ID values behave similar to PT (signaling based assignment)

-- ... so MDD might need to align them

-- Needs more discussion of how

-- RFC5450

-- MDD MUST NOT change

-- Not used widely today and might not be in future (ref RMCAT )

-- RFC6051

-- MDD MUST NOT change, might need more discussions

-- no timestamp rewriting implies no changing of this value

-- Tied to E2E RTCP decision

-- RFC6464

-- removing or not removing might not matter

-- b/w might force to remove but having it allows end-point to verify
the authenticity of source reporting its audio level

--=C2=A0 RFC6465

-- MDD MUST NOT Modify

--=C2=A0 Encrypted or not ( needs more discussion for all the audio
levels). Use HBH as the baseline to drive these discussions.

-- CVO

-- MUST NOT MODIFY

-- [[ Ran out of time here ]]


Path Forward:

-- Work through existing extensions to see what capabilities are needed

-- Write protocol mechanism for capabilities, handling guidlines per header=

--001a11426cde4b23f9052fadbccf-- From nobody Tue Apr 5 16:04:06 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F0712D0CC for ; Tue, 5 Apr 2016 16:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPTwLhbPHwY8 for ; Tue, 5 Apr 2016 16:04:03 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248AD12D134 for ; Tue, 5 Apr 2016 16:04:03 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id k1so37262518vkb.0 for ; Tue, 05 Apr 2016 16:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=Igzc9RKHUzMqkHpcWQr7UqECl6xoLkRFub2Ei2k4zVY=; b=rxRgGjK83wKMjYp262JTrnXkhmtw9CKj94iBaLWH4Sn7wDHNk/azhthqxL8BiIP9tE VVtRUwAf1rKOwPXpoeyiOzIdIh/+PNTHqS8H5WQEouYTg2HTvMGwbv3GXDDeiVcxE4SD iZ+/q+sDh3oZOW69iEQ1LmuBj/uYCkC4BJQZhtZXIdPUtVikk4wh8hCUu3fpAQGnb6OG GqT0/500wcaW2bPEiCA3cgmMXWVXrV8FTiRlaZsYOZdwDEwkrUH9BENpKGgFn93inS87 F6ltPAtXyKFoZ8tUlbDAP1U/0ct8Kh5kNyJ/SPGpEAiIZKeHzURHOgwi1NiuZLXPLVU4 k+6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Igzc9RKHUzMqkHpcWQr7UqECl6xoLkRFub2Ei2k4zVY=; b=FLPdp2fxZf+h4m3MzzxFfRZxLHDa7voNsmuBmBlV4ahCcmet66h2FiuF51LzyCYdYz Lbl979+gmOweHxvnDFVCfy/wtYK+y+NygbDc56BX983nnMV+iSrawAOam1C4UyfQJzjx 9egbAywVSOHgSTCUW8ninmXQTGv8mRYrytHPJAcEEwVwyacvmFlt7q8XHLPiYIi4C2G0 V3TSBLUzezIiv70vZG2hmwx4b6ZEp2BlBT9jedvXoPc8GDVk2qzWQoOG0rR/MfoUzz+i RXwsiT6KJ5pjwivM7DtxOeIszsiPjlqO6DMxuU+klgCMhmo6+A/nAJeiQ7mnCYWoAmof OoIA== X-Gm-Message-State: AD7BkJIH4FWSOb35SwW077SS4f1EquefIdjcsjX+du+vLxOuGqKygpyU9AhP8FhhnM++eOxduyH0sICOFuG4HQ== MIME-Version: 1.0 X-Received: by 10.31.194.10 with SMTP id s10mr8297542vkf.72.1459897442246; Tue, 05 Apr 2016 16:04:02 -0700 (PDT) Received: by 10.176.66.199 with HTTP; Tue, 5 Apr 2016 16:04:02 -0700 (PDT) Date: Tue, 5 Apr 2016 16:04:02 -0700 Message-ID: From: Suhas Nandakumar To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114661dc74254a052fc4dc46 Archived-At: Subject: [Perc] Perc Meeting Minutes (IETF95) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:04:05 -0000 --001a114661dc74254a052fc4dc46 Content-Type: text/plain; charset=UTF-8 Hello All Please find the meeting minutes uploaded here https://www.ietf.org/proceedings/95/minutes/minutes-95-perc Big Thanks to Harald and Mo for capturing the minutes. Please let me and Richard know if there are any omissions or wrong summarizations. Cheers Richard/Suhas --001a114661dc74254a052fc4dc46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 Please find the meetin= g minutes uploaded here

Big Thanks to Harald= and Mo for capturing the minutes.

Please let me a= nd Richard know if there are any omissions or wrong summarizations.

Cheers
Richard/Suhas
--001a114661dc74254a052fc4dc46-- From nobody Tue Apr 5 16:07:09 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C520B12D894 for ; Tue, 5 Apr 2016 14:38:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405213834.30985.87316.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 14:38:34 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 16:07:07 -0700 Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:38:35 -0000 Changed milestone "Submit encrypted key transport specification to IESG (Standards Track)", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/perc/charter/ From nobody Mon Apr 11 16:48:13 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D501712D1F0 for ; Mon, 11 Apr 2016 16:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjm6Rt_Pd3Uw for ; Mon, 11 Apr 2016 16:48:10 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541A112D769 for ; Mon, 11 Apr 2016 16:48:10 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id c4so2470998vkb.3 for ; Mon, 11 Apr 2016 16:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=lkkV/D4FBl4VpuSMZGTrYh9YSr2/j4xtaF6hgnjNnFg=; b=adfnh6rCnmR+KTvTNaklFUkfXYzYYC4rIq6QyFQtPZ3t0tQpvMph2Ev+EhDUHAdSIL m5i76dTo78IWtdzff4gfraS/h053g/2pp+gi00KMfx/oMo2O380RgqLNPn7ma4WBMih0 j0ldz/Gwe2raeQCmhCwkfa4cT7eFA4WAc8ZCqtEBIqUZLnfJKiQlR0Mg/0Fgxf5xLzBF Y1zJ7MDdXAQ8LmbMQb+bI895WDnmlSa9Lo03P4fvh4V9MoSWlJ1q5u/yguHCQyhxP+q5 BsEhmavjtO/T/8EaSq746KHhjmxP9jLZjgJVZPu3Wmue/47GtFXThGfG6wNmRpkZgJ9p uxnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=lkkV/D4FBl4VpuSMZGTrYh9YSr2/j4xtaF6hgnjNnFg=; b=cFREEC3IqyL6Cz7bq+vwM6Hv0Y+OkPCfugzohGlIxWI+bh+WsitkYZn7y0jSyX5RAV ZvIVGJyUnWMml2GgYkPer8LV+F5epsJCUa+r1/3TlnOZUN5hELRhvGNrhzGt0Kw5GBhK 2kbEVSjqU1EAj0mYYMX+dUgDAWvpZvMkEaHnWrooy+MFthuvj5b/3l0AJ5u7M8pQ+lBq ak18SERYosTBHvuj1vBIM2kMCZDcyiQbv+gr4gxxaYCDWZl7bOBa8jd+OdUKFD+sWfL9 r61wmaGyuIppIPENkyIWf3ZHm+Zb5pxI9GtwtTBDc5IiyyunhSbPyrI7f+wsgys75sob yI5A== X-Gm-Message-State: AOPr4FXkIndgVgU+nh55nLwoStJhToKoM5T9BZ8AdXFQCqM2wgzjHW7EliQaQumcUi3+GdhijJAWQGUglPAB3g== MIME-Version: 1.0 X-Received: by 10.31.5.71 with SMTP id 68mr80018vkf.25.1460418489231; Mon, 11 Apr 2016 16:48:09 -0700 (PDT) Received: by 10.159.38.199 with HTTP; Mon, 11 Apr 2016 16:48:09 -0700 (PDT) Date: Mon, 11 Apr 2016 16:48:09 -0700 Message-ID: From: Suhas Nandakumar To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a1143d2e046331f05303e2d80 Archived-At: Subject: [Perc] PERC Virtual Interim - Doodle Link X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:48:12 -0000 --001a1143d2e046331f05303e2d80 Content-Type: text/plain; charset=UTF-8 Hello All In order to keep the momentum from the IETF 95 going and to focus on closing open issues with respect to Key Management Protocol, here is the doodle poll link with options for the Virtual Interim http://doodle.com/poll/tmp4mu2isx5bkna8 Please let us know of your availability and thanks for the participations Regards Richard/Suhas --001a1143d2e046331f05303e2d80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 In order to keep the m= omentum from the IETF 95 going and to focus on closing open issues with res= pect to Key Management Protocol, here is the doodle poll link with options = for the Virtual Interim

http://doodle.com/poll/tmp4mu2isx5bkna8


Please let us know of your availabil= ity and thanks for the participations

Regards
Richard/Suhas
--001a1143d2e046331f05303e2d80-- From nobody Tue Apr 19 21:40:53 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EC012EB45 for ; Tue, 19 Apr 2016 21:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhKhreURSvhO for ; Tue, 19 Apr 2016 21:40:51 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4072512EB47 for ; Tue, 19 Apr 2016 21:40:51 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t10so41601251ywa.0 for ; Tue, 19 Apr 2016 21:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=Sp26Ji4iK67Y6AkXxBrbIOLxf8dEur31CYDI3fzeY3g=; b=FqEOSFgHqxZO0BT9dfle4mGKzRDfhHx4tyyqbzdrpRCSD0aurNde6L4F8mv8DmOi0H h2HMXodwRHCecojiVRIKRVnRSTPc2JHjusRg/IZi84KwT9++cRF8GjPX5YkN1TaS+2fO kaR6pdgeOPEU4HPHXFUf8Wt+xDKiiaV+TtTUSYDfOB7JpjBzwWpW3fGhO3oZyAmLRggS NURhCId3h4PA2Etap2XVGjbKqLtK5k/ZnZInilIkQ7etEPbJm2coG+rGwOTJVWqZCieQ /aHYFNQ2UnCioHk1IG4yy24hVQi989VeWanG53j9ngsaOrJsLMcyrRpqDO7CraVbMSk5 HmMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Sp26Ji4iK67Y6AkXxBrbIOLxf8dEur31CYDI3fzeY3g=; b=Nt5whWXu+8YTn8Rbl12eBff4UfnjSmbLEByf48vYbJDvqUJluadOetIAN6AXHsdpIG xCrbsR04Wt3yJC0R+eaT2RRkSaJNeu/kU3kY+E6CGCFKKhu7oIcSQhVJOPRXQEbAWGHZ LiAJT5EgJUFiLTe9TIDvd6+pmkbnt4sOZXDl761224KmNZL1DoB1LQBOwdV+yS847R5B wSTwRDDhnTkPg8YQ8flMm9K4BGeSXJ7yvt1bb5dn7WLCuHIopUH+1mPK5A1jR+t0qrbT z0isC0WYWkiTKVDvumDBOHaV+cML01lFuMGC6/yCzDGquhvCKdxUoljpIptkep2nOL+W 74yA== X-Gm-Message-State: AOPr4FUNOt5wBtcUdtjvWRiN4LuItPBNhNME31QYgcHNsD9mP/rPAgv9rhf45pqVSHMLi+m0v3mSz6ZFYFKwMw== MIME-Version: 1.0 X-Received: by 10.37.20.133 with SMTP id 127mr4087516ybu.95.1461127250452; Tue, 19 Apr 2016 21:40:50 -0700 (PDT) Received: by 10.129.54.15 with HTTP; Tue, 19 Apr 2016 21:40:50 -0700 (PDT) Date: Tue, 19 Apr 2016 21:40:50 -0700 Message-ID: From: Suhas Nandakumar To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a113ea110bc2b900530e332d3 Archived-At: Subject: [Perc] WG Adoption of perc-double, perc-media-framework and more X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:40:52 -0000 --001a113ea110bc2b900530e332d3 Content-Type: text/plain; charset=UTF-8 Hey all, In Buenos Aires, there was consensus in the room to adopt the following drafts as WG documents: * draft-jones-perc-private-media-framework * draft-jennings-perc-double This message is to confirm that consensus. If you are opposed to any of these drafts becoming a WG document, please say so (and say why). Please have your response in by May 6th. (We also promised a call to adopt EKT, i.e., draft-jennings-perc-srtp-ekt-diet. We will do that once the authors publish a revision to address the issues they pointed out in the meeting.) Thanks, The Chairs --001a113ea110bc2b900530e332d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

In Buenos Aires, there was consensus in th= e room to adopt the following drafts as WG documents:

* draft-jones-= perc-private-media-framework
* draft-jennings-perc-double

This me= ssage is to confirm that consensus.=C2=A0 If you are opposed to any of thes= e drafts becoming a WG document, please say so (and say why).=C2=A0 Please = have your response in by May 6th.

(We also promised a call to ado= pt EKT, i.e., draft-jennings-perc-srtp-ekt-diet. We will do that once the a= uthors publish a revision to address the issues they pointed out in the mee= ting.)

Thanks,
The Chairs
--001a113ea110bc2b900530e332d3-- From nobody Tue Apr 19 21:51:20 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0312EB99 for ; Tue, 19 Apr 2016 21:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTa05EHVM0fF for ; Tue, 19 Apr 2016 21:51:16 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966AA12EB96 for ; Tue, 19 Apr 2016 21:51:16 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id j74so36761079ywg.1 for ; Tue, 19 Apr 2016 21:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=OctX/V6vkvMM5eME9+iq4aYN/YlSKTscmjBOT6hy0Fo=; b=rS6uzI9ogr42MFSdcqf7wJkNfwddlrsAEs5S1LOSdgjDBinaXAu1GET4I09NMLS9Su 9vUN0j4lqCmp7PtuLZLHTVu93lyUTXkuwpAWVo6BlMbOSDJXt/JVeHbv0Hmc5XigwzbG RbNeqTI3Th7iIBKPkCtUi1OmTQJGedsGTzoWXsv23DAlH1Scku+xfUF1vJxyygw0HLDK 9LjpAfSdKWRY5AIkLFoMZisXPJb8EJeNBQMfW49ifXq9I928qPUIUjEiCja7JALHv6gT SAD0lEBKEDuz56gfqABbK2sHKUftpoAk2/R53XGUtkZxfAhWji213GNRSOKdd5jFIpM9 Thrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=OctX/V6vkvMM5eME9+iq4aYN/YlSKTscmjBOT6hy0Fo=; b=MAvbRH7q1kJ8Uj6ejLnIUQlK4tPS8zJjw1Buwi9tZsNVOMTu/j0UYTCYEzqTYc26D8 NXIj5SFsnybN/j/LZSJ8kKOM9SKlomfY5HTpvOGyi5vAzkkEYuJd/qClYvFyEoGerspJ qAWdRfpQqduyAhnANADGN8PrlTn7uwgySTuv1I+vLiO0MFlKNJ+IiE0nFU0/uyn/d9/o R6mfY6lctJHXwldPfN+b1+8aDVUqGA9so+fqsvWwtYvgH3GmDrgM5fC3SBNpsUFDlP9x ykQhMFIGS+OIK90wasyG40QpCVYybyJ0asoUVuJWpQ0pN1RHtLJrMZzhsdQhQ/BHuZ8u G7AQ== X-Gm-Message-State: AOPr4FVSizjxYE+s0ASvs89fCRLegWw9PlzDPBzOoP465o1pdX7YOPDnAZpAmOytCX1SA0jzFxeMOLEzrvSKuA== MIME-Version: 1.0 X-Received: by 10.37.24.69 with SMTP id 66mr3920221yby.187.1461127875881; Tue, 19 Apr 2016 21:51:15 -0700 (PDT) Received: by 10.129.54.15 with HTTP; Tue, 19 Apr 2016 21:51:15 -0700 (PDT) Date: Tue, 19 Apr 2016 21:51:15 -0700 Message-ID: From: Suhas Nandakumar To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a113fc6b203764d0530e3580b Archived-At: Subject: [Perc] 4/27 PERC Virtual Interim Agenda X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 04:51:18 -0000 --001a113fc6b203764d0530e3580b Content-Type: text/plain; charset=UTF-8 Hello All Thanks everyone for participating in the doodle poll. Based on the poll results, we plan to have our next virtual interim on :- *Wednesday, the 27th (4/27) for a 60 minute session at 8 AM PST* The focus of this interim meeting will be on discussing requirements and open issues related to the tunnel protocol between MDD and the KMF. Draft Agenda : 10 mins Chairs Intro 20 mins Requirements 30 mins Tunnel Protocol WebEx link for the same : https://go.webex.com/join/snandaku Look forward for the discussions. Please let me or Richard know if you have any questions. Cheers Perc Chairs --001a113fc6b203764d0530e3580b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 Thanks everyone for pa= rticipating in the doodle poll.=C2=A0 Based on the poll results, we plan to= have our next virtual interim on :-

=C2=A0 Wednesday, the 27th (4/27) for a 60 minute = session at =C2=A08 AM PST


The focus of this interim meeting will be on discussing requirements and = open issues related to the tunnel protocol between MDD and the KMF.

Draft Agenda :

10 mins Chairs In= tro
20 mins Requirements
30 mins Tunnel Protocol
<= div>
WebEx link for the same =C2=A0:

https://go.webex.com/join/s= nandaku



Look= forward for the discussions.=C2=A0

Please let me = or Richard know if you have any questions.



Cheers
Perc Chairs

--001a113fc6b203764d0530e3580b-- From nobody Wed Apr 20 11:28:18 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6A12D1A5 for ; Wed, 20 Apr 2016 11:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aVK23p48fYl for ; Wed, 20 Apr 2016 11:28:15 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 C77FC12D7BB for ; Wed, 20 Apr 2016 11:28:11 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so63351487ywa.0 for ; Wed, 20 Apr 2016 11:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=WK9OurXIC0vgCs2DurBYocS1qhg/VgqF+S7zFTHNrVw=; b=vnAdLCGbcZUvgANyjxNAWxVImjFR2xbEkSLpjlO/idmf2QWFZlr3wLmcwbZB4gYcYO 4Y3g2Jlm0gRWw09ALPuhO9bwkYBCQ0nOj7I/WCdRfz9s/hKPanidNEQr+5hFpR02+B4P Y9g4agZBSlwOT7wTqFP7cRBxkCyTUQZWSwgjgoC+x4Y7y2F+MUnsIiLrUIHYNjraaxS9 4Pj1FPTqHTiNc4COYfNFkDaUaosvlnnoepA/v9gteLEBl1NT4CpIGW/6UmwL2jdxsCbd FPKN9ELDavFB/WWbPQ87jU702lXBb0/cinw4yRFmHWsYd1vMSudhjogq5dvt1od+BZ/0 ksBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=WK9OurXIC0vgCs2DurBYocS1qhg/VgqF+S7zFTHNrVw=; b=H/VMTdWaUnQWBYk0mspy4zGYfqWt9dYWZFKsgzU8UkS5zyikhvD9SZgiUcwQyLHq4l FblmJnouF9xsUigVB+cWhxUjsKhcg/jGM5Va0GPtNElXIQ8L+1eqSFeQgEcy8b9Zh+aT wRZCk97jmkasT7dejKmiLqFpHxP0wwQA/vZxkpTWXOipTcTpmmJVWrDePtNVIWXINd7v Kp/Nqun/3/lNjkfuOuxkU6ceGjtx2Gu5GoW35WKexh7PX0B6ds0Trx4gcztJhjuhXrTO WNh5Xk+p/wpk7ot1wIhfjZWh59BrEWlF8ivmJra8ix2eDZfn6Khr/su9RJWk2awjGeXt Tx8A== X-Gm-Message-State: AOPr4FUD/49qB7dPux5qeXo7CF747ZG5NBOejH8ONf5c7MXhsLV05K2zObINwbjVo+fNL0rlEGdh7L1vnfxfvg== MIME-Version: 1.0 X-Received: by 10.13.193.195 with SMTP id c186mr7143535ywd.285.1461176891058; Wed, 20 Apr 2016 11:28:11 -0700 (PDT) Received: by 10.129.54.15 with HTTP; Wed, 20 Apr 2016 11:28:11 -0700 (PDT) Date: Wed, 20 Apr 2016 11:28:11 -0700 Message-ID: From: Suhas Nandakumar To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114ed1e48bb3bd0530eec18e Archived-At: Subject: [Perc] WG Adoption of draft-jennings-perc-srtp-ekt-diet-01 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:28:17 -0000 --001a114ed1e48bb3bd0530eec18e Content-Type: text/plain; charset=UTF-8 Hello All Cullen has submitted a new version of EKT Diet spec (-01) after adding the text that was accidentally omitted from the -00 spec. Please consider this mail as a call for adopting "draft-jennings-perc-srtp-ekt-diet-01 ( https://datatracker.ietf.org/doc/draft-jennings-perc-srtp-ekt-diet) as the WG document. If you are opposed to it becoming a WG document, please say so ( and say why). Please have your response in my May 6th Thanks Perc Chairs --001a114ed1e48bb3bd0530eec18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 =C2=A0Cullen has submi= tted a new version of EKT Diet spec (-01) after adding the text that was ac= cidentally omitted from the -00 spec.


Please consider this mail as a call for adopting "draft-jennings-pe= rc-srtp-ekt-diet-01 (https://datatracker.ietf.org/doc/draft-jennings-pe= rc-srtp-ekt-diet) as the WG document.

If you a= re opposed to it becoming a WG document, please say so ( and say why). Plea= se have your response in my May 6th

Thanks
Perc Chairs

--001a114ed1e48bb3bd0530eec18e-- From nobody Mon Apr 25 14:33:47 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3AD12D0B0; Mon, 25 Apr 2016 14:33:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425213345.30158.4135.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 14:33:45 -0700 Archived-At: Cc: perc-chairs@ietf.org, ben@nostrum.com, snandaku@cisco.com, perc@ietf.org Subject: [Perc] perc - New Meeting Session Request for IETF 96 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 21:33:45 -0000 A new meeting session request has just been submitted by Suhas Nandakumar, a Chair of the perc working group. --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtcweb tls avtcore avtext clue siprec netvc acme lurk Second Priority: tcpinc oauth jose straw sipcore stir payload xrblock uta mmusic modern saag Third Priority: stox codec dispatch insipid p2psip kitten Special Requests: added modern and saag as conflicts per Ben and Alissa --------------------------------------------------------- From nobody Mon Apr 25 14:34:17 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFB912B02B; Mon, 25 Apr 2016 14:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425213415.30206.6410.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 14:34:15 -0700 Archived-At: Cc: perc-chairs@ietf.org, ben@nostrum.com, snandaku@cisco.com, perc@ietf.org Subject: [Perc] perc - Update to a Meeting Session Request for IETF 96 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 21:34:16 -0000 An update to a meeting session request has just been submitted by Suhas Nandakumar, a Chair of the perc working group. --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: rtcweb tls avtcore avtext clue siprec netvc acme lurk Second Priority: tcpinc oauth jose straw sipcore stir payload xrblock uta mmusic modern saag Third Priority: stox codec dispatch insipid p2psip kitten Special Requests: added modern and saag as conflicts per Ben and Alissa --------------------------------------------------------- From nobody Tue Apr 26 23:58:30 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95712D1CE for ; Tue, 26 Apr 2016 23:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0UvjG0z5oHn for ; Tue, 26 Apr 2016 23:58:28 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8818112D097 for ; Tue, 26 Apr 2016 23:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:To:From; bh=syy3A2/A1ZKlO7GKsEtDzxj1kIzma4kw1wOryOP5Ph4=; b=gmFnFbSP/X9AQAjGRcJwJQ+uGy GGZVs/h1ktnKvoRxHDaOmJasXTTUiB0tfXq22JH7VOK5Rr0ikyQRatHhXu7YrqBWwVHvbZLlBctmi tE58hyXRxu2tYXWnidZ06FdK7mQW55AgiQAJO5cymPPnha8t3vAYT5ukabL4JBIEDnYuliXHETfhG hldnjaDuORscWZxknK6EqyffbuFIPLWtVZgH86ElaBTbCwYVRMhygqNtJWHPKPwwYpugXxtvaMrJX NG5PPEcGUI7umA8Jewk9H84oIXacIrGteWIYIEXgehhR6+He5H6me8j/8m/v0BTXvgXVY7MFh1fnM Y3p8AeVw==; Received: from ppp118-209-116-64.lns20.mel4.internode.on.net ([118.209.116.64]:62088 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1avJQY-001kaf-6A; Wed, 27 Apr 2016 16:58:26 +1000 From: Christian Groves To: "P E. Jones" , perc@ietf.org Message-ID: Date: Wed, 27 Apr 2016 16:58:23 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Perc] draft-jones-perc-dtls-tunnel questions? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 06:58:29 -0000 Hello Paul, Just reviewing https://tools.ietf.org/html/draft-jones-perc-dtls-tunnel-02 a couple of minor comments/questions: 1. Clause 6.x: Are 2 octets really needed to indicate version information? Seems one byte would be enough. (I know this will muck up your diagrams). You could use one of the octets for Data Type so the message type is known at the start of the header. 2. Clause 6.2: "Length: This is the length in octets of the protection profiles. This length must be greater than or equal to 2." I take it that the value must be >= 2 AND be a multiple of 2 given that protection profiles are 2 octets. Regards, Christian From nobody Wed Apr 27 05:58:46 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81C12D15D for ; Wed, 27 Apr 2016 05:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEWpO-Dphaqz for ; Wed, 27 Apr 2016 05:58:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DFF12D151 for ; Wed, 27 Apr 2016 05:58:37 -0700 (PDT) Received: from dyn-229.arid.us (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u3RCwZCx028479 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2016 08:58:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1461761916; bh=0/RR0s403J3JOSDwlch0mtToYfUwvinM+nsNoZofOk0=; h=In-Reply-To:References:Subject:From:Date:To; b=SwxeEeRZiB/ZIqr4wjo9nL+DUUgco1p7+U3NnbUL+XLeZJQmFHm5F/1ru3rmMmftm dDSYdJqUiY58L+G5E+iUW1x4OpVMQTcSDO2+CwFfdXy605xYDZ5rnl0GmxARJQXpVO Dsq2xCi1XwL8+1c3Y2DwFnhQdDB02DgP4SY0cK3U= User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----NXG7MSXIDIOEA2NTCO9896IPVCBR68" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Wed, 27 Apr 2016 08:58:34 -0400 To: Christian Groves , perc@ietf.org Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 27 Apr 2016 08:58:36 -0400 (EDT) Archived-At: Subject: Re: [Perc] draft-jones-perc-dtls-tunnel questions? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 12:58:39 -0000 ------NXG7MSXIDIOEA2NTCO9896IPVCBR68 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Christian, 1) No, but that was a derivative of the syntax I was using to create the protocol. I think I commented on the in the meeting. In the proposal today, I shrank it down to one octet and then I was told to remove it entirely. So, we have one octet reserved in the message header. 2) Yes, that would be true. With the protocol I'll talk about today, we don't even have a length over that. We have a length in the common header and then the data. Paul -------- Original Message -------- From: Christian Groves Sent: April 27, 2016 2:58:23 AM EDT To: "P E. Jones" , perc@ietf.org Subject: [Perc] draft-jones-perc-dtls-tunnel questions? Hello Paul, Just reviewing https://tools.ietf.org/html/draft-jones-perc-dtls-tunnel-02 a couple of minor comments/questions: 1. Clause 6.x: Are 2 octets really needed to indicate version information? Seems one byte would be enough. (I know this will muck up your diagrams). You could use one of the octets for Data Type so the message type is known at the start of the header. 2. Clause 6.2: "Length: This is the length in octets of the protection profiles. This length must be greater than or equal to 2." I take it that the value must be >= 2 AND be a multiple of 2 given that protection profiles are 2 octets. Regards, Christian _______________________________________________ Perc mailing list Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc ------NXG7MSXIDIOEA2NTCO9896IPVCBR68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Christian,

1) No, but that was a derivative of the syntax I was using to create the protocol. I think I commented on the in the meeting. In the proposal today, I shrank it down to one octet and then I was told to remove it entirely. So, we have one octet reserved in the message header.

2) Yes, that would be true. With the protocol I'll talk about today, we don't even have a length over that. We have a length in the common header and then the data.

Paul

From: Christian Groves <Christian.Groves@nteczone.com>
Sent: April 27, 2016 2:58:23 AM EDT
To: "P E. Jones" <paulej@packetizer.com>, perc@ietf.org
Subject: [Perc] draft-jones-perc-dtls-tunnel questions?

Hello Paul,

Just reviewing

https://tools.ietf.org/html/draft-jones-perc-dtls-tunnel-02

a couple of minor comments/questions:

1. Clause 6.x: Are 2 octets really needed to indicate version 
information? Seems one byte would be enough. (I know this will muck up 
your diagrams). You could use one of the octets for Data Type so the 
message type is known at the start of the header.

2. Clause 6.2: "Length: This is the length in octets of the protection 
profiles. This length must be greater than or equal to 2." I take it 
that the value must be >= 2 AND be a multiple of 2 given that protection 
profiles are 2 octets.

Regards, Christian



Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
------NXG7MSXIDIOEA2NTCO9896IPVCBR68-- From nobody Wed Apr 27 11:15:36 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA1E12DB70 for ; Wed, 27 Apr 2016 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zZr8i4nDVu5 for ; Wed, 27 Apr 2016 11:15:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 F410012DB4A for ; Wed, 27 Apr 2016 11:15:33 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j74so85002518ywg.1 for ; Wed, 27 Apr 2016 11:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=+/o9oD2M9zbDpwwDZDNBeOZS4TxBVYszTIlGjREqvZo=; b=VrRg3fae5BITrkUC0FFGqyhH0OGS7jU2khaHK9qQuDshyqUdqEqd+jhDdoKi0Ky4e0 Q1cIr6v0iTQ0cPx/hz4/pKaszxACJH4nFoFZVjSpKjUKvaKTifXeK8L0JxEHksFqnEWL sS7wck7yj6dQttghaYb7p+IKLgn2uFgRXuNlgsJ3vagImTF6+7rI5/dCCa29oe/bv914 6NbN0U7izcjmXNii8nMMXUvTz6DcGZjvqVkhtzn/n12US7l+wnjX7J7ZEH19RyY0PmOy Xkdqz+SOMfw9AOAYuBpC+5tf5GI38BvCOvvxxVGRfLPP3LvTcJQelBd/7DtY4HbZcvgT yB6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=+/o9oD2M9zbDpwwDZDNBeOZS4TxBVYszTIlGjREqvZo=; b=B6lkOev64ywGBY4nMH+CL5GTUxrYfL0sw6lnAZf83aYrd2WOJmwSnpyWv8MNXSgL2I x6PcNjtipLCliR5oYNsahlitEnELRx4ooYRL+e0E3rf2JMuPafNBRhXfPc1bLi5UvXat A38ROfJfXly7ZkcJ0cemYa4bvyFOSrK6+HVMNa1Z0elSNFZRpLuBLd2eNOzKiTsO9BJF KwBpk5SFT7xVAMupAnd2QdM1f9YWF/LXrKTa8MDIFGxslWxsjx/R2LtG9k+vL/gug+4z j7rglXYxpH7BilkgzjUzz/yEneTdVYh2SlJfdXUxdD6mBKWh0iC6W2cwxD41985BKW1Z UCAg== X-Gm-Message-State: AOPr4FUDRDx3cfOjHrRG/LIHyTNzbBhu8BqcqlzULWlQxFKu5VGdT3wfU9e4ppTnK121S7giRsg6O0OdzFvbgg== MIME-Version: 1.0 X-Received: by 10.129.128.70 with SMTP id q67mr5568286ywf.215.1461780933268; Wed, 27 Apr 2016 11:15:33 -0700 (PDT) Received: by 10.129.54.15 with HTTP; Wed, 27 Apr 2016 11:15:33 -0700 (PDT) Date: Wed, 27 Apr 2016 11:15:33 -0700 Message-ID: From: Suhas Nandakumar To: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0329d4445b7305317b65f0 Archived-At: Subject: [Perc] Perc 4/27 Virtual Interim Proceedings X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:15:35 -0000 --94eb2c0329d4445b7305317b65f0 Content-Type: text/plain; charset=UTF-8 Thanks everyone for participating in the discussions today at the virtual interim. Please find the proceedings from our meeting here : https://www.ietf.org/proceedings/interim/2016/04/27/perc/proceedings.html Let me/Richard know if you find anything missing from the notes captured. Cheers richard/suhas --94eb2c0329d4445b7305317b65f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0 =C2=A0Thanks everyone for parti= cipating in the discussions today at the virtual interim.

Please find the proceedings from our meeting here :=C2=A0https://www.ietf.org/proceedings/interim/2016/04/27/perc/proceedings.html<= /a>



--94eb2c0329d4445b7305317b65f0-- From nobody Wed Apr 27 15:19:53 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74F612D1AB for ; Wed, 27 Apr 2016 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS_ohRspGnNp for ; Wed, 27 Apr 2016 15:19:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0AAB712D0CF for ; Wed, 27 Apr 2016 15:19:50 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3RMJjMO032225 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Apr 2016 17:19:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "perc@ietf.org" From: Adam Roach Message-ID: <57213B00.1090207@nostrum.com> Date: Wed, 27 Apr 2016 17:19:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Magnus Westerlund Subject: [Perc] Open issue: TCP or UDP for the tunnel? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 22:19:52 -0000 Today's interim call focused on the protocol between the KMF and the MDD. While we didn't make it very far into the proposed solution, the call was still very useful in teasing out some of the larger open issues that we're going to want to think about. I'm going to discuss one in this message, and will be sending out subsequent messages to talk through others. One issue we discussed was the transport to be used between the KMF and the MDD. Prior to the Buenos Aires meeting, discussions had assumed that such a connection would be some form of DTLS, presumably directly on top of UDP (but see below). This is the design reflected in the current tunnel protocol draft (draft-jones-perc-dtls-tunnel-02). During our face-to-face conversations in Buenos Aires, Magnus Westerlund raised some concerns about whether the overhead of encapsulating DTLS handshake messages inside a "Tunnel" message that is then itself carried over DTLS runs the risk of exceeding the underlying MTU. By my understanding (and a quick check of RFC6347 confirms this), one of the adaptations made for DTLS is the ability to fragment (at the TLS level, not the IP level) handshake messages according to the application's knowledge and/or guess of PMTU. This means that, at worst, the use of DTLS for the tunnel makes us subtract on the order of 30 bytes (for the "Tunnel" messages), plus whatever overhead the additional DTLS header imposes, from our notion of PMTU for handshake messages in PERC implementations. I'm not close enough to that part of the stack to know how PMTU is computed (or assumed) for normal DTLS handshake usage, but I presume it's pretty conservative. Perhaps someone with DTLS implementation knowledge can weigh in on the topic. All of which is to say the fragmentation issue seems to be of little or no consequence. I'm happy to be corrected by someone who is intimately familiar with the inner workings of DTLS if I'm off base here (Richard? EKR?). So, unless that turns out to be an issue that legitimately runs us over MTU on a regular basis, we should make our decision based on the properties of the transports. The point I made on the call was fundamentally this: once we make the assumption that the network containing the KMF is suitable for passing media to and from the MDD (which is manifestly true for a co-located KMF, and presumptively true for a non-co-located one) for the duration of a conference, then we know for certain that it is behind a firewall that can support UDP associations for the duration of a conference. What we do *not* know is that it is behind a firewall that is willing to support a TCP connection for that long. And we do know that some firewalls -- intended to be HTTP proxies -- limit the duration of TCP connections to prevent unauthorized use for non-HTTP purposes. So my take here is that we're going to want to retain the use of DTLS rather than shifting to a TLS-based tunnel for the KMF-MDD communication, unless I've made some bad assumptions about how DTLS does handshake fragmentation. /a From nobody Wed Apr 27 16:57:33 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406912D51A for ; Wed, 27 Apr 2016 16:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-wNdHFXaR1n for ; Wed, 27 Apr 2016 16:57:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CDE0C12D509 for ; Wed, 27 Apr 2016 16:57:28 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3RNvRhA040746 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 27 Apr 2016 18:57:28 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "perc@ietf.org" From: Adam Roach Message-ID: <572151E7.3020108@nostrum.com> Date: Wed, 27 Apr 2016 18:57:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] Open Issue: Tunnel Multiplexing X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 23:57:31 -0000 Following up from my other message, once we nail down how we're communicating between the KMF and the MDD, we need to decide how we represent the endpoint-to-KMF traffic on that interface. For this message, I'm assuming that we're still planning to use a datagram-based interface between the KMF and MDD rather than a stream-based one. If that assumption does not hold, we'll need to revisit these issues. On the call, I heard several different options, which I will attempt to summarize at a high level: 1. DTLS/Tunnel/DTLS/UDP: Have the KMF establish one (or possibly more) DTLS association per conference, and then send the client-to-KMF packets inside that association as application data, and use the scheme described in draft-jones-perc-dtls-tunnel-02 to multiplex the client DTLS associations within this tunnel. 2. Multiple DTLS/UDP: Have the KMF establish one DTLS association with the MDD for key management. The KMF will forward every DTLS packet received from clients to the KMF, in raw form, using a unique source port for each client. 3. DTLS/SCTP/DTLS/UDP: Have the KMF establish one (or possibly more) DTLS association per conference, and run SCTP inside this DTLS association. Using one flow per client, tunnel client DTLS packets inside the SCTP association. 4. DataChannel/SCTP/DTLS/UDP: Something like #3 but using WebRTC data channels. I think Richard would need to expand on this, since the deeper I go on trying to figure out the details, the less it holds up to scrutiny. I assume I've misunderstood something. Compared against the status quo (#1): #2 has the benefit of allowing the KMF to simply process inbound client packets using a stock DTLS stack, rather than having to worry about any kind of message encapsulation. It has the drawback of eating up substantial NAT/Firewall resources (ports and port bindings). It also has the lesser issues of requiring additional mechanism to associate the client connections with their conference (for KMFs that can serve more than one conference at a time), since the binding is not implicit (as it is with other approaches), and of requiring us to bolt reliability on to the MDD-to-KMF key management protocol. #3 has the property (unless we work to avoid it) of decoupling the MDD-to-KMF protocol (communicating ciphersuites and selected keys) from the client-to-KMF messages, at the cost of requiring PERC endpoints and KMFs to include an SCTP stack. This is no big deal for WebRTC setups with co-located KMFs, but it may be unnecessarily complicated for non-WebRTC clients and for enterprise-hosted KMFs. I think the idea behind #4 was to allow WebRTC endpoints that are serving as KMFs to use the DTLS association with the MDD as the KMF-MDD communication channel, but I'm not 100% certain. If such is the case, then we can reduce the number of DTLS associations between the endpoint/KMF and the MDD from two to one, at the cost of some design (and probably implementation) complexity. Like #3, it pushes SCTP onto endpoints and KMFs that might not otherwise need it, with the additional complication of also pushing the DataChannel protocol onto them. Again, I'll leave it to Richard to explain the approach and benefits, as I believe it was he who brought it up. Regardless of whether we go with #4, there's a good chance that we could shoehorn any of the other approaches into re-using the DTLS-SRTP connection from a co-located endpoint/KMF for key management. I think we'd need to sketch out exactly how that would work before we weigh the impact of doing so against the value of having only one association. What I most worry about with such an approach is that it basically results in two disparate modes of operation from an MDD perspective: one for a co-located KMF, and one for a non-co-located KMF. Once we have non-trivial protocol differences between these two network architectures, I fear we're going to rapidly get into situations where some MDDs will support only one style of conference and not the other, and will be difficult to adapt to support the other. We would effectively have two different protocols for performing the same function, which isn't generally good for interop. /a From nobody Wed Apr 27 19:31:24 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F8C12B043 for ; Wed, 27 Apr 2016 19:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OR4u4KJP0Kl for ; Wed, 27 Apr 2016 19:31:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8FB12B00A for ; Wed, 27 Apr 2016 19:31:21 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u3S2VHGQ023004 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2016 22:31:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1461810678; bh=Z0WqAt3iEGbmbZF3KlV7EMdpFoTYLZPNyVCs6pju1lk=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=HpJcQAgTaV/vPQmVhajQ8NsLJAuvZV55T/+kDbTzfJ7Q71ZMa4ncBks2t3fp3noYr QlwSk6AuVsCj7cixXIn0SGbSkRGUm/ZetEBeolfcnd5bnKQKJi1w5rEbH6umB+fYCO vFUALLbOSW90c7I0u3gQb+nG2fGmj+JGctOLPRNM= From: "Paul E. Jones" To: "Adam Roach" , "perc@ietf.org" Date: Thu, 28 Apr 2016 02:31:27 +0000 Message-Id: In-Reply-To: <57213B00.1090207@nostrum.com> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 27 Apr 2016 22:31:18 -0400 (EDT) Archived-At: Cc: Magnus Westerlund Subject: Re: [Perc] Open issue: TCP or UDP for the tunnel? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 02:31:24 -0000 Adam, You are correct that that the handshake messages are fragmented "under=20 the covers" to ensure that the MTU size is not exceeded. At least with OpenSSL, there is a function called SSL_set_mtu() that=20 allows one to set an MTU. It will allow one to reduce the MTU size, but= =20 not exceed what the DTLS stack believes is the max MTU. Additionally,=20 one can query what the stack thinks is the current MTU via=20 DTLS_get_link_min_mtu(). It gets this by querying the kernel,=20 subtracting some number of octets for IP and UDP overhead (max 48 octets= =20 overhead). The overhead introduced in the current tunnel draft is minimal and we=20 could shrink it further by reducing the size of the version field (or=20 eliminating it) and reducing the size of the association ID. The largest chunk of data added by the tunnel is the key and salt=20 information which is ONLY transmitted when the "Finished" message is=20 sent. For the AES-GCM using a 256 bit key, those would be: Client write: 32 (256 bit) Server write: 32 (256 bit) Client master salt: 12 (96 bits) Server master salt: 12 (96 bits) data type field: 1 Protection profile: 2 MKI length: 1 (this could be eliminated for PERC, because we will not= =20 be using MKI and is only there because it is in DTLS-SRTP) MKI value: 2 (actually variable, but 2 is reasonable. Again, we could= =20 remove this from the protocol.) So, that gives us 91 octets if I counted correctly (beyond the other=20 tunnel header data). If AES-CTR was used, we could add another 2 octets=20 to the read/write salt values (total 4 octets). Let's just say 100=20 octets max. The other part of it is how long is the CipherChangeSpec and Finished,=20 which are sent in the same flight with the key info. I don't have an=20 exact octet count for those. ChangeCipherSpec is about 1 octet (plus=20 the record overhead) and Finished is about 12 (plus the record=20 overhead), as I understand. In any case, it is well below any=20 reasonable MTU size, even with the "tunnel+key info" additions. Paul ------ Original Message ------ From: "Adam Roach" To: "perc@ietf.org" Cc: "Magnus Westerlund" Sent: 4/27/2016 6:19:44 PM Subject: [Perc] Open issue: TCP or UDP for the tunnel? >Today's interim call focused on the protocol between the KMF and the=20 >MDD. While we didn't make it very far into the proposed solution, the=20 >call was still very useful in teasing out some of the larger open=20 >issues that we're going to want to think about. I'm going to discuss=20 >one in this message, and will be sending out subsequent messages to=20 >talk through others. > >One issue we discussed was the transport to be used between the KMF and= =20 >the MDD. Prior to the Buenos Aires meeting, discussions had assumed=20 >that such a connection would be some form of DTLS, presumably directly=20 >on top of UDP (but see below). This is the design reflected in the=20 >current tunnel protocol draft (draft-jones-perc-dtls-tunnel-02). > >During our face-to-face conversations in Buenos Aires, Magnus=20 >Westerlund raised some concerns about whether the overhead of=20 >encapsulating DTLS handshake messages inside a "Tunnel" message that is= =20 >then itself carried over DTLS runs the risk of exceeding the underlying= =20 >MTU. By my understanding (and a quick check of RFC6347 confirms this),=20 >one of the adaptations made for DTLS is the ability to fragment (at the= =20 >TLS level, not the IP level) handshake messages according to the=20 >application's knowledge and/or guess of PMTU. > >This means that, at worst, the use of DTLS for the tunnel makes us=20 >subtract on the order of 30 bytes (for the "Tunnel" messages), plus=20 >whatever overhead the additional DTLS header imposes, from our notion=20 >of PMTU for handshake messages in PERC implementations. I'm not close=20 >enough to that part of the stack to know how PMTU is computed (or=20 >assumed) for normal DTLS handshake usage, but I presume it's pretty=20 >conservative. Perhaps someone with DTLS implementation knowledge can=20 >weigh in on the topic. > >All of which is to say the fragmentation issue seems to be of little or= =20 >no consequence. I'm happy to be corrected by someone who is intimately=20 >familiar with the inner workings of DTLS if I'm off base here (Richard?= =20 >EKR?). > >So, unless that turns out to be an issue that legitimately runs us over= =20 >MTU on a regular basis, we should make our decision based on the=20 >properties of the transports. > >The point I made on the call was fundamentally this: once we make the=20 >assumption that the network containing the KMF is suitable for passing=20 >media to and from the MDD (which is manifestly true for a co-located=20 >KMF, and presumptively true for a non-co-located one) for the duration=20 >of a conference, then we know for certain that it is behind a firewall=20 >that can support UDP associations for the duration of a conference. > >What we do *not* know is that it is behind a firewall that is willing=20 >to support a TCP connection for that long. And we do know that some=20 >firewalls -- intended to be HTTP proxies -- limit the duration of TCP=20 >connections to prevent unauthorized use for non-HTTP purposes. > >So my take here is that we're going to want to retain the use of DTLS=20 >rather than shifting to a TLS-based tunnel for the KMF-MDD=20 >communication, unless I've made some bad assumptions about how DTLS=20 >does handshake fragmentation. > >/a > >_______________________________________________ >Perc mailing list >Perc@ietf.org >https://www.ietf.org/mailman/listinfo/perc From nobody Thu Apr 28 20:39:48 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF512D14E for ; Thu, 28 Apr 2016 20:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6xx1-Rk04ur for ; Thu, 28 Apr 2016 20:39:27 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FDC12B00A for ; Thu, 28 Apr 2016 20:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iFDi5j6Q5Gssw0BCgD1kdeegU9KTSmR9AOTamlElCD0=; b=RnRS4AwshzwAyyQK5OYZ4BUk2H sDPi9fut7tYaNsZDu6atAg3Mlh6gWODWGnimOYYLQkOmm5wOkXQCeao7SI4FgG4gOlR8kL6hWH12A bDsXCyzrb6AMhp/28AYYtZsLSzgy3PiM292m6rFSbiiBhRPNlj9duEUfxPAWns5mXGSQfPV+9howf qC24W2keP+pGnO7CcKQnohwrUWrAsuOAB7RdAhixihQ3/4+Vr9Az/bush//Zh8Dyg6OqEmdUUGoTn BpBfqoSZQVRPlLTf/c9Z5jR8TgJID1ZiBaaupJU/FSEpUL1e4OZoy0RLbAW0d97ey/PE8HIxK4AhK QH+cZ2Ew==; Received: from ppp118-209-116-64.lns20.mel4.internode.on.net ([118.209.116.64]:53554 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1avzH2-00294N-6X for perc@ietf.org; Fri, 29 Apr 2016 13:39:24 +1000 To: perc@ietf.org References: <57213B00.1090207@nostrum.com> From: Christian Groves Message-ID: Date: Fri, 29 Apr 2016 13:39:19 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <57213B00.1090207@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Perc] Open issue: TCP or UDP for the tunnel? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 03:39:46 -0000 +1 for using DTLS. Christian On 28/04/2016 8:19 AM, Adam Roach wrote: > Today's interim call focused on the protocol between the KMF and the > MDD. While we didn't make it very far into the proposed solution, the > call was still very useful in teasing out some of the larger open > issues that we're going to want to think about. I'm going to discuss > one in this message, and will be sending out subsequent messages to > talk through others. > > One issue we discussed was the transport to be used between the KMF > and the MDD. Prior to the Buenos Aires meeting, discussions had > assumed that such a connection would be some form of DTLS, presumably > directly on top of UDP (but see below). This is the design reflected > in the current tunnel protocol draft (draft-jones-perc-dtls-tunnel-02). > > During our face-to-face conversations in Buenos Aires, Magnus > Westerlund raised some concerns about whether the overhead of > encapsulating DTLS handshake messages inside a "Tunnel" message that > is then itself carried over DTLS runs the risk of exceeding the > underlying MTU. By my understanding (and a quick check of RFC6347 > confirms this), one of the adaptations made for DTLS is the ability to > fragment (at the TLS level, not the IP level) handshake messages > according to the application's knowledge and/or guess of PMTU. > > This means that, at worst, the use of DTLS for the tunnel makes us > subtract on the order of 30 bytes (for the "Tunnel" messages), plus > whatever overhead the additional DTLS header imposes, from our notion > of PMTU for handshake messages in PERC implementations. I'm not close > enough to that part of the stack to know how PMTU is computed (or > assumed) for normal DTLS handshake usage, but I presume it's pretty > conservative. Perhaps someone with DTLS implementation knowledge can > weigh in on the topic. > > All of which is to say the fragmentation issue seems to be of little > or no consequence. I'm happy to be corrected by someone who is > intimately familiar with the inner workings of DTLS if I'm off base > here (Richard? EKR?). > > So, unless that turns out to be an issue that legitimately runs us > over MTU on a regular basis, we should make our decision based on the > properties of the transports. > > The point I made on the call was fundamentally this: once we make the > assumption that the network containing the KMF is suitable for passing > media to and from the MDD (which is manifestly true for a co-located > KMF, and presumptively true for a non-co-located one) for the duration > of a conference, then we know for certain that it is behind a firewall > that can support UDP associations for the duration of a conference. > > What we do *not* know is that it is behind a firewall that is willing > to support a TCP connection for that long. And we do know that some > firewalls -- intended to be HTTP proxies -- limit the duration of TCP > connections to prevent unauthorized use for non-HTTP purposes. > > So my take here is that we're going to want to retain the use of DTLS > rather than shifting to a TLS-based tunnel for the KMF-MDD > communication, unless I've made some bad assumptions about how DTLS > does handshake fragmentation. > > /a > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > From nobody Thu Apr 28 21:17:21 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0A12D529 for ; Thu, 28 Apr 2016 21:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwvnnDRLGzHN for ; Thu, 28 Apr 2016 21:17:18 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2757C12D523 for ; Thu, 28 Apr 2016 21:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dRuHoJAevgG1zrOeKWBLr/LQHSOCPLzhsrh1XJIhx2I=; b=Tsd0ht/6VTMtE6X2I+98rxTD83 VdMIXo0abdanjgbMuKcqeVIBYrC3MMzrviPmWKykDbV1M49AHVpP1bcZD69emU/jYQC1XylLc9ahU zp6POS/sK7aflD7BYlDJAWz3sLoW4cKi7bHbN2d4AIsMDI4ATR+SNDAR8UtoBgRuiskUO5h/GXZkv yD7JNTV0v/8ky57B+7q+54nIYv0lZ0doMQvhQarojdLfOSpbod+7F4PnLwzkvXs8oKNNdcwWufYVx gPHuhVVarvIWRi7rXEpduy29gnBZDiy03zckuht0HLY9EDbVfuPanH6yqwz8OZ1mAVeP3H7JmMhKx CkFOmh/Q==; Received: from ppp118-209-116-64.lns20.mel4.internode.on.net ([118.209.116.64]:53648 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1avzrg-002CIQ-6O for perc@ietf.org; Fri, 29 Apr 2016 14:17:16 +1000 To: perc@ietf.org References: <572151E7.3020108@nostrum.com> From: Christian Groves Message-ID: <6ce54383-d009-ce3f-ed87-f5099f2b01f5@nteczone.com> Date: Fri, 29 Apr 2016 14:17:11 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572151E7.3020108@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Perc] Open Issue: Tunnel Multiplexing X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 04:17:20 -0000 Hello Adam, For 2 in the second sentence I assume you mean "The will forward every DTLS packet received from clients to the KMF,.."? For 4, I guess it also depends on whether clients will in general use datachannel towards the MDD given that the MDD isn't trusted. A client may need multiple DTLS associations for datachannels depending on the sub-protocol and peer-endpoints. Given this it doesn't seem onerous for the client to support an additional DTLS association for the co-located KMF/Client case if it means a common method for both co-located and non-located deployments. Regards, Christian On 28/04/2016 9:57 AM, Adam Roach wrote: > Following up from my other message, once we nail down how we're > communicating between the KMF and the MDD, we need to decide how we > represent the endpoint-to-KMF traffic on that interface. > > For this message, I'm assuming that we're still planning to use a > datagram-based interface between the KMF and MDD rather than a > stream-based one. If that assumption does not hold, we'll need to > revisit these issues. > > On the call, I heard several different options, which I will attempt > to summarize at a high level: > > 1. DTLS/Tunnel/DTLS/UDP: Have the KMF establish one (or possibly more) > DTLS association per conference, and then send the client-to-KMF > packets inside that association as application data, and use the > scheme described in draft-jones-perc-dtls-tunnel-02 to multiplex the > client DTLS associations within this tunnel. > > 2. Multiple DTLS/UDP: Have the KMF establish one DTLS association with > the MDD for key management. The KMF will forward every DTLS packet > received from clients to the KMF, in raw form, using a unique source > port for each client. > > 3. DTLS/SCTP/DTLS/UDP: Have the KMF establish one (or possibly more) > DTLS association per conference, and run SCTP inside this DTLS > association. Using one flow per client, tunnel client DTLS packets > inside the SCTP association. > > 4. DataChannel/SCTP/DTLS/UDP: Something like #3 but using WebRTC data > channels. I think Richard would need to expand on this, since the > deeper I go on trying to figure out the details, the less it holds > up to scrutiny. I assume I've misunderstood something. > > > Compared against the status quo (#1): > > > #2 has the benefit of allowing the KMF to simply process inbound > client packets using a stock DTLS stack, rather than having to worry > about any kind of message encapsulation. It has the drawback of eating > up substantial NAT/Firewall resources (ports and port bindings). It > also has the lesser issues of requiring additional mechanism to > associate the client connections with their conference (for KMFs that > can serve more than one conference at a time), since the binding is > not implicit (as it is with other approaches), and of requiring us to > bolt reliability on to the MDD-to-KMF key management protocol. > > #3 has the property (unless we work to avoid it) of decoupling the > MDD-to-KMF protocol (communicating ciphersuites and selected keys) > from the client-to-KMF messages, at the cost of requiring PERC > endpoints and KMFs to include an SCTP stack. This is no big deal for > WebRTC setups with co-located KMFs, but it may be unnecessarily > complicated for non-WebRTC clients and for enterprise-hosted KMFs. > > I think the idea behind #4 was to allow WebRTC endpoints that are > serving as KMFs to use the DTLS association with the MDD as the > KMF-MDD communication channel, but I'm not 100% certain. If such is > the case, then we can reduce the number of DTLS associations between > the endpoint/KMF and the MDD from two to one, at the cost of some > design (and probably implementation) complexity. Like #3, it pushes > SCTP onto endpoints and KMFs that might not otherwise need it, with > the additional complication of also pushing the DataChannel protocol > onto them. Again, I'll leave it to Richard to explain the approach and > benefits, as I believe it was he who brought it up. > > Regardless of whether we go with #4, there's a good chance that we > could shoehorn any of the other approaches into re-using the DTLS-SRTP > connection from a co-located endpoint/KMF for key management. I think > we'd need to sketch out exactly how that would work before we weigh > the impact of doing so against the value of having only one association. > > What I most worry about with such an approach is that it basically > results in two disparate modes of operation from an MDD perspective: > one for a co-located KMF, and one for a non-co-located KMF. Once we > have non-trivial protocol differences between these two network > architectures, I fear we're going to rapidly get into situations where > some MDDs will support only one style of conference and not the other, > and will be difficult to adapt to support the other. We would > effectively have two different protocols for performing the same > function, which isn't generally good for interop. > > /a > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > From nobody Thu Apr 28 21:49:50 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755EA12D535 for ; Thu, 28 Apr 2016 21:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWUIeTgrnmCn for ; Thu, 28 Apr 2016 21:49:46 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 B3E1012B00A for ; Thu, 28 Apr 2016 21:49:46 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id u185so113155368iod.3 for ; Thu, 28 Apr 2016 21:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wFubJrG/EZ84GENf85ZcR7/lnuOg1GSVBG8U34Ddaw4=; b=BdmgFrXj+LsLYd04Al1teZKoQX+LlJ/uG89PcYXmTNtBrAPGwnvWWEqj3vwnW9fo8o elpcDBYONlcbs7fXnJB6OZZLma0G7m+naGTCX94i7BCoqViXc0CtsIDnTc5m41jo+PbH 2ev7UaRQMBel/8aVGVIDrXnLcs/8ZTgE2wk0KEbxSnZqhtO0SoWdLLo6kIEMuzA8LQr4 TqjEAucQhyGnc8S3xTcCOwwfKAbwBjM374WXcn5YoSY3T2C6qF43k5lzAgazeA6hZIDH /biItKcWIPGTRZyjatYNJNDOss+dyi1ASi8cKdDJJ5xBD5fxzmge84cDJRwEMpzf5NlU jkYQ== 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; bh=wFubJrG/EZ84GENf85ZcR7/lnuOg1GSVBG8U34Ddaw4=; b=LoiO9yf16cncV2BR8y9Ee3Ksa+/LLSB82AOMVJWP8baxwnUljbR3v/jfTaFGjxXMft N8/akkCLRMKjlFtx0xe3TfNfPB7uC3DdfWiCnQC+f6j8Uzq/eiV/LI/FUrRfzXTMOHi3 k2xtLbfJp2puyLB+8qfjRyC4lD49qIgj8iFaMJ8xLheu5iCb0AexcBW8EBogN3blAD37 6Hgp7bFuw3rP2hiZgzehxo33Clyj65nDM9OQS98pMi2/ER1jX2E+ClvO23PiIHk8Pp9s A6QTrcX/0UXXrzCAbsaBASayeG1sh4ibvtFBK7kIi7udQM2eRmlFhVaFlNB+BUgRowc8 hMXw== X-Gm-Message-State: AOPr4FX1yPCDV+FHgW+dcxPWU1foFK3LOimbe1Cv30A9pugTZzA9u7QZ9ogXa+2UikXxkHFo4gwyzOyEY7ckqQ== MIME-Version: 1.0 X-Received: by 10.107.59.85 with SMTP id i82mr20365705ioa.108.1461905385995; Thu, 28 Apr 2016 21:49:45 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 28 Apr 2016 21:49:45 -0700 (PDT) In-Reply-To: <57213B00.1090207@nostrum.com> References: <57213B00.1090207@nostrum.com> Date: Fri, 29 Apr 2016 14:49:45 +1000 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Magnus Westerlund , "perc@ietf.org" Subject: Re: [Perc] Open issue: TCP or UDP for the tunnel? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 04:49:48 -0000 On 28 April 2016 at 08:19, Adam Roach wrote: > This means that, at worst, the use of DTLS for the tunnel makes us subtract > on the order of 30 bytes (for the "Tunnel" messages), plus whatever overhead > the additional DTLS header imposes, from our notion of PMTU for handshake > messages in PERC implementations. I'm not close enough to that part of the > stack to know how PMTU is computed (or assumed) for normal DTLS handshake > usage, but I presume it's pretty conservative. Perhaps someone with DTLS > implementation knowledge can weigh in on the topic. DTLS records have a 13 octet header, and will likely carry a 16 octet authentication tag, so your analysis is correct. PMTU handling in DTLS is fairly crude, but should handle a wart of that size. NSS starts out assuming that it can send 1472 octets (excluding the IP and UDP headers, which make it up to 1500). It then steps down on every other retransmission attempt to 1252, 548, and then 228. That last value is nuts. If you can't get that many octets through, just give up. Future versions of DTLS might be leaner by a few octets on its own headers, but the authentication tag will remain. I don't imagine that saving 10 octets will have much impact here. From nobody Fri Apr 29 13:53:22 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3855712D111 for ; Fri, 29 Apr 2016 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAT8uIgDiduy for ; Fri, 29 Apr 2016 13:53:18 -0700 (PDT) Received: from smtp85.ord1c.emailsrvr.com (smtp85.ord1c.emailsrvr.com [108.166.43.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5960112D530 for ; Fri, 29 Apr 2016 13:53:17 -0700 (PDT) Received: from smtp11.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp11.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9F6972801F7; Fri, 29 Apr 2016 16:53:16 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 2CFF52801CE; Fri, 29 Apr 2016 16:53:16 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Fri, 29 Apr 2016 16:53:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <572151E7.3020108@nostrum.com> Date: Fri, 29 Apr 2016 14:53:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <572151E7.3020108@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Open Issue: Tunnel Multiplexing X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 20:53:20 -0000 Good summary.=20 #3 and #4 just seem to add complexity that is not needed. I prefer 1 as = it seems like 2 can run into running out of ports issues on the KMF.=20 > On Apr 27, 2016, at 5:57 PM, Adam Roach wrote: >=20 > Following up from my other message, once we nail down how we're = communicating between the KMF and the MDD, we need to decide how we = represent the endpoint-to-KMF traffic on that interface. >=20 > For this message, I'm assuming that we're still planning to use a = datagram-based interface between the KMF and MDD rather than a = stream-based one. If that assumption does not hold, we'll need to = revisit these issues. >=20 > On the call, I heard several different options, which I will attempt = to summarize at a high level: >=20 > 1. DTLS/Tunnel/DTLS/UDP: Have the KMF establish one (or possibly more) > DTLS association per conference, and then send the client-to-KMF > packets inside that association as application data, and use the > scheme described in draft-jones-perc-dtls-tunnel-02 to multiplex the > client DTLS associations within this tunnel. >=20 > 2. Multiple DTLS/UDP: Have the KMF establish one DTLS association with > the MDD for key management. The KMF will forward every DTLS packet > received from clients to the KMF, in raw form, using a unique source > port for each client. >=20 > 3. DTLS/SCTP/DTLS/UDP: Have the KMF establish one (or possibly more) > DTLS association per conference, and run SCTP inside this DTLS > association. Using one flow per client, tunnel client DTLS packets > inside the SCTP association. >=20 > 4. DataChannel/SCTP/DTLS/UDP: Something like #3 but using WebRTC data > channels. I think Richard would need to expand on this, since the > deeper I go on trying to figure out the details, the less it holds > up to scrutiny. I assume I've misunderstood something. >=20 >=20 > Compared against the status quo (#1): >=20 >=20 > #2 has the benefit of allowing the KMF to simply process inbound = client packets using a stock DTLS stack, rather than having to worry = about any kind of message encapsulation. It has the drawback of eating = up substantial NAT/Firewall resources (ports and port bindings). It also = has the lesser issues of requiring additional mechanism to associate the = client connections with their conference (for KMFs that can serve more = than one conference at a time), since the binding is not implicit (as it = is with other approaches), and of requiring us to bolt reliability on to = the MDD-to-KMF key management protocol. >=20 > #3 has the property (unless we work to avoid it) of decoupling the = MDD-to-KMF protocol (communicating ciphersuites and selected keys) from = the client-to-KMF messages, at the cost of requiring PERC endpoints and = KMFs to include an SCTP stack. This is no big deal for WebRTC setups = with co-located KMFs, but it may be unnecessarily complicated for = non-WebRTC clients and for enterprise-hosted KMFs. >=20 > I think the idea behind #4 was to allow WebRTC endpoints that are = serving as KMFs to use the DTLS association with the MDD as the KMF-MDD = communication channel, but I'm not 100% certain. If such is the case, = then we can reduce the number of DTLS associations between the = endpoint/KMF and the MDD from two to one, at the cost of some design = (and probably implementation) complexity. Like #3, it pushes SCTP onto = endpoints and KMFs that might not otherwise need it, with the additional = complication of also pushing the DataChannel protocol onto them. Again, = I'll leave it to Richard to explain the approach and benefits, as I = believe it was he who brought it up. >=20 > Regardless of whether we go with #4, there's a good chance that we = could shoehorn any of the other approaches into re-using the DTLS-SRTP = connection from a co-located endpoint/KMF for key management. I think = we'd need to sketch out exactly how that would work before we weigh the = impact of doing so against the value of having only one association. >=20 > What I most worry about with such an approach is that it basically = results in two disparate modes of operation from an MDD perspective: one = for a co-located KMF, and one for a non-co-located KMF. Once we have = non-trivial protocol differences between these two network = architectures, I fear we're going to rapidly get into situations where = some MDDs will support only one style of conference and not the other, = and will be difficult to adapt to support the other. We would = effectively have two different protocols for performing the same = function, which isn't generally good for interop. >=20 > /a >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Fri Apr 29 13:56:28 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4646D12D66B for ; Fri, 29 Apr 2016 13:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03aacdJAul9a for ; Fri, 29 Apr 2016 13:56:26 -0700 (PDT) Received: from smtp93.ord1c.emailsrvr.com (smtp93.ord1c.emailsrvr.com [108.166.43.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C4F12D68F for ; Fri, 29 Apr 2016 13:56:26 -0700 (PDT) Received: from smtp28.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp28.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 8B47618026C; Fri, 29 Apr 2016 16:56:25 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 32E2618029A; Fri, 29 Apr 2016 16:56:25 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Fri, 29 Apr 2016 16:56:25 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 29 Apr 2016 14:56:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57213B00.1090207@nostrum.com> To: Christian Groves X-Mailer: Apple Mail (2.3124) Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Open issue: TCP or UDP for the tunnel? X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 20:56:27 -0000 > On Apr 28, 2016, at 9:39 PM, Christian Groves = wrote: >=20 > +1 for using DTLS. >=20 > Christian +1 - I think as we dig into the MTU issue we will decide there is no = problem with it From nobody Fri Apr 29 14:03:55 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D1712D72E for ; Fri, 29 Apr 2016 14:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHgH1Z2ytj-1 for ; Fri, 29 Apr 2016 14:03:50 -0700 (PDT) Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1089E12D72B for ; Fri, 29 Apr 2016 14:03:49 -0700 (PDT) Received: from smtp5.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 71D6E18032C; Fri, 29 Apr 2016 17:03:49 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1A1E5180300; Fri, 29 Apr 2016 17:03:48 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Fri, 29 Apr 2016 17:03:49 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 29 Apr 2016 15:03:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E296891-465D-4A23-A78E-F10B7294D5C6@iii.ca> References: <572151E7.3020108@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Open Issue: Tunnel Multiplexing X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 21:03:54 -0000 > On Apr 29, 2016, at 2:53 PM, Cullen Jennings wrote: >=20 > #3 and #4 just seem to add complexity that is not needed. I prefer 1 = as it seems like 2 can run into running out of ports issues on the KMF.=20= Oops - meant to say running out of ports on MDD not KMF.=20 In #2, if you have a lot of endpoints behind a single CGN and each of = these endpoints in running a KMF for a different conference, the MDD = will need to make sure that each DTLS connection from the MDD to the KMF = originates from different port because the rest of the 5 tuple can be = the same. And if the the MDD is supporting a lot of users across all the = combined conferences, that might get large.=20 You also have the issue of it is is easiest to set up the connection = from KMF to MDD but the natural flow in 2 would be KMF to MDD which = would take some extra work to get going.=20=