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

[Paul Kyzivat <[e-mail]>]

On 12/23/16 3:30 AM, Asveren, Tolga wrote:
> i- I agree with the need to “standardize” the “connection reuse per
> existing deployment semantics”.  I think what we are looking for is:
>
> -          Bidirectional connection reuse with TLS/server-side only
> certificate/UE authentication per SIP registration without RFC5626
>
> -          Bidirectional connection reuse with TCP over VPN, e.g. IPSec
>
> -          Bidirectional connection reuse with TCP when
> authentication/security is provided by L2

The problem in all of these cases is for the entity sending a request to 
be able to ascertain that the connection terminates on a device known to 
correspond to the URI used to address it.

Outbound was created to solve that problem. I have yet to see another 
"simpler" solution that provides that assurance.

As currently defined outbound can be used without redundancy if that is 
what you want to do. There is a requirement for the software to 
*support* use of redundancy, but deployments are free to configure 
without it. So I see no compelling reason to revise outbound for this 
purpose.

Maybe there is something simpler than outbound that will work. But it 
remains to be proposed.

	Thanks,
	Paul

> I am not sure what would be the best place to address these. It could be
> either happy-earballs or a new document. I would prefer the former and
> can provide text in either case.
>
>
>
> ii- The issue with SIP/UDP/DTLS is something quite different. It really
> is more about providing fast/practically feasible failover for DTLS
> connections (in addition to defining use of UDP/DTLS as a new transport
> for SIP but this part is relatively straightforward IMHO). In any case,
> let me use this opportunity to express my strong interest in this work
> one more time.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:*Olle E. Johansson [mailto:[e-mail]]
> *Sent:* Thursday, December 22, 2016 12:17 PM
> *To:* Asveren, Tolga <[e-mail]>
> *Cc:* Olle E Johansson <[e-mail]>; Christer Holmberg
> <[e-mail]>; Adam Roach <[e-mail]>; SIPCORE
> <[e-mail]>; Ben Campbell <[e-mail]>
> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>
>
>
>
>
>     On 22 Dec 2016, at 18:08, Asveren, Tolga <[e-mail]
>     <mailto:[e-mail]>> 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:[e-mail]]
>     *Sent:* Thursday, December 22, 2016 10:55 AM
>     *To:* Asveren, Tolga <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Olle E Johansson <[e-mail] <mailto:[e-mail]>>;
>     Christer Holmberg <[e-mail]
>     <mailto:[e-mail]>>; Adam Roach
>     <[e-mail] <mailto:[e-mail]>>; SIPCORE
>     <[e-mail] <mailto:[e-mail]>>; Ben Campbell
>     <[e-mail] <mailto:[e-mail]>>
>     *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>
>
>
>
>
>         On 22 Dec 2016, at 16:34, Asveren, Tolga <[e-mail]
>         <mailto:[e-mail]>> 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-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:[e-mail]]
>         *Sent:* Thursday, December 22, 2016 9:08 AM
>         *To:* Asveren, Tolga <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* Olle E Johansson <[e-mail] <mailto:[e-mail]>>;
>         Christer Holmberg <[e-mail]
>         <mailto:[e-mail]>>; Adam Roach
>         <[e-mail] <mailto:[e-mail]>>; SIPCORE
>         <[e-mail] <mailto:[e-mail]>>; Ben Campbell
>         <[e-mail] <mailto:[e-mail]>>
>         *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and
>         milestones
>
>
>
>
>
>             On 22 Dec 2016, at 14:50, Asveren, Tolga
>             <[e-mail] <mailto:[e-mail]>> 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:[e-mail]] *On Behalf
>             Of *Christer Holmberg
>             *Sent:* Thursday, December 22, 2016 7:39 AM
>             *To:* Adam Roach <[e-mail]
>             <mailto:[e-mail]>>; 'SIPCORE' <[e-mail]
>             <mailto:[e-mail]>>
>             *Cc:* Ben Campbell <[e-mail] <mailto:[e-mail]>>
>             *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 <[e-mail]
>             <mailto:[e-mail]>> on behalf of
>             "[e-mail] <mailto:[e-mail]>"
>             <[e-mail] <mailto:[e-mail]>>
>             *Date: *Tuesday 20 December 2016 at 22:27
>             *To: *"[e-mail] <mailto:[e-mail]>"
>             <[e-mail] <mailto:[e-mail]>>
>             *Cc: *Ben Campbell <[e-mail] <mailto:[e-mail]>>
>             *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.
>
>              1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently
>                 under discussion on the list.
>              2. "DTLS Transport for SIP", as proposed by Tolga Asveren's
>                 recent messages.
>              3. A mechanism for labeling the nature of SIP calls, with
>                 <draft-schulzrinne-sipcore-callinfo-spam> as a likely
>                 candidate draft.
>              4. 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.
>              5. 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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/sipcore
>
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>