Subject: [stir] STIR's basic operational model with SIP

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Aug 2016 08:11:31 -0700

Folks,

 From what I've been told offline -- but which is not explicitly 
documented in the specifications -- the intended operational framework 
for these specifications is amongst a relatively small set of service 
providers.  That is, the community of folk who are regulated and/or used 
to doing business with bilateral agreements.

This appears to produce an expectation of a service infrastructure for 
STIR that is not public.  That is, the query service for obtaining keys 
and key validation information will not be accessible to random users 
over the open Internet.

For the SIP-based portion of the validation service, this means that a 
caller or a callee with their own SIP clients will not be able to 
participate in the validation process.

If that is not correct, would someone please explain?

If it is correct, why is that an acceptable operational choice for a SIP 
service?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 11:18:49 -0400

I think we believe that is where implementations will start, but not where we will end up.

Many of us want to get to the point where devices sign and check and carriers only delegate credentials.  Might take a while to do that.

To get rid of robocalling, larger carriers have to push down signing responsibility to smaller service providers.  If they don’t, then they will be left holding the bag when the authorities come.

All service providers can sign on behalf of their subscribers, but they may want to shed responsibility and liability by pushing that off to the subscriber.  But to get the whole system up and running, it will be the big guys doing it for a while.

So I think you got the “necessary” part, but not the “sufficient” part.

I certainly hope that SPs don’t strip the validation headers.   There are no protocol police however.

Brian

> On Aug 9, 2016, at 11:11 AM, Dave Crocker <[email-masked]> wrote:
> 
> Folks,
> 
> From what I've been told offline -- but which is not explicitly documented in the specifications -- the intended operational framework for these specifications is amongst a relatively small set of service providers.  That is, the community of folk who are regulated and/or used to doing business with bilateral agreements.
> 
> This appears to produce an expectation of a service infrastructure for STIR that is not public.  That is, the query service for obtaining keys and key validation information will not be accessible to random users over the open Internet.
> 
> For the SIP-based portion of the validation service, this means that a caller or a callee with their own SIP clients will not be able to participate in the validation process.
> 
> If it is correct, why is that an acceptable operational choice for a SIP service?
> 
> d/
> -- 
> 
>  Dave Crocker
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Tue, 9 Aug 2016 15:48:44 +0000

+1....ish.

Given the source of many calls (legitimate or otherwise) is call-centres, and in many jurisdictions these can & do push their CLIs into the network, for STIR to have any ability to indicate the trustworthiness of the CLI, the signing has to go back into the call-centre.  

As I said last week, my call-centre customers get their numbers both from me & third party providers...I can't attest to the veracity of the CLIs on a call-by-call basis to sign them at the first node in the public network, and likewise saying that call-centres have to use CLIs provided by a given service provider over trunks into that service provider breaks the business & regulatory model that the customer owns their number (or at least has right of use over), not the service provider.

For example, the outsourced call-centre that does our own outbound calling (with our number displayed) also processes outbound calls for a dozen large enterprises, presenting a relevant CLI on each call.  Or as another example an enterprise with a head-office and 100+ high street shops will have a single breakout into my public network and send the relevant CLI according to which shop/head-office extension placed an outbound call (& not all of those numbers will route back via my network).

So service provider signing will get the ball rolling and will continue to be suitable on the whole for residential and mobile, but for enterprise it's essential that the eventual model is to allow the enterprise to sign; and until then anyone refusing calls based on the CLI not being signed will throw away a lot of legitimate calls.

Cheers

Paul

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 09 August 2016 16:19
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] STIR's basic operational model with SIP

Brian

---

From: Richard Shockey <[email-masked]>
Date: Tue, 09 Aug 2016 12:25:18 -0400

+1 it has to start some where.  

The circles of trust start first with the circles of authority and then can be delegated as requirements dictate.  The integrity numbering plan is a direct and plenary responsibility of NRA’s period full stop. 

I’m less confident we will ever get to the device level..at least not for the foreeable future aka my lifetime. 

On 8/9/16, 11:18 AM, "stir on behalf of Brian Rosen" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 12:58:23 -0400

> I’m less confident we will ever get to the device level..at least not for the foreeable future aka my lifetime.

If the SPs have an incentive to *not* delegate then it will be very hard 
to get there.

OTOH, if they have an incentive then the chances are better.

Brian and Paul R outlined some possible incentives to delegate. That 
gives some hope.

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Tue, 09 Aug 2016 13:09:29 -0400

On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

RS> Not our concern.   Way beyond our scope of competence here. Don’t forget the NRA’s have the real “Maxwell’s Silver Hammer” and you can be sure they can use it if delegation or lack thereof is perceived to be anti competitive.    

    
    	Thanks,
    	Paul

---

From: Andy Hutton <[email-masked]>
Date: Wed, 10 Aug 2016 13:41:36 +0100

Also as Dave Crocker pointed out what happens at the callee is also
important if no validation is possible at the callee's device then surely
there is no real benefit to the consumer.

Regards
Andy

On Tue, Aug 9, 2016 at 6:09 PM, Richard Shockey <[email-masked]> wrote:

>
>
> On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     > The circles of trust start first with the circles of authority and
> then can be delegated as requirements dictate.  The integrity numbering
> plan is a direct and plenary responsibility of NRA’s period full stop.
>     >
>     > I’m less confident we will ever get to the device level..at least
> not for the foreeable future aka my lifetime.
>
> RS> Not our concern.   Way beyond our scope of competence here. Don’t
> forget the NRA’s have the real “Maxwell’s Silver Hammer” and you can be
> sure they can use it if delegation or lack thereof is perceived to be anti
> competitive.
>
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Aug 2016 09:02:03 -0400

I don’t think that is at all true.  If validation is done at, say a transit network interconnect, and the transit network refuses to accept the call without a valid signature (assuming it does not run afoul of its local regulations in doing so), then there is value to the consumer.  If the termination network does the same, value.  If the termination network modifies the signaling towards the consumer so that the display name is “suspicious call” or  “unknown caller”, that is of great value to the consumer.  If it offers an option to the consumer to send calls with bad signatures or no signatures direct to voicemail, that is of great value.

So, while I really, really do want to do the validation on the device (because the consumer will have more options available of that is what happens), I think the mechanism can help consumers way before it shows up on the device and the device is able to do something with it.

Brian

> On Aug 10, 2016, at 8:41 AM, Andy Hutton <[email-masked]> wrote:
> 
> 
> Also as Dave Crocker pointed out what happens at the callee is also important if no validation is possible at the callee's device then surely there is no real benefit to the consumer.
> 
> Regards
> Andy
> 
> On Tue, Aug 9, 2016 at 6:09 PM, Richard Shockey <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>

---

From: Andy Hutton <[email-masked]>
Date: Wed, 10 Aug 2016 14:11:34 +0100

OK understood but if the callee device or could be an enterprise network is
going to make decisions based on this don't we need to specify the
information/signalling on which they make that decision?

Andy

On Wed, Aug 10, 2016 at 2:02 PM, Brian Rosen <[email-masked]> wrote:

> I don’t think that is at all true.  If validation is done at, say a
> transit network interconnect, and the transit network refuses to accept the
> call without a valid signature (assuming it does not run afoul of its local
> regulations in doing so), then there is value to the consumer.  If the
> termination network does the same, value.  If the termination network
> modifies the signaling towards the consumer so that the display name is
> “suspicious call” or  “unknown caller”, that is of great value to the
> consumer.  If it offers an option to the consumer to send calls with bad
> signatures or no signatures direct to voicemail, that is of great value.
>
> So, while I really, really do want to do the validation on the device
> (because the consumer will have more options available of that is what
> happens), I think the mechanism can help consumers way before it shows up
> on the device and the device is able to do something with it.
>
> Brian
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Aug 2016 09:14:52 -0400

Maybe I don’t understand the question, but I certainly want to see the Identity header and the JWT sent to the device/enterprise.  I certainly hope the device/enterprise will have access to the PKI and OCSP service to validate.  Then it can decide what to do with the call.

If the network drops the call then clearly the enterprise can’t do anything.  If the display name is changed, maybe it could.

Brian

