Subject: [stir] Comments on draft-peterson-secure-origin-ps-02

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 26 Sep 2013 21:42:55 +0000

I think this is a good document and should be adopted by the work group.

My comments:
Abstract
The sentence "However, interworking SIP with the
   traditional telephone network has ultimately reduced the security of
   Caller ID systems." implies that the interwork causes the problem.  That's not the case.  Perhaps something like "Unfortunately, the way SIP has been implemented, and the proliferation of SIP service providers who are not traditional telephony carriers has allowed unscrupulous callers to falsify calling party telephone numbers"

Get rid of "therefore" in "This document therefore examines the reasons…"

Introduction
The first two sentences both use "arises"; get rid of one of them

The goal of these mechanisms
   is to validate that originator of a call is authorized to use the
   From identifier.

is not true in the case of P-A-I.  P-A-I assumes From can be wishful thinking and provides an alternative to From to identify the caller

s/improve/improved/ in "little indication that it will be improve in the future"

The sentence "In particular, the interworking
   with different communication architectures (e.g., SIP, PSTN, XMPP,
   RTCWeb) breaks the end-to-end semantic of the communication
   interaction and destroys the identification capabilities.
"
doesn't work for me.  That isn't the reason we have the problem.  We have the problem with all SIP, and have had fewer issues with all PSTN.  The problem is the inability to trust that From is accurate and the inability to always have PAI, and have it be the desired TN.  You could get into middle boxes and how they break SIP identity (or for that matter PAI) here.

"   Furthermore, the use of different identifiers (e.g., E.164 numbers
   vs. SIP URIs) creates challenges for determining who is able to claim
   "ownership" for a specific identifier.
"
is also problematic because we have DNS based ways of determining who can claim domain based identifiers, but don't for TN based identifiers.
So, maybe "although domain based identifiers (sip:[email-masked]) may use DNS based approaches to determine who is able to claim "ownership" of the URI, telephone numbers do not have any similar mechanism defined".

Problem Statement
While I like the explanation of the problem, I find the section lacking an actual statement of the problem.  I would think we would want to carefully craft at least a paragraph of text that precisely defines what we are trying to do.

Use cases
In VoIP to VoIP, we have this fragment "a group of service providers
   that offer interconnected VoIP service exchange calls using SIP end-
   to-end, but may also deliver some calls via circuit-switched
   facilities, as described below."

The "but.." clause isn't true, those cases are handled by different sections.

In PSTN to VoIP, the note confuses me.  Is it saying an IP-IP call with an SBC looks like a PSTN-IP call?  Something else?  Dunno, but make it more clear.  

I worry a bit about this case because unless the PSTN exit point is a carrier delegated the TN, it can't be signed by the GW.

In VoIP to PSTN, I would appreciate flipping the diagram around so Alice is on the left.  The first intro paragraph matches the diagram and the heading in saying its a call from Alice on a VoIP phone to Carl on a PSTN phone.  But it then says Alice wants to know who she is talking to.  That's called party (destination) identity, not part of this work, so far.  I suspect you mean Carl wants to know who he is talking to.

In all of these diagrams and explanations, you assume one VoIP provider.  That limits the discussion of the solution space.  If there are more than one SPs in the SIP path, any of them can verify the signature, and that would be very helpful.  

Limitations
You describe PAI as being "where end-user devices cannot alter or inspect SIP messages" and then say "cannot offer any protection against identity spoofing by intermediaries or entities that allow end users to set the P -Asserted-Identity information".  Can't have it both ways, either end users can set it or they can't.  I think the problem is more that the network blindly trusts the From when setting PAI in too many cases; it does not verify that the From is correct, especially with enterprise customers who claim they need to assert any of their numbers.  I have no doubt there are networks that allow their customers to send a PAI, but I don't think it's very common.

I find the paragraph in SIP Identity that begins with "One of the main reasons that SIP deployments mimic the PSTN" not helpful.  The first part seems to set something up, but doesn't provide a rational I understand, and the latter part is true, but not germane to the problem.

It would seem to me that by the time you get to the discussion of SDP mangling, you should have said the work doesn't propose to do anything so stop MITM.  That may be problematic given recent developments, but it is where we are.

In "Public Key Infrastructure Developments" you have the first introduction of the delegation tree property of telephone numbers.  This is such a fundamental concept to the solution that I would prefer to find a way to introduce it earlier on it's own - the basic notion that in every country, numbers are delegated in a formal (or formal + informal) way, with a per-country root of authority.  You get to it later, but I found the first reference here to be underwhelming.  At the very least, supply a forward reference, but I'd prefer to actually introduce the idea earlier in the document.

In "Pervasive Nature of B2BUA Deployments", I think you should introduce the concept of a canonical TN.  Explain that there are many ways numbers are represented, but they are convertible to a canonical e.164.  If you didn't add a section, or change the title of this one, you could explain that one of the things B2BUAs do is rewrite numbers to mess with prefixes or add/subtract country codes. 

In "Relationship with number assignment and management" you don't cover number resell.  I would add text that explains that while the initial assignments usually are constrained by formal processes, often with regulatory imperatives, in some countries, reselling of numbers using less formal processes is permitted.  I might even observe that assignment is often in ranges, and also that an assignment to an enterprise looks like a resell.  I would also note in this section that the permitted spoofing cases really are another form of delegation.

Requirements

I think there are more requirements.  I think origination devices or service providers must be able to generate secure identities, and termination devices or service providers must be able to validate.

I think we want to have some requirement on efficiency  -- I want to be able to say things about length of signature chains in the solution.

I think there is a requirement to base credentials on national number delegation, and there is not a requirement for a golden root.

I think we have agreed to remove caller name from the current effort.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Thu, 26 Sep 2013 17:58:51 -0400

I really tried to get this done last week, but didn't make it, sorry.

Brian

On Sep 26, 2013, at 5:42 PM, "Rosen, Brian" <[email-masked]> wrote:

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Sep 2013 23:32:21 +0000

Thanks for these; a few notes below.

I'm planning to release the new version of this very soon that reflects
these changes and some other additions, so no one will be submitting
review comments that have been overcome by events.

Jon Peterson
Neustar, Inc.

>   Caller ID systems." implies that the interwork causes the problem.
>That's not the case.  Perhaps something like "Unfortunately, the way SIP
>has been implemented, and the proliferation of SIP service providers who
>are not traditional telephony carriers has allowed unscrupulous callers
>to falsify calling party telephone numbers"

I agree we need to be careful where we aim the blame-cannon, but aiming at
"SIP service providers who are not traditional telephony carriers" seems a
bit more damaging than just saying "interworking." Surely if those service
providers were not interworking, VoIP would not be contributing to the
problem of calling party number falsification on the PSTN - and many of
these interworking service providers are not responsible for generating
the calling party number passed to them. I had already reworked the text
of the abstract a bit already to be less SIP-specific at Hadriel's
request, but I'm having a hard time seeing how to improve this specific
statement. Suggestions welcome.

>Get rid of "therefore" in "This document therefore examines the reasonsŠ"

OK.

>The first two sentences both use "arises"; get rid of one of them

OK.

>is not true in the case of P-A-I.  P-A-I assumes From can be wishful
>thinking and provides an alternative to From to identify the caller

Right. So we'll say "to claim an originating identifier."

>s/improve/improved/ in "little indication that it will be improve in the

Check.

>doesn't work for me.  That isn't the reason we have the problem.  We have
>the problem with all SIP, and have had fewer issues with all PSTN.  The
>problem is the inability to trust that From is accurate and the inability
>to always have PAI, and have it be the desired TN.  You could get into
>middle boxes and how they break SIP identity (or for that matter PAI)
>here.

For the second point, we can say "interworking with different
communication architectures (...) and other forms of mediation." I would
say it is "a" reason we have the problem, even if it's not "the" reason. I
do think that "destroys the identification capabilities" was intended to
speak to the inability to trust that the From is accurate, in combination
with the point you raise on the next sentence.

>is also problematic because we have DNS based ways of determining who can
>claim domain based identifiers, but don't for TN based identifiers.
>So, maybe "although domain based identifiers (sip:[email-masked]) may
>use DNS based approaches to determine who is able to claim "ownership" of
>the URI, telephone numbers do not have any similar mechanism defined".

I can append that to the end. Will change "DNS based" to "certificate or
DNS-related," and add a "yet" to "telephone numbers do not."

>Problem Statement
>While I like the explanation of the problem, I find the section lacking
>an actual statement of the problem.  I would think we would want to
>carefully craft at least a paragraph of text that precisely defines what
>we are trying to do.

