Re: [stir] Do we agree on the basics?

["Rosen, Brian" <[e-mail]>]

Inline
On Jun 19, 2013, at 10:22 AM, Dave Crocker <[e-mail]> wrote:

> On 6/19/2013 6:52 AM, Rosen, Brian wrote:
>> 5. We think we need two MECHANISMS, an in-band mechanism that has the
>> originating device or service provider signing information and
>> carries the signature in the signaling.  The other is some out of
>> band mechanism that involves some new database or service that gets
>> written by the originating device or service provider and checked by
>> some downstream entity.  The latter mechanism is needed to allow the
>> identity to be assured even if the information or signature from the
>> in band mechanism is lost (such as when the call goes through an SS7
>> hop).
> 
> 
> Good list.
> 
> I'd like us to explore #5 carefully.  Although it carries the usual appeal of flexibility. However beyon that intuitive appeal, it dramatically increases complexity and its viable usage is not at all obvious.  The motivating rationale in the last sentence sounds great, but that doesn't mean it's viable.
> 
> Some examples of questions that such an approach needs to answer:
> 
> 1. What does it do to overall design and operations complexity and cost?
Two mechanisms, got to be at least twice the cost

> 
> 2. What is a realistic estimate of the likelihood of major benefit; in other words, why should we believe it will help enough to warrant the added costs?
Because we want to solve the problem now, where essentially all calls go through an SS7 link.

> 
> 3. What are the added adoption barriers?
That depends on the solution.  There are several of them, for sure.

> 
> 4. What are the early-stage costs, such as when almost no one has it implemented?
> 
>   For example, the stated use is when the call request arrives without the signature information; this will look exactly the same as a call from a system that did not add the signature.  Initially the latter will be far, far more common than the former.  Almost no one will be signing.  Hence, the querying agent is going to be making unsuccessful alternative checks essentially every time.  Failure rates at that level discourage adoption.
For one thing the same is true for the in band mechanism.

Sure, there is a cost for the out of band mechanism.
It's mostly fixed cost, but there are always transaction volume related costs.  

Actually, some of us are worried that the problem of the out of band mechanism is that by the time we've deployed it, and sunk most of the cost, the problem goes away.  Others think that there will always be some barriers and the out of band mechanism has value for a very long time.

The costs are mostly the database itself, and the implementation in wherever it is done.  In EKR's idea, it's at the ends (device or services).  In the alternate idea I just described, it's in the gateways (or near them, a B2BUA could do it).

> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir