Subject: [Acme] NYTimes.com: How Do You Stop Robocalls?

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jul 2021 16:59:32 +0000

Linked from today’s front page of The New York Times:

How Do You Stop Robocalls?
An F.C.C. rule that went into effect last month is meant to help put a stop to those relentless calls about your extended warranty, and others.
https://www.nytimes.com/article/stop-robocalls-scam-fcc.html?smid=em-share

It talks about Shaken/Stir by name a couple of times.  Someone want to tell the reporter there are still IESG issues that needs be resolved?

---

From: Mary Barnes <[email-masked]>
Date: Mon, 12 Jul 2021 12:38:18 -0500

For what has been implemented right now (i.e., basic calls), all the
specifications are RFCs.  AFAIK no one has implemented ACME for
certificate management (yet).

Regards,
Mary.

On Mon, Jul 12, 2021 at 11:59 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> An F.C.C. rule that went into effect last month is meant to help put a
> stop to those relentless calls about your extended warranty, and others.
>
> It talks about Shaken/Stir by name a couple of times.  Someone want to
> tell the reporter there are still IESG issues that needs be resolved?
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 12 Jul 2021 14:48:01 -0400

I know of a couple, including the one i work for :)

> On Jul 12, 2021, at 1:38 PM, Mary Barnes <[email-masked]> wrote:
> 
> For what has been implemented right now (i.e., basic calls), all the specifications are RFCs.  AFAIK no one has implemented ACME for certificate management (yet).
> 
> Regards,
> Mary.
> 
> On Mon, Jul 12, 2021 at 11:59 AM Salz, Rich <rsalz=[email-masked] <mailto:[email-masked]>> wrote:
> https://www.nytimes.com/article/stop-robocalls-scam-fcc.html?smid=em-share <https://www.nytimes.com/article/stop-robocalls-scam-fcc.html?smid=em-share>
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Jul 2021 00:58:21 -0400

Usually, with any new network protocols, the last 5% of deployment and
interop take 95% of the effort. STIR/SHAKEN is about 10% deployed, so there
is a lot of work to be done, including a lot of interop testing and likely
RFC update based on the deployment experience.

The RFC for Identity relies on JWT functionality which is not normally
present in the current SIP stacks. It is designed to be implemented using
standard web development technologies and falls slightly outside of the
normal telecom implementation expertise. Furthermore, the Identity header
more than triples the average SIP message size, which according to
standards, should trigger the protocol change from UDP to TCP. Bad JWT
implementation and network issues associated with the increased SIP
message size already affect the reliability of legitimate calls. Most of
the currently deployed SIP equipment has interop issues in their Identity
or TCP/TLS implementations.

This is compounded by the fact that SIP is, at this point, a legacy
protocol. Most SIP calls are sent over unecrypted UDP, which would not be
acceptable for any modern protocol. At the same time, SIP over TLS has many
performance and reliability issues that would need to be addressed before
it is ready for industry-wide deployment. Dealing with the fact that a lot
of telecom equipment is not routinely updated and relies on being isolated
from public access and mutual interop to operate makes deploying anything
new an excruciating process. The current set of standards was not exactly
designed to make deployment easier.

To summarize, currently, this is a bit of a mess. I would expect people
working hard to fix this, but very few people seem to care. It feels like
the whole industry is going through the infamous "Mission Accomplished"
moment.
_____________
Roman Shpount

On Mon, Jul 12, 2021 at 1:39 PM Mary Barnes <[email-masked]>
wrote:

> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Jul 2021 08:32:56 +0200

> 13 juli 2021 kl. 06:58 skrev Roman Shpount <[email-masked]>:
> 
>  At the same time, SIP over TLS has many performance and reliability issues that would need to be addressed before it is ready for industry-wide deployment.

There’s also a lack of applicable standards for TLS usage, as I’ve pointed out a few times, but the working group seems to have no energy to fix. SIP over TLS from the SIP phone side requires implementation of SIP outbound, which we never successfully tested at any SIPit. I know of a few implementations now, but haven’t tested them together.

Made this presentation five years ago
https://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world <https://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world>

/O

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Jul 2021 03:06:52 -0400

On Tue, Jul 13, 2021 at 2:33 AM Olle E. Johansson <[email-masked]> wrote:

>  At the same time, SIP over TLS has many performance and reliability
> issues that would need to be addressed before it is ready for industry-wide
> deployment.
>
>
> There’s also a lack of applicable standards for TLS usage, as I’ve pointed
> out a few times, but the working group seems to have no energy to fix. SIP
> over TLS from the SIP phone side requires implementation of SIP outbound,
> which we never successfully tested at any SIPit. I know of a few
> implementations now, but haven’t tested them together.
>

We have built a SIP Outbound implementation with TLS. It kind of works but
helped us identify plenty of problems both from reliability and scalability
points of view.

In the meantime, I am more concerned with more and more PII being sent in
SIP INVITE, especially with RCD. It might be legally required to encrypt it
when sending such data over the public internet, which would require TLS or
VPN connections for all service providers. Together with increased SIP
INVITE size, TLS essentially becomes the requirement. At this point, I am
more concerned with making service provider to service provider use cases
working.
_____________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Jul 2021 09:10:59 +0200

> On 13 Jul 2021, at 09:06, Roman Shpount <[email-masked]> wrote:
> 
> On Tue, Jul 13, 2021 at 2:33 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 13 juli 2021 kl. 06:58 skrev Roman Shpount <[email-masked] <mailto:[email-masked]>>:
>> 
> We have built a SIP Outbound implementation with TLS. It kind of works but helped us identify plenty of problems both from reliability and scalability points of view.
> 
> In the meantime, I am more concerned with more and more PII being sent in SIP INVITE, especially with RCD. It might be legally required to encrypt it when sending such data over the public internet, which would require TLS or VPN connections for all service providers. Together with increased SIP INVITE size, TLS essentially becomes the requirement. At this point, I am more concerned with making service provider to service provider use cases working.

I would love to have a discussion on that - either on the sipcore list or somewhere else. I gave a lot of input to the SIPconnect update but there’s still a lot of work to do on the server2server case.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Jul 2021 08:10:09 +0000

Hi Olle,

When you say “does not support Outbound”, are you referring to the whole mechanism, or to the specific reuse-of-registration-connection-for-incoming-calls part?

Regards,

Christer

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: stir <[email-masked]> on behalf of Olle E. Johansson <[email-masked]>
Sent: Tuesday, July 13, 2021 9:32:56 AM
To: Roman Shpount <[email-masked]>
Cc: [email-masked] <[email-masked]>; Mary Barnes <[email-masked]>; Salz, Rich <rsalz=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?

13 juli 2021 kl. 06:58 skrev Roman Shpount <[email-masked]<mailto:[email-masked]>>:

Made this presentation five years ago
https://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Jul 2021 10:21:09 +0200

> On 13 Jul 2021, at 10:10, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> Hi Olle,
> 

We have had a lot of discussions about this in the past, where I focused on the latter. In the current set of standards a server is not allowed to reuse the incoming TLS connection for outbound requests. Only SIP outbound allows this. That’s why I started a discussion about a “half-outbound” - much like the use of Outbound in SIP over WebSockets today.

Here’s some notes and ideas on that from 2016:
https://www.slideshare.net/oej/sip-half-outbound-random-notes <https://www.slideshare.net/oej/sip-half-outbound-random-notes>

/O
> 
> Regards,
> 
> Christer
> 
> Get Outlook for iOS <https://aka.ms/o0ukef>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Jul 2021 08:52:33 +0000

Hi,

> We have had a lot of discussions about this in the past, where I focused on the latter. In the current set of standards a server is not allowed to reuse the incoming TLS connection for outbound requests. Only SIP outbound allows this. 

Correct.

However, many still do it, because in addition to the TLS issues it is also needed for NAT traversal.

>That’s why I started a discussion about a “half-outbound” - much like the use of Outbound in SIP over WebSockets today.

That specific part could be defined in a separate specification, similar to what we did for SIP keep-alive: people wanted to have a mechanism for negotiating keep-alives, without having to implement everything else in Outbound.

Regards,

Christer

________________________________________
From: stir <mailto:[email-masked]> on behalf of Olle E. Johansson <mailto:[email-masked]>
Sent: Tuesday, July 13, 2021 9:32:56 AM
To: Roman Shpount <mailto:[email-masked]>
Cc: mailto:[email-masked] <mailto:[email-masked]>; Mary Barnes <mailto:[email-masked]>; Salz, Rich <mailto:rsalz=[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>
Subject: Re: [stir] [Acme] http://NYTimes.com: How Do You Stop Robocalls? 

13 juli 2021 kl. 06:58 skrev Roman Shpount <mailto:[email-masked]>:

/O
mailto:[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Jul 2021 10:56:05 +0200

> On 13 Jul 2021, at 10:52, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
Exactly. Kamailio does that, because it’s the only way even if we break the RFCs.
> That specific part could be defined in a separate specification, similar to what we did for SIP keep-alive: people wanted to have a mechanism for negotiating keep-alives, without having to implemen…

Yes, that was my idea. But at the time it seemed like people either did not understand or did not see the need.
Maybe we have a different situation now. It is needed, as we need RFC-compliant security in SIP.

/O