I am not sure it is essential to progress that we do this, as these sorts
of statements need to be heavily tooled and end up concealing as much as
they elucidate in my experience. Still, I'd be happy to look at any
proposed text.

>The "but.." clause isn't true, those cases are handled by different

The "but" clause is just saying that that is covered be a separate use
case in another section. I'll try to make that clearer

>In PSTN to VoIP, the note confuses me.  Is it saying an IP-IP call with
>an SBC looks like a PSTN-IP call?  Something else?  Dunno, but make it
>more clear.  

I think that note actually belongs in the IP-PSTN-IP use case. Someone
(probably me) likely cut-and-pasted it into the wrong section.

>I worry a bit about this case because unless the PSTN exit point is a
>carrier delegated the TN, it can't be signed by the GW.

Out-of-band would also be an option here, if Carl's device supported it,
say.

>In VoIP to PSTN, I would appreciate flipping the diagram around so Alice
>is on the left.  The first intro paragraph matches the diagram and the
>heading in saying its a call from Alice on a VoIP phone to Carl on a PSTN
>phone.  But it then says Alice wants to know who she is talking to.
>That's called party (destination) identity, not part of this work, so
>far.  I suspect you mean Carl wants to know who he is talking to.

I'll ask Hannes if he feels like rejiggering the ASCII art here. But yes,
more importantly, this text is discussing the connected identity use case,
which we do want to rule out here, so this text requires some major
surgery. I took a swing at that.

>In all of these diagrams and explanations, you assume one VoIP provider.
>That limits the discussion of the solution space.  If there are more than
>one SPs in the SIP path, any of them can verify the signature, and that
>would be very helpful.

Certainly these diagrams aren't meant to rule out the possibility that
there will be more than one VoIP SP, or more than one gateway, or anything
of the kind. I think these are atomic functional scenarios. We do want to
be explicit somewhere (not sure exactly where) that multiple parties in
the architecture could participate in the verification process. This also
touches on a larger question we need to explore about how much transitive
trust we imagine will be in the architecture - do we want to allow one SP
to delegate responsibility for verification to another SP, and if so, how
do we best reflect that in the solution?

>Limitations
>You describe PAI as being "where end-user devices cannot alter or inspect
>SIP messages" and then say "cannot offer any protection against identity
>spoofing by intermediaries or entities that allow end users to set the P
>-Asserted-Identity information".  Can't have it both ways, either end
>users can set it or they can't.  I think the problem is more that the
>network blindly trusts the From when setting PAI in too many cases; it
>does not verify that the From is correct, especially with enterprise
>customers who claim they need to assert any of their numbers.  I have no
>doubt there are networks that allow their customers to send a PAI, but I
>don't think it's very common.

There is now a whole section on PAI that will hopefully make its
properties a bit more clear in the document. To your specific initial
point, I will substitute for "end users" in the second phrase there
"untrusted entities."

>I find the paragraph in SIP Identity that begins with "One of the main
>reasons that SIP deployments mimic the PSTN" not helpful.  The first part
>seems to set something up, but doesn't provide a rational I understand,
>and the latter part is true, but not germane to the problem.

Personally, I think that paragraph captures a critical dimension of the
problem space. Reading it again, I don't sense a non-sequitur here, but
please do explain further if this really seems like a problem.

>It would seem to me that by the time you get to the discussion of SDP
>mangling, you should have said the work doesn't propose to do anything so
>stop MITM.  That may be problematic given recent developments, but it is
>where we are.

Not sure I agree: up front in this "Limitations" section, we're discussing
the intrinsic limitations with the existing methods, not the scope of the
proposed new work in the WG. We do say that later.

>In "Public Key Infrastructure Developments" you have the first
>introduction of the delegation tree property of telephone numbers.  This
>is such a fundamental concept to the solution that I would prefer to find
>a way to introduce it earlier on it's own - the basic notion that in
>every country, numbers are delegated in a formal (or formal + informal)
>way, with a per-country root of authority.  You get to it later, but I
>found the first reference here to be underwhelming.  At the very least,
>supply a forward reference, but I'd prefer to actually introduce the idea
>earlier in the document.

What may help here is that the former "Roadmap" section has been turned
(hastily) into a "Terminology" section and moved forward in the document,
and so there is now a terminology definition for the "Authority Delegation
Infrastructure" that readers will hit earlier. Even if what's in there now
isn't ideal, it could be a place for that to live. Workable?

>In "Pervasive Nature of B2BUA Deployments", I think you should introduce
>the concept of a canonical TN.  Explain that there are many ways numbers
>are represented, but they are convertible to a canonical e.164.  If you
>didn't add a section, or change the title of this one, you could explain
>that one of the things B2BUAs do is rewrite numbers to mess with prefixes
>or add/subtract country codes.

I think if we were going to introduce that somewhere, it shouldn't be in
this little subsection. I'll add a definition to the terminology section.

>In "Relationship with number assignment and management" you don't cover
>number resell.  I would add text that explains that while the initial
>assignments usually are constrained by formal processes, often with
>regulatory imperatives, in some countries, reselling of numbers using
>less formal processes is permitted.  I might even observe that assignment
>is often in ranges, and also that an assignment to an enterprise looks
>like a resell.  I would also note in this section that the permitted
>spoofing cases really are another form of delegation.

The text there is really "for example" text, but I can add a bit about
resellers and enterprises, just high-level text that isn't too
prescriptive.

>
>Requirements
>
>I think there are more requirements.  I think origination devices or
>service providers must be able to generate secure identities, and
>termination devices or service providers must be able to validate.

I don't think the current list of requirements is exhaustive by any means,
it's just what was captured very early on in this process.

I added a parallel "Generation" and "Validation" bullet here to start this
off.

>I think we want to have some requirement on efficiency  -- I want to be
>able to say things about length of signature chains in the solution.

Added.

>I think there is a requirement to base credentials on national number
>delegation, and there is not a requirement for a golden root.

Tried to get a starting bullet for this in there too.

>I think we have agreed to remove caller name from the current effort.

It is cut.

Thanks again!

---

From: Michael Hammer <[email-masked]>
Date: Mon, 30 Sep 2013 13:28:00 +0000

Brian,

These statements are a bit contradictory:
"I think we want to have some requirement on efficiency  -- I want to be
able to say things about length of signature chains in the solution.
I think there is a requirement to base credentials on national number
delegation, and there is not a requirement for a golden root."

What do you mean by "golden root"?

The root of trust here is the formal delegation from the national authority.
If that isn't golden, then you are sliding down a slippery slope.
If you want something more distributed, then you are going to create long
signature chains, which should be a concern.
Bottom line is that anyone in the world needs to know how to validate and
where to go to get trusted information to do that.
Trust gets diluted when the number of strangers involved goes up.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Thursday, September 26, 2013 5:43 PM
To: [email-masked] Mail List
Subject: [stir] Comments on draft-peterson-secure-origin-ps-02

My comments:
Abstract
The sentence "However, interworking SIP with the
   traditional telephone network has ultimately reduced the security of
   Caller ID systems." implies that the interwork causes the problem.
That's not the case.  Perhaps something like "Unfortunately, the way SIP has
been implemented, and the proliferation of SIP service providers who are not
traditional telephony carriers has allowed unscrupulous callers to falsify
calling party telephone numbers"

Get rid of "therefore" in "This document therefore examines the reasons."

Introduction

s/improve/improved/ in "little indication that it will be improve in the
future"

The sentence "In particular, the interworking
   with different communication architectures (e.g., SIP, PSTN, XMPP,
   RTCWeb) breaks the end-to-end semantic of the communication
   interaction and destroys the identification capabilities.
"
doesn't work for me.  That isn't the reason we have the problem.  We have
the problem with all SIP, and have had fewer issues with all PSTN.  The
problem is the inability to trust that From is accurate and the inability to
always have PAI, and have it be the desired TN.  You could get into middle
boxes and how they break SIP identity (or for that matter PAI) here.

"   Furthermore, the use of different identifiers (e.g., E.164 numbers
   vs. SIP URIs) creates challenges for determining who is able to claim
   "ownership" for a specific identifier.
"
is also problematic because we have DNS based ways of determining who can
claim domain based identifiers, but don't for TN based identifiers.
So, maybe "although domain based identifiers (sip:[email-masked]) may use
DNS based approaches to determine who is able to claim "ownership" of the
URI, telephone numbers do not have any similar mechanism defined".

Problem Statement
While I like the explanation of the problem, I find the section lacking an
actual statement of the problem.  I would think we would want to carefully
craft at least a paragraph of text that precisely defines what we are trying
to do.

Use cases

The "but.." clause isn't true, those cases are handled by different
sections.

In PSTN to VoIP, the note confuses me.  Is it saying an IP-IP call with an
SBC looks like a PSTN-IP call?  Something else?  Dunno, but make it more
clear.  

In VoIP to PSTN, I would appreciate flipping the diagram around so Alice is
on the left.  The first intro paragraph matches the diagram and the heading
in saying its a call from Alice on a VoIP phone to Carl on a PSTN phone.
But it then says Alice wants to know who she is talking to.  That's called
party (destination) identity, not part of this work, so far.  I suspect you
mean Carl wants to know who he is talking to.

Limitations
You describe PAI as being "where end-user devices cannot alter or inspect
SIP messages" and then say "cannot offer any protection against identity
spoofing by intermediaries or entities that allow end users to set the P
-Asserted-Identity information".  Can't have it both ways, either end users
can set it or they can't.  I think the problem is more that the network
blindly trusts the From when setting PAI in too many cases; it does not
verify that the From is correct, especially with enterprise customers who
claim they need to assert any of their numbers.  I have no doubt there are
networks that allow their customers to send a PAI, but I don't think it's
very common.

I find the paragraph in SIP Identity that begins with "One of the main
reasons that SIP deployments mimic the PSTN" not helpful.  The first part
seems to set something up, but doesn't provide a rational I understand, and
the latter part is true, but not germane to the problem.

In "Public Key Infrastructure Developments" you have the first introduction
of the delegation tree property of telephone numbers.  This is such a
fundamental concept to the solution that I would prefer to find a way to
introduce it earlier on it's own - the basic notion that in every country,
numbers are delegated in a formal (or formal + informal) way, with a
per-country root of authority.  You get to it later, but I found the first
reference here to be underwhelming.  At the very least, supply a forward
reference, but I'd prefer to actually introduce the idea earlier in the
document.

In "Pervasive Nature of B2BUA Deployments", I think you should introduce the
concept of a canonical TN.  Explain that there are many ways numbers are
represented, but they are convertible to a canonical e.164.  If you didn't
add a section, or change the title of this one, you could explain that one
of the things B2BUAs do is rewrite numbers to mess with prefixes or
add/subtract country codes. 

In "Relationship with number assignment and management" you don't cover
number resell.  I would add text that explains that while the initial
assignments usually are constrained by formal processes, often with
regulatory imperatives, in some countries, reselling of numbers using less
formal processes is permitted.  I might even observe that assignment is
often in ranges, and also that an assignment to an enterprise looks like a
resell.  I would also note in this section that the permitted spoofing cases
really are another form of delegation.

Requirements

I think there are more requirements.  I think origination devices or service
providers must be able to generate secure identities, and termination
devices or service providers must be able to validate.

I think we want to have some requirement on efficiency  -- I want to be able
to say things about length of signature chains in the solution.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 30 Sep 2013 13:49:36 +0000

By "Golden Root", I meant a global root, not a national root. 

We've had bad experiences trying to establish global roots.

I expect we can use something like the LoST Forest Guide to figure out where the database for a given country can be found.  Then I hope it's mostly one database per country.  What I don't want to see is a signature chain on each level of delegation that has to be checked serially to determine if the signature is valid.

Brian

---

From: Michael Hammer <[email-masked]>
Date: Mon, 30 Sep 2013 14:25:46 +0000

Thanks, that helps.

Mike

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, September 30, 2013 9:50 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: Comments on draft-peterson-secure-origin-ps-02

I expect we can use something like the LoST Forest Guide to figure out where
the database for a given country can be found.  Then I hope it's mostly one
database per country.  What I don't want to see is a signature chain on each
level of delegation that has to be checked serially to determine if the
signature is valid.

Brian

On Sep 30, 2013, at 9:28 AM, Michael Hammer <[email-masked]>
 wrote:

> "I think we want to have some requirement on efficiency  -- I want to 
> be able to say things about length of signature chains in the solution.
> If you want something more distributed, then you are going to create 
> long signature chains, which should be a concern.
> Bottom line is that anyone in the world needs to know how to validate 
> and where to go to get trusted information to do that.
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Rosen, Brian
> That's not the case.  Perhaps something like "Unfortunately, the way 
> SIP has been implemented, and the proliferation of SIP service 
> providers who are not traditional telephony carriers has allowed 
> unscrupulous callers to falsify calling party telephone numbers"
> 
> doesn't work for me.  That isn't the reason we have the problem.  We 
> have the problem with all SIP, and have had fewer issues with all 
> PSTN.  The problem is the inability to trust that From is accurate and 
> the inability to always have PAI, and have it be the desired TN.  You 
> could get into middle boxes and how they break SIP identity (or for that
matter PAI) here.
> is also problematic because we have DNS based ways of determining who 
> can claim domain based identifiers, but don't for TN based identifiers.
> So, maybe "although domain based identifiers (sip:[email-masked]) 
> may use DNS based approaches to determine who is able to claim 
> "ownership" of the URI, telephone numbers do not have any similar
mechanism defined".
> 
> Problem Statement
> While I like the explanation of the problem, I find the section 
> lacking an actual statement of the problem.  I would think we would 
> want to carefully craft at least a paragraph of text that precisely 
> defines what we are trying to do.
> 
> Use cases
> In PSTN to VoIP, the note confuses me.  Is it saying an IP-IP call 
> with an SBC looks like a PSTN-IP call?  Something else?  Dunno, but 
> make it more clear.
> 
> In VoIP to PSTN, I would appreciate flipping the diagram around so 
> Alice is on the left.  The first intro paragraph matches the diagram 
> and the heading in saying its a call from Alice on a VoIP phone to Carl on
a PSTN phone.
> But it then says Alice wants to know who she is talking to.  That's 
> called party (destination) identity, not part of this work, so far.  I 
> suspect you mean Carl wants to know who he is talking to.
> 
> That limits the discussion of the solution space.  If there are more 
> than one SPs in the SIP path, any of them can verify the signature, 
> and that would be very helpful.
> 
> Limitations
> You describe PAI as being "where end-user devices cannot alter or 
> inspect SIP messages" and then say "cannot offer any protection 
> against identity spoofing by intermediaries or entities that allow end 
> users to set the P -Asserted-Identity information".  Can't have it 
> both ways, either end users can set it or they can't.  I think the 
> problem is more that the network blindly trusts the From when setting 
> PAI in too many cases; it does not verify that the From is correct, 
> especially with enterprise customers who claim they need to assert any 
> of their numbers.  I have no doubt there are networks that allow their 
> customers to send a PAI, but I don't think it's very common.
> 
> reasons that SIP deployments mimic the PSTN" not helpful.  The first 
> part seems to set something up, but doesn't provide a rational I 
> understand, and the latter part is true, but not germane to the problem.
> 
> mangling, you should have said the work doesn't propose to do anything 
> so stop MITM.  That may be problematic given recent developments, but 
> it is where we are.
> 
> introduction of the delegation tree property of telephone numbers.  
> This is such a fundamental concept to the solution that I would prefer 
> to find a way to introduce it earlier on it's own - the basic notion 
> that in every country, numbers are delegated in a formal (or formal + 
> informal) way, with a per-country root of authority.  You get to it 
> later, but I found the first reference here to be underwhelming.  At 
> the very least, supply a forward reference, but I'd prefer to actually 
> introduce the idea earlier in the document.
> 
> In "Pervasive Nature of B2BUA Deployments", I think you should 
> introduce the concept of a canonical TN.  Explain that there are many 
> ways numbers are represented, but they are convertible to a canonical 
> e.164.  If you didn't add a section, or change the title of this one, 
> you could explain that one of the things B2BUAs do is rewrite numbers 
> to mess with prefixes or add/subtract country codes.
> 
> In "Relationship with number assignment and management" you don't 
> cover number resell.  I would add text that explains that while the 
> initial assignments usually are constrained by formal processes, often 
> with regulatory imperatives, in some countries, reselling of numbers 
> using less formal processes is permitted.  I might even observe that 
> assignment is often in ranges, and also that an assignment to an 
> enterprise looks like a resell.  I would also note in this section 
> that the permitted spoofing cases really are another form of delegation.
> 
> 
> Requirements
> 
> I think we want to have some requirement on efficiency  -- I want to 
> be able to say things about length of signature chains in the solution.
>