> On Aug 10, 2016, at 9:11 AM, Andy Hutton <[email-masked]> wrote:
> 
> OK understood but if the callee device or could be an enterprise network is going to make decisions based on this don't we need to specify the information/signalling on which they make that decision?
> 
> Andy
> 
> On Wed, Aug 10, 2016 at 2:02 PM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 10, 2016, at 8:41 AM, Andy Hutton <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Wed, 10 Aug 2016 13:53:06 +0000

I’d agree here.

At the originating/signing end, there are good reasons to involve the enterprise (if not initially, then certainly as a longer term solution).

At the terminating/checking end, I don’t “get” what having an enterprise do their own checking gains, compared to it happening as a service in the network.  I’m not philosophically opposed, just don’t see the benefit.

(Incidentally, although transit networks could do the checking, I see it more occurring at the terminating end.  The terminating network owns the commercial relationship with the end customer that’s being inconvenienced by nuisance calls; it’s they that can derive commercial/public-policy gain or make their relationship more “sticky” by helping prevent these)

Cheers

Paul

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 10 August 2016 14:15
To: Andy Hutton
Cc: IETF STIR Mail List; Paul Kyzivat; Richard Shockey
Subject: Re: [stir] STIR's basic operational model with SIP

Brian

On Aug 10, 2016, at 9:11 AM, Andy Hutton <[email-masked]<mailto:[email-masked]>> wrote:

Andy

On Wed, Aug 10, 2016 at 2:02 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think that is at all true.  If validation is done at, say a transit network interconnect, and the transit network refuses to accept the call without a valid signature (assuming it does not run afoul of its local regulations in doing so), then there is value to the consumer.  If the termination network does the same, value.  If the termination network modifies the signaling towards the consumer so that the display name is “suspicious call” or  “unknown caller”, that is of great value to the consumer.  If it offers an option to the consumer to send calls with bad signatures or no signatures direct to voicemail, that is of great value.

Brian

On Aug 10, 2016, at 8:41 AM, Andy Hutton <[email-masked]<mailto:[email-masked]>> wrote:

Regards
Andy

On Tue, Aug 9, 2016 at 6:09 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

        Thanks,
        Paul

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

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Aug 2016 10:00:48 -0400

I will give you an argument for checking at a transit network interconnect:

Today, the majority of robocalls are originated on a VoIP network, and terminated on a network that has some non SIP connection between that VoiP network and the termination network.  We’re rapidly changing that so that the interconnects will be sip, but there are still going to be too many non-sip interconnects in the time frame we could deploy stir.  If the transit network changed its interconnect agreements so that they stated on such and such a date, some percentage of calls it accepts must be validly signed, and it ratcheted up that percentage over time, we would cut out “bad” calls close to the source and not depend on a SIP call path all the way to the termination network.

I think that would be a reasonable, implementable, and meaningful deployment strategy.  It would force the “pink” service providers to clean up their act. 

Brian

