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?
RS> Well I have to swap it from time to time with my NO PRI hat. I'm still
trying to kill it off SS7 if someone will let me put metadata in ENUM
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.
RS> There is a reasonable trust model in the PSTN that relies on several
factors ..first the regulatory structure that says "you will route e164
transactions by law if you are a licenced carrier" and access to the root
numbering structures and databases which in North America are the LERG and
the NPAC GTT etc. You can determine who is the responsible carrier of record
for nearly any E.164 number out there. You just have real trouble
determining who was issued that number.
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.
RS> You cannot authoritatively determine a binding between a phone number
and a consumer (domain) without access to the databases.
You make a phone call if it answers and you hopefully get a caller ID
hasn't been spoofed then maybe you are OK and maybe you hope the TTL is
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.
But the routing data aka the DPC's were updated to reflect those
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
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
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.
Solution rewrite the charter to note that fact that this is, in fact,
"best efforts" only, "full disclosure" or "caveat emptor" to be
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.
RS> for the 352nd time you don't own E.164 numbers. They are not property by
RS> Well this could go on forever. My point is still that the charter as
written implies a service level and trust binding that unrealistic and what
is proposed is essentially a "best efforts" service. Ok there is nothing
wrong with that. TCP? The underlying DHT technology here has been
demonstrated to work in the past but to imply that ViPR is some way cool new
new thing I'm going to rely on just because it made a successful PSTN call
with a ill determined TTL binding .. please.
Ietf mailing list