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

From: Mary Barnes <[email-masked]>
Date: Wed, 30 Jun 2010 10:24:01 -0500

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)
<[email-masked]> 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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Mary Barnes
>> Sent: Monday, June 28, 2010 8:38 PM
>> To: DISPATCH
>> Subject: [dispatch] VIPR - proposed charter version 3
>>
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 30 Jun 2010 10:24:51 -0500

Agreed - I will make that change in the version 4 of the charter.

Thanks,
Mary.

2010/6/30 Romascanu, Dan (Dan) <[email-masked]>:
> Hi Mary,
>
> I also think that listing the deliverables should be independent from mentioning the existing initial contributions. The existing contributions could be listed as well, but they should not preclude other contributions on the same items after the WG is formed.
>
> Regards,
>
> Dan
>
>
>> Sent: Monday, June 28, 2010 9:00 PM
>> To: DRAGE, Keith (Keith)
>> Cc: DISPATCH
>> Subject: Re: [dispatch] VIPR - proposed charter version 3
>>
>> Hi Keith,
>>
>> That's a valid concern and we can rewrite the deliverables as
>> functional descriptions as we have done for other WG charters
>> even in cases where documents existed (e.g., overload).  The
>> current text is trying to say that these documents map to
>> deliverables and can be used as WG documents, although as it
>> notes these should be considered starting points (i.e., it's
>> understood the proposed WG has change control), but certainly
>> the current text is somewhat misleading.
>>
>> Thanks,
>> Mary.
>>
>> On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith)
>> <[email-masked]> wrote:
>> > I have a major issue with including "which shall form the
>> bases of the WG documents" into the charter. To me this is
>> confusing the charter discussion with the working group that
>> might eventually result deciding what its deliverables, and
>> their contents, shall be.
>> >
>> > regards
>> >
>> > Keith
>> >
>> >> Sent: Monday, June 28, 2010 6:38 PM
>> >> To: DISPATCH
>> >> Hi all,
>> >> Below, please find version 3 of the VIPR proposed charter.
>> >> It's been updated to reflect ML feedback, in particular
>> VAP has been
>> >> added and clarifications have been made with regards to impacts
>> >> (i.e., none) on existing PSTN interfaces.
>> >>
>> >> Regards,
>> >> Mary
>> >> (DISPATCH WG co-chair)
>> >>
>> >> ============================================
>> >> VIPR Charter Proposal (Version 3)
>> >>
>> >> WG Name:  Verification Involving PSTN Reachability (VIPR)
>> >>
>> >> There are two globally deployed address spaces for communications
>> >> used by more than a billion people daily - phone numbers and DNS
>> >> rooted address such as web servers and email addresses. The
>> >> inter-domain signaling design of SIP is primarily designed
>> for email
>> >> style addresses yet a large percentage of SIP deployments
>> mostly use
>> >> phone numbers for identifying users. The goal of this
>> working group
>> >> is to enable inter-domain communications over the the
>> Internet, using
>> >> protocols such as SIP, while still allowing people to use phone
>> >> numbers to identify the person with whom they wish to communicate.
>> >>
>> >> 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. In this context, "responsible" means an administrative
>> >> domain, which is at least one of the domains, to which a
>> PSTN call to
>> >> this phone number would be routed. Once the domain responsible for
>> >> the phone number is found, existing protocols, such as SIP, can be
>> >> used for inter-domain communications.
>> >>
>> >> 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.
>> >>
>> >> The validation mechanism requires a domain to gather and maintain
>> >> information related to PSTN calls.  This information is
>> used by call
>> >> agents such as phones, SBCs and IP PBXs to route calls.
>> The WG will
>> >> define a client-server protocol between these call agents and the
>> >> entity within a domain that maintains the information.
>> >>
>> >> To help mitigate SPAM issues when using SIP between
>> domains, the WG
>> >> will define a mechanism to enable one domain to check that
>> incoming
>> >> SIP messages are coming from a validated phone number.  A phone
>> >> number is considered validated if it is coming from a
>> domain to which
>> >> the calling domain had previously successfully placed a
>> PSTN call.
>> >> The working group will define new SIP headers and option tags, as
>> >> necessary, to enable this.
>> >>
>> >> The essential characteristic of VIPR is establishing
>> authentication
>> >> by PSTN reachability when it is not possible to use a direct
>> >> reference to ENUM databases or other direct assertions of
>> PSTN number
>> >> ownership. Elements such as public ENUM easily coexist
>> with VIPR but
>> >> no direct interaction with ENUM will be required.  The
>> solution set
>> >> defined by this WG will be incrementally deployable using only
>> >> existing interfaces to the PSTN.  No changes will be required to
>> >> existing PSTN capabilities, no new database access is
>> needed nor is
>> >> any new support from PSTN service providers required.
>> >>
>> >> The problem statement and some possible starting points
>> for solutions
>> >> are further discussed in the following internet drafts which shall
>> >> form the bases of the WG documents:
>> >>
>> >> draft-rosenberg-dispatch-vipr-overview
>> >> draft-rosenberg-dispatch-vipr-reload-usage
>> >> draft-rosenberg-dispatch-vipr-pvp
>> >> draft-rosenberg-dispatch-vipr-sip-antispam
>> >> draft-rosenberg-dispatch-vipr-vap
>> >>
>> >> The working group will carefully coordinate with the
>> security area,
>> >> O&M area, as well as the appropriate RAI WGs such as sipcore and
>> >> p2psip.
>> >> _______________________________________________
>> >> dispatch mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/dispatch
>> >>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 30 Jun 2010 10:47:15 -0500

