From nobody Thu May 12 12:03:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F312D53B for ; Thu, 12 May 2016 12:03:46 -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 JDJc0q4YrwPX for ; Thu, 12 May 2016 12:03:45 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 0280912D11D for ; Thu, 12 May 2016 12:03:45 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x19so135183868oix.2 for ; Thu, 12 May 2016 12:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=c0mUtSOWMbG1RaqbNc2c825yLS+zETNgnTmoyGDwDMA=; b=sIgdvaXRLpuQi7cIlA+YqW7FuD6KC4JbATiW5uym8vxBW/Wr8jJvUD56uQfgvo04pL C/xdPBwygRpbY81C4r1BZDWum81Q8DFBm7+KC2fP9mOaSEbgDyyrJzY3PqHK3jqy98Nl 466QeZCj8LpwUBkHnaegXXDdzLmwG0x+0ta722G6/D+hWKYqTErmOfvmHqU1SWwXQosT M+K0DjHDvRoNftAdaodly0wyk37szCxwoEXh3g+iTFUlkeGW/C3ZLAuy/3pG9bxrLAiF 1zc3WRoRbaE5iHVA0ixwZe1AG4VOrGmW2xEq+Zez+Xfbdq14IirGMjbS57i2yZ2X4dvE boKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=c0mUtSOWMbG1RaqbNc2c825yLS+zETNgnTmoyGDwDMA=; b=BKwGEyhaBK/AXbBmQa38mcMOOtlqZxqVCvqAOnZ4oTN359Ux8O8SQ3jc2UlGTN4WxF 6ClnpXO9kiKUF6SRvNxDNjTVhnibL3xOBNZu7KZtPaRw37Gb2vlntjLcGSL3jDaIycpM 0AplAhhgLURsKwNtvRU3JtdV9j4WKfJygHVVgO2osGYKjJKtchZ7xF11IULm7dUTK/Es yiJePQNXMWZ31ssluhtLZlxxBiTY3/KoAiS3imW7CGO6OcTq+OIf5bhj9acba4h3/IK9 WalLT6ushlCHqo3RMs8PGudoINwUIi7mmWibnI3ae8de4LUmYdUOI3ABYRe22XiJp+XV Z/vQ== X-Gm-Message-State: AOPr4FVqUqKXptsnC7jsYQO05UnnLok74RSIA3eEjbWKMeyk9dDklvsZueNtNQuFOkHSXmA6QGwUBb87Kw/e/A== X-Received: by 10.157.20.149 with SMTP id d21mr6153069ote.143.1463079824231; Thu, 12 May 2016 12:03:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.210 with HTTP; Thu, 12 May 2016 12:03:24 -0700 (PDT) From: Ted Hardie Date: Thu, 12 May 2016 12:03:24 -0700 Message-ID: To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary=001a113e22ac33bbe90532a9d1c6 Archived-At: Cc: Christian Huitema , Jana Iyengar Subject: [dispatch] Proposed BoF for QUIC in Berlin X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 19:03:47 -0000 --001a113e22ac33bbe90532a9d1c6 Content-Type: text/plain; charset=UTF-8 Howdy, I wanted to let folks know that we (the cc'ed folks) have proposed a BoF on QUIC for Berlin. The BoF proposal is here: https://tools.ietf.org/bof/trac/ . This effort, if approved, will split the current approach (which is currently described in pretty monolithic terms) into a set of components, one stream of which would be a mapping of specific applications' semantics onto the QUIC transport (starting with HTTP/2). So, the BoF is in transport, but the topic may be of broader interest in ART as a result. The IETF mailing list for discussion of this proposal has been set up at quic@ietf.org. The intent is to form a working group, so a charter will be posted there for review soon. If you're interested in the topic, please join the list. thanks, Ted --001a113e22ac33bbe90532a9d1c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

I wanted to let folks know t= hat we (the cc'ed folks) have proposed a BoF on QUIC for Berlin.=C2=A0 = The BoF proposal is here: https://tools.ietf.= org/bof/trac/ .

This effort, if approved, will split the current approach (which is=20 currently described in pretty monolithic terms)=C2=A0 into a set of=20 components, one stream of which would be a mapping of specific applications= ' semantics onto the=20 QUIC transport (starting with HTTP/2). So, the BoF is in transport, but the= topic may be of broader interest in ART as a result.

The IETF= mailing list for discussion of this proposal has been set up at quic@ietf.org.=C2= =A0 The intent is to form a working group, so a charter will = be posted there for review soon.

If you're interested= in the topic, please join the list.

thanks,

Ted
--001a113e22ac33bbe90532a9d1c6-- From nobody Fri May 13 12:33:17 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541912D19F for ; Fri, 13 May 2016 12:33:15 -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 fSIhK7YTBskE for ; Fri, 13 May 2016 12:33:11 -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 6F96912B036 for ; Fri, 13 May 2016 12:33:11 -0700 (PDT) Received: from Orochi.local (rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u4DJX5vo031457 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 May 2016 14:33:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58] claimed to be Orochi.local To: Christer Holmberg , "A. Jean Mahoney" , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37F866CB@ESESSMB209.ericsson.se> From: Adam Roach Message-ID: <91c371c2-1743-f762-47af-35b0e62291e3@nostrum.com> Date: Fri, 13 May 2016 14:33:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F866CB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 19:33:16 -0000 The -06 version addresses the only blocking concerns that I had. From an expert review perspective, I approve its publication. /a On 4/27/16 10:57, Christer Holmberg wrote: > Hi, > > Based on Adam's comments, I've submitted a new version (-06) of draft-holmberg-dispatch-rfc7315-updates. > > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 27 April 2016 18:07 > To: Adam Roach ; A. Jean Mahoney ; dispatch@ietf.org > Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored > > Hi, > >> Sure -- my suggestion was one for clarification. If 3GPP does, in fact, >> intend to allow the header field in mid-dialog messages, then my >> comment doesn't apply. >> >> But if they *do* intend to allow the field mid-dialog, I'm curious >> about why it's forbidden in the current list of methods: save for some >> obscure corner cases, all of the methods called out by name are sent >> mid-dialog, and none of the un-named methods are. > OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog. > > I can't give an answer here and now why the list looks like it does, but this is how it's specified in 3GPP :) > >> Either way, it's just a suggestion. The hard block here is in the ACK >> handling that I pointed out. > Based on your comments, the new text would now say: > > "The P-Associated-URI header field can appear in SIP REGISTER > 2xx responses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. > The P-Visited-Network-ID header field can appear in all SIP methods > except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The > P-Access-Network-Info header field can appear in all SIP methods > and non-100 responses, except in CANCEL methods, CANCEL responses > and ACK methods triggered by non-2xx responses. The P-Charging-Vector > header field can appear in all SIP methods and non-100 responses, > except in CANCEL methods, CANCEL responses and ACK methods triggered > by non-2xx responses. The P-Charging-Function-Addresses header field > can appear in all SIP methods and non-100 responses, except in ACK > and CANCEL methods and CANCEL responses." > > > Regards, > > Christer > > > > > > > >> /a >> >> On 4/27/16 08:01, Christer Holmberg wrote: >>> Hi, >>> >>> One more thing: >>> >>> I guess we could also change ³all responses² to ³all non-100 >>> responses², as 100 responses are also hop-to-hop (similar to ACKs >>> triggered by non-2xx responses). >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 25/04/16 14:30, "Christer Holmberg" >>> >>> wrote: >>> >>>> Hi Adam, >>>> >>>> Are you ok with my suggested way forward? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> On 21/04/16 22:43, "Christer Holmberg" >>>> >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> .... >>>>> >>>>>>> One additional review note that does not affect my expert review >>>>>>> (treat it as a last-call comment): >>>>>>> >>>>>>> >>>>>>> Add statement that the P-Visited-Network-ID header field >>>>>>> cannot >>>>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>>>> >>>>>>> It seems to me that it would be significantly more future proof >>>>>>> to phase this as "...cannot appear in mid-dialog requests," as >>>>>>> that appears to be the intention. The revised text then becomes >>>>>>> something >>>>>>> like: "The P-Visited-Network-ID header field can appear in all >>>>>>> SIP methods except ACK and CANCEL; however, it cannot be sent in >>>>>>>> any mid-dialog requests." >>>>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>>>> I had a closer look at this, and I don't think we can forbid usage >>>>> in all mid-dialog requests. >>>>> >>>>> For example, the header field is allowed in OPTIONS, that can be >>>>> sent in-dialog. >>>>> >>>>> Also, the header field is allowed in REFER, and RFC 7614 defines a >>>>> mechanism that allows in-dialog REFERs. >>>>> >>>>> re-INVITE is also tricky. The header field is generally allowed in >>>>> INVITE requests, but there is no text explicitly disallowing it in >>>>> re-INVITEs. >>>>> >>>>> Whether it makes sense to include the header field in the methods >>>>> above I don't know (3GPP does allow them), but as the purpose is >>>>> only to align >>>>> 7315 with 3455 I'd suggest we keep the text as it is. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>>>> Since this draft updates RFC 7315, which required expert review of >>>>> its header fields, Adam Roach will be conducting an expert review >>>>> of this draft according to the guidance given in RFC 5727. >>>>> >>>>> Thanks, >>>>> >>>>> Jean >>>>> >>>>> >>>>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> This document has been proposed to be progressed as AD sponsored: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-upd >>>>> ate >>>>> s/ >>>>> The document has been carefully reviewed and it is now ready to >>>>> move forward - Jean Mahoney is the shepherd. >>>>> >>>>> I don't anticipate anyone would have concerns about this decision, >>>>> given that's how RFC 7315 was progressed and this update has >>>>> actually been much more carefully reviewed. However, f anyone has >>>>> any final comments, please post no later than Friday, March 11th, >>>>> 2016. Note, that you will also still have IETF LC to provide any >>>>> comments. >>>>> >>>>> Regards, >>>>> Mary. >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun May 15 12:15:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09ED12D09E for ; Sun, 15 May 2016 12:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-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 tGyG39Q21DYt for ; Sun, 15 May 2016 12:15:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5585812B008 for ; Sun, 15 May 2016 12:15:39 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b0-5738cad902c3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 20.6F.27088.9DAC8375; Sun, 15 May 2016 21:15:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Sun, 15 May 2016 21:15:37 +0200 From: Christer Holmberg To: Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored] Thread-Index: AQHRrU5Ijw7HYDK7hkOWILVzT9X5r5+6YanA Date: Sun, 15 May 2016 19:15:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37FBE7AB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F866CB@ESESSMB209.ericsson.se> <91c371c2-1743-f762-47af-35b0e62291e3@nostrum.com> In-Reply-To: <91c371c2-1743-f762-47af-35b0e62291e3@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7uu7NUxbhBr+X6lvs+buI3WLppAWs Fg2dK1kdmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxjq40KznlX3Jyr2sB4xbOLkZND QsBEYsm1P8wQtpjEhXvr2boYuTiEBI4wSvzed4cFwlnCKHHl43ymLkYODjYBC4nuf9ogDSIC pRJvTz1mBakRFpjOKDHl9DNmEEdEYAZQ994d7BBVRhLP1s4Cs1kEVCVa75xhBLF5BXwltnbf YILY0MQocezOQTaQDZwC9hLHG41BahiBTvp+ag0TiM0sIC5x68l8JohTBSSW7DkPdbaoxMvH /1ghbCWJtYe3s4CMYRbQlFi/Sx+iVVFiSvdDdoi1ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGA kWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmC0HNzy22AH48vnjocYBTgYlXh4FW6Yhwux JpYVV+YeYpTgYFYS4WU6ZBEuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6Yklqdmpq QWoRTJaJg1OqgdHkyFu7L9dmae8tEeu4KrH4cdhChnSRaW8qDn/6cbb58cJDXNvfrfOSDr68 v5vrOxu7/633KebyC7k0T7VpRP9sOHksMqd0lf9hvvO70rv/xN9R1Vngovqwedcno7ubHVex /Or8XXRMPUPm6P5ptp/UVvIoOjFIRwrdvsNwNHbxKs8uXhbnizJKLMUZiYZazEXFiQCwA+ws kgIAAA== Archived-At: Subject: Re: [dispatch] Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 19:15:42 -0000 VGhhbmtzISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dIA0KU2Vu dDogMTMgTWF5IDIwMTYgMjI6MzMNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPjsgQS4gSmVhbiBNYWhvbmV5IDxtYWhvbmV5QG5vc3RydW0uY29t PjsgZGlzcGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBEcmFmdCBuZXcgdmVyc2lvbjogZHJh ZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVzLTA2IFt3YXM6IFByb2dyZXNzaW5n IGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcyBhcyBBRCBzcG9uc29yZWRd DQoNClRoZSAtMDYgdmVyc2lvbiBhZGRyZXNzZXMgdGhlIG9ubHkgYmxvY2tpbmcgY29uY2VybnMg dGhhdCBJIGhhZC4gRnJvbSBhbiBleHBlcnQgcmV2aWV3IHBlcnNwZWN0aXZlLCBJIGFwcHJvdmUg aXRzIHB1YmxpY2F0aW9uLg0KDQovYQ0KDQpPbiA0LzI3LzE2IDEwOjU3LCBDaHJpc3RlciBIb2xt YmVyZyB3cm90ZToNCj4gSGksDQo+DQo+IEJhc2VkIG9uIEFkYW0ncyBjb21tZW50cywgSSd2ZSBz dWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTA2KSBvZiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1y ZmM3MzE1LXVwZGF0ZXMuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBDaHJpc3RlciBIb2xtYmVyZw0KPiBT ZW50OiAyNyBBcHJpbCAyMDE2IDE4OjA3DQo+IFRvOiBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0u Y29tPjsgQS4gSmVhbiBNYWhvbmV5IA0KPiA8bWFob25leUBub3N0cnVtLmNvbT47IGRpc3BhdGNo QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFByb2dyZXNzaW5nIA0KPiBkcmFm dC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMgYXMgQUQgc3BvbnNvcmVkDQo+DQo+ IEhpLA0KPg0KPj4gU3VyZSAtLSBteSBzdWdnZXN0aW9uIHdhcyBvbmUgZm9yIGNsYXJpZmljYXRp b24uIElmIDNHUFAgZG9lcywgaW4gDQo+PiBmYWN0LCBpbnRlbmQgdG8gYWxsb3cgdGhlIGhlYWRl ciBmaWVsZCBpbiBtaWQtZGlhbG9nICBtZXNzYWdlcywgdGhlbiANCj4+IG15IGNvbW1lbnQgZG9l c24ndCBhcHBseS4NCj4+DQo+PiBCdXQgaWYgdGhleSAqZG8qIGludGVuZCB0byBhbGxvdyB0aGUg ZmllbGQgbWlkLWRpYWxvZywgSSdtIGN1cmlvdXMgDQo+PiBhYm91dCB3aHkgaXQncyBmb3JiaWRk ZW4gaW4gdGhlIGN1cnJlbnQgbGlzdCBvZiBtZXRob2RzOiBzYXZlIGZvciANCj4+IHNvbWUgb2Jz Y3VyZSBjb3JuZXIgY2FzZXMsIGFsbCBvZiB0aGUgbWV0aG9kcyBjYWxsZWQgb3V0IGJ5IG5hbWUg YXJlIA0KPj4gc2VudCBtaWQtZGlhbG9nLCBhbmQgbm9uZSBvZiB0aGUgdW4tbmFtZWQgbWV0aG9k cyBhcmUuDQo+IE9QVElPTlMsIEJZRSwgUkVGRVIgKHdpdGggUkZDNzYxNSkgYW5kIHJlLUlOVklU RSBjYW4gYmUgc2VudCBpbi1kaWFsb2cuDQo+DQo+IEkgY2FuJ3QgZ2l2ZSBhbiBhbnN3ZXIgaGVy ZSBhbmQgbm93IHdoeSB0aGUgbGlzdCBsb29rcyBsaWtlIGl0IGRvZXMsIA0KPiBidXQgdGhpcyBp cyBob3cgaXQncyBzcGVjaWZpZWQgaW4gM0dQUCA6KQ0KPg0KPj4gRWl0aGVyIHdheSwgaXQncyBq dXN0IGEgc3VnZ2VzdGlvbi4gVGhlIGhhcmQgYmxvY2sgaGVyZSBpcyBpbiB0aGUgQUNLIA0KPj4g aGFuZGxpbmcgdGhhdCBJIHBvaW50ZWQgb3V0Lg0KPiBCYXNlZCBvbiB5b3VyIGNvbW1lbnRzLCB0 aGUgbmV3IHRleHQgd291bGQgbm93IHNheToNCj4NCj4gICAgICJUaGUgUC1Bc3NvY2lhdGVkLVVS SSBoZWFkZXIgZmllbGQgY2FuIGFwcGVhciBpbiBTSVAgUkVHSVNURVINCj4gICAgIDJ4eCByZXNw b25zZXMuIFRoZSBQLUNhbGxlZC1QYXJ0eS1JRCBoZWFkZXIgZmllbGQgY2FuIGFwcGVhciBpbg0K PiAgICAgU0lQIElOVklURSwgT1BUSU9OUywgUFVCTElTSCwgUkVGRVIsIFNVQlNDUklCRSwgYW5k IE1FU1NBR0UgbWV0aG9kcy4NCj4gICAgIFRoZSBQLVZpc2l0ZWQtTmV0d29yay1JRCBoZWFkZXIg ZmllbGQgY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhvZHMNCj4gICAgIGV4Y2VwdCBBQ0ssIEJZ RSwgQ0FOQ0VMLCBOT1RJRlksIFBSQUNLLCBJTkZPIGFuZCBVUERBVEUuIFRoZQ0KPiAgICAgUC1B Y2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciBmaWVsZCBjYW4gYXBwZWFyIGluIGFsbCBTSVAgbWV0 aG9kcw0KPiAgICAgYW5kIG5vbi0xMDAgcmVzcG9uc2VzLCBleGNlcHQgaW4gQ0FOQ0VMIG1ldGhv ZHMsIENBTkNFTCByZXNwb25zZXMNCj4gICAgIGFuZCBBQ0sgbWV0aG9kcyB0cmlnZ2VyZWQgYnkg bm9uLTJ4eCByZXNwb25zZXMuIFRoZSBQLUNoYXJnaW5nLVZlY3Rvcg0KPiAgICAgaGVhZGVyIGZp ZWxkIGNhbiBhcHBlYXIgaW4gYWxsIFNJUCBtZXRob2RzIGFuZCBub24tMTAwIHJlc3BvbnNlcywN Cj4gICAgIGV4Y2VwdCBpbiBDQU5DRUwgbWV0aG9kcywgQ0FOQ0VMIHJlc3BvbnNlcyBhbmQgQUNL IG1ldGhvZHMgdHJpZ2dlcmVkDQo+ICAgICBieSBub24tMnh4IHJlc3BvbnNlcy4gVGhlIFAtQ2hh cmdpbmctRnVuY3Rpb24tQWRkcmVzc2VzIGhlYWRlciBmaWVsZA0KPiAgICAgY2FuIGFwcGVhciBp biBhbGwgU0lQIG1ldGhvZHMgYW5kIG5vbi0xMDAgcmVzcG9uc2VzLCBleGNlcHQgaW4gQUNLDQo+ ICAgICBhbmQgQ0FOQ0VMIG1ldGhvZHMgYW5kIENBTkNFTCByZXNwb25zZXMuIg0KPg0KPg0KPiBS ZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPj4gL2ENCj4+DQo+ PiBPbiA0LzI3LzE2IDA4OjAxLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+PiBIaSwNCj4+ Pg0KPj4+IE9uZSBtb3JlIHRoaW5nOg0KPj4+DQo+Pj4gSSBndWVzcyB3ZSBjb3VsZCBhbHNvIGNo YW5nZSDCs2FsbCByZXNwb25zZXPCsiB0byDCs2FsbCBub24tMTAwIA0KPj4+IHJlc3BvbnNlc8Ky LCAgYXMgMTAwIHJlc3BvbnNlcyBhcmUgYWxzbyBob3AtdG8taG9wIChzaW1pbGFyIHRvIEFDS3Mg DQo+Pj4gdHJpZ2dlcmVkIGJ5IG5vbi0yeHggIHJlc3BvbnNlcykuDQo+Pj4NCj4+PiBSZWdhcmRz LA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4+DQo+Pj4gT24gMjUvMDQvMTYgMTQ6MzAsICJD aHJpc3RlciBIb2xtYmVyZyINCj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0K Pj4+IHdyb3RlOg0KPj4+DQo+Pj4+IEhpIEFkYW0sDQo+Pj4+DQo+Pj4+IEFyZSB5b3Ugb2sgd2l0 aCBteSBzdWdnZXN0ZWQgd2F5IGZvcndhcmQ/DQo+Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+ Pj4+IENocmlzdGVyDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDIxLzA0LzE2IDIyOjQzLCAi Q2hyaXN0ZXIgSG9sbWJlcmciDQo+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ DQo+Pj4+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4gSGkgQWRhbSwNCj4+Pj4+DQo+Pj4+PiAuLi4uDQo+ Pj4+Pg0KPj4+Pj4+PiBPbmUgYWRkaXRpb25hbCByZXZpZXcgbm90ZSB0aGF0IGRvZXMgbm90IGFm ZmVjdCBteSBleHBlcnQgcmV2aWV3IA0KPj4+Pj4+PiAodHJlYXQgaXQgYXMgYSBsYXN0LWNhbGwg Y29tbWVudCk6DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICBBZGQgc3RhdGVtZW50 IHRoYXQgdGhlIFAtVmlzaXRlZC1OZXR3b3JrLUlEIGhlYWRlciBmaWVsZCANCj4+Pj4+Pj4gY2Fu bm90DQo+Pj4+Pj4+ICAgICAgICBhcHBlYXIgaW4gdGhlIFNJUCBOT1RJRlksIFBSQUNLLCBJTkZP IGFuZCBVUERBVEUgbWV0aG9kcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSXQgc2VlbXMgdG8gbWUgdGhh dCBpdCB3b3VsZCBiZSBzaWduaWZpY2FudGx5IG1vcmUgZnV0dXJlIHByb29mIA0KPj4+Pj4+PiB0 byAgcGhhc2UgdGhpcyBhcyAiLi4uY2Fubm90IGFwcGVhciBpbiBtaWQtZGlhbG9nIHJlcXVlc3Rz LCIgYXMgDQo+Pj4+Pj4+IHRoYXQgIGFwcGVhcnMgdG8gYmUgdGhlIGludGVudGlvbi4gVGhlIHJl dmlzZWQgdGV4dCB0aGVuIGJlY29tZXMgDQo+Pj4+Pj4+IHNvbWV0aGluZw0KPj4+Pj4+PiBsaWtl OiAiVGhlIFAtVmlzaXRlZC1OZXR3b3JrLUlEIGhlYWRlciAgZmllbGQgY2FuIGFwcGVhciBpbiBh bGwgDQo+Pj4+Pj4+IFNJUCBtZXRob2RzIGV4Y2VwdCBBQ0sgYW5kIENBTkNFTDsgaG93ZXZlciwg aXQgIGNhbm5vdCBiZSBzZW50IA0KPj4+Pj4+PiBpbg0KPj4+Pj4+Pj4gYW55IG1pZC1kaWFsb2cg cmVxdWVzdHMuIg0KPj4+Pj4+IFNlZW1zIHJlYXNvbmFibGUsIGJ1dCBJJ2xsIHZlcmlmeSB3aXRo IG15IDNHUFAgZGVsZWdhdGVzLg0KPj4+Pj4gSSBoYWQgYSBjbG9zZXIgbG9vayBhdCB0aGlzLCBh bmQgSSBkb24ndCB0aGluayB3ZSBjYW4gZm9yYmlkIHVzYWdlIA0KPj4+Pj4gaW4gYWxsICBtaWQt ZGlhbG9nIHJlcXVlc3RzLg0KPj4+Pj4NCj4+Pj4+IEZvciBleGFtcGxlLCB0aGUgaGVhZGVyIGZp ZWxkIGlzIGFsbG93ZWQgaW4gT1BUSU9OUywgdGhhdCBjYW4gYmUgDQo+Pj4+PiBzZW50IGluLWRp YWxvZy4NCj4+Pj4+DQo+Pj4+PiBBbHNvLCB0aGUgaGVhZGVyIGZpZWxkIGlzIGFsbG93ZWQgaW4g UkVGRVIsIGFuZCBSRkMgNzYxNCBkZWZpbmVzIGEgDQo+Pj4+PiBtZWNoYW5pc20gdGhhdCBhbGxv d3MgaW4tZGlhbG9nIFJFRkVScy4NCj4+Pj4+DQo+Pj4+PiByZS1JTlZJVEUgaXMgYWxzbyB0cmlj a3kuIFRoZSBoZWFkZXIgZmllbGQgaXMgZ2VuZXJhbGx5IGFsbG93ZWQgaW4gDQo+Pj4+PiBJTlZJ VEUgIHJlcXVlc3RzLCBidXQgdGhlcmUgaXMgbm8gdGV4dCBleHBsaWNpdGx5IGRpc2FsbG93aW5n IGl0IA0KPj4+Pj4gaW4gcmUtSU5WSVRFcy4NCj4+Pj4+DQo+Pj4+PiBXaGV0aGVyIGl0IG1ha2Vz IHNlbnNlIHRvIGluY2x1ZGUgdGhlIGhlYWRlciBmaWVsZCBpbiB0aGUgbWV0aG9kcyANCj4+Pj4+ IGFib3ZlIEkgIGRvbid0IGtub3cgKDNHUFAgZG9lcyBhbGxvdyB0aGVtKSwgYnV0IGFzIHRoZSBw dXJwb3NlIGlzIA0KPj4+Pj4gb25seSB0byBhbGlnbg0KPj4+Pj4gNzMxNSB3aXRoIDM0NTUgSSdk IHN1Z2dlc3Qgd2Uga2VlcCB0aGUgdGV4dCBhcyBpdCBpcy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g UmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIDMvNy8xNiAxNDowOCwgQS4gSmVhbiBN YWhvbmV5IHdyb3RlOg0KPj4+Pj4gU2luY2UgdGhpcyBkcmFmdCB1cGRhdGVzIFJGQyA3MzE1LCB3 aGljaCByZXF1aXJlZCBleHBlcnQgcmV2aWV3IG9mIA0KPj4+Pj4gaXRzIGhlYWRlciBmaWVsZHMs IEFkYW0gUm9hY2ggd2lsbCBiZSBjb25kdWN0aW5nIGFuIGV4cGVydCByZXZpZXcgDQo+Pj4+PiBv ZiB0aGlzIGRyYWZ0IGFjY29yZGluZyB0byB0aGUgZ3VpZGFuY2UgZ2l2ZW4gaW4gUkZDIDU3Mjcu DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4NCj4+Pj4+IEplYW4NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj4gT24gMy83LzE2IDk6MzMgQU0sIE1hcnkgQmFybmVzIHdyb3RlOg0KPj4+Pj4NCj4+Pj4+ IEhpIGZvbGtzLA0KPj4+Pj4NCj4+Pj4+IFRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gcHJvcG9zZWQg dG8gYmUgcHJvZ3Jlc3NlZCBhcyBBRCBzcG9uc29yZWQ6DQo+Pj4+Pg0KPj4+Pj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11 DQo+Pj4+PiBwZA0KPj4+Pj4gYXRlDQo+Pj4+PiBzLw0KPj4+Pj4gVGhlIGRvY3VtZW50IGhhcyBi ZWVuIGNhcmVmdWxseSByZXZpZXdlZCBhbmQgaXQgaXMgbm93IHJlYWR5IHRvIA0KPj4+Pj4gbW92 ZSAgZm9yd2FyZCAtIEplYW4gTWFob25leSBpcyB0aGUgc2hlcGhlcmQuDQo+Pj4+Pg0KPj4+Pj4g SSBkb24ndCBhbnRpY2lwYXRlIGFueW9uZSB3b3VsZCBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMg ZGVjaXNpb24sIA0KPj4+Pj4gZ2l2ZW4gIHRoYXQncyBob3cgUkZDIDczMTUgd2FzIHByb2dyZXNz ZWQgYW5kIHRoaXMgdXBkYXRlIGhhcyANCj4+Pj4+IGFjdHVhbGx5IGJlZW4gbXVjaCAgbW9yZSBj YXJlZnVsbHkgcmV2aWV3ZWQuICBIb3dldmVyLCBmIGFueW9uZSANCj4+Pj4+IGhhcyBhbnkgZmlu YWwgY29tbWVudHMsICBwbGVhc2UgcG9zdCBubyBsYXRlciB0aGFuIEZyaWRheSwgTWFyY2ggDQo+ Pj4+PiAxMXRoLCAyMDE2LiAgTm90ZSwgdGhhdCB5b3Ugd2lsbCAgYWxzbyBzdGlsbCBoYXZlIElF VEYgTEMgdG8gDQo+Pj4+PiBwcm92aWRlIGFueSBjb21tZW50cy4NCj4+Pj4+DQo+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4gTWFyeS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IGRpc3BhdGNoIG1haWxpbmcgbGlz dA0KPj4+Pj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0 DQo+Pj4+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QN Cj4+Pj4+IGRpc3BhdGNoQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoN Cg0K From nobody Tue May 17 14:28:53 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E18012D9DD; Tue, 17 May 2016 14:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 tczLdNM3G_eF; Tue, 17 May 2016 14:28:49 -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 9ECAC12D1E0; Tue, 17 May 2016 14:28:49 -0700 (PDT) Received: from [172.20.10.3] (mobile-166-170-033-119.mycingular.net [166.170.33.119] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4HLSiGP034897 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 May 2016 16:28:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-170-033-119.mycingular.net [166.170.33.119] (may be forged) claimed to be [172.20.10.3] From: "Ben Campbell" To: DISPATCH Date: Tue, 17 May 2016 17:28:38 -0400 Message-ID: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: dispatch-chairs@ietf.org, ART ADs , Russ Housley , Gonzalo Camarillo , Richard Barnes Subject: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:28:51 -0000 Hi, DISPATCH participants will recall the discussion about improvements to security for SIP-signaled SRTP at the meeting in Buenos Aires. Here is a proposed draft charter[1] for a SIPBRANDY working group to progress that work. Gonzalo Camarillo has agreed to chair the group, if formed. Please send comments (positive or negative) about the proposed charter to the dispatch working list as soon as possible. [1] https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ Thanks! Ben. From nobody Tue May 17 23:40:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4760112D114 for ; Tue, 17 May 2016 23:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.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 1944OJldxF0O for ; Tue, 17 May 2016 23:40:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0057.outbound.protection.outlook.com [207.46.100.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C72712D0E5 for ; Tue, 17 May 2016 23:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X9xm1TfQBI/aG/fu89QWJboCYojDb1ilRQlTuPp0ueE=; b=BmCOkouXwi7qbJr77WfBl3T3acQ71P5VqMhj3Zi24rIcrmBy8Qe3x4Lokv2yFAu31aSmNwzsO/b5FBuEBSgxxaU5qeMJSSqFCjTdYJJaWWzOEX2H+ExFsJL35Glo8JYFTuCY7AAXNSwn3h4XsLUvMluz6/oxcS4Qq8IRGv7xR/M= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 06:40:22 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0497.019; Wed, 18 May 2016 06:40:22 +0000 From: "Asveren, Tolga" To: DISPATCH Thread-Topic: [dispatch] Proposed SIPBRANDY Charter Thread-Index: AQHRsIMnMmXJATXz6k6I9RndQqa4sZ++PUPg Date: Wed, 18 May 2016 06:40:22 +0000 Message-ID: References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> In-Reply-To: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: f853116a-c74d-4b8d-5c72-08d37ee749ca x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:+fmMMYiE4NiKpKirbjcshk8sc9RkeKdkh26LNc1bvSj+cGmzMprZL8UPbX6L1q44poIPjlIXO6EqgsTLL7DaoQ3lmKwiCroEWyKfewwJor3IDizxgmcQJIM8tzBY7lbV7J0t5AStAkp1HBKynx4XRQ==; 24:vPUYg/k4J3knrEoxxKBpQrWdA1tyr+1oGEWOM7WkfVrPiPwivyUCmWal77A640NabsAeUgUo2GgWxjOzpIAn80sKiWiJsDXcpnyUvBnZP6c=; 7:CwTB1ZXdh1aPYy2LFuRPFCNFX2c22APsgnlJGfjwq9DbYmcvJ0FtOOBHtT8Y92gNDExCV1ijmVlWt/qzOaRIH43Lk1wZ1eK+8Vn/IEw2ZF2A5okf9JEBEfzszq3avtU8JwiZOnJyJY4xy9aOthvwWJzejDnCOGgL13iveFAIR5WTclghgN2yP0O2903w3Fsx x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377454003)(6116002)(110136002)(3280700002)(102836003)(107886002)(106116001)(76576001)(5002640100001)(99286002)(19580395003)(92566002)(19580405001)(5003600100002)(11100500001)(81166006)(3660700001)(10400500002)(5008740100001)(2906002)(450100001)(15975445007)(77096005)(586003)(87936001)(33656002)(74316001)(2950100001)(5004730100002)(1220700001)(54356999)(122556002)(50986999)(9686002)(76176999)(86362001)(66066001)(189998001)(8676002)(8936002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 06:40:22.8040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 Archived-At: Subject: Re: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 06:40:26 -0000 i- "The SIPBRANDY working group will define best practices for establishing two-party, SIP-signaled SRTP sessions with end-to-end security associations, including a single, preferred SRTP key exchange mechanism." I think this is an area, where in the past there were repeated half-hearted= /failed (at least in practice) attempts and statuesque prevailed. *If* the = reality on the ground is to be considered as well -rather than just a theor= etically perfect "solution"-, I think it is worth to give it another try. ii- "The working group will additionally coordinate with the MMUSIC working group to define opportunistic security [RFC 7435] for SIP-signaled media=20 sessions for situations where strong protections are not necessary or not" feasible." IMHO, this is important, shouldn't be too difficult to converge on a soluti= on and would have great practical value. I would be willing to contribute -in one way or another- for both. Thanks, Tolga > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben > Campbell > Sent: Tuesday, May 17, 2016 5:29 PM > To: DISPATCH > Cc: dispatch-chairs@ietf.org; ART ADs ; Russ Housley > ; Gonzalo Camarillo > ; Richard Barnes > Subject: [dispatch] Proposed SIPBRANDY Charter >=20 > Hi, >=20 > DISPATCH participants will recall the discussion about improvements to > security for SIP-signaled SRTP at the meeting in Buenos Aires. Here is a > proposed draft charter[1] for a SIPBRANDY working group to progress that > work. Gonzalo Camarillo has agreed to chair the group, if formed. >=20 > Please send comments (positive or negative) about the proposed charter to > the dispatch working list as soon as possible. >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed May 18 14:56:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8893312D5EA; Wed, 18 May 2016 14:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, TVD_SPACE_RATIO=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 Vxj7T_SHJ3NG; Wed, 18 May 2016 14:56:32 -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 4599D12D51A; Wed, 18 May 2016 14:56:29 -0700 (PDT) Received: from mutabilis-2.local ([108.19.241.180]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4ILuRkQ094674 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 May 2016 16:56:28 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [108.19.241.180] claimed to be mutabilis-2.local To: draft-holmberg-dispatch-rfc7315-updates.all@ietf.org, DISPATCH list From: "A. Jean Mahoney" Message-ID: <0e43d6db-2b68-109e-bb4b-c44c0b850ac1@nostrum.com> Date: Wed, 18 May 2016 16:56:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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 Archived-At: Subject: [dispatch] Doc Shepherd write-up for draft-holmberg-dispatch-rfc7315-updates X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 21:56:33 -0000 Now available. Thanks! https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/shepherdwriteup/ From nobody Thu May 19 14:23:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B85A12D633 for ; Thu, 19 May 2016 14:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 lob5wtIlzcRj for ; Thu, 19 May 2016 14:23:50 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 416F712D689 for ; Thu, 19 May 2016 14:23:50 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by comcast with SMTP id 3VPzbpz4JBE6O3VQ5buiHz; Thu, 19 May 2016 21:23:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463693029; bh=RICSWF838Y4Dw8k4fZvhsLiEnK+1q3jF0kEqYL7j8wY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=QZkwyB1L/YMHDvUwzcoljc3AVzo6ITS42c0ExYDftTviVcNBDzPE04YDYQCcPOGIK U3MunQLOwoM5X+P7ER7iIZgLhhfmVULNsGnJhfkhudKLi189XDF1XURj4JeqMlkH+8 RZR3Q5ecl1LmkU+b1A1xy/btt7mY4PhBSO/ikMcFbWL9PcefQ76KxJobwBVTaAp7K9 OulTw4JbL65jCzeKZcQZOMz/ZDxxtNZbL2jDs8cwU+/EToCrygpfgv8wCeTJ9N1lJ1 FJrtNJzxtpG8Q/VyNgCST1qM0vOTSgWRw54rieJ+bQoltY50W+Kn3+i/BLGUM5ge6G SmkTnXIb9nIIg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id wMPp1s0023KdFy101MPpsB; Thu, 19 May 2016 21:23:49 +0000 To: dispatch@ietf.org References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> From: Paul Kyzivat Message-ID: <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> Date: Thu, 19 May 2016 17:23:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:23:51 -0000 On 5/17/16 5:28 PM, Ben Campbell wrote: > Hi, > > DISPATCH participants will recall the discussion about improvements to > security for SIP-signaled SRTP at the meeting in Buenos Aires. Here is a > proposed draft charter[1] for a SIPBRANDY working group to progress that > work. Gonzalo Camarillo has agreed to chair the group, if formed. I didn't hear the BA discussions, so I'm shooting blind here. Is there any intention for this to yield something that can be interworked with webrtc (one webrtc endpoint, one sip endpoint) while still getting e2e SRTP? If so, that ought to be stated because it will constrain the solution space. Thanks, Paul > Please send comments (positive or negative) about the proposed charter > to the dispatch working list as soon as possible. > > [1] https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ > > Thanks! > > Ben. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu May 19 15:34:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACF612D5D2 for ; Thu, 19 May 2016 15:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 12em-hxJQsiT for ; Thu, 19 May 2016 15:34:54 -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 5D3A212D0DA for ; Thu, 19 May 2016 15:34:54 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4JMYpLp089218 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 19 May 2016 17:34:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Paul Kyzivat" Date: Thu, 19 May 2016 17:34:51 -0500 Message-ID: <58579292-ED03-4E90-BE30-C42A84E75965@nostrum.com> In-Reply-To: <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 22:34:55 -0000 On 19 May 2016, at 16:23, Paul Kyzivat wrote: > On 5/17/16 5:28 PM, Ben Campbell wrote: >> Hi, >> >> DISPATCH participants will recall the discussion about improvements >> to >> security for SIP-signaled SRTP at the meeting in Buenos Aires. Here >> is a >> proposed draft charter[1] for a SIPBRANDY working group to progress >> that >> work. Gonzalo Camarillo has agreed to chair the group, if formed. > > I didn't hear the BA discussions, so I'm shooting blind here. > > Is there any intention for this to yield something that can be > interworked with webrtc (one webrtc endpoint, one sip endpoint) while > still getting e2e SRTP? > > If so, that ought to be stated because it will constrain the solution > space. I don't recall it being discussed, at least not explicitly. Or maybe I just forgot. What do people think? > > Thanks, > Paul > >> Please send comments (positive or negative) about the proposed >> charter >> to the dispatch working list as soon as possible. >> >> [1] https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ >> >> Thanks! >> >> Ben. >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri May 20 03:57:36 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18412D825 for ; Fri, 20 May 2016 03:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 KEtL4JBcdPBl for ; Fri, 20 May 2016 03:57:33 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3A312D823 for ; Fri, 20 May 2016 03:57:33 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id CB6661EB84D8; Fri, 20 May 2016 12:57:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Fri, 20 May 2016 12:57:31 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Proposed SIPBRANDY Charter Thread-Index: AQHRshTAL8saaeHJkkiMPKtZ+aUWwZ/BpviQ Date: Fri, 20 May 2016 10:57:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF2610B22A@MCHP04MSX.global-ad.net> References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> In-Reply-To: <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 10:57:35 -0000 On: 19 May 2016 22:24 Paul Kyzivat wrote: > I didn't hear the BA discussions, so I'm shooting blind here. >=20 > Is there any intention for this to yield something that can be > interworked with webrtc (one webrtc endpoint, one sip endpoint) while > still getting e2e SRTP? >=20 > If so, that ought to be stated because it will constrain the solution > space. >=20 I also don't think this was discussed in the meeting but I would support ha= ving it stated as a goal. Andy From nobody Fri May 20 04:14:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A71112D845; Fri, 20 May 2016 04:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 XGeC1kX7o7rH; Fri, 20 May 2016 04:14:15 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F89912D84C; Fri, 20 May 2016 04:14:15 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id ABFE823F050F; Fri, 20 May 2016 13:14:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Fri, 20 May 2016 13:14:13 +0200 From: "Hutton, Andrew" To: Ben Campbell , DISPATCH Thread-Topic: Proposed SIPBRANDY Charter & PERC Interaction Thread-Index: AQHRsIMfEdiWe2I7hkKFKRkTIjmGnp/Bq9lA Date: Fri, 20 May 2016 11:14:12 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF2610B2CF@MCHP04MSX.global-ad.net> References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> In-Reply-To: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ART ADs , Richard Barnes , Russ Housley , Gonzalo Camarillo , "dispatch-chairs@ietf.org" Subject: [dispatch] Proposed SIPBRANDY Charter & PERC Interaction X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 11:14:17 -0000 The draft charter states: "The SIPBRANDY working group will define best practices for establishing tw= o-party, SIP-signaled SRTP sessions with end-to-end security associations, = including a single, preferred SRTP key exchange mechanism". I understand that the PERC working group is working on the multi-party case= but it is I think strange to start this work with the assumption that it o= nly relates to two-party calls. From a SIP endpoint perspective it cannot k= now when it initiates a session whether it is going to be a two-party or mu= lti-party session or that a two-party session will not transition to multi-= party. Therefore the work of this group needs to be coordinated in some way with t= he work of the PERC group to make sure that the outputs from these working = groups results in solutions which are not incompatible and I think this nee= ds to be in the charter. At a minimum PERC should be added to the groups that SIPBRANDY closely coll= aborates with but I would also like to see something added to the SIPBRANDY= objectives to state that the solution needs to compatible with PERC meanin= g that SIP endpoints can support both and don't need prior knowledge of whi= ch will be used in a session.=20 By the way it might also be necessary to update the PERC charter to say som= ething similar about SIPBRANDY. Regards Andy > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben > Campbell > Sent: 17 May 2016 22:29 > To: DISPATCH > Cc: dispatch-chairs@ietf.org; ART ADs; Russ Housley; Gonzalo Camarillo; > Richard Barnes > Subject: [dispatch] Proposed SIPBRANDY Charter >=20 > Hi, >=20 > DISPATCH participants will recall the discussion about improvements to > security for SIP-signaled SRTP at the meeting in Buenos Aires. Here is > a > proposed draft charter[1] for a SIPBRANDY working group to progress > that > work. Gonzalo Camarillo has agreed to chair the group, if formed. >=20 > Please send comments (positive or negative) about the proposed charter > to the dispatch working list as soon as possible. >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri May 20 14:13:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B2912D63C for ; Fri, 20 May 2016 14:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 4asnMrMMD9MH for ; Fri, 20 May 2016 14:13:16 -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 1341D12D4FB for ; Fri, 20 May 2016 14:13:16 -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.15.2) with ESMTPSA id u4KLDBxx099934 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 May 2016 16:13:12 -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: Ben Campbell , Paul Kyzivat References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> <58579292-ED03-4E90-BE30-C42A84E75965@nostrum.com> From: Adam Roach Message-ID: Date: Fri, 20 May 2016 16:13:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <58579292-ED03-4E90-BE30-C42A84E75965@nostrum.com> Content-Type: multipart/alternative; boundary="------------34CB1ABD380768E9D5528663" Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 21:13:18 -0000 This is a multi-part message in MIME format. --------------34CB1ABD380768E9D5528663 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/19/16 17:34, Ben Campbell wrote: > On 19 May 2016, at 16:23, Paul Kyzivat wrote: > >> On 5/17/16 5:28 PM, Ben Campbell wrote: >>> Hi, >>> >>> DISPATCH participants will recall the discussion about improvements to >>> security for SIP-signaled SRTP at the meeting in Buenos Aires. Here >>> is a >>> proposed draft charter[1] for a SIPBRANDY working group to progress >>> that >>> work. Gonzalo Camarillo has agreed to chair the group, if formed. >> >> I didn't hear the BA discussions, so I'm shooting blind here. >> >> Is there any intention for this to yield something that can be >> interworked with webrtc (one webrtc endpoint, one sip endpoint) while >> still getting e2e SRTP? >> >> If so, that ought to be stated because it will constrain the solution >> space. > > I don't recall it being discussed, at least not explicitly. Or maybe I > just forgot. What do people think? I would definitely support it. I also think it's pretty likely we'll end up there without really trying. In many ways, WebRTC took lessons learned from earlier VoIP efforts, and tried to identify "actual best practices": the use of ICE for consent-to-receive; the use of DTLS-SRTP for more secure key management; etc. But I believe that making it an explicit goal would be good. /a --------------34CB1ABD380768E9D5528663 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 5/19/16 17:34, Ben Campbell wrote:
On 19 May 2016, at 16:23, Paul Kyzivat wrote:

On 5/17/16 5:28 PM, Ben Campbell wrote:
Hi,

DISPATCH participants will recall the discussion about improvements to
security for SIP-signaled SRTP at the meeting in Buenos Aires. Here is a
proposed draft charter[1] for a SIPBRANDY working group to progress that
work. Gonzalo Camarillo has agreed to chair the group, if formed.

I didn't hear the BA discussions, so I'm shooting blind here.

Is there any intention for this to yield something that can be interworked with webrtc (one webrtc endpoint, one sip endpoint) while still getting e2e SRTP?

If so, that ought to be stated because it will constrain the solution space.

I don't recall it being discussed, at least not explicitly. Or maybe I just forgot. What do people think?


I would definitely support it. I also think it's pretty likely we'll end up there without really trying. In many ways, WebRTC took lessons learned from earlier VoIP efforts, and tried to identify "actual best practices": the use of ICE for consent-to-receive; the use of DTLS-SRTP for more secure key management; etc.

But I believe that making it an explicit goal would be good.

/a

--------------34CB1ABD380768E9D5528663-- From nobody Wed May 25 15:15:17 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B8F12DDD5 for ; Wed, 25 May 2016 15:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 kqsoT1HBpbne for ; Wed, 25 May 2016 15:15:14 -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 B47BB12D505 for ; Wed, 25 May 2016 15:15:14 -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.15.2) with ESMTPSA id u4PMFCpU045963 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 25 May 2016 17:15:14 -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: "dispatch@ietf.org" From: Adam Roach Message-ID: Date: Wed, 25 May 2016 17:15:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 22:15:16 -0000 As early as 2005, we identified a class of DoS attack that would be enabled by SIP systems, if widely deployed on the public internet. Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures. While I don't think this is something that SIPBRANDY is required to address, I would like it to be part of the discussion. I believe this makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature -- which would seem to require the same set of expertise as the other problems SIPBRANDY will work on. To that end, I propose adding the following sentence to the "Objectives" paragraph in the SIPBRANDY charter: "The working group may also define best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1." To be clear: I do not wish to presuppose that the solution to this problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration. /a From nobody Thu May 26 14:57:38 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6550312D1A1 for ; Thu, 26 May 2016 14:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 YjONDXbXJd5P for ; Thu, 26 May 2016 14:57:35 -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 1247012D13D for ; Thu, 26 May 2016 14:57:35 -0700 (PDT) Received: from [10.0.1.24] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4QLvXJC063658 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 26 May 2016 16:57:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.24] From: "Ben Campbell" To: "Adam Roach" Date: Thu, 26 May 2016 16:57:32 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 21:57:36 -0000 On 25 May 2016, at 17:15, Adam Roach wrote: > As early as 2005, we identified a class of DoS attack that would be > enabled by SIP systems, if widely deployed on the public internet. > Called the "Voice Hammer," this attack involves triggering potentially > vast quantities of media traffic towards a target using normal SIP > call setup procedures. > > While I don't think this is something that SIPBRANDY is required to > address, I would like it to be part of the discussion. I believe this > makes sense for two reasons: (1) I expect the recommendations that > come out of SIPBRANDY to require non-trivial endpoint changes, and it > would be good to consider coupling breaking changes to each other so > as to minimize the number of potential modes of operation; and (2) the > issue is fundamentally a security issue -- albeit of a different > nature -- which would seem to require the same set of expertise as the > other problems SIPBRANDY will work on. > > To that end, I propose adding the following sentence to the > "Objectives" paragraph in the SIPBRANDY charter: > > "The working group may also define best practices for ensuring > recipients of media flows have consented to receive such flows, in > order to prevent or mitigate the denial-of-service attack described in > RFC 5245, section 18.5.1." > > To be clear: I do not wish to presuppose that the solution to this > problem will be ICE, or that it even is required in order for the WG > to declare success. I just want it to be available for consideration. I agree it would be nice to address that. My concern is whether this is the right place to do it. We've so far not succeeded in standardizing e2e SRTP for SIP. I hope we can do better this time around, but there's no guarantee there. So anything that distracts from that mission concerns me. A compromise might be to put Adam's language in along with some disclaimer to the effect that e2e crypto will have priority. Does anyone else have thoughts about this? Thanks! Ben. From nobody Thu May 26 15:24:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165A212B025 for ; Thu, 26 May 2016 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 17kR-7zPVEN7 for ; Thu, 26 May 2016 15:24:39 -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 C109D12D133 for ; Thu, 26 May 2016 15:24:39 -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.15.2) with ESMTPSA id u4QMOc8F065973 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 26 May 2016 17:24:39 -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: Ben Campbell References: From: Adam Roach Message-ID: <3bd962fb-fe92-090c-9190-3a4f04a8cb36@nostrum.com> Date: Thu, 26 May 2016 17:24:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:24:41 -0000 On 5/26/16 16:57, Ben Campbell wrote: > On 25 May 2016, at 17:15, Adam Roach wrote: > >> As early as 2005, we identified a class of DoS attack that would be >> enabled by SIP systems, if widely deployed on the public internet. >> Called the "Voice Hammer," this attack involves triggering >> potentially vast quantities of media traffic towards a target using >> normal SIP call setup procedures. >> >> While I don't think this is something that SIPBRANDY is required to >> address, I would like it to be part of the discussion. I believe this >> makes sense for two reasons: (1) I expect the recommendations that >> come out of SIPBRANDY to require non-trivial endpoint changes, and it >> would be good to consider coupling breaking changes to each other so >> as to minimize the number of potential modes of operation; and (2) >> the issue is fundamentally a security issue -- albeit of a different >> nature -- which would seem to require the same set of expertise as >> the other problems SIPBRANDY will work on. >> >> To that end, I propose adding the following sentence to the >> "Objectives" paragraph in the SIPBRANDY charter: >> >> "The working group may also define best practices for ensuring >> recipients of media flows have consented to receive such flows, in >> order to prevent or mitigate the denial-of-service attack described >> in RFC 5245, section 18.5.1." >> >> To be clear: I do not wish to presuppose that the solution to this >> problem will be ICE, or that it even is required in order for the WG >> to declare success. I just want it to be available for consideration. > > I agree it would be nice to address that. My concern is whether this > is the right place to do it. We've so far not succeeded in > standardizing e2e SRTP for SIP. I hope we can do better this time > around, but there's no guarantee there. So anything that distracts > from that mission concerns me. > > A compromise might be to put Adam's language in along with some > disclaimer to the effect that e2e crypto will have priority. To be clear, that's what I had in mind, and I would support adding language to make it even more explicit. /a From nobody Thu May 26 17:05:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8181712D85E for ; Thu, 26 May 2016 17:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 GsCqwCZpls2L for ; Thu, 26 May 2016 17:05:07 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 692E512D769 for ; Thu, 26 May 2016 17:05:07 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u4R02dJl007690; Thu, 26 May 2016 20:05:06 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 23442kfjpk-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 May 2016 20:05:06 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Thu, 26 May 2016 20:05:05 -0400 From: "Peterson, Jon" To: Adam Roach , "dispatch@ietf.org" Thread-Topic: [dispatch] SIPBRANDY and other dangers Thread-Index: AQHRttLyF0uzizBeHk2yQZGrEmJB3Z/LtuEA Date: Fri, 27 May 2016 00:05:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <1726B21E379B9845B79A7705AE6E68E4@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-26_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605260276 Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:05:10 -0000 It would be a fairly significant change to the proposed scope, but perhaps one that's warranted. I understand why you have some process caution here about scoping a consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set the explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibility with SIP, and it would be a shame if the effort to interwork the two proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting plausible interworking with WebRTC could also provide some further incentive for implementers to crack open their SIP implementations. If a "grand unified theory" is the goal, then this also conforms nicely with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those three things in a common way - especially as WebRTC IdP today conveys that identity information as an SDP attribute. Realigning Offers[/Answers]: The Grand Unified Theory? Jon Peterson Neustar, Inc. On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" wrote: >As early as 2005, we identified a class of DoS attack that would be >enabled by SIP systems, if widely deployed on the public internet. >Called the "Voice Hammer," this attack involves triggering potentially >vast quantities of media traffic towards a target using normal SIP call >setup procedures. > >While I don't think this is something that SIPBRANDY is required to >address, I would like it to be part of the discussion. I believe this >makes sense for two reasons: (1) I expect the recommendations that come >out of SIPBRANDY to require non-trivial endpoint changes, and it would >be good to consider coupling breaking changes to each other so as to >minimize the number of potential modes of operation; and (2) the issue >is fundamentally a security issue -- albeit of a different nature -- >which would seem to require the same set of expertise as the other >problems SIPBRANDY will work on. > >To that end, I propose adding the following sentence to the "Objectives" >paragraph in the SIPBRANDY charter: > >"The working group may also define best practices for ensuring >recipients of media flows have consented to receive such flows, in order >to prevent or mitigate the denial-of-service attack described in RFC >5245, section 18.5.1." > >To be clear: I do not wish to presuppose that the solution to this >problem will be ICE, or that it even is required in order for the WG to >declare success. I just want it to be available for consideration. > >/a > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu May 26 17:55:24 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0312D17D for ; Thu, 26 May 2016 17:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 dgCVeThUB8n3 for ; Thu, 26 May 2016 17:55:20 -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 D229612B050 for ; Thu, 26 May 2016 17:55:20 -0700 (PDT) Received: from [10.0.1.24] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4R0tJib078841 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 26 May 2016 19:55:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.24] From: "Ben Campbell" To: "Peterson, Jon" Date: Thu, 26 May 2016 19:55:19 -0500 Message-ID: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:55:23 -0000 Hi Jon, As an individual, I'm afraid the association of this effort with other great unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, the implied acronym :-) ) I'd be happy if we just solved e2e confidentiality. And I don't think we would be happy if we solved all the other things and _not_ e2e confidentiality. It also seems to me that aligning identity models fits more with STIR than with this group. That being said, what about something like the following: "While confidentiality is the first priority of the working group, it may work on aligning these practices with WebRTC, for example by defining best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1." Ben. On 26 May 2016, at 19:05, Peterson, Jon wrote: > It would be a fairly significant change to the proposed scope, but > perhaps > one that's warranted. > > I understand why you have some process caution here about scoping a > consent mechanism to ICE at the outset, but if we're going to put this > problem under SIPPRANDY's umbrella, I think it could make sense to set > the > explicit goal of getting a "grand unified theory" of VoIP security > that > would align the security of SIP and WebRTC. As we all know, WebRTC > went > down many of the paths that it did for the sake of backwards > compatibility > with SIP, and it would be a shame if the effort to interwork the two > proved futile because of lack of e2e SRTP. Consent would be another > prong > of that. So maybe writing ICE in as a foregone conclusion in the > service > of that goal would let us skip some unnecessary deliberation. Getting > plausible interworking with WebRTC could also provide some further > incentive for implementers to crack open their SIP implementations. > > If a "grand unified theory" is the goal, then this also conforms > nicely > with Cullen's recent efforts to figure out how to get STIR and > WebRTC's > IdP aligned. As my strawman proposal for SIP media confidentiality had > both a STIR story and an opportunistic story, we could argue that > getting > alignment of identity, consent, and encryption could be grouped under > one > effort, which is mostly about getting offer/answer to deal with those > three things in a common way - especially as WebRTC IdP today conveys > that > identity information as an SDP attribute. > > Realigning Offers[/Answers]: The Grand Unified Theory? > > Jon Peterson > Neustar, Inc. > > On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > wrote: > >> As early as 2005, we identified a class of DoS attack that would be >> enabled by SIP systems, if widely deployed on the public internet. >> Called the "Voice Hammer," this attack involves triggering >> potentially >> vast quantities of media traffic towards a target using normal SIP >> call >> setup procedures. >> >> While I don't think this is something that SIPBRANDY is required to >> address, I would like it to be part of the discussion. I believe this >> makes sense for two reasons: (1) I expect the recommendations that >> come >> out of SIPBRANDY to require non-trivial endpoint changes, and it >> would >> be good to consider coupling breaking changes to each other so as to >> minimize the number of potential modes of operation; and (2) the >> issue >> is fundamentally a security issue -- albeit of a different nature -- >> which would seem to require the same set of expertise as the other >> problems SIPBRANDY will work on. >> >> To that end, I propose adding the following sentence to the >> "Objectives" >> paragraph in the SIPBRANDY charter: >> >> "The working group may also define best practices for ensuring >> recipients of media flows have consented to receive such flows, in >> order >> to prevent or mitigate the denial-of-service attack described in RFC >> 5245, section 18.5.1." >> >> To be clear: I do not wish to presuppose that the solution to this >> problem will be ICE, or that it even is required in order for the WG >> to >> declare success. I just want it to be available for consideration. >> >> /a >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon May 30 15:43:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A3C12D69B for ; Mon, 30 May 2016 15:43:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 KVNlnIk37_uV for ; Mon, 30 May 2016 15:43:38 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA1B12D673 for ; Mon, 30 May 2016 15:43:37 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w184so275368969oiw.2 for ; Mon, 30 May 2016 15:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:date:message-id:subject:from:to; bh=0N0Ius3SeTg8U8m2DSNHRSuZhpwZJhv83okghbLpZuk=; b=V2akhvfgvJ0QDxiVmqysL1C3mt2tad24CCZhd4UQ9zrutVbdJdDU9mbO8abVwwT7sA IrUJ/WSSTw2bw9PU21NXGFdKd9Cy9mLDks7138vqAtwABZa173FzlPRI8zgVni0VX2nd ZhQwwqiulRCBTpGi3YnBgryJmA9E3hyp76asA= 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=0N0Ius3SeTg8U8m2DSNHRSuZhpwZJhv83okghbLpZuk=; b=TkGHaSKZUqLJUiL7Ya4eoSDLbK1AMzW1ANign8IeWWv6RZZvNzGM3//5vWx/XbYvoI rXOShOQjIw6xmpoNjHDSKDfT+h3UW/naXQFp49ykxh0CJLe4MQBleVfnEy0BbBjfbF+a YiIsRGlSmjcorQKWJniV6iPkkzly79s5M/ht3qKyKl1Q9yJt3kY39VB9RRPvODbE5m5K YjsVadsPfGtxkxVV54Ru9ZLR3H5N6ymfqJu+LesNbiTyqBF7YLYPFRwa0ul+GtWWwRD8 Rau29CIrU0PNwF+0NThKKQbTWxEdtnbEG/E1+qmkckrhkPIdaqH8dPhDbtpZ6uw5xsGK 31iw== X-Gm-Message-State: ALyK8tI5d0bMlS3YwnigroLCTVFQmJHSm6Tyj2SuiALg+skXcpKywGKYhZfCdSmvynEGfanymO2tc8GZE/zRjg== MIME-Version: 1.0 X-Received: by 10.202.88.86 with SMTP id m83mr18513106oib.52.1464648217062; Mon, 30 May 2016 15:43:37 -0700 (PDT) Received: by 10.202.81.5 with HTTP; Mon, 30 May 2016 15:43:36 -0700 (PDT) Date: Tue, 31 May 2016 00:43:36 +0200 Message-ID: From: Adrian Hope-Bailie To: DISPATCH Content-Type: multipart/alternative; boundary=001a113d35b0b30d0e053416fc0d Archived-At: Subject: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 22:43:40 -0000 --001a113d35b0b30d0e053416fc0d Content-Type: text/plain; charset=UTF-8 Hi, I am Adrian Hope-Bailie, employed at Ripple (ripple.com) and co-chair of the Web Payments Working Group at W3C. Some of you I know because we have met through the W3C and many of you I hope to meet in Berlin in July. I'm new to the IETF process and many RFCs later feel like I am getting to grips with things...slowly. I have been in discussion with the ART and SEC ADs over the last few weeks regarding work being done in a W3C community group that I chair, the Interledger Community Group. On the advice of the ADs I am seeking feedback/questions/comments as I work on a BoF proposal for this work, the Interledger Protocol. Put simply, Interledger is an open, neutral, payment protocol that is modeled on the Internet stack and runs on the open Internet. It is a protocol to connect payment networks/ledgers/blockchains into a network of payment networks (in much the same way that TCP/IP creates a network of networks). The idea for the work started at in 2015 Ripple and with the publishing of the Interledger Whitepaper in October became an open community effort. Since then the community group has grown to just shy of 200 participants. We held a packed to capacity all-day workshop in February in San Francisco and have another scheduled for 6 July in London ( https://interldger.org/workshop) There is a website with a lot of resources about the project at https://interledger.org as well as a reference implementation at https://github.com/interledger. This audience will likely be most interested in the architecture: https://interledger.org/rfcs/0001-interledger-architecture/ One of the more mature aspects of the work is a primitive used in the protocol called crypto-conditions. This has already been spec'd as an RFC: https://interledger.org/five-bells-condition/spec.html We hold a bi-weekly conference call on Wednesday at 3pm UTC which i invite you attend this week (1 June) to ask any questions or just lurk and listen. The details of the call are sent to the mailing list ( public-interledger@w3.org) in the agenda the day before. (To join the mailing list go to: https://www.w3.org/community/interledger/join). I will also post the details to this thread. Adrian --001a113d35b0b30d0e053416fc0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am Adrian Hope-Bailie, employ= ed at Ripple (ripple.com) and co-chair of= the Web Payments Working Group at W3C. Some of you I know because we have = met through the W3C and many of you I hope to meet in Berlin in July. I'= ;m new to the IETF process and many RFCs later feel like I am getting to gr= ips with things...slowly.

I have been in discussion with = the ART and SEC ADs over the last few weeks regarding work being done in a = W3C community group that I chair, the Interledger Community Group.

<= /div>
On the advice of the ADs I am seeking feedback/questions/comments= as I work on a BoF proposal for this work, the Interledger Protocol.
Put simply, Interledger is an open, neutral, payment protocol = that is modeled on the Internet stack and runs on the open Internet. It is = a protocol to connect payment networks/ledgers/blockchains into a network o= f payment networks (in much the same way that TCP/IP creates a network of n= etworks).

The idea for the work started at in 2015 Ripple= and with the publishing of the Interledger Whitepaper in October became an= open community effort. Since then the community group has grown to just sh= y of 200 participants. We held a packed to capacity all-day workshop in Feb= ruary in San Francisco and have another scheduled for 6 July in London (https://interldger.org/workshop)

One of the more mature aspects= of the work is a primitive used in the protocol called crypto-conditions. = This has already been spec'd as an RFC: https://interledger.org/five-bells-cond= ition/spec.html

We hold a bi-weekly confere= nce call on Wednesday at 3pm UTC which i invite you attend this week (1 Jun= e) to ask any questions or just lurk and listen. The details of the call ar= e sent to the mailing list (public-interledger@w3.org) in the ag= enda the day before. (To join the mailing list go to: https://www.w3.org/community/interledg= er/join).

I will also post the details to this thread= .

Adrian
--001a113d35b0b30d0e053416fc0d--