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

From: Adam Roach <[email-masked]>
Date: Tue, 20 Dec 2016 14:27:15 -0600

[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>,
    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

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 21 Dec 2016 04:52:42 +0000

Considering that we already agreed in Berlin to take on "Happy Eyeballs for SIP” as a milestone, I think that should be prioritized.  We are obviously willing to work on this and have already put forth a candidate draft to satisfy this milestone (draft-worley-sip-he-connection) that we’re hoping the WG will consider for adoption.

Cheers,

Gonzalo

> On Dec 20, 2016, at 3:27 PM, Adam Roach <[email-masked]> wrote:
> 
> [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>, 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.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 21 Dec 2016 08:49:09 +0000

Sorted according to my order of preference:

i- A mechanism for labeling the nature of SIP calls, with <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate draft.
I can actively review. This draft addresses a real/practical/urgent industry need.

ii- "Happy Eyeballs for SIP" (aka Happy Earballs), currently under discussion on the list.
I can actively review/co-author. This shouldn’t; take too long and probably would end up standardizing a few common-sense/almost obvious semantics/changes in currently defined procedures -which makes it important-

iii- "DTLS Transport for SIP", as proposed by Tolga Asveren's recent messages.
I can (co)-author. Use of UDP in a secure way is important for large-scale servers.

The other two are of equal importance from my perspective and are at the bottom of my list.

I assume any RFC6555 Happy Eyeballs related discussions/bis activity should take place mainly in the V6ops WG(?)

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, December 20, 2016 3:27 PM
To: 'SIPCORE' <[email-masked]>
Cc: Ben Campbell <[email-masked]>
Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

[as chair]

  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

Thanks!

/a

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Dec 2016 14:29:02 +0000

4 and 5 are error fixing, so we should probably do them anyway, no matter what the priority.

Of new work 3 has highest priority in my mind.

Your message rather seems to imply we do them all and we are just sorting out the sequence, as there is no indication required that people consider we actually need the work (that is a different question from actively review and comment).

Keith

Sent: 20 December 2016 20:27

[as chair]

Thanks!

/a

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 21 Dec 2016 15:35:30 -0500

>     <draft-sparks-sipcore-name-addr-guidance> as a likely candidate draft

These two are essentially bug fixes, and it seems that we are already in
need of their results.  Also, the amount of additional work to complete
them is small.  So they appear to be the highest-priority items.

>  1. "Happy Eyeballs for SIP" (aka Happy Earballs), currently under

I'm involved in working on this, so I think it's useful.  Generally, its
usefulness hinges on how many SIP systems are both (1) dual-stack and
(2) use general RFC 3263 mechanisms to find servers (i.e., aren't in
heavily configured environments).  But if we want to support SIP over
the general Internet in the future, we'll need this.

>  2. "DTLS Transport for SIP", as proposed by Tolga Asveren's recent

I think this is a good idea, as it solves a problem that Roman Shpount
and Tolga Asveren have both mentioned as important.  Do other people who
work with large-scale servers feel a need for DTLS or DTLS-like
signaling transport?

>     <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate draft.

Certainly spam calls are a problem in reality.  Do people consider this
a way to help suppress them in practice?

Dale

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Dec 2016 21:02:30 +0000

A bit of background below.

The two drafts are part of a broader suite of tools, and probably among the lower-importance ones compared to, in particular, the STIR caller ID authentication work. I think there is some consensus that a complete robocall prevention eco system consists of a number of components:

(1) A way to validate caller ID, to prevent spoofing and to facilitate tracking and suitable law enforcement. (Spoofing makes the other parts hard or fail.) Law enforcement, besides putting a few spammers behind bars, changes the risk/reward calculus and thus discourages copy cats.

(2) With authenticated caller ID, various block/black lists can work, decreasing the reach of spammers and thus again weakening their business model.

(3) Given the challenges of not being able to do content analysis easily (or look at the history of domain names or senders), human feedback is important to populate the blacklists. Also, as for email, there's a significant gray zone of calls in between the clearly-wanted (calls from your spouse, one would hope) and the outright-criminal fraud. The "unwanted" draft allows for standards-based feedback by humans to make both automated blocking, for groups of customers and the individual, and enforcement work better.

(4) Given the gray area and the general desire not to interfere with communications, for both customer-focused and, in some countries, legal reasons, some calls are best flagged and labeled rather than rejected, so that end systems or humans can make more nuanced decisions. Examples often cited include calls from charities, politicians and survey organizations, but also automated calls for prescription pickup, school snow days or outstanding debts. The 'callinfo' draft addresses this particular need.

Both drafts are outgrowths of the Robocall Strike Force (https://www.fcc.gov/news-events/events/2016/10/second-meeting-industry-led-robocall-strike-force) and were identified as standards gaps by the participants.

Thus, the drafts are unlikely, by themselves, to solve the robocall problem, but hopefully they'll help in a small way.

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

>     <draft-schulzrinne-sipcore-callinfo-spam> as a likely candidate draft.

Certainly spam calls are a problem in reality.  Do people consider this a way to help suppress them in practice?

Dale

---

From: Richard Shockey <[email-masked]>
Date: Wed, 21 Dec 2016 17:53:53 -0500

+1  

“There is no Silver Bullet”

Henning is right.  These drafts are part of a whole suite of initiatives going on at multiple levels among multiple SDO’s.

It should also be pointed out that these initiatives are being supported by multiple National Regulatory Authorities.  

I might point out my presentation to NICC in the UK recently and the presentation by Huw Saunders the Director of Network Infrastructure for OFCOM the UK telecom regulator.  

http://www.niccstandards.org.uk/meetings/forum-2016.cfm

This is going to get deployed.  The SIP Forum along with ATIS are working on the STIR/ SHAKEN implementation profiles as we speak. 

I will say something else. The pending change in US Administration IMHO will not affect these initiatives in any way shape or form.

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

On 12/21/16, 4:02 PM, "sipcore on behalf of Henning Schulzrinne" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    Henning
    
    -----Original Message-----
    From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
    Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

    
    Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Dec 2016 12:39:00 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 20 December 2016 at 22:27
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Subject: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

[as chair]

Thanks!

/a

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 22 Dec 2016 13:50:36 +0000

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.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, December 22, 2016 7:39 AM
To: Adam Roach <[email-masked]>; 'SIPCORE' <[email-masked]>
Cc: Ben Campbell <[email-masked]>
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

Hi,

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

[as chair]

Thanks!

/a

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Dec 2016 15:08:02 +0100

> On 22 Dec 2016, at 14:50, Asveren, Tolga <[email-masked]> wrote:
> 
> 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:[email-masked] <mailto:[email-masked]>] On Behalf Of Christer Holmberg
> To: Adam Roach <[email-masked] <mailto:[email-masked]>>; 'SIPCORE' <[email-masked] <mailto:[email-masked]>>
> Cc: Ben Campbell <[email-masked] <mailto:[email-masked]>>
> From: sipcore <[email-masked] <mailto:[email-masked]>> on behalf of "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: Ben Campbell <[email-masked] <mailto:[email-masked]>>
> "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
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 22 Dec 2016 15:34:06 +0000

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?

Thanks,
Tolga

From: Olle E. Johansson [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 9:08 AM
To: Asveren, Tolga <[email-masked]>
Cc: Olle E Johansson <[email-masked]>; Christer Holmberg <[email-masked]>; Adam Roach <[email-masked]>; SIPCORE <[email-masked]>; Ben Campbell <[email-masked]>
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

On 22 Dec 2016, at 14:50, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

/O

Thanks,
Tolga

To: Adam Roach <[email-masked]<mailto:[email-masked]>>; 'SIPCORE' <[email-masked]<mailto:[email-masked]>>

Hi,

Regards,

Christer

[as chair]

Thanks!

/a
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Dec 2016 16:55:04 +0100

> On 22 Dec 2016, at 16:34, Asveren, Tolga <[email-masked]> wrote:
> 
> Olle,
>  
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:[email-masked] <mailto:[email-masked]>] 
> To: Asveren, Tolga <[email-masked] <mailto:[email-masked]>>
> Cc: Olle E Johansson <[email-masked] <mailto:[email-masked]>>; Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Adam Roach <[email-masked] <mailto:[email-masked]>>; SIPCORE <[email-masked] <mailto:[email-masked]>>; Ben Campbell <[email-masked] <mailto:[email-masked]>>
> On 22 Dec 2016, at 14:50, Asveren, Tolga <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 22 Dec 2016 17:08:38 +0000

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.
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.

Thanks,
Tolga

Sent: Thursday, December 22, 2016 10:55 AM

On 22 Dec 2016, at 16:34, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Olle,

Cheers,
/O

Thanks,
Tolga

From: Olle E. Johansson [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 9:08 AM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Cc: Olle E Johansson <[email-masked]<mailto:[email-masked]>>; Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Adam Roach <[email-masked]<mailto:[email-masked]>>; SIPCORE <[email-masked]<mailto:[email-masked]>>; Ben Campbell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

/O

Thanks,
Tolga

Hi,

Regards,

Christer

[as chair]

Thanks!

/a

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 22 Dec 2016 18:16:32 +0100

> On 22 Dec 2016, at 18:08, Asveren, Tolga <[email-masked]> wrote:
> 
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 synchronizat…
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
> On 22 Dec 2016, at 16:34, Asveren, Tolga <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Olle,
>  
> 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>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 23 Dec 2016 08:30:44 +0000

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

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

Sent: Thursday, December 22, 2016 12:17 PM

On 22 Dec 2016, at 18:08, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

/O

Thanks,
Tolga

Olle,

Cheers,
/O

Thanks,
Tolga

/O

Thanks,
Tolga

Hi,

Regards,

Christer

[as chair]

Thanks!

/a

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 23 Dec 2016 16:30:52 +0000

BTW, SIP/UDP/DTLS has an advantage over SIP/TCP/TLS even without the possible improvements I mentioned below: It does not require establishment of a new TCP connection. This particularly is important for server failover scenarios as it would decrease the amount of work to be done by the standby server after it became active and also would cut the overall number of round-trips needed to resume communication toward/from a UE.

And another side benefit is that SIP/UDP is less “victimized” than SIP/TCP on congested links, e.g. poor/congested mobile coverage areas.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Friday, December 23, 2016 3:31 AM
To: Olle E. Johansson <[email-masked]>
Cc: Ben Campbell <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones

Thanks,
Tolga

/O

Thanks,
Tolga

Olle,

Cheers,
/O

Thanks,
Tolga

/O

Thanks,
Tolga

Hi,

Regards,

Christer

[as chair]

Thanks!

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Dec 2016 17:11:29 -0500

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 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:[email-masked]]
> *Sent:* Thursday, December 22, 2016 12:17 PM
> *To:* Asveren, Tolga <[email-masked]>
> *Cc:* Olle E Johansson <[email-masked]>; Christer Holmberg
> <[email-masked]>; Adam Roach <[email-masked]>; SIPCORE
> <[email-masked]>; Ben Campbell <[email-masked]>
> *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>
>
>
>
>
>     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
>
>     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 :-)
>
>
>
> 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:[email-masked]]
>     *Sent:* Thursday, December 22, 2016 10:55 AM
>     *To:* Asveren, Tolga <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Olle E Johansson <[email-masked] <mailto:[email-masked]>>;
>     Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>; Adam Roach
>     <[email-masked] <mailto:[email-masked]>>; SIPCORE
>     <[email-masked] <mailto:[email-masked]>>; Ben Campbell
>     <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and milestones
>
>
>
>
>
>         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.
>
>     We’ve discussed it a number of times both here and on the SIP Forum
>     techwg mailing list. You can find summaries here:
>
>
>
>     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
>
>     We’ve had a lot of clients register with “;transport=tls” at SIPit
>     without a client cert - which means we can’t communicate
>
>         *From:* Olle E. Johansson [mailto:[email-masked]]
>         *Sent:* Thursday, December 22, 2016 9:08 AM
>         *To:* Asveren, Tolga <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* Olle E Johansson <[email-masked] <mailto:[email-masked]>>;
>         Christer Holmberg <[email-masked]
>         <mailto:[email-masked]>>; Adam Roach
>         <[email-masked] <mailto:[email-masked]>>; SIPCORE
>         <[email-masked] <mailto:[email-masked]>>; Ben Campbell
>         <[email-masked] <mailto:[email-masked]>>
>         *Subject:* Re: [sipcore] RESPONSE REQUESTED: SIPCORE work and
>         milestones
>
>
>
>
>
>             On 22 Dec 2016, at 14:50, Asveren, Tolga
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>             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
>
>         Adam as chair: SIP Client Connection Reuse is something we’ve
>         disussed under multiple names - “half outbound” or “why is
>         ;transport=tls”
>
>             *From:* sipcore [mailto:[email-masked]] *On Behalf
>             Of *Christer Holmberg
>             *Sent:* Thursday, December 22, 2016 7:39 AM
>             *To:* Adam Roach <[email-masked]
>             <mailto:[email-masked]>>; 'SIPCORE' <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* Ben Campbell <[email-masked] <mailto:[email-masked]>>
>             *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 <[email-masked]
>             <mailto:[email-masked]>> on behalf of
>             "[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>
>             *Date: *Tuesday 20 December 2016 at 22:27
>             *To: *"[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>
>             *Cc: *Ben Campbell <[email-masked] <mailto:[email-masked]>>
>             *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.
>
>              4. Fixing Content-ID in SIP, as discussed
>                 in <https://www.ietf.org/mail-archive/web/sipcore/current/msg07245.html>
>             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.
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 24 Dec 2016 12:08:16 +0000

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.
IMHO the main requirement for "simple outbound" is: (Re)use a single TCP connection between UA/Edge Proxy. This is anyhow how many deployments out in the wild operate. 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)

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. 

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

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, December 23, 2016 5:11 PM
> To: [email-masked]
> > i- I agree with the need to "standardize" the "connection reuse per
> > existing deployment semantics".  I think what we are looking for is:
> >
> 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.
> 
> without it. So I see no compelling reason to revise outbound for this purpose.
> 
> > 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
> >
> >
> >
> > <[email-masked]>; Adam Roach <[email-masked]>;
> > SIPCORE <[email-masked]>; Ben Campbell <[email-masked]>
> > It's not mutual - two certs in the same TLS session, but that would
> > also
> >
> > The current way to handle this is connection reuse that breaks the
> > RFCs, we have that implementation in Kamailio.
> >
> >         I missed the point about why "practically possible failover"
> >     We've discussed it a number of times both here and on the SIP Forum
> >     In short, without SIP Outbound the client connection can't be
> >     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
> >
> >             more "failover friendly". This issue requires more
> >         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
> >
> >
> >
> >             we want to specify DTLS-for-SIP simply because DTLS is "hot"?
> >
> >
> >
> >             Regards,
> >
> >
> >
> >             Christer
> >
> >
> >
> >                 in <https://www.ietf.org/mail-
> archive/web/sipcore/current/msg07245.html>
> >                 <https://www.ietf.org/mail-
> archive/web/sipcore/current/msg07245.html>,

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Dec 2016 10:15:28 -0500

On 12/24/16 7:08 AM, Asveren, Tolga wrote:
> 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-.
>

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?

> 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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 25 Dec 2016 06:52:19 +0000

Inline...

Thanks,
Tolga

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Saturday, December 24, 2016 10:15 AM
> To: Asveren, Tolga <[email-masked]>; [email-masked]
>  > 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.
> 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. 
> > 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-.
> >
> > 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.
> 
[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
> 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
> >
> >> 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.
> >>
> >> 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
> >>> 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.
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> be one solution (there is a RFC for that). SIP Outbound permits
> >>> reuse of the incoming connection and thus
> >>>