Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 6 Jun 2013 21:04:40 +0000

I agree. But the interface to the user needs to be easily understood to the user, independent of device.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
Sent: Wednesday, June 05, 2013 1:18 PM
To: [email-masked]
Subject: Re: A 4474 that will work through SBCs (generally/potentially)

There may exist options for presenting unsigned calls to end-users and
allow them to decide on a call rejection.

I would encourage the separation of end-users from service providers and
hope the technical solution can enable multiple policies for SSPs and
regulators to choose from (SIP Service Providers could be enterprises,
SMS, service operators, or my asterisk software).

Jean-Francois.
---
Jean-François Mulé
Mobile:+1-415-881-7178
mailto:[email-masked]

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Labs
[email-masked]<mailto:[email-masked]>
+1-609-903-3360

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Jun 2013 18:15:40 -0400

Let’s be realistic.  For the consumer that is being grossly affected by this
problem you are dealing with a class of consumer device that is, for the
time being, is not going to display any type of reputation information
beyond  “unknown” even in the enterprise this is not going to work too well.
 
I pay Verizon or ATT or Bell Canada or Orange for a service. I’m happy to do
that. I expect that they can simply manage the service in an appropriate
manner to keep me paying them X per month.  We have seen the failure of DKIM
we do not want the Public SIP Telephony Network to end up like ..
 
This is going to end up being a service provider problem first then
something else as the SIP/IMS networks evolve. 
 
My life and ours is complicated enough. 
 