> On Aug 10, 2016, at 9:53 AM, Rosbotham, Paul, Vodafone UK <[email-masked]> wrote:
> 
> I’d agree here.
>  
> On Aug 10, 2016, at 9:11 AM, Andy Hutton <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <[email-masked] <mailto:[email-masked]> on behalf [email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Aug 2016 14:01:36 +0000

There are three facets:

* checking

* marking (translating the checking result into something else, whether that's caller-ID-related information or some SIP header)

* call handling (call rejection, voice mail, etc.) based on either authentication status or call origin

Unless the terminating carrier performs all three or possibly checking and marking, the enterprise will need to do that, e.g., to implement a unauthenticated-to-voicemail or failed-to-reject policy. Since we currently don't have a good standards-based way to do marking (and it isn't clear that this offers significant value compared to just doing the checking again), I suspect that means that either carriers have to implement both checking and call policy, or the end system has to do both. Some policy options, such as routing to voicemail, seem much easier to do at the enterprise level.

Henning

________________________________
From: stir <[email-masked]> on behalf of Rosbotham, Paul, Vodafone UK <[email-masked]>
Sent: Wednesday, August 10, 2016 9:53:06 AM
To: Brian Rosen; Andy Hutton
Cc: IETF STIR Mail List; Paul Kyzivat; Richard Shockey
Subject: Re: [stir] STIR's basic operational model with SIP

I’d agree here.

Cheers

Paul

Brian

Andy

Brian

Regards
Andy

        Thanks,
        Paul

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Wed, 10 Aug 2016 14:07:01 +0000

Ah – that’s where we differ (as in from country to country, rather than in opinion) – by the time we get the ducks in a line on STIR implementation on this side of the pond, the bulk of our interconnects probably will be SIP…. ☺

From: Brian Rosen [mailto:[email-masked]]
Sent: 10 August 2016 15:01
To: Rosbotham, Paul, Vodafone UK
Cc: Andy Hutton; IETF STIR Mail List; Paul Kyzivat; Richard Shockey
Subject: Re: [stir] STIR's basic operational model with SIP

Brian

On Aug 10, 2016, at 9:53 AM, Rosbotham, Paul, Vodafone UK <[email-masked]<mailto:[email-masked]>> wrote:

I’d agree here.

Cheers

Paul

Brian

Andy

Brian

Regards
Andy

On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

        Thanks,
        Paul

---

From: "Rosbotham, Paul, Vodafone UK" <[email-masked]>
Date: Wed, 10 Aug 2016 14:11:10 +0000

Fair point Henning.

I guess my focus is that most of the victims at present (here at least) are resi/mobile; not to say that enterprises don't receive nuisance calls but it's not those which are causing our government ministers' inboxes to fill up with irate letters.  I'm not saying I'm against enterprises doing their own checking, more that it's an edge case (unlike enterprises signing, which is absolutely core to the issues around nuisance calls).  Perhaps it's different in the US market.

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: 10 August 2016 15:02
To: Rosbotham, Paul, Vodafone UK; Brian Rosen; Andy Hutton
Cc: IETF STIR Mail List; Paul Kyzivat; Richard Shockey
Subject: Re: [stir] STIR's basic operational model with SIP

There are three facets:

* checking

Henning

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Rosbotham, Paul, Vodafone UK <[email-masked]<mailto:[email-masked]>>

I'd agree here.

At the terminating/checking end, I don't "get" what having an enterprise do their own checking gains, compared to it happening as a service in the network.  I'm not philosophically opposed, just don't see the benefit.

(Incidentally, although transit networks could do the checking, I see it more occurring at the terminating end.  The terminating network owns the commercial relationship with the end customer that's being inconvenienced by nuisance calls; it's they that can derive commercial/public-policy gain or make their relationship more "sticky" by helping prevent these)

Cheers

Paul

Maybe I don't understand the question, but I certainly want to see the Identity header and the JWT sent to the device/enterprise.  I certainly hope the device/enterprise will have access to the PKI and OCSP service to validate.  Then it can decide what to do with the call.

If the network drops the call then clearly the enterprise can't do anything.  If the display name is changed, maybe it could.

Brian

Andy

On Wed, Aug 10, 2016 at 2:02 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
I don't think that is at all true.  If validation is done at, say a transit network interconnect, and the transit network refuses to accept the call without a valid signature (assuming it does not run afoul of its local regulations in doing so), then there is value to the consumer.  If the termination network does the same, value.  If the termination network modifies the signaling towards the consumer so that the display name is "suspicious call" or  "unknown caller", that is of great value to the consumer.  If it offers an option to the consumer to send calls with bad signatures or no signatures direct to voicemail, that is of great value.

Brian

Regards
Andy

    On 8/9/16 12:25 PM, Richard Shockey wrote:
    > The circles of trust start first with the circles of authority and then can be delegated as requirements dictate.  The integrity numbering plan is a direct and plenary responsibility of NRA's period full stop.
    >
    > I'm less confident we will ever get to the device level..at least not for the foreeable future aka my lifetime.

RS> Not our concern.   Way beyond our scope of competence here. Don't forget the NRA's have the real "Maxwell's Silver Hammer" and you can be sure they can use it if delegation or lack thereof is perceived to be anti competitive.

        Thanks,
        Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Aug 2016 14:18:39 +0000

Don't know about telemarketing-style nuisance calls (although I have been offered cruises on my FCC work phone...), but TDOS is a big issue for healthcare and hospitality companies. Also, financial institutions would benefit from knowing whether the claimed number is real. They wouldn't reject unauthenticated calls, but would apply different customer validation procedures, such as warning the customer service representative or having fraud control monitor the interaction in real-time.

________________________________
From: Rosbotham, Paul, Vodafone UK <[email-masked]>
Sent: Wednesday, August 10, 2016 10:11:10 AM
To: Henning Schulzrinne; Brian Rosen; Andy Hutton
Cc: IETF STIR Mail List; Paul Kyzivat; Richard Shockey
Subject: RE: [stir] STIR's basic operational model with SIP

Fair point Henning.

I guess my focus is that most of the victims at present (here at least) are resi/mobile; not to say that enterprises don’t receive nuisance calls but it’s not those which are causing our government ministers’ inboxes to fill up with irate letters.  I’m not saying I’m against enterprises doing their own checking, more that it’s an edge case (unlike enterprises signing, which is absolutely core to the issues around nuisance calls).  Perhaps it’s different in the US market.

There are three facets:

* checking

Henning

I’d agree here.

Cheers

Paul

Brian

Andy

Brian

Regards
Andy

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Aug 2016 10:32:03 -0400

+1

If you count on the terminating provider to do the call handling, then 
the customer can only choose from among call handling policies that the 
provider offers. If the call handling is left to the customer then he is 
free to try all sorts of new innovative policies.

Also, the "send to voicemail" policy can only be done by the provider if 
the provider is managing the voicemail. (Conversely, if the provider 
*is* managing the voicemail, then *that* call handling policy needs to 
be handled by the provider.)

While we could find a way to do the marking, I agree with Henning that 
it is probably more straightforward to let the customer redo the 
checking. Certainly the provider could provide the marking as a service, 
and the customer can decide to use it or not.

For end user landline service handling by the provider is probably the 
only option. But end user mobile service, typically terminated by 
smartphones, is fertile ground for innovative new handling options by 
the end device.

	Thanks,
	Paul

On 8/10/16 10:01 AM, Henning Schulzrinne wrote:
> There are three facets:
>
> * checking
>
> * marking (translating the checking result into something else, whether
> that's caller-ID-related information or some SIP header)
>
> Unless the terminating carrier performs all three or possibly checking
> and marking, the enterprise will need to do that, e.g., to implement a
> unauthenticated-to-voicemail or failed-to-reject policy. Since we
> currently don't have a good standards-based way to do marking (and it
> isn't clear that this offers significant value compared to just doing
> the checking again), I suspect that means that either carriers have to
> implement both checking and call policy, or the end system has to do
> both. Some policy options, such as routing to voicemail, seem much
> easier to do at the enterprise level.
>
>
> Henning
>
> ------------------------------------------------------------------------
> *From:* stir <[email-masked]> on behalf of Rosbotham, Paul,
> Vodafone UK <[email-masked]>
> *Sent:* Wednesday, August 10, 2016 9:53:06 AM
> *To:* Brian Rosen; Andy Hutton
> *Cc:* IETF STIR Mail List; Paul Kyzivat; Richard Shockey
> *Subject:* Re: [stir] STIR's basic operational model with SIP
>
>
> I’d agree here.
>
>
>
> At the originating/signing end, there are good reasons to involve the
> enterprise (if not initially, then certainly as a longer term solution).
>
>
>
> At the terminating/checking end, I don’t “get” what having an enterprise
> do their own checking gains, compared to it happening as a service in
> the network.  I’m not philosophically opposed, just don’t see the benefit.
>
>
>
> (Incidentally, although transit networks could do the checking, I see it
> more occurring at the terminating end.  The terminating network owns the
> commercial relationship with the end customer that’s being
> inconvenienced by nuisance calls; it’s they that can derive
> commercial/public-policy gain or make their relationship more “sticky”
> by helping prevent these)
>
>
>
> Cheers
>
>
>
> Paul
>
>
>
> *From:*stir [mailto:[email-masked]] *On Behalf Of *Brian Rosen
> *Sent:* 10 August 2016 14:15
> *To:* Andy Hutton
> *Cc:* IETF STIR Mail List; Paul Kyzivat; Richard Shockey
> *Subject:* Re: [stir] STIR's basic operational model with SIP
>
>
>
> Maybe I don’t understand the question, but I certainly want to see the
> Identity header and the JWT sent to the device/enterprise.  I certainly
> hope the device/enterprise will have access to the PKI and OCSP service
> to validate.  Then it can decide what to do with the call.
>
>
>
> If the network drops the call then clearly the enterprise can’t do
> anything.  If the display name is changed, maybe it could.
>
>
>
> Brian
>
>
>
>     On Aug 10, 2016, at 9:11 AM, Andy Hutton <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>     OK understood but if the callee device or could be an enterprise
>     network is going to make decisions based on this don't we need to
>     specify the information/signalling on which they make that decision?
>
>
>
>     Andy
>
>
>
>     transit network interconnect, and the transit network refuses to
>     accept the call without a valid signature (assuming it does not run
>     afoul of its local regulations in doing so), then there is value to
>     the consumer.  If the termination network does the same, value.  If
>     the termination network modifies the signaling towards the consumer
>     so that the display name is “suspicious call” or  “unknown caller”,
>     that is of great value to the consumer.  If it offers an option to
>     the consumer to send calls with bad signatures or no signatures
>     direct to voicemail, that is of great value.
>
>
>
>     So, while I really, really do want to do the validation on the
>     device (because the consumer will have more options available of
>     that is what happens), I think the mechanism can help consumers way
>     before it shows up on the device and the device is able to do
>     something with it.
>
>
>
>     Brian
>
>
>
>         On Aug 10, 2016, at 8:41 AM, Andy Hutton
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>
>
>
>
>         Also as Dave Crocker pointed out what happens at the callee is
>         also important if no validation is possible at the callee's
>         device then surely there is no real benefit to the consumer.
>
>
>
>         Regards
>
>         Andy
>
>
>
>         On Tue, Aug 9, 2016 at 6:09 PM, Richard Shockey
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         On 8/9/16, 12:58 PM, "stir on behalf of Paul Kyzivat"
>         <[email-masked] <mailto:[email-masked]> on behalf
>         of [email-masked] <mailto:[email-masked]>> wrote:
>
>             > The circles of trust start first with the circles of
>         authority and then can be delegated as requirements dictate.
>         The integrity numbering plan is a direct and plenary
>         responsibility of NRA’s period full stop.
>             >
>             > I’m less confident we will ever get to the device
>         level..at least not for the foreeable future aka my lifetime.
>
>         RS> Not our concern.   Way beyond our scope of competence here.
>         Don’t forget the NRA’s have the real “Maxwell’s Silver Hammer”
>         and you can be sure they can use it if delegation or lack
>         thereof is perceived to be anti competitive.
>
>

---

From: Andy Hutton <[email-masked]>
Date: Wed, 10 Aug 2016 15:37:51 +0100

On Wed, Aug 10, 2016 at 3:18 PM, Henning Schulzrinne <
[email-masked]> wrote:
>
> Don't know about telemarketing-style nuisance calls (although I have been
offered cruises on my FCC work phone...), but TDOS is a big issue for
healthcare and hospitality companies. Also, financial institutions would
benefit from knowing whether the claimed number is real. They wouldn't
reject unauthenticated calls, but would apply different customer validation
procedures, such as warning the customer service representative or having
fraud control monitor the interaction in real-time.

