Re: [stir] current draft charter

["Richard Shockey" <[e-mail]>]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Michael Hammer
Sent: Monday, June 17, 2013 12:04 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [stir] current draft charter

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.

[RS> ]  I was waiting for that little subject to come up. :-)   Personally I
detest this draft since it was clearly designed as an anti 6116 statement.
Ive never liked it and personally I hope it is never published. 

Title           : Architectural Considerations on Application Features in
the DNS
	Author(s)       : Jon Peterson
                          Olaf Kolkman
                          Hannes Tschofenig
                          Bernard Aboba
	Filename        : draft-iab-dns-applications-07.txt
	Pages           : 37
	Date            : 2013-02-25

Abstract:
   A number of Internet applications rely on the Domain Name System
   (DNS) to support their operations.  Many applications use the DNS to
   locate services for a domain; some for example transform identifiers
   other than domain names into formats that the DNS can process, and
   then fetch application data or service location data from the DNS.
   Proposals incorporating sophisticated application behavior using DNS
   as a substrate have raised questions about the role of the DNS as an
   application platform.  This document explores the architectural
   consequences of using the DNS to implement certain application
   features, and provides guidance to future application designers as to
   the limitations of the DNS as a substrate and the situations in which
   alternative designs should be considered.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-iab-dns-applications

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-iab-dns-applications-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-iab-dns-applications-07



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.


RS> I wish to point out that reliance on 10K block delegations in most cases
is essentially a nonstarter for endless reasons in the US and is irrelevant
in other national jurisdictions.  



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