ietf
[Top] [All Lists]

RE: [dispatch] VIPR - proposed charter version 3

2010-07-08 00:01:16
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Richard Shockey
Sent: Monday, July 05, 2010 11:48 AM
To: 'Paul Kyzivat'
Cc: 'DISPATCH'; 'IETF-Discussion list'; 'Peter Musgrave'
Subject: RE: [dispatch] VIPR - proposed charter version 3

Paul of course I've read them, though the PVP document is uniquely
dense and gave me a headache. Security by ID Obscurity.

My assertion still stands. In the absence of any linkage in the PVP to
the E164 numbering authorities and or databases any assertion about
verification and validation of a E.164 is in essence self validation. 
The charter does NOT state that. My point is the proposed charter is badly

written and implies a trust model that does not exist.

I guess your "no-SS7" hat doesn't fit anymore?

That trust model which "does not exist" is exactly the trust model
that we all use, daily, whenever we dial the pizza joint across
the street, the paint contractor with the spiffy one-page advertisement
in the yellow pages, pay FedEx or the postal service to deliver
a package, or pay a shipper to send a crate full of Champagne
from France to some other country, or call the Sears & Roebuck 
catalog number give them our credit card and expect them to use
a shipper (FedEx/postal service/UPS/DHL) to send us the product.

I agree that trust model is imperfect.

But that trust model is what delivers almost all of the commerce
and business in the world.  To assert that this trust model "does 
not exist" is a false assertion.

You make a phone call if it answers and you hopefully get a caller ID
that
hasn't been spoofed then maybe you are OK and maybe you hope the TTL is
set
to some interval that doesn't cause number hijacking. But gee what
happens when the number is disconnected from the PSTN? Hummmm

Similar disconnections (and resales) of telephone numbers happen,
today, on the PSTN.  I dial a restaurant (now out of business) 
which has taken over the same physical location (oh my gosh, 
Identity Thieves!) and paid to acquire the previous restaurant's
phone number.  Other, non-restaurant businesses do similar 
things.  SBC bought the assets of AT&T including its brand name, 
doing something similar with the att.com domain itself and,
I'm sure, with its 800 services.

So, it's not as if querying SS7 would provide some magic sauce
to prevent the problem.  The problem is different, to be sure,
just as IP addresses, domain names, physical (street) addresses,
email addresses, telephone numbers, are not all quite exactly
"the same".  But each is considered an "identity" to a varying 
degree.

The use of the term validation and or verification here implies
authentication and my assertion is that any authentication of the
responsible domain for a E.164 number outside of the PSTN service
provider
or national numbering authority is not possible under the current
regulatory circumstances.  Consequently the charter implies an 
ability to develop a solution which we all know is impossible.

I disagree.

Solution rewrite the charter to note that fact that this is, in fact,
"best efforts" only, "full disclosure" or "caveat emptor" to be 
precise.

Once I know someone owned an E.164 and I can, afterwards,
do crypto to ensure I know I'm talking to the same entity -- that
is *far* more reliable than what occurs, today, on the PSTN.  The PSTN
where phone numbers are bought and sold willy-nilly.

I'm not saying it might not work. As I used to tell Mark Spencer about
DUNDI
it's a fine intra-domain PBX session routing protocol. Might work in
some
highly integrated industries like airlines, auto etc but the empirical
evidence indicates a uphill battle.

-d

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat(_at_)cisco(_dot_)com]
Sent: Monday, July 05, 2010 1:43 PM
To: Richard Shockey
Cc: 'Peter Musgrave'; 'DISPATCH'; 'IETF-Discussion list'
Subject: Re: [dispatch] VIPR - proposed charter version 3

Richard,

Have you actually read and understood the drafts that Jonathan
submitted
on ViPR? I don't see how you could make the assertions you are making
if
  you had.

      Thanks,
      Paul

Richard Shockey 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(_dot_)musgrave(_at_)magorcorp(_dot_)com]
*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 
<richard(_at_)shockey(_dot_)us
<mailto:richard(_at_)shockey(_dot_)us>> 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: dispatch-bounces(_at_)ietf(_dot_)org 
<mailto:dispatch-bounces(_at_)ietf(_dot_)org>
[mailto:dispatch-bounces(_at_)ietf(_dot_)org 
<mailto:dispatch-bounces(_at_)ietf(_dot_)org>]
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:mary(_dot_)ietf(_dot_)barnes(_at_)gmail(_dot_)com
<mailto:mary(_dot_)ietf(_dot_)barnes(_at_)gmail(_dot_)com>]
 > 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)
 > <dromasca(_at_)avaya(_dot_)com <mailto:dromasca(_at_)avaya(_dot_)com>> 
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: dispatch-bounces(_at_)ietf(_dot_)org <mailto:dispatch-
bounces(_at_)ietf(_dot_)org>
 > >> [mailto:dispatch-bounces(_at_)ietf(_dot_)org
<mailto:dispatch-bounces(_at_)ietf(_dot_)org>] 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
dispatch(_at_)ietf(_dot_)org <mailto:dispatch(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch(_at_)ietf(_dot_)org <mailto:dispatch(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/dispatch




---------------------------------------------------------------------
---

_______________________________________________
dispatch mailing list
dispatch(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf