Re: [stir] current draft charter

[Brian Rosen <[e-mail]>]

This particular effort is aimed at trying to do something about robocalling, vishing and swatting in a relatively short time frame.  To many of us, that seems doable.

Re-doing how routing of telephone number based identities work is the charter of TERQ.  It probably can't be done relatively quickly, no matter what mechanisms are used.

Restricting charter is a time-honored way of getting stuff done.  I'll take that path without any qualms.  I'm not interested in re-doing routing of telephone number identities as part of this work.

The point of asserting that it takes someone like Neustar to handle a database like what is being described is that a DNS based tree doesn't map into the way number delegation works - so the entire tree has to be handled by one entity - you can't delegate part of it to someone else, especially when porting is considered.   I was trying to contrast that with the model I've described where cert delegation follows number delegation.  That doesn't require a monolithic database.

Brian

On Jun 13, 2013, at 12:39 PM, Richard Shockey <[e-mail]> wrote:

> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Brian Rosen
> Sent: Thursday, June 13, 2013 10:08 AM
> To: Wendt, Chris
> Cc: Dan York; Peterson, Jon; Hadriel Kaplan; [e-mail]; Dave Crocker;
> Henning Schulzrinne; Stephen Farrell
> Subject: Re: [stir] current draft charter
> 
> The IETF is starting a new effort on routing,  see the TERQ work.  If you
> have ideas on routing, that would be the place to bring them.
> [RS> ] 
> [RS> ]  Wait a second.. You are demonstrating a profound misunderstanding of
> what a service provider has in place or are capable of actually implementing
> within a reasonable time frame.  It is not utterly unreasonable to at least
> consider that the issues of number resolution for TN Source Authentication
> or Routing would be somewhat similar.  There is infrastructure and
> technology in place.  Dismissing that question out of hand is absurd.
> Frankly the way the IETF works these days the chances of TERQ actually
> deploying before the End of Ages is debatable.  You know the timelines as
> well as anyone ... 4 years for a RFC then 2 years for it to show up on
> carrier requirements, regression testing .. vendor selection.  Get a grip. 
> 
> 
> I think the problem we have here is trying to decide who is a "good guy".
> Most of the service providers who would would call "pink" in this context
> would claim they are good guys.  Trying to create a mechanism to separate
> good guys from bad guys is very hard.
> 
> I'm not sure why protecting TNs individually is more complex then the view
> you have of routing, especially because we have tried what you are
> suggesting, although we did not have DNSSEC.  Dealing with the privacy
> issues, just to start, would be the first real barrier.
> 
> Let's say we got beyond that.  We then need someone, probably someone like
> Neustar, to maintain a per country portion of the database.  How would it do
> that?
> 
> [RS> ]  OH PLEASE.. I love a good global domination strategy as much as the
> next red blooded capitalist but these endless references to ..."somelike
> NeuStar"  are becoming tedious and inappropriate. 
> 
> 
> Basically, every time a number was delegated, it would change the domain of
> the entry to reflect the delegation.  That could work.  What it means is
> that delegation of any kind has to be recorded in the new database.  If you
> note, certs follow delegation, with you inserting "domain" in the middle
> (domain follows delegation).  The twist is that instead of a 2nd level
> reseller issuing a cert to a 3rd level reseller, the 2nd level reseller goes
> to the new database and has them effectively do the same thing.   
> 
> Having databases that associate a domain with a TN might help things like
> finding a cert, but it doesn't affect the basic issue of how you avoid
> spoofing.  Do you think the approach we have suggested here (signing of
> From/To/Time/Session Id) with a cert traceable to the identity is
> appropriate?
> 
> If you are "simply" suggesting the cert is located via DANE in the domain of
> the caller, then for user@domain, I think we're probably saying the same
> thing.  Where we seem to differ is that you suggest we have a DNS entry for
> the TN that has the domain in it, and then you use that to find the cert
> used for signing.  In the basic case, we're suggesting a URI to the cert in
> the signaling, which seems simpler.  What matters however is how the DNS
> tree for the TNs is maintained.
> 
> So, my response is the same as I have given before: the privacy and
> operational issues of putting per TN information in the public DNS are
> overwhelming.  We have tried it, and it has failed.  
> 
> Unlike Hadriel, you really do want to disclose domain with TN.  That has
> been a non-starter for many carriers.
> 
> Brian
> 
> 
> On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" <[e-mail]>
> wrote:
> 
>> Hi Folks,
>> 
>> I believe it couldn't be a better time to start discussing public routing.
> While this is a little beyond the scope of protecting caller-id, I think the
> effort is highly complimentary, and solving both together will provide a
> better path to get things implemented in service provider networks.
>> 
>> IP communications is evolving whether you want to get on the train or not.
> I applaud Henning's efforts to push the ball forward.
>> 
>> Moving more to an internet model for routing is inevitable, IMHO.  There
> is questions about how relevant TN is or will be in the near future.  For
> the sake of having any chance of success, let's simplify the effort and
> focus on the future.  There will be a transition process to get there, no
> doubt, but let's focus on the end goal, and not focus on fixing problems of
> the past.  We are already in a world of multiple private peering
> arrangements, LCR, and managing multiple egress points anyway, so the
> transition should not be that difficult.
>> 
>> I believe a common routing mechanism for both user@domain and TN/e164
> based identities should be the focus.  Treat both as first class citizens
> for IP communications.
>> 
>> Use DNS and domain based routing for all.  Use DNSEC to validate and
> cryptographically associate TN/caller-id with a domain (for good guys) and
> do domain routing from there.  
>> Forget about trying to protect TN's individually, that is too complex.
>> 
>> It's up to the consumer service providers to enforce and block bad things
> from bad domains.
>> It's up to wholesale/trunking providers to allow customers to assert their
> own domain, or be responsible for asserting domains on their behalf at the
> risk of being considered a "bad guy".
>> 
>> This is high level, and perhaps a sunny day view of the world, but I don't
> think unrealistic.  Frankly, if there is any chance of a common federated
> communications system continuing to be relevant, I believe a simple approach
> that matches the internet model is the only choice.
>> 
>> You should see more concrete opinions from Comcast in the future, but I
> wanted to take the opportunity to express these thoughts and would love
> feedback on why this should or should not be the model going forward.
>> 
>> If there is agreement, I believe some of this should be addressed in the
> charter, because I think some of the assumptions may not enable this path. 
>> 
>> -Chris
>> 
>> 
>> 
>> 
>> On Jun 13, 2013, at 8:51 AM, Dan York <[e-mail]> wrote:
>> 
>>> Hadriel,
>>> 
>>> On 6/12/13 5:38 PM, "Hadriel Kaplan" <[e-mail]> wrote:
>>> 
>>>> That begs the question of what issues you think made Public ENUM 
>>>> fail, and why we won't hit the same issues in whatever model we choose.
>>> 
>>> Since you addressed this question to me, I feel compelled to 
>>> answer... but in the meantime both Brian and Jon have given much more 
>>> detailed answers with which I mostly agree.
>>> 
>>> I saw security/privacy issues as the main issues that made Public 
>>> ENUM not work, i.e. Brian's points 4, 5 and 6:
>>> 
>>>> 4. Any public database that was able to show any information about a 
>>>> telephone number was considered a privacy issue, requiring a lot of 
>>>> "sign off", which never happened.
>>>> 5. Everyone objected to being able to determine what numbers were "live"
>>>> 6. Carriers objected to a public database that told competitors what 
>>>> numbers they controlled
>>> 
>>> 
>>> The potential for spam was also high.  Five or six years ago there 
>>> was at least one tool circulating around that would walk an ENUM 
>>> tree, generate a list of all potential phone numbers and then send 
>>> SIP INVITEs to all of those numbers.  I remember either seeing a 
>>> video or reading about how someone did this with all the public ENUM 
>>> numbers published for Germany (at that time). So using Public ENUM 
>>> could be a fantastic way to potentially get yourself on the calling lists
> for telemarketers.
>>> 
>>> Ideally, I think a public service *would* be a useful way to enable 
>>> ubiquitous usage. I'm just not sure how to get there without also 
>>> opening a solution up to these same kind of security/privacy issues.
>>> 
>>> Dan
>>> 
>>> --
>>> Dan York
>>> Senior Content Strategist, Internet Society
>>> [e-mail] <mailto:[e-mail]>   [phone]
>>> Jabber: [e-mail] <mailto:[e-mail]>
>>> Skype: danyork   http://twitter.com/danyork
>>> 
>>> http://www.internetsociety.org/deploy360/
>>> 
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>