Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

"Olle E. Johansson" <oej@edvina.net> Thu, 22 December 2016 17:17 UTC

Return-Path: <oej@edvina.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B913A12965F for <sipcore@ietfa.amsl.com>; Thu, 22 Dec 2016 09:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5mlV7_PYAx4i for <sipcore@ietfa.amsl.com>; Thu, 22 Dec 2016 09:17:08 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 01EE3129530 for <sipcore@ietf.org>; Thu, 22 Dec 2016 09:17:07 -0800 (PST)
Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 693F8702E; Thu, 22 Dec 2016 18:16:48 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_06D6E694-1B7E-49D4-BD0A-BD8B6E53056C"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <SN2PR03MB2350D22AA44D07FE21369CB0B2920@SN2PR03MB2350.namprd03.prod.outlook.com>
Date: Thu, 22 Dec 2016 18:16:32 +0100
Message-Id: <C871E653-CAE4-456E-B397-1CB0B182D847@edvina.net>
References: <e42393d8-9ddb-78ba-78fe-34f04f6d672d@nostrum.com> <D48194CE.14EEA%christer.holmberg@ericsson.com> <CO2PR03MB2342255BB9ECDF579283A930B2920@CO2PR03MB2342.namprd03.prod.outlook.com> <2341DDCB-C96D-441B-A6CA-049A8149FB0B@edvina.net> <SN2PR03MB235007F2298CD2EEDC718363B2920@SN2PR03MB2350.namprd03.prod.outlook.com> <EBAB0160-CDD2-4821-9765-44EF10742728@edvina.net> <SN2PR03MB2350D22AA44D07FE21369CB0B2920@SN2PR03MB2350.namprd03.prod.outlook.com>
To: "Asveren, Tolga" <tasveren@sonusnet.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/UHU3gPROR2UxHazIL9npZxIUbc0>
Cc: Ben Campbell <ben@nostrum.com>, SIPCORE <sipcore@ietf.org>, Olle E Johansson <oej@edvina.net>
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 17:17:12 -0000

> On 22 Dec 2016, at 18:08, Asveren, Tolga <tasveren@sonusnet.com> wrote:
> 
> Thanks for the clarification.
>  
> i- I agree that connection re-use needs to be addressed as it would be a normative change.
> ii- Is it a mandate that mutual authentication needs to be used if transport=tls? If so, that would require another normative change to align with practical needs.
The URI for the target and the cert for the UA server needs to match. It’s not mutual - two certs in the same TLS session, but that would also
be one solution (there is a RFC for that). SIP Outbound permits reuse of the incoming connection and thus
avoids this particular problem.

> iii- I think both i-/ii- are relatively straightforward to address. The more interesting/challenging aspect is how to failover DTLS connections without a need for per-transaction state synchronization and with the fewest round-trips possible.
Connection reuse needs to be handled separately and needs to be something that is way more easy to implement than SIP outbound.
We need something we can easily test and get it done soon, as I want more TLS on the SIP networks out there :-)

The current way to handle this is connection reuse that breaks the RFCs, we have that implementation in Kamailio.
If there is an open socket, TLS or TCP, we prefer to use it to make things work. I would love for this to be RFC compliant :-)