Hi Dan,

One of the starting points for this work is that more centralized
solutions to this problem have been defined (and implemented), yet
they have not been successful.  Per one of Christer's earllier
comments, we will add some text with reference to such and thus
substantiate why this group is focusing on a p2p based solution.

Thanks,
Mary.

On Wed, Jun 30, 2010 at 10:33 AM, Romascanu, Dan (Dan)
<[email-masked]> wrote:
> 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
>
>
>> From: Mary Barnes [mailto:[email-masked]]
>> Sent: Wednesday, June 30, 2010 6:24 PM
>> To: Romascanu, Dan (Dan)
>> Cc: DISPATCH; IETF-Discussion list
>> 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:
>> 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.
>>
>> >> number.
>> > 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
>> >
>> >

---

From: Mary Barnes <[email-masked]>
Date: Wed, 30 Jun 2010 11:21:22 -0500

Hi Roni,

Comments inline below and some snipping of the thread.

Thanks,
Mary.

On Wed, Jun 30, 2010 at 11:03 AM, Roni Even <[email-masked]> wrote:
> Mary,
> When I read the charter it is not clear why from the first paragraph you
> deduct the second paragraph.
> If the first paragraph will say
> " The goal of this working group is to enable inter-domain communications
> over the Internet, using protocols such as SIP, while still allowing people
> to use the called person assigned circuit switch phone number for
> identifying the person with whom they wish to communicate. "
> It may look clearer.
[MB] We could change "phone number" to "called person assigned circuit switch
phone number for identifying the person", but I think that "phone
number" is well
understood to be exactly what you want to describe it as.  [/MB]

>
> Still this is based on the assumption that using other ways to assign and
> authenticate SIP phone numbers using central databases is not catching up
> because the carriers object to implement it and not due to any other reason
> like preferences of enterprises IT to use PSTN for calls because of better
> quality of service and manageability.
[MB] I'm not certain (personally) that the latter preferences you note
are as prevalent as you might suggest. I would still contend that the
larger issue is the former. However, if other folks share this
concern, we can certainly add that as well - it reflects equally as
being a non-technical reason for widespread implementation [/MB]
> Roni Even
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Mary Barnes

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 3 Jul 2010 14:33:38 -0400

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: [email-masked] [mailto:[email-masked]] 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

Dan

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 03 Jul 2010 13:39:11 -0700

> works pretty well BTW and globally deployed.

$ host -t NAPTR 7.8.2.4.9.2.3.8.0.4.1.e164.arpa.
Host 7.8.2.4.9.2.3.8.0.4.1.e164.arpa. not found: 3(NXDOMAIN)

Until this request succeeds, I am supporting the creation of the ViPR WG.

>>> 'problem statement and some possible starting points for solutions'?

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 4 Jul 2010 16:48:45 -0400

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:[email-masked]] 
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 <[email-masked]> wrote:

-----Original Message-----

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Jul 2010 11:14:56 -0400

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:[email-masked]] 
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 <[email-masked]> wrote:

Hi Richard,

Peter Musgrave

-----Original Message-----

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Jul 2010 14:48:06 -0400

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.

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

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. 

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

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. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
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:
> 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.
> 
>  
> 
> certainly publish something as Informational but getting something past 
> the IESG is another thing entirely.
> 
>  
> 
> *From:* Peter Musgrave [mailto:[email-masked]]
> *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. 
> 
>  
> 

> 
>  
> 
> Peter Musgrave
> 
> On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On 
> Behalf
> Of Romascanu, Dan (Dan)
>  > From: Mary Barnes [mailto:[email-masked] 
> <mailto:[email-masked]>]
>  > <[email-masked] <mailto:[email-masked]>> wrote:
>  > >> From: [email-masked] <mailto:[email-masked]>
>  > >> [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Mary Barnes
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Jul 2010 21:27:01 -0400

Thank you Brother Conroy... this is a full IETF discussion since it does
involve the creation of a new working group that does not seem to understand
what is actually involved in E.164 validation.

I do understand what this is really about..how do we screw global voice
service providers since the IETF has not been able to convince normal folk
to use SIP URI's. 

A reasonable objective, but I haven't seen many SIP URI on the back of
plumbing or tree conservation trucks driving down my Reston VA neighborhoods
recently. HTTP URI's are another thing.

The real ultimate question is, can we, the SIP community, possibly learn to
live with E.164 in SIP in some rational manner? Phone numbers are not going
to go away as much as my dear friend Henry Sinnreich would prefer.

-----Original Message-----
From: Lawrence Conroy [mailto:[email-masked]] 
Sent: Monday, July 05, 2010 7:46 PM
To: Richard Shockey
Cc: Paul Kyzivat; DISPATCH
Subject: Re: [dispatch] VIPR - proposed charter version 3

Hi Richard, folks,
 [removing ietf-general as cross-posting this whole thread doesn't help,
IMHO]
I have remained silent so far, but just to clarify...
Richard is absolutely correct.
The comments on ENUM seemed to miss WHY public ENUM has been hard to roll
out.

Each country (or region) has its own idea of Eligibility criteria for ENUM
domain registration in its jurisdiction.
One thing they pretty much every one of the authorities agrees on is that
*AT LEAST* there has to be a demonstrable proof that the domain owner is
provided (or provides) service via the associated E.164 number.

To say that this is a challenge to arrange cheaply or simply (or at all)
is an understatement. Trust me; I know to my cost, as does Richard.

Even that does not demonstrate that a value published in an ENUM domain
MUST be, by some guarantee, always tied to that domain and its associated
E.164 number. If I own a domain, I can provision what I like in that domain.

The validation "hook" is tied some way to the numbering authority for E.164
numbers in a particular jurisdiction, and there IS no validation authority
that ties a SIP URI to an E.164 number.

In private ENUM clouds, carriers "know their own" and trust partner carriers
(at least partially). That's a set of contractual agreements, nothing more.

The real question you have to ask is: can you gain access to the basic
information on which the private ENUM domains provisioning is based?
If you are part of that federation, then yes (at least you can query the
private ENUM tree).
If you are outside that federation, then no protocol magic is going to
change that fact.

Sorry for the long post, but it isn't a protocol issue; that well be
LDAP (or something that scales). It's an operational and contractual
agreement between CSPs, and last I heard that was not an IETF topic.

all the best,
  Lawrence

On 5 Jul 2010, at 19:48, Richard Shockey wrote:
> my assertion is that any authentication of the
> circumstances.

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Jul 2010 09:28:30 -0500

On 7/6/10 7:20 AM, Peter Musgrave wrote:
> From my perspective what this is really about is the ability for me to 
> have interoperable ad-hoc video calls between businesses which can be 
> established via SIP with a "good enough" level of authentication and 
> security.

You're looking in the wrong place, then.

The problem is that VIPR really provides something more like "random 
failure surprise," as some portion of the call attempts must go over the 
(non-video-capable) PSTN. The user doesn't have any idea about, or 
control over, when this will happen. So while it might be something you 
could use for personal purposes -- where frequent video call setup 
failures would be okay -- I doubt it's a viable video solution in a 
business environment. To run a business, you need something better than 
"random failure surprise".

/a

---

From: Peter Musgrave <[email-masked]>
Date: Sat, 3 Jul 2010 17:48:43 -0400

Hi Richard,

Peter Musgrave

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 5 Jul 2010 09:14:56 -0400

Hi,

Thanks,

Peter Musgrave

On Sun, Jul 4, 2010 at 4:48 PM, Richard Shockey <[email-masked]> wrote:

> lamentable record of some protocols that don’t accomplish much. But the core
> 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.
>
>
>
> that many folks don’t like their voice service providers or PSTN that

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Jul 2010 13:42:50 -0400

Richard,

	Thanks,
	Paul

Richard Shockey wrote:
> lamentable record of some protocols that don’t accomplish much. But the 
> to authenticate who is the responsible party . ViPR doesn’t change that 
> problem either.
> 
>  
> 
> doing very well BTW as a SS7/TCAP replacement however in private trees BTW.
> 
>  
> 
> fail.  I do understand that many folks don’t like their voice service

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 6 Jul 2010 08:20:46 -0400

Hi,

>From my perspective what this is really about is the ability for me to have
interoperable ad-hoc video calls between businesses which can be established
via SIP with a "good enough" level of authentication and security.

ViPR appears to be the best candidate at this point. It has the advantage
that it is self-contained and not reliant on any centralized mechanism. It
is clearly not perfect and there will be issues which need careful
consideration (including some of the security issues you have raised w.r.t.
call id spoofing, number migration etc.).

Is there a specific disclaimer you would like to see added to the charter so
these limitations are clearly set forth in the WG definition or is your
objection irreconcilable?

Regards,

Peter Musgrave

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Jul 2010 10:39:35 -0500

On 7/6/10 10:00 AM, Peter Musgrave wrote:
> Yeah. Sigh.
>
> I guess the issue then becomes whether this is enough of a step in 
> right direction that it can be built on - and whether it's worth the 
> effort.
>
> Cullen/Jonathan - can you speak to any of the operational issues 
> w.r.t. 'failure surprise' in the existing implementation?

Well, to be clear, with voice communications, you don't end up with 
"random failure surprise". You end up with "random quality surprise". 
Some of your voice communications go over whatever codec your device 
uses for VoIP, which is probably a nice broadband codec. But some calls 
will randomly use the PSTN, with an 8 kHz sampling frequency and a 
notch-pass filter at 2600 Hz.

While that's kind of an unpleasant property, it's not enough to 
disqualify it from normal business use.

My point was that it's not a reasonable multimedia solution. If all 
you're looking for is feature parity with the PSTN, it's a passable 
solution, even if just barely.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Jul 2010 11:56:12 -0400

Speaking of ad-hoc video calls.

Side bar issue.. Has anyone figured out who to talk to at Apple about
FaceTime?  Granted Apple has had a few "issues" to deal with recently but
the silence on how they plan to publish their profile is deafening.

I call Steve's office if I have to ..but 

From: Peter Musgrave [mailto:[email-masked]] 
Sent: Tuesday, July 06, 2010 8:21 AM
To: Richard Shockey
Cc: Lawrence Conroy; DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

Hi,

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Jul 2010 13:06:42 -0400

Adam is entirely right here. The question is do you want to standardize such
a service in the IETF. "Best Efforts" is not a problem on the Internet in
general. After all about 14% of all international call traffic is now going
over Skype.

You simply have to make that clear from the outset which is why IMHO the
charter as it is currently written is unacceptable.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Roach
Sent: Tuesday, July 06, 2010 11:40 AM
To: Peter Musgrave
Cc: Cullen Jennings; DISPATCH; Richard Shockey; IETF-Discussion list;
[email-masked]
Subject: Re: [dispatch] VIPR - proposed charter version 3

/a
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 6 Jul 2010 11:00:52 -0400

Yeah. Sigh.

I guess the issue then becomes whether this is enough of a step in right
direction that it can be built on - and whether it's worth the effort.

Cullen/Jonathan - can you speak to any of the operational issues w.r.t.
'failure surprise' in the existing implementation?

Regards,

Peter Musgrave

On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach <[email-masked]> wrote:

> (non-video-capable) PSTN. The user doesn't have any idea about, or control
> over, when this will happen. So while it might be something you could use
> for personal purposes -- where frequent video call setup failures would be
> okay -- I doubt it's a viable video solution in a business environment. To
> run a business, you need something better than "random failure surprise".
>
> /a
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Jul 2010 13:24:00 -0400

> solution which we all know is impossible. 

Perhaps better terms can be found and used.

But the end effect is that the destination you reach using ViPR has the 
same assuredness of being who you thought it would be as an actual PSTN 
call has.

For the most part, that is a level of assurance that many people are 
comfortable with, even if we know that is not as reliable as most people 
think it is. And regardless of whether it is as good as people would 
like, it is as good as can be had in most cases with the current state 
of the art.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Jul 2010 22:26:46 -0600

The user surprise is problem is largely masked by the user preference problem so in practice it is not a big deal. 

Let me explain what I mean by this. I have a video phone on my desk and so does my boss and they are on the same "PBX" and can trivially do video between each other. However, when my boss calls the number of my video phone, he does not actually expect to get video. My preferences may have totally turned that off. I may have forwarded the phone to my cell phone. I may have just "muted" the camera because I am wearing a jacket and tie and would not want him to catch me in that. The call may go to voice mail because I was on another call. Users are not particularly surprised when the video is not there. Similarly, they are not very surprised when the audio quality is radically different than they might have hoped due to the other parties preference. My boss's phone and mine both do wideband audio but we are not surprised when we don't get that. Audio preferences included putting people on speaker phones, using just about mobile phone and so on, taking calls while riding a bike and so on.

But let's not get too wrapped up in this. This whole topic is a non issue with a validation scheme that transferred some random secret in the first second of the PSTN call then did real time validation followed by moving the call (still in first few seconds of the call) from the PSTN to the IP network. One can imagine how to insert this into the audio by using watermarking or by fingerprinting existing media. A validation scheme like this is much better than the start/stop time based one proposed in the current vipr drafts but unfortunately it requires changing something in the media path at both ends and doing that takes longer to deploy. So the current validation scheme is pretty easy to get rolled out as everything was already collecting CDR in some form but a media path validation scheme could work in real time instead of waiting to the end of the PSTN call to validate. 

On Jul 6, 2010, at 9:00 AM, Peter Musgrave wrote:

> Yeah. Sigh. 
> 
> I guess the issue then becomes whether this is enough of a step in right direction that it can be built on - and whether it's worth the effort. 
> 
> Cullen/Jonathan - can you speak to any of the operational issues w.r.t. 'failure surprise' in the existing implementation?
> 
> Regards,
> 
> Peter Musgrave
> 
> From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a "good enough" level of authentication and security.
> 
> 
> The problem is that VIPR really provides something more like "random failure surprise," as some portion of the call attempts must go over the (non-video-capable) PSTN. The user doesn't have any idea about, or control over, when this will happen. So while it might be something you could use for personal purposes -- where frequent video call setup failures would be okay -- I doubt it's a viable video solution in a business environment. To run a business, you need something better than "random failure surprise".
> 
> /a
> 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 22:00:44 -0700

> From: [email-masked] [mailto:[email-masked]] 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.

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

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

> evidence indicates a uphill battle.

-d

> >  > http://www.ietf.org/mail-
> archive/web/dispatch/current/msg02027.html
> >  >
> peer

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 8 Jul 2010 11:46:55 -0400

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
databases. :-) 

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.  

RS> You cannot authoritatively determine a binding between a phone number
and a consumer (domain) without access to the databases.

But the routing data aka the DPC's were updated to reflect those
transactions.

I disagree.

RS> for the 352nd time you don't own E.164 numbers. They are not property by
treaty. 

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Jul 2010 18:20:14 -0400

> and a consumer (domain) without access to the databases.

The point of ViPR is that the authoritative mapping as you've defined it 
just isn't necessary; a forward routability check is all that is really 
needed.

Indeed, let us look at email for a moment. How does one know that 
"[email-masked]" authoritatively maps to me? In reality the only 
authoritative source for this is the databases at jdrosen.net which 
contain credentials that are bound to me. However, those are 
inaccessible to the rest of the world. Instead, one can check if 
[email-masked] routes to me by sending me an email with some kind 
of secret, and if I can prove I know that secret, you know that I'm 
[email-masked]. This forward routability check is the foundation 
for vast amounts of web security and identity, and that same principle 
is applied here for phone numbers.

Do you argue that we should stop using these forward email routing 
checks in the web?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net