Subject: [dispatch] ViPR Charter V4- a suggestion

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

Hi all,

Here is a suggestion about changing the charter language which has been
labeled 'political' to one which is more mechanistic.

How do people feel about the paragraph below in place of the first two paras
of the V4 charter (reproduced below). I think it needs more polish - but the
idea is to not raise the issues of domains and ownership.

A secure call to a SIP endpoint requires a knowledge of the endpoints URI
and a shared secret. Each of these requirements has been an obstacle to
widespread generic SIP calling. SIP URIs are not generally published or
easily discoverable and there is no general mechanism for setting up
security credentials in wide-spread use. Many SIP devices are also reachable
by a PSTN number through a PSTN-SIP gateway. This allows SIP devices to both
make and receive PSTN calls. The ViPR WG will develop a peer-to-peer
mechanism which allows SIP endpoints to assert a relationship with PSTN
numbers. Other SIP endpoints in the P2P overlay can determine if their
calling destinations have an entity asserting a relationship with the target
PSTN number and then use an initial PSTN call to confirm/re-confim the
relationship. Issues relating to whether the first PSTN call is an isolated
call or can be escalated to a direct, secure peer-to-peer SIP call will be
investigated by the working group. Subsequent calls within some reasonable
time scale can then be made directly using SIP.

Peter Musgrave

Existing first two paragraphs:

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, thus DNS lookups are not sufficient. Other approaches
such as public ENUM are not sufficient due to lack of widespread
deployment for non-technical reasons - i.e., the involvement of
government and service provider administrative entities needing to
approve and populate the registries.  Private federations have been
established to workaround the issue, however, that solution is not
scalable. 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 develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. Validation protocols will be developed 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.

---

From: "Mohammad Al-Taraireh (maltarai)" <[email-masked]>
Date: Tue, 13 Jul 2010 09:40:08 -0500

Excellent now we are getting some where :-). I think that is a good
start. 

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Musgrave
Sent: Tuesday, July 13, 2010 8:20 AM
To: dispatch mailing list; Mary Barnes
Subject: [dispatch] ViPR Charter V4- a suggestion

Hi all, 

How do people feel about the paragraph below in place of the first two
paras of the V4 charter (reproduced below). I think it needs more polish
- but the idea is to not raise the issues of domains and ownership. 

A secure call to a SIP endpoint requires a knowledge of the endpoints
URI and a shared secret. Each of these requirements has been an obstacle
to widespread generic SIP calling. SIP URIs are not generally published
or easily discoverable and there is no general mechanism for setting up
security credentials in wide-spread use. Many SIP devices are also
reachable by a PSTN number through a PSTN-SIP gateway. This allows SIP
devices to both make and receive PSTN calls. The ViPR WG will develop a
peer-to-peer mechanism which allows SIP endpoints to assert a
relationship with PSTN numbers. Other SIP endpoints in the P2P overlay
can determine if their calling destinations have an entity asserting a
relationship with the target PSTN number and then use an initial PSTN
call to confirm/re-confim the relationship. Issues relating to whether
the first PSTN call is an isolated call or can be escalated to a direct,
secure peer-to-peer SIP call will be investigated by the working group.
Subsequent calls within some reasonable time scale can then be made
directly using SIP. 

Peter Musgrave

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Jul 2010 09:14:34 -0700

There's some good parts in this that perhaps we can figure out how to use but I don't think we should make this change exactly as proposed. 

If there are political parts of the current proposal,  I'm glad to make them more politically correct or whatever it is people want to fix them but I'm not understanding the reasons for removing theses two paragraphs. Is it the mention of public ENUM you are concerned about? It would be easy to rephrase that. 

I'm not at keen on the replacement paragraph - the big reasons why is for people who have not been following this list or deeply involved with RAI, it removed the whole big picture motivation of why we want this WG or what the problem is. More details inline. 

On Jul 13, 2010, at 5:20 , Peter Musgrave wrote:

> Hi all, 
> 
> Here is a suggestion about changing the charter language which has been labeled 'political' to one which is more mechanistic. 
> 
> How do people feel about the paragraph below in place of the first two paras of the V4 charter (reproduced below). I think it needs more polish - but the idea is to not raise the issues of domains and ownership. 
> 
> 
> A secure call to a SIP endpoint requires a knowledge of the endpoints URI and a shared secret. 

I know what you meant by the above sentence but recognize that it is very easy to endless argue about many of the words in that. What is a secure call? Is is possible to do without a shared secret? What and when is the knowledge required? all of this does not matter much to the work at hand but a sentence like that would cause a very long thread on the ietf@ietf mailing list.

> Each of these requirements has been an obstacle to widespread generic SIP calling. SIP URIs are not generally published or easily discoverable and there is no general mechanism for setting up security credentials in wide-spread use.

Again above  is arguable not true. You should ask Microsoft about the number of people using SIP URI - it's impressive. The lack of URI is not really the problem - if it were everyone would have a SIP URI that was the same as their email address and we would be done. 

> Many SIP devices are also reachable by a PSTN number through a PSTN-SIP gateway. This allows SIP devices to both make and receive PSTN calls. The ViPR WG will develop a peer-to-peer mechanism which allows SIP endpoints to assert a relationship with PSTN numbers. Other SIP endpoints in the P2P overlay can determine if their calling destinations have an entity asserting a relationship with the target PSTN number and then use an initial PSTN call to confirm/re-confim the relationship.

The above 2 sentence seem good and I like them. And I like the term "relationship" as a possible replacement for "responsible".  This seems like it helps fix parts of the second paragraph but does not get at any of the motivation in the first para. It would still need to introduce the validation concepts for the later paragraphs to make sense and I think it would need to specify the nature of the term "relationship" along the lines of "means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed."

> Issues relating to whether the first PSTN call is an isolated call or can be escalated to a direct, secure peer-to-peer SIP call will be investigated by the working group. Subsequent calls within some reasonable time scale can then be made directly using SIP. 

Not sure I really knows what that means given some of validation approaches that are possible. 

> Peter Musgrave

Cullen in my individual contributor role

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

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 18 Jul 2010 12:57:32 -0400

HI Cullen,

I don't have strong feelings about what I proposed - I was simply probing to
see if there was middle ground which avoided the tangle the list seemed to
get into over the issue of asserting ownership of a PSTN number. That notion
appeared to trigger a severe immune response in some. The kernal is the part
you seemed to find ok (the notion of asserting a relationship with a PSTN
number) - so maybe we can keep that.

I agree the preamble on publishing SIP URIs and secure calls is a quagmire
and I am happy to avoid it.

I think the main issue in the V4 first two paragraphs is the sentence:
"The VIPR WG will develop a peer to peer based approach to finding

communications."

This notion of 'responsibility' appears (to me) to have been the source of
angst. Perhaps it would suffice to use the 'assert a relationship' notion
here.

Re-reading the rest I don't find anything else I object to (but then I was
ok with the original text anyway).

Cheers,

Peter Musgrave

On Sun, Jul 18, 2010 at 12:14 PM, Cullen Jennings <[email-masked]> wrote:

>
> There's some good parts in this that perhaps we can figure out how to use
> but I don't think we should make this change exactly as proposed.
>
> If there are political parts of the current proposal,  I'm glad to make
> them more politically correct or whatever it is people want to fix them but
> I'm not understanding the reasons for removing theses two paragraphs. Is it
> the mention of public ENUM you are concerned about? It would be easy to
> rephrase that.
>
> I'm not at keen on the replacement paragraph - the big reasons why is for
> people who have not been following this list or deeply involved with RAI, it
> removed the whole big picture motivation of why we want this WG or what the
> problem is. More details inline.
>
>
> paras of the V4 charter (reproduced below). I think it needs more polish -
> but the idea is to not raise the issues of domains and ownership.
> >
> >
> and a shared secret.
> I know what you meant by the above sentence but recognize that it is very
> easy to endless argue about many of the words in that. What is a secure
> call? Is is possible to do without a shared secret? What and when is the
> knowledge required? all of this does not matter much to the work at hand but
> a sentence like that would cause a very long thread on the ietf@ietfmailing list.
>
> > Each of these requirements has been an obstacle to widespread generic SIP
> calling. SIP URIs are not generally published or easily discoverable and
> there is no general mechanism for setting up security credentials in
> wide-spread use.
>
> Again above  is arguable not true. You should ask Microsoft about the
> number of people using SIP URI - it's impressive. The lack of URI is not
> really the problem - if it were everyone would have a SIP URI that was the
> same as their email address and we would be done.
>
> > Many SIP devices are also reachable by a PSTN number through a PSTN-SIP
> gateway. This allows SIP devices to both make and receive PSTN calls. The
> ViPR WG will develop a peer-to-peer mechanism which allows SIP endpoints to
> assert a relationship with PSTN numbers. Other SIP endpoints in the P2P
> overlay can determine if their calling destinations have an entity asserting
> a relationship with the target PSTN number and then use an initial PSTN call
> to confirm/re-confim the relationship.
>
> The above 2 sentence seem good and I like them. And I like the term
> "relationship" as a possible replacement for "responsible".  This seems like
> it helps fix parts of the second paragraph but does not get at any of the
> motivation in the first para. It would still need to introduce the
> validation concepts for the later paragraphs to make sense and I think it
> would need to specify the nature of the term "relationship" along the lines
> of "means an administrative domain, which is at least one of the domains, to
> which a PSTN call to this phone number would be routed."
>
> > Issues relating to whether the first PSTN call is an isolated call or can
> be escalated to a direct, secure peer-to-peer SIP call will be investigated
> by the working group. Subsequent calls within some reasonable time scale can
> then be made directly using SIP.
>

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 18 Jul 2010 22:55:14 +0100

Hi Cullen, Peter, folks,
 MY strong immune reaction was to the first two paragraphs.

- The first sentence of the first paragraph is OK.

- First para, second sentence: ", thus DNS lookups are not sufficient".
I have no idea what this means. On first look it doesn't follow, and seems to be not true for at least some cases.

Many/most SIP addresses I have *ever* used have been of the form <bag-of-digits>*@<domainpart>, and if the SIP proxy
for domainpart recognises the digit string as a known userpart, what is the problem? It works for me. DNS lookups
work fine to get the server for the domainpart.

- First paragraph, third sentence: I don't see how public ENUM is "another approach"; another approach to what?
The rest of the sentence discusses the administrative load for public ENUM. Yes, it is hard to validate an E.164 number.
Frankly, if that makes ENUM untenable, then use e164.org and be done with it; that does have validation, but they only assume that one can answer a phone and goto a web page; no further protocol sauce required.
For a real alternative approach, there's always IMS (OK, that also specifies use of ENUM, but it sure is different from RFC 2543).

- First Paragraph, fourth sentence: To suggest that *all* ENUM-like systems are not scalable seems odd without further justification.
If this statement has any justification, why is it not in the charter text?

- First paragraph, final sentence: People use phone numbers already; I sure use them with SIP (to my provider's B2BUA -- not exactly a SIP service, so it works fine). So ... this Intro needs to spell out in a lot more detail what's the gap that this proposed WG needs to fill.
The "big picture" so far is a bit Bridget Riley.

To continue:
Given the text in the second paragraph, does this mean any one of my SIP providers is a "domain responsible for a phone number", because I can dial to that phone number via any of them? Whichever one I choose is an intermediary from my perspective. It sure has a "relationship" with that target phone number. The second paragraph third sentence (especially the "...at least one of the domains, ...") needs a LOT of work before its ready for prime time.

And so to the third paragraph:

Peter's comment on sharing a secret seems to be absolutely germane; it's the only way you're going to avoid a central system as timings (if at all realistic) and media fingerprinting are secrets shared between end points (and your friendly local Carrier, and anyone else who's listening, and anyone who processes either party's CDRs, and ...). Without shared secret knowledge, why should an end point trust an assertion from some random lawn mower man?

I remain to be convinced that a reasonable administrative association between a SIP domainpart and a PSTN number is feasible, at scale, on a dynamic basis, particularly if the domainpart is intended to include any intermediaries.
Nothing yet mentioned in the charter looks like it would work; it does look from later paragraphs like it envisages upgrades to a LOT of kit.

It would very good to find such an (unencumbered) scheme that doesn't require a lot of upgraded components, but this is a really hard problem.
I'm not alone in being skeptical; those skeptics seem to include folk who have suffered operational pain over a protracted period of life with phone number/server validation.
In short, just 'cos it's the Internet doesn't mean the problems go away.

I await enlightenment @ Maastricht (or at least some beers).

all the best,
  Lawrence

> I'm not at keen on the replacement paragraph - the big reasons why is for people who have not been following this list or deeply involved with RAI, it removed the whole big picture motivation of wh…
<BIG SNIP>