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

[Paul Kyzivat <[e-mail]>]

On 12/24/16 7:08 AM, Asveren, Tolga wrote:
> RFC5626 seems to be leaving some room to use a single registration:
>    "For each outbound proxy URI in the set, the User Agent Client (UAC)
>    SHOULD send a REGISTER request using this URI as the default outbound
>    proxy.  (Alternatively, the UA could limit the number of flows formed
>    to conserve battery power, for example).  If the set has more than
>    one URI, the UAC MUST send a REGISTER request to at least two of the
>    default outbound proxies from the set. "
>
> OTOH it mandates use of reg-id/+sip.instance parameters:
>    "A UAC conforming to this specification MUST include in the Contact
>    header field, a "reg-id" parameter that is distinct from other
>    "reg-id" parameters used in other registrations that use the same
>    "+sip.instance" Contact header field parameter and AOR."
>
> I am not arguing that these parameters are not adding value/addressing certain requirements.
 > I just think that not everything they are helping with is absolutely 
needed by many existing deployments.

Maybe not. But it is what we have. Is it such a burden that we need to 
define something else?

> IMHO the main requirement for "simple outbound" is:
> (Re)use a single TCP connection between UA/Edge Proxy.

Do you really mean TCP? Or do you really mean TLS?

> This is anyhow how many deployments out in the wild operate.

Yes, but this has not been vetted for security.

> It would be great if that could be allowed (maybe with a SHOULD in happy-earballs).
> Iy may be even possible to define semantics without use of an option-tag  -
> I am not sure though whether we can end up with something kosher from IETF perspective-.
>
> As far as authentication is concerned:
> i- For TLS(only server certificate)
> Server authenticated based on X.509 certificate
> UE authenticated during registration (digest)

This only works in the case that the registrar is the first hop from the 
UA, and is also the home proxy for all subsequent sip messaging.

Is that a workable limitation?

> ii- For TLS(certificate for both ends)
> Already covered by RFC5923
>
> iii- For VPN
> Both ends are authenticated during VPN setup, e.g. IMS AKA.

ISTM the problem in this case is tying the endpoints and credentials 
used for VPN setup with the URL used to identify the two endpoints for 
sip messaging.

> Overall, I don't see any problem with your "knowing who is on the other end" question. Maybe I am missing your point(?)

See above. Note, I don't claim to be a security expert. We really need 
some in this discussion.

	Thanks,
	Paul

> Thanks,
> Tolga
>
>> -----Original Message-----
>> From: sipcore [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>> Sent: Friday, December 23, 2016 5:11 PM
>> To: [e-mail]
>> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>>
>> 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
>>>
>>
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>