/O
>  
> Thanks,
> Tolga
>  
> From: Olle E. Johansson [mailto:oej@edvina.net <mailto:oej@edvina.net>] 
> Sent: Thursday, December 22, 2016 10:55 AM
> To: Asveren, Tolga <tasveren@sonusnet.com <mailto:tasveren@sonusnet.com>>
> Cc: Olle E Johansson <oej@edvina.net <mailto:oej@edvina.net>>; Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>; Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>>; SIPCORE <sipcore@ietf.org <mailto:sipcore@ietf.org>>; Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>>
> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>  
>  
> On 22 Dec 2016, at 16:34, Asveren, Tolga <tasveren@sonusnet.com <mailto:tasveren@sonusnet.com>> wrote:
>  
> Olle,
>  
> I missed the point about why “practically possible failover” needs to be solved both for TLS/DTLS (I am not arguing it would be good to have a solution for both) and also what this issue in general has something to do with client certificates.
> Could you provide a bit more information/clarifications?
>  
> We’ve discussed it a number of times both here and on the SIP Forum techwg mailing list. You can find summaries here:
>  
> http://www.slideshare.net/oej/sip-half-outbound-random-notes <http://www.slideshare.net/oej/sip-half-outbound-random-notes>
> http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world <http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world>
>  
> In short, without SIP Outbound the client connection can’t be re-used for outbound requests. Seems like there is a huge
> resistance to implement SIP Outbound. We need a way for the client to allow the server to reuse the inbound connection
> for outbound requests even though there’s no TLS certificate matching the URI on the client side.
>  
> We’ve had a lot of clients register with “;transport=tls” at SIPit without a client cert - which means we can’t communicate
> based on that registration.
>  
> Cheers,
> /O
> 
> 
> Thanks,
> Tolga
>  
> From: Olle E. Johansson [mailto:oej@edvina.net <mailto:oej@edvina.net>] 
> Sent: Thursday, December 22, 2016 9:08 AM
> To: Asveren, Tolga <tasveren@sonusnet.com <mailto:tasveren@sonusnet.com>>
> Cc: Olle E Johansson <oej@edvina.net <mailto:oej@edvina.net>>; Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>; Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>>; SIPCORE <sipcore@ietf.org <mailto:sipcore@ietf.org>>; Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>>
> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>  
>  
> On 22 Dec 2016, at 14:50, Asveren, Tolga <tasveren@sonusnet.com <mailto:tasveren@sonusnet.com>> wrote:
>  
> Regarding the interest in SIP/UDP/DTLS:
> This is mainly based on prospect of larger scalability on server side. There may/may not be an immediate need to tweak/change things to make DTLS related processing (hopefully just on the local stack level rather than on on-the-wire protocol- with some supporting SIP enhancements) more “failover friendly”. This issue requires more analysis/discussion but does not sound unsolvable IMHO.
> We will have to solve client connection reuse for both TLS and DTLS sessions though. Unless you want to have
> client certificates on all devices.
>  
> Adam as chair: SIP Client Connection Reuse is something we’ve disussed under multiple names - “half outbound” or “why is ;transport=tls”
> deprecated” or “Why doesn’t SIP Outbound happen?”. Maybe that deserves a milestone.
>  
> /O
> 
> 
>  
> Thanks,
> Tolga
>  
> From: sipcore [mailto:sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>] On Behalf Of Christer Holmberg
> Sent: Thursday, December 22, 2016 7:39 AM
> To: Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>>; 'SIPCORE' <sipcore@ietf.org <mailto:sipcore@ietf.org>>
> Cc: Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>>
> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>  
> Hi,
>  
> I will obviously be actively involved in 4), and I also agree that 5) should be done as it is a correction.
>  
> As far as the other potential work is concerned, 3) has the highest priority for me, and I would actively participate in that work.
>  
> I would review 1) and 2), but I would really like to see an individual draft on 2) before we agree whether to create a milestone for it. For example, I would like to see some input on WHY to do it, and HOW it is intended to be deployed etc. How does DTLS fit SIP? What are the advantages? OR, do we want to specify DTLS-for-SIP simply because DTLS is “hot”?
>  
> Regards,
>  
> Christer
>  
> From: sipcore <sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>> on behalf of "adam@nostrum.com <mailto:adam@nostrum.com>" <adam@nostrum.com <mailto:adam@nostrum.com>>
> Date: Tuesday 20 December 2016 at 22:27
> To: "sipcore@ietf.org <mailto:sipcore@ietf.org>" <sipcore@ietf.org <mailto:sipcore@ietf.org>>
> Cc: Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>>
> Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>  
> [as chair]
> 
> Now that we have our new charter approved, I'd like the working group to have a discussion about the specific work items that we should take on in the short- to medium-term so that we can revise our milestones appropriately. Based on recent discussions on the mailing list, the following topics have some mind-share behind them. What I'd like from everyone with an interest in any of these topics is to indicate (a) whether you are willing to actively review and comment on documents on the topic; and (b) what priority each task has relative to each other: there are five topics; please indicate a unique priority from one (most important) to five (least important) for each topic.
> 
> "Happy Eyeballs for SIP" (aka Happy Earballs), currently under discussion on the list.
> "DTLS Transport for SIP", as proposed by Tolga Asveren's recent messages.
> A mechanism for labeling the nature of SIP calls, with <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate draft.
> Fixing Content-ID in SIP, as discussed in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07245.html> <https://www.ietf.org/mail-archive/web/sipcore/current/msg07245.html>, with <draft-holmberg-sipcore-content-id> as a likely candidate draft.
> Clarifications around SIP name-addr, with <draft-sparks-sipcore-name-addr-guidance> as a likely candidate draft
> 
> I will also note that we have already declared consensus on adopting <draft-ietf-sipcore-status-unwanted> as a WG document, and will be adding an associated milestone. I want to take this opportunity to remind people that the document is in WGLC, and your comments are strongly encouraged, the earlier the better.
> 
> Please respond before the end of 2016. Thanks!
> 
> Thanks!
> 
> /a
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org <mailto:sipcore@ietf.org>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>