|
I don’t make that assumption at all. ENUM cannot be used
to establish any authoritative mapping of E.164 to domain. I fought that war
for 10 years and lost thank you. In addition I reject the assertion in the proposed charter that
private federations don’t scale. In fact they do and are widely deployed
among service providers who in fact self assert their authority over TN’s
based on their own knowledge of what TN’s they are authoritative for
and have access to the underlying national telephone numbering databases and signaling
mechanism. The charter does not make any mention of Local Number
Portability at all. This discussion of running code is irrelevant here and has zero
merit in this discussion. In fact a more simplistic approach to the
problem statement was developed by Asterisk years ago called DUNDI and though I
haven’t spoken to Mark Spencer and company in several years about this
subject, I don’t believe it deployed in any significant way. It’s a
form of DHT among trusted peers with self validation of the underlying TN’s.
It works. Fine. That is a private protocol deployed among private Asterisk
deployments. There is a ID lying around somewhere. My assertion still holds. Without meaningful cooperation of national
numbering authorities it is impossible to establish a chain of trust that can reliably
determine the domain of authority for a E.164 number especially in conditions
where the number is either disconnected or potentially ported. The validation scheme proposed is essentially it can successfully
make a PSTN call. Wow I’m impressed! Then what? My
assertion is that the charter has to reflect that there is no reliable chain of
trust or validation model for E.164 numbers and consequently assertion of E.164
numbers by domains relies on self validation. The central thesis of this
proposed charter is false, that you can authoratively validate a mapping
between E.164 and a domain. You want to call this SELF-verification involving PSTN reachability
fine. Then you would have a honest statement of what you propose to
develop. This is about “truth in protocol development” tm. From: Peter Musgrave
[mailto:peter.musgrave@xxxxxxxxxxxxx] Hi, I think the charter issue here is an assumption that number
ownership is established using ENUM. I agree with you comments about chains of
trust, certs etc. and that this is likely impossible but they are not the
mechanism being proposed in the charter. It states: "Some
validation protocols may be based on knowledge gathered around a An approach
which is given as a sample solution is in the vipr-overview doc. The fact that
there is running code shows the solution has some merit. Can you
please clarify what part of this approach you view as impossible? Thanks, Peter
Musgrave On Sun, Jul 4, 2010 at 4:48 PM, Richard Shockey <richard@xxxxxxxxxx>
wrote: Well folks can certainly do what they
want to do. And the IETF has a lamentable record of some protocols that
don’t accomplish much. But the core of this proposed WG is based on a
fallacy. ViPR cannot verify or authenticate the responsible party for a E.164
number. It is incapable of doing so since there is no possible administrative
chain of trust other than self assertion . Hence the possibility of
identity or number/session hijacking is very large. You have to have the
cooperation of the national numbering authorities or the issuer of the phone
number to authenticate who is the responsible party . ViPR doesn’t change
that problem either. This has been a well known problem in
SIP for some time and that was part of the difficulties that public ENUM had in
e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in
private trees BTW. Consequently I think this issue has to
be fully defined in the charter and I will gleefully anticipate what the
security considerations text will look like. The fact that there is CISCO running
code is utterly irrelevant. There is lots of bad code out there. I
understand the problem of how do you create SIP federations across domains
outside the scope of service providers, but without a comprehensive trust model
this is going to fail. I do understand that many folks don’t like
their voice service providers or PSTN that perpetuates the use of E.164 numbers
but this proposal is not going to solve that. IMHO in the absence of any rational
trust or security model you can certainly publish something as Informational
but getting something past the IESG is another thing entirely. From: Peter
Musgrave [mailto:peter.musgrave@xxxxxxxxxxxxx]
Hi
Richard, Clearly
we don't want to be trying to solve the impossible - that could take a really
long time. The
mechanism in the ViPR drafts seemed to be able to accomplish the "finding
the party responsible for a number" - and IIRC this is based on *running
code* in the Cisco IME. ViPR
is frankly not beautiful (in the way ICE is not beautiful) but I do think it
can solve a problem which needs to be solved. Hence I support it. Peter
Musgrave On
Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <richard@xxxxxxxxxx>
wrote: A
we already have centralized solutions for interdomain routing based on |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf