RE: [dispatch] VIPR - proposed charter version 3

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

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:[e-mail]] 
Sent: Monday, July 05, 2010 9:15 AM
To: Richard Shockey
Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

 

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
PSTN call; for example, the ability to prove a call was received over
the PSTN based on start and stop times. Other validation schemes, such
as examining fingerprints or watermarking of PSTN media to show that a
domain received a particular PSTN phone call, may also be considered by
the working group. This validation will be accomplished using publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate.  The WG will select and
standardize at least one validation scheme."

 

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 <[e-mail]> 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:[e-mail]] 
Sent: Saturday, July 03, 2010 5:49 PM
To: Richard Shockey
Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list


Subject: Re: [dispatch] VIPR - proposed charter version 3

 

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 <[e-mail]> wrote:

A we already have centralized solutions for interdomain routing based on
E.164. its called ENUM in both its private and public instantiations. It
works pretty well BTW and globally deployed.

IMHO this charter is a non starter and should not be approved on the basis
of this statement alone.

"finding domains that claim to be responsible for a given phone number"

This IMHO is flat out impossible. Validating or authenticating an entity
that is "responsible for a phone number" is as bad as  " who is the carrier
of record" , is a massive rathole. Cullen and Johathan should know better.
Certs? LNP ?

We have this problem of E.164 validation all the time in SIP and its not
going to be solved in the IETF.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Romascanu, Dan (Dan)
Sent: Wednesday, June 30, 2010 11:33 AM
To: Mary Barnes
Cc: DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

It looks to me that one can imagine 'centralized' solutions which are
also based on reusing SIP related functionality developed in RAI. I
would rather not close such an option and allow the WG a window of
opportunity in which alternate solutions that could meet the same goals
can be presented.

Dan


> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: Wednesday, June 30, 2010 6:24 PM
> To: Romascanu, Dan (Dan)
> Cc: DISPATCH; IETF-Discussion list
> Subject: Re: [dispatch] VIPR - proposed charter version 3
>
> Hi Dan,
>
> The term peer to peer is intended to exclude mechanisms that
> would use a central repository for the information:  This was
> discussed in an earlier thread:
> http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html
>
> In one sense it is a solution, however, in another sense it
> is reusing SIP related functionality defined in RAI and thus
> is in a similar vein as specifying the use of SIP in a charter.
>
> Thanks,
> Mary.
>
> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan)
> <[e-mail]> wrote:
> >> The VIPR WG will address this problem by developing a peer to peer
> >> based approach to finding domains that claim to be
> responsible for a
> >> given phone number and validation protocols to ensure a reasonable
> >> likelihood that a given domain actually is responsible for
> the phone
> >> number.
> >
> > Hi,
> >
> > Clarification question. What exactly means 'peer to peer
> based approach'
> > and what kind of approaches are excluded by having this in
> the charter.
> > Does 'approach' mean solution? If so why does a specific type of
> > solution need to be agreed in the charter, while all we
> have at hand
> > at this point are individual contribution I-Ds that describe the
> > 'problem statement and some possible starting points for solutions'?
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Mary Barnes
> >> Sent: Monday, June 28, 2010 8:38 PM
> >> To: DISPATCH
> >> Subject: [dispatch] VIPR - proposed charter version 3
> >>
> >
>
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch

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