Re: [stir] current draft charter

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

-----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