+1 and add Emergency Services to the list of callee's for which this
information is potentially very important.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 10 Aug 2016 14:54:30 +0000

>From a practical getting-started perspective I hope it is agreeable that originating carriers (not end points such as phones or PBXes) need to sign the calls and only because it's a lot less physical SIP-enabled things to touch and so the effort to reach a valuable critical mass of authentication actions should be less and faster.  And the termination side of the equation is the same.  I think this implies carrier-based certs, a relatively small number of them per carrier and maybe only a couple of CAs to start with.

It is interesting to contemplate how certs could be delegated to enterprises and other endpoints enabled with signing technology, and how to encourage them to sign.  Using only that approach I think it could be very difficult to achieve a critical mass of signed calls and I assume would take a longer time than starting with carriers. Also, since endpoints can mis-sign either through fault or intention, and that there are so many of them of varying brand and quantity, it will introduce signal noise.

I assume mobile devices may be more easily enabled (then enterprises) and we could expect most signing within 10 years (assuming we still have 2+ years of standards, development, testing, and deployment and the usual 4 to 6 year cycle of device upgrade/replacement).  I assume WebRTC will be more challenging with respect to adoption/usage.

I'm with Paul Rosbatham in that I'm not sure we as consumers really want or even benefit much from endpoint signing and interpretation.  I'm not fundamentally against it, but it introduces additional challenges, and I'm not able to easily foresee what the mish-mash of results of that approach will look like.

Since we think we can get anti-robocalling value from adding (variable) authenticity to calling numbers, and we want it sooner rather than later, I think you want the carriers managing the start-up of the technology and you want it to operate within the network (mostly) to start.

Pierce

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: August 10, 2016 9:19 AM
To: Rosbotham, Paul, Vodafone UK <[email-masked]>; Brian Rosen <[email-masked]>; Andy Hutton <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>; Paul Kyzivat <[email-masked]>; Richard Shockey <[email-masked]>
Subject: Re: [stir] STIR's basic operational model with SIP

From: Rosbotham, Paul, Vodafone UK <[email-masked]<mailto:[email-masked]>>

Fair point Henning.

There are three facets:

* checking

Henning

I'd agree here.

Cheers

Paul

Brian

Andy

Brian

Regards
Andy

        Thanks,
        Paul

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Aug 2016 11:08:56 -0400

+1

I think Henning pointed out the value for consumers of devices validating.

I think the advantage to devices and enterprises signing is relieving the carrier of liability, but I agree with you that we have to start with carriers signing and validating.

I also think your observations that it gets a lot simpler to deploy if there are only a few certs to issue is correct, although I wonder if it is really the right thing for carriers to share secret keys among all the replicated parts of their infrastructure.  It may be that a carrier gets a small set of keys that are used by a Sub CA the carrier operates to issue individual keys to each box that signs.

Since the key has to be associated with all the numbers the carrier is delegated, it is not entirely clear if you want one, or a bunch of keys per carrier.  

There isn’t any standards issue with any variation here.  It’s all deployment decisions, and so we don’t have to deal with those issues here or really in any other body.  It’s obvious that the carrier gets keys for numbers it has been delegated by the numbering authority.  How many keys it gets, and which keys go with which TNs is up to it.  What it does with them (use the keys directly to sign, or operate a CA that issues keys to the boxes that sign) is up to it.

Where it might get complicated is if the carrier ever obtains numbers in a resale arrangement with another carrier.  In those cases, it would get a cert from that carrier along with the numbers, and then has to use those keys (directly or indirectly) to sign for calls from those numbers.  If all of the numbers it signs for come from the NRA, it’s easy.

Brian

> On Aug 10, 2016, at 10:54 AM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> From a practical getting-started perspective I hope it is agreeable that originating carriers (not end points such as phones or PBXes) need to sign the calls and only because it’s a lot less physical SIP-enabled things to touch and so the effort to reach a valuable critical mass of authentication actions should be less and faster.  And the termination side of the equation is the same.  I think this implies carrier-based certs, a relatively small number of them per carrier and maybe only a couple of CAs to start with.
>  
> I’m with Paul Rosbatham in that I’m not sure we as consumers really want or even benefit much from endpoint signing and interpretation.  I’m not fundamentally against it, but it introduces additional challenges, and I’m not able to easily foresee what the mish-mash of results of that approach will look like.
>  
> From: Rosbotham, Paul, Vodafone UK <[email-masked] <mailto:[email-masked]>>
> From: Henning Schulzrinne [mailto:[email-masked] <mailto:[email-masked]>] 
> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Rosbotham, Paul, Vodafone UK <[email-masked] <mailto:[email-masked]>>
> From: stir [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Rosen

---

From: Richard Shockey <[email-masked]>
Date: Wed, 10 Aug 2016 15:52:26 -0400

Thank you Brian… That is exactly what some of us have in mind ..Call Validation Display Framework derived from the Network Validation process. 

http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,819/Itemid,261/

We can argue about whether the validation should be done at the device or within the network, but the consumer need to see what is going on. 

From: Brian Rosen <[email-masked]>
Date: Wednesday, August 10, 2016 at 9:02 AM
To: Andy Hutton <[email-masked]>
Cc: Richard Shockey <[email-masked]>, IETF STIR Mail List <[email-masked]>, Paul Kyzivat <[email-masked]>
Subject: Re: [stir] STIR's basic operational model with SIP

Brian

 

Regards

Andy

        Thanks,
        Paul