Simple wins. 
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DOLLY, MARTIN C
Sent: Thursday, June 06, 2013 5:05 PM
To: [email-masked]
Subject: Re: [stir] A 4474 that will work through SBCs
(generally/potentially
 
I agree. But the interface to the user needs to be easily understood to the
user, independent of device.
 
-----Original Message-----
From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
Jean-Francois Mule
Sent: Wednesday, June 05, 2013 1:18 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: A 4474 that will work through SBCs (generally/potentially)

 
Jean-Francois.
---
Jean-François Mulé
Mobile:+1-415-881-7178
 <mailto:[email-masked]> mailto:[email-masked]
 
Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Labs
 <mailto:[email-masked]> [email-masked]
+1-609-903-3360

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 6 Jun 2013 22:27:17 +0000

I agree that only a simple solution that addresses IP space is the Big Bang for the buck

We might add an extension for authentication assurance

Martin Dolly
AT&T

Sent from my iPhone

On Jun 6, 2013, at 6:15 PM, "Richard Shockey" <[email-masked]<mailto:[email-masked]>> wrote:

Let’s be realistic.  For the consumer that is being grossly affected by this problem you are dealing with a class of consumer device that is, for the time being, is not going to display any type of reputation information beyond  “unknown” even in the enterprise this is not going to work too well.

I pay Verizon or ATT or Bell Canada or Orange for a service. I’m happy to do that. I expect that they can simply manage the service in an appropriate manner to keep me paying them X per month.  We have seen the failure of DKIM we do not want the Public SIP Telephony Network to end up like ..

This is going to end up being a service provider problem first then something else as the SIP/IMS networks evolve.

Simple wins.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Thursday, June 06, 2013 5:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
Sent: Wednesday, June 05, 2013 1:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: A 4474 that will work through SBCs (generally/potentially)

Jean-Francois.
---
Jean-François Mulé
Mobile:+1-415-881-7178
mailto:[email-masked]

Martin Dolly

---

From: Brian Rosen <[email-masked]>
Date: Thu, 6 Jun 2013 18:31:08 -0400

Since virtually no bad calls are SIP end to end, it would seem that we need something that lets us go SIP to PSTN to SIP, early on.

I do think there are opportunities to show more info, but I get the point about paying the service provider for a reliable service.

Brian

On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" <[email-masked]> wrote:

> On Jun 6, 2013, at 6:15 PM, "Richard Shockey" <[email-masked]> wrote:
> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
>> [email-masked]
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 6 Jun 2013 22:50:18 +0000

Brian

PSTN is a the icing on the cake

BR

Martin Dolly
AT&T

Sent from my iPhone

On Jun 6, 2013, at 6:31 PM, "Brian Rosen" <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Jun 6, 2013, at 6:27 PM, "DOLLY, MARTIN C" <[email-masked]<mailto:[email-masked]>> wrote:

Martin Dolly
AT&T

Sent from my iPhone

Simple wins.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
Sent: Wednesday, June 05, 2013 1:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: A 4474 that will work through SBCs (generally/potentially)

Jean-Francois.
---
Jean-François Mulé
Mobile:+1-415-881-7178
mailto:[email-masked]

Martin Dolly

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jun 2013 18:55:47 -0400

On 6/6/13 6:31 PM, Brian Rosen wrote:
> Since virtually no bad calls are SIP end to end,

No? Why? Just lack of demand? Or lack of technology?

> it would seem that we
> need something that lets us go SIP to PSTN to SIP, early on.

For PSTN to SIP, the sip side has nothing better to go on than what it 
was provided. So it seems the only option here is transitive trust.

Now consider a "trusted" PSTN source. It can't remain trusted if it 
permits spoofed IDs on its incoming SIP connections. So such a SIP-PSTN 
interconnect must not assert an ID for any call it gets from a sip 
source and can't verify.

So ISTM that in addition to a suitable mechanism, there is need for a 
certification process for PSTN providers that they are suitably 
verifying incoming sip calls.

	Thanks,
	Paul

> I do think there are opportunities to show more info, but I get the
> point about paying the service provider for a reliable service.
>
> Brian
>
>>> Let’s be realistic.For the consumer that is being grossly affected by
>>> this problem you are dealing with a class of consumer device that is,
>>> for the time being, is not going to display any type of reputation
>>> information beyond “unknown” even in the enterprise this is not going
>>> to work too well.
>>>
>>> I pay Verizon or ATT or Bell Canada or Orange for a service. I’m
>>> happy to do that. I expect that they can simply manage the service in
>>> an appropriate manner to keep me paying them X per month. We have
>>> seen the failure of DKIM we do not want the Public SIP Telephony
>>> Network to end up like ..
>>>
>>> *From:[email-masked] <mailto:[email-masked]>
>>> [mailto:[email-masked]] *On Behalf Of *DOLLY, MARTIN C
>>> *Sent:* Thursday, June 06, 2013 5:05 PM
>>> *To:* [email-masked] <mailto:[email-masked]>
>>> *Subject:* Re: [stir] A 4474 that will work through SBCs
>>> (generally/potentially
>>>
>>> From:
>>> [email-masked]<mailto:[email-masked]>[mailto:[email-masked]]
>>> On Behalf Of Jean-Francois Mule
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 6 Jun 2013 23:02:56 +0000

I rarely agree with Paul, but yes

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 6, 2013, at 6:56 PM, "Paul Kyzivat" <[email-masked]> wrote:

> For PSTN to SIP, the sip side has nothing better to go on than what it was provided. So it seems the only option here is transitive trust.
> 
> Now consider a "trusted" PSTN source. It can't remain trusted if it permits spoofed IDs on its incoming SIP connections. So such a SIP-PSTN interconnect must not assert an ID for any call it gets from a sip source and can't verify.
> 
> So ISTM that in addition to a suitable mechanism, there is need for a certification process for PSTN providers that they are suitably verifying incoming sip calls.
> 
>    Thanks,
>    Paul
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 Jun 2013 19:13:42 -0400

> Since virtually no bad calls are SIP end to end, it would seem that we need something that lets us go SIP to PSTN to SIP, early on.

If virtually no bad calls are SIP the whole way, then identifying which calls are SIP the whole way will tell you when the calls are good. ;)

(ie, using an authentication mechanism which works when calls are SIP the whole way might not be such a bad thing... it just won't tell you when legacy-PSTN-based calls are also good)

That's all we were really going to accomplish anyway - identify good caller-ids, not identify bad ones.  By that I mean it's not like there was going to be a flag day when suddenly everyone everywhere switches to doing some new caller-id mechanism; so instead we'd only be able to identify legitimate caller-ids for a portion of the calls, and the rest would basically be "unverified" or whatever.  So only the very "good guys" are going to be using this mechanism at first for a while anyway, and they generally use SIP a lot already.

It might be reasonable to expect the adoption rate of a new caller-id auth mechanism to follow the adoption rate of SIP interconnection, at least within the US/NANP (which is what started this topic).

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Thu, 6 Jun 2013 20:35:33 -0400

The problem we're trying to solve has one end (the origination end) mostly on SIP and the termination end mostly on PSTN/2G/3G with, commonly, two or more transitions.

The origination end is mostly SIP because it's much much easier to manipulate the signaling.  The service providers that are tolerant of the problems are SIP service providers.  They are mostly non-certificated carriers, which means they have to go through someone else to get to the termination network, because nearly all of the interconnects today are SS7.  You often see 3 or more SIP providers, then an SS7 transition, then, increasingly, a conversion back to SIP, and finally the termination endpoint, which today is heavily weighted POTS or 2G./3G wireless, but increasingly is SIP based.  If the endpoint is enterprise, it's better.  It's getting to all SIP on the termination side quickly, but there is still an SS7 link between origination and termination.

We can't deploy today, but if we try to deploy, say next year, then we can't assume most carrier interconnect is SIP.  Wish it were true, isn't.  Increasingly, there is a SIP leg in the termination side, and I think if we make things work so we get that environment (SIP on origination, at least one SIP leg in termination, SS7 between origination and termination), we will largely address the problems.  It will get better as more legs migrate to SIP, but if it has to be SIP end to end before the problem is addressed, what we are attempting will be considered a fail.

If we make the mostly-but-not-all SIP scenario largely true, we will most likely also help the case where there isn't (yet) a SIP leg on the termination side, only because we will have enough disincentive in place so the problem sources will mostly be stymied.  If at least one SIP leg only accepts calls with a validated identity we can fix a lot of the problem.

So, there is a continuum:
If one leg on the origination side checks, we get the first real value, and it's substantial
If one leg on the termination side checks, and we have SIP interconnect to that point, we have more value
If one leg on the termination side checks, and it works across an SS7 interconnect, we have a great deal of value
If we get end to end checks, we get to where we want to be eventually

The longer it takes to deploy, the more SIP interconnects there are and the value of a mechanism that works around the SS7 interconnect fades.  We're really trying to make a really significant dent in the problem well before we expect that to happen, which is why I think having some mechanism to work around an SS7 leg is going to be important.

But, there is no doubt that if we just get one leg in the origination side to check, we get a big win.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 6 Jun 2013 22:38:28 -0400

My take is that the first SS7 carrier tends to be trusted (and trustworthy), and should be able to mark or drop bad-actor calls. (The former might involve a new calling party category. Or you could use the prison phone category, anticipating future residential address of the caller.)

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 05:29:54 +0200

On 6/7/2013 12:15 AM, Richard Shockey wrote:
> We have seen the failure of DKIM

Huh?  What failure?

DKIM isn't for end-users, so I really don't understand what you mean.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 10:35:01 +0000

> It might be reasonable to expect the adoption rate of a new caller-id auth mechanism to follow the
> adoption rate of SIP interconnection, at least within the US/NANP (which is what started this topic).

It's an (optimistic, still...) assumption you can probably make elsewhere as well. But, if as I would expect, this mechanism depends on the ability to "sign a number" within national numbering plans anyway, or maybe parts of these, the adoption rate (and success) of this would also follow the deployment of this capability nationally. This may significantly vary from country to country.  

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, June 07, 2013 1:14 AM
To: Brian Rosen
Cc: [email-masked]; DOLLY, MARTIN C; Richard Shockey
Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially

-hadriel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 7 Jun 2013 09:00:20 -0400

Yeah, that's "one leg on the origination side", and I agree with you.

"Drop" is what we're after, but at that point (just before diving into the SS7 network), we're talking about a certificated carrier who has restrictions on what calls he can drop, so regulatory action would be needed in most countries.  It might well be fairly forthcoming given the scale of the problems in many countries.  "Mark" may be challenging.  It might be possible to do something in the SS7 signaling that doesn't change a lot of hardware carriers will not invest in, but at the very least, you would have to upgrade software in the gateways.  The problem, ISTM, is that unless there is a SIP leg on the other side, there isn't any reasonable way to detect the mark and do something with it.  But, if there is a SIP leg, then we could do an out of band solution rather than mark the SS7 signaling.  That might be more palatable to the carriers who really don't want to make any investments in any part of the SS7 network.

Brian

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 7 Jun 2013 15:21:18 +0000

I do not believe we can add anything to ISUP

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 11:36:14 -0400

I was thinking of a codepoint for CPC, not an addition to the protocol.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 7 Jun 2013 15:46:11 +0000

Henning,

I chair the ATIS committee where the change would be made. I have an interim call on 6/17, and I can test the waters then.

Regards,

Martin

---

From: Michael Procter <[email-masked]>
Date: Fri, 7 Jun 2013 17:20:24 +0100

>> I do not believe we can add anything to ISUP

ISUP CLIs already come with a screening indicator.  From memory, you can
encode 4 meanings:
- Network provided CLI
- User Provided CLI - unscreened
- User Provided CLI - verified and passed
- User Provided CLI - verified and failed (often reserved for national use,
if I recall correctly).

When I last worked with ISUP (which was a while back), I think most
networks essentially used only value.  Whilst it sounds like this field
would be a good match for the problem, you may find fewer interop concerns
raised over introducing a new CPC value as you suggest.

Regards,

Michael

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 7 Jun 2013 16:29:36 +0000

These values are implemented as of  4E14 & 5E6

From: Michael Procter [mailto:[email-masked]]
Sent: Friday, June 07, 2013 12:20 PM
To: Henning Schulzrinne
Cc: DOLLY, MARTIN C; [email-masked]; Richard Shockey; Hadriel Kaplan; Brian Rosen
Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially

>> I do not believe we can add anything to ISUP
ISUP CLIs already come with a screening indicator.  From memory, you can encode 4 meanings:
- Network provided CLI
- User Provided CLI - unscreened
- User Provided CLI - verified and passed
- User Provided CLI - verified and failed (often reserved for national use, if I recall correctly).

When I last worked with ISUP (which was a while back), I think most networks essentially used only value.  Whilst it sounds like this field would be a good match for the problem, you may find fewer interop concerns raised over introducing a new CPC value as you suggest.

Regards,

Michael

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 12:50:15 -0400

> The origination end is mostly SIP because it's much much easier to manipulate the signaling.  The service providers that are tolerant of the problems are SIP service providers.  They are mostly non…

Yes, the origination and termination is SIP - even though 2G/3G the handset itself isn't SIP, but there's SIP in the termination carrier up to the MSC/CPE/ATA.  And for cases where the termination provider isn't SIP, there's absolutely nothing we can do for them, because no one's investing in new SS7 functions.

Regardless, the point I was trying to make in my previous email is the bad guys, or even the "pink carriers", aren't the ones we have to worry-about/handle supporting this mechanism, because by definition they're not going to use it.  Whether they go through SS7 or carrier pigeon doesn't matter.  All we can do is identify the good caller-ids from the good guys.  So my point was the good guys are using SIP more and more, including for interconnection.  

If we can get sufficient use/coverage such that unsigned national number caller-id's due to SS7 become marked as "unknown" or "unverified", then that incites the rest to go SIP.

> We can't deploy today, but if we try to deploy, say next year, then we can't assume most carrier interconnect is SIP.  Wish it were true, isn't.  Increasingly, there is a SIP leg in the termination…

OK, if you want to be realistic, here is realism: the IETF RAI area has never gone from BOF to published RFC in a year, afaik.  Martini was just slightly longer than a year.  So let's assume the best-case: it takes one year to publish this new caller-id thing.  Most of the big vendors won't start implementing anything until there's a published RFC.  Let's assume it takes them 6 months to get it into a GA release (it usually takes more).  Then the service providers have to start testing the new release, another 6 months. Now we're at two years.  Then assuming it all works well they schedule deployment for some 3-6 months after that.  That's all assuming you hit the timing right for each phase's window, which never happens.  Realistically, we're talking 3 to 4 years from now for the big carriers.  And that's probably being aggressive.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 7 Jun 2013 12:58:23 -0400

I can be optimistic, can't I?

Suppose it was 3-4 years.   I really doubt that we will have more than 50% SIP end to end (let's say originating SP to terminating SP) by then.

It's pretty clear that we all agree that the basic sign and check feature is the first thing we need to do.  

What we're discussing is whether a mechanism that helps get through non cooperating intermediaries is worth doing.

I think it is, especially if we can figure out how to make it relatively easy to deploy.

I will agree with you that if such mechanisms are delayed, or hard to deploy, that the value decreases.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 13:02:52 -0400

I'm not sure I understand the logic here.
Why would we trust a "not-evil" bit coming in from SS7/ISUP?
Why wouldn't all pink carriers just start setting that bit?

At some point you said we can trust the SS7 carrier, but really we can't - or rather, it's too late by then.  The pink carriers egress their calls on PRIs/etc. on gateways they own.  The next transit carrier has no idea if the transmitted CgPN is valid or not.
Did I miss something?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 7 Jun 2013 13:10:12 -0400

Turns out that the "pink carriers" don't own the PSTN interconnects by and large.  They are SIP only.  They pass calls to a certificated carrier who is actually pretty trustworthily mostly.  That isn't always true, but it's mostly true.

I'm still not sure we can get those carriers to implement a validity check and cause the SS7 gateways to set the not-evil bit, but it may be possible.

The out of band DB still seems to be a better solution but this could help.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 13:33:41 -0400

Hmmm... maybe I'm using a different definition for "pink carrier".  I was thinking a pink carrier was an origination or transit provider that doesn't care whether it's caller-id's are bogus or not.  Not because it's malicious or setting invalid caller-ids itself, but just because it receives it that way form its customers and doesn't know better or doesn't care so long as it gets paid.  I know some carriers like that, and they have PSTN gateways upstream.  As far as I know they're not "SS7 carriers" in that they don't have STPs and point codes - but they have SIP-PRI gateways, and their PRIs go to SS7 carriers.

Are you saying that those are the pink carriers, but that usually they've got SIP upstream to their next transit carrier; or are you saying those are the green carriers and the pink carriers are their customers, the ones setting bogus caller-ids on purpose?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Fri, 7 Jun 2013 13:49:56 -0400

Henning can tell us more, but I understand that at least in the U.S., most of the bad calls are coming from carriers that are not certificated, and are SIP connected to a certificated carrier.  They purchase numbers from that carrier.  They are SIP only.

Many of the certificated carriers currently do not check the validity of the calling party number for calls arriving on their wholesale side via SIP.  It's pretty difficult - the upstream service provider could have millions of numbers spread across all the rate centers the certificated carrier has service in.  Martin can speak to whether AT&T tries to do that.

I certainly do worry about a pink carrier with an SS7 connection.  There are some certificated carriers that provide such services and if we close off the SIP interconnect path, they may seek out the SS7 path.  That would be bad because then we have no green carrier before we get to SS7.  It may be that we can work out ways to encourage such carriers to migrate their customers to SIP trunks rather than PRI and then be in a place to fix the issues.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 14:37:01 -0400

The origin of the term "pink carrier" is in the email spam area, and is explained in

http://en.wikipedia.org/wiki/Email_spam

My take is that "pink carrier" refers to entities willing to host robocallers and other scum, rather than just carriers that don't validate. There's obviously a fluid boundary between having robocallers be part of your business plan and being insufficiently diligent.

Henning