Re: [stir] current draft charter

[Michael Hammer <[e-mail]>]

All,

I am following the thread and trying to grasp the heart of the matter.

First point:  This is about E.164 number delegation and proof of ownership.

So, I find much of the discussion that seems to rely on DNS structure or
Domain name structuring to be a distraction.
How you prove proof of ownership of a domain is a separate, albeit twin
problem.
But, I think that is out of scope.  I do not believe the answer here is to
ask my evil twin if he owns the E.164.

Second point:  The delegation of E.164 numbers down the tree inextricable
defines who owns the number, 
so any collection of certs into an authoritative repository MUST follow the
same path back up, or you lose sight of that ownership.
E.164 is already the hierarchy, so no second hierarchy is needed.
The recipient of a number block or an individual number may need to receive
the private key, 
else the carrier signs and inserts the signature on the path out from that
user.
(Note, still need to determine how many bytes constitute the signature such
that it fits into an existing SS7 parameter.
Perhaps the answer is to include an indicator in SS7 that the gateway to SIP
must perform the signature outbound.
But, that may limit this to a single hop, else need to trust follow-on SS7
networks to sign properly, but that may be acceptable.)

Third point:  The called party needs to unequivocally know how to validate
an assertion and who to go to for the inputs to perform that validation.
The how should be defined by the RFC, but the who ultimately depends on the
root of each E.164 country code (see point 2).
If the DNS is involved, I think that there is an IAB draft/RFC that says the
DNS should not be used for all things.
So, it is likely that the called party search would start with a well-known
URI to the CC authority, communication to which could be secure, 
who could then point to one or more authoritative services, depending on how
the out-sourcing is done, 
who have the official cert associated with the official delegation of E.164
number blocks or numbers.

This seems to be a parallel to the number portability databases, except that
one is now looking for a cert rather than a route to the serving carrier.
I am not suggesting that the NP databases be used, as this could be
orthogonal to that.

Doing a search based on using the E.164 as an index should not be an issue, 
since in many cases a 10k block of numbers may point to a single cert.
In those cases where portability occurs and single numbers have a different
cert, 
the database could have an indicator of which 10k blocks require full E.164
search to be performed. 
(For international, blocks are defined by how many leading digits are used.)

Fourth point:  Lastly, so the called party has all the elements from the
signaling with which to validate the signature, 
the RFC needs to specify what elements are prohibited from changing
end-to-end.
Given that some of the existing parameters do change in current systems, I
don't know how you get around doing one of the following:
- define new header that contains complete signature package that is added
by whomever does the signing.
- re-define existing headers to add the signature and restrict any
intermediary from modifying those values.
Seeing that the existing already have usage baggage, the first option seems
more likely to succeed.

Also, need to ensure that the SS7 network can carry elements E2E without
changes.
SS7 terminations may have to rely on the SIP-to-SS7 GW to perform
validation.
SIP terminations may have to rely on the SS7-to-SIP GW to generate
signatures.
SIP-SS7-SIP would be an issue given the "no change SS7" limitation.

Did I miss any requirements or constraints here?

Mike


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Henning Schulzrinne
Sent: Monday, June 17, 2013 8:14 AM
To: Hadriel Kaplan
Cc: [e-mail]; [e-mail]; Peterson, Jon
Subject: Re: [stir] current draft charter

I wouldn't be surprised if the large carriers cache all certs locally. For
+1, I'd suggest that's less than a TB, i.e., a single disk, even if every
number has their own cert, rather than number ranges. They would then
subscribe to a notification service for any porting-related changes, given
that such changes affect a very small fraction of the numbers (quarterly
churn of mobile carriers is about 1-2%). This can all be done within the
carrier network, i.e., without affecting the external public data interface.

On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote:

> 
> On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" <[e-mail]>
wrote:
> 
>> The exact amount of tolerable delay is a very interesting dimension 
>> of this problem space. I suspect we have a considerable amount of 
>> time, given all the human expectations about both post-dial delay and 
>> the wait for someone to pick up after altering. I think it's enough 
>> time to perform some non-trivial operations.
> 
> I've been thinking about that and I'm not sure we actually have much time.
I've been looking at what the CNAM guys are doing, and at least one them
(used in a large mobile provider) goes so far as to sometimes skip it on the
INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the
delay.  I.e., they have us queue the INVITE while they retrieve the CNAM
info for the given caller-id, but if they take too long then we send the
INVITE and send their results separately afterwards in another message.
Another operator that uses private ENUM for CNAM querying also sets very low
timeouts on the query, and just don't provide a calling name if it times out
(ie., the INVITE gets sent on without it, and nothing updates it later).
> 
> Also, Brian at one point mentioned transit providers possibly doing 
> the verification check as well, and that might be difficult if it 
> takes non-trivial time I think, because one of the SLA measurements 
> they get ranked on is how fast they route their calls onward.  
> (Besides which they're never involved this type of stuff so I'd doubt 
> they'd start now anyway.)
> 
> Anecdotally, I find that intra-nation calls get to ringing stage much
faster than international calls, so people are probably ok with
international caller-id verification taking longer.
> 
> -hadriel
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> 

_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir