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

["Asveren, Tolga" <[e-mail]>]

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Saturday, December 24, 2016 10:15 AM
> To: Asveren, Tolga <[e-mail]>; [e-mail]
> Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
> 
> 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?
[TOLGA] In terms of "burden in practice", yes IMHO. There is a large set of existing deployments behaving in certain way and I don't see people giving up that model/it causing any issues. It would be good to standardize it -and to add some clarifications/warnings/guidelines as needed- so that people have a more informed understanding.
> 
> > 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?
[TOLGA]  Politically correct answer: TLS. OTOH, the behavior I described is widely used with TCP as well. With VPN/L2 security, this probably should be acceptable even within IETF. There are also several cases, where there is no VPN/L2 security and folks are still fine with using TCP this way(although not addressing a MitM attack, TCP sequence numbers, SIP Call-Id/to-tag/from-tag provide some resiliency for many more common/practical attack scenarios)). I would prefer allowing TCP as well -in the specification, if there is agreement to have one- with information about security aspects. 
> 
> > 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?
[TOLGA] This is how things operate mostly in practice. It can be mentioned as when the mechanism is applicable.
> 
> > 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.
[TOLGA] Again, based on practice/existing deployments:
IMS AKA: The identity provided by SIM/USIM is what is used for SIP as well.
VPN among servers: Servers know each other based on preconfigured data, e.g. IP Address, and that is used during VPN setup and by SIP (possibly after DNS resolution)
TLS(only server side certificate): X.509 identity is what is used by SIP. Registered AoR (for UE authentication) is anyhow what SIP uses.

I don't see any problem/issues on this front. Again, all this is based on how things operate in practice for many years.
> 
> > 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-wor
> >>> ld
> >>>
> >>>
> >>>
> >>>     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
> >