Subject: [stir] Do we agree on the basics?

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 13:52:09 +0000

A lot of our discussion is focussed on where certs are found.  I want to make sure that we agree on the basics, because where certs are found is pretty far down the list of things to agree on.

So, do we agree:
1. The PROBLEM we're solving is robocalling, vishing and swatting
2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed.
3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid
4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority.  For identities that are domain based, the credentials are based on the domain entry in the DNS.
5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling.  The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity.  The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop).
6. The credentials (4) are the same in both mechanisms (5)

That doesn't say things like where the certs are or what is signed, or what the out of band mechanism does.

So, I ask, do you agree with that?

Brian

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 19 Jun 2013 14:05:34 +0000

Brian:
I think this is a helpful summary to keep us on track; thanks for posting it. I do wonder if the fifth point, about handling SS7 in the middle may be too ambitious. My own belief is that the best we can hope to achieve is a solution in the post PSTN transition where we are end-to-end IP. While there is SS7 in the middle, there will still likely be SS7 at the beginning or at the end of some calls and I don't see us fixing those cases. So, I'll be happy if we just get the promised land right.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 19, 2013 9:52 AM
To: [email-masked]
Subject: [stir] Do we agree on the basics?

So, do we agree:

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 19 Jun 2013 16:12:15 +0200

> So, I ask, do you agree with that?

I think we should declare "identities that are domain based" out of scope for this work. 

#5 can also be useful with old b2buas that will drop a lot of headers mid-call.

/O

---

From: Michael Hammer <[email-masked]>
Date: Wed, 19 Jun 2013 14:18:43 +0000

The question of whether this works with SS7 in the path is a key one.
That was part of the reason I was concerned about doing both E.164 and email
identities at the same time.

I am not buying the out-of-band, not connected to the current state of the
received signaling message, yet.
If the signaling message arrives with different elements, how do I know that
it is the same thing that is being signed out of band?
Versus an imposter?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
PFAUTZ, PENN L
Sent: Wednesday, June 19, 2013 10:06 AM
To: Rosen, Brian; [email-masked]
Subject: Re: [stir] Do we agree on the basics?

Brian:
I think this is a helpful summary to keep us on track; thanks for posting
it. I do wonder if the fifth point, about handling SS7 in the middle may be
too ambitious. My own belief is that the best we can hope to achieve is a
solution in the post PSTN transition where we are end-to-end IP. While there
is SS7 in the middle, there will still likely be SS7 at the beginning or at
the end of some calls and I don't see us fixing those cases. So, I'll be
happy if we just get the promised land right.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Wednesday, June 19, 2013 9:52 AM
To: [email-masked]
Subject: [stir] Do we agree on the basics?

A lot of our discussion is focussed on where certs are found.  I want to
make sure that we agree on the basics, because where certs are found is
pretty far down the list of things to agree on.

So, do we agree:
1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The
APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the
call, because we believe that spoofing identity or non providing identity is
the way the bad calls are being placed.
3. The METHOD we're going to use is to pick some data from the call and sign
or encrypt it in a way that a downstream entity can verify that the
information is valid 4. The CREDENTIALS we're going to use, for identities
that are telephone numbers, is based on delegation of the number, rooted in
the national numbering authority.  For identities that are domain based, the
credentials are based on the domain entry in the DNS.
5. We think we need two MECHANISMS, an in-band mechanism that has the
originating device or service provider signing information and carries the
signature in the signaling.  The other is some out of band mechanism that
involves some new database or service that gets written by the originating
device or service provider and checked by some downstream entity.  The
latter mechanism is needed to allow the identity to be assured even if the
information or signature from the in band mechanism is lost (such as when
the call goes through an SS7 hop).
6. The credentials (4) are the same in both mechanisms (5)

That doesn't say things like where the certs are or what is signed, or what
the out of band mechanism does.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 14:18:59 +0000

I think that the in band mechanism comes first.  If we can agree on an out of band mechanism we think we can deploy before the problem goes away, that would be good.  That means our milestones should show work on the out of band mechanism later.

I observe that there are a lot of cases of SIP - SS7 - SIP.  Some have claimed that by the time we could deploy any solution, that middle SS7 hop will be gone.  I'm not so sure of that.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 07:22:19 -0700

On 6/19/2013 6:52 AM, Rosen, Brian wrote:
> originating device or service provider signing information and
> carries the signature in the signaling.  The other is some out of
> band mechanism that involves some new database or service that gets
> written by the originating device or service provider and checked by
> some downstream entity.  The latter mechanism is needed to allow the
> identity to be assured even if the information or signature from the
> in band mechanism is lost (such as when the call goes through an SS7
> hop).

Good list.

I'd like us to explore #5 carefully.  Although it carries the usual 
appeal of flexibility. However beyon that intuitive appeal, it 
dramatically increases complexity and its viable usage is not at all 
obvious.  The motivating rationale in the last sentence sounds great, 
but that doesn't mean it's viable.

Some examples of questions that such an approach needs to answer:

1. What does it do to overall design and operations complexity and cost?

2. What is a realistic estimate of the likelihood of major benefit; in 
other words, why should we believe it will help enough to warrant the 
added costs?

3. What are the added adoption barriers?

4. What are the early-stage costs, such as when almost no one has it 
implemented?

    For example, the stated use is when the call request arrives without 
the signature information; this will look exactly the same as a call 
from a system that did not add the signature.  Initially the latter will 
be far, far more common than the former.  Almost no one will be signing. 
  Hence, the querying agent is going to be making unsuccessful 
alternative checks essentially every time.  Failure rates at that level 
discourage adoption.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 14:34:59 +0000

Of course, like most of us, you are an engineer, so you want to see that there is at least one solution that could work before you even want to see something in a charter.  So, EKR proposed one solution where the source writes a data record in a database encrypted for the termination.  All that depends on is the source and destination identities.  Ignoring whether you think we can deploy it, it does solve the problem.

I'll give you the guts of another solution:  The SIP-> SS7 GW writes a record with Called and Calling party TNs, and the SIP headers.  The SS7-SIP GW searches for a record with the same called and calling TNs, within a short time frame, and retrieves the SIP headers, which it uses to populate its outgoing message, effectively restoring the signature and the elements that were used when creating it.  Ignoring whether you think we could deploy it, it also solves the problem, but only in a more restricted set of situations.

There are all sorts of trust issues, cert distribution issues, privacy issues, business model issues, and a host of other stuff, but either of these solutions would work.  In this thread, I'd like to stay away from discussing those issues - I'm only trying to convince you that there are reasonable engineering solutions that would work.  Once we have a WG, we can work out the issues.  In the end, that might fail, but we're starting from  reasonable engineering base I think.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 14:47:42 +0000

Inline
On Jun 19, 2013, at 10:22 AM, Dave Crocker <[email-masked]> wrote:

> I'd like us to explore #5 carefully.  Although it carries the usual appeal of flexibility. However beyon that intuitive appeal, it dramatically increases complexity and its viable usage is not at all obvious.  The motivating rationale in the last sentence sounds great, but that doesn't mean it's viable.
> 
Two mechanisms, got to be at least twice the cost

> 
> 2. What is a realistic estimate of the likelihood of major benefit; in other words, why should we believe it will help enough to warrant the added costs?
Because we want to solve the problem now, where essentially all calls go through an SS7 link.

> 3. What are the added adoption barriers?
That depends on the solution.  There are several of them, for sure.

> 
> 4. What are the early-stage costs, such as when almost no one has it implemented?
> 
>   For example, the stated use is when the call request arrives without the signature information; this will look exactly the same as a call from a system that did not add the signature.  Initially the latter will be far, far more common than the former.  Almost no one will be signing.  Hence, the querying agent is going to be making unsuccessful alternative checks essentially every time.  Failure rates at that level discourage adoption.
For one thing the same is true for the in band mechanism.

Sure, there is a cost for the out of band mechanism.
It's mostly fixed cost, but there are always transaction volume related costs.  

Actually, some of us are worried that the problem of the out of band mechanism is that by the time we've deployed it, and sunk most of the cost, the problem goes away.  Others think that there will always be some barriers and the out of band mechanism has value for a very long time.

The costs are mostly the database itself, and the implementation in wherever it is done.  In EKR's idea, it's at the ends (device or services).  In the alternate idea I just described, it's in the gateways (or near them, a B2BUA could do it).

---

From: Michael Hammer <[email-masked]>
Date: Wed, 19 Jun 2013 14:54:45 +0000

OK, so this out-of-band was simply focusing on bypassing the SS7
restrictions by allowing the ingress to SS7 and the egress from SS7 to
cooperate in passing data that would not fit into SS7.
That is a limited and perhaps reasonable work-around.  

Until now, I had no real idea what you were going for in the out-of-band
comments.

Mike

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Wednesday, June 19, 2013 10:35 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Do we agree on the basics?

Of course, like most of us, you are an engineer, so you want to see that
there is at least one solution that could work before you even want to see
something in a charter.  So, EKR proposed one solution where the source
writes a data record in a database encrypted for the termination.  All that
depends on is the source and destination identities.  Ignoring whether you
think we can deploy it, it does solve the problem.

I'll give you the guts of another solution:  The SIP-> SS7 GW writes a
record with Called and Calling party TNs, and the SIP headers.  The SS7-SIP
GW searches for a record with the same called and calling TNs, within a
short time frame, and retrieves the SIP headers, which it uses to populate
its outgoing message, effectively restoring the signature and the elements
that were used when creating it.  Ignoring whether you think we could deploy
it, it also solves the problem, but only in a more restricted set of
situations.

There are all sorts of trust issues, cert distribution issues, privacy
issues, business model issues, and a host of other stuff, but either of
these solutions would work.  In this thread, I'd like to stay away from
discussing those issues - I'm only trying to convince you that there are
reasonable engineering solutions that would work.  Once we have a WG, we can
work out the issues.  In the end, that might fail, but we're starting from
reasonable engineering base I think.

Brian
On Jun 19, 2013, at 10:18 AM, Michael Hammer <[email-masked]>
wrote:

> That was part of the reason I was concerned about doing both E.164 and 
> email identities at the same time.
> 
> I am not buying the out-of-band, not connected to the current state of 
> the received signaling message, yet.
> If the signaling message arrives with different elements, how do I 
> know that it is the same thing that is being signed out of band?
> Versus an imposter?
> 
> Mike
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of PFAUTZ, PENN L
> I think this is a helpful summary to keep us on track; thanks for 
> posting it. I do wonder if the fifth point, about handling SS7 in the 
> middle may be too ambitious. My own belief is that the best we can 
> hope to achieve is a solution in the post PSTN transition where we are 
> end-to-end IP. While there is SS7 in the middle, there will still 
> likely be SS7 at the beginning or at the end of some calls and I don't 
> see us fixing those cases. So, I'll be happy if we just get the promised
land right.
> A lot of our discussion is focussed on where certs are found.  I want 
> to make sure that we agree on the basics, because where certs are 
> found is pretty far down the list of things to agree on.
> 
> So, do we agree:
> 1. The PROBLEM we're solving is robocalling, vishing and swatting 2. 
> The APPROACH we're going to use is to verify the IDENTITY of the 
> SOURCE of the call, because we believe that spoofing identity or non 
> providing identity is the way the bad calls are being placed.
> 3. The METHOD we're going to use is to pick some data from the call 
> and sign or encrypt it in a way that a downstream entity can verify 
> that the information is valid 4. The CREDENTIALS we're going to use, 
> for identities that are telephone numbers, is based on delegation of 
> the number, rooted in the national numbering authority.  For 
> identities that are domain based, the credentials are based on the domain
entry in the DNS.
> originating device or service provider signing information and carries 
> the signature in the signaling.  The other is some out of band 
> mechanism that involves some new database or service that gets written 
> by the originating device or service provider and checked by some 
> downstream entity.  The latter mechanism is needed to allow the 
> in band mechanism is lost (such as when the call goes through an SS7 hop).

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 15:03:31 +0000

EKRs idea is allow simple in some ways - the origination encrypt details about the call with the credentials of the termination.  The termination searches for calls to it.  The database validates the credentials of the origination to permit the write.  It has some clever ideas on avoiding analysis of calling patterns.

Brian

On Jun 19, 2013, at 10:54 AM, Michael Hammer <[email-masked]> wrote:

>> Of Rosen, Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 19 Jun 2013 11:08:12 -0400

Brian,

Thanks for a timely summary.  I have some questions I've been hoping would become clear by monitoring the discussion, that so far haven't.

Questions re. scope:
--------------------
#1:  Is the scope limited to _only_ identities that are or imbed, E.164 numbers?
#2:  Does the scope include identities that are or imbed, numbers structured per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers)?
#3:  Does the scope include identities that are or imbed, national numbers?

General Question:
-----------------
#4:  Is there any actual data behind this initiative?  I don't recall seeing any numbers (e.g., how often do various types of bad things, happen; what damage is done; is it on the rise or decline).  I don't recall any assessment of how these things are being done (just assumptions that they're facilitated by spoofing caller ID in a VoIP call origination).  Yes, I know there are web sites you can go to that let you do exactly that.  But do we know that that's how this mischief is being done?  What if it's being initiated on a circuit switched PBX connected into the POTS network via a PRI, and the culprits are leveraging gaps in the interworking of ISUP and SIP to go undetected?  If it's knowable we ought to try and know, so that we fix the right problem.  I don't recall any analysis of the [in]adequacy of currently defined mechanisms.  Why for example does transitive trust seem to work in the PSTN but not in SIP?

I'm not really trying to invite pontification.  I'm asking has any actual investigation been done, and if so where are the results?  A list of URLs would be great.  No offense intended with respect to the interesting technical discussions already taking place, but in order to motivate deployment _somebody_ is going to have to do this.

Regarding the discussion below:
-------------------------------
On point #2, can you clarify what is meant by "verify the identity of the source"?  What I'm imagining is something like (a) verifying that the calling identity is "valid"; and (b) verifying that the calling UA has the "right" to claim that identity for the purpose of initiating the call in question.  Is that roughly it?  If so, can you step through how that validity check would work?  It's kind of a big leap to see how "pick[ing] some data from the call and sign[ing] it", achieves those objectives.  

Similarly, what is the rule for when it's OK that entity 'A' assert identity (e.g., phone number) 'b'?  Some seem obvious, but not all.  For example:

   Case 1: numbering plan administrator has assigned identity 'b' to carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'A'.  
   Case 2: numbering plan administrator has assigned identity 'b' to carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'C'.  
           Person 'C' grants to person 'A' permission to identify itself as 'b'.
   Case 3: numbering plan administrator has assigned identity 'b' to carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'C'.  
           Person 'C' grants to person 'A' permission to identify itself as 'b'; with some constraints (e.g., only at night, or only 
           for 1 day, or only to invoke certain services or call certain numbers).

In case 1 it is OK for 'A' to identify itself as 'b'.  
In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on whether there are restrictions on "sub-assignment" of numbers and if so, whether 'C' meets them.  
In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending both on whether 'C' had authority to 'sub-assign' identity 'b', and whether the other restrictions specified by 'C' were met.  Who would check?

Cheers,

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 19, 2013 8:52 AM
To: [email-masked]
Subject: [stir] Do we agree on the basics?

So, do we agree:
1. The PROBLEM we're solving is robocalling, vishing and swatting 2. The APPROACH we're going to use is to verify the IDENTITY of the SOURCE of the call, because we believe that spoofing identity or non providing identity is the way the bad calls are being placed.
3. The METHOD we're going to use is to pick some data from the call and sign or encrypt it in a way that a downstream entity can verify that the information is valid 4. The CREDENTIALS we're going to use, for identities that are telephone numbers, is based on delegation of the number, rooted in the national numbering authority.  For identities that are domain based, the credentials are based on the domain entry in the DNS.
5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling.  The other is some out of band mechanism that involves some new database or service that gets written by the originating device or service provider and checked by some downstream entity.  The latter mechanism is needed to allow the identity to be assured even if the information or signature from the in band mechanism is lost (such as when the call goes through an SS7 hop).
6. The credentials (4) are the same in both mechanisms (5)

Brian

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 19 Jun 2013 15:14:50 +0000

+1 to the concern about non-VoIP based spoofing and the issue of legitimate use of a number assigned to another party. To be specific, lots of companies contract with call centers for telemarketing. They want the calling party number to show the toll free number of the company with the product, not the telemarketer.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: Wednesday, June 19, 2013 11:08 AM
To: Rosen, Brian; [email-masked]
Subject: Re: [stir] Do we agree on the basics?

Brian,

Questions re. scope:
--------------------

General Question:
-----------------

Cheers,

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 19, 2013 8:52 AM
To: [email-masked]
Subject: [stir] Do we agree on the basics?

So, do we agree:

Brian

---

From: <[email-masked]>
Date: Wed, 19 Jun 2013 16:12:04 +0000

This looks good to me, thanks for summing this up. For the record, I share the observations/reservations that have already been made on point 5 for the out-of-band mechanism and the practicalities of a gradual deployment.  

The other thing that slightly puzzles me (and that I don't quite see in other comments) is the statement about "identities that are domain based" ("the credentials are based on the domain entry in the DNS "). Given that the proposed charter doesn't talk about what is meant to be in scope in terms of URI format and what isn't, maybe this exercise will be necessary at some point to move forward (or if this ""domain-based identity" is meant to clarify this, my apologies, I don't quite get it.) 

This assumes that for a signed and 'uncorrupted' sip:[email-masked];user=phone to be validated by the endpoint, the host part must remain untouched end-to-end since, if I read the above correctly, the credentials for +CC-XXXXXX will have to be found under domain.com (and I don't mean this literally in the DNS). Is this correct? (incidentally to me this clearly restricts the use case to calling party numbers, your point 2., since for called parties as others have pointed out, in some networks, the host part is generally for good or bad irrelevant when the SIP URI conveys an encapsulated tel) 

Thanks,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 19, 2013 3:52 PM
To: [email-masked]
Subject: [stir] Do we agree on the basics?

So, do we agree:

Brian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 09:21:26 -0700

> 5. We think we need two MECHANISMS, an in-band mechanism that has the originating device or service provider signing information and carries the signature in the signaling.  The other is some out o…

Perhaps I'm misunderstanding its expected usage scenario, but problems 
with gatewaying to/from SS7 are being cited as the rationale for the out 
of band mechanism.  As such, it sounds like an issue that does not 
involve the core design, but rather a kind of workaround for a hop that 
doesn't support that core design.  If so, it should be specified as a 
separate mechanism to be applied in only specific cases.

In some environments, the hack for overcoming such a limitation is 
tunneling.  That is, encapsulated things to hide them from the hop that 
lacks support.  I don't think there's common term for using a side-stash 
of the information, but we should invent one.  As I understand the 
requirement, it might make sense to specify it as an additional 
mechanism to be used only by SIP/SS7 and SS7/SIP gateways.

When transiting SIP/SS7, the information is stored into the side cache. 
  When transiting SS7/SIP, the cache is queried; if an entry is found, 
the STIR information is restored in native form.

There is still the small matter of vanishingly small success for the 
SS7/SIP queries that will happen for a very long time.  This really 
creates a very strong disincentive for the sizable additional cost.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 17:21:44 +0000

To be fair, there are some scenarios other than SS7 links where the information is lost.  If we go for an SS7-only solution, we don't cover those cases.  The mechanisms may be able to be used in other environments.

I don't know why you think that we have "vanishingly small success for the SS7/SIP queries".

Brian

On Jun 19, 2013, at 12:21 PM, Dave Crocker <[email-masked]> wrote:

> Perhaps I'm misunderstanding its expected usage scenario, but problems with gatewaying to/from SS7 are being cited as the rationale for the out of band mechanism.  As such, it sounds like an issue that does not involve the core design, but rather a kind of workaround for a hop that doesn't support that core design.  If so, it should be specified as a separate mechanism to be applied in only specific cases.
> 
> In some environments, the hack for overcoming such a limitation is tunneling.  That is, encapsulated things to hide them from the hop that lacks support.  I don't think there's common term for using a side-stash of the information, but we should invent one.  As I understand the requirement, it might make sense to specify it as an additional mechanism to be used only by SIP/SS7 and SS7/SIP gateways.
> 
> When transiting SIP/SS7, the information is stored into the side cache.  When transiting SS7/SIP, the cache is queried; if an entry is found, the STIR information is restored in native form.
> 
> There is still the small matter of vanishingly small success for the SS7/SIP queries that will happen for a very long time.  This really creates a very strong disincentive for the sizable additional cost.
> 
> d/
> -- 
> Dave Crocker

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 17:23:38 +0000

"domain based identities" = identities of the form sip:[email-masked].
It DOES NOT include [email-masked];user=phone

Brian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 10:25:46 -0700

> To be fair, there are some scenarios other than SS7 links where the information is lost.  If we go for an SS7-only solution, we don't cover those cases.  The mechanisms may be able to be used in ot…

What scenarios, specifically?

> I don't know why you think that we have "vanishingly small success for the SS7/SIP queries".

This is Transition 101.  In the absence of an explicit indicator of 
support, checking for the data is blind; a query must be done every 
time, whether it will succeed or not.

Because there is not universal cut-over event, adoption is incremental. 
  The world starts with zero adoption and tries to move in a positive 
direction.

Until adoption is very widespread, the likelihood that a query will 
succeed is small because the proportion of adopters doing signing is 
small.  Vanishingly small.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 13:32:16 -0400

> Of course, like most of us, you are an engineer, so you want to see that there is at least one solution that could work before you even want to see something in a charter.  So, EKR proposed one sol…

So does putting the info on a piece of paper, rolling it up, attaching the roll to the leg of a carrier pigeon, and pushing the pigeon out the window.  But I don't think we can ignore that such a solution isn't deployable. (mostly because there aren't enough qualified pigeons)

I'm not trying to be difficult - I'm worried because in the BOFs that I've been to before, whether a problem is solvable in a useful/deployable fashion is often a criteria for getting a Working Group created.  Or instead during the BOF we get bogged down with lots of microphone discussion about the viability of solutions, and run out of time resulting in a request for another BOF before getting a Working Group.

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 17:40:03 +0000

> Thanks for a timely summary.  I have some questions I've been hoping would become clear by monitoring the discussion, that so far haven't.
Some of us want to be able to expand to user@domain identities, but that isn't the problem we are solving

> #2:  Does the scope include identities that are or imbed, numbers structured per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers)?
Yes

> #3:  Does the scope include identities that are or imbed, national numbers?
Yes, although we can't go beyond what you do today - you can't call them internationally for example.  I don't think scope includes service numbers like 511 though.

> General Question:
I don't have numbers.  Henning might.  I know that some specific offenders have been traced and found, and they were using VoIP on their side.

> Regarding the discussion below:
Yes, you have that correct.

So you get a credential that comes to you because you were delegated a number or range of numbers.  Every time a delegation happens, a new cert is created.  So if an enterprise got a delegation of 10 numbers from a VoIP reseller, who got them from a VoIP SP, who got them from a certificated carrier, who got them from the Pooling Admin, who got them from the NANPA, then there were 4 certs in the path.  The enterprise signs its outgoing calls with the cert it got.  It's traceable all the way back to NANPA.

So you take a set of information from the SIP signaling - we're discussing the details, but it's something like Called and Calling Party Telephone Numbers, a Call Id and a time stamp.  You compute a signature over that info.  You include the signature, and either the cert itself, or a URI to it, in the SIP signaling.

Any downstream entity can extract the information from the signaling, recompute the signature, check it, and verify that the cert is (still) valid for the range.

If any of that information is changed, the signature wouldn't verify.  But, more importantly, the signature can be proved to be that of the cert holder, so we know who sent the call.  And we know that the cert holder was delegated the number (which covered by the signature).  If a downstream entity only accepts calls with valid identity, that means it only accepts calls with a signed identity header, signed by an entity that was delegated the TN in the identity.

Is that clear?

>   Case 1: numbering plan administrator has assigned identity 'b' to carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'A'.  
Administer issues cert to carrier X.  Carrier X issues cert to A
>           Person 'C' grants to person 'A' permission to identify itself as 'b'.
Administer issues cert to carrier X.  Carrier X issues cert to C. C issues cert to A.  

>           for 1 day, or only to invoke certain services or call certain numbers).
We haven't discussed constraints..  Only for one day is easy.  We'd have to work on other constraints.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 19 Jun 2013 17:42:45 +0000

I'll take a stab at this, below, though I wouldn't describe these as
settled issues.

On 6/19/13 8:08 AM, "Dwight, Timothy M (Tim)" <[email-masked]>
wrote:

>Brian,
>
>Thanks for a timely summary.  I have some questions I've been hoping
>would become clear by monitoring the discussion, that so far haven't.
>
>Questions re. scope:
>--------------------

The problem we're trying to fix is specific to telephone numbers, but as
the answers below suggest, not just E.164 numbers.

One small caveat: if in fact we build on the existing work in RFC4474, we
would be effectively extending a mechanism that does cover non-TN
identifiers (sip:user@domain style) to now cover TN identifiers. So for
example, RFC4474bis would have provisions for both. But the point of the
proposed STIR work is secure telephone numbers.

>#2:  Does the scope include identities that are or imbed, numbers
>structured per Rec. E.164 that aren't end point identifiers (e.g., toll
>free numbers)?

I think ideally nationally-specific numbers should also be in scope,
including freephone numbers. I should be able to get a call from United's
IVR that uses a freephone number as a calling party number with a valid
identity signature. Understood that the authority for these numbers is
managed differently than for ordinary numbers.

>#3:  Does the scope include identities that are or imbed, national

As above, at least some. There are corner case and hard edges to consider
here. I'd like identity to work for text messaging as well as calls. Does
that mean short codes in scope - that is, are there use cases where you
can get a text from a short code? Will there be some national authorities
who want to be able to claim an emergency number as a calling party
number, ever - will reverse 911 show up literally as from "911"? I don't
think I have the answers to all of that, and it's not within the scope of
the administrative databases of the PSTN today to say who is authoritative
to claim "911" as a calling number.

>
>General Question:
>-----------------
>#4:  Is there any actual data behind this initiative?  I don't recall
>seeing any numbers (e.g., how often do various types of bad things,
>happen; what damage is done; is it on the rise or decline).  I don't
>recall any assessment of how these things are being done (just
>assumptions that they're facilitated by spoofing caller ID in a VoIP call
>origination).  Yes, I know there are web sites you can go to that let you
>do exactly that.  But do we know that that's how this mischief is being
>done?  What if it's being initiated on a circuit switched PBX connected
>into the POTS network via a PRI, and the culprits are leveraging gaps in
>the interworking of ISUP and SIP to go undetected?  If it's knowable we
>ought to try and know, so that we fix the right problem.  I don't recall
>any analysis of the [in]adequacy of currently defined mechanisms.  Why
>for example does transitive trust seem to work in the PSTN but not in SIP?

Henning has some charts about the bad behind swatting, vishing and
robocalling. Really I'd say that FCC's efforts to respond to consumer
complaints and widespread perceptions of challenges in this area the
primary impetus for us to revisit this problem space. Perhaps we should
get a link to Henning's preso into the STIR archives.

To your last point, if transitive trust worked in the PSTN, we would have
none of those problems. As you rightly point out, transitive trust for
source identity hasn't been totally reliable in the PSTN since some
service providers starting accepting the asserted source numbers of Q.931
SETUP messages and putting them directly into the CIN fields of IAMs. That
was around long before VoIP was a material concern. The difference is that
the Internet has increased both the number of gateways and the
programmability of gateways.

There has been some talk on the list in the past couple of days about the
"out-of-band" prong of STIR's scope. The original idea behind out-of-band
was to attempt to leverage the increasing amount of smarts in devices to
improve security even when SIP is only signaled in part of the call path,
or even not at all. So yes, there are non-SIP dimensions to this problem
space, and yes, trying to address them is in the proposed scope of STIR.
We all however acknowledge that this will be a longer-term deliverable, if
we take it on.

>I'm not really trying to invite pontification.  I'm asking has any actual
>investigation been done, and if so where are the results?  A list of URLs
>would be great.  No offense intended with respect to the interesting
>technical discussions already taking place, but in order to motivate
>deployment _somebody_ is going to have to do this.
>
>
>On point #2, can you clarify what is meant by "verify the identity of the
>source"?  What I'm imagining is something like (a) verifying that the
>calling identity is "valid"; and (b) verifying that the calling UA has
>the "right" to claim that identity for the purpose of initiating the call
>in question.  

It's closer to (b). Or at least I don't know what "valid" means. Even
knowing that the number is assigned, and in that sense valid, would help
some, if that's what you mean. But we are trying to get somewhere closer
to (b).

>Is that roughly it?  If so, can you step through how that validity check
>would work?  It's kind of a big leap to see how "pick[ing] some data from
>the call and sign[ing] it", achieves those objectives.

We have some input drafts about this, and some older work that we propose
to build on. At this stage of the work, though, when we're discussing
chartering here in the IETF, we don't necessarily have to agree on details
of the solution so much as how we plan to try to attack the problem. I
could give you at least a straw man answer to your questions here, but do
bear in mind, this doesn't necessarily reflect the consensus of the group
and is just an example.

Verizon has a credential for a ten-thousand block, we'll say. A SIP call
is placed, and wants to claim a number within that ten-thousand block. The
proposed system could work in at least two ways. In the first way, Verizon
will have delegated to the calling UA a sub-credential covering only the
specific number, and the calling UA will actually provide a signature
itself before sending the call. In the second way, Verizon could operate
some kind of service, effectively like a SIP proxy, that the caller would
send the call through; Verizon would in some service-specific way
authenticate the caller, and then sign the call with their ten-thousand
block credential if the

On the verification side, when a call comes in, a verification service
(which might be implemented at a intermediary, or even in an end device
potentially) will compare the credential that created the signature with
the telephone number asserted in the From header field. If they match, or
more precisely if the credential has a scope that includes the number in
question, then provided the signature verifies then the identity will be
presented as a verified identity.

So to your points:

>Similarly, what is the rule for when it's OK that entity 'A' assert
>identity (e.g., phone number) 'b'?  Some seem obvious, but not all.  For
>example:
>
>   Case 1: numbering plan administrator has assigned identity 'b' to
>carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'A'.
>   Case 2: numbering plan administrator has assigned identity 'b' to
>carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'C'.
>   Case 3: numbering plan administrator has assigned identity 'b' to
>carrier 'X'.  Carrier 'X' has assigned identity 'b' to person 'C'.
>           Person 'C' grants to person 'A' permission to identify itself
>as 'b'; with some constraints (e.g., only at night, or only

Provided X has given the appropriate credential to A, or is otherwise
willing to sign their request, then yes.

>In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on
>whether there are restrictions on "sub-assignment" of numbers and if so,
>whether 'C' meets them.

Depending on how the credential system works, there are a variety of ways
to meet requirements along these lines. If A has a certificate giving them
authority for b, they could potentially delegate some of the authority to
a certificate held by C, and C could then use that authority to place a
call for b. Again, just an example. There are potentially other mechanisms
with alternative delegation properties.

>In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending
>both on whether 'C' had authority to 'sub-assign' identity 'b', and
>whether the other restrictions specified by 'C' were met.  Who would
>check?

The ability to impose constraints like this is something that could be
designed into the credential mechanism. While that's not impossible, it's
certainly not the first case that would be on our plate in the proposed
STIR work. Ultimately, again with something like a certificate issued to
C, attributes in the cert could indicate these parameters, and a
verification service could verify them when A uses the cert. Or if we
assume Verizon manages all signatures for this ten-thousand block, perhaps
C would have some web interface to Verizon that lets them articulate this
policy and designate very narrow powers to A. In the latter case, this
would be more of a question of application behavior than standards. But
again, I think these sorts of policies would be something we'd consider
after nailing down more basic cases.

Jon Peterson
Neustar, Inc.

>APPROACH we're going to use is to verify the IDENTITY of the SOURCE of
>the call, because we believe that spoofing identity or non providing
>identity is the way the bad calls are being placed.
>3. The METHOD we're going to use is to pick some data from the call and
>sign or encrypt it in a way that a downstream entity can verify that the
>information is valid 4. The CREDENTIALS we're going to use, for
>identities that are telephone numbers, is based on delegation of the
>number, rooted in the national numbering authority.  For identities that
>are domain based, the credentials are based on the domain entry in the
>DNS.
>the signature in the signaling.  The other is some out of band mechanism
>that involves some new database or service that gets written by the
>originating device or service provider and checked by some downstream
>entity.  The latter mechanism is needed to allow the identity to be
>assured even if the information or signature from the in band mechanism
>is lost (such as when the call goes through an SS7 hop).

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 17:58:45 +0000

To a certain extent, I agree, but it's also the case that we get a hair ball out of solving every problem before we start work.

To me, the problems with EKR's idea, which I actually like quite a bit are:
a) Only the origination can write the record.  This might possibly be fixable in some cases (SIP->SS7 GW is owned by a service provider who has the number delegated to it, even though it delegated the number downstream).  But in a generic transit network case, it wouldn't work.  With in-band, the any provider in the path can verify.  But only the termination entity (the one who owns the credential) can validate.
b) It depends (for stopping robocalling, vishing and swatting) on being able to discover the credentials of the termination by the origination.  That requires a public database of TN to cert.  I think the PERCEIVED difficulties of doing that doom deployment in any interesting timeframe.  I think many national regulators and national carriers will refuse to allow it.  I think many privacy advocates will object enough to slow deployment unacceptably.

The problems with the alternate idea (SIP->SS7 writes, SS7->SIP queries, restore the in band information) is that it has a more limited applicability, and must have a central DB.

There is another idea I've had for the problem of PSTN.   First of all, note that if the SIP->SS7 GW checked identity in band, it fixes the problem.  It doesn't have to be the termination device or carrier.  Further, if ANY entity in the path checks, it fixes the problem.  That means SIP origination, PSTN termination can be addressed if we have at least one good SP in the path.

The idea is that if the SS7->SIP GW doesn't find the record, we could issue it a cert that it could use to create a signature from that point forward.  That cert would only say "I don't know what happened before I got the call, but from here on, the identities were …".  That helps adoption some.  It doesn't fix a spoofed ID that started in the SS7 network.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 19 Jun 2013 14:00:45 -0400

-----Original Message-----
Dwight, Timothy M (Tim)

Brian,

Thanks for a timely summary.  I have some questions I've been hoping would
become clear by monitoring the discussion, that so far haven't.

Questions re. scope:
--------------------
#1:  Is the scope limited to _only_ identities that are or imbed, E.164
numbers?

[RS> ]  IMHO E.164 for now.  I, for one, will never support any charter that
has "boil the ocean" goals and objectives.  

#2:  Does the scope include identities that are or imbed, numbers structured
per Rec. E.164 that aren't end point identifiers (e.g., toll free numbers)?
[RS> ]  Excellent question. IMHO it does but don't get me started on
SMS800.com. I do believe they will have to be involved at some point since
those numbers are absolutely vital to business. 

#3:  Does the scope include identities that are or imbed, national numbers?
[RS> ] Please clarify.. I don't understand. 

General Question:
-----------------
#4:  Is there any actual data behind this initiative?  I don't recall seeing
any numbers (e.g., how often do various types of bad things, happen; what
damage is done; is it on the rise or decline). 

[RS> ]  Right now the Federal Trade Commission is reporting 200,000
complaints per month to their agency alone on issues related to Call
Spoofing. I don't have exact figures on the FCC complaint lines but I would
easily bet its #1 or #2 as well. The CRTC in Ottawa is reporting 50% of
their complaints etc.  It not just the criminal fraud issues it's the
violation of the do not call lists etc and a host of other Telephony Denial
of Service Attacks on enterprises and even PSAP's. There is ample evidence
of a broad spectrum problem. 

Henning gave a useful presentation several weeks ago here in DC I'll let him
post the URL.  

 I don't recall any assessment of how these things are being done (just
assumptions that they're facilitated by spoofing caller ID in a VoIP call
origination).  
[RS> ] 
[RS> ] Especially from  Call Gateways operated by some carrier Wholesale
divisions. 

Yes, I know there are web sites you can go to that let you do exactly that.
But do we know that that's how this mischief is being done?  What if it's
being initiated on a circuit switched PBX connected into the POTS network
via a PRI, and the culprits are leveraging gaps in the interworking of ISUP
and SIP to go undetected?  If it's knowable we ought to try and know, so
that we fix the right problem.  I don't recall any analysis of the
[in]adequacy of currently defined mechanisms.  Why for example does
transitive trust seem to work in the PSTN but not in SIP?

Regarding the discussion below:
-------------------------------
On point #2, can you clarify what is meant by "verify the identity of the
source"?  What I'm imagining is something like (a) verifying that the
calling identity is "valid"; and (b) verifying that the calling UA has the
"right" to claim that identity for the purpose of initiating the call in
question.  Is that roughly it?  If so, can you step through how that
validity check would work?  It's kind of a big leap to see how "pick[ing]
some data from the call and sign[ing] it", achieves those objectives.  

Similarly, what is the rule for when it's OK that entity 'A' assert identity
(e.g., phone number) 'b'?  Some seem obvious, but not all.  For example:

   Case 1: numbering plan administrator has assigned identity 'b' to carrier
'X'.  Carrier 'X' has assigned identity 'b' to person 'A'.  
   Case 2: numbering plan administrator has assigned identity 'b' to carrier
'X'.  Carrier 'X' has assigned identity 'b' to person 'C'.  
           Person 'C' grants to person 'A' permission to identify itself as
'b'.
   Case 3: numbering plan administrator has assigned identity 'b' to carrier
'X'.  Carrier 'X' has assigned identity 'b' to person 'C'.  
           Person 'C' grants to person 'A' permission to identify itself as
'b'; with some constraints (e.g., only at night, or only 
           for 1 day, or only to invoke certain services or call certain
numbers).

In case 1 it is OK for 'A' to identify itself as 'b'.  
In case 2 it _may be_ OK for 'A' to identify itself as 'b', depending on
whether there are restrictions on "sub-assignment" of numbers and if so,
whether 'C' meets them.  
In case 3 it _may be_ OK for 'A' to identify itself as 'b', depending both
on whether 'C' had authority to 'sub-assign' identity 'b', and whether the
other restrictions specified by 'C' were met.  Who would check?

Cheers,

tim

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

So, do we agree:

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 19 Jun 2013 14:06:27 -0400

I know Penn. This is an excellent example of the corner case of legitimate
manipulation in the public interest.  I'm sure we can address this,  but at
some point the regulators themselves are going to have to look at the
problem with a different view. What I'm sure of is the IETF has no magic
bullet here.  We can only provide tools.  In order to look at a
comprehensive solution there will have to be some recognition among the
regulators that they have a big tool box as well and it contains a pretty
big hammer.

If you look at the Truth in Caller ID act its badly written and functionally
useless since enforcement depends on the notion of "intent to defraud" which
is difficult to prove.  

What would have been more useful is to ban Caller ID spoofing entirely with
the exception of a specific "certificate of need" such as the use case you
describe and the others we are all aware of.  Another option is the case of
the TCPA permit a private right of action against the violators.  That
private right of action was vital in controlling the Junk fax problem in the
mid 90's.

www.fcc.gov/cgb/policy/TCPA-Rules.pd

At some point the regulators and the legislators will have to follow the
wisdom of Captain Spock, "the needs of the many outweigh the needs of the
few"    I could also quote Jeremy Bentham but that might be going over the
top even for me. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
PFAUTZ, PENN L
Sent: Wednesday, June 19, 2013 11:15 AM
To: Dwight, Timothy M (Tim); Rosen, Brian; [email-masked]
Subject: Re: [stir] Do we agree on the basics?

+1 to the concern about non-VoIP based spoofing and the issue of legitimate
use of a number assigned to another party. To be specific, lots of companies
contract with call centers for telemarketing. They want the calling party
number to show the toll free number of the company with the product, not the
telemarketer.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

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

Brian,

Questions re. scope:
--------------------

General Question:
-----------------
#4:  Is there any actual data behind this initiative?  I don't recall seeing
any numbers (e.g., how often do various types of bad things, happen; what
damage is done; is it on the rise or decline).  I don't recall any
assessment of how these things are being done (just assumptions that they're
facilitated by spoofing caller ID in a VoIP call origination).  Yes, I know
there are web sites you can go to that let you do exactly that.  But do we
know that that's how this mischief is being done?  What if it's being
initiated on a circuit switched PBX connected into the POTS network via a
PRI, and the culprits are leveraging gaps in the interworking of ISUP and
SIP to go undetected?  If it's knowable we ought to try and know, so that we
fix the right problem.  I don't recall any analysis of the [in]adequacy of
currently defined mechanisms.  Why for example does transitive trust seem to
work in the PSTN but not in SIP?

Cheers,

tim

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

So, do we agree:

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 18:13:44 +0000

You get the idea that if we have a chain of delegations, we have a mirror chain of certs.  The enterprise gets a cert from his SP covering his number.  He can then issue a cert to the call center authorizing them to use its number.  It's one more delegation and one more link in the chain.  Note that this is analogous to the SP signing with its cert a call from the enterprise.  Even if it has delegated the number, it can, if it wishes, sign the header.  It probably would want to police such calls to make sure they are from who they say they are from before it signs, of course.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 18:41:07 +0000

Just to be clear, the reason why I want to have the second mechanism sooner rather than later is that essentially all interconnect between certificated carriers is via SS7.  If we don't solve that problem, it won't work.

The counter argument is that by the time we deploy anything, that won't be true.  I don't believe that.

Brian

On Jun 19, 2013, at 1:25 PM, Dave Crocker <[email-masked]>
 wrote:

> This is Transition 101.  In the absence of an explicit indicator of support, checking for the data is blind; a query must be done every time, whether it will succeed or not.
> 
> Because there is not universal cut-over event, adoption is incremental.  The world starts with zero adoption and tries to move in a positive direction.
> 
> Until adoption is very widespread, the likelihood that a query will succeed is small because the proportion of adopters doing signing is small.  Vanishingly small.
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 11:58:34 -0700

> The counter argument is that by the time we deploy anything, that won't be true.  I don't believe that.

I don't recall commenting on the timing for specifying this, but rather 
that it be encapsulated as the gateway-specific mechanism that it is.

And that attention be paid to the classic adoption-barrier problem of 
having the receive side be forced to do a query everytime and blindly 
and with very small success rates in the early stages of adoption (if 
not longer.)

d/

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 19 Jun 2013 19:11:30 +0000

I don't want to drag us too far off course but would offer the following perspective on the timing of SIP interconnection and what we're trying to do here:
SS7 interconnection persists where there are SS7 endpoints. Where you have an SS7 originating point/network you are not going to get either inband or out of band to work (can't encode for inband; can't post for out of band.) Likewise, where you have an SS7 served terminating point/network you won't get it either  (can't access either validation mechanism; can't show the result to the called party).
That's the bad news. The good news is that end users are moving to IP and their carriers thus have incentives to do SIP interconnect. I think this will ramp up faster than some expect.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, June 19, 2013 2:59 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [stir] Out of band

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 19:19:41 +0000

SS7 is currently persisting in carrier interconnect because of tariff and other regulatory issues.  They may or may not get solved soon.  You are more optimistic than I.

If you have SS7 origination, and the identity is spoofed, nothing we are discussing will help.

If you have SS7 termination, but SIP origination, and at least one "good" SP in the path, we can fix the problem.

If you have SS7 in the middle, and we have at least one "good" SIP SP before the SS7 link, we can fix the problem, but we can't validate all the way through.

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 19 Jun 2013 15:40:14 -0400

Brian:  

You said> If you have SS7 origination, and the identity is spoofed, nothing we are discussing will help.

Talk me in off the ledge :-)  How does that realization not make this whole exercise one of chasing the roaches to the other side of the room?

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 19, 2013 2:20 PM
To: PFAUTZ, PENN L
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Out of band

Brian

On Jun 19, 2013, at 3:11 PM, "PFAUTZ, PENN L" <[email-masked]> wrote:

> Of Dave Crocker
> I don't recall commenting on the timing for specifying this, but 
> rather that it be encapsulated as the gateway-specific mechanism that it is.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 19:45:49 +0000

Because in most networks, it's actually hard to spoof in the TDM side.  Most carriers do a decent job of policing until they get to the SS7 network itself.
What I've seen, and I don't have statistics, is most spoofing is happening on SIP networks, because it's really easy to do it.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 20:29:16 +0000

> What scenarios, specifically?
An SBC that mangles the headers that were originally signed

> Until adoption is very widespread, the likelihood that a query will succeed is small because the proportion of adopters doing signing is small.  Vanishingly small.
That is exactly the same scenario for the in band mechanism.
The problem is that most calls today have at least one SS7 link

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 19 Jun 2013 16:51:12 -0400

I agree that it's almost certainly easier and cheaper to spoof your identity on VoIP.  That doesn't mean it's hard or expensive to do so on a TDM line though.  It just means that one is easy and the other is stupidly easy.  It is also true, at least in some cases, that carriers police TDM interfaces.  The classic "TDM loophole" for CPN spoofing is the ISDN PRI, which in theory supports the option of the calling party number (CPN) being user-provided and unscreened by the carrier.  Some carriers (e.g., Verizon) decline to support that option due to its potential misuse but I'm sure there are others that allow it.

Anyway, point taken, but still I hope we don't just make VoIP better by making POTS worse.  And I worry about the scenario that "the bugs just move to the dark side of the room", i.e., that attacks on VoIP endpoints continue unabated, originated on the PSTN side and using VoIP gateways as "force multipliers" to increase the damage they can cause.  By which I refer to the fact that the information elements that on the PSTN side would have identified the spoofed CPN as non-trustworthy, don't pass through the VoIP gateway.

tim

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Wednesday, June 19, 2013 2:46 PM
To: Dwight, Timothy M (Tim)
Cc: PFAUTZ, PENN L; [email-masked]; [email-masked]
Subject: Re: [stir] Out of band

Brian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 14:00:56 -0700

On 6/19/2013 1:29 PM, Rosen, Brian wrote:
>>> To be fair, there are some scenarios other than SS7 links where
>>> the information is lost.  If we go for an SS7-only solution, we
>>> don't cover those cases.  The mechanisms may be able to be used
>>> in other environments.
>>

So you expect every agent that creates a signature to also stash an
entry in the cache and every agent that wants to validate a signature to
check "the" cache if there's no signature?

If I'm not understanding the usage scenario you envision, please clarify
with details.

>> succeed is small because the proportion of adopters doing signing
>> is small.  Vanishingly small.
>
> That is exactly the same scenario for the in band mechanism. The
> problem is that most calls today have at least one SS7 link

No; it's entirely different.

The in-band mechanism carries the signal that it is signed.  Hence a 
query is in response to this affirmative indicator.  That is, the query 
is only done in the presence of an explicit indicator that it should be.

This is in contrast to the out-of-band query which is done as a blind guess.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 19 Jun 2013 21:08:43 +0000

> check "the" cache if there's no signature?
Details vary depending on exactly how this works.  In EKR's proposal, yes.  In the SS7 GW idea, it's the SIP->SS7 GW that writes the record and the SS7-SIP GW that queries.

> The in-band mechanism carries the signal that it is signed.  Hence a query is in response to this affirmative indicator.  That is, the query is only done in the presence of an explicit indicator that it should be.
> 
Okay, I misunderstood.  Yes, in EKR's you have to do the query on all incoming calls that don't have the in-band signature, which won't give you much useful data until it's well deployed, in mine, the SS7-SIP GW has to query on all incoming calls with the same small meager success early on.

But a query that returns no results is pretty cheap.  EKRs is more expensive, because he explicitly tries to make it hard to discover calling patterns, so the querier has to do work to find good results.

In mine, we have more trusted entities and we don't work as hard to avoid trolling the database.  Doesn't mean we ignore the problem, it's just a bit easier.

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Jun 2013 17:19:23 -0400

> I'm not trying to be difficult - I'm worried because in the BOFs that I've been to before, whether a problem is solvable in a useful/deployable fashion is often a criteria for getting a Working Gro…

When I think about BOFs, I draw the line differently.  I want to know that the solution space is ready for engineering.  That does not mean it will be easy; hard work and consensus build is okay.  However, I want to know that an interoperability specification can be achieved without further research.

Research problems should be diverted to the IRTF.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 14:19:40 -0700

Brian,

> Two mechanisms, got to be at least twice the cost

I was looking for something a bit more substantive.  But as long as you
are staying abstract, I'll note that a common clinical assessment about
increases to design complexity is that the cost of doubling the
mechanisms in a tend toward exponential increases in cost and risk, not
linear...

>> 2. What is a realistic estimate of the likelihood of major
>> benefit; in other words, why should we believe it will help enough
>> to warrant the added costs?
>

Given the query failure rate I cite, it won't solve it.  Not for a very,
very long time, if ever.  And by not solve I mean it won't have an
appreciable effect anytime soon.

To the extent that you disagree, please cite a detailed scenario that
will make a difference and then offer an example of something similar in
the last 20 years that was equivalently effective.

> That depends on the solution.  There are several of them, for sure.

My intent in asking the question was to look for substantive responses.

The questions are merely classic ones of the type used to analyze
design and use choices, so that the process isn't merely a random walk
down a lane of personal preferences and intuition.

Most schemes fail.  Considering concrete adoption barriers and value
propositions carefully beforehand tends to reduce the likelihood of
failure.

>> For example, the stated use is when the call request arrives
>> without the signature information; this will look exactly the same
>> as a call from a system that did not add the signature.  Initially
>> the latter will be far, far more common than the former.  Almost
>> no one will be signing.  Hence, the querying agent is going to be
>> making unsuccessful alternative checks essentially every time.
>> Failure rates at that level discourage adoption.

By saying "early-stage" I meant to focus not on the simple mechanics but
on the operational concerns present when there are few adopters.

When an ops person is asked to implement something new, their obvious
question is about the benefit that will be obtained.  Now.  Tell them
the benefit will be later and they will say that's when they'll deploy.

> Actually, some of us are worried that the problem of the out of band
> mechanism is that by the time we've deployed it, and sunk most of
> the cost, the problem goes away.

That sounds like an expectation of very fast deployment of the core
mechanism.  For telcos?  So, most of the world's telcos have already
promised to deploy the technology as quickly as possible?

> Others think that there will always be some barriers and the out of
> band mechanism has value for a very long time.

Which better matches typical Internet transition experiences.

> The costs are mostly the database itself, and the implementation in
> wherever it is done.  In EKR's idea, it's at the ends (device or
> services).  In the alternate idea I just described, it's in the
> gateways (or near them, a B2BUA could do it).

In terms of basic design, among various other concerns, I was struck by
the scheme's apparent reliance on a centralized mechanism.  For the
entire Internet.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 14:23:54 -0700

On 6/19/2013 2:19 PM, Russ Housley wrote:
> Hadriel:
>
>> I'm not trying to be difficult - I'm worried because in the BOFs
>> that I've been to before, whether a problem is solvable in a
>> useful/deployable fashion is often a criteria for getting a Working
>> Group created.  Or instead during the BOF we get bogged down with
>> lots of microphone discussion about the viability of solutions, and
>> run out of time resulting in a request for another BOF before
>> getting a Working Group.
>
> When I think about BOFs, I draw the line differently.  I want to know
> that the solution space is ready for engineering.  That does not mean
> it will be easy; hard work and consensus build is okay.  However, I
> want to know that an interoperability specification can be achieved
> without further research.
>

Russ,

Sorry, but now I'm even more confused than usual.

Given your note classes your perspective as being in opposition to 
Hadriels, please explain how "ready for engineering" means something 
different from "solvable in a useful/deployable fashion."

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 17:36:22 -0400

> An SBC that mangles the headers that were originally signed

Ugh, this is like deja vu all over again.  The reasons why an SBC *should* "mangle" the headers has been explained numerous times.  The reasons why most users should actually *want* them to be "mangled" by SBCs has been explained numerous times.  And the reasons why those headers aren't *necessary* to sign have also been explained numerous times.

Some of the info the SBC "mangles" is changed to actually make the call *work*, or because the owners of them *want* those fields to be changed.  Sending them un-changed in an out-of-band channel won't mean anything to the receiver of the call: it won't provide assurance of anything, and can't be used directly.

For example, 4474 signs the SDP body.  One of the purported reasons it does this is to protect the IP:port info of the media because it identifies the caller's media.  Let's ignore the fact that an IP address is not a user identity, and that RTP over UDP traffic is trivial to spoof, and that it doesn't actually identify the end host most of the time due to NATs/Firewalls anyway... let's instead just assume this IP:port SDP info reaches the far-end destination of the call in this out-of-band channel.  What would this IP Address actually mean??  It's not usable, because it's highly likely to be a private IP Address in someone else's private network.  And its not where the media will actually come from or go to, because the media needs to go to the SBC instead.  So what good does it do you to get it??

Or another example is 4474 signing the Contact.  The claimed reason for this was to prevent a MitM from changing the Contact such that it would be able to intercept future messages.  Again, let's ignore the fact it doesn't actually prevent the attack threat, because a MitM can insert Record-Routes all day long to achieve the same goal... let's just assume the Contact reaches the far-end in an out-of-band channel.  What would it mean to you?  What would you use it for?  And why should I let you learn my Contact URI, which typically contains my host IP Address?  SBCs change it in order to (1) make call scenarios work right, because certain call scenarios cannot work without changing the contact, and more importantly (2) to protect each party by hiding their IP Addresses;, because if someone calls my house, I don't expect that someone to learn my IP Address just because my phone rings or my answering machine answers; or vice-versa, if I call someone else I don't expect them to learn my IP Address just because I called them.

And some of the info the SBC "mangles" isn't actually necessary for an identity verification mechanism to work.  For example the Call-ID.  It's signed by 4474 as a means of preventing replay.  But we know it didn't have to be, that a different field could have been created for that purpose instead.  It was simply *convenient* to use it for 4474.

Let's face it: we screwed up with 4474.  We knew the problems with it, we had the debates about it, and we ignored the problems in the hope that the World would change to accommodate the IETF's vision.  It didn't.

-hadriel

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Jun 2013 17:41:29 -0400

Dave:

> ,Sorry, but now I'm even more confused than usual.
> 
> Given your note classes your perspective as being in opposition to Hadriels, please explain how "ready for engineering" means something different from "solvable in a useful/deployable fashion."

I'll try to be more clear.

Hadriel says that he is worried about spending BOF time on the viability of different solutions.  He fears that will take so much time in the meeting that we will not be able to get to the work needed to charter a Working Group.

I agree.  BOF time should be spent making sure that there is a solution space that will lead to an interoperability specification.  That is, make sure the work being considered is engineering, not research.  Once chartered, a Working Group can consider many different approaches, perhaps even specify a hybrid.

The point is that once the BOF is convinced that the solution is in the engineering space, no further time in the BOF session need be spent discussing the various different alternatives.  Hadriel correctly call that "bogged down."

Russ

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 14:47:46 -0700

> The point is that once the BOF is convinced that the solution is in the engineering space, no further time in the BOF session need be spent discussing the various different alternatives.  Hadriel c…

Ahh.  Yes, thanks.

I'll take that as your agreeing with the danger, but offering a view of 
how to limit it.

Simplistically I think means criticism of proposals need to assert and 
justify a claim that they won't work, rather than that one is better 
than another.[*]

Sure hope the bof chairs are good at enforcing that discipline... 
Sounds like fun.

d/

[*] of course, there are plenty of ratholes to go down with even this 
more constrained debate scope, but still...

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 19 Jun 2013 21:54:31 +0000

I don't think anyone here is particularly interested in retreading this
debate; I think we all agree STIR would be adopting a signature algorithm
that differs from RFC4474 in a way that is intended to make it possible
for it to survive SBCs.

I think how I'd cast what I think Brian was getting it was more like this:
there are going to be forms of B2BUAs, like PSTN gateways, maybe gateways
associated with other standard or proprietary protocols, whatever, that
are going to effectively remove the Identity headers no matter how
friendly we make them. That's just a fact of life. We want to try to
arrange things so that it won't happen as a part of ordinary SBC
operation, but again, I think the problem space of robocalling involves
all kinds of use cases where SIP is only used over part of the call path,
or potentially even none of it. The secure-origins-ps draft lists many
scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc.

If we had some capability to let the originating and terminating side
verify, more securely than what would get from hop-by-hop trust, that a
call setup attempt from the originating number is in place, a capability
that could work around these kinds of extremely adverse B2BUA conditions,
it would help the impersonation problem. Those of us who spun our gears on
the VIPR problem for a while know that this isn't trivial, but VIPR is at
least one (implemented and even deployed, though not widely used) example
of how Internet endpoints could discover one another as endpoints of a
call and use that out-of-band connection to enhance identity and security.

Clearly the knobs were not set in an ideal position for VIPR, so what we
want to explore is ways of addressing the problem space that will be more
likely to succeed. In part, that will extracting components out of the
very vertical and monolithic VIPR proposal: the CDS straw men are examples
of what one of those components would look like (roughly taking the place
of the VIPR DHT). I think many of us feel that the smartphone revolution
has created some new opportunities in this space that weren't around when
we first started working on all this. The way the charter is structured,
this out-of-band deliverable is placed after the we get done with the
Identity signature revisitation, so I don't think this would be the first
order of business. I do however think that we should define how that
system will interface with Identity, and how the credentials of the
systems are related (or different), and that it belongs in the scope of
STIR.

Jon Peterson
Neustar, Inc.

On 6/19/13 2:36 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>>>> To be fair, there are some scenarios other than SS7 links where the
>>>>information is lost.  If we go for an SS7-only solution, we don't
>>>>cover those cases.  The mechanisms may be able to be used in other
>>>>environments.
>>> 
>Ugh, this is like deja vu all over again.  The reasons why an SBC
>*should* "mangle" the headers has been explained numerous times.  The
>reasons why most users should actually *want* them to be "mangled" by
>SBCs has been explained numerous times.  And the reasons why those
>headers aren't *necessary* to sign have also been explained numerous
>times.
>
>Some of the info the SBC "mangles" is changed to actually make the call
>*work*, or because the owners of them *want* those fields to be changed.
>Sending them un-changed in an out-of-band channel won't mean anything to
>the receiver of the call: it won't provide assurance of anything, and
>can't be used directly.
>
>For example, 4474 signs the SDP body.  One of the purported reasons it
>does this is to protect the IP:port info of the media because it
>identifies the caller's media.  Let's ignore the fact that an IP address
>is not a user identity, and that RTP over UDP traffic is trivial to
>spoof, and that it doesn't actually identify the end host most of the
>time due to NATs/Firewalls anyway... let's instead just assume this
>IP:port SDP info reaches the far-end destination of the call in this
>out-of-band channel.  What would this IP Address actually mean??  It's
>not usable, because it's highly likely to be a private IP Address in
>someone else's private network.  And its not where the media will
>actually come from or go to, because the media needs to go to the SBC
>instead.  So what good does it do you to get it??
>
>Or another example is 4474 signing the Contact.  The claimed reason for
>this was to prevent a MitM from changing the Contact such that it would
>be able to intercept future messages.  Again, let's ignore the fact it
>doesn't actually prevent the attack threat, because a MitM can insert
>Record-Routes all day long to achieve the same goal... let's just assume
>the Contact reaches the far-end in an out-of-band channel.  What would it
>mean to you?  What would you use it for?  And why should I let you learn
>my Contact URI, which typically contains my host IP Address?  SBCs change
>it in order to (1) make call scenarios work right, because certain call
>scenarios cannot work without changing the contact, and more importantly
>(2) to protect each party by hiding their IP Addresses;, because if
>someone calls my house, I don't expect that someone to learn my IP
>Address just because my phone rings or my answering machine answers; or
>vice-versa, if I call someone else I don't expect them to l
> earn my IP Address just because I called them.
>
>And some of the info the SBC "mangles" isn't actually necessary for an
>identity verification mechanism to work.  For example the Call-ID.  It's
>signed by 4474 as a means of preventing replay.  But we know it didn't
>have to be, that a different field could have been created for that
>purpose instead.  It was simply *convenient* to use it for 4474.
>
>Let's face it: we screwed up with 4474.  We knew the problems with it, we
>had the debates about it, and we ignored the problems in the hope that
>the World would change to accommodate the IETF's vision.  It didn't.
>
>-hadriel
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 15:19:08 -0700

Jon,

On 6/19/2013 2:54 PM, Peterson, Jon wrote:
> that differs from RFC4474

RFC 4474's discussion of signature algorithm is quite limited, with a 
some quick referencs e to "sha1WithRSAEncryption as described in RFC 
3370".  And I don't think I've seen any serious concern about signature 
algorithms in this thread.

Rather, discussion has been about basic approaches to system design.  To 
the extent that a design includes signing, the algorithmic details 
aren't (and aren't likely to be) controversial.

In contrast, the system design is.

> in a way that is intended to make it possible
> for it to survive SBCs.

Perhaps I've missed it, but I don't think there are any proposals for 
survival, but rather one scheme that proposes something that invokes the 
"routing around" mantra popular on the net, to allow re-asserting the 
signature.

And it seems to be offered as an addition to an RFC 4474 base, rather 
than as an alternative to (differing from) it. That is, the proposal 
appears to be to use 4474 and then add a mechanism that attempts to 
"work around" destruction of the signature.

Please correct me if I'm wrong about these basic points.

Then the question for this added mechanism is whether it is at all 
viable in real-world scenarios and scale.

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 19 Jun 2013 22:31:07 +0000

>algorithms in this thread.

There will be some things to discuss there, I'm pretty sure.

>In contrast, the system design is.

I think there's room for controversy about both. I'm not sure you and I
entirely agree about what is the scope of the IETF when it comes to
"system design," but I definitely agree that in so far as the system
design impacts the design of the protocols we'd specify in the IETF, we
need to understand its characteristics.

>"routing around" mantra popular on the net, to allow re-asserting the

Well, the phrase you excerpted here was talking about the in-band work,
not the out-of-band work. The in-band work is indeed intended to create a
signature that would survival SBCs.

>"work around" destruction of the signature.

Correct. Broadly, the creator of a SIP request isn't going to be able to
tell whether or not there will be SIP end-to-end, and thus whether the
4474 signature will survive end-to-end. So yes, 4474 surviving is the
sunny day outcome. To plan for rainy days, both mechanisms could be
invoked roughly as you describe.

>viable in real-world scenarios and scale.

Sure.

Jon Peterson
Neustar, Inc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 20:51:15 -0400

> The counter argument is that by the time we deploy anything, that won't be true.  I don't believe that.

To be fair to your view, I don't think anyone really believes SS7 will be _completely_ gone in the sense of universal, no-exceptions, complete disappearance of SS7.  There'll always be some usage for many decades to come.  Even the hand-cranked human-operator-switched phones existed somewhere in the USA into the 1980s (someplace in Maine I think).  And someone probably still uses Token Ring, 5.25 inch floppies, and even Fore Systems ASX-100 switches.  ;)

I agree there'll be quite a bit of SS7, including between carriers, for the next 10, 20, or even 30 years from now.  That'll especially be true in specific countries and regions of the World, which probably don't need to be listed here.

But for the group of carriers/countries/enterprises that we care about - for the group that would even do anything new, for the group who even have IP on both "ends" to consider an IP-based out-of-band mechanism between each other, for the group who see the problem coming and are willing to do something to prevent it - for *that* group, I think SS7 interconnect is going away pretty darn fast.  And some of them already have SIP interconnect. (My previous employer sold thousands of SBCs just for interconnecting carriers, so it must happen somewhere!)

I think it's very hard to try to convince the "modern" carriers to spend even more money in order to support an ever-shrinking group of "legacy" carriers.  The business motivation here is backwards.

Having said that, I do also think we can at least specify how a STIR in-band model could work through SS7, for example in a UUI.  It might even be usable if the "SS7" portion is very short and well-managed.  We could never guarantee it would work, but it might in some specific cases of SS7 in-the-middle.

For the real legacy SS7 carriers, though... most of those won't be applicable to either STIR or an out-of-band mechanism, because they use SS7 in their whole TDM network, and obviously there's not a lot of new development going on in SS7 products.  These carriers don't offer SIP trunks, or SIP access of any kind.  Just POTS and PRIs.  The theory espoused on this list has been: such networks generate relatively good caller-IDs.  So even for an out-of-band approach, I don't see them getting certs, or using them, or verifying anything.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 18:10:05 -0700

On 6/19/2013 3:31 PM, Peterson, Jon wrote:
> I think there's room for controversy about both.

There's room for controversy about anything.  Or perhaps we could debate 
/that/...

Discussing and refining is defferent from debating what is 
controversial.  My point was about what's already established as 
controversial vs. what's likely.  Debating the details of a signing 
algorithm is not likely.  Debating approaches to the overall design of 
the authorization service already is controversial and it's likely to 
stay that way for awhile.

> I'm not sure you and I
> "system design,"

That part of your statement is surprising enough to me that I have no 
idea what you mean by system design.

As for me, I mean it in the usual way it's used in the IETF and 
elsewhere to refer to the definition and arrangement of components and 
their interactions to achieving any complete service.  In this case, 
that means the end-to-end components and their interactions, needed to 
establish authorization for a TN appearing in the From field.

In the IETF, a system is often characterized within an architecture or 
service description document.  Protocols are the rules of interaction 
between components.

> signature that would survival SBCs.

Brian just got done citing SBCs as an example of needing the out of band 
mechanism.

> invoked roughly as you describe.

So the design and operational requirement you've just defined is two 
entirely redundant mechanisms to be employed for every call.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jun 2013 21:16:57 -0400

I don't see any harm in providing guidance on how to carry things through SS7 clouds. This isn't likely to be all that complicated (we already have general carry-SIP-stuff-in-SS7 documents), and as long as we don't depend on it, the worst-case outcome is another RFC that nobody implements.

My suspicion is that the most common model will be that you've reached mostly "good guys" once you enter the first SS7 link. As long as that first SS7 gateway validates the SIP call, you're back to roughly the pre-VoIP status quo, i.e., mostly reliable caller ID. 

Henning

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 21:18:27 -0400

Let's take a step back for a second.

You believe an out-of-band mechanism can be made to work well.  You believe that it can avoid the problems of SS7, B2BUAs, etc., in the middle.  You believe that it can and will be successfully deployed and used, and will be deployed and useful before an in-band mechanism already handles things sufficiently end-to-end.

So I gotta ask: why would you advocate doing an in-band approach at all for this new WG, let alone doing it first before an out-of-band one??

I mean, given those beliefs for an out-of-band solution are true, the out-of-band solution should be able to handle pure end-to-end SIP calls too.  Right?  So why would the IETF ever need or want an in-band solution?  If people are going to deploy and use an out-of-band one eventually anyway, why should they bother deploying an in-band one that is purportedly inferior?

I mean it seems like a lot of people are going to be spending a lot of effort on whatever we do - not just effort in the IETF writing RFCs, but also in development, testing, documentation, training, deployment, evangelizing, communicating with other SDOs, etc.  Writing RFCs is the easy part really.

If you feel an in-band solution is insufficient to solve the problem at hand, then why should we spend so much effort on it if we're going to start all over again afterwards?

If, on the other hand, doing an in-band solution is sufficient to solve the problem at hand, why would we do something else afterwards?  For posterity?

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jun 2013 22:27:46 -0400

> I don't have numbers.  Henning might.  I know that some specific offenders have been traced and found, and they were using VoIP on their side.

No numbers, but all known offenders are indeed VoIP, as the cost properties make the "business model" of robocallers work far better than ISDN-equipped boiler rooms. Also, SS7 entities are usually regulated entities. Bad actors can be more readily identified, tend to be within the same country and have a legitimate fear that their (state) certificate of public convenience and necessity is put in jeopardy. There are also prohibitions against "phantom calls".

My presentation with background is at

http://www.cs.columbia.edu/~hgs/papers/2013/2013-source-identity.pptx

Needless to say, if we can solve SS7 issues as well, so much the better. I see those as largely orthogonal.

Henning

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 09:37:39 +0000

OK, good, thanks. And finally what if user=TN? (sip:[email-masked]) Does this fall into your "based on delegation of the number" category or on the "domain entry in the DNS" one?

I guess you're going to tell me that it's a "domain based identity" where the user just happens to be digits :)

I'm not arguing one way or another and have some sympathy with Paul's observation below; but I also realize as others did that we see loads of them in real life (always treated as phone numbers I mean). My guess is that in a stir environment two sip URIs sharing the same canonical form as I believe those two do (with and without user=phone), could be treated as the same by the (called) endpoint though.   

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, June 10, 2013 10:49 PM
> To: [email-masked]
> Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?
>

[snip] 

> I only bring this up because we may need to consider the implications of 
> one or the other. IMO sip:[email-masked] is a private uri 
> belonging to example.com. It may be intended by example.com to represent 
> a phone number, but I don't think anyone without special knowledge of 
> example.com's policies can trust that assumption. Certainly example.com 
> is free to use such a URI even if it has no rights to that phone number.

[snip]

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Wednesday, June 19, 2013 7:24 PM
To: FOUQUART Philippe OLNC/OLN
Cc: [email-masked]
Subject: Re: [stir] Do we agree on the basics?

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Jun 2013 13:46:34 +0000

You misunderstood what I said, sorry for my part of the confusion.
What I meant was, no matter what we do, we are sure to have some SBCs mangling whatever we need.  It's inevitable.  

I understand that what 4474 does is incompatible with how real networks are run, and we need to change the approach.  I believe we are discussing a canonical e.164 From and To, a timestamp and perhaps the INSIPID call id.  

I did not mean to imply that all SBCs will forever frustrate solving the problem.

Brian

On Jun 19, 2013, at 5:36 PM, Hadriel Kaplan <[email-masked]> wrote:

> Or another example is 4474 signing the Contact.  The claimed reason for this was to prevent a MitM from changing the Contact such that it would be able to intercept future messages.  Again, let's ignore the fact it doesn't actually prevent the attack threat, because a MitM can insert Record-Routes all day long to achieve the same goal... let's just assume the Contact reaches the far-end in an out-of-band channel.  What would it mean to you?  What would you use it for?  And why should I let you learn my Contact URI, which typically contains my host IP Address?  SBCs change it in order to (1) make call scenarios work right, because certain call scenarios cannot work without changing the contact, and more importantly (2) to protect each party by hiding their IP Addresses;, because if someone calls my house, I don't expect that someone to learn my IP Address just because my phone rings or my answering machine answers; or vice-versa, if I call someone else I don't expect them to l

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Jun 2013 13:51:37 +0000

It's not clear to me how any downstream entity is supposed to route a call like that.  If they follow RFCs, then they would route it to example.com.
If in fact they route it based on the +CC-YYYY e.164, then it's in scope as a TN based delegation cert.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Thu, 20 Jun 2013 10:05:43 -0400

Because we have increasing instances of calls that don't go through SS7 links.  Most of them are effectively "on-net", or between smaller service providers.  We will have, soon enough, IMS based interchange.  We would expect services like Skype to be able to use these mechanisms.

Eventually,  the things that are inhibiting direct SIP interconnect will get solved.

It won't be a flag day, but it will happen gradually. 

The bad guys will exploit whatever holes we leave them, so we need to cover both bases for a while.

EKR's idea has some longer term value.  My gateway idea is just a temporary work around for a temporary problem.

Brian

---

From: <[email-masked]>
Date: Thu, 20 Jun 2013 14:17:55 +0000

OK. In a Request-URI (I was thinking more of it in a From given the context) with a + sign upfront, the entities I'm familiar with would route it based on the TN and without it, some may even also do the same. One may argue that those entities are not meant to support anything else than TN-based sessions anyway. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, June 20, 2013 3:52 PM
To: FOUQUART Philippe OLNC/OLN
Cc: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Thu, 20 Jun 2013 11:12:15 -0400

Thanks, Henning.  The slides are helpful.

A couple of observations.

1) The set of mischievous actions enabled by anonymization seem equally enabled by simply omitting the calling party number (CPN).  In theory Anonymous Call Rejection (ACR) protects from the latter, but because so many calls fail to specify a valid CPN, few people use ACR.  They'd simply miss too many calls.  Point being that our solution needs to explicitly address this case.  Here's a very practical reason why:  although nobody seems to know how "big" the explicitly-signaled-invalid-CPN problem is, we do know how big the lack-of-valid-CPN problem is.  That helps when it comes time to build the case to deploy something.

2) We seem to have leapt quickly to a solution.  Were others considered and discarded?  If so can a summary of ideas-not-pursued, be provided?  Basically I'm looking for a summary of the normal problem analysis and solution requirements activities, so that I can understand why the solution being promoted is the best possible (or at least a reasonable) solution.

tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, June 19, 2013 9:28 PM
To: Rosen, Brian
Cc: Dwight, Timothy M (Tim); [email-masked]
Subject: Re: [stir] Do we agree on the basics?

Henning

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 12:41:13 -0400

I don't think it matters at all whether there's a 'user=phone' param or not.  Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire.  Whether there's a 'user=phone' or not, or even a leading '+' or not, if the user portion of the URI looks like a phone number and smells like a phone number, its treated as a phone number by virtually everyone.  It's been that way for many years in SIP.

At a high level, it doesn't matter how something appears on-the-wire.  If the terminating domain *treats* it as a phone number, and displays to the user only a phone number caller-id, then we need to validate it as a phone number.  Otherwise, if foo.com sends a From URI of 'sip:[email-masked]', and STIR treats it as an email-style name instead of E.164, but your phone displays '330145295813', then foo.com will have successfully spoofed your number.

The really important point/concept Brian made in another email thread earlier, I think, was the idea of determining a canonical E.164 number from the To/From URIs.  One of his points there was that sure the encoded number in the URI may have a prefix of digits, or is missing the country-code because it's in national form, or it has visual separators in it, or whatever.  But as long as the signer and verifier can both determine what the "real" E.164 numbers are that they need to sign/verify, then the actual user string in the URI doesn't matter.

At first I thought that idea was crazy - that it would be too hard to get systems along the path to be able to figure out a canonical E.164 automatically from random user strings they get in To/From URIs.  But then I realized that actually it's not hard at all, and that in fact it's done all the time.  It may require more-than-trivial configuration, but ultimately every carrier has to actually do that type of determination for every call that leaves/enters their domain.  Well ok, they only have to do it for international calls, but the point is a lot of them do this type of thing already.  And it's done by a lot of systems.  Even SBCs do it, using number translations or manipulation rules or whatever.

So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164 vs. an email-style name.  It would be based on the rules of the domain, and parameters like 'user=phone' can be ignored if the domain ignores it for routing and display purposes anyway.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 13:06:33 -0400

> I don't think it matters at all whether there's a 'user=phone' param or not.  Brian's right that that's what *should* be in the URI, but we all know that isn't what happens on-the-wire.  Whether th…

I have no problem with somebody using specific knowledge of how domain 
foo.example.com manages user parts to decide that the sip URI with that 
domain is a phone number, and then use the phone number to route the call.

But it is a serious problem if that is done *without* any knowledge of 
the target domain. Some issues with this:
- if you route the call to the PSTN, but foo.example.com doesn't have a
   connection to receive from the PSTN, its a problem.
- if the official mapping of the phone number part takes it to some
   other domain than foo.example.com, that's a problem.
- if you route it to the PSTN, and it does make it back to
   foo.example.com, then it may have lost important properties,
   like video.
- it may be that the user part only coincidentally is made up of
   digits that you happen to think look like a phone number.

If this is considered acceptable behavior, then we have effectively 
declared that all user parts that even remotely resemble a phone number 
are reserved, and can only be used in cases where gatewaying to PSTN is 
acceptable.

> So if we accept the fact that the signing and verifying domains can and will do a canonicalization step, I'd argue part of that step is deciding whether a received To/From URI is actually an E.164…

So as long as the part about "rules of the domain" really applies, and 
it isn't done if the rules of the domain aren't known, then I'm ok.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 20 Jun 2013 13:17:26 -0400

I think Hadriel got it right - if you will route it based on the phone number, then use a phone number based identity.  If you route it as a user@domain address, then use a domain based identity.  Both ends will use the same assumptions or the call won't get to the intended destination.

Brian

On Jun 20, 2013, at 1:06 PM, Paul Kyzivat <[email-masked]> wrote:

> I have no problem with somebody using specific knowledge of how domain foo.example.com manages user parts to decide that the sip URI with that domain is a phone number, and then use the phone number to route the call.
> 
> But it is a serious problem if that is done *without* any knowledge of the target domain. Some issues with this:
> If this is considered acceptable behavior, then we have effectively declared that all user parts that even remotely resemble a phone number are reserved, and can only be used in cases where gatewaying to PSTN is acceptable.
> 
> So as long as the part about "rules of the domain" really applies, and it isn't done if the rules of the domain aren't known, then I'm ok.
> 
> 	Thanks,
> 	Paul
> 
>> -hadriel
>> 
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 13:22:51 -0400

OK, but my point was that view is inconsistent.  The claims made are that an out-of-band is basically a completely-overlapping superset of the in-band: the out-of-band covers all cases, whereas the in-band does not.  The rationale for having an out-of-band is that in the near-term, we don't have SIP everywhere, so we need the superset out-of-band solution too.  This already implies we need the out-of-band *sooner* than we need the in-band.  But more importantly if the out-of-band is really possible, and really going to be deployed and used, then why should we bother doing the in-band at all, ever?

Right now you're asking for the charter to cover two mechanisms/models: an in-band and out-of-band.  The claim is it's worth our time and effort to do both, and that both have their place.  I assume the belief is both would be actually deployed and used, right?

I find it very hard to believe that.  I think if we can get one mechanism to be deployed, no one would do anything different.  Why would they??  Why should we spend the huge amount of effort it will take to do something once, and then do it all over again a second time?

My guess is you and Jon think the problem is we need a "stop-gap" solution that we can quickly specify and deploy, and *that's* what the in-band is for.  But that in the long term we need an out-of-band solution, and people will switch to that because the in-band won't work well enough in the long-term.

If that's the case, there's an existing solution we can use for a stop-gap short-term solution: P-Asserted-Identity.  No one has ever shown me a case of P-Asserted-Identity being spoofed.  It's not hard to spoof it, obviously, because it's purely based on transitive trust.  It doesn't work through SS7, but neither would a new in-band approach.[1]  In the long-term it will likely fail, and people will be able to inject into the trusted networks a false PAI header value that spoofs another number.  But the idea of even a new in-band solution not being good enough in the long-term must already be believed, for us to believe people will migrate to an out-of-band approach and make it worth our time.

-hadriel
[1] well... we might be able to get an in-band approach to work through short SS7 connections.  Maybe.

---

From: "Wendt, Chris" <[email-masked]>
Date: Thu, 20 Jun 2013 17:36:39 +0000

I personally would like to get away from user=phone, but as long as there is a authoritative domain for both TN and user based routing, I'm ok.

-Chris

---

From: Brian Rosen <[email-masked]>
Date: Thu, 20 Jun 2013 13:39:12 -0400

The arguments are somewhat different depending on what the out of band solution looks like.
If it's like EKR's approach, one could argue it could be the only mechanism. 
If it's like my alternate SS7 GW approach, then it can't.

However, the problem is that just doing something the way EKR proposes wouldn't solve the problem until it's nearly universally deployed.
That's because an intermediary can't check validity - only the end device or service can do that.  To stop the problem we're working on, we need intermediaries to refuse calls that don't have valid identity.  It's one of my problems with that approach, although I actually like it quite a bit.

I believe in most cases you would not see P-A-I on a "pink" carrier to "green" carrier interchange.  If you did, it would be a straight copy of what is in From.  Those carriers do not police, in any way, what their customers put on the signaling.  I think that most carriers accept calls from other carriers without PAI.  We could try to change that, but then all you would get is a copy of From.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jun 2013 10:42:43 -0700

On 6/19/2013 2:41 PM, Russ Housley wrote:
> BOF time should be spent making sure that there is a solution space that will lead to an interoperability specification.  That is, make sure the work being considered is engineering, not research.

Follow-on...

To be able to debate and agree on whether the work is in engineering 
space, there must be agreement on the problem(s) to be solved, with 
enough detail to guide the engineering-vs-research analysis.

The draft charter is piecemeal and generic about the problem statement. 
  It contains quite a bit of discussion, of course, but no simple, 
direct, statement of the problem to be solved or the actors that will be 
involved in operating the solution.

In fact, the current draft charter actually contains a work item to 
develop the problem statement.  I don't understand how the BOF can agree 
that the working group will operate in engineering space if there is not 
already an agreed, basic problem statement and agreement on the broad 
strokes of requirements for the solution.

Discussion on this list seems to move the problem statement around, in 
terms of the basic function(s) being sought and the actors it is 
intended to apply to.  I suggest honing this down to a consensus 
statement about what is needed and for whom.

Here are relevant bits of text that I've extracted from the draft 
charter, concerning the basic problem or the basic solution 
requirements, distinct from the details of how this is to be achieved:

   *  lack of security mechanisms for attesting the origins of real-time
      communications

   *  securing the origins of SIP communication

   *  lack of any real means of asserting authority over telephone
      numbers on the Internet

   *  work when one side of a call is in the PSTN – or potentially even
      both

 From the discussion on the list, I believe the basic problem statement 
for STIR is:

      Handling agents of SIP requests must be able to determine that use
      of a telephone number in the From field is authorized by the
      number's assignee.

An added piece is:

      An authorization mechanism needs to try to be robust against
      transitions through SIP Border Controllers, including transit
      through an SS7 network.

To the extent that these statements are inaccurate or incomplete, please 
suggest changes or replacement text.

Note that these statements don't mention any of the actors who assert 
the authorization.  I'm not sure whether that's needed, for this level 
of specification, but could easily imagine it is.

d/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jun 2013 13:45:54 -0400

> I think Hadriel got it right - if you will route it based on the phone number, then use a phone number based identity.  If you route it as a user@domain address, then use a domain based identity.…

Yes, I agree with this.

My point wasn't really a stir-specific issue. But it remains a concern.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 20 Jun 2013 13:49:39 -0400

Not sure what you mean by "get rid of user=phone".  A sip URI with user=phone is supposed to be directly convertible into a tel uri.  Are you arguing we should use tel uris as the only way to carry a telephone number based address?  Note that we're discussing using a canonical e.164 as the entity we're using for the identity, so how it's encoded in the SIP message won't matter in this work. 

Maybe you don't get what we mean by "canonical e.164".  Some examples:
From: sip:[email-masked];user=phone   Canonical e.164=+12025551212
From tel:+12025551212  Canonical e.164=+12025551212
From: sip:[email-masked] (routed as a TN)  Canonical e.164=+12025551212
From: sip:[email-masked] (in a PBX) Canonical e.164=+12025551212
From: tel:8005551212  Canonical e.164=+18005551212

By extracting the canonical e.164, we get a string that we can do a signature over that doesn't depend on that exact contents of From getting all the way through the network unchanged.  For example, the call could have a From in the first example rewritten to the second example by a downstream proxy, and when it gets to the endpoint, the canonical e.164 will be the same, and therefore the signature can be verified.

Brian

---

From: "Wendt, Chris" <[email-masked]>
Date: Thu, 20 Jun 2013 17:58:26 +0000

No, sorry, actually the complete opposite.  Depricate the use of tel uri. only use SIP URI.  (you quoted me wrong, didn't say get rid of, I said get away from)

-Chris

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Jun 2013 14:00:59 -0400

The IESG has approved a meeting slot for the STIR BOF.

Brian and I have been talking about the agenda, and with think that there are three primary chunks to the agenda: problem statement, solutions proposals, and draft charter.

I think that that a charter needs to characterize the problem, and it really needs to provide scope.  However, the WG can develop a more complete problem description as a document so long as it does not conflict with the scope set out in the charter.

Russ

= = = = = = = =

Problem Statement
Goal: determine scope

Solution Proposals
Goal: demonstrate that we are ready for engineering; this is not a research topic

Draft Charter
Goal: draft charter that is ready for review on the mail list and then IESG review

On Jun 20, 2013, at 1:42 PM, Dave Crocker wrote:

> To be able to debate and agree on whether the work is in engineering space, there must be agreement on the problem(s) to be solved, with enough detail to guide the engineering-vs-research analysis.
> 
> The draft charter is piecemeal and generic about the problem statement.  It contains quite a bit of discussion, of course, but no simple, direct, statement of the problem to be solved or the actors that will be involved in operating the solution.
> 
> In fact, the current draft charter actually contains a work item to develop the problem statement.  I don't understand how the BOF can agree that the working group will operate in engineering space if there is not already an agreed, basic problem statement and agreement on the broad strokes of requirements for the solution.
> 
> Discussion on this list seems to move the problem statement around, in terms of the basic function(s) being sought and the actors it is intended to apply to.  I suggest honing this down to a consensus statement about what is needed and for whom.
> 
> 
> Here are relevant bits of text that I've extracted from the draft charter, concerning the basic problem or the basic solution requirements, distinct from the details of how this is to be achieved:
> 
> From the discussion on the list, I believe the basic problem statement for STIR is:
> 
> To the extent that these statements are inaccurate or incomplete, please suggest changes or replacement text.
> 
> Note that these statements don't mention any of the actors who assert the authorization.  I'm not sure whether that's needed, for this level of specification, but could easily imagine it is.
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jun 2013 18:03:42 +0000

I view having multiple approaches that complement each other as insurance against our collective inability to predict deployment and non-engineering hurdles. The approaches discussed have different trade-offs, but they don't seem to conflict with each other. The cost to validate seems reasonably low, in terms of implementation complexity. (The infrastructure cost is higher, but that's where we can't really estimate with certainty what will happen, and that may well depend on countries.) For example, some approaches are more likely to be suitable for "self-help", informal and bottom-up deployment, others probably fit better into a coordinated "formal" environment.

We also seem to have champions and even proto-drafts for each, so it doesn't appear we'll lack for draft editors.

Yes, this imposes a burden on a small segment of the industry, but mail servers have learned to deal with multiple ways to do spam detection.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Thursday, June 20, 2013 1:23 PM
To: Brian Rosen
Cc: [email-masked]; Jon Peterson
Subject: Re: [stir] Out-of-band vs. in-band

-hadriel

On Jun 20, 2013, at 10:05 AM, Brian Rosen <[email-masked]> wrote:

>>> I don't think anyone here is particularly interested in retreading 
>>> this debate; I think we all agree STIR would be adopting a signature 
>>> algorithm that differs from RFC4474 in a way that is intended to 
>>> make it possible for it to survive SBCs.
>>> 
>>> there are going to be forms of B2BUAs, like PSTN gateways, maybe 
>>> gateways associated with other standard or proprietary protocols, 
>>> whatever, that are going to effectively remove the Identity headers 
>>> no matter how friendly we make them. That's just a fact of life. We 
>>> want to try to arrange things so that it won't happen as a part of 
>>> ordinary SBC operation, but again, I think the problem space of 
>>> robocalling involves all kinds of use cases where SIP is only used 
>>> over part of the call path, or potentially even none of it. The 
>>> secure-origins-ps draft lists many scenarios under consideration, including IP-PSTN, IP-PSTN-IP, etc.
>>> 
>>> If we had some capability to let the originating and terminating 
>>> side verify, more securely than what would get from hop-by-hop 
>>> trust, that a call setup attempt from the originating number is in 
>>> place, a capability that could work around these kinds of extremely 
>>> adverse B2BUA conditions, it would help the impersonation problem. 
>>> Those of us who spun our gears on the VIPR problem for a while know 
>>> that this isn't trivial, but VIPR is at least one (implemented and 
>>> even deployed, though not widely used) example of how Internet 
>>> endpoints could discover one another as endpoints of a call and use that out-of-band connection to enhance identity and security.
>>> 
>>> Clearly the knobs were not set in an ideal position for VIPR, so 
>>> what we want to explore is ways of addressing the problem space that 
>>> will be more likely to succeed. In part, that will extracting 
>>> components out of the very vertical and monolithic VIPR proposal: 
>>> the CDS straw men are examples of what one of those components would 
>>> look like (roughly taking the place of the VIPR DHT). I think many 
>>> of us feel that the smartphone revolution has created some new 
>>> opportunities in this space that weren't around when we first 
>>> started working on all this. The way the charter is structured, this 
>>> out-of-band deliverable is placed after the we get done with the 
>>> Identity signature revisitation, so I don't think this would be the 
>>> first order of business. I do however think that we should define 
>>> how that system will interface with Identity, and how the 
>>> credentials of the systems are related (or different), and that it belongs in the scope of STIR.
>>> 
>>> Jon Peterson
>>> Neustar, Inc.
>>> 
>> 
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 20 Jun 2013 19:19:50 +0000

Brian:
I think we pretty much have to reject the idea that intermediaries would be asked to refuse calls where the identity can't be validated. We could ask it to be flagged in some fashion perhaps but I wouldn't want to kill the call.  Right now US Federal regulations would prevent deletion of the CPN info.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, June 20, 2013 1:39 PM
To: Hadriel Kaplan
Cc: [email-masked]; Jon Peterson
Subject: Re: [stir] Out-of-band vs. in-band

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 20 Jun 2013 19:28:53 +0000

I think the in-band mechanism is going to provide better security overall
than out-of-band. That's why we use terms like "fallback" for out-of-band.
It's what you do as a last resort to still get some security when other
avenues fail you.

Jon Peterson
Neustar, Inc.

On 6/19/13 6:18 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>You believe an out-of-band mechanism can be made to work well.  You
>believe that it can avoid the problems of SS7, B2BUAs, etc., in the
>middle.  You believe that it can and will be successfully deployed and
>used, and will be deployed and useful before an in-band mechanism already
>handles things sufficiently end-to-end.
>
>So I gotta ask: why would you advocate doing an in-band approach at all
>for this new WG, let alone doing it first before an out-of-band one??
>
>I mean, given those beliefs for an out-of-band solution are true, the
>out-of-band solution should be able to handle pure end-to-end SIP calls
>too.  Right?  So why would the IETF ever need or want an in-band
>solution?  If people are going to deploy and use an out-of-band one
>eventually anyway, why should they bother deploying an in-band one that
>is purportedly inferior?
>
>I mean it seems like a lot of people are going to be spending a lot of
>effort on whatever we do - not just effort in the IETF writing RFCs, but
>also in development, testing, documentation, training, deployment,
>evangelizing, communicating with other SDOs, etc.  Writing RFCs is the
>easy part really.
>
>If you feel an in-band solution is insufficient to solve the problem at
>hand, then why should we spend so much effort on it if we're going to
>start all over again afterwards?
>
>If, on the other hand, doing an in-band solution is sufficient to solve
>the problem at hand, why would we do something else afterwards?  For
>posterity?
>
>-hadriel
>
>
>>gateways
>>first

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jun 2013 12:39:35 -0700

> It's what you do as a last resort to still get some security when other

Not quite.

In order for it to work, the caller must employ both mechanisms, for 
every call.

The only "fallback" is for the agent doing authorization checking.

d/

---

From: Brian Rosen <[email-masked]>
Date: Thu, 20 Jun 2013 15:40:00 -0400

Why is that?

I understand that there are regulations that would probably prohibit refusing calls, but we think that can and will be changed in order to fix the problem.

I don't think it works to just mark the call.  You are just pushing the problem downstream.  You can't send the call to the consumer.  It's not enough to just have some flag.

You probably can refuse calls that don't meet some signaling requirements, although we understand that you have some restrictions, Tim mentioned that.
We want to get to the point where invalid or missing identity doesn't meet your signaling requirements.  It's not so much that you are "killing calls".  It's that you require valid identity from your peering partners.   You might choose to monitor identity and, at some point, refuse to peer for example.  It might have a slowly decreasing percentage of allowable invalid/missing identity calls.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 15:46:24 -0400

On Jun 20, 2013, at 2:03 PM, Henning Schulzrinne <[email-masked]> wrote:

> I view having multiple approaches that complement each other as insurance against our collective inability to predict deployment and non-engineering hurdles. The approaches discussed have different trade-offs, but they don't seem to conflict with each other.

Umm... they quite clearly conflict with each other.  They're two alternative solutions to the same problem.  They have different deployment models and implementation logic.  Unless you mean they don't conflict in the sense that you could deploy both?  I mean "conflict" in the sense that they compete for the same resources: people, money, and time.  Having two solutions also makes it a lot harder to convince the people that need to actually deploy it.

How are we supposed to convince our companies, partner companies, customers, and other SDOs to do this stuff?  "Uh, well we need you all to do X right now, but there's a Y coming later that is deployed and managed and works differently that you'll have to do later too, because we think this X thing we want you to do right now won't work well..."

Obviously we can be wrong if we pick one solution.  There're a ton of DOA RFCs.  Heck, we can pick two or three solutions and still fail.  But to start out from the outset with the goal of developing two competing solutions generates its own set of problems.  Like for example interoperability when domain A does X and domain B does Y.  Or confusion in the marketplace.  Someone from Costco once explained it quite well: "Making people decide, that causes confusion, and they ultimately decide to walk away."

> The cost to validate seems reasonably low, in terms of implementation complexity. (The infrastructure cost is higher, but that's where we can't really estimate with certainty what will happen, and that may well depend on countries.) For example, some approaches are more likely to be suitable for "self-help", informal and bottom-up deployment, others probably fit better into a coordinated "formal" environment.
> 
> Yes, this imposes a burden on a small segment of the industry

I either agree with you, or strongly disagree - depending on how you mean that. :)

For *us*, the humans in an IETF working group, I agree it is a relatively small burden to discuss, propose and argue over multiple approaches to a problem in email.  It's a lot more burden for us to get them into published RFCs, but still in the grand scale of things it's a small burden for *us* to publish RFCs for competing solutions to the same problem.  It costs us more to talk about it in IETF meetings physically, due to the short time we get in IETF meetings for this stuff, but yes we could afford that.  Even the work required for some of us to explain this and get this into other SDOs (and we *will* need to do that), in the grand scale that's not a huge burden.

But for the people that actually have to do the hard part: vendors to implement it and carriers to deploy it... for them it's an *enormous* amount of work, and a huge segment of the industry if we really want this thing to work World-wide.

And it's going to cost money.  The equipment vendors may not charge their customers more for doing two mechanisms vs. one, but it does actually cost them more to do it.  And for the carriers it also really does cost more, because it takes more effort and resources.  They have to do more architecture planning, create more procedures, perform more testing, do more admin work, monitor more in their NOCs, do more training, troubleshoot more stuff, etc.  Depending on the deployment model for these STIR mechanisms, it may also cost them more to host stuff in servers or pay third-parties to do things for them, or consume more CPU resources on network equipment and thus cost for more equipment.  All this stuff costs real money.  They even bill some of it internally between departments.

And there's no "new" money for this - this stuff doesn't create a new revenue-generating feature, nor a feature one can use for competitive advantage.  This thing is just a cost sink: another red line item for opex and capex, with no black line to offset it.  It's got to be as cheap as possible.  And it's got to be something we think will actually *work*.  We can be wrong in the end of course, but we can't believe we'll be wrong from the start!

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 20 Jun 2013 19:59:15 +0000

True, I've said that from start.

Jon Peterson
Neustar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 20 Jun 2013 16:02:31 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, June 20, 2013 3:40 PM
To: PFAUTZ, PENN L
Cc: [email-masked]; Hadriel Kaplan; Jon Peterson
Subject: Re: [stir] Out-of-band vs. in-band

Why is that?

I understand that there are regulations that would probably prohibit
refusing calls, but we think that can and will be changed in order to fix
the problem.
[RS> ]   WHAT!  What are you thinking?   You really think there would be
some FCC or CRTC NPRM that would permit such behavior?  What possible
example could you site to come to that conclusion?  Do you have any clue
about the ongoing problem of rural call completion and what it has taken to
even realize the problem exists much less come up with some solutions and
it's not entirely clear those would work.  USF/ICC reform took 10 years.
Take a break and read a random selection of regulatory ex parte filings. 

I don't think it works to just mark the call.  You are just pushing the
problem downstream.  You can't send the call to the consumer.  It's not
enough to just have some flag.

You probably can refuse calls that don't meet some signaling requirements,
although we understand that you have some restrictions, Tim mentioned that.

[RS> ]  You can probably refuse calls from carriers that don't pay their
bills ..but that is another issue. 

We want to get to the point where invalid or missing identity doesn't meet
your signaling requirements.  It's not so much that you are "killing calls".
It's that you require valid identity from your peering partners.   You might
choose to monitor identity and, at some point, refuse to peer for example.
It might have a slowly decreasing percentage of allowable invalid/missing
identity calls.

[RS> ]  The only think that a carrier can do is negotiate a voluntary
bilateral interconnection agreement that states. You WILL NOT do <foo> and
you MUST do <bar> and place these headers in the right order..thank you very
much. 

Brian

On Jun 20, 2013, at 3:19 PM, "PFAUTZ, PENN L" <[email-masked]> wrote:

> Brian:
> I think we pretty much have to reject the idea that intermediaries would
be asked to refuse calls where the identity can't be validated. We could ask
it to be flagged in some fashion perhaps but I wouldn't want to kill the
call.  Right now US Federal regulations would prevent deletion of the CPN
info.
> Of Brian Rosen
> However, the problem is that just doing something the way EKR proposes
wouldn't solve the problem until it's nearly universally deployed.
> That's because an intermediary can't check validity - only the end device
or service can do that.  To stop the problem we're working on, we need
intermediaries to refuse calls that don't have valid identity.  It's one of
my problems with that approach, although I actually like it quite a bit.
> 
> I believe in most cases you would not see P-A-I on a "pink" carrier to
"green" carrier interchange.  If you did, it would be a straight copy of
what is in From.  Those carriers do not police, in any way, what their
customers put on the signaling.  I think that most carriers accept calls
from other carriers without PAI.  We could try to change that, but then all
you would get is a copy of From.
>> OK, but my point was that view is inconsistent.  The claims made are that
an out-of-band is basically a completely-overlapping superset of the
in-band: the out-of-band covers all cases, whereas the in-band does not.
The rationale for having an out-of-band is that in the near-term, we don't
have SIP everywhere, so we need the superset out-of-band solution too.  This
already implies we need the out-of-band *sooner* than we need the in-band.
But more importantly if the out-of-band is really possible, and really going
to be deployed and used, then why should we bother doing the in-band at all,
ever?
>> 
>> Right now you're asking for the charter to cover two mechanisms/models:
an in-band and out-of-band.  The claim is it's worth our time and effort to
do both, and that both have their place.  I assume the belief is both would
be actually deployed and used, right?
>> 
>> I find it very hard to believe that.  I think if we can get one mechanism
to be deployed, no one would do anything different.  Why would they??  Why
should we spend the huge amount of effort it will take to do something once,
and then do it all over again a second time?
>> 
>> My guess is you and Jon think the problem is we need a "stop-gap"
solution that we can quickly specify and deploy, and *that's* what the
in-band is for.  But that in the long term we need an out-of-band solution,
and people will switch to that because the in-band won't work well enough in
the long-term.
>> 
>> If that's the case, there's an existing solution we can use for a
stop-gap short-term solution: P-Asserted-Identity.  No one has ever shown me
a case of P-Asserted-Identity being spoofed.  It's not hard to spoof it,
obviously, because it's purely based on transitive trust.  It doesn't work
through SS7, but neither would a new in-band approach.[1]  In the long-term
it will likely fail, and people will be able to inject into the trusted
networks a false PAI header value that spoofs another number.  But the idea
of even a new in-band solution not being good enough in the long-term must
already be believed, for us to believe people will migrate to an out-of-band
approach and make it worth our time.
>>> Because we have increasing instances of calls that don't go through SS7
links.  Most of them are effectively "on-net", or between smaller service
providers.  We will have, soon enough, IMS based interchange.  We would
expect services like Skype to be able to use these mechanisms.
>>> EKR's idea has some longer term value.  My gateway idea is just a
temporary work around for a temporary problem.
>>>> You believe an out-of-band mechanism can be made to work well.  You
believe that it can avoid the problems of SS7, B2BUAs, etc., in the middle.
You believe that it can and will be successfully deployed and used, and will
be deployed and useful before an in-band mechanism already handles things
sufficiently end-to-end.
>>>> I mean, given those beliefs for an out-of-band solution are true, the
out-of-band solution should be able to handle pure end-to-end SIP calls too.
Right?  So why would the IETF ever need or want an in-band solution?  If
people are going to deploy and use an out-of-band one eventually anyway, why
should they bother deploying an in-band one that is purportedly inferior?
effort on whatever we do - not just effort in the IETF writing RFCs, but
also in development, testing, documentation, training, deployment,
evangelizing, communicating with other SDOs, etc.  Writing RFCs is the easy
part really.
>>>> If you feel an in-band solution is insufficient to solve the problem at
hand, then why should we spend so much effort on it if we're going to start
all over again afterwards?
>>>>> this debate; I think we all agree STIR would be adopting a 
>>>>> signature algorithm that differs from RFC4474 in a way that is 
>>>>> intended to make it possible for it to survive SBCs.
>>>>> 
>>>>> whatever, that are going to effectively remove the Identity 
>>>>> headers no matter how friendly we make them. That's just a fact of 
>>>>> life. We want to try to arrange things so that it won't happen as 
>>>>> a part of ordinary SBC operation, but again, I think the problem 
>>>>> space of robocalling involves all kinds of use cases where SIP is 
>>>>> only used over part of the call path, or potentially even none of 
>>>>> it. The secure-origins-ps draft lists many scenarios under
consideration, including IP-PSTN, IP-PSTN-IP, etc.
>>>>> place, a capability that could work around these kinds of 
>>>>> extremely adverse B2BUA conditions, it would help the 
>>>>> impersonation problem. Those of us who spun our gears on the VIPR 
>>>>> problem for a while know that this isn't trivial, but VIPR is at 
>>>>> least one (implemented and even deployed, though not widely used) 
>>>>> example of how Internet endpoints could discover one another as
endpoints of a call and use that out-of-band connection to enhance identity
and security.
>>>>> what we want to explore is ways of addressing the problem space 
>>>>> that will be more likely to succeed. In part, that will extracting 
>>>>> the CDS straw men are examples of what one of those components 
>>>>> would look like (roughly taking the place of the VIPR DHT). I 
>>>>> think many of us feel that the smartphone revolution has created 
>>>>> some new opportunities in this space that weren't around when we 
>>>>> first started working on all this. The way the charter is 
>>>>> structured, this out-of-band deliverable is placed after the we 
>>>>> get done with the Identity signature revisitation, so I don't 
>>>>> think this would be the first order of business. I do however 
>>>>> think that we should define how that system will interface with 
>>>>> Identity, and how the credentials of the systems are related (or
different), and that it belongs in the scope of STIR.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 16:03:04 -0400

> I understand that there are regulations that would probably prohibit refusing calls, but we think that can and will be changed in order to fix the problem.

We'd have to get to a point of virtually every carrier doing this thing, and with virtually zero false-positives.  That will take a long time.  In the meantime, we need something useful to do when we detect an invalid or missing verification, to make it worth deploying sooner, before we can start rejecting.

Otherwise you're going to have a bunch of pissed off citizens and corporate lobbyists.

> I don't think it works to just mark the call.  You are just pushing the problem downstream.  You can't send the call to the consumer.  It's not enough to just have some flag.

The logical thing to do would be to change the caller-ID to the same as when caller-id's aren't provided or are blocked: i.e, your phone displays "unknown" or whatever it does for those situations today.  Because basically that's the case: we don't know the caller-id.

When it gets more widely adopted, we could start sending invalid caller-id calls to an announcement server telling them why they're being blocked; or an IVR system that calls them back on the number they're claiming; or whatever.

If and when we get to a significant usage level of STIR and if it doesn't have false-positives, we could switch to actual "rejecting".

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jun 2013 13:11:03 -0700

> True, I've said that from start.

"It's what you do as a last resort" means exactly the opposite from 
"it's done for every call".

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 20 Jun 2013 20:12:30 +0000

I think our job is to design a protocol that has the right hooks for
policy and user interface to rely on, not to specify what those policies
or user interfaces are. When calls should be rejected is a policy
question, just like whether or not a phone should alert a user if the
caller is anonymous. If there are desirable policies or UIs that would
require different hooks than we're providing in the protocol, we should
fix that. Otherwise, this isn't for us to decide here.

Jon Peterson
Neustar, Inc.

On 6/20/13 1:03 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>>refusing calls, but we think that can and will be changed in order to
>>fix the problem.
>
>We'd have to get to a point of virtually every carrier doing this thing,
>and with virtually zero false-positives.  That will take a long time.  In
>the meantime, we need something useful to do when we detect an invalid or
>missing verification, to make it worth deploying sooner, before we can
>start rejecting.
>
>The logical thing to do would be to change the caller-ID to the same as
>when caller-id's aren't provided or are blocked: i.e, your phone displays
>"unknown" or whatever it does for those situations today.  Because
>basically that's the case: we don't know the caller-id.
>
>When it gets more widely adopted, we could start sending invalid
>caller-id calls to an announcement server telling them why they're being
>blocked; or an IVR system that calls them back on the number they're
>claiming; or whatever.
>
>If and when we get to a significant usage level of STIR and if it doesn't
>have false-positives, we could switch to actual "rejecting".
>
>-hadriel
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 20 Jun 2013 20:13:33 +0000

Obviously, by "you" I meant "the verification service."

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jun 2013 13:19:29 -0700

On 6/20/2013 11:03 AM, Henning Schulzrinne wrote:
> I view having multiple approaches that complement each other as insurance against our collective inability to predict deployment and non-engineering hurdles.

Henning,

Perhaps you know of examples of a global, multi-administration 
infrastructure service for the Internet, that has deployed two redundant 
mechanisms for doing the same task and succeeded, but I don't.  On the 
average, successful Internet services have been marked by relatively 
lean simplicity, not redundant, parallel functionality.

Hadriel's comments about costs and incentives are worth noting.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Jun 2013 16:32:44 -0400

> It's what you do as a last resort to still get some security when other

Oy vey.  Now we're talking about having shades of gray??

At the end of the day, some validating system has to make a choice: it's a valid caller-id or not.  They use that choice to determine whether to accept the call, or anonymize the caller-id, or shunt it to voicemail, or whatever.

What does it mean to have "some security" vs. "better security" for evaluating caller-id's??  I mean I understand that some security mechanisms will have more or fewer weaknesses - but I mean what difference will it make in the final outcome for calls, in practice?  What will the validating system do differently if it can only validate the caller-id in the out-of-band mechanism?

The system's operator has to configure it to either trust the out-of-band caller-id, or not at all.  If not, then it wouldn't even use the out-of-band method to begin with.

I assume you don't expect the verifier to note it to the human user and let the decision to be left to the human user, do you?  As you well know, most humans can't even figure out what a simple lock-icon means on a Web Browser, let alone if it's light green or dark green, or made of iron vs. hardened steel.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 20 Jun 2013 16:40:37 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Thursday, June 20, 2013 4:03 PM
To: Brian Rosen
Cc: [email-masked]; PFAUTZ, PENN L; Jon Peterson
Subject: Re: [stir] Out-of-band vs. in-band

We'd have to get to a point of virtually every carrier doing this thing, and
with virtually zero false-positives.  That will take a long time.  In the
meantime, we need something useful to do when we detect an invalid or
missing verification, to make it worth deploying sooner, before we can start
rejecting.

Otherwise you're going to have a bunch of pissed off citizens and corporate
lobbyists.
[RS> ]
[RS> ]  But the Federal Communications Bar Association would love it ...
Humm more billable hours!!

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 20 Jun 2013 20:49:49 +0000

Yes, I think there can be differences in how well two mechanisms like this
perform, and I don't think it's ridiculous to propose that we should use a
rely on one when possible, and the other when the first isn't possible.
"Better" here may mean working faster, requiring less network lookups or
less crypto operations. "Better" may mean not vulnerable to certain
classes of impersonation attacks that we care about, but know that we
can't beat in all cases.

Deployments may end up dictating what's possible. I can imagine a class of
pure PSTN endpoints (a smart phone without SIP, say) that can only do
out-of-band. I can imagine a class of SIP phones that can do in-band. I
can imagine that when I place a call, I don't know which class of device
I'm going to reach, and thus that I would want to supply both.

I don't think that translates into "shades of gray" or somehow
communicating that identity is semi-secure. As I said in a mail just a few
minutes ago, our job here (I think) is to provide the hooks for policy and
UI to plug into. I agree it's not our job to specify what color the
lockbox should be.

Jon Peterson
Neustar, Inc.

On 6/20/13 1:32 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>At the end of the day, some validating system has to make a choice: it's
>a valid caller-id or not.  They use that choice to determine whether to
>accept the call, or anonymize the caller-id, or shunt it to voicemail, or
>whatever.
>
>What does it mean to have "some security" vs. "better security" for
>evaluating caller-id's??  I mean I understand that some security
>mechanisms will have more or fewer weaknesses - but I mean what
>difference will it make in the final outcome for calls, in practice?
>What will the validating system do differently if it can only validate
>the caller-id in the out-of-band mechanism?
>
>The system's operator has to configure it to either trust the out-of-band
>caller-id, or not at all.  If not, then it wouldn't even use the
>out-of-band method to begin with.
>
>I assume you don't expect the verifier to note it to the human user and
>let the decision to be left to the human user, do you?  As you well know,
>most humans can't even figure out what a simple lock-icon means on a Web
>Browser, let alone if it's light green or dark green, or made of iron vs.
>hardened steel.
>
>-hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Jun 2013 05:52:53 -0400

> rely on one when possible, and the other when the first isn't possible.

Just to be clear: it's not "ridiculous" to propose anything.  I didn't use the word "ridiculous", and I'm not trying to ridicule anyone.

I'm just trying to understand why we need to have two mechanisms at all; because I believe it's a really big deal to have to deploy two.

> classes of impersonation attacks that we care about, but know that we

OK, but again what would it mean to the validation system?  You've said in-band might be more secure than out-of-band, that out-of-band may be more susceptible to impersonation attacks.  So let's say I receive an INVITE and there's no in-band and I try the out-of-band and it tells me the caller-id is indeed valid.  Now what?  You've just told me it's more susceptible to impersonation attacks.  Should I accept the INVITE?  Should I not?

*Of course* one mechanism may have more or fewer weaknesses.  But I don't see why that makes any difference for why we would want two mechanisms vs. one.  Or whether one is a primary vs. fallback.  Because at the end of the day, either a mechanism is good enough to trust the caller-id and allow the call, or it isn't.  If it's too weak to trust, then it's not usable at all even as a fallback.  If it's strong enough to trust as a fallback, then it's strong enough to be the one-and-only mechanism.  There are "no shades of gray". (btw, that's what I meant by using that phrase in my earlier email)

Unless you're thinking that the in-band will secure more than just the caller-id?  While the out-of-band only secures the caller-id? 

-hadriel

---

From: <[email-masked]>
Date: Fri, 21 Jun 2013 10:04:14 +0000

I guess we're saying the same thing. Maybe you're more liberal than I am and I'd have no problem with that :)

I do understand that if originating party/signer and terminating party/verifier both agree on a common implicit "context" for the digit string ("the user part I'll be sending is a number, no need for a user=phone or a '+', and I'll provide only the E.164 NDC-SN not the CC because my server can't do it and you can figure out it comes from country CC because I'll send it on trunk Y..."). I agree you don't need any particular syntactical elements to flag that it's a phone number and determine its canonical form and I know we sometimes have to do it for operational reasons.  

I would argue, however, that outside a limited remit (eg in-net or national calls, technical limitations of your vis-à-vis...), such practice doesn't scale well if the syntax you use is all over the place. It will generally become an O&M nightmare if you have as many agreements of that sort as you have interconnect bilaterals and that's why we try and stick to the identity formats defined in national or international SIP "profiles". 3966 might not be perfect in some respects but I think the principle of providing a canonical form whenever applicable or a context otherwise is well-grounded. It sometimes require very little effort for the originating party to provide a 'reasonably-canonical' form for what it sends and a lot more effort for the terminating party to manage a plethora of syntax variations and double-guess what the other guy meant (especially if you have three or four other guys in between...). 

Note, I'm not saying the solution that this group may come up with should preclude such practice (in as much as it could... indeed...) and as a matter of fact, I would hate this since as [you and] I said, it's not an uncommon operational practice. I'm just saying it's not something that should be recommended or at any rate that I would recommend as "proper engineering practice" (:-J) bearing in mind that there can be exceptions and we have to deal with those formats anyway. 

For the record, my phone may indeed display '330145295813' if "STIR treats it as an email-style name" but would definitely *reject* it "as an E.164" because it knows 0 is only the E.164 trunk prefix in the French dialing plan :) (don't hate me for this, it was hard to resist)

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Thursday, June 20, 2013 6:41 PM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 21 Jun 2013 13:22:21 +0000

For the purposes of this work, the notion is that you take the information from From (or possibly PAI, we have to work that out), whatever it is, and you extract the canonical e.164 from it.  We may not have to send it (unless it's already in that form).  You just extract it, and use it to compute the hash that is part of the signature.  So, we're not proposing to change any current practice.  You handle calls the way you do now.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Jun 2013 13:52:58 -0400

> I would argue, however, that outside a limited remit (eg in-net or national calls, technical limitations of your vis-à-vis...), such practice doesn't scale well if the syntax you use is all over th…

Just to be clear: I'm not suggesting anything change in the To/From/req-uri/etc. at all - they are whatever they are today, for you, in your network/systems.  If you ran wireshark, you'd see no difference. (well... other than there's a new "Identity" header or whatever)

Whether we have to get pre-agreement between the originator/signer and the terminator/verifier on this canonicalization is a critical subject - my *hope*, is that we can do it without needing any such agreement, because having to do that would basically kill the entire idea.

I'm half-way done with a draft proposing a new Identity header thing, that includes how the canonicalization works (or not).  I hope to get the draft submitted soon.  I was writing up a bigger draft on a way to replace all of 4474, using the DNS approach for holding certs, mostly to see if DNS would make sense for it or not, but that draft will take longer so I split out just the parts about a new header and signature.

> For the record, my phone may indeed display '330145295813' if "STIR treats it as an email-style name" but would definitely *reject* it "as an E.164" because it knows 0 is only the E.164 trunk prefi…

Hah! Ya know, I was actually considering looking online to see if the trunk prefix was part of the number or not before I sent the email, because every time I call Europe I get confused about whether to dial the '0' or not, and I *always* choose incorrectly.  So this time I thought to myself: "every time you chose before you get it wrong, and the obvious thing is the zero is not included, so the obvious thing must be wrong because you got it wrong every other time before, so clearly the zero *is* included."  And apparently I think that way every time. :(

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 14:25:10 -0400

On 6/20/13 1:49 PM, Brian Rosen wrote:
> Not sure what you mean by "get rid of user=phone".  A sip URI with user=phone is supposed to be directly convertible into a tel uri.

By my reading of 3261, you are stretching the definition of user=phone. 
3261 says:

          The set of valid telephone-subscriber strings is a subset of
          valid user strings.  The user URI parameter exists to
          distinguish telephone numbers from user names that happen to
          look like telephone numbers.  If the user string contains a
          telephone number formatted as a telephone-subscriber, the user
          parameter value "phone" SHOULD be present.  Even without this
          parameter, recipients of SIP and SIPS URIs MAY interpret the
          pre-@ part as a telephone number if local restrictions on the
          name space for user name allow it.

The above is unfortunately limited in many respects:

- it *doesn't* say "if the user string is *not* formatted as a
   telephone-subscriber then the user parameter value "phone" MUST NOT
   be present." But even so, I read between the lines and conclude that
   this is intended. So IMO <sip:[email-masked];user=phone>
   is a non-conforming usage.

- it most definitely doesn't say "if user=phone is present you may
   ignore the domain when routing the request." If a sip URI with
   user=phone were converted to a tel: uri then that would result
   in ignoring the domain when routing.

- I find the last sentence significant, because it talks about local
   restrictions on the namespace. Local to whom? IMO the only thing
   that makes sense is "if restrictions by the domain on the namespace
   for user name allow it." And that means you can't infer this
   unless you are *aware* of the namespace policies for the domain.

	Thanks,
	Paul

> Are you arguing we should use tel uris as the only way to carry a telephone number based address?  Note that we're discussing using a canonical e.164 as the entity we're using for the identity, so how it's encoded in the SIP message won't matter in this work.
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 21 Jun 2013 14:50:55 -0400

Yeah, I stretched, sorry.

I think the bottom line hasn't changed.  The originator can determine what the telephone number of the termination is.  It can take whatever URI is provided, and turn it into an e.164.  Right now, I think we can ignore calls within a domain where there may not be an e.164 (such as within a PBX without DIDs for each extension).

Brian

On Jun 21, 2013, at 2:25 PM, Paul Kyzivat <[email-masked]> wrote:

> By my reading of 3261, you are stretching the definition of user=phone. 3261 says:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 14:52:06 -0400

> No, sorry, actually the complete opposite.  Depricate the use of tel uri. only use SIP URI.  (you quoted me wrong, didn't say get rid of, I said get away from)

Let me get this straight:

You want to deprecate TEL?
And you want to not use (deprecate) user=phone?
And I suppose that also means you don't want to deprecate user=dialstring?

So I guess you just want to reserve all user parts that are all numeric 
to mean "some sort of phone number or dial string thing whose syntax is 
vaguely defined"???

Would you allow the use of the telephone-subscriber syntax from the tel 
URI (with "+", separators, paramters, etc.), or do you want to deprecate 
that too?

In that hypothetical world, is there any significance to the domain name 
in the URI? Are you in any way obligated to honor it when routing?

If we were to do these things, then URIs for telephone numbers would be 
entirely context sensitive. I could never tell by examination how to 
process one.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 14:55:11 -0400

+1

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 14:59:31 -0400

> I think the bottom line hasn't changed.  The originator can determine what the telephone number of the termination is.  It can take whatever URI is provided, and turn it into an e.164.  Right now,…

I think the issue is the one Philippe raised: if we don't impose *some* 
constraints on how numbers are represented, then the two ends may not do 
the canonicalization in a consistent way.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Fri, 21 Jun 2013 15:13:02 -0400

I think that the To part is pretty easy or the call wouldn't route.  The From may have some issues.  Specifically, you sometimes see local numbers and an international call couldn't easily determine the canonical e.164 from that at the termination.  We may have to do something there.

Brian

On Jun 21, 2013, at 2:59 PM, Paul Kyzivat <[email-masked]> wrote:

> I think the issue is the one Philippe raised: if we don't impose *some* constraints on how numbers are represented, then the two ends may not do the canonicalization in a consistent way.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 16:47:16 -0400

> And there's no "new" money for this - this stuff doesn't create a new revenue-generating feature, nor a feature one can use for competitive advantage.  This thing is just a cost sink: another red l…

What about the $5/month fee for "block spam calls"? :-)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Jun 2013 17:11:51 -0400

On Jun 21, 2013, at 2:52 PM, Paul Kyzivat <[email-masked]> wrote:

> So I guess you just want to reserve all user parts that are all numeric to mean "some sort of phone number or dial string thing whose syntax is vaguely defined"???
> Would you allow the use of the telephone-subscriber syntax from the tel URI (with "+", separators, paramters, etc.), or do you want to deprecate that too?

I think what Chris is saying is that in the real world that's generally the case: TEL URI is rarely seen, the existence or lack thereof for 'user=phone' is ignored, 'user=dialstring' is rarely ever seen, and all user names of digits do in fact require contextual knowledge that does not exist in the URI.

And the truth is he's right, at least in the majority sense.

But I think you're also right: in the IETF we can't deprecate or ignore them.  We need to have them to make our specs self-consistent, and we don't want to presume a specific deployment model and make different rules for each device in it, and we want it to be possible to handle digit-based usernames with a "do what I say not what I mean" model.  Whether they actually can be or not in the real world today doesn't matter - they could be if everyone followed the rules in the RFCs.

I'm not saying the IETF is wrong to ignore the real world - for one thing there's probably *some* SIP domain of SIP devices somewhere that actually follow the RFCs sufficiently to use that stuff, and for that reason we wouldn't deprecate it; and there are certainly specific SIP hops/devices in general where those rules do apply, and they're doing the "right thing", and for that reason we wouldn't deprecate it as well.

But for people actually using this stuff - building products, deploying it all, managing the service - for them it's frustrating that the IETF RFCs don't line up with the reality as shown by Wireshark.

Unfortunately there is no solution for this.  It's the nature of standards organizations to keep their specs self-consistent, to not change their view unless it can be proven that something's fundamentally broken if their view is followed, to not even be able to change their view unless it can be proven that absolutely no one follows it, etc.

And the IETF's not alone in having that problem.  The 3GPP IMS specs have the same problem - no one actually follows all the specs to-the-letter; not if you look at Wireshark traces.  Things would break if they tried to follow them precisely.  The same with the specs that many country-specific SDOs generate.

Thank god we have Wireshark. :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 17:31:29 -0400

> But for people actually using this stuff - building products, deploying it all, managing the service - for them it's frustrating that the IETF RFCs don't line up with the reality as shown by Wiresh…

And this will work for them as long as they live in their sheltered garden,

OR, as long as they deploy SBCs at the boundaries of their garden to 
preserve their naive assumptions.

So its no problem for you - its just a way to preserve your business 
model. :-)

But you are right that we (IETF) really don't need to, and probably 
shouldn't, worry aobut that, because that is a problem for the SBCs of 
the world.

What we define should actually work in and E2E model with no SBCs 
rewriting everything along the way. And then that should actually become 
a usable model for what ought to flow *between* SBCs, so that its not 
necessary to negotiate n^2 number transformations.

But I still have to ask:

Why *wouldn't* those using telephone numbers *want* to use TEL URIs for 
From, To, and P-A-ID headers? This eliminates those domain names that 
have no relevance to how the URIs are used. Is it simply "we don't do it 
that way and see no reason to change"?

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 21 Jun 2013 17:55:12 -0400

>
> I think what Chris is saying is that in the real world that's generally
the case: TEL URI is rarely seen, the existence or lack thereof for
'user=phone' is ignored, 'user=dialstring' is rarely ever seen, and all user
names of digits do in fact require contextual knowledge that does not exist
in the URI.
> But I think you're also right: in the IETF we can't deprecate or ignore
them.  We need to have them to make our specs self-consistent, and we don't
want to presume a specific deployment model and make different rules for
each device in it, and we want it to be possible to handle digit-based
usernames with a "do what I say not what I mean" model.  Whether they
actually can be or not in the real world today doesn't matter - they could
be if everyone followed the rules in the RFCs.
>
> I'm not saying the IETF is wrong to ignore the real world - for one thing
there's probably *some* SIP domain of SIP devices somewhere that actually
follow the RFCs sufficiently to use that stuff, and for that reason we
wouldn't deprecate it; and there are certainly specific SIP hops/devices in
general where those rules do apply, and they're doing the "right thing", and
for that reason we wouldn't deprecate it as well.
>
> But for people actually using this stuff - building products, deploying it
all, managing the service - for them it's frustrating that the IETF RFCs
don't line up with the reality as shown by Wireshark.

[RS> ]  Well the carriers are the institutions that have to support the STIR
mechanism and there WILL be some serious discussion about what practically
possible for deployment.  Personally I believe anything that looks like HTTP
is a non-starter. It will not deploy in the time frames envisioned.  Not
that I have a particular love for DNS. It's just I know what is actually
deployed and there is a LOT of DNS for number translations out there.  IN
the US that means virtually all Cable, Verizon FIOS, ATT uVerse and a
substantial amount of Enterprise SIP Trunking environments. Though SIP
redirect for intra-carrier routing is widely deployed as well.  

[RS> ] Every single institution deploying SIP either at the carrier layer or
enterprise is using a SBC.  There is no naivety here.  

So its no problem for you - its just a way to preserve your business model.
:-)

[RS> ]  Well it seems there a lot of companies looking to preserve business
models around here :-) .. but that aside SBC's exist for the practical
reasons Hadriel describes one AAA to be sure but normalizing the SIP headers
to actually make them work is the biggest reason.  CSCF and SIP proxy
vendors that write weird code that it takes Wireshark to decipher. 

But you are right that we (IETF) really don't need to, and probably
shouldn't, worry aobut that, because that is a problem for the SBCs of the
world.

What we define should actually work in and E2E model with no SBCs rewriting
everything along the way. And then that should actually become a usable
model for what ought to flow *between* SBCs, so that its not necessary to
negotiate n^2 number transformations.

But I still have to ask:

Why *wouldn't* those using telephone numbers *want* to use TEL URIs for
From, To, and P-A-ID headers? This eliminates those domain names that have
no relevance to how the URIs are used. Is it simply "we don't do it that way
and see no reason to change"?
[
[RS> ]  Well URI's do have some relevance when you see carriers actually
deploying various forms of SIP Interconnection among themselves and the To:
and From: in some cases actually identify the underlying carriers after the
first order number translation.   The preference is always for a fully
formed SIP URI vs Tel.  That's the way bi lateral NNI agreements are written
generally. 

I will argue rather aggressively that the protocol methodologies for STIR
need to be relatively compatible with the number translations for SIP
interconnection.  I simply can't imagine some new stack in the CSCF's in any
existing or future planned 3GPP IMS releases.  If anyone has any information
to the contrary I'd be very interested to know.  

	Thanks,
	Paul

> Unfortunately there is no solution for this.  It's the nature of standards
organizations to keep their specs self-consistent, to not change their view
unless it can be proven that something's fundamentally broken if their view
is followed, to not even be able to change their view unless it can be
proven that absolutely no one follows it, etc.
>
> And the IETF's not alone in having that problem.  The 3GPP IMS specs have
the same problem - no one actually follows all the specs to-the-letter; not
if you look at Wireshark traces.  Things would break if they tried to follow
them precisely.  The same with the specs that many country-specific SDOs
generate.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jun 2013 15:06:56 -0700

> rely on one when possible, and the other when the first isn't possible.

This sort of belts-and-suspenders approach has obvious appeal, for the 
reason you cite.  It also is massively expensive; and it might introduce 
some problematic interactions between the two.  (The cliche "if you have 
one watch you know what time it is; if you have two, you're never quite 
sure" comes to mind.)

Do you know of any examples of similar functional redundancy for 
critical infrastructure services on the Internet?  I can't think of one.

d/

---

From: Michael Hammer <[email-masked]>
Date: Fri, 21 Jun 2013 22:10:32 +0000

One might also question if one puts an E.164 number in the context of a
domain name, 
does that  rightly or wrongly assert that the number was assigned to that
domain?

If not belonging to that domain, then that is injecting an error into the
system.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Friday, June 21, 2013 5:31 PM
To: Hadriel Kaplan
Cc: Wendt, Chris; Brian Rosen; <[email-masked]>
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

On 6/21/13 5:11 PM, Hadriel Kaplan wrote:
>>> No, sorry, actually the complete opposite.  Depricate the use of tel 
>>> uri. only use SIP URI.  (you quoted me wrong, didn't say get rid of, 
>>> I said get away from)
>>

But I still have to ask:

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Jun 2013 18:33:54 -0400

> And this will work for them as long as they live in their sheltered garden,

Ironically, it is the IETF that lives in a sheltered garden.  A virtual-reality one.
I like that garden - it's very comforting to only see neat rows of beautiful plants and trees growing as you programmed them to.
It's much less fun to be in the real world with bugs and weeds and thorns, and plants trying to grow as they wish.

> OR, as long as they deploy SBCs at the boundaries of their garden to preserve their naive assumptions.
> So its no problem for you - its just a way to preserve your business model. :-)

You've known me and my efforts in the IETF have actually been the exact opposite.  That I've tried time and again to make things more interoperable, less complicated, and with a desire that SBCs *not* have to fix them.  That's why I spend time in the IETF - its not my day job.  If my goal was to have interop problems for SBCs to fix, I would leave the IETF alone and let it accomplish that goal for me.

> But I still have to ask:
> 
> Why *wouldn't* those using telephone numbers *want* to use TEL URIs for From, To, and P-A-ID headers? This eliminates those domain names that have no relevance to how the URIs are used. Is it simply "we don't do it that way and see no reason to change"?

There are actually several reasons, and we've talked about them before in SIP or SIPPING lists years back.  But it doesn't matter because it's too late now.  There's too much stuff deployed that doesn't support them.  And as I said you *will* certainly see TEL URIs on specific SIP hops, but they're converted to/from SIP URIs on each end of the hop. (e.g., on some inter-carrier SIP peering connections this happens)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jun 2013 22:36:31 -0400

Don't you find it rather silly and unfortunate that we have to rewrite 
all of the URIs in the message over and over as it transits the network, 
rather than using a context-free form that doesn't need to be rewritten?

Of course this is for the most part irrelevant *to stir*, *except* for 
whatever is used to sign the message. But it isn't going to work if the 
recipient of a request has to use the originator's local context to 
canonicalize the caller phone number in order to check the signature.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Jun 2013 03:02:08 -0400

On Jun 21, 2013, at 10:36 PM, Paul Kyzivat <[email-masked]> wrote:

> Don't you find it rather silly and unfortunate that we have to rewrite all of the URIs in the message over and over as it transits the network, rather than using a context-free form that doesn't need to be rewritten?

Yup.  Used to drives me nuts, because it requires a lot of configuration in a lot of systems.  But there're too many servers/phones/gateways/etc. where each vendor can only send/receive one format/schema, without something in common for them all.

And when carriers provide SIP trunks to Enterprise customers, there's already a PBX in the Enterprise and it does whatever format works for it, so the carrier can't make them change.  And when they peer with other carriers they can't make the other carriers change.  It's a quagmire.

So I decided to "just let go Luke" and let The Force guide me to things I have a chance of improving. :)

> Of course this is for the most part irrelevant *to stir*, *except* for whatever is used to sign the message. But it isn't going to work if the recipient of a request has to use the originator's local context to canonicalize the caller phone number in order to check the signature.

Well... I think it might actually work.  I mean yes - each domain has its own context for usernames - but they do actually know what the E.164 number is for that username in *their* context. (if the username could even be an E.164 at all - i.e., if it's not a short code or some other digit string that really doesn't represent an E.164 number)  

In other words, if you were to capture a SIP message with wireshark and show it to the operator who sent it, they could look at it and tell you what its full E.164 number is, even without having to look up a translation database or anything.  Because it invariably follows a pattern of some type for their network.  It may not be a trivial pattern, and it may have conditional rules, but it's a pattern.  And the pattern may look different in different spots of their network, but at any given point they'd know what pattern it follows there and how to turn it into an E.164 number.

So for the systems they use to sign the caller-id, they'll know what the pattern is at that point and can configure the system appropriately to internally generate the E.164 based on the pattern in order to sign it.  And the same goes for the verifier - wherever the verifying system is in the terminating domain, it too knows what it's locally-specific pattern is and it can determine the E.164 that was signed.

It sucks to have to do it this way.  It will take configuration on the signer/verifier systems.  I hate having to do things by configuration instead of automatically.  It's more work for the admin, and mistakes can cause hard-to-find errors, and it's brittle.  But I don't see a way around it for this STIR stuff, and it will work in the end.

I'm also thinking that we might want to consider copying these generated To/From canonical E.164 numbers into the Identity header - not the whole URIs, just the digits without any decoration, in a header param.  They wouldn't be used for caller-id displaying, nor routing, nor anything at a SIP layer.  They're to help with troubleshooting if the signature failed.  They wouldn't be covered by the signature hash, and they could even be optional to send.  Good-idea/bad-idea?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Jun 2013 09:25:34 -0400

> I'm also thinking that we might want to consider copying these generated To/From canonical E.164 numbers into the Identity header - not the whole URIs, just the digits without any decoration, in a…

You seem to be missing the point above:

*Of course* the sending operator (signer) can look at the original 
message and figure out what the corresponding E.164 is for the caller, 
and probably for the callee too. And so can use those to sign the message.

And presumably the verifier will be able to look at the received message 
and be able to figure out the E.164 number for the recipient, since it 
knows where it is going to be received.

But it is far from clear that the verifier will be able to look at the 
received message and be able to figure out the E.164 number for the 
caller. It may just see a localized form of that number that is 
meaningful in the caller's context. And without being familiar with the 
caller's context that isn't enough.

STIR *could* make an assumption (requirement?) that whatever value is 
used be rewritten along the path from signer to verifier so that the 
verifier will be able to do the verification. But if that is the intent, 
then it had better be stated with great clarity.

But I continue to find this rediculous - to depend on constant rewriting 
throughout the path of the message rather than canonicalizing at the 
endpoints. It is the antithesis of the E2E principal. (But as a 
precedent, it is exactly analogous to what NATs do.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Jun 2013 15:44:54 -0400

> What about the $5/month fee for "block spam calls"? :-)

I can't tell if you were being serious or not, so I'll reply in case you are. :)

Having a validated Caller-ID doesn't block spam calls.   It just reduces them, by removing the ones with spoofed caller-ids.  Just like I get tons of email spam from perfectly legitimate email addresses.  Would you pay $5/month for something that didn't actually block the spam calls?  We're already supposed to get do-not-call listing for free, and arguably beyond that it's hard to determine what is really spam vs. legitimate bulk-calling.

Would you pay $5/month for "no spoofed caller-ids" - i.e., just for legitimate caller-ids?  My guess is most every-day users expect they're already getting that, and that it's part of the service.

But having said that, it's definitely possible that certain corporations or organizations would pay for "verified" caller-ids.  So there probably will be some new revenue for some carriers for a time.  But for such a thing to work, it would require most numbers to be verifiable, which means most carriers doing it, which means most calls will be verifiable for everyone anyway, which means ultimately it won't be worth much to get what everyone else gets for free as part of their phone service.

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 22 Jun 2013 20:15:05 +0000

Unless the FCC always the carriers to block calls, the best that may be done is displaying the CgPN as verified 

Note there may be legitimate calls that are not verified 

Martin Dolly
AT&T 

Sent from my iPhone

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Jun 2013 16:30:01 -0400

On Jun 22, 2013, at 9:25 AM, Paul Kyzivat <[email-masked]> wrote:

> *Of course* the sending operator (signer) can look at the original message and figure out what the corresponding E.164 is for the caller, and probably for the callee too. And so can use those to sign the message.
> 
> And presumably the verifier will be able to look at the received message and be able to figure out the E.164 number for the recipient, since it knows where it is going to be received.
> 
> But it is far from clear that the verifier will be able to look at the received message and be able to figure out the E.164 number for the caller. It may just see a localized form of that number that is meaningful in the caller's context. And without being familiar with the caller's context that isn't enough.

Ahhh - so what you're saying is that canonicalization will work for the To-number, but not the From-number.  Sorry, missed that point in your original email.

> STIR *could* make an assumption (requirement?) that whatever value is used be rewritten along the path from signer to verifier so that the verifier will be able to do the verification. But if that is the intent, then it had better be stated with great clarity.

Right, I think that is a basic assumption and we could even write it in as a requirement.  And it's not as ludicrous as it sounds to do that.  For one thing, afaict it's actually the case today.  At least on SBCs, whenever I've seen rewriting of the To-URI, there's a corresponding rewrite of the From-URI.  In practice, operators of SIP domains do use the From-URI for stuff, so they rewrite them as they exit/enter domains.

But even if it *weren't* the case, that instead a terminating domain receives a From-URI in a format it can't determine an E.164 for, then it shouldn't be displaying it as a caller-id on its subscribers' phones.  So if the verification fails or is un-doable due to receiving such an unknown string, then arguably it's achieving the correct result: the caller-id is unverified.  Obviously at a high-level we don't *want* that to happen - we want to be able to successfully verify legitimate caller-ids, because otherwise from the user's perspective it's a false-positive - but over time those things will sort themselves out.

That's why I was wondering if we should put a copy of the E.164 numbers into the Identity header, to help the operators troubleshoot failures and sort them out.

> But I continue to find this rediculous - to depend on constant rewriting throughout the path of the message rather than canonicalizing at the endpoints. It is the antithesis of the E2E principal. (But as a precedent, it is exactly analogous to what NATs do.)

"Endpoints" have rarely ever been able to canonicalize.  They have no knowledge of "contexts", or what is or is not a phone number, or what is or is not an E.164 number vs. national vs. local vs. short code vs. star code vs. just a string of digits.  All they know is the user pressed digit buttons and a "call" or "send" button.  So they just put those digits into a SIP To-URI and req-uri user portion.  And they put the AoR they Registered into the From-URI, which again they don't know the semantics of but just use what they were configured to Register with.

Arguably that's one of the reasons few people use 'user=phone' and Tel-URLs and such, and rewriting happens a lot.  The RFCs assumed the endpoints were smart - that they'd somehow know the intentions of the human and the contexts of phone numbers, and put the right things in the To/From.  And then we told the Proxies not to change those To/From's, because doing that was "evil" and subverted the endpoints' intentions.  But in practice the endpoints are dumb and the 'proxies' are smart... at least for this topic anyway. ;)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Sat, 22 Jun 2013 22:01:05 +0000

Those who mangle the To and From headers tend to be the sort that are too
clever for their own good.
They tend to be of the hop-by-hop mind-set and don't quite get the E2E idea
of SIP.

Note:  Vendors can modify node behavior to do what is "right".  The existing
code base is flexible; it is software after all.
The hard part is getting industry consensus on what is "right".  Don't
underestimate the client, PBX, or SBC vendors ability to adapt.

It might be best to leave the Request-URI, To-, and Route- headers to be
mangled, and not confuse that with the source identity problem.
If we limited that scope, it might help keep this from trying to boil the
ocean.

The tendency of folks to get too creative is what usually leads to
regulation.
In this case, it may come to the FCC establishing rules for those that get
number assignments directly to enforce.

We should also not conflate the technical detail of ensuring validated
numbers in the signaling and the legal distinction of what is spam or not.
Thanks to our legislators and the various loop-holes (political calls
anyone?) that could change, we have no control of the latter, but might be
able to help with the former.
Also, as noted already, there may be cases where it is permissible to send
anonymous calls that might be dependent on the called party identity, 
but that is an exception that should not be too hard to handle, once the
basic rules are established.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Saturday, June 22, 2013 4:30 PM
To: Paul Kyzivat
Cc: Wendt, Chris; <[email-masked]>; Brian Rosen
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

On Jun 22, 2013, at 9:25 AM, Paul Kyzivat <[email-masked]> wrote:

> *Of course* the sending operator (signer) can look at the original message
and figure out what the corresponding E.164 is for the caller, and probably
for the callee too. And so can use those to sign the message.
> And presumably the verifier will be able to look at the received message
and be able to figure out the E.164 number for the recipient, since it knows
where it is going to be received.
> But it is far from clear that the verifier will be able to look at the
received message and be able to figure out the E.164 number for the caller.
It may just see a localized form of that number that is meaningful in the
caller's context. And without being familiar with the caller's context that
isn't enough.

Ahhh - so what you're saying is that canonicalization will work for the
To-number, but not the From-number.  Sorry, missed that point in your
original email.

> STIR *could* make an assumption (requirement?) that whatever value is used
be rewritten along the path from signer to verifier so that the verifier
will be able to do the verification. But if that is the intent, then it had
better be stated with great clarity.

Right, I think that is a basic assumption and we could even write it in as a
requirement.  And it's not as ludicrous as it sounds to do that.  For one
thing, afaict it's actually the case today.  At least on SBCs, whenever I've
seen rewriting of the To-URI, there's a corresponding rewrite of the
From-URI.  In practice, operators of SIP domains do use the From-URI for
stuff, so they rewrite them as they exit/enter domains.

But even if it *weren't* the case, that instead a terminating domain
receives a From-URI in a format it can't determine an E.164 for, then it
shouldn't be displaying it as a caller-id on its subscribers' phones.  So if
the verification fails or is un-doable due to receiving such an unknown
string, then arguably it's achieving the correct result: the caller-id is
unverified.  Obviously at a high-level we don't *want* that to happen - we
want to be able to successfully verify legitimate caller-ids, because
otherwise from the user's perspective it's a false-positive - but over time
those things will sort themselves out.

That's why I was wondering if we should put a copy of the E.164 numbers into
the Identity header, to help the operators troubleshoot failures and sort
them out.

throughout the path of the message rather than canonicalizing at the
endpoints. It is the antithesis of the E2E principal. (But as a precedent,
it is exactly analogous to what NATs do.)

"Endpoints" have rarely ever been able to canonicalize.  They have no
knowledge of "contexts", or what is or is not a phone number, or what is or
is not an E.164 number vs. national vs. local vs. short code vs. star code
vs. just a string of digits.  All they know is the user pressed digit
buttons and a "call" or "send" button.  So they just put those digits into a
SIP To-URI and req-uri user portion.  And they put the AoR they Registered
into the From-URI, which again they don't know the semantics of but just use
what they were configured to Register with.

Arguably that's one of the reasons few people use 'user=phone' and Tel-URLs
and such, and rewriting happens a lot.  The RFCs assumed the endpoints were
smart - that they'd somehow know the intentions of the human and the
contexts of phone numbers, and put the right things in the To/From.  And
then we told the Proxies not to change those To/From's, because doing that
was "evil" and subverted the endpoints' intentions.  But in practice the
endpoints are dumb and the 'proxies' are smart... at least for this topic
anyway. ;)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Jun 2013 21:31:01 -0400

> clever for their own good.

Umm... you mean the sort that want the calls to work? ;)

> They tend to be of the hop-by-hop mind-set and don't quite get the E2E idea

It *is* end-to-end - the rewriting is done by B2BUAs, so it's just a lot of ends.
:)

And to be fair, it's not every hop/node that rewrites this stuff.  Usually a given domain follows a consistent format/pattern/rule-set inside its domain, as much as possible.

> underestimate the client, PBX, or SBC vendors ability to adapt.

It is shockingly difficult to get vendors to change software code.  Even if you get them to agree to do it, it takes a surprisingly long time.  Besides, the motivation is backwards - the installed base has already sold their products and it's working, the new ones are the ones with motivation to adapt to the installed base, and that means the next round of new ones have that too, ad infinitum.  And when you're a carrier, your motivation is to add sip trunks from every Enterprise, so you generally don't tell them to go switch their gear out.  Likewise when peering with another carrier.

Changing the To/From URI model in a SIP domain is not a small thing - it affects almost every SIP system in the domain, not to mention the back-office stuff (which is a lot of stuff).  It's kinda like changing an ISP network from IPv4 to IPv6.

-hadriel

---

From: "Anton Tveretin" <[email-masked]>
Date: Sun, 23 Jun 2013 18:00:08 +0600

I agree with that. Validating the sender or caller does not stop spam 
completely. However, it could be enforceable to mark spam as such (there 
were ideas for e-mail, as start the subject line from $$$ AFAIK). It would 
be possible to block spammers who violate a convention. And pay $5/month for 
no spam at all, I think some businesses would buy it. Someone would prefer 
spam.

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, June 23, 2013 1:44 AM
Subject: Re: [stir] Out-of-band vs. in-band

On Jun 21, 2013, at 4:47 PM, Paul Kyzivat <[email-masked]> wrote:

>> And there's no "new" money for this - this stuff doesn't create a new
>> revenue-generating feature, nor a feature one can use for competitive
>> advantage.  This thing is just a cost sink: another red line item for
>> opex and capex, with no black line to offset it.  It's got to be as cheap
>> as possible.  And it's got to be something we think will actually *work*.
>> We can be wrong in the end of course, but we can't believe we'll be wrong
>> from the start!
>

I can't tell if you were being serious or not, so I'll reply in case you
are. :)

Having a validated Caller-ID doesn't block spam calls.   It just reduces
them, by removing the ones with spoofed caller-ids.  Just like I get tons of
email spam from perfectly legitimate email addresses.  Would you pay
$5/month for something that didn't actually block the spam calls?  We're
already supposed to get do-not-call listing for free, and arguably beyond
that it's hard to determine what is really spam vs. legitimate bulk-calling.

Would you pay $5/month for "no spoofed caller-ids" - i.e., just for
legitimate caller-ids?  My guess is most every-day users expect they're
already getting that, and that it's part of the service.

But having said that, it's definitely possible that certain corporations or
organizations would pay for "verified" caller-ids.  So there probably will
be some new revenue for some carriers for a time.  But for such a thing to
work, it would require most numbers to be verifiable, which means most
carriers doing it, which means most calls will be verifiable for everyone
anyway, which means ultimately it won't be worth much to get what everyone
else gets for free as part of their phone service.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 23 Jun 2013 08:33:18 -0400

On Jun 23, 2013, at 8:00 AM, Anton Tveretin <[email-masked]> wrote:

> I agree with that. Validating the sender or caller does not stop spam completely. However, it could be enforceable to mark spam as such (there were ideas for e-mail, as start the subject line from $$$ AFAIK). It would be possible to block spammers who violate a convention. And pay $5/month for no spam at all, I think some businesses would buy it. Someone would prefer spam.

There would also be companies willing to pay a lot more than $5/month to have the calls they make to everyone else *not* be treated as spam.  But undoubtedly many of those companies would be what you and I would consider to be spammers. ;)

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Jun 2013 15:36:17 -0700

> There would also be companies willing to pay a lot more than $5/month to have the calls they make to everyone else *not* be treated as spam.  But undoubtedly many of those companies would be what y…

This highlights a classic point of distinction that has proved very 
difficult for workers in the field to maintain in the email anti-spam 
world, and I'd expect the same to apply for the SIP world:  Everyone 
working in that space has been forced for nearly 20 years to focus on 
finding bad messages and obviously without the cooperation of the 
author.  In other words, to focus on the mis-trust side of the equation.

Adding authentication creates a collaborative exchange between 
origination and destination, with a mechanism that is inherently 
tailored for building trust, finding /good/ messages.  In some 
scenarios, there is a derivative ability to find wayward message, but it 
really is a secondary benefit of the approach.

One of the benefits of the trust side is that it's noise-free, whereas 
the mistrust side is massively noisy.  Noise-free means that you can 
believe /all/ the data you have for building a reputation on the 
identifier.  When the data are very noisy, you've no clean way to know 
what to use for reputation and what not to.

The trick for getting the trust side to work is building receive-side 
mechanisms that behave differently when they know they know who 
originated the contact and know that they are a good actor.

d/

---

From: "Wendt, Chris" <[email-masked]>
Date: Mon, 24 Jun 2013 02:26:33 +0000

> 
> In that hypothetical world, is there any significance to the domain name in the URI? Are you in any way obligated to honor it when routing?
> 

If I were to have my way, domain would be representation of the TN owners assertion.  Signing of the SIP URI would prove that ownership and that's what goes to the heart of what I believe we want to accomplish in this group.

So, yes I believe domain has everything to do with verification and tracability of the caller-id  (and yes the future of SIP peering and call routing too)

-Chris

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Jun 2013 23:07:18 -0400

> So, yes I believe domain has everything to do with verification and tracability of the caller-id  (and yes the future of SIP peering and call routing too)

I don't follow you. Consider a UA that is sending a request. It is given 
a phone number by the caller. A priori it doesn't know the domain name 
that owns the phone number. Yet it needs to form some sort of request in 
order to send the request. So what domain name does it use?

Then when the request is routed, is the request routed based on the 
domain name, or the number?

For example, the originating UA may insert some domain, then route to 
its outbound proxy, independent of either domain or number. That UA may 
have made the domain correspond to the domain of its provider, or not.

When the request reaches the outbound proxy, belonging to the caller's 
provider, if the domain of the r-uri is that of the provider, then of 
course it makes sense for the proxy to route the request further based 
on the number.

But if the r-uri does *not* contain the domain of the provider, what 
shall the proxy do? Should it honor the uri, and route based on domain? 
Or may it simply ignore the domain, translate the the r-uri based on the 
number and route it on based on that?

IMO, in the latter case it is obligated to route based on the domain of 
the r-uri.

	Thanks,
	Paul

---

From: "Wendt, Chris" <[email-masked]>
Date: Mon, 24 Jun 2013 03:16:53 +0000

In the context of STIR, I was referring mostly to the signing of the FROM address (caller), for example, ala RFC4474.

But for domain routing, for R-URI, there would need to be some e164.arpa lookup to provide SIP URI with authoritative domain.  But I think we got scolded for treading out-of-scope for discussing routing in this group already :)

On Jun 23, 2013, at 11:07 PM, Paul Kyzivat <[email-masked]> wrote:

> I don't follow you. Consider a UA that is sending a request. It is given a phone number by the caller. A priori it doesn't know the domain name that owns the phone number. Yet it needs to form some sort of request in order to send the request. So what domain name does it use?
> 
> Then when the request is routed, is the request routed based on the domain name, or the number?
> 
> For example, the originating UA may insert some domain, then route to its outbound proxy, independent of either domain or number. That UA may have made the domain correspond to the domain of its provider, or not.
> 
> When the request reaches the outbound proxy, belonging to the caller's provider, if the domain of the r-uri is that of the provider, then of course it makes sense for the proxy to route the request further based on the number.
> 
> But if the r-uri does *not* contain the domain of the provider, what shall the proxy do? Should it honor the uri, and route based on domain? Or may it simply ignore the domain, translate the the r-uri based on the number and route it on based on that?
> 
> IMO, in the latter case it is obligated to route based on the domain of the r-uri.
> 
> 	Thanks,
> 	Paul
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Jun 2013 01:00:56 -0400

> In the context of STIR, I was referring mostly to the signing of the FROM address (caller), for example, ala RFC4474.

[sorry for the length of this response; and this isn't about the above statement but rather just sharing viewpoints based on the general topic]

Yeah, I used to hold that view as well - that if the originating domains signed using their From domain name, then for domain names of big/well-known service providers like Comcast, we could just believe whatever the TN was they were claiming it to be.  I was thinking we could eventually create a reputation system for handling the smaller providers, such that the verifying systems in terminating domains would have a provisioned list of "trustworthy" providers it would believe caller-id's from and anything else would not be trusted.

I even wrote up a draft for doing rfc4474 in a way that could cross through SBCs/B2BUAs, that assumed that model:
http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01

But now I'm thinking it wouldn't have worked for long, or not well enough.

One problem is a reputation model is messy: it's prone to error, and hard to defend in court.  These 'pink' carriers that are letting the bad calls in would eventually have their domain name put on the naughty list as we intended, but then what?  You'd have to start blocking/redirecting *all* their calls or even just clearing *all* their caller-ids, instead of just their invalid ones.  So there'll probably be either law suits or complaints to the FCC.  They'll claim it was a few isolated incidents/errors or whatever, that you're either preventing competition or impacting a public utility, and demand to be put back on the good list.  The 'pink' carriers aren't necessarily shady fly-by-night operations - they could just be either under-managed or unaware.  They could be things like rural LECs or OTT providers, for example.

Another problem is it's really hard to determine thresholds for being bad.  We can't put providers on the naughty list just due to a few bad calls now and then - after all, mistakes are going to happen even for the biggest providers.  How many bad calls would it take to get on the naughty list?  Is it a different number per originator, because each originator is of a different size and generates a different volume of calls?  Is it a percentage of calls?  If you stay below the percentage, how do we stop you from doing so forever, and having bad caller-ids forever?

Another problem is if we want this to ever be usable for international calls, a reputation system gets super-messy.  There're thousands of providers in the world, and dealing with reputations for each of them is very hard.  Perhaps the big operators could handle it, but the smaller ones (e.g., rural LECs) wouldn't be able to.  You could try sharing reputation lists - but it'd be full of errors for the reasons I mentioned earlier.  Even for the large providers it would be a massive operational headache.

So now I'm thinking the only way to handle this thing is to know whether the originating domain truly has the right to claim a given caller-id number or not for a given call.  It needs to be something that's as automated as possible, to reduce operational burden.  And at the same time it has to avoid claims of prejudice if caller-ids are deemed invalid, by detecting which specific calls are illegitimate, having a low false-positive rate, and based on some common ultimate authority for the numbers.

It sucks because it's going to be really painful to do this stuff, whatever we end up doing; but no one's come up with an easier way so far.
:(

-hadriel

---

From: SM <[email-masked]>
Date: Sun, 23 Jun 2013 23:43:07 -0700

>Henning has some charts about the bad behind swatting, vishing and

What do these people have in common?

  Justin Bieber
  Russell Brand
  P. Diddy
  Ashton Kutcher
  Miley Cyrus
  Kanye West
  Justin Timberlake
  Selena Gomez
  Rhianna

Each of those cost LAPD USD 10,000/-.

Regards,
-sm

---

From: "Wendt, Chris" <[email-masked]>
Date: Mon, 24 Jun 2013 11:25:15 +0000

I can't totally disagree.  The world where service providers turn on basically spam filters and start blocking calls doesn't seem "right" and probably will be a hard pill to swallow, whether it's voluntary or regulated or whatever.

But I think at least you have traceability and at a minimum wholesale or trunking providers will have a clear signal to realize they are signing caller-id on behalf of their customers (or passing the responsibility to their customers) and therefore will be the first call from an "authority" whether regulatory or criminal or civil when bad things start happening.  This, in my opinion, will keep the system more honest, and maybe is the best state we can hope for in the end.

-Chris

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Jun 2013 11:10:37 -0400

> I can't tell if you were being serious or not, so I'll reply in case you are. :)

It was only half tongue in cheek.

My point was that if this is something that costs the providers 
something they will probably do their best to monetize it one way or 
another.

Maybe they'll just call it a "fee" with a name that makes it sound like 
a government regulation, even if it isn't, and certainly if it is.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Jun 2013 11:30:44 -0400

On 6/22/13 4:30 PM, Hadriel Kaplan wrote:
> But even if it *weren't* the case, that instead a terminating domain receives a From-URI in a format it can't determine an E.164 for, then it shouldn't be displaying it as a caller-id on its subscribers' phones.

Well, there is "shouldn't", and there is "SHOULD NOT", and there is "do" 
or "don't".

People want to see the caller id. So a provider has incentive to provide 
what it has.

I think I used to see this issue on Cisco phones for calls between Cisco 
locations. (Of course these probably never left the Cisco domain, so one 
might argue that the same rules don't apply.)

There were dialing rules that allowed short dial strings of various 
forms for dialing within a facility and between facilities, along with 
longer dial strings for dialing numbers outside. And routinely the dial 
string was displayed to the callee as the caller id. I don't recall what 
showed to someone outside Cisco. Most likely that was more correct.

It wouldn't have been a particular issue if the dialing rules were the 
same at every facility, but they weren't.

> So if the verification fails or is un-doable due to receiving such an unknown string, then arguably it's achieving the correct result: the caller-id is unverified.  Obviously at a high-level we don't *want* that to happen - we want to be able to successfully verify legitimate caller-ids, because otherwise from the user's perspective it's a false-positive - but over time those things will sort themselves out.

*IF* there was a way to display what you have, yet indicate that it is 
unverified, then that would be an improvement. Right now we don't have that.

It would then also provide the incentive for the caller to provide the 
caller id in a form that *can* be verified.

> That's why I was wondering if we should put a copy of the E.164 numbers into the Identity header, to help the operators troubleshoot failures and sort them out.

For the purpose of *stir*, putting the full E.164 numbers *somewhere*, 
early on, and carrying it all the way to the end, would be a solution.

I would *like* to see the same for To/From/R-URI, etc. but that is a 
discussion for a different forum, and it is harder to achieve.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 24 Jun 2013 16:11:41 +0000

> Just to be clear: I'm not suggesting anything change in the To/From/req-uri/etc. 
> at all - they are whatever they are today, for you, in your network/systems.   
> If you ran wireshark, you'd see no difference. (well... other than there's 
> a new "Identity" header or whatever)

Thanks, I misunderstood what you wrote. 

> Whether we have to get pre-agreement between the originator/signer and the 
> terminator/verifier on this canonicalization is a critical subject - 
> my *hope*, is that we can do it without needing any such agreement, because 
> having to do that would basically kill the entire idea.

I agree both that it's a critical point and that such an agreement shouldn't be necessary, hopefully. I also do not quite see how a system where the verifier would rely on prior knowledge of what the signer's conventions were would work - and scale. 

Maybe I'm missing something but assuming that both work on the canonical form where the user-param are removed, the only realistic alternative I can think of, given that this would in all likelihood be first implemented on a per country basis, may be to provide an 'identity' represented as the dial string in the national dialing plan or some variant of the kind, but
a) I guess this would require a "context" if we want a reasonable chance to see this adopted 'cross-border' and 
b) if every country applies its own logic it will turn into yet another O&M nightmare (see how we get confused with our respective trunk codes already... ;) 
(unless we assume that this identity format may vary depending on the CdP party, which I don't think is desirable either.) 

I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing plans and the added complexity for the receiver is in my view not worth it. 

Finally the irony of not providing a full canonical form is that an increasing number of user data profiles contains the subscriber number in its full E.164 format, so it may actually require *extra work* to provide a different format in a CgP-related header. (I'm not referring to R-Us which in the world I live in generally have to be manipulated as some point to see the light of the CdP party's endpoint or they'll just never get there - if this group were to address such use cases, the logic may have to be different IMHO)  

> I'm half-way done with a draft proposing a new Identity header thing, that includes 
> how the canonicalization works (or not).  I hope to get the draft submitted soon.  

Looking forward to that...

> Hah! Ya know, I was actually considering looking online to see if the trunk 
> prefix was part of the number or not before I sent the email, because every 
> time I call Europe I get confused about whether to dial the '0' or not, and 
> I *always* choose incorrectly.  So this time I thought to myself: "every time 
> you chose before you get it wrong, and the obvious thing is the zero is not 
> included, so the obvious thing must be wrong because you got it wrong every 
> other time before, so clearly the zero *is* included."  And apparently I think 
> that way every time. :(

:D... but I shouldn't smile: I apply the exact same logic to password variations *all the time*... with similar success but more embarrassing consequences :) 
Seriously though, the only case of this kind nearby here is I think the mobile range in Italy where 0 is both the first digit of the dialing plan and of the mobile NDC/SN, the others (that also use 0 I mean) actually follow E.164 recommendation to use it (only) as a trunk prefix.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, June 21, 2013 7:53 PM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 24 Jun 2013 16:52:16 +0000

I think a lot of it depends on how you understand "redundancy." How many
security systems that provide identity for email are out there in some
degree of use? There are technologies like PGP and S/MIME staged at the
client or end-user level, there are techniques like DKIM up at the domain
or intermediary level, and there are various places where mails are
analyzed to prevent spam that surely remove some mail from impersonated
identities. I'm sure we could add other technologies to that list. All of
them are to various extents overlapping and complementary to one another,
but all require a pretty different support infrastructure (some use PKI,
some use DNS, some something else) and deployment footprint. No single
thing solves the problem completely. I view the two prongs of the STIR
proposal in a similar light.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 10:10:38 -0700

Jon,

> I think a lot of it depends on how you understand "redundancy." How many

You are confusing the word competitive with the word redundant.  You are 
also confusing differences in functional intent with redundancy.

PGP and S/MIME are directly competitive.  They were established entirely 
independently, and not as backups to each other, as the current STIR 
proposal does for caller-id validation.

DKIM performs an entirely different function from PGP or S/MIME. 
There's nothing 'redundant' about it with them.

My question meant the word redundant according the the third definition 
listed in Miriam Webster:

      "serving as a duplicate for preventing failure of an entire system
      (as a spacecraft) upon failure of a single component"

      http://www.merriam-webster.com/dictionary/redundant

>  All of

OK.  So you are also confusing complementary with redundant.

SPF and DKIM are often classed as complementary.  There is a core 
similarity in their goals.  However they are entirely different 
mechanisms with substantially different semantics.  So while they cna be 
said to have some overlap, their semantics do not come close to 
overlapping completely.  Hence, their relationship is nothing like the 
redundancy being proposed for STIR.

Redundant means that two things are essentially the same.  Of the 
various examples you provided, only PGP and S/MIME are essentially the 
same.  And, again, they are competitive, not proposed for parallel, 
long-term use.  One /could/ sign a message with both, but I'm pretty 
sure I've never seen that done.

So my original question stands:

      Where else has the IETF had an orchestrated design for 
functionally redundant mechanisms to be used always and simultaneously?

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 24 Jun 2013 17:18:01 +0000

My point was that in so far as technologies like DKIM and technologies
like S/MIME provide strategies for protecting against impersonation (among
other things), their capabilities overlap. They do so by relying on quite
different deployments and security infrastructures. The parallel to STIR
is obvious.

To your refined question, about using two approaches "always and
simultaneously," some STIR deployments would be capable of doing both, and
yes under the model I at least have in mind they would do both. Others
will only be capable of doing one and will only do one. I mean, if my
email client can do S/MIME and I possess appropriate credentials, and my
domain has the proper infrastructure for DKIM, I would assume that my
identity in mails coming from me would always, simultaneously be protected
by both S/MIME and DKIM. Sure, it's kind of redundant, but not entirely
redundant. The two STIR prongs have similar properties, I believe.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 10:30:15 -0700

> different deployments and security infrastructures. The parallel to STIR

 From a sufficiently high altitude, everything looks the same.  Tree, 
mountain, car, whatever.

I meant my question to be substantive.  Not so abstract as to lose all 
utility.

> simultaneously," some STIR deployments would be capable of doing both,

I've queried once or twice explicitly about the redundancy and you've 
confirmed it.  This is the first time you've said "some".

That introduces a degree of uncertainty which automatically calls to 
question the utility.  If it's done sometimes and not others, what is 
the benefit?

Viable Internet protocols are not usually used that whimsical.

> and
> by both S/MIME and DKIM.

Jon, again, they are completely different semantics.  They are used in 
completely different ways and by different actors.  They are not 
redundant.

> Sure, it's kind of redundant,

No it's not.

Really, in spite of Alice being a common referent in security 
discussions, we are not in Wonderland and the meaning of terms isn't 
that fluid.  "Kind of" redundant doesn't compute.

An ascii 'a' apears in many different words in this email.  That does 
not make the words "redundant".  The fact that there are some components 
of DKIM and S/MIME that are similar does not make them redundant.

  but not entirely
> redundant. The two STIR prongs have similar properties, I believe.

1. They have exactly the same semantics.

2. They are proposed for simultaneous use by all callers.

/That/ is redundancy.

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 24 Jun 2013 17:59:22 +0000

It's pretty clear to me that both S/MIME and DKIM provide protection
against impersonation.

As for the two prongs of STIR and their differing applicabilities, several
times on the list, and in the drafts, we've noted that there are cases
where telephone calls don't use SIP at all, but it would still be useful
to prevent impersonation. If this hasn't been sufficient to explain why
only "some" cases would use both prongs of STIR, I don't think the problem
has been lack of clarity on our part. This has nothing to do with whimsy.

Similarly, I am surprised that it is unclear that the actors that would
use the two prongs of STIR are potentially different. Authentication and
verification services can be instantiated by intermediaries. The
out-of-band proposal is more likely to be staged at smart devices. The
parallels to comparable actors, and mechanisms, in the email space are not
merely the result of altitude sickness.

If those points remain murky, it probably wouldn't be helpful to
articulate the differences in scope or semantics of the proposed
mechanisms. Since they are only proposals, and their scopes may shift if
these become work items of the IETF, it's hard to speak to their eventual
shape. Suffice it to say that at least for the input documents I was
involved with, the in-band mechanism has more integrity protection in its
scope, for example. That alone illustrates that they don't have exactly
the same semantics.

Certainly there is considerable overlap, enough that in fact I think
handling these two work items in the scope of the same IETF group would be
very useful, in part to make sure that they reuse as much as possible.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 11:24:42 -0700

> It's pretty clear to me that both S/MIME and DKIM provide protection

A semi-trailor and a ferrari both provide transportation.

They are not redundant.

If S/MIME and DKIM were redundant, there would be an operational basis 
for using one in place of the other.  Since there isn't, they aren't.

> has been lack of clarity on our part. This has nothing to do with whimsy.

That explains the problem of concern.  No one has challenged the 
statement of the problem.

The issue is with the proposed solution, in terms of cost and likely 
utility.  And lack of precedent for such a design proposal.

> use the two prongs of STIR are potentially different.

You confirmed that both paths would be created by the same actor (the 
caller) for every call:

    http://www.ietf.org/mail-archive/web/stir/current/msg00423.html

> Authentication and

What do you mean "staged"?

What do you mean smart devices?  I don't recall their being cited in the 
proposal discussion so far.  How is the type of device relevant?

Simplistically, there are two functions at issue.  One is creating the 
authorization information.  The other is validating it.

In the message I cite above, you confirm that creation of both kinds of 
authentication information would be by the same actor, the caller.  Are 
you suggesting a different scenario now?

While perhaps different actors in the sequence would do validation, 
that's separate from having wholly redundant creation for every call.

> merely the result of altitude sickness.

Which kind of sickness is responsible?

> these become work items of the IETF, it's hard to speak to their eventual

Jon, you appear to be saying that making a proposal carries no ability 
to respond to questions about it or to otherwise concrete.  It sounds as 
if a proposal is to be adopted before it has serious substance or 
analysis.

Since I doubt that you mean that, I don't understand your difficulty at 
responding to rather basic concerns.

> scope, for example. That alone illustrates that they don't have exactly

Unless I've misunderstood the purpose of this work, data integrity is an 
entirely secondary function (or even tertiary.)  Let's not get 
distracted by differences that are secondary.

The primary function is checking authorization of the telephone number 
in the From field.  In this, the two mechanisms have exactly the same 
semantics, don't they?

> Certainly there is considerable overlap, enough that in fact I think

Having exactly the same primary function and producing exactly the same 
semantic result is not "overlap".  It is redundancy.

> very useful, in part to make sure that they reuse as much as possible.

The issue isn't where to do the development work, but the benefit of 
pursuing entirely redundant mechanisms.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jun 2013 18:25:47 +0000

I'd add at least two "overlapping" solutions that may have parallels, namely SPF and various DNS-based blacklists. Slightly further afield, you have the newer anti-malware protocols, such as

https://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec

Henning
________________________________________
From: [email-masked] [[email-masked]] on behalf of Peterson, Jon [[email-masked]]
Sent: Monday, June 24, 2013 12:52 PM
To: [email-masked]
Cc: [email-masked]; Brian Rosen
Subject: Re: [stir] Out-of-band vs. in-band

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 11:35:34 -0700

Henning,

Thanks for the followup.  I'm trying to draw a distinction between two 
things having "some" relationship vs. being wholly redundant.  SPF and 
blacklists have some relationship, but they are not at all redundant.

SPF is an objective, mechanical technique for checking authorization of 
a sever to send mail that has a particular domain name in the SMTP 
MailFrom command.  Success means the domain's use was authorized; 
failure means it wasn't.  Success does /not/ mean that the message is 
from a good actor.  SPF makes no assessment of actor quality.  It turns 
out that failure doesn't guarantee that it's from a bad actor. (Thank 
you, mailing lists and other intermediaries, as well as configuration 
errors and user mobility.)

Blacklists are highly subjective formulations of actor reputation. They 
offer a quality assessment.

While there can be correlations between the two, they are wholly 
independent mechanisms with wholly different semantics (although some 
blacklists might use operational patterns involving SPF when formulating 
entries.)

All of this is hugely different from having the caller exercising two 
semantically identical mechanisms for every call.  /That/ is what I mean 
by redundant.

Imagine that besides sending this email to the group, I sent the same 
message to everyone via IM.  THAT would be redundant.  Now imagine that 
each of us did that for every message we post to the group.  THAT is 
equivalent to what is being proposed for STIR.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jun 2013 19:08:18 +0000

The overlap, if any, is largely between S/MIME, SPF and DKIM, all related to origin authentication. (Yes, I recognize that they validate different parts of the mail message, but that's probably as meaningful a distinction to most users and sys admins as the difference between validating ANI and callerID, which are the rough moral equivalents in the PSTN space.)

That S/MIME also validates content is a good illustration - 4474 does the same thing (possibly signing media-related items), which out-of-band wouldn't.

The main difference between the two STIR modes discussed is between the actors involved and the likely deployment incentives. The in-band mechanism is likely to be deployed by carriers, the out-of-band mechanism by end users, such as legitimate call centers (and smart phones), for a variety of reasons already discussed at length. I'm guessing that many of us are hopeful that we'll get much closer to 100% coverage with two mechanisms than with one. The incremental validation effort is pretty minimal, and different entities have different incentives to deploy one or the other, possibly on different timelines.

For example, legitimate call centers and reverse-911 operations have incentives to deploy out-of-band mechanisms. They can't, in most cases, deploy in-band solutions.

Your main argument seems to be that this hasn't been done before. That argument seems to carry only so far, even for email.

Henning

________________________________________
From: Dave Crocker [[email-masked]]
Sent: Monday, June 24, 2013 2:35 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [stir] Out-of-band vs. in-band

Henning,

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jun 2013 19:21:45 +0000

Once you remove spoofing, there are two cases:

(1) The entity is located in the US and violates the do-not-call list and TCPA. They have now painted a fine-me target on their back. (Robocalls are strictly opt-in in the US for commercial use.) There is no do-not-email list equivalent, so the analogy doesn't quite hold.

(2) For entities that are on the borders of legitimacy, I suspect you'll see more crowd-sourced call blocking, as is already happening for smart phones. Right now, given the prevalence of spoofing, they are not very effective in reducing the total volume of robocalls. (You could still get dubious entities rapidly switching between legitimate numbers, but that's an expensive arms race, given that you'd probably have to get a new number every ten calls or so.)

(3) The entity is located outside the US. How did they get the ability to originate a signed call? If they had "help" by a carrier, that carrier has lost plausible deniability.

I would also hope that this can be a competitive differentiator, particularly for new entrants. Gmail, to pick one example, seems to have picked up a fair number of users based on the perception of its spam filtering mechanism.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Monday, June 24, 2013 11:10 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [stir] Out-of-band vs. in-band

        Thanks,
        Paul

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 12:22:22 -0700

Henning,

On 6/24/2013 12:08 PM, Henning Schulzrinne wrote:
> The main difference between the two STIR modes discussed is between
> the actors involved and the likely deployment incentives. The in-band
> mechanism is likely to be deployed by carriers, the out-of-band
> mechanism by end users, such as legitimate call centers (and smart

That's quite different from what Jon confirmed for me, namely that both 
would be done by the caller, every time.

For an exercise of the type being done now, it's extremely important to 
be very clear about the usage scenarios that are being proposed.

And so, just as an example, let's say the main model is a clean, 
end-to-end SIP-SIP, with an in-band authorization mechanism.  but then 
let's say there is a need to handle SIP-SS7-SIP, where the SS7 "hop" 
might lose the authorization information. Then one can reasonably 
imagine a special mechanism to handle the hop, such as stashing the 
information in a side cache to be retrieved in the SS7>SIP transition.

That's what I suggested a few days ago, but was instead told that the 
intent was to have the /caller/ do /both/ mechanisms /every time/.  That 
is, both are being proposed as full, end-to-end mechanisms.

At the least, it's important to get everyone sharing the same 
understanding of what is being proposed, in terms of its architecture 
and its usage.

Otherwise, we really are in Wonderland.  Where each person has whatever 
meaning they wish and no one can communicate.  Pessimal interoperability.

> phones), for a variety of reasons already discussed at length. I'm
> guessing that many of us are hopeful that we'll get much closer to
> 100% coverage with two mechanisms than with one.

Unfortunately there is just as much chance -- and maybe more -- of 
getting /less/.

Having two different mechanisms creates confusion about which to use, 
nevermind the added cost of everyone having to support both, which 
creates a disincentive to implement either.

 > The incremental
> validation effort is pretty minimal, and different entities have
> different incentives to deploy one or the other, possibly on
> different timelines.

I don't think I've seen reference to "incremental" validation and am not 
sure what you mean.  Neither of the two mechanisms being proposed sound 
incremental to me.

> For example, legitimate call centers and reverse-911 operations have
> incentives to deploy out-of-band mechanisms. They can't, in most
> cases, deploy in-band solutions.
>
> Your main argument seems to be that this hasn't been done before.
> That argument seems to carry only so far, even for email.

It's useful to know whether there is an experiential base for a 
paradigm.  When it exists, it helps to evaluate costs, utilities and 
risks.

That doesn't preclude innovation at the level of basic paradigms, of 
course, but it means that the risks are dramatically higher.

Most new paradigms fail.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jun 2013 19:23:56 +0000

You could imagine the equivalent of "block anonymous calls" service that's user-invoked ("block unauthenticated calls"), or interfaces to third-party services chosen by the user. They may, for example, enable that service if their call center is under attack or robocalls are flaring up.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Wendt, Chris [[email-masked]]
Sent: Monday, June 24, 2013 7:25 AM
To: Hadriel Kaplan
Cc: <[email-masked]>; Paul Kyzivat; Brian Rosen
Subject: Re: [stir] Domain signing vs. TN authorities (was: RE: URI     formats...)

-Chris

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jun 2013 19:29:58 +0000

To add one example: There are now a fair number of "hosted" telephony providers (Twilio is a well-known one). Just like hosting providers in the web space, I suspect you'd get the same problem Hadriel describes below for them. There are legitimate concerns that suppressing bad actors could also conveniently suppress unwelcome competition. Thus, a "no excuses" solution does seem called for.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Monday, June 24, 2013 1:00 AM
To: Wendt, Chris
Cc: <[email-masked]>; Paul Kyzivat; Brian Rosen
Subject: [stir] Domain signing vs. TN authorities (was: RE: URI formats...)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Jun 2013 20:24:33 +0000

We have some existence proof that numbers can be made reasonably uniform if they have to be - I suspect SS7 isn't terribly tolerant of lots of variations in either calling or called number formats, at least within a jurisdiction. Since most inter-provider calls touch SS7 at some point today, this seems analogous. (STIR is not really an issue for intra-provider calls since the caller is a direct customer of the provider.)

________________________________________
From: [email-masked] [[email-masked]] on behalf of Michael Hammer [[email-masked]]
Sent: Saturday, June 22, 2013 6:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

Mike

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

-hadriel

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Jun 2013 23:29:32 +0100

Apologies that I've not kept fully up with this thread, esp
if what I'm about to say has been said already:-)

I'm not sure that the in-band/out-of-band characterisation
is quite right. I'm not saying its not - I'm just not sure.

I can envisage that a call from Alice to Bob via Charlie
and then Dave might be such that a signature can be preserved
in-band between Alice and Charlie, and between Dave and
Bob, but that some out-of-band scheme might be required
for the hop between Charlie and Dave.

I don't know enough about the various signalling and
media handling magic to know if the above is a realistic
scenario or not, but if it is then the same call might
require both methods, where the signature (or
authorization) is sent as part of signalling messages
and also where the signature (or authorization) can't
be part of the signalling and some scheme like Ekr's
might be needed.

If that scenario is rubbish (quite possible) then no
need to read further:-)

If that Alice->Bob scenario is realistic and if its
important enough (I've no idea) then it'd also argue to
consider some aspects of the Charlie->Dave hop up front
in case that'd affect how the signature ought be
represented between Alice and Charlie or Alice and Bob.

Or maybe that scenario is realistic but just not
important at all, (again I dunno), and the WG would be
better off re-chartering before taking it on.

I guess this is a good topic for the BoF maybe. I think
I'd agree with folks who want to first prioritise the
more straightforward e2e approach that assumes that the
signature can make it from Alice->Bob.

S.

On 06/24/2013 08:22 PM, Dave Crocker wrote:
> paradigm.  When it exists, it helps to evaluate costs, utilities and risks.
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 00:06:45 +0000

You prove my point that since there is wide-spread non-standard usage for
From/To,
And because there is installed base inertia,
Relying on those headers for anything new is a non-starter.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, June 22, 2013 6:31 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

On Jun 22, 2013, at 6:01 PM, Michael Hammer <[email-masked]>
wrote:

> Those who mangle the To and From headers tend to be the sort that are 
> too clever for their own good.

> They tend to be of the hop-by-hop mind-set and don't quite get the E2E 
> idea of SIP.

It *is* end-to-end - the rewriting is done by B2BUAs, so it's just a lot of
ends.
:)

And to be fair, it's not every hop/node that rewrites this stuff.  Usually a
given domain follows a consistent format/pattern/rule-set inside its domain,
as much as possible.

> Note:  Vendors can modify node behavior to do what is "right".  The 
> existing code base is flexible; it is software after all.

It is shockingly difficult to get vendors to change software code.  Even if
you get them to agree to do it, it takes a surprisingly long time.  Besides,
the motivation is backwards - the installed base has already sold their
products and it's working, the new ones are the ones with motivation to
adapt to the installed base, and that means the next round of new ones have
that too, ad infinitum.  And when you're a carrier, your motivation is to
add sip trunks from every Enterprise, so you generally don't tell them to go
switch their gear out.  Likewise when peering with another carrier.

Changing the To/From URI model in a SIP domain is not a small thing - it
affects almost every SIP system in the domain, not to mention the
back-office stuff (which is a lot of stuff).  It's kinda like changing an
ISP network from IPv4 to IPv6.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 01:07:33 +0000

Agree so long as we stay away from dial strings or we fall of the cliff at
that point.

We also have to determine what it means if an E.164 is encoded as a user
part followed by a domain part.
Does that connote ownership or not?

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, June 24, 2013 1:25 PM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

We have some existence proof that numbers can be made reasonably uniform if
they have to be - I suspect SS7 isn't terribly tolerant of lots of
variations in either calling or called number formats, at least within a
jurisdiction. Since most inter-provider calls touch SS7 at some point today,
this seems analogous. (STIR is not really an issue for intra-provider calls
since the caller is a direct customer of the provider.)

________________________________________
From: [email-masked] [[email-masked]] on behalf of Michael
Hammer [[email-masked]]
Sent: Saturday, June 22, 2013 6:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

We should also not conflate the technical detail of ensuring validated
numbers in the signaling and the legal distinction of what is spam or not.
Thanks to our legislators and the various loop-holes (political calls
anyone?) that could change, we have no control of the latter, but might be
able to help with the former.
Also, as noted already, there may be cases where it is permissible to send
anonymous calls that might be dependent on the called party identity, but
that is an exception that should not be too hard to handle, once the basic
rules are established.

Mike

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

On Jun 22, 2013, at 9:25 AM, Paul Kyzivat <[email-masked]> wrote:

> message

> used

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jun 2013 01:17:35 +0000

I don't see why it would necessarily. It's clear that the request URI could just point to the next intermediary, such as an LCR or indicate temporary reachability via an intermediary (for From).

I probably missed why this would be helpful or necessary. I could see the case for deriving cert location information that way ("if you get sip:[email-masked], ask example.com for the cert for TN"), but explicit indication seems more general. If you just trust that AT&T would not use [email-masked] unless they are the holder of the number, you're back to the trust difficulties Hadriel has described.

Thus, unlike for regular [email-masked] cases, where 'alice' is clearly local to example.com, the use of a non-dial-string number in an inter-provider context would seem to indicate that this is indeed the identifier of interest and the domain is only a routing indicator, vaguely similar to having two IP addresses in mobile IP or various identifier-locator discussions. (Which I suspect none of us want to have on this list.)

________________________________________
From: Michael Hammer [[email-masked]]
Sent: Monday, June 24, 2013 9:07 PM
To: Henning Schulzrinne; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] URI formats (was RE:  Do we agree on the basics?)

Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 00:04:57 -0400

For identification/ownership I agree.

For routing, (even callback routing, to From URI) ISTM that if there is 
a domain, then it should be taken at least as a strong indication of 
preference that routing be done to that domain. That is perhaps out of 
scope here, except in cases where the callee saves the callerid, perhaps 
in an address book, for later contact. While this is outside the scope 
of what we can reasonably mandate, ISTM it would be useful to set 
expectations.

Of course this is irrelevant if the recipient is incapable of handling a 
SIP uri.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 01:18:33 -0400

On Jun 25, 2013, at 12:04 AM, Paul Kyzivat <[email-masked]> wrote:

> For routing, (even callback routing, to From URI) ISTM that if there is a domain, then it should be taken at least as a strong indication of preference that routing be done to that domain. That is perhaps out of scope here, except in cases where the callee saves the callerid, perhaps in an address book, for later contact. While this is outside the scope of what we can reasonably mandate, ISTM it would be useful to set expectations.

This is somewhat theoretical now, but yes I agree with you that if a UAS inside domain 'bob.com' received a request with a From-URI domain portion of 'alice.com', it should be able to use that whole From-URI as a To-URI later back. (or be able to use any received From-URI, for that matter)

But how is that germane to the issue at hand?  By that I mean the issue of determining an E.164 caller-id out of the received From-URI.

The problem is we'd be receiving things like this:
sip:[email-masked]
sip:[email-masked]
sip:[email-masked]
sip:[email-masked]

Technically in SIP URI syntax, none of those are phone numbers.  But users don't perceive such received From-URIs as email addresses.  They see it as a string of digits representing a phone-number.  Even if they were shown the full URI (which is rare), I bet many users would still perceive them as phone numbers.  And other deployed systems in the terminating provider also treat them as phone numbers - things like voicemail servers, IVRs, CNAM servers, conf bridges, billing systems, etc.  So if we don't try to verify it as a E.164, we'd be letting all 4 domains above claim the same number.  Then all robo-callers have to do is delete the 'user=phone' part to bypass STIR.

Or I guess to put this in a different way - *if* you're going to treat the user part as a phone number, *then* you need to canonicalize it as an E.164.

Maybe we can have some language like this:
If the terminating/verifying domain treats the user part of a received request's From-URI as a phone number for purposes of caller-id display or processing functions, then the verification system MUST internally generate a canonical form of the user part into the equivalent E.164 number for the phone number it would display/process.

OK?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 01:40:02 -0400

> Relying on those headers for anything new is a non-starter.

We're not relying on them - in the sense that we're not treating them as literal strings.
Instead, we're assuming the terminating domain has some means of determining what E.614 number a received From-URI represents.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 02:00:08 -0400

> I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing pl…

We could certainly have an RFC require the signing domain to generate a To/From URI of E.164 and 'user=part' and all, but I don't see how that would really succeed:

1) From a practical matter, legacy operators can't change all their systems to suddenly use a new format; so you'd be forcing them to do the signing function on their egress SBCs.  While I expect that to be a common scenario anyway, I don't think we'd want to force people to doing it there, or on any SBCs for that matter.  It should be possible to do the signing anywhere on any system type, so long as the signing system knows the caller can claim the E.164 number.

2) Even if the originator/signer does it that way, by the time the terminating domain receives the call it will have come through transit providers who already today change the To/From URIs.

> Finally the irony of not providing a full canonical form is that an increasing number of user data profiles contains the subscriber number in its full E.164 format, so it may actually require *extr…

Oh you don't have to provide it in a different format - if you provide it in an E.164 format today you can continue to with STIR, and you can even change from your current local format to using an E.164 format.  We just wouldn't be relying on everyone changing over, for STIR to work.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 02:19:02 -0400

> for the hop between Charlie and Dave.

That depends - if it's literally just a PRI link between Charlie and Dave, we can tunnel the info in an ISUP UUI.  There're even ways of doing that without requiring the PRI Gateway to be truly aware of it nor need to be upgraded, depending on the vendors involved.  If it's a full SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier connecting them, we might still be able to tunnel the UUI through.  But if it's the full-blown PSTN with multiple number of transit carriers between Charlie and Dave, we'd likely need an out-of-band thing.

The questions are: who the "we" are that would need such a thing, why we think they'd deploy it, who we think would pay for it, where we think they'd use it, how we think it would work, why we think it's manageable, why we think it's scalable, etc.  I know in IETF we don't always consider those things in advance, but I think when we don't then we waste an incredible amount of time specifying things people don't use much.  That's what happened with VIPR, TRIP, rfc4474, 

> be part of the signalling and some scheme like Ekr's

It's certainly possible that Alice and Bob can't get something through just with SIP.  Some calls might require two methods, some calls might require sixteen methods.  Right now, EKRs proposal is just a high-level concept (as I believe he intended it to be), so we can't tell whether it will work or not, how it gets deployed, who would/would-not use it, etc.  For example, his draft proposes a common third-party database-in-the-sky that both Alice and Bob use.  Who would run this database?  Who would I contact if something broke?  How does the database know Alice can claim the E.164 number she claims?  Is this database global, that everyone on the planet need to use it for it to be useful, or do we need to use umpteen such database providers to prove our caller-ids?

We don't always need to understand details of a proposed solution to create a WG to work on it, but we usually want to have some idea of it's applicability and likelihood of adoption before we do.

> signature can make it from Alice->Bob.

My guess is if we talk about this stuff at the BOF we're doomed - we'll never get off the microphones and get to consensus for creating a WG.
:(

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 03:05:59 -0400

> For example, legitimate call centers and reverse-911 operations have incentives to deploy out-of-band mechanisms. They can't, in most cases, deploy in-band solutions.

OK, so now we get to the heart of it.  The actors involved are different - one is for carriers, one is for smart-phone end-users and enterprises.  Those sets of actors have very different requirements, deployment constraints, regulatory and legal issues, call volumes, and vendors.  They also typically involve different participants in the IETF, and I'm pretty sure these two would.

Yes there may be some human and documentation overlap, but we have that across most every RAI working group.  And yes we'll have to prevent overlapping meeting times, but again we have those constraints (and tools to handle them) already for RAI groups.

But there are downsides to mixing the two together:
- they either starve each other for meeting time, or one wins most of the time and the other loses
- they distract the participants who don't care about the other, e.g. with all the emails in mailing lists such as this one
- they make it hard to judge interest and consensus, because half the group never cares about the other

I suggest these two separate mechanisms be split into separate WGs.  That way an out-of-band model can be worked on without waiting for the in-band to complete, and vice-versa.

-hadriel

p.s. Since 911 operators and call-centers use carriers in a similar (albeit not identical) fashion as most Enterprises, I would expect their carriers to be able to do the signing for them for an in-band solution.  But your point is taken, they may want to use other mechanisms - many more than two even - at the same time.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Jun 2013 12:48:08 +0000

I get that termination TN has to be able to be canonicalized, because routing has to work.

What do we do about From?

As it is today, can the terminating domain extract a canonical e.164 from what is actually sent?
Alternatively, is it reasonable for the ingress SBC to rewrite it so it can be?
Or do we need to send it somewhere else?
Or do we rely on P-A-I?

Brian

---

From: <[email-masked]>
Date: Tue, 25 Jun 2013 12:49:59 +0000

Hadriel,

We seem to be talking past each other. I interpreted your comment as: 
a) the signing of the TN - who may be done directly or on behalf of the holder - may use a non canonical form of TN,  
b) supposing in-band, that signing would then be conveyed in some way yet TBD untouched to the verifier, and
c) the verifier would then have to compute that "canonical form" to eventually assert authenticity.     

My comment was that I didn't see how the verifier could reasonably do c) without prior knowledge of the numbering plan of TN, so either the signer and the verifier implicitly share the function according to which you can translate the non canonical form into a canonical form (eg they are on the same dialing plan) or I don't see how this could work. Say TN=+12125551212, but a) signs 2125551212 how could c) be correct unless the verifier knows that it's an NANP number for which adding +1 upfront is enough to make it a full E.164 number?  

What am I missing here? 

I definitely don't want to force anyone doing anything with the format of their CLI, I was merely observing that, with the same examples, if a) proceeds with 2125551212 and c) is not in the NANP number or doesn't know it's an NANP number, then I didn't see how it could determine what canonicalization function to apply.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

> I understand it may not be the priority here but as a target I think that grand plan could remain in scope, and again, I think the extra flexibility for a signer is quite minimal in most dialing pl…

We could certainly have an RFC require the signing domain to generate a To/>From URI of E.164 and 'user=part' and all, but I don't see how that would really succeed:

-hadriel

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 08:54:43 -0400

I don't believe that the participants are at all different, and I don't think the charters would be different enough to warrant two groups.

I think that carriers care a lot about what devices do, and devices are increasingly able to handle things carriers do, so while I agree with Henning, I think the device wants to be able to check the signature if it makes it and the carrier wants to be able to check the out of band mechanisms on behalf of some endpoints.  I don't think anyone interested in this subject would not be on both lists and at both meetings.

We're all in agreement that we will complete the in band solution before we complete the out of band solution so it should be reasonable for chairs to manage the WG time effectively.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jun 2013 08:00:45 -0700

On 6/25/2013 5:54 AM, Brian Rosen wrote:
> We're all in agreement that we will complete the in band solution
> before we complete the out of band solution so it should be
> reasonable for chairs to manage the WG time effectively.

Excellent!

So the wg will initially focus on a pure-SIP scenario?

That is:

    Caller SIP UA -> SIP Op1..SIP OpN -> Callee SIP UA

If not, then what is the actual architectural mix of the STIR 
authorization service that will be targeted and how will it be handled 
by an pure in-band approach?

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jun 2013 15:09:13 +0000

I agree with the conclusion.

In most non-SIP trunking cases, the call will be converted to circuit-switched somewhere along the path, whether in the CO for analog trunks in traditional copper-ILECs or in the FiOS box in the basement or in the cable modem, all generating "regular" caller ID. Thus, this isn't a new problem and seems to be solvable in operational practice.

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Tuesday, June 25, 2013 1:18 AM
To: Paul Kyzivat
Cc: Henning Schulzrinne; [email-masked]; Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

OK?

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jun 2013 15:12:30 +0000

The signed entity would always be a full E.164 number, as the theory is that both calling and called carrier are able to derive that canonical format, as they need to do today for SS7 signaling, CNAM and intercarrier compensation. Thus, the originating carrier would never sign 212-555-1212, but only +12125551212.

________________________________________
From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Tuesday, June 25, 2013 8:49 AM
To: Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

Hadriel,

What am I missing here?

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 11:12:58 -0400

It doesn't have to be sip end to end to be effective.  It have to be sip to an SP that validates and does something with the results.  We've discussed, for example, requiring valid source identity as part of a peering relationship.

The in band mechanism as we have been describing it allows any element in the path to do the validation.

Brian

On Jun 25, 2013, at 11:00 AM, Dave Crocker <[email-masked]> wrote:

> If not, then what is the actual architectural mix of the STIR authorization service that will be targeted and how will it be handled by an pure in-band approach?
> 
> d/
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jun 2013 08:18:16 -0700

> The in band mechanism as we have been describing it allows any element in the path to do the validation.

Sure, but if it is not applied end-to-end, then what is its utility?

That is, if the later stages of handling are not covered by the 
authorization mechanism, traffic could have arrived through a separate 
path, over that same final sequence, that is not protected.

The processing nodes and user in that final sequence then have no way to 
distinguish valid from forged numbers.

I'm trying to understand the system-wide trust model being proposed.

d/

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 15:25:52 +0000

It is a pity we don't use the Route header to actually route.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, June 24, 2013 6:18 PM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

I don't see why it would necessarily. It's clear that the request URI could
just point to the next intermediary, such as an LCR or indicate temporary
reachability via an intermediary (for From).

I probably missed why this would be helpful or necessary. I could see the
case for deriving cert location information that way ("if you get
sip:[email-masked], ask example.com for the cert for TN"), but explicit
indication seems more general. If you just trust that AT&T would not use
[email-masked] unless they are the holder of the number, you're back to the
trust difficulties Hadriel has described.

Thus, unlike for regular [email-masked] cases, where 'alice' is clearly
local to example.com, the use of a non-dial-string number in an
inter-provider context would seem to indicate that this is indeed the
identifier of interest and the domain is only a routing indicator, vaguely
similar to having two IP addresses in mobile IP or various
identifier-locator discussions. (Which I suspect none of us want to have on
this list.)

Mike

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 15:30:42 +0000

Hadriel,

I support having some rules that make sense, but I seem to recall you saying
that it will be extremely difficult to get all those SBC and PBX to change
their handling of those fields.

Which is it?  Can we expect some rules to be imposed, or do we need to
establish a new header to do this?

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, June 24, 2013 10:19 PM
To: Paul Kyzivat
Cc: Henning Schulzrinne; [email-masked]; Michael Hammer; [email-masked];
[email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

On Jun 25, 2013, at 12:04 AM, Paul Kyzivat <[email-masked]> wrote:

> For routing, (even callback routing, to From URI) ISTM that if there is a
domain, then it should be taken at least as a strong indication of
preference that routing be done to that domain. That is perhaps out of scope
here, except in cases where the callee saves the callerid, perhaps in an
address book, for later contact. While this is outside the scope of what we
can reasonably mandate, ISTM it would be useful to set expectations.

This is somewhat theoretical now, but yes I agree with you that if a UAS
inside domain 'bob.com' received a request with a From-URI domain portion of
'alice.com', it should be able to use that whole From-URI as a To-URI later
back. (or be able to use any received From-URI, for that matter)

But how is that germane to the issue at hand?  By that I mean the issue of
determining an E.164 caller-id out of the received From-URI.

Technically in SIP URI syntax, none of those are phone numbers.  But users
don't perceive such received From-URIs as email addresses.  They see it as a
string of digits representing a phone-number.  Even if they were shown the
full URI (which is rare), I bet many users would still perceive them as
phone numbers.  And other deployed systems in the terminating provider also
treat them as phone numbers - things like voicemail servers, IVRs, CNAM
servers, conf bridges, billing systems, etc.  So if we don't try to verify
it as a E.164, we'd be letting all 4 domains above claim the same number.
Then all robo-callers have to do is delete the 'user=phone' part to bypass
STIR.

Or I guess to put this in a different way - *if* you're going to treat the
user part as a phone number, *then* you need to canonicalize it as an E.164.

Maybe we can have some language like this:
If the terminating/verifying domain treats the user part of a received
request's From-URI as a phone number for purposes of caller-id display or
processing functions, then the verification system MUST internally generate
a canonical form of the user part into the equivalent E.164 number for the
phone number it would display/process.

OK?

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 11:35:11 -0400

The problem we are solving is robocalling, vishing and swatting.
Telephone calls are typically routed through some fixed algorithm like least cost.  There isn't really a dynamic route, and there isn't a re-route.  Routing is static.

While a routing hop will have alternative paths, it's only one or two alternates usually, and only when something fails or gets congested are the alternate paths used.

As long as the peering partners of the "pink" carriers are willing to check, and do something like making valid source identity a condition of peering, the problem will be greatly reduced.  It does not have to be end to end to be effective.  It's much better end to end, but the mechanisms will be helpful without it.

Brian

On Jun 25, 2013, at 11:18 AM, Dave Crocker <[email-masked]> wrote:

> That is, if the later stages of handling are not covered by the authorization mechanism, traffic could have arrived through a separate path, over that same final sequence, that is not protected.
> 
> The processing nodes and user in that final sequence then have no way to distinguish valid from forged numbers.
>

---

From: <[email-masked]>
Date: Tue, 25 Jun 2013 15:38:33 +0000

Thank you, I would think so, and wouldn't be missing anything then: signing for the in-band mechanism would only be done on the full E.164 form. 

I don't know how far we want to stretch the parallel with SS7 on this though: in some SS7 networks today, the full E.164 format is never used in national calls, neither for CdP and nor CgP (the CC is not conveyed) whilst it may be in others (typically >= 2G mobile networks). 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 5:13 PM
To: FOUQUART Philippe OLNC/OLN; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

Hadriel,

What am I missing here?

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Tue, 25 Jun 2013 11:48:51 -0400

What about the private dial plan / sip trunking scenarios?  In that case it may be desired to deliver the FROM header in "non-canonical" format, so that the recipient can know that this was an "internal" call.  

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, June 25, 2013 10:13 AM
To: [email-masked]; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Hadriel,

What am I missing here?

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

> Finally the irony of not providing a full canonical form is that an 
> increasing number of user data profiles contains the subscriber number 
> in its full E.164 format, so it may actually require *extra work* to 
> provide a different format in a CgP-related header. (I'm not referring 
> to R-Us which in the world I live in generally have to be manipulated 
> as some point to see the light of the CdP party's endpoint or they'll 
> just never get there - if this group were to address such use cases, 
> the logic may have to be different IMHO)

-hadriel

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 15:51:53 +0000

With overlayed area codes and number portability, I think the telephone
network has evolved past the point where routing on partial numbers can be
deterministic.
If we can agree that we need full canonical E.164 numbers, then we have made
progress.
I haven't heard an argument that having a full E.164 number causes any
problems.

The other shoe here is whether one can tell if a sip: address has an E.164
number value as user part or not.
One could argue that for this new feature to work, whatever header it
operates on must be a tel: URI.
But, I can't ascertain if there is the power or will to enforce that on the
existing implementations.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, June 25, 2013 8:39 AM
To: Henning Schulzrinne; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Thank you, I would think so, and wouldn't be missing anything then: signing
for the in-band mechanism would only be done on the full E.164 form. 

I don't know how far we want to stretch the parallel with SS7 on this
though: in some SS7 networks today, the full E.164 format is never used in
national calls, neither for CdP and nor CgP (the CC is not conveyed) whilst
it may be in others (typically >= 2G mobile networks). 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 5:13 PM
To: FOUQUART Philippe OLNC/OLN; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

The signed entity would always be a full E.164 number, as the theory is that
both calling and called carrier are able to derive that canonical format, as
they need to do today for SS7 signaling, CNAM and intercarrier compensation.
Thus, the originating carrier would never sign 212-555-1212, but only
+12125551212.

________________________________________
From: [email-masked] [[email-masked]] on behalf of
[email-masked] [[email-masked]]
Sent: Tuesday, June 25, 2013 8:49 AM
To: Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

Hadriel,

We seem to be talking past each other. I interpreted your comment as:
a) the signing of the TN - who may be done directly or on behalf of the
holder - may use a non canonical form of TN,
b) supposing in-band, that signing would then be conveyed in some way yet
TBD untouched to the verifier, and
c) the verifier would then have to compute that "canonical form" to
eventually assert authenticity.

My comment was that I didn't see how the verifier could reasonably do c)
without prior knowledge of the numbering plan of TN, so either the signer
and the verifier implicitly share the function according to which you can
translate the non canonical form into a canonical form (eg they are on the
same dialing plan) or I don't see how this could work. Say TN=+12125551212,
but a) signs 2125551212 how could c) be correct unless the verifier knows
that it's an NANP number for which adding +1 upfront is enough to make it a
full E.164 number?

What am I missing here?

I definitely don't want to force anyone doing anything with the format of
their CLI, I was merely observing that, with the same examples, if a)
proceeds with 2125551212 and c) is not in the NANP number or doesn't know
it's an NANP number, then I didn't see how it could determine what
canonicalization function to apply.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

On Jun 24, 2013, at 12:11 PM, [email-masked] wrote:
> I understand it may not be the priority here but as a target I think that
grand plan could remain in scope, and again, I think the extra flexibility
for a signer is quite minimal in most dialing plans and the added complexity
for the receiver is in my view not worth it.

We could certainly have an RFC require the signing domain to generate a
To/From URI of E.164 and 'user=part' and all, but I don't see how that would
really succeed:

1) From a practical matter, legacy operators can't change all their systems
to suddenly use a new format; so you'd be forcing them to do the signing
function on their egress SBCs.  While I expect that to be a common scenario
anyway, I don't think we'd want to force people to doing it there, or on any
SBCs for that matter.  It should be possible to do the signing anywhere on
any system type, so long as the signing system knows the caller can claim
the E.164 number.

2) Even if the originator/signer does it that way, by the time the
terminating domain receives the call it will have come through transit
providers who already today change the To/From URIs.

> the logic may have to be different IMHO)

Oh you don't have to provide it in a different format - if you provide it in
an E.164 format today you can continue to with STIR, and you can even change
from your current local format to using an E.164 format.  We just wouldn't
be relying on everyone changing over, for STIR to work.

-hadriel

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 15:55:33 +0000

I don't think we can specify what a private network does internally.

The only question here is whether the private network should normalize, 
or the public network normalize the values on entry to the public network.

Of course that begs the question of when is it public.
One could argue that when you cross administrative domains, it becomes
public.

Mike

-----Original Message-----
To: Henning Schulzrinne; [email-masked]; Hadriel Kaplan

What about the private dial plan / sip trunking scenarios?  In that case it
may be desired to deliver the FROM header in "non-canonical" format, so that
the recipient can know that this was an "internal" call.  

tim

-----Original Message-----
Henning Schulzrinne

Hadriel,

What am I missing here?

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jun 2013 16:28:52 +0000

Traffic that stays within a private network is probably not a major concern, at least for the "provider-validates" scenario.
My understanding is that in order to deliver usable caller ID to SIP phones, SIP trunking providers normalize phone numbers except maybe for in-house extensions.

________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Tuesday, June 25, 2013 11:48 AM
To: Henning Schulzrinne; [email-masked]; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE:  Do we agree on the basics?)

tim

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 12:38:50 -0400

On 6/25/13 2:19 AM, Hadriel Kaplan wrote:

> That depends - if it's literally just a PRI link between Charlie and Dave, we can tunnel the info in an ISUP UUI.  There're even ways of doing that without requiring the PRI Gateway to be truly aware of it nor need to be upgraded, depending on the vendors involved.  If it's a full SS7 carrier in between Charlie and Dave, but it's just one SS7 carrier connecting them, we might still be able to tunnel the UUI through.

I've seen this mentioned multiple times on this list.

Let us not forget that UUI is there for others to use.
We have tools.ietf.org/html/draft-ietf-cuss-sip-uui‎ that defines how to 
use this in SIP, and which can be tunneled in SS7.

I guess this doesn't preclude using UUI for stir, but it certainly 
compromises it.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 12:41:19 -0400

> We're all in agreement that we will complete the in band solution before we complete the out of band solution so it should be reasonable for chairs to manage the WG time effectively.

If that's truly the case - that we plan to do an in-band first, and when that's done then an out-of-band one - then I propose we remove the out-of-band from the charter.  We can always re-charter and add new deliverables when we're ready for an out-of-band mechanism; we re-charter all the time in RAI groups.  We might even decide by then that an out-of-band mechanism should work very differently, or that defining one isn't necessary, or that we don't have the right participants in the IETF to do so successfully.

For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings.  I am very worried that we won't have a successful BOF - where I measure "success" as reaching consensus to create a Working Group.  Lengthy microphone debates kill BOFs, in my experience. (and I recognize you and Russ and others have seen far more BOFs than I have, so maybe I've just been to the wrong ones ;)

-hadriel

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Tue, 25 Jun 2013 12:54:46 -0400

The scenario I meant to refer to, was one in which the private dial plan is supported on the public network.  This is commonly the case with SIP trunking services.

Could there be such a thing as layered signing, e.g, the Enterprise signs the FROM header (if it wants) and the public network signs the P-Asserted-Identity header.  PAID is not necessarily a canonical version of the FROM header, it is simply an identity assigned by the network.  It doesn't have to be in International E.164 format but in practice it normally is.

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 10:56 AM
To: Dwight, Timothy M (Tim); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

Mike

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

tim

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

Hadriel,

What am I missing here?

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 8:00 AM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 12:56:38 -0400

> But how is that germane to the issue at hand?  By that I mean the issue of determining an E.164 caller-id out of the received From-URI.

I agree that it is somewhat off-topic, though "related".

When I capture a caller's "number" to save in my address book, if it is 
actually a SIP URI, then ideally that would be captured in my address 
book, so that when I call it later the domain will be used. But of 
course that only makes sense if the domain is "right". If the domain I 
receive is just a matter of convenience based on the last provider it 
passed through, then I would be better off not capturing it.

Whether it *matters* depends on whether the user with that number gets 
value out of having calls routed via sip. So it would be good for the 
caller to have the option to indicate whether it is or isn't. And that 
is where TEL comes in: If you don't care how it is routed, use TEL; if 
you do, use SIP. (In From.)

And of course, if the call transits a non-sip leg, then the distinction 
will be lost. Sad, but a limitation of the deployed technology.

Regardless of this, we can still sign based on the E.164 in or derived 
from the From-URI.

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jun 2013 10:00:09 -0700

> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings.  I am very worried that we won't have a successful BO…

+1.

Narrow, clear focus.

Good.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Jun 2013 17:00:47 +0000

> Could there be such a thing as layered signing, e.g, the Enterprise signs the FROM header (if it wants) and the public network signs the P-Asserted-Identity header.  PAID is not necessarily a canon…
I think this is a fall back.  We'd like the in band mechanism to be able to be end to end, even if that isn't the way it's initially deployed.  P-A-I isn't end to end.
But if From can't be canonicalized at the termination, we have to do something.

There seems to be two ways to handle the case where From can't be canonicalized, three really, if rewrite at ingress SBC is an option:
a) Sign on a canonicalized PAI
b) Send the canonicalized From in a (new) header, possibly as a parameter to the identity header.

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Tue, 25 Jun 2013 13:02:50 -0400

So you're proposing that SIP trunking services would be exempted from these requirements?  That's one solution I suppose.  I'm not opposed.

You may have more experience that me with SIP trunking services, but in my limited experience the PBX often needs to know (or at least, will behave differently if it knows) that the call was from an on-net user.

tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 11:29 AM
To: Dwight, Timothy M (Tim); [email-masked]; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

tim

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 13:03:09 -0400

On Jun 25, 2013, at 12:38 PM, Paul Kyzivat <[email-masked]> wrote:

> We have tools.ietf.org/html/draft-ietf-cuss-sip-uui‎ that defines how to use this in SIP, and which can be tunneled in SS7.
> 
> I guess this doesn't preclude using UUI for stir, but it certainly compromises it.

Right, it doesn't preclude use of it for STIR, but it does mean the UUI may already be being used by another element for the given INVITE/IAM message.  But I'm not sure or not if that will present a real problem in practice.

For a direct PRI link between two SIP carriers/service-providers, I've been told that's not really a problem - UUI isn't used nor useful on such links typically.  I don't have much real-world experience seeing what crosses such links, but from what I hear we'd be ok in using UUI there.  But we'd need to ask some experts who know.

For an SS7 carrier, I've been told the main use of UUI is for Enterprises which communicate amongst their branch offices, using the UUI between their HQ and branch PBXs across the SS7 carrier.  It sometimes goes across multiple SS7 carriers, but not as much as staying only within one carrier as a transport between the PRIs of an Enterprise.  Realistically the UUI is not used between participants who don't know each other in-advance, because UUI is a proprietary blob and both ends need to use the same PBX vendor/products to understand the UUI.

If that's the case, I think we might be ok.  Because for an Enterprise communicating to its carrier using PRIs, STIR isn't necessary/needed when its talking to its own branch offices and using the UUI.  When it communicates to others, it doesn't send a UUI so we're free to use it.

That's my theory anyway, from what I hear about its use - but as I said we'd need to ask some people who deal with that stuff on a daily basis.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 13:05:06 -0400

> What about the private dial plan / sip trunking scenarios?  In that case it may be desired to deliver the FROM header in "non-canonical" format, so that the recipient can know that this was an "int…

I have never understood this argument.

If the call is "internal" (because the caller and callee are in the same 
enterprise, regardless of whether the call transited a public hop), then 
the recipient should be able to recognize that the From, in E.164 
format, is an internal number. If it wants, the receiving device can 
apply the inverse of the dial plan to the number to produce an internal 
dial string that represents the caller, and display that as the caller id.

I have experienced behavior such as you describe, that worked poorly, 
because individual sites of the enterprise have different dial plans, so 
that the "local" number at one site has a different meaning when 
displayed as caller id for the callee at a different site.

If the calling number has no E.164 equivalent, then the 
telephone-subscriber syntax used in both TEL and SIP has a phone-context 
param that can be used to represent the private number in a globally 
unique way.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 13:12:15 -0400

When UUI is used in SIP, there are other parameters available to 
describe the purpose. On the non-sip links there is only the one byte 
prefix, which isn't really helpful for anything. And AFAIK there are no 
standards for what the rest looks like.

So there is the possibility of misunderstanding the purpose of a 
received UUI. That must also be taken into account.

Combine that with the lack of universal support for UUI, and maybe it 
just isn't something that makes sense to use for stir.

	Thanks,
	Paul

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Tue, 25 Jun 2013 13:15:48 -0400

It's not just an issue of what gets displayed.  The PBX may have different policies for internal and external calls.  It's not necessarily the case that every PBX in an Enterprise knows the E.164 numbers of every other PBX in the Enterprise.  That's why they have private dial plans...

I won't comment on what works poorly or well, other than to note that most solutions can be made to fall into either category.

This may all be moot if it's agreed to exclude calls that originate and terminate within the same Enterprise, from this activity.

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, June 25, 2013 12:05 PM
To: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

If the call is "internal" (because the caller and callee are in the same enterprise, regardless of whether the call transited a public hop), then the recipient should be able to recognize that the From, in E.164 format, is an internal number. If it wants, the receiving device can apply the inverse of the dial plan to the number to produce an internal dial string that represents the caller, and display that as the caller id.

I have experienced behavior such as you describe, that worked poorly, because individual sites of the enterprise have different dial plans, so that the "local" number at one site has a different meaning when displayed as caller id for the callee at a different site.

If the calling number has no E.164 equivalent, then the telephone-subscriber syntax used in both TEL and SIP has a phone-context param that can be used to represent the private number in a globally unique way.

	Thanks,
	Paul

> Of Henning Schulzrinne
> a) the signing of the TN - who may be done directly or on behalf of 
> the holder - may use a non canonical form of TN,
>> increasing number of user data profiles contains the subscriber 
>> number in its full E.164 format, so it may actually require *extra 
>> work* to provide a different format in a CgP-related header. (I'm not 
>> referring to R-Us which in the world I live in generally have to be 
>> manipulated as some point to see the light of the CdP party's 
>> endpoint or they'll just never get there - if this group were to 
>> address such use cases, the logic may have to be different IMHO)
>
> ______________________________________________________________________
> ___________________________________________________
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 13:17:52 -0400

We'd prepend the contents inside the UUI with some random string, to prevent such confusion.  I.e., the first field of the UUI's payload would be some magic cookie like "3y87grgv" or whatever, similar to the "z9hG4bK" of Via branches.

-hadriel

On Jun 25, 2013, at 1:12 PM, Paul Kyzivat <[email-masked]> wrote:

> When UUI is used in SIP, there are other parameters available to describe the purpose. On the non-sip links there is only the one byte prefix, which isn't really helpful for anything. And AFAIK there are no standards for what the rest looks like.
> 
> So there is the possibility of misunderstanding the purpose of a received UUI. That must also be taken into account.
> 
> Combine that with the lack of universal support for UUI, and maybe it just isn't something that makes sense to use for stir.
> 
> 	Thanks,
> 	Paul
>

---

From: "Wendt, Chris" <[email-masked]>
Date: Tue, 25 Jun 2013 17:19:49 +0000

+1

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 13:30:38 -0400

If they originate and terminate in the same enterprise, then both know the dial plan.  We might have a few words in the doc that cover this case which makes an exception for the canonicalization to e.164 as long as they can canonicalize to something they both understand.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 13:31:41 -0400

> As it is today, can the terminating domain extract a canonical e.164 from what is actually sent?

Yes, I think it's a very safe bet that the terminating domain can figure out what the E.164 source identity is.  My evidence of that is that terminating carriers use the source info a LOT, on a bunch of systems: voicemail servers, IVRs, CNAM servers, conf bridges, billing systems, etc.  And of course they ultimately display them as caller-ids on their subscriber's phones.

And the transit carriers can too, because they also use the source identity: for billing and for source-based routing (which is common for transits).

> Alternatively, is it reasonable for the ingress SBC to rewrite it so it can be?

The SBC already rewrite the From - they convert it into a format the local operator can understand/use, so that it works in those systems I mentioned above.
The SBCs can determine what the equivalent E.164 number is so that they can do the verifying, but they couldn't convert the From into a "compliant" E.164 format, because then it won't work on those systems I mentioned above.

> Or do we rely on P-A-I?

Well... whether to use the From or PAI as the source identity is a bit tricky.  PAI is also very commonly used for some of the things we'd want to have validated caller-ids for, and goes across/between some carriers too.  In other words, some of those systems I mentioned above use the PAI instead of the From, but I think we'd be ok saying in the RFC to validate the From, and if the From doesn't match the PAI then leave it up to local policy to decide what to do.  3GPP will go define what to do in that circumstance for IMS, for example.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 13:35:53 -0400

If it works to use UUI, that would be great, but I don't know if UUI would survive most of the SS7 hops, especially if there is a transit carrier in the path, which I suspect is pretty common in the cases we care about.

The alternative I proposed was a new database the SIP->SS7 GW wrote and the SS7->SIP GW searched to restore the identity signature.  That would always work, and we probably could work out reasonable ways to avoid privacy issues because we would be in a more trusted environment, with a restricted set of users who we would have good identity for.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Jun 2013 17:38:04 +0000

Good.  

I think your suggestion on how to handle PAI is fine.  We could have some way to mark the identity header with what was signed if we needed to carry that.

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Jun 2013 17:49:44 +0000

Sure, I don't think we need to do these things at the same time. The way
the current draft charter is structured, the out-of-band solution is last
because we understand it least, and the in-band is more low hanging fruit.
It may make sense to structure the charter in such a way that these
deliverables aren't immediately listed in the milestones.

However, I do think we need to do these things in the same place, as the
potential for overlap and reuse makes me reluctant to decouple this
entirely. The real-world problems here of vishing, robocalling and so on
are not going to be solved by an in-band (that is, for e2e SIP calls)
solution alone. If we design the in-band without consideration for what
the out-of-band solution might look like, this could take us in the wrong
direction. The primary thing we need to be mindful of is the
applicability, and where we anticipate the hand-off will be from the
in-band to the out-of-band. For that reason I still think we should have
discussion of the out-of-band in the charter text, though it should remain
at a high level.

Jon Peterson
Neustar, Inc.

On 6/25/13 9:41 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>>before we complete the out of band solution so it should be reasonable
>>for chairs to manage the WG time effectively.
>
>If that's truly the case - that we plan to do an in-band first, and when
>that's done then an out-of-band one - then I propose we remove the
>out-of-band from the charter.  We can always re-charter and add new
>deliverables when we're ready for an out-of-band mechanism; we re-charter
>all the time in RAI groups.  We might even decide by then that an
>out-of-band mechanism should work very differently, or that defining one
>isn't necessary, or that we don't have the right participants in the IETF
>to do so successfully.
>
>For now, by removing it from the charter, we can focus on one solution
>and not have to debate about this aspect during the BOF nor WG meetings.
>I am very worried that we won't have a successful BOF - where I measure
>"success" as reaching consensus to create a Working Group.  Lengthy
>microphone debates kill BOFs, in my experience. (and I recognize you and
>Russ and others have seen far more BOFs than I have, so maybe I've just
>been to the wrong ones ;)
>
>-hadriel
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jun 2013 11:06:34 -0700

On 6/25/2013 10:49 AM, Peterson, Jon wrote:
>  The primary thing we need to be mindful of is the

1.  By the reference to hand-offs, you are implying some specific 
scenarios.  Please offer some diagrams that show the architectural 
relationships between in-band and out-of-band that you expect the work 
to cover.

2. A charter specifies work to be done.  It's not clear how the 
inclusion of "high-level" discussion about out-of-band is helpful in 
terms of deliverables, since it won't be the work to be done.

The kind of "high-level" reference you suggest never provides meaningful 
engineering guidance.  Mindfulness is wonderful for meditation and 
dieting, but its utility for standards processes is entirely ambiguous. 
  It's the form without the substance.

d/

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 25 Jun 2013 18:11:10 +0000

+1.

I was also thinking that these two proposed solutions are so different they should not be covered by the same WG and if we can agree to do one after the other then even better.

Also agree there is much more chance of a successful BOF if we can focus on the in-band solution and not have to debate both.

Andy

> Sent: 25 June 2013 17:41
> Cc: [email-masked]; [email-masked]; Henning Schulzrinne
> If that's truly the case - that we plan to do an in-band first, and
> when that's done then an out-of-band one - then I propose we remove the
> deliverables when we're ready for an out-of-band mechanism; we re-
> charter all the time in RAI groups.  We might even decide by then that
> an out-of-band mechanism should work very differently, or that defining
> one isn't necessary, or that we don't have the right participants in
> the IETF to do so successfully.
> 
> and not have to debate about this aspect during the BOF nor WG
> meetings.  I am very worried that we won't have a successful BOF -
> where I measure "success" as reaching consensus to create a Working
> Group.  Lengthy microphone debates kill BOFs, in my experience. (and I
> recognize you and Russ and others have seen far more BOFs than I have,
> so maybe I've just been to the wrong ones ;)
> 
> -hadriel
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 25 Jun 2013 18:23:39 +0000

> ON: 25 June 2013 18:03 Hadriel Kaplan Wrote:
> To: Paul Kyzivat
> 
> For an SS7 carrier, I've been told the main use of UUI is for
> Enterprises which communicate amongst their branch offices, using the
> UUI between their HQ and branch PBXs across the SS7 carrier.  It
> sometimes goes across multiple SS7 carriers, but not as much as staying
> only within one carrier as a transport between the PRIs of an
> Enterprise.  Realistically the UUI is not used between participants who
> don't know each other in-advance, because UUI is a proprietary blob and
> both ends need to use the same PBX vendor/products to understand the
> UUI.
> 
> If that's the case, I think we might be ok.  Because for an Enterprise
> communicating to its carrier using PRIs, STIR isn't necessary/needed
> when its talking to its own branch offices and using the UUI.  When it
> communicates to others, it doesn't send a UUI so we're free to use it.
> 
> That's my theory anyway, from what I hear about its use - but as I said
> we'd need to ask some people who deal with that stuff on a daily basis.

I think this theory is very dubious if an enterprise is using PRI to a carrier to talk to its own branches why would STIR not be needed?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jun 2013 18:34:07 +0000

I don't think number spoofing within enterprise networks or within a single carrier network is a major problem at the moment, so I'm less worried about supporting that case if it requires major contortions.

I'm a bit worried about having too many identifiers in the same message - we want to make sure that the number presented to the user, via caller-ID, can be trusted, rather than some other string that the user cannot see and may well differ. While MIM attacks are not a major concern, if you can essentially slap a signed block into just about any signaling message, and the callerID is interpreted as signed even though the signed block refers to some completely different number, this seems like a recipe for mischief.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Dwight, Timothy M (Tim) [[email-masked]]
Sent: Tuesday, June 25, 2013 1:02 PM
To: Henning Schulzrinne; [email-masked]; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 11:29 AM
To: Dwight, Timothy M (Tim); [email-masked]; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

tim

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Jun 2013 18:47:34 +0000

This has also been my historical concern about asserting identity for some
new header field. When an INVITE lands at a SIP device, what if anything
do we expect the standard header field value would be that gets displayed
to the user as the identity of the caller?

The path we went down with RFC3325 (and many subsequent specifications in
3GPP and elsewhere, to say nothing of proprietary measures) increasingly
proliferated the identities carried within a request, some of which were
never intended to be rendered to end users - certainly per the trust
domain definition followed by RFC3325, it would rarely be standard
behavior to deliver a PAI header to an end-user device.

Back when we were working on RFC4474, the prevailing argument was that the
baseline behavior of SIP devices would be to render the From header field,
and that's why we focused on it. This thread has amply illustrated that
there's no free lunch here in terms of implementing secure identity:
either the way service providers handle identifiers, or the way-end user
devices render identifiers, or both, will have to change. The discussion
here has to be one about which are the least painful and surprising
changes, and about where identity information should be carried to reduce
the security vulnerability to legacy systems.

Jon Peterson
Neustar, Inc.

On 6/25/13 11:34 AM, "Henning Schulzrinne" <[email-masked]>
wrote:

>I don't think number spoofing within enterprise networks or within a
>single carrier network is a major problem at the moment, so I'm less
>worried about supporting that case if it requires major contortions.
>
>I'm a bit worried about having too many identifiers in the same message -
>we want to make sure that the number presented to the user, via
>caller-ID, can be trusted, rather than some other string that the user
>cannot see and may well differ. While MIM attacks are not a major
>concern, if you can essentially slap a signed block into just about any
>signaling message, and the callerID is interpreted as signed even though
>the signed block refers to some completely different number, this seems
>like a recipe for mischief.
>
>From: [email-masked] [[email-masked]] on behalf of Dwight,
>Timothy M (Tim) [[email-masked]]
>So you're proposing that SIP trunking services would be exempted from
>these requirements?  That's one solution I suppose.  I'm not opposed.
>
>You may have more experience that me with SIP trunking services, but in
>my limited experience the PBX often needs to know (or at least, will
>behave differently if it knows) that the call was from an on-net user.
>
>tim
>
>Traffic that stays within a private network is probably not a major
>concern, at least for the "provider-validates" scenario.
>My understanding is that in order to deliver usable caller ID to SIP
>phones, SIP trunking providers normalize phone numbers except maybe for
>in-house extensions.
>
>What about the private dial plan / sip trunking scenarios?  In that case
>it may be desired to deliver the FROM header in "non-canonical" format,
>so that the recipient can know that this was an "internal" call.
>
>tim

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Jun 2013 19:05:15 +0000

>relationships between in-band and out-of-band that you expect the work

I did offer a more-than-implicit scenario: if I may paraphrase, it was
"in-band assumes e2e SIP" and "not all calls are e2e SIP." This seems like
a pretty good reason to be mindful of something other than just in-band.

There are already some diagrams in the secure-origins-ps draft that show
the difference between these call types. It's just a start, but, well,
we're just starting work here.

>terms of deliverables, since it won't be the work to be done.

It is helpful for the reason you called a "reference to hand-offs" above.
Charters scope work to be done and work not to be done. Identifying
modular pieces is helpful. And the idea of including it would be "this
isn't the first thing we're going to do, but we're going to do it later."
This is not uncommon in IETF charters.

>dieting, but its utility for standards processes is entirely ambiguous.

Charters are high level, and whether or not they provide meaningful
engineering guidance is a subject of ongoing controversy. For years I've
been a fan of requiring a "boxes and arrows" document that would be more
detailed than a charter. We did supply some input drafts that try to take
this down at least one level lower.

>  It's the form without the substance.

Funny, I get the same feeling sometimes.

Jon Peterson
Neustar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Jun 2013 19:10:42 +0000

I think your last statement is the gist of this issue.
Is routing and authentication within a private network in scope for this
group.
I think not.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dwight, Timothy M (Tim)
Sent: Tuesday, June 25, 2013 10:16 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

It's not just an issue of what gets displayed.  The PBX may have different
policies for internal and external calls.  It's not necessarily the case
that every PBX in an Enterprise knows the E.164 numbers of every other PBX
in the Enterprise.  That's why they have private dial plans...

I won't comment on what works poorly or well, other than to note that most
solutions can be made to fall into either category.

This may all be moot if it's agreed to exclude calls that originate and
terminate within the same Enterprise, from this activity.

Tim

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

> What about the private dial plan / sip trunking scenarios?  In that case
it may be desired to deliver the FROM header in "non-canonical" format, so
that the recipient can know that this was an "internal" call.

If the call is "internal" (because the caller and callee are in the same
enterprise, regardless of whether the call transited a public hop), then the
recipient should be able to recognize that the From, in E.164 format, is an
internal number. If it wants, the receiving device can apply the inverse of
the dial plan to the number to produce an internal dial string that
represents the caller, and display that as the caller id.

I have experienced behavior such as you describe, that worked poorly,
because individual sites of the enterprise have different dial plans, so
that the "local" number at one site has a different meaning when displayed
as caller id for the callee at a different site.

If the calling number has no E.164 equivalent, then the telephone-subscriber
syntax used in both TEL and SIP has a phone-context param that can be used
to represent the private number in a globally unique way.

	Thanks,
	Paul

> The signed entity would always be a full E.164 number, as the theory is
that both calling and called carrier are able to derive that canonical
format, as they need to do today for SS7 signaling, CNAM and intercarrier
compensation. Thus, the originating carrier would never sign 212-555-1212,
but only +12125551212.
really succeed:
>
> 1) From a practical matter, legacy operators can't change all their
systems to suddenly use a new format; so you'd be forcing them to do the
signing function on their egress SBCs.  While I expect that to be a common
scenario anyway, I don't think we'd want to force people to doing it there,
or on any SBCs for that matter.  It should be possible to do the signing
anywhere on any system type, so long as the signing system knows the caller
can claim the E.164 number.
> Oh you don't have to provide it in a different format - if you provide it
in an E.164 format today you can continue to with STIR, and you can even
change from your current local format to using an E.164 format.  We just
wouldn't be relying on everyone changing over, for STIR to work.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 15:10:55 -0400

> I think this theory is very dubious if an enterprise is using PRI to a carrier to talk to its own branches why would STIR not be needed?

To be clear: I don't mean if a PBX uses a PRI to talk to its branches it can't use the same PRI for calling the PSTN - it can, and it can use STIR for the PSTN-based calls.  It just can't use STIR for the inter-branch calls.  And I'm saying that's ok - securing source identity for inter-branch calls isn't a problem we're trying to solve.  And as far as I know there's not been a problem with spoofed caller-id's for inter-branch calls in the real world.  Has there?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 15:28:31 -0400

> If it works to use UUI, that would be great, but I don't know if UUI would survive most of the SS7 hops, especially if there is a transit carrier in the path, which I suspect is pretty common in th…

It won't work in those cases - I had said that earlier on this or another thread: it might work for direct PRI links, or for a single SS7 transit carrier, but if there are multiple transits it's doubtful.  I'm not claiming it's going to work across SS7 everywhere in all cases, or even in most cases for that matter.

But I don't think that's a problem we need to solve - not by the time we actually have a solution that could solve it.  Yes there will still be SS7 in 10 years, but if we've reduced the volume of caller-id spoofing and the only remaining way to spoof a caller-id is to get your call to go through multiple SS7 carriers, then I really think we'd be breaking out the Champagne.

> The alternative I proposed was a new database the SIP->SS7 GW wrote and the SS7->SIP GW searched to restore the identity signature.  That would always work, and we probably could work out reasonabl…

Sorry I missed that proposal somewhere.  Did you send it in an email? (there have been a lot of emails on this list :)

If I get the gist of what you're proposing, effectively it's an out-of-band mechanism, but just a private one for carriers rather than a public one?
Again, from a purely technical perspective I don't debate we could define something like that in drafts that pass a Working Group and IETF Last-Call, IESG review, and get published as RFCs by the RFC Editor. 

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 15:30:14 -0400

> Sorry I missed that proposal somewhere.  Did you send it in an email? (there have been a lot of emails on this list :)
Yeah, I did

> Again, from a purely technical perspective I don't debate we could define something like that in drafts that pass a Working Group and IETF Last-Call, IESG review, and get published as RFCs by the R…
Meaning not deployed?  Why?

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 25 Jun 2013 20:24:22 +0000

> Sent: 25 June 2013 20:11
> To: Hutton, Andrew
> Cc: Paul Kyzivat; [email-masked]
> Subject: Re: [stir] Use of UUI for stir
> 
> 
> > I think this theory is very dubious if an enterprise is using PRI to
> a carrier to talk to its own branches why would STIR not be needed?
> 
> 
> To be clear: I don't mean if a PBX uses a PRI to talk to its branches
> it can't use the same PRI for calling the PSTN - it can, and it can use
> STIR for the PSTN-based calls.  It just can't use STIR for the inter-
> branch calls.  And I'm saying that's ok - securing source identity for
> inter-branch calls isn't a problem we're trying to solve.  And as far
> as I know there's not been a problem with spoofed caller-id's for
> inter-branch calls in the real world.  Has there?

If you mean that it cannot use STIR for calls within a private numbering plan then I am ok with that.

Andy

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Jun 2013 16:32:16 -0400

> Meaning not deployed?  Why?

Because if you send the call into SS7, without any idea of who/what's beyond, and can't send something in-band to tell the far-end carrier why/how it should believe your caller-id, then you'd have to tell some third-party you really trust instead (ie, EKR's CDS server cloud thingy).  You'd have to believe the far-end carrier would use the same third-party to verify, even though you don't know who that far-end carrier is.  For that to work, it means there're only one or two such third-parties for a given country, or even for the planet Earth (depending on the details of how this thing would work).

The only way I'd believe that could really happen is for either (1) regulatory bodies to choose a third-party for everyone to use, or (2) enough of the big carriers to choose a common third-party that it drives/forces everyone else to use the same.  I don't debate (1) is possible, but it's a big deal to get that to happen and the regulatory effort would be better spent making the legacy carriers move to a technology that can transport the caller-id info (which does not need to be SIP, btw - it could be H.323, XMPP, or whatever).  Doing that not only provides the caller-id we need, but also keeps us from giving regulated monopoly power to a third-party.  I would believe in (2) a lot more, but I don't believe the big carriers want to give even de-facto monopoly power to a third-party if they can avoid it.  It always bites them in the a$$ in the end.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Jun 2013 16:38:15 -0400

Yeah, there has to be one per country with some LoST like thingy for an international call.

I think it would be #2.  The $damage is limited because the big guys will be exiting SS7 sooner rather than later, although I think that's a decade.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jun 2013 22:34:33 -0700

> It is helpful for the reason you called a "reference to hand-offs" above.

Actually it doesn't.  More often it's counter-productive.

In a form that generic, it has no technical substance and offers no 
guidance.  Anything could qualify within it.  Anything could be 
excluded.  The usual effect of text like that is to distract from doing 
a clean design.  It winds up causing people to instead attempt an 
awkward hybrid design -- trying to solve both problems -- rather than a 
clean, focused one.

> Charters scope work to be done and work not to be done.

A generic statement along the lines of the "be mindful of..." sort that 
you want to add does neither.

> Identifying
> modular pieces is helpful.

Sure is.  But you've just cited that as if it relates to the discussion. 
  Perhaps it does, but it isn't obvious how.

> And the idea of including it would be "this

Charter language along those lines is primarily used to say "ignore 
these issues now because they are out of scope now".  That can, indeed, 
be helpful for focusing a working group that is easily subject to 
distraction.

Unfortunately, that's not the purpose you have in mind.  "Be mindful of" 
serves exactly the opposite purpose.

> This is not uncommon in IETF charters.

Not uncommon.  Almost never useful.  More typically distracting.

In the face of problem and solution spaces that have already displayed 
serious challenges in producing coherent group discussion, that's 
exactly the danger to worry about with such extraneous text in the charter.

If the charter is not disciplined, it's unlikely the working group will be.

  d/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 26 Jun 2013 09:52:07 +0200

>> For now, by removing it from the charter, we can focus on one solution and not have to debate about this aspect during the BOF nor WG meetings.  I am very worried that we won't have a successful B…

Agree.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 26 Jun 2013 10:09:23 +0200

> Is routing and authentication within a private network in scope for this

I do agree.
Now, the question is if the situation with two private networks peering using
E.164 phone numbers is within scope?

We will see more and more of that and the definition of "service provider" is less and less clear.

There some sort of border we're looking for where a call using an E.164 number as a caller ID
leaves a "domain" or "realm".

/O

---

From: <[email-masked]>
Date: Wed, 26 Jun 2013 09:18:40 +0000

Such an approach on From vs PAI would be fine with me. 

> My evidence of that is that terminating carriers use the source info a LOT, 
> on a bunch of systems: voicemail servers, IVRs, CNAM servers, conf bridges, 
> billing systems, etc.  

My evidence is also that they do, indeed. 

> And of course they ultimately display them as caller-ids on their subscriber's phones.

I guess we'll be saying the same thing but actually they do not, strictly speaking because they've always made a difference between the dialing plan and the numbering plan, ie what the user sees/uses vs. what the "network" uses. What is displayed is generally the result of a CLIP service. For example, a DDI/DID number of a SIP trunking service conveyed as an E.164 number CLI would generally be displayed in three different ways depending on whether the call terminates on the same PBX, on a landline in the same country or on a mobile phone.   

> The SBC already rewrite the From - they convert it into a format the local 
> operator can understand/use

They can, but they may not have to, luckily enough. The extent to which this is necessary really depends on the kind of traffic they handle.   

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 7:32 PM
To: Rosen, Brian
Cc: FOUQUART Philippe OLNC/OLN; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

---

From: <[email-masked]>
Date: Wed, 26 Jun 2013 10:05:43 +0000

I wouldn't think it is either. I suppose the DDI numbers might indeed be treated exactly as E.164 numbers (by and large they are, in the (SIP) networks I'm familiar with) but the non DDIs will remain a bit of a problem with the current logic as would be the case of short codes in the public dialing plan anyway. I'm fine with leaving all of those aside. 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 8:34 PM
To: Dwight, Timothy M (Tim); FOUQUART Philippe OLNC/OLN; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 11:29 AM
To: Dwight, Timothy M (Tim); [email-masked]; Hadriel Kaplan
Cc: Rosen, Brian; [email-masked]
Subject: RE: [stir] URI formats (was RE: Do we agree on the basics?)

tim

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 26 Jun 2013 11:03:38 +0000

Agree with Dave

Martin Dolly
AT&T 

Sent from my iPhone

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 26 Jun 2013 13:50:26 +0000

We need to think carefully about terminology here and stop using terms such as "private network", "service provider" and "enterprise network" which are open to interpretation. These boundaries are becoming more and more blurred.

Increasingly we see vendors offering cloud based communications / UC to enterprises so an enterprise can easily subscribe to cloud based communications services. In this case the boundaries are less clear.

So I agree with Olle we need clarity on what is we are actually trying to solve and the trust boundaries to which it applies.  Maybe it will become clearer as I catch up with the long list of e-mails I still have to read but I am concerned by the terminology we are using.

Regards
Andy

> Olle E. Johansson
> Sent: 26 June 2013 09:09
> Cc: [email-masked]; Olle E. Johansson; [email-masked];
> [email-masked]
> Of
> Of Paul
> displayed
> >> b) supposing in-band, that signing would then be conveyed in some
> way
> >> yet TBD untouched to the verifier, and

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jun 2013 10:02:43 -0400

> So I agree with Olle we need clarity on what is we are actually trying to solve and the trust boundaries to which it applies.  Maybe it will become clearer as I catch up with the long list of e-mai…

I agree.

ISTM that we can consider out of scope cases where caller, callee, and 
the entire path are under control of a single organization (e.g., a 
business' private phone network). But they can still opt in for for 
regulatory reasons (e.g., a carrier) or just because they want to.

And I think we could rule out cases where the numbers aren't covered by 
a canonicalization mechanism understood by both ends. That might cover 
numbers that don't have E.164 representatons. But we *could* allow 
*some* of those to be covered by parameters to telephone-subscriber 
(such as phone-context).

ISTM that STIR could cover any case not excluded by the above.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 26 Jun 2013 11:33:19 -0400

+1 as well ... take it out of the charter. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <[email-masked]>
Cc: [email-masked]; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

isn't necessary, or that we don't have the right participants in the IETF to
do so successfully.
>> For now, by removing it from the charter, we can focus on one solution
and not have to debate about this aspect during the BOF nor WG meetings.  I
am very worried that we won't have a successful BOF - where I measure
"success" as reaching consensus to create a Working Group.  Lengthy
microphone debates kill BOFs, in my experience. (and I recognize you and
Russ and others have seen far more BOFs than I have, so maybe I've just been
to the wrong ones ;)

---

From: Michael Hammer <[email-masked]>
Date: Wed, 26 Jun 2013 16:15:52 +0000

I would not confuse the underlying environment and transport between
signaling elements.
We are talking about the signaling layer here and only functions on those
elements that process the SIP or SS7.

Whether you want to call it inter-domain versus public or private, the
essence is still the same.
Intra-administration you can do what you want, but when you pass it to some
other independent entity, perhaps some rules apply.

That does not mean that the intra-domain experience cannot also follow
suite, if they find it useful.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Wednesday, June 26, 2013 7:03 AM
To: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

On 6/26/13 9:50 AM, Hutton, Andrew wrote:
>
> We need to think carefully about terminology here and stop using terms
such as "private network", "service provider" and "enterprise network" which
are open to interpretation. These boundaries are becoming more and more
blurred.
>
> Increasingly we see vendors offering cloud based communications / UC to
enterprises so an enterprise can easily subscribe to cloud based
communications services. In this case the boundaries are less clear.
>
> So I agree with Olle we need clarity on what is we are actually trying to
solve and the trust boundaries to which it applies.  Maybe it will become
clearer as I catch up with the long list of e-mails I still have to read but
I am concerned by the terminology we are using.

I agree.

ISTM that we can consider out of scope cases where caller, callee, and the
entire path are under control of a single organization (e.g., a business'
private phone network). But they can still opt in for for regulatory reasons
(e.g., a carrier) or just because they want to.

And I think we could rule out cases where the numbers aren't covered by a
canonicalization mechanism understood by both ends. That might cover numbers
that don't have E.164 representatons. But we *could* allow
*some* of those to be covered by parameters to telephone-subscriber (such as
phone-context).

	Thanks,
	Paul

>> Of Olle E. Johansson
>> There some sort of border we're looking for where a call using an 
>> E.164 number as a caller ID leaves a "domain" or "realm".
>>
>> /O
>>>
>>> Mike
>>>
>>>
>>> I won't comment on what works poorly or well, other than to note 
>>> that
>> most
>>> recipient should be able to recognize that the From, in E.164 
>>> format,
>> is an
>>> I have experienced behavior such as you describe, that worked 
>>> poorly, because individual sites of the enterprise have different 
>>> dial plans,
>> so
>>> syntax used in both TEL and SIP has a phone-context param that can 
>>> be
>> used
>>>> The signed entity would always be a full E.164 number, as the 
>>>> theory
>> is
>>> compensation. Thus, the originating carrier would never sign 
>>> 212-555-
>> 1212,
>>> but only +12125551212.
>>>>
>>> and the verifier implicitly share the function according to which 
>>> you
>> can
>>> their CLI, I was merely observing that, with the same examples, if 
>>> a) proceeds with 2125551212 and c) is not in the NANP number or 
>>> doesn't
>> know
>>>>> Finally the irony of not providing a full canonical form is that 
>>>>> an increasing number of user data profiles contains the subscriber 
>>>>> referring to R-Us which in the world I live in generally have to 
>>>>> be manipulated as some point to see the light of the CdP party's 
>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>> ce message
>> par

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jun 2013 22:22:05 +0000

+1. I would make one additional point, given that we're in chartering territory: I suspect this is also an indicator of requirements cut-offs. In other words, if supporting single-organization applications, such as the ones mentioned by Paul, are causing complexity, such as arcane normalization rules, the need for special headers or the inability to normalize, in the inter-organization case, I think that it's acceptable to defer those for later, including "never". Since inter-organization calls already routinely have to interface with systems (SS7, CNAM, billing, etc. that have been mentioned) that are only marginally tolerant of random protocol and format variations, that increases our chances of success and limits complexity.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Wednesday, June 26, 2013 10:02 AM
To: [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

        Thanks,
        Paul

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jun 2013 15:33:00 -0700

I have an extremely naive suggestion.  No doubt I'm entirely 
misunderstanding some range of basic, essential things.

At the least, I hope that my suggestion prompts a concise summary of the 
this sub-topic in terms of the operational domain it will be applied to 
and the functional goal it must satisfy.  The lengthy thread isn't all 
that easy to follow.

So...

As I understand the basic issue, the telephone number in the From field 
is not kept in a single, standardized form.  At each stage of handling, 
the agent processing the message might coerce it to be any of a range of 
different forms.  The details of why this is and how we might wish 
things otherwise are not helpful; the operational reality is what it is: 
numbers are represented in a variety of ways.

However, the STIR verifier must have a canonical string to use for 
performing checking and the string needs to match the string that was 
used during signing.

So here's my naive suggestion:

    For a message that is signed by the STIR mechanism, ignore whatever 
string is currently in the From field.

    Instead, take the canonical telephone number that is in the 
signature field -- I'm assuming that /it/ is /not/ messed with in 
transit -- and stuff it into the From field.

    In other word, use the STIR telephone number to override the string 
in the From field.

Ok.  start shooting...

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Jun 2013 19:07:04 -0400

It's not a naive suggestion - in fact it was considered several times during debates about this topic in years past.
:)

We can't overwrite/replace the From or To fields in the SIP message with whatever this WG decides a canonical format is, because it will break existing deployments.  Obviously existing deployments have to change slightly to perform STIR - namely they have to deploy a signer and verifier - but only specific systems have to do that job and be changed, and only in originating/terminating domains.  In deployed SIP use today, there are a lot of disparate systems in any given SIP domain, and transit SIP domains in-between the originator+terminator.  So since we can't expect a flag-day to change everything, we have to leave the To/From alone. [one note on this is the transits will have to pass along the new signature header, but that's a lot more likely to happen than expecting them to change their numbering plans everywhere]

There have also been suggestions for the signer to write the canonical form into some new header(s) and have the verifier simply verify that new header, but that idea is difficult too for a similar reason as above but in a different way: since all the existing systems in the terminating/verifying domain use the info in the From (or PAI) as the caller-id, then verifying some value in another header won't actually prove anything about the caller-id that actually gets used for things.  In other words, since the voicemail, billing, CNAM, conf bridges, phone displays, etc., use the From for the caller-id, verifying something else won't stop the bad guys from achieving their end goals unless we change all those systems/phones to start using the new header for the caller-id in a flag-day, which isn't reasonable. 

-hadriel

On Jun 26, 2013, at 6:33 PM, Dave Crocker <[email-masked]> wrote:

> I have an extremely naive suggestion.  No doubt I'm entirely misunderstanding some range of basic, essential things.
> 
> At the least, I hope that my suggestion prompts a concise summary of the this sub-topic in terms of the operational domain it will be applied to and the functional goal it must satisfy.  The lengthy thread isn't all that easy to follow.
> 
> So...
> 
> As I understand the basic issue, the telephone number in the From field is not kept in a single, standardized form.  At each stage of handling, the agent processing the message might coerce it to be any of a range of different forms.  The details of why this is and how we might wish things otherwise are not helpful; the operational reality is what it is: numbers are represented in a variety of ways.
> 
> However, the STIR verifier must have a canonical string to use for performing checking and the string needs to match the string that was used during signing.
> 
>   For a message that is signed by the STIR mechanism, ignore whatever string is currently in the From field.
> 
>   Instead, take the canonical telephone number that is in the signature field -- I'm assuming that /it/ is /not/ messed with in transit -- and stuff it into the From field.
> 
>   In other word, use the STIR telephone number to override the string in the From field.
> 
> 
> Ok.  start shooting...
> 
> d/
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 27 Jun 2013 01:39:32 +0000

So, do you want to keep your cake whole or eat it?

You cannot have both a canonical value that can be relied on and maximum
flexibility to mangle the From header.
Something has to give.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Wednesday, June 26, 2013 4:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

It's not a naive suggestion - in fact it was considered several times during
debates about this topic in years past.
:)

We can't overwrite/replace the From or To fields in the SIP message with
whatever this WG decides a canonical format is, because it will break
existing deployments.  Obviously existing deployments have to change
slightly to perform STIR - namely they have to deploy a signer and verifier
- but only specific systems have to do that job and be changed, and only in
originating/terminating domains.  In deployed SIP use today, there are a lot
of disparate systems in any given SIP domain, and transit SIP domains
in-between the originator+terminator.  So since we can't expect a flag-day
to change everything, we have to leave the To/From alone. [one note on this
is the transits will have to pass along the new signature header, but that's
a lot more likely to happen than expecting them to change their numbering
plans everywhere]

There have also been suggestions for the signer to write the canonical form
into some new header(s) and have the verifier simply verify that new header,
but that idea is difficult too for a similar reason as above but in a
different way: since all the existing systems in the terminating/verifying
domain use the info in the From (or PAI) as the caller-id, then verifying
some value in another header won't actually prove anything about the
caller-id that actually gets used for things.  In other words, since the
voicemail, billing, CNAM, conf bridges, phone displays, etc., use the From
for the caller-id, verifying something else won't stop the bad guys from
achieving their end goals unless we change all those systems/phones to start
using the new header for the caller-id in a flag-day, which isn't
reasonable. 

-hadriel

> At the least, I hope that my suggestion prompts a concise summary of the
this sub-topic in terms of the operational domain it will be applied to and
the functional goal it must satisfy.  The lengthy thread isn't all that easy
to follow.
> 
> So...
> 
> As I understand the basic issue, the telephone number in the From field is
not kept in a single, standardized form.  At each stage of handling, the
agent processing the message might coerce it to be any of a range of
different forms.  The details of why this is and how we might wish things
otherwise are not helpful; the operational reality is what it is: numbers
are represented in a variety of ways.
> However, the STIR verifier must have a canonical string to use for
performing checking and the string needs to match the string that was used
during signing.
> 
>   Instead, take the canonical telephone number that is in the signature
field -- I'm assuming that /it/ is /not/ messed with in transit -- and stuff
it into the From field.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Jun 2013 00:30:38 -0400

> So, do you want to keep your cake whole or eat it?

Welll... based on my physical weight I'd say I always eat the cake, and ask for seconds. :)

> flexibility to mangle the From header.

The premise so far has been that you can do both - you can mangle the From header in the message all you like, so long as you can figure out what the From's E.164 number would be.  And I'd argue there's plenty of evidence that is the case: that regardless of the syntax used in the encoding, the originator and terminator domains both know what the 'real' E.164 is for a given URI (assuming it's an E.164 at all), because if they didn't then all kinds of things wouldn't work right today.

But let's play devil's advocate.  Let's say the premise is wrong: that in fact originators use syntax X and terminators use syntax Y and the terminator can't correctly figure out what the From's E.164 is today.  What could we do about it and why would we need to?  After all, if the terminating domain can't figure out what the From E.164 number is today, then in what way is the From being used such that we need to validate them as E.164 numbers for such a terminating domain?  I.e., if they're not using the From for a source identity, then what's broken for them that we need to fix?  And if they're not using them as E.164's, then why would they care to change their behavior for a STIR RFC?

[note: I say "E.164" but really I mean a phone-number: something that either is an E.164 or can be converted to such, for example by prepending a country-code and an area-code]

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Thu, 27 Jun 2013 15:51:31 +0000

You've just made the argument that the STIR WG is not needed.
Guess we can all go home now.  :)

You've essentially said that we must trust whatever the latest network
mangles the From header to be and assume to trust that network.
I've been trying to discover in all the suggestions how that chain of trust
is preserved from the start.
But, you argue against any E2E trust, just hop-by-hop.
That doesn't seem to be working so well today.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 9:31 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

> So, do you want to keep your cake whole or eat it?

Welll... based on my physical weight I'd say I always eat the cake, and ask
for seconds. :)

> You cannot have both a canonical value that can be relied on and 
> maximum flexibility to mangle the From header.
> Something has to give.

The premise so far has been that you can do both - you can mangle the From
header in the message all you like, so long as you can figure out what the
From's E.164 number would be.  And I'd argue there's plenty of evidence that
is the case: that regardless of the syntax used in the encoding, the
originator and terminator domains both know what the 'real' E.164 is for a
given URI (assuming it's an E.164 at all), because if they didn't then all
kinds of things wouldn't work right today.

But let's play devil's advocate.  Let's say the premise is wrong: that in
fact originators use syntax X and terminators use syntax Y and the
terminator can't correctly figure out what the From's E.164 is today.  What
could we do about it and why would we need to?  After all, if the
terminating domain can't figure out what the From E.164 number is today,
then in what way is the From being used such that we need to validate them
as E.164 numbers for such a terminating domain?  I.e., if they're not using
the From for a source identity, then what's broken for them that we need to
fix?  And if they're not using them as E.164's, then why would they care to
change their behavior for a STIR RFC?

[note: I say "E.164" but really I mean a phone-number: something that either
is an E.164 or can be converted to such, for example by prepending a
country-code and an area-code]

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Jun 2013 12:42:10 -0400

> That doesn't seem to be working so well today.

I don't think I've done that - how have I done it?

I haven't said you have to trust the From - I said the From can and will be changed in syntax/format.  Ultimately the guy receiving and using the caller-id (the E.164 number) needs to know it's a valid *phone-number* - what he does *not* need to know is that the From URI string encoding has been unchanged.  This whole exercise is about preventing spoofed E.164 caller-ids - not about preventing a From header field string as opaque data.

It does not matter if it started as 'sip:[email-masked];user=phone' and got received as 'sip:[email-masked]'; because if the terminator uses it as the E.164 phone number '12125551212' in his systems and caller-id displays, then what he really needs to know is that this call request came from someone with the authority to claim '12125551212' - he does *not* need to know it really came from 'bbb.com', nor that it came from user '+1-212-555-1212', nor even that it came from SIP.

There is nothing anyone in the middle can do to successfully break this - no amount of their header munging will succeed, because if they change the actual number to be interpreted by the terminator as something else, like '161712345678' instead, then the signature will fail as it should fail.  If they munge the headers so it can't be interpreted as any E.164 phone number, then the signature fails as it should fail.  If they munge the headers so that it's still interpreted as '12125551212', then they haven't succeeded in spoofing anyone.  I recognize this won't protect the rest of the From URI - but that's not the goal.  The goal is to prevent spoofing Caller-IDs.  Nothing more.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 27 Jun 2013 18:16:44 +0000

>It does not matter if it started as 'sip:[email-masked];user=phone' and
>got received as 'sip:[email-masked]'; because if the terminator
>uses it as the E.164 phone number '12125551212' in his systems and
>caller-id displays, then what he really needs to know is that this call
>request came from someone with the authority to claim '12125551212' - he
>does *not* need to know it really came from 'bbb.com', nor that it came
>from user '+1-212-555-1212', nor even that it came from SIP.

Perhaps what some folks are missing here is the clear statement that both
the auth service and the verification service need to canonicalize the
>From number to E.164 (actually a bit of a variant, but glossing over for
now) as a part of the signature generation/verification process.

The idea is basically this: when the auth signature is placed over
sip:[email-masked], the auth service canonicalizes 5551212 to
"12125551212", and that is what is signed over in the digest-strig of the
Identity header. In RFC4474 terms, this canonicalized string would take
the place of the addr-spec of the AoR in Section 9. When the verification
service receives [email-masked], it too canonicalizes that to
12125551212 for the purposes of regenerating the digest-string. Thus it
doesn't matter how From is munged. Nor do you need to store a copy of the
number anywhere in the message, which for the various reasons previously
discussed won't work.

The requirement here that both the auth service and verification service
canonicalize numbers in the same fashion is absolute, and perhaps
non-trivial, but it's certainly way better than hop-by-hop protection.

Jon Peterson
Neustar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 27 Jun 2013 21:53:09 +0000

Agree.  But, I may be looking for something a little more stringent.

First, you have to have a string that has a canonical form.
If it is not, then the string is likely something out of scope.

Second, you have to have a place in a header that you can be guaranteed to
find that canonical form.
We seem to be very squishy about that.  I don't want to have to know the
secret hand-shake to understand that.
(Standard versus clubs)  A recipient should not have to have a different
flavor or handling for aaa.com or bbb.com, or ...
Note, what someone does intra-domain may not matter.  At least at the
inter-domain boundary, be standard.

Third, if the normal rules state that the context of a string is defined by
a domain and not by the standard, and,
since you have previously stated (I think) that the domain can do whatever
it wants with the user part, 
then I really can't know that any user part string is an E.164 or something
else.
So, if it is within the scope of a domain, all bets are off.

The degree of flexibility you want to preserve is probably directly
proportional to the degree of non-interoperability you will get.

Mike

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Thursday, June 27, 2013 11:17 AM
To: Hadriel Kaplan; Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

>It does not matter if it started as 'sip:[email-masked];user=phone' 
>and got received as 'sip:[email-masked]'; because if the 
>terminator uses it as the E.164 phone number '12125551212' in his 
>systems and caller-id displays, then what he really needs to know is 
>that this call request came from someone with the authority to claim 
>'12125551212' - he does *not* need to know it really came from 
>'bbb.com', nor that it came from user '+1-212-555-1212', nor even that it
came from SIP.

Perhaps what some folks are missing here is the clear statement that both
the auth service and the verification service need to canonicalize the From
number to E.164 (actually a bit of a variant, but glossing over for
now) as a part of the signature generation/verification process.

The idea is basically this: when the auth signature is placed over
sip:[email-masked], the auth service canonicalizes 5551212 to
"12125551212", and that is what is signed over in the digest-strig of the
Identity header. In RFC4474 terms, this canonicalized string would take the
place of the addr-spec of the AoR in Section 9. When the verification
service receives [email-masked], it too canonicalizes that to
12125551212 for the purposes of regenerating the digest-string. Thus it
doesn't matter how From is munged. Nor do you need to store a copy of the
number anywhere in the message, which for the various reasons previously
discussed won't work.

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 28 Jun 2013 00:11:21 +0000

>If it is not, then the string is likely something out of scope.

Not sure what you mean.

>find that canonical form.

No, actually, I think the idea is just the opposite, that the canonical
form would not appear as a literal in the message. Both the auth service
and the verification service must have an algorithm that will let them
derive the (single identical) canonical form from what they find in the
From, however scungy it may be.

>secret hand-shake to understand that.

Secret handshakes are to be avoided, yes.

>So, if it is within the scope of a domain, all bets are off.

It is just an assumption of this model that the canonicalization is
possible. Clearly it is conceivable that a verification service will
receive a From and be unable to canonicalize the contents of its user part
into a valid telephone number - that would be an identity failure. If
intermediary systems cause that to happen, their policies would have to
change for identity to be possible.

>proportional to the degree of non-interoperability you will get.

The only thing this is trying to preserve is interoperability with
existing systems that rely on the From.

Jon Peterson
Neustar, Inc.

>From
>the

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jun 2013 20:20:16 -0400

Mike,

> If it is not, then the string is likely something out of scope.

The presumption is that the strings are whatever is in From and To, and 
they they *are not* in canonical form. But it is assumed that the signer 
can look at whatever is in the From and To it sees, and generate a 
canonical form to sign. And that the verifier can look at whatever is in 
the From and To *it* sees, and generate the canonical form to verify. 
And that the get the same result!

It is *not* assumed that the signer and the verifier are looking at the 
identical thing. Each may be looking at a non-canonical form that fits 
its local conventions, and that magic has resulted in the signer's form 
being transformed into the verifier's form.

It seems to me to be a lousy way to run a railroad, but that is what the 
deployed systems apparently like to do.

	Thanks,
	Paul

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 02:15:44 +0000

Jon,

Interesting.  What I hope to do as a recipient is not to have to be divining
tea leaves.
What you suggest below seems to me to be a pre-processor step that should be
wholly within the domain that wants to muck around with the From header.
By the time the From reaches the "public" network (or egress or interop
point) I would hope it is clear where and what is the number.
I can't rely on the From if I can't read it.

Mike

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Thursday, June 27, 2013 5:11 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Not sure what you mean.

>Second, you have to have a place in a header that you can be guaranteed 
>to find that canonical form.

No, actually, I think the idea is just the opposite, that the canonical form
would not appear as a literal in the message. Both the auth service and the
verification service must have an algorithm that will let them derive the
(single identical) canonical form from what they find in the From, however
scungy it may be.

>We seem to be very squishy about that.  I don't want to have to know 
>the secret hand-shake to understand that.

>(Standard versus clubs)  A recipient should not have to have a 
>different flavor or handling for aaa.com or bbb.com, or ...
>Third, if the normal rules state that the context of a string is 
>defined by a domain and not by the standard, and, since you have 
>previously stated (I think) that the domain can do whatever it wants 
>with the user part, then I really can't know that any user part string 
>is an E.164 or something else.

It is just an assumption of this model that the canonicalization is
possible. Clearly it is conceivable that a verification service will receive
a From and be unable to canonicalize the contents of its user part into a
valid telephone number - that would be an identity failure. If intermediary
systems cause that to happen, their policies would have to change for
identity to be possible.

>proportional to the degree of non-interoperability you will get.

The only thing this is trying to preserve is interoperability with existing
systems that rely on the From.

Jon Peterson
Neustar, Inc.

>Perhaps what some folks are missing here is the clear statement that 
>both the auth service and the verification service need to canonicalize 
>the From number to E.164 (actually a bit of a variant, but glossing 
>over for
>"12125551212", and that is what is signed over in the digest-strig of 
>the Identity header. In RFC4474 terms, this canonicalized string would 
>take the place of the addr-spec of the AoR in Section 9. When the 
>verification service receives [email-masked], it too 
>canonicalizes that to
>doesn't matter how From is munged. Nor do you need to store a copy of 
>the number anywhere in the message, which for the various reasons 
>previously discussed won't work.
>
>The requirement here that both the auth service and verification 
>service canonicalize numbers in the same fashion is absolute, and 
>perhaps non-trivial, but it's certainly way better than hop-by-hop
protection.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 02:21:00 +0000

But then you get the situation where:
A thinks X means Y, while
B thinks X means Z.
Verifying that it is truly X means different things to A and B.
So, A signs X and sends to B to confirm that the number is Y.
B  verifies X and confirms that the number is Z.

I don't think that is what we want.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Thursday, June 27, 2013 5:20 PM
To: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Mike,

> If it is not, then the string is likely something out of scope.

The presumption is that the strings are whatever is in From and To, and they
they *are not* in canonical form. But it is assumed that the signer can look
at whatever is in the From and To it sees, and generate a canonical form to
sign. And that the verifier can look at whatever is in the From and To *it*
sees, and generate the canonical form to verify. 
And that the get the same result!

It is *not* assumed that the signer and the verifier are looking at the
identical thing. Each may be looking at a non-canonical form that fits its
local conventions, and that magic has resulted in the signer's form being
transformed into the verifier's form.

	Thanks,
	Paul

> Second, you have to have a place in a header that you can be 
> guaranteed to find that canonical form.
> both the auth service and the verification service need to 
> canonicalize the From number to E.164 (actually a bit of a variant, 
> but glossing over for
> 12125551212 for the purposes of regenerating the digest-string. Thus 
> it doesn't matter how From is munged. Nor do you need to store a copy 
> of the number anywhere in the message, which for the various reasons 
protection.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 00:50:04 -0400

> B  verifies X and confirms that the number is Z.

I thought Jon did a good job of explaining this.

In the above case, A thinks X means Y, so A generates a signature over 
Y. Then when B attempts to verify, it does so over Z, so the 
verification fails.

> I don't think that is what we want.

Its not what we want. And hopefully its not what A and B want either. So 
I guess they would be motivated to agree on the meaning of X.

The real world implication of this is that A provides X as the callerid. 
To call A, in general you must call some dial string that yields the 
E.164 Y. When this reaches B, perhaps X is displayed as the callerid. 
But when used as a dial string in B's context, it calls the E.164 Z. 
Since a callback wouldn't reach A, its reasonable that the callerid 
doesn't verify.

IMO this just highlights the need to move to a world where E.164 numbers 
are passed around. If desired, they can be *rendered* as convenient dial 
string that corresponds to that E.164, but that should be a local action.

Or we could just give up on phone numbers because they are unfixable.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 00:59:13 -0400

I think you guys either keep missing the point, or you choose to ignore it.  The point is we have proof the concept can work, because things work today.

It simply can't be the case that domain A thinks a literal "X" means Y, and domain B thinks literal "X" means Z, and that a message domain A sent had "X" written on it and when B got it it still says "X".  Because if that were true, things wouldn't work right now - forget signing anything, or STIR, or whatever.  Domain A and B couldn't be communicating today if that were the case.  Calls would be going to the wrong people all day.  So clearly, by the time domain B gets the message from domain A, the message must now say something that means Y to domain B - it could be a literal "Y", or it could be "W".  It doesn't actually matter what the literal string is, so long as A and B both can figure out it means Y.  And we're going to have domain A sign as if it said Y all along, not the literal "X"; and we're going to have domain B verify for Y as well, not the literal "W" or whatever.  We just won't make them change whatever literal character it is they use on-the-wire already.

I know it sucks - no one's saying it's the ideal world.  It will probably take some configuration, on the signing system or verifying system or both.  But that's better than changing configuration, code, or behavior of every other system in all the domains at the same instant.

And it's not as bad as it seems, either.  It's not like people are changing "+12125551212" into "djbDVbovur".
:)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 02:08:59 -0400

Maybe an analogy would help...

Let's say you're a member of the New Hampshire division of the American Automobile Association (AAA) in the USA.  And let's say AAA provides their members with a web-form to fill out if they want to complain about a car design defect, and that AAA sends the complaint on to the Better Business Bureau (BBB), who then sends the complaint on to the car manufacturer.

So you go on the New Hampshire AAA website and fill out a form to complain about your car, a Dodge Durango SUV - Dodge being a division of Chrysler Car Company (CCC).  The AAA web-form has a field asking you what your phone-number is, so that you can be contacted for more information if need be.  And let's say since this website is for New Hampshire members, that the web-form accepts a phone-number such as the literal string "555-1212".  There's no +1 needed because it's a US-based customer web-form, and no "603" area-code because it knows you're from New Hampshire.

So AAA has some back-end systems that crunch this web-form input, and those systems have no idea what format the Dodge Durango Division (DDD) of Chrysler Car Company (CCC) expects to get it as.  But they do know how the BBB expects it, and the BBB expects it in the format "603-555-1212", so the AAA back-end systems convert it to that and send it to the BBB.  The BBB likewise doesn't know Dodge's format, but they know Chrysler and their format, so BBB's systems convert it to CCC's which is "+16035551212".  Chrysler then routes this complaint to Dodge Durango Division, who happens to expect it as "+1.603.555.1212".

So we have:
[email-masked] -> [email-masked] -> [email-masked] -> [email-masked]

None of these domains along the way are "confused" about what your number really is, yet they all have a different syntactic representation for it on-the-wire.

So along comes the IETF, and we're worried that customer complaint forms are getting received by car companies with spoofed customer contact phone-numbers.

What should we do?  Should we say: "sorry, everyone's systems are broken - please go fix them all to use a single syntax so we can sign and verify it on both ends".  That wouldn't happen, and isn't necessary.

Instead, we're saying: "the forms are what they are to each domain and we can't change that, but the New Hampshire AAA signing system has to sign the E.164 equivalent to what its form says, and the Dodge Durango Division verification system has to verify the E.164 equivalent to what its form says."  

It sounds silly, but it will work - both AAA and DDD do know what the E.164 really is, regardless of what was put in the complaint form, and despite the fact they have no idea what format/syntax the other one uses.  And the proof of that is that their complaint form mechanism works today already; it's just getting spoofed with fake numbers.

-hadriel
p.s. This was a fictional example - I have no idea if AAA provides complaint web-forms or how they get to Dodge.
:)

On Jun 27, 2013, at 8:20 PM, Paul Kyzivat <[email-masked]> wrote:

> The presumption is that the strings are whatever is in From and To, and they they *are not* in canonical form. But it is assumed that the signer can look at whatever is in the From and To it sees, and generate a canonical form to sign. And that the verifier can look at whatever is in the From and To *it* sees, and generate the canonical form to verify. And that the get the same result!
> 
> It is *not* assumed that the signer and the verifier are looking at the identical thing. Each may be looking at a non-canonical form that fits its local conventions, and that magic has resulted in the signer's form being transformed into the verifier's form.
> 
> It seems to me to be a lousy way to run a railroad, but that is what the deployed systems apparently like to do.
> 
> 	Thanks,
> 	Paul

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Fri, 28 Jun 2013 08:56:27 +0200

Yes, this is a sample of legitimate Caller-ID spoofing ;-)

However, there are solutions for it.
We can allow multiple signees for each phone number and thus there is a solution for re-signing as long as it is guaranteed that all signees are enrolled and authenticated by the CA. This will be a classic PKI delegation and will be perfectly valid.

As such, PKI can support our beloved hop-by-hop model as well.
Of course, this will require that all "re-signees" are enrolled as a delegated authoritative  signee for this particular number as well. So your example can be served well by PKI delegation models.

Willi

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 08:42:02 +0000

Hadriel,

Re:  So AAA has some back-end systems that crunch this web-form input, and
those systems have no idea what format the Dodge Durango Division (DDD) of
Chrysler Car Company (CCC) expects to get it as.  But they do know how the
BBB expects it...  STOP right there.

That is an assumption that will often not hold.  And is precisely my
problem.  You assume that any given sender knows how to format for every
given recipient.
The issue of dots, dashes, or none is a sideshow.

What if AAA decides to send as:  From:  [email-masked]

And if BBB looks at that and because BBB is in another area code (703), it
thinks that to extract, interpret, and expand it becomes +1-703-555-1212
versus +1-603-555-1212 then you get errors.
Now compound that with different countries.  You will gets lots of failures.

The phone system routes on other headers, so what is in the From header
doesn't matter, so using that as an argument  of "well the system knows how
to route" doesn't mean anything.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Thursday, June 27, 2013 11:09 PM
To: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Let's say you're a member of the New Hampshire division of the American
Automobile Association (AAA) in the USA.  And let's say AAA provides their
members with a web-form to fill out if they want to complain about a car
design defect, and that AAA sends the complaint on to the Better Business
Bureau (BBB), who then sends the complaint on to the car manufacturer.

So you go on the New Hampshire AAA website and fill out a form to complain
about your car, a Dodge Durango SUV - Dodge being a division of Chrysler Car
Company (CCC).  The AAA web-form has a field asking you what your
phone-number is, so that you can be contacted for more information if need
be.  And let's say since this website is for New Hampshire members, that the
web-form accepts a phone-number such as the literal string "555-1212".
There's no +1 needed because it's a US-based customer web-form, and no "603"
area-code because it knows you're from New Hampshire.

So AAA has some back-end systems that crunch this web-form input, and those
systems have no idea what format the Dodge Durango Division (DDD) of
Chrysler Car Company (CCC) expects to get it as.  But they do know how the
BBB expects it, and the BBB expects it in the format "603-555-1212", so the
AAA back-end systems convert it to that and send it to the BBB.  The BBB
likewise doesn't know Dodge's format, but they know Chrysler and their
format, so BBB's systems convert it to CCC's which is "+16035551212".
Chrysler then routes this complaint to Dodge Durango Division, who happens
to expect it as "+1.603.555.1212".

So we have:
[email-masked] -> [email-masked] -> [email-masked] ->
[email-masked]

None of these domains along the way are "confused" about what your number
really is, yet they all have a different syntactic representation for it
on-the-wire.

So along comes the IETF, and we're worried that customer complaint forms are
getting received by car companies with spoofed customer contact
phone-numbers.

What should we do?  Should we say: "sorry, everyone's systems are broken -
please go fix them all to use a single syntax so we can sign and verify it
on both ends".  That wouldn't happen, and isn't necessary.

Instead, we're saying: "the forms are what they are to each domain and we
can't change that, but the New Hampshire AAA signing system has to sign the
E.164 equivalent to what its form says, and the Dodge Durango Division
verification system has to verify the E.164 equivalent to what its form
says."  

It sounds silly, but it will work - both AAA and DDD do know what the E.164
really is, regardless of what was put in the complaint form, and despite the
fact they have no idea what format/syntax the other one uses.  And the proof
of that is that their complaint form mechanism works today already; it's
just getting spoofed with fake numbers.

-hadriel
p.s. This was a fictional example - I have no idea if AAA provides complaint
web-forms or how they get to Dodge.
:)

> The presumption is that the strings are whatever is in From and To, and
they they *are not* in canonical form. But it is assumed that the signer can
look at whatever is in the From and To it sees, and generate a canonical
form to sign. And that the verifier can look at whatever is in the From and
To *it* sees, and generate the canonical form to verify. And that the get
the same result!

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 28 Jun 2013 12:44:01 +0000

+1

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, June 28, 2013 2:09 AM
To: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

So we have:

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 05:54:36 -0700

On 6/27/2013 11:08 PM, Hadriel Kaplan wrote:
> Instead, we're saying: "the forms are what they are to each domain
> and we can't change that, but the New Hampshire AAA signing system
> has to sign the E.164 equivalent to what its form says, and the Dodge
> Durango Division verification system has to verify the E.164
> equivalent to what its form says."

Context-dependent forms, for global values, became antithetical to 
Internet standards at least 35 years ago.  They are fragile enough to 
threaten interoperability.  The issue isn't that one can specify a 
scenario that can work, but how easily one can instead fall into a 
scenario that doesn't; notably, take the form, without context 
descriptors, and give it to someone else, such as if Dodge moves and the 
form isn't converted to the new, local conventions.

But alas, as you've made clear, the use of the From field is established 
practice.

So we have to start with text along the lines of your "signers and 
verifiers convert the number to its E.164 equivalent, before performing 
the cryptographic functions."

My guess is that the non-e.164 forms have limited variations.  That is, 
I suspect we/you know what other forms the number can be in.  I suggest 
performing the case analysis, listing each and specifying what is needed 
to covert it to E.164.

Absent something like this, we've got an Internet standard that begins 
with reliance on whatever local heuristic folks feel like using. 
Heuristics are essential to some programing but, as I said, they are 
antithetical to global standards.

d/

---

From: <[email-masked]>
Date: Fri, 28 Jun 2013 13:12:48 +0000

> Now compound that with different countries.  You will gets lots of failures.

I don't know if the following will help but the reason why this would fail in theory but is indeed going to work in practice IMHO is that the number of those "implicit contexts" that signers and verifiers share is limited and not combinatory (and more or less match the legacy Numbering Plan / Type of Number of other signaling oddly enough...):
a) (no context) full international
b) national
c) local
d) private (out of scope) 

If for some reason, the signer sends a local format outside the area code or a national format cross border, verification is indeed going to fail because the canonical form cannot be derived from the CgP, but as Hadriel said the calling party number is meaningless to the callee anyway regardless of what stir does. All other cases where the full context is not provided will happen within the above categories not across. 

The question for stir might be whether that may provide a backdoor to avoid a "reject unsigned CLI" policy, but the problem is there anyway - and again quite limited. 

Now as I've already said, since what is conveyed and what is displayed are too different things, I'm still convinced that providing the full format if it's not too much work for the caller is always preferable, but not everyone does that, such is life.

[it seems this is along the lines of what Dave's just posted but I still hope it helps :)] 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Friday, June 28, 2013 10:42 AM
To: [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Hadriel,

Mike

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

So we have:

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 11:07:58 -0400

> Of course, this will require that all "re-signees" are enrolled as a delegated authoritative  signee for this particular number as well. So your example can be served well by PKI delegation models.

You're joking Willi, right?
I know you have a dry sense of humor, so I often can't tell when you're joking or not.
(sarcasm and dry humor doesn't always convey itself as such in email)

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 08:09:39 -0700

[Semi-randomly picking a message to reply to...]

First, let me say that I'm not at all wedded to anything in the proposal
that bears my name and that I presented at the original STIR meeting.
That proposal was designed to match a specific set of needs and
if those needs aren't needed, then so much the better.

With that said, my impression going into that meeting and from the
discussion so far was that in fact for the foreseeable future we are
going to have environments where:

(1) We want to have secure caller-id
(2) We basically can't put anything meaningful in the messages that
go from caller to callee (I hasten to add that I don't know anywhere
near enough about SS7 to know if that's true, but that was my
impression).

If that's true, then it seems like we really should be considering some
non-inband solution from the get-go.

So, for the people who favor not doing a non-inband solution, do you
think that one of the two claims above is untrue? Or do you just don't
think it follows that we should be doing something about it?

Thanks,
-Ekr

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <[email-masked]> wrote:

> to
> been

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 11:26:18 -0400

But we have existence proof that cannot be the case: BBB could not possibly be expanding it to +1-703-555-1212 today, because by the time Dodge gets it they wouldn't be able to use it for the customer contact number.  I set the analogy up this way because it's similar to phone calls: the From is in fact being used by the terminating carrier already right now; just like Dodge is already using the customer contact number in the analogy.

For example when it reaches your phone, your phone displays some caller-id that has meaning to your phone/you, and it's not making the mistake of showing +1-703-555-1212 for calls from +1-603-555-1212 today.  And the terminating carriers offer things like voicemail, CNAM, *69 callback, and billing records - and all those things work right now, and use the caller-id/From, and aren't getting confused about the area code.  And in fact even the transit carriers (ie, BBB) often use the From phone number today - they use it for least-cost-routing for example, and billing.

And the problem we're being told to go fix isn't that the terminating carriers can't figure out the From's E.164 numbers - they can - their problem is the caller-id's are being misrepresented on-purpose.  

Or to bring it back to the car analogy: Dodge isn't telling us "we can't figure out what the human put in AAA's original web-forms" - they're telling us people are *lying* when they fill out the web-forms.

-hadriel

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 28 Jun 2013 15:37:37 +0000

Eric:
Here's the problem I see: The out of band solution assumes that there is something at the terminating end that is able to make use of the out of band mechanism. This is not going to be generally true until the circuit switched network is mostly retired; customers hanging off a circuit switch aren't going to be protected.
Once we have end to end SIP we can do something in-band.
People might like to have a rapid solution but I just don't see it happening without major refits to the legacy network. So, I'd prefer to concentrate on getting things right in the new world, even if that world isn't coming as soon as any of us would like.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; [email-masked]; Dave Crocker; Brian Rosen; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

Thanks,
-Ekr

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:
+1 as well ... take it out of the charter.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Brian Rosen; Hadriel Kaplan; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band
+1

> bbiw.net<http://bbiw.net>
> [email-masked]<mailto:[email-masked]>

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

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 11:41:47 -0400

> think it follows that we should be doing something about it?

We had a long email debate about it, and it's not as simple as that.  Even if one only considers those two claims in isolation, it's not as simple as "yes" or "no" to *either* of those claims.  I would give you the readers-digest version, but undoubtedly it would be a subjective view of it, and would just open up the debate all over again.

I think, though, that we reached consensus not to have it in the charter for this BOF and WG formation; that way we don't bog down the BOF debating it on microphones and running out of time.  We can always recharter after there's a WG, if there's WG consensus to do so.  And if there isn't WG consensus to do so later, then that tells you this particular WG shouldn't be doing it.

-hadriel

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Jun 2013 15:45:46 +0000

Testing while developing VIPR indicated that UUI does not survive all the carrier to carrier transitions.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 08:47:24 -0700

On Fri, Jun 28, 2013 at 8:41 AM, Hadriel Kaplan
<[email-masked]>wrote:

> We had a long email debate about it, and it's not as simple as that.  Even
> if one only considers those two claims in isolation, it's not as simple as
> "yes" or "no" to *either* of those claims.  I would give you the
> readers-digest version, but undoubtedly it would be a subjective view of
> it, and would just open up the debate all over again.
>

Well, I did read the debate, but frankly, I didn't think it really was that
responsive to this. So I actually do think it would be useful.

> I think, though, that we reached consensus not to have it in the charter
> for this BOF and WG formation;

Is that actually true? It was also not my sense that there was consensus on
this point.
For instance, did I miss a message where Jon agreed to that?

-Ekr

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Jun 2013 15:48:25 +0000

+1 

I think we need both the modes to happen at same time as the incremental deployment of one greatly improves the chance of any deployment of the second mode. And deployment of that second mode is how we can get to the very high percentages of calls to have a valid identity. I also think the dual approach will make it much easier to get to consensus on on the actually mechanism in the WG as we won't have the proponents of one type trying to turn the other type into the type they prefer. 

I'd prefer the charter to be clear that both in-band and out-band was the intended direction of the group. 

Cullen

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 08:48:20 -0700

On Fri, Jun 28, 2013 at 8:37 AM, PFAUTZ, PENN L <[email-masked]> wrote:

>  Eric:****
>
> Here’s the problem I see: The out of band solution assumes that there is
> something at the terminating end that is able to make use of the out of
> band mechanism.
>

Of course.

>  This is not going to be generally true until the circuit switched network
> is mostly retired; customers hanging off a circuit switch aren’t going to
> be protected.
>

Why is that true? A huge fraction of circuit switched devices are now
smartphones,
which could absolutely make use of such a mechanism. In fact, that's
precisely
the environment for which the system in question was designed.

-Ekr

> ****
>
> Once we have end to end SIP we can do something in-band.****
>
> People might like to have a rapid solution but I just don’t see it
> happening without major refits to the legacy network. So, I’d prefer to
> concentrate on getting things right in the new world, even if that world
> isn’t coming as soon as any of us would like.****
>
> ** **
>
> ** **
>
> ** **
>
> Penn Pfautz****
>
> AT&T Access Management****
>
> +1-732-420-4962****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Eric Rescorla
> *Sent:* Friday, June 28, 2013 11:10 AM
> *To:* Richard Shockey
> *Cc:* Wendt, Chris; Hadriel Kaplan; [email-masked]; Dave Crocker; Brian
> Rosen; Henning Schulzrinne
>
> *Subject:* Re: [stir] Out-of-band vs. in-band****
>
> ** **
>
> [Semi-randomly picking a message to reply to...]****
>
> ** **
>
> First, let me say that I'm not at all wedded to anything in the proposal**
> **
>
> that bears my name and that I presented at the original STIR meeting.****
>
> That proposal was designed to match a specific set of needs and****
>
> if those needs aren't needed, then so much the better.****
>
> ** **
>
> With that said, my impression going into that meeting and from the****
>
> discussion so far was that in fact for the foreseeable future we are****
>
> going to have environments where:****
>
> ** **
>
> (1) We want to have secure caller-id****
>
> (2) We basically can't put anything meaningful in the messages that****
>
> go from caller to callee (I hasten to add that I don't know anywhere****
>
> near enough about SS7 to know if that's true, but that was my****
>
> impression).****
>
> ** **
>
> If that's true, then it seems like we really should be considering some***
> *
>
> non-inband solution from the get-go.****
>
> ** **
>
> So, for the people who favor not doing a non-inband solution, do you****
>
> think that one of the two claims above is untrue? Or do you just don't****
>
> think it follows that we should be doing something about it?****
>
> ** **
>
> Thanks,****
>
> -Ekr****
>
> ** **
>
> ** **
>
> On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <[email-masked]>
> wrote:****
>
> +1 as well ... take it out of the charter.****
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of***
> *
>
> Wendt, Chris
> To: <[email-masked]>****
>
> Subject: Re: [stir] Out-of-band vs. in-band****
>
> +1
>
> https://www.ietf.org/mailman/listinfo/stir****
>
> ** **
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 16:21:54 +0000

To prove that A exists is not a proof that B cannot exist.

Second, your analogy relies on the partial discipline of the PSTN, that you
also later note can be intentionally broken.
What you don't yet recognize is that one can also unintentionally break
things, unless some discipline removes the possibility (application of
Murphy's Law).

Third, you assume that all senders and receivers know all others a priori
and that all know each other's conventions.  
You have not yet proven that is a reasonable assumption.
While 100 years of history have allowed the accumulation of such knowledge
in the PSTN, that doesn't transfer to the Internet.

So, you need to get back to the fundamental question I am asking.
What data does the function at the receive side need to rely on, and where
does it get that information?

The second you start assuming a priori out-of-band knowledge, this breaks.
Unless you can show me how that knowledge can be learned upon receipt of the
call, I am not buying it.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, June 28, 2013 8:26 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

But we have existence proof that cannot be the case: BBB could not possibly
be expanding it to +1-703-555-1212 today, because by the time Dodge gets it
they wouldn't be able to use it for the customer contact number.  I set the
analogy up this way because it's similar to phone calls: the From is in fact
being used by the terminating carrier already right now; just like Dodge is
already using the customer contact number in the analogy.

For example when it reaches your phone, your phone displays some caller-id
that has meaning to your phone/you, and it's not making the mistake of
showing +1-703-555-1212 for calls from +1-603-555-1212 today.  And the
terminating carriers offer things like voicemail, CNAM, *69 callback, and
billing records - and all those things work right now, and use the
caller-id/From, and aren't getting confused about the area code.  And in
fact even the transit carriers (ie, BBB) often use the From phone number
today - they use it for least-cost-routing for example, and billing.

And the problem we're being told to go fix isn't that the terminating
carriers can't figure out the From's E.164 numbers - they can - their
problem is the caller-id's are being misrepresented on-purpose.  

Or to bring it back to the car analogy: Dodge isn't telling us "we can't
figure out what the human put in AAA's original web-forms" - they're telling
us people are *lying* when they fill out the web-forms.

-hadriel

On Jun 28, 2013, at 4:42 AM, Michael Hammer <[email-masked]>
wrote:

> Hadriel,
> 
> Re:  So AAA has some back-end systems that crunch this web-form input, 
> and those systems have no idea what format the Dodge Durango Division 
> (DDD) of Chrysler Car Company (CCC) expects to get it as.  But they do 
> know how the BBB expects it...  STOP right there.
> 
> problem.  You assume that any given sender knows how to format for 
> every given recipient.
> And if BBB looks at that and because BBB is in another area code 
> (703), it thinks that to extract, interpret, and expand it becomes 
> +1-703-555-1212 versus +1-603-555-1212 then you get errors.
> The phone system routes on other headers, so what is in the From 
> header doesn't matter, so using that as an argument  of "well the 
> system knows how to route" doesn't mean anything.
> 
> Mike
> 
> 
> Of Hadriel Kaplan
> Let's say you're a member of the New Hampshire division of the 
> American Automobile Association (AAA) in the USA.  And let's say AAA 
> provides their members with a web-form to fill out if they want to 
> complain about a car design defect, and that AAA sends the complaint 
> on to the Better Business Bureau (BBB), who then sends the complaint on to
the car manufacturer.
> 
> So you go on the New Hampshire AAA website and fill out a form to 
> complain about your car, a Dodge Durango SUV - Dodge being a division 
> of Chrysler Car Company (CCC).  The AAA web-form has a field asking 
> you what your phone-number is, so that you can be contacted for more 
> information if need be.  And let's say since this website is for New 
> Hampshire members, that the web-form accepts a phone-number such as the
literal string "555-1212".
> So AAA has some back-end systems that crunch this web-form input, and 
> those systems have no idea what format the Dodge Durango Division 
> (DDD) of Chrysler Car Company (CCC) expects to get it as.  But they do 
> know how the BBB expects it, and the BBB expects it in the format 
> "603-555-1212", so the AAA back-end systems convert it to that and 
> send it to the BBB.  The BBB likewise doesn't know Dodge's format, but 
> they know Chrysler and their format, so BBB's systems convert it to CCC's
which is "+16035551212".
> Chrysler then routes this complaint to Dodge Durango Division, who 
> happens to expect it as "+1.603.555.1212".
> 
> So we have:
> None of these domains along the way are "confused" about what your 
> number really is, yet they all have a different syntactic 
> representation for it on-the-wire.
> 
> So along comes the IETF, and we're worried that customer complaint 
> forms are getting received by car companies with spoofed customer 
> contact phone-numbers.
> 
> What should we do?  Should we say: "sorry, everyone's systems are 
> broken - please go fix them all to use a single syntax so we can sign 
> and verify it on both ends".  That wouldn't happen, and isn't necessary.
> 
> Instead, we're saying: "the forms are what they are to each domain and 
> we can't change that, but the New Hampshire AAA signing system has to 
> sign the
> verification system has to verify the E.164 equivalent to what its 
> form says."
> 
> It sounds silly, but it will work - both AAA and DDD do know what the 
> E.164 really is, regardless of what was put in the complaint form, and 
> despite the fact they have no idea what format/syntax the other one 
> uses.  And the proof of that is that their complaint form mechanism 
> works today already; it's just getting spoofed with fake numbers.
> 
> -hadriel
> p.s. This was a fictional example - I have no idea if AAA provides 
> complaint web-forms or how they get to Dodge.
> :)
> 
> 
> they they *are not* in canonical form. But it is assumed that the 
> signer can look at whatever is in the From and To it sees, and 
> generate a canonical form to sign. And that the verifier can look at 
> whatever is in the From and To *it* sees, and generate the canonical 
> form to verify. And that the get the same result!
>> 
> its local conventions, and that magic has resulted in the signer's 
> form being transformed into the verifier's form.
>>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 28 Jun 2013 16:28:22 +0000

One more point.

The solution needs to handle calls from a domain that you have never heard
from before.
That domain may have just been created an hour before.

We need a truly global solution when folks follow the IETF RFCs.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Friday, June 28, 2013 9:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, June 28, 2013 8:26 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

-hadriel

the car manufacturer.
which is "+16035551212".

---

From: Dave Crocket <[email-masked]>
Date: Fri, 28 Jun 2013 09:47:47 -0700

Forgive my confusion, but is Jon's agreement required, before being able to declare consensus?

Eric Rescorla <[email-masked]> wrote:

>------------------------------------------------------------------------
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: williw <[email-masked]>
Date: Fri, 28 Jun 2013 18:50:01 +0200

No Im serious and we shall learn little by little how to handle signatures for Internet services.
Nevertheless I might need to learn how to finetune the possibilities a bit mor.

Hennings proposed multi (3) phase approach is definitely a good start we shall think about.

WIlli

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 09:54:02 -0700

> Forgive my confusion, but is Jon's agreement required, before being able

Of course not. However, to my knowledge there also hasn't been a
formal consensus call, so any assertions about consensus are
merely individual's sense of the list. Did I miss such a call?

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 10:06:56 -0700

Formal??? I think you are mistaking this with a working group.  It is difficult for a group with no formal existance or structure to have formal decision making.

On the other hand it is quite easy to review postings and see whether those participating in the discussion expressed views that converged in a way that could reasonably be called consensus.

Eric Rescorla <[email-masked]> wrote:

>> Forgive my confusion, but is Jon's agreement required, before being
>able
>> to declare consensus?
>>
>

-- 
Dave Crocker
bbiw.net

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 10:12:48 -0700

On Fri, Jun 28, 2013 at 10:06 AM, Dave Crocker <[email-masked]> wrote:

> Formal??? I think you are mistaking this with a working group. It is
> difficult for a group with no formal existance or structure to have formal
> decision making.
>
> On the other hand it is quite easy to review postings and see whether
> those participating in the discussion expressed views that converged in a
> way that could reasonably be called consensus.
>

This seems like a digression, but surely you know well that mailing
list volume is not necessarily an accurate gauge of the views of
the group.

Regardless, I don't think that there has been a sufficient level of
demonstrated consensus to justify the assertion of Hadriel's
to which I was replying.

-Ekr

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 28 Jun 2013 13:22:49 -0400

This is not going to be generally true until the circuit switched network is
mostly retired; customers hanging off a circuit switch aren't going to be
protected.

[RS> ]  Frankly I would doubt that.  I would imagine the mobile operators
and Apple would object to anything that creates more signaling over the air.
Battery life. Its already an issue in VoLTE deployments.  I have trouble
imagining any E2E scenarios in a first phase deployment and Penn is
absolutely correct that there are not going to be any major retrofits of the
legacy networks, certainly not in North America.

If the BOF is going to turn on in vs out of band vs both, historically we
tend to note that the IETF works best when it builds on some success with
one first. 

-Ekr

People might like to have a rapid solution but I just don't see it happening
without major refits to the legacy network. So, I'd prefer to concentrate on
getting things right in the new world, even if that world isn't coming as
soon as any of us would like.

Penn Pfautz

AT&T Access Management

 <tel:%2B1-732-420-4962> +1-732-420-4962

From:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] On Behalf Of Eric
Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan;  <mailto:[email-masked]> [email-masked];
Dave Crocker; Brian Rosen; Henning Schulzrinne

impression).

Thanks,

-Ekr

On Wed, Jun 26, 2013 at 8:33 AM, Richard Shockey <[email-masked]
<mailto:[email-masked]> > wrote:

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of

Wendt, Chris
Sent: Tuesday, June 25, 2013 1:20 PM
To: <[email-masked] <mailto:[email-masked]> >

Cc: [email-masked] <mailto:[email-masked]> ; Brian Rosen; Hadriel Kaplan;
Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

+1

> bbiw.net <http://bbiw.net> 
> [email-masked] <mailto:[email-masked]> 

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 10:28:01 -0700

On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey <[email-masked]>wrote:

> be protected.****
> smartphones,****
> precisely****
> the environment for which the system in question was designed.****
>
> ** **
>
> *[RS> ]  Frankly I would doubt that.  I would imagine the mobile
> operators and Apple would object to anything that creates more signaling
> over the air.  Battery life. Its already an issue in VoLTE deployments.  I
> have trouble imagining any E2E scenarios in a first phase deployment and
> Penn is absolutely correct that there are not going to be any major
> retrofits of the legacy networks, certainly not in North America.*
>

I'm really not following this.

1. We're talking about something on the order of 10KB of traffic/call.
My iphone uses this much bandwidth every time it polls my email
server. This has a trivial impact on battery life.

2. It doesn't need a retrofit of the network, just the phone software.
That's the point.

-Ekr

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 28 Jun 2013 17:49:33 +0000

No retrofits in legacy networks

Martin Dolly
AT&T

Sent from my iPhone

On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <[email-masked]<mailto:[email-masked]>> wrote:

This is not going to be generally true until the circuit switched network is mostly retired; customers hanging off a circuit switch aren’t going to be protected.

Why is that true? A huge fraction of circuit switched devices are now smartphones,
which could absolutely make use of such a mechanism. In fact, that's precisely
the environment for which the system in question was designed.

[RS> ]  Frankly I would doubt that.  I would imagine the mobile operators and Apple would object to anything that creates more signaling over the air.  Battery life. Its already an issue in VoLTE deployments.  I have trouble imagining any E2E scenarios in a first phase deployment and Penn is absolutely correct that there are not going to be any major retrofits of the legacy networks, certainly not in North America.

If the BOF is going to turn on in vs out of band vs both, historically we tend to note that the IETF works best when it builds on some success with one first.

-Ekr

Once we have end to end SIP we can do something in-band.
People might like to have a rapid solution but I just don’t see it happening without major refits to the legacy network. So, I’d prefer to concentrate on getting things right in the new world, even if that world isn’t coming as soon as any of us would like.

Penn Pfautz
AT&T Access Management
+1-732-420-4962<tel:%2B1-732-420-4962>
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Friday, June 28, 2013 11:10 AM
To: Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; [email-masked]<mailto:[email-masked]>; Dave Crocker; Brian Rosen; Henning Schulzrinne

Thanks,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 10:51:00 -0700

Could you perhaps elaborate?

-Ekr

On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C <[email-masked]> wrote:

> On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <[email-masked]> wrote:
>
>   ** **
>
> ** **
>
>  ****
>
>  This is not going to be generally true until the circuit switched
> network is mostly retired; customers hanging off a circuit switch aren’t
> going to be protected.****
>
>  ** **
>
> * *
> *If the BOF is going to turn on in vs out of band vs both, historically
> we tend to note that the IETF works best when it builds on some success
> with one first. *
>
> * *
>
> * *
>
> ** **
>
> -Ekr****
>
>  ****
>
> Rosen; Henning Schulzrinne****
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Jun 2013 14:07:42 -0400

> list volume is not necessarily an accurate gauge of the views of

Unfortunately that's all we have to go on for now.  There is no WG. (fwiw, ISTM that many WG's in the IETF do in fact use email volume to gauge things, but I digress...)

> demonstrated consensus to justify the assertion of Hadriel's

That's fair, and I should have been much more careful with what I said - I should have been clearer that I didn't mean unanimous agreement - we definitely do NOT have that.  I meant it more as a "I believe the majority opinion is..."   

And it's certainly possible my perception of a thinking even that is wrong, and that we might be evenly divided instead, or that even the majority might favor having both in-band and out-of-band in the charter.  I don't *think* that's the case, but I could be wrong.

I will say though that if I count the multiple personalities/voices in my head, I outnumber all of you. ;)

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 28 Jun 2013 18:28:12 +0000

No changes to legacy switches to likely include CS-PS GW

Martin Dolly
AT&T

Sent from my iPhone

On Jun 28, 2013, at 1:51 PM, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:
No retrofits in legacy networks

Martin Dolly
AT&T

Sent from my iPhone

-Ekr

Penn Pfautz
AT&T Access Management

Thanks,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Jun 2013 11:39:15 -0700

Sure, I think that's consistent with that I'm saying.

-Ekr

On Fri, Jun 28, 2013 at 11:28 AM, DOLLY, MARTIN C <[email-masked]> wrote:

> On Jun 28, 2013, at 1:51 PM, "Eric Rescorla" <[email-masked]> wrote:
>
>> First, let me say that I'm not at all wedded to anything in the proposal*
>> ***
>>
>> If that's true, then it seems like we really should be considering some**
>> **
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of**
>> **
>>
>> Wendt, Chris
>> when
>>  I

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 28 Jun 2013 14:44:28 -0400

It is perfectly clear to those of us that have some intimate knowledge of
North American carrier networks that neither the Incumbent LEC's , CLEC's
nor the existing mobile operators will not make any new, much less
incremental investments in  TDM infrastructures.  Go try and get some parts
for a DMS 500 or 5ESS switch these days. 

All of it is gradually moving to SIP/IMS architectures.  Cable, with some
exceptions, has never relied on TDM in the core.  There is some chance of
implementation at the Gateways where SIP/TDM meet but that is another issue.

http://www.fiercebroadbandwireless.com/story/t-wants-fccs-blessing-shut-down
-pstn/2010-01-03 

That said there is a staggering amount of SIP, SIP Interconnection AND
DNS/ENUM btw in all NA carrier networks especially those that support SIP
Trunking in the enterprise.  Existing VZ  FIOS and ATT uVerse  networks use
SIP/IMS in the core but the legacy handsets in the home are treated as
B2BUA. Europe is somewhat behind but there are similar trends there. 

FCC Form 477 data now indicates that about 1/3 of all US Voice is SIP/IMS
based but not fully SIP/IMS interconnected. Most of it is converted to TDM
for interconnection for a lot of regulatory reasons I won't bore you with.
(Section 251 of Act) 

All of the existing mobile CDMA/GSM networks still rely on TDM switches for
the Voice service. That is going to change in 18-48 months as IMS based
VoLTE rolls out so a handset tablet solution MAY be possible then.   Those
existing C5 switches in the mobile networks will be phased out within 5
years or so since the mobile operators want to refarm the existing spectrum
to LTE. In fact your scenario won't work on the any existing Version or
Sprint networks since CDMA does not allow for WIFI access and voice at the
same time.  Sorry 

Marty and Penn are right. The point Hadriel and I have been trying to make
is the STIR solution(s) selected actually have to confront the reality of
what can and will deploy given carrier capital budgets and overall long term
strategy.  The argument is that if out of band will have a "chalangening"
deployment environment it makes sense to start with in band first and build
on success. 

I can also point out that this is at the heart of the DNS v HTTPS wars on
lookup transport we will resume eventually.

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rescorla
Sent: Friday, June 28, 2013 1:51 PM
To: DOLLY, MARTIN C
Cc: [email-masked]; Henning Schulzrinne; Dave Crocker; Richard Shockey
Subject: Re: [stir] Out-of-band vs. in-band

-Ekr

On Fri, Jun 28, 2013 at 10:49 AM, DOLLY, MARTIN C <[email-masked]
<mailto:[email-masked]> > wrote:

Martin Dolly

AT&T 

Sent from my iPhone

On Jun 28, 2013, at 1:23 PM, "Richard Shockey" <[email-masked]
<mailto:[email-masked]> > wrote:

 

-Ekr

 

Penn Pfautz

AT&T Access Management

impression).

Thanks,

-Ekr

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

Wendt, Chris

+1

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 14:27:43 -0700

Eric,

> (1) We want to have secure caller-id

My conclusion, after some years of trying to carefully learn security 
terminology is that one of the words that has ceased to have any 
technical meaning is "secure".  It's too vague.  As Hadriel notes, 
there's a very specific bit of protection that is being targeted for 
STIR, with all sorts of other, appealing protection deemed out of scope.

So for debating what to do or how to do it, we probably should try to be
painfully precise in our labels, if only so that non-security pretenders
like me can guess at what is really meant, with some hope of guessing 
correctly...

The simple form as I understand it is to permit actors along the call
setup path to validate authorization for the telephone number that is
used in the From field.  (Or whatever text made it into the current
draft charter text.)

> near enough about SS7 to know if that's true, but that was my

It's clear that's true for some portions of some scenarios.  It's also
clear that it's not true for other scenarios.

> think that one of the two claims above is untrue? Or do you just
> don't think it follows that we should be doing something about it?

The range of issues that should move us towards a simplified initial 
focus is rather richer than just answering those two questions.  They 
are useful, but not sufficient.

> On 6/28/2013 8:48 AM, Eric Rescorla wrote:>
>> Why is that true? A huge fraction of circuit switched devices are
>> now smartphones, which could absolutely make use of such a
>> mechanism. In fact, that's precisely the environment for which the
>> system in question was designed.

It is difficult to imagine that it would be wise to rely on smartphone 
adoption of anything new, such as an authentication method, in the 
critical path to anything near-term, or that focusing on smartphone 
usage initially would be the best point of leverage for a global forgery 
problem. Perhaps you know of some other global infrastructure security 
mechanism that has demonstrated a successful track record with such an 
approach?

I'm also concerned that the goal seems to keep moving for the 
out-of-band mechanism.  Its usage scenario seems to be different now 
than was cited in the original charter text, and the current one seems 
to have some impressive incremental overhead but with poor early-adopter 
benefits, thereby producing adoption disincentives.  All in all, my own 
view is that it's turned into a relatively messy topic, with unclear 
likely benefits.

In any event...

In terms of strategy for managing productive IETF work, things go better 
when there is clear, initial focus on a single, narrow topic.  Groups 
that try to juggle multiple topics simultaneously -- especially when 
they are essentially parallel mechanisms for the same problem -- tend to 
suffer the usual outcome of juggling too much, namely dropping /all/ the 
balls.

EAI is the most reason example I've seen of getting distracted and 
confused by trying to design gatewaying to a different environment, at 
the same time as working on the the clean, core solution.  They wound up 
with a dysfunctional hybrid that they were never able to clean up.

And the discussion here, so far, between in-band and out-of-band, looked 
singularly unsatisfying to me.

So the best thing for STIR is to start with the simplest, cleanest 
problem and produce the simplest, cleanest /useful/ design, as quickly 
as it reasonably can, and then proceed to add to it.  That way it can 
field the initial stuff, while it is working on the incremental 
capabilities.

For one thing, the smallest, narrowest, cleanest problem space is 
typically still quite challenging.  And we are clearly already seeing 
that for the pure SIP-SIP discussion, such as concerning the From field, 
choices among query mechanism, and key-vs-credential retrieval. So even 
the simplest task for this topic involves some serious working group effort.

If someone thinks that a pure SIP-SIP mechanism isn't useful, they 
should speak up.  If someone thinks that a pure SIP-SIP mechanism is not 
the base upon which everything else should be build, they should speak 
up about that.  Otherwise, it's difficult to see how that isn't the 
place to start.

d/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Jun 2013 22:28:55 +0000

> What I meant was, no matter what we do, we are sure to have some SBCs mangling whatever we need.  It's inevitable.  

I'll add to that with AFAIC, the bulk of deployed SBC are configured to remove anything they don't understand. They may support other configurations but practically speaking, they are often viewed as a security device and in that use case most operators seem to remove things they don't understand.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Jun 2013 22:28:55 +0000

inline 

> a) Only the origination can write the record.  This might possibly be fixable in some cases (SIP->SS7 GW is owned by a service provider who has the number delegated to it, even though it delegated…

I think we could figure out ways to allow an authorized intermediary to do this …

> b) It depends (for stopping robocalling, vishing and swatting) on being able to discover the credentials of the termination by the origination.  That requires a public database of TN to cert.
>  I think the PERCEIVED difficulties of doing that doom deployment in any interesting timeframe.  I think many national regulators and national carriers will refuse to allow it.

What would their primary concerns be? Just trying to get my head around all the issues. We might be thinking about different things being revealed at this level. I'm thinking that it would reveal that TN may or may not be assigned to a user but if it is, the public crypto key for that TN is X. 

>  I think many privacy advocates will object enough to slow deployment unacceptably.

Hmm - compared to the alternative of centralized global database that gets all the information about who is calling who I'm not sure I agree. Be interesting to figure out the privacy issues of both types of designs. 

> There is another idea I've had for the problem of PSTN.   First of all, note that if the SIP->SS7 GW checked identity in band, it fixes the problem.  It doesn't have to be the termination device or…

I'm worried about that this will reduce to a hop by hop trust solution with the trust level being the lowest common denominator which is more or less what we have today. I've often made the point that the person that wishes the caller ID did not work is often the paying customer for a given carrier.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Jun 2013 16:24:53 -0700

On 6/28/2013 8:48 AM, Cullen Jennings (fluffy) wrote:
> I think we need both the modes to happen at same time as the incremental deployment of one greatly improves the chance of any deployment of the second mode.

That's such a clear and forceful assertion, I'm motivated to ask for 
examples of times a similarly co-dependent deployment model has been 
successful for other global infrastructure efforts.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 28 Jun 2013 23:35:31 +0000

> I think we could figure out ways to allow an authorized intermediary to do this …
Do tell.  The point of the cert delegation model was that it followed number delegation.  Authorizing an intermediary that is a transit network would be pretty tough to do I think.  If the intermediary was in the delegation path, it would work.

> What would their primary concerns be? Just trying to get my head around all the issues. We might be thinking about different things being revealed at this level. I'm thinking that it would reveal t…
I think the problems aren't real, they are perceived.   Who owns what number, which numbers are active, tracking people by observing the database operations, walking the database to discover interesting patterns, and on and on.  The minute it's public, we get a whole different level of scrutiny by a lot of people who won't get the crypto details.  I worry a lot about regulators and national carriers, for example.

> Hmm - compared to the alternative of centralized global database that gets all the information about who is calling who I'm not sure I agree. Be interesting to figure out the privacy issues of both…
If you are referring to my alternate idea, it's per nation with a LoST like connection between national dbs.  It's only accessible to trusted entities.  Many of the entities who would be worried about a public DB would be less worried about a DB that they had significant control over.
> I'm worried about that this will reduce to a hop by hop trust solution with the trust level being the lowest common denominator which is more or less what we have today. I've often made the point t…
Sure, but the closer you get to the termination, the more they care.  All we need is ONE SP in the path that cares before the SS7 link.
Note that EKRs idea makes it worse - either the origination endpoint or origination SP has to write the record, no one else can.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 28 Jun 2013 19:45:50 -0400

We have a BoF approved, and we have chairs for the BoF.  We'll deal with consensus in the charter discussion at the BoF. 

Brian

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 28 Jun 2013 23:51:12 +0000

Cullen, please be a little less general 

Martin Dolly
AT&T 

Sent from my iPhone

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 28 Jun 2013 23:57:37 +0000

Agree with Dave 

Martin Dolly
AT&T 

Sent from my iPhone

On Jun 28, 2013, at 7:25 PM, "Dave Crocker" <[email-masked]> wrote:

> That's such a clear and forceful assertion, I'm motivated to ask for examples of times a similarly co-dependent deployment model has been successful for other global infrastructure efforts.
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Jun 2013 03:35:58 -0400

> I'll add to that with AFAIC, the bulk of deployed SBC are configured to remove anything they don't understand. They may support other configurations but practically speaking, they are often viewed…

I don't debate that from an Enterprise PBX's perspective that appears to be the case: new headers they add don't make it through a carrier to consumers/Enterprises elsewhere.  Sometimes this is due to the security policies on SBCs, sometimes due to behaviors of other B2BUAs in the carriers.

But afaik, for the inter-carrier peering SBCs it's not nearly as bad - those SBCs usually are only configured to remove specific headers; so if originating/terminating *carriers* are the ones to sign/verify, it won't be as hard to add an Identity header to be let through among them.  At least in the sense that carriers have far fewer inter-carrier peering points to have to do that with, than they do Enterprise trunks.  Especially if they have an incentive to let them through, and if they're benign.

For the other B2BUA devices, it appears to be usually harder than simple configuration.  My idealistic hope is that those vendors will someday soon learn to simply have a configurable means of letting named headers through, instead of having to wait for their next software release for each specific new header name.  But in their defense there aren't many headers they've been able to simply handle in an opaque manner, so there probably hasn't been much drive for such an ability.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Jun 2013 14:15:53 -0400

> To prove that A exists is not a proof that B cannot exist.

Let's assume there is a B.  Let's say that there exists an Edsel car company somewhere receiving these complaint forms with completely wrong numbers.  They can't make heads or tails of them.  How has Edsel been using these contact numbers for anything meaningful today, if they're nonsensical numbers?  I.e., in what way is Edsel using the contact number such that we can or need to provide a verification mechanism for them?  The problem that Edsel is having is different than our problem - we're not being asked to fix received caller-id's being unintelligible; we're being asked to provide a way for Dodge to know the E.164 contact number they got in the complaint form is really the contact number of the human who sent it.

> things, unless some discipline removes the possibility (application of

The assumption I'm making for the "discipline of the PSTN" is that the terminating domain can figure out what the source/dest E.164 phone numbers are for requests they  get, regardless of where they got them from.  If they don't, then STIR won't work for them, but that's not a problem for STIR to fix.  There are RFCs that tell them how to syntactically format their URIs, and they can choose to use those to solve that problem.  But we don't need those syntactic forms to be used end-to-end to get STIR to work.

> in the PSTN, that doesn't transfer to the Internet.

OK, let's ignore the way all SIP domain interconnect today.  Let's assume they behaved more like email, where essentially any domain can send SIP requests to any other domain, without foreknowledge of conventions.  For that model to work at all, all domains must agree on some common convention, or there has to be some protocol means for them to negotiate/learn one to use.  For example they could use TEL URLs for E.164 numbers.  STIR will function fine in that environment.  STIR will not function fine if they don't pick a common convention - but that's not a fault of STIR nor a problem STIR is being formed to address/fix - that would be a problem even if no one used STIR to begin with.

> does it get that information?

The data the function relies on are the E.164 phone numbers being used (plus some other data to prevent replay/cut+paste, but that other data can all be sent in the new header).

The receive side gets that "data" from the To/From, but again the "data" is E.164 numbers, not encoding strings.

> call, I am not buying it.

Since the existing interconnection model does deliver caller-id in an intelligible manner, and has for many years, it clearly hasn't broken the second it was assumed. Don't get me wrong - it's not how we'd like to do this stuff, clearly, but we need to focus on the problem at hand - not a different problem that might happen someday.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 18:50:15 +0000

The Google app store has several, if not dozens, of apps that query databases for incoming calls, for displaying related information and user-initiated blocking. To pick by download popularity, TrueCaller, Current Caller ID, My Number-Block, WhosCall, Call Control, etc. (I have no idea how well any of them work - I'm just copying names from the play.google.com web site...) These obviously don't address callerID spoofing, but they query databases for incoming calls.

There are distinct issues with out-of-band mechanisms, but I doubt that user bandwidth or app availability are first-order concerns.

________________________________
From: Eric Rescorla [[email-masked]]
Sent: Friday, June 28, 2013 1:28 PM
To: Richard Shockey
Cc: [email-masked]; Dave Crocker; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 30 Jun 2013 18:54:29 +0000

Confused, so what is the problem space? Where does Google use SIP?

Martin Dolly
AT&T 

Sent from my iPhone

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 19:05:51 +0000

The details depend on the solution, but the out-of-band solutions discussed all only assume that both end systems have Internet connectivity. For many users, unknown callers (i.e., those not in their address book or call log) are likely commercial entities that have both Internet connectivity and an interest to make sure their calls are answered and not spoofed.

This is not a comment on whether this should be a first-on-the-list or a rechartering item, just that I think the constraints are a bit different than stated.

Also, I think it would be useful to consider how the same basic approach could work for both "clear" (SIP) and obstructed (TDM) paths. If I understand him correctly, Brian has been trying to get attention for that model. All the basic information in the Identity-minus header (To/From/Date) seems to survive non-IP paths, so this doesn't seem completely infeasible. Thus, rather than seeing in-band and out-of-band as necessarily divergent technologies and infrastructures, it might be interesting to explore whether there is indeed some useful commonality.

The phone system itself has and continues to operate both in in-band and out-of-band mode and gradations in-between (MF as inband; ISDN as same-path, different channel; SS7 and SIP as out-of-band), using compatible constructs, so having multiple global interconnected infrastructures is not a new concept to telephony folks.

________________________________
From: PFAUTZ, PENN L [[email-masked]]
Sent: Friday, June 28, 2013 11:37 AM
To: Eric Rescorla; Richard Shockey
Cc: Wendt, Chris; Hadriel Kaplan; [email-masked]; Dave Crocker; Brian Rosen; Henning Schulzrinne
Subject: RE: [stir] Out-of-band vs. in-band

Eric:
Here’s the problem I see: The out of band solution assumes that there is something at the terminating end that is able to make use of the out of band mechanism. This is not going to be generally true until the circuit switched network is mostly retired; customers hanging off a circuit switch aren’t going to be protected.
Once we have end to end SIP we can do something in-band.
People might like to have a rapid solution but I just don’t see it happening without major refits to the legacy network. So, I’d prefer to concentrate on getting things right in the new world, even if that world isn’t coming as soon as any of us would like.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

Thanks,
-Ekr

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 19:10:12 +0000

I said nothing about Google and using SIP, just that today there are Android apps (not made by Google) that query an external database for every call and use community rating to provide additional call-related information or block the call as spam. This is essentially an out-of-band solution in the same general problem space. It obviously doesn't address caller ID spoofing (except for some lazy robocallers that spoof the same number repeatedly - they exist), but provides an existence proof that having an end system query a database per call is not a novel concept.

________________________________________
From: DOLLY, MARTIN C [[email-masked]]
Sent: Sunday, June 30, 2013 2:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; [email-masked]
Subject: Re: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 19:23:29 +0000

+1

Just in case this isn't plain to everyone: Today, the display of the text caller ID (212 555 1000 translates to "Joe's Pizza") is resolved at the receiving end, often by entities (CNAM databases) that have nothing to do with either the calling or called carrier. This clearly works well enough, at least for entities that don't want it to break. In our case, the good guys we can validate have every interest in making it work. It also works well enough for call centers that routinely use that number to look up your account record.

Thus, unless somebody has specific evidence to the contrary in inter-carrier cases, maybe we can put this topic to rest. (We all seem to agree that lots of odd numbering things happen within corporate or closed networks, but they are not our problem.)

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Friday, June 28, 2013 12:59 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] URI formats (was RE:  Do we agree on the basics?)

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 30 Jun 2013 19:54:59 +0000

Understood what you said, you have not proven "existence proof", as when I make a call on my mobile it does not interact with any other  app, so how does the "magic" happen for real, not "what if" land.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]
Subject: RE: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" <[email-masked]> wrote:

> This is not going to be generally true until the circuit switched network is mostly retired; customers hanging off a circuit switch aren't going to be protected.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 20:02:20 +0000

I'm not quite following you. I haven't tried all (or most) of these apps, but the ones I have seen get notified on inbound calls, fetch the number-related information and then reject the call if found on the black list. This works on Android; it may not work on IOS. Apparently, you may get one spurious ring in some cases. These are real apps, not "what if". One of them claims 18 million users.

Maybe you can explain your concern in a bit more detail, as I'm obviously not catching on.

Sent: Sunday, June 30, 2013 3:54 PM

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]
Subject: RE: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 30 Jun 2013 20:09:11 +0000

To hopefully be clearer, I do NOT invoke any app when I make or receive a call...

I hope you are not saying that the IETF  is creating a solution that requires me to invoke an app when I just want to make a Plain Old Phone call (POTS), independent on whether my device is IP capable.

I have an iPhone 5 and turn off all notifications and privilege for location information, unless I need it.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]
Subject: RE: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 20:16:12 +0000

The app invokes itself; as far as I can tell, the user phone behavior doesn't really change, i.e., you use the same phone interface as before and the blocking app runs in the background.

I think we all agree that a solution that does not require users to install apps (and that works for feature phones and landlines) is preferable. However, if a carrier infrastructure solution is not forthcoming, I wouldn't blame users if they chose the second best alternative, even if it involves installing apps. I'm encouraged by the extensive carrier participation in STIR, so you may well get your wish (and may be in a position to help) of not having to deal with apps.

Sent: Sunday, June 30, 2013 4:09 PM

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]
Subject: RE: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Jun 2013 13:17:23 -0700

> To hopefully be clearer, I do NOT invoke any app when I make or receive a

On a smartphone, the dialer generally is an app. For instance:

https://wiki.mozilla.org/Gaia/Dialer

-Ekr

I hope you are not saying that the IETF  is creating a solution that
> requires me to invoke an app when I just want to make a Plain Old Phone
> call (POTS), independent on whether my device is IP capable.
>
> I'm not quite following you. I haven't tried all (or most) of these apps,
> but the ones I have seen get notified on inbound calls, fetch the
> number-related information and then reject the call if found on the black
> list. This works on Android; it may not work on IOS. Apparently, you may
> get one spurious ring in some cases. These are real apps, not "what if".
> One of them claims 18 million users.
>
> Understood what you said, you have not proven "existence proof", as when I
> make a call on my mobile it does not interact with any other  app, so how
> does the "magic" happen for real, not "what if" land.
>
> I said nothing about Google and using SIP, just that today there are
> Android apps (not made by Google) that query an external database for every
> call and use community rating to provide additional call-related
> information or block the call as spam. This is essentially an out-of-band
> solution in the same general problem space. It obviously doesn't address
> caller ID spoofing (except for some lazy robocallers that spoof the same
> number repeatedly - they exist), but provides an existence proof that
> having an end system query a database per call is not a novel concept.
>
> > The Google app store has several, if not dozens, of apps that query
> databases for incoming calls, for displaying related information and
> user-initiated blocking. To pick by download popularity, TrueCaller,
> Current Caller ID, My Number-Block, WhosCall, Call Control, etc. (I have no
> idea how well any of them work - I'm just copying names from the
> play.google.com web site...) These obviously don't address callerID
> spoofing, but they query databases for incoming calls.
> >
> > There are distinct issues with out-of-band mechanisms, but I doubt that
> user bandwidth or app availability are first-order concerns.
> >
> network is mostly retired; customers hanging off a circuit switch aren't
> going to be protected.
> >
> > [RS> ]  Frankly I would doubt that.  I would imagine the mobile
> retrofits of the legacy networks, certainly not in North America.
> >
> >

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 30 Jun 2013 20:18:24 +0000

I really do not want apps that invoke themselves...it is a little thing called security/privacy.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]
Subject: RE: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 30 Jun 2013 20:20:44 +0000

Eric,

My mother picks up her phone and she dials a number...no app, even though she has a smart phone. This is the user we have to protect... do you agree?

Thank you,

Martin

From: Eric Rescorla [mailto:[email-masked]]
Sent: Sunday, June 30, 2013 4:17 PM
To: DOLLY, MARTIN C
Cc: Henning Schulzrinne; Richard Shockey; [email-masked]
Subject: Re: [stir] Out-of-band vs. in-band

On Sun, Jun 30, 2013 at 1:09 PM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:
To hopefully be clearer, I do NOT invoke any app when I make or receive a call...

-Ekr

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 30, 2013 4:02 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] Out-of-band vs. in-band

________________________________________
From: DOLLY, MARTIN C [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 30, 2013 3:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] Out-of-band vs. in-band

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 30, 2013 3:10 PM
To: DOLLY, MARTIN C
Cc: Eric Rescorla; Richard Shockey; [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] Out-of-band vs. in-band

________________________________________
From: DOLLY, MARTIN C [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, June 30, 2013 2:54 PM
To: Henning Schulzrinne
Cc: Eric Rescorla; Richard Shockey; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Out-of-band vs. in-band

Martin Dolly
AT&T

Sent from my iPhone

On Jun 30, 2013, at 2:51 PM, "Henning Schulzrinne" <[email-masked]<mailto:[email-masked]>> wrote:

> The Google app store has several, if not dozens, of apps that query databases for incoming calls, for displaying related information and user-initiated blocking. To pick by download popularity, TrueCaller, Current Caller ID, My Number-Block, WhosCall, Call Control, etc. (I have no idea how well any of them work - I'm just copying names from the play.google.com<http://play.google.com> web site...) These obviously don't address callerID spoofing, but they query databases for incoming calls.
>
> From: Eric Rescorla [[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; Dave Crocker; Henning Schulzrinne
> On Fri, Jun 28, 2013 at 10:22 AM, Richard Shockey <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jun 2013 13:27:27 -0700

> https://wiki.mozilla.org/Gaia/Dialer

The lookups done by that dialer are to a /local/ contacts list, not an 
external one.

d/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Jun 2013 13:32:06 -0700

On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C <[email-masked]> wrote:

>  Eric,****
>
> ** **
>
> My mother picks up her phone and she dials a number…no app, even though
> she has a smart phone. This is the user we have to protect… do you agree?
>

I'm not sure you and I have the same definition of "app". On a smartphone,
the dialer
is often (always?) a program that runs on the phone and that has access to
the
mobile dialer functionality. That's an app. Now, apps come in a number of
flavors,
depending on whether:

- They are shipped with the phone or installed by the user.
- What level of privileges they have.

But I think Henning's point is that there is nothing particularly difficult
about
the smartphone manufacturer adding this sort of functionality to the builtin
dialer app. It's not an architectural change to the phone, just a new
feature
to a program. Is that something you disagree with?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Jun 2013 13:35:05 -0700

On Sun, Jun 30, 2013 at 1:27 PM, Dave Crocker <[email-masked]> wrote:

>> https://wiki.mozilla.org/Gaia/**Dialer<https://wiki.mozilla.org/Gaia/Dialer>
>>
>
>

That's a pretty fuzzy distinction in the face of things like sync.

Moreover, I'm not sure I see the relevance. Henning observed that you could
get third party applications that do a db lookup with each call and so there
was no in principle reason why the builtin phone application couldn't do
the same thing. Obviously, the vendors would have to be induced to do so,
but as far as I know there is no technical reason why that would be
difficult
for them to do, provided that such a service existed.

-Ekr

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2013 20:39:19 +0000

Let's see if we can agree on the observable facts as of today:

* Standard smartphone dialers are apps.

* There are event-driven apps that listen to incoming call events in the background. They are used for a variety of purposes, including safe driving (Sprint provides one like that; it auto-answers calls and texts when the phone is in motion) and robocall prevention. I use one that provides a browser pop-up on incoming calls (useful when I've muted my smartphone during a lecture or meeting).

* Some of these apps contact external databases for blacklisting and additional-information (caller reputation) purposes.

* The basic network interaction model of these current apps would probably be pretty similar to the out-of-band validation apps discussed.

* There are legitimate privacy concerns about who has access to call data. A significant fraction of users would find that sufficiently disconcerting to prevent them from installing such apps.

* Regardless, millions of people have installed them since they apparently find them better than the unfettered-robocalling alternative.

Any disagreement on the above?

Henning

________________________________________
From: Dave Crocker [[email-masked]]
Sent: Sunday, June 30, 2013 4:27 PM
To: Eric Rescorla
Cc: [email-masked]; Richard Shockey; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

d/

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 30 Jun 2013 21:36:03 +0000

Yes, you assume too much

Martin Dolly
AT&T 

Sent from my iPhone

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Jun 2013 14:43:03 -0700

It would be helpful if you could provide more detail
about what you disagree with here.

-Ekr

On Sun, Jun 30, 2013 at 2:36 PM, DOLLY, MARTIN C <[email-masked]> wrote:

> > * There are event-driven apps that listen to incoming call events in the
> background. They are used for a variety of purposes, including safe driving
> (Sprint provides one like that; it auto-answers calls and texts when the
> phone is in motion) and robocall prevention. I use one that provides a
> browser pop-up on incoming calls (useful when I've muted my smartphone
> during a lecture or meeting).
> >
> > * Some of these apps contact external databases for blacklisting and
> additional-information (caller reputation) purposes.
> >
> > * The basic network interaction model of these current apps would
> probably be pretty similar to the out-of-band validation apps discussed.
> >
> > * There are legitimate privacy concerns about who has access to call
> data. A significant fraction of users would find that sufficiently
> disconcerting to prevent them from installing such apps.
> >
> > * Regardless, millions of people have installed them since they
> apparently find them better than the unfettered-robocalling alternative.
> >