Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00

From: Michael Hammer <[email-masked]>
Date: Sat, 1 Feb 2014 17:51:13 +0000

We seem to have this confusion repeated from time to time.

Local prefixes that tell the switch whether the entered digits are local,
national, or international number are not part of the E.164 number.
A proper switch knows not to include such prefixes as part of the E.164
number.
This is a case of "if it hurts to do something confusing, then stop doing it
that way."

Also, the domain part after the @ sign is not part of the E.164 number, and
so should not be confused with any operation that STIR might make.

So, I guess bottom line, am agreeing with Brian that we need to have
explicit guidance for STIR about all the rules about processing numbers,
again.

Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408-202-9291
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, January 31, 2014 4:21 PM
To: Anton Baskov
Cc: [email-masked] List
Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00

This is a good point.

We probably have to say that if the rules we agree to do not result in a a
proper e.164, and the call is sent beyond the local domain, that the From
must be changed to be able to be canonicalized by the rules.

Brian

On Jan 30, 2014, at 5:49 AM, Anton Baskov <[email-masked]> wrote:

> Some notes about phone number canonization described in Cullen's STIR
Signaling presentation and section "7.  Identity and Telephone Numbers" of
draft-jennings-stir-rfc4474bis:
> 
> There is a problem with telephone number canonization that in some cases
we can't assume right number judging on sip uri, because some countries uses
international access codes different that recommended by ITU. For example,
at Russia dial out code is "8" for long distance calls and "8 - 10" for
international calls, and most local operators use such number representation
in their voip systems, so looking at "sip:8495..." number we can't suppose
is that call from Moscow (+7495...) or it's from Vietnam (+84...). Also I
saw two voip operators that use internal account number as right side of
client sip uri - it's make a possibility to make false phone number
assumption by clients. In this case I think that we should have at least
information header with full tel: uri or limit canonization procedure only
to "sip:+..@domain"-like uri.
> 
> 
> -- 
> Anton Baskov <[email-masked]>
> +7 (911) 254-77-92, +7 (916) 716-89-46
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

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

---

From: Anton Baskov <[email-masked]>
Date: Mon, 10 Feb 2014 10:15:04 +0200

I think that by default canonization should be possible only if we have any additional informational header with tel: uri to allow canonization. But, if this header is accidentally missed, we can still guess full E.164 number and if will match STIR signature we can be sure that all is ok, but if phone number we guessed don’t match signature we don’t know – is it a problem with signature or we just guessed wrong number.

By the way, additional field can be helpful if we would like to have signed call from local numbers, like tel:112 (911) and other numbers that can’t be routed globally.

On Sat, 1 Feb 2014 17:51:13 +0000

---

From: Brian Rosen <[email-masked]>
Date: Mon, 10 Feb 2014 09:23:36 -0500

I think we’re proposing to describe an algorithm in our document that turns the From/PAI into a canonical e.164.  We need some rules for what happens when the algorithm fails.  The origination side can test this and determine if it needs to do anything.  So, it’s not a “guess”.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 10:05:37 -0500

> By the way, additional field can be helpful if we would like to have signed call from local numbers, like tel:112 (911) and other numbers that can’t be routed globally.

Note: tel:112 and tel:911 are invalid syntax for a tel uri.

112 isn't an E.164. To be syntactically valid it requires a parameter. 
E.g., tel:112;phone-context=+44, tel:911;phone-context=+1

But is there really a case where we need to sign these? We are talking 
about signing From, not To. I don't expect to get a call with one of 
these as From.

	Thanks,
	Paul

---

From: Michael Hammer <[email-masked]>
Date: Mon, 10 Feb 2014 15:09:22 +0000

I think that this is opening Pandora's box.  They are essentially service codes that are localized.
There could be literally thousands of termination points that those codes go to.
Not sure it helps to have calls coming from those numbers, signed or not.

We should stick to the current scope of worrying about E.164 telephone numbers.

Michael Hammer
Principal Engineer

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, February 10, 2014 10:06 AM
To: [email-masked]
Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00

But is there really a case where we need to sign these? We are talking about signing From, not To. I don't expect to get a call with one of these as From.

	Thanks,
	Paul

---

From: Alex Bobotek <[email-masked]>
Date: Mon, 10 Feb 2014 10:16:29 -0800

+1

With the assumption that local numbering needs to be supported (an assumption which I support), there are two non-exclusive enforcement choices:

* provide an endpoint (or its proxy) with sufficient information with which to enforce policy -- specifically:
        - its own context and
        - the context of the caller
        - context(s) authorized for the caller

* rely on networks to block unauthorized calling contexts (e.g., local numbering schemes) from reaching a called endpoint

Currently the latter is in place; it's reasonable to assume that it will remain so.

----

Another comment in reaction to a cert issued by a 3rd party non-telephony-SP:

I don't believe a secure calling environment interoperable with the PSTN can be established without a mechanism in which an originating service provider takes responsibility for (i.e., signs) an originating call.  Is this a topic for discussion or generally agreed?

Regards,

Alex

> From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
> Sent: Monday, February 10, 2014 7:09 AM
> To: [email-masked]; [email-masked]
> [email-masked]<mailto:[email-masked]>
> Mobile: +1 408-202-9291
> To: [email-masked]<mailto:[email-masked]>
> > I think that by default canonization should be possible only if we have any
> additional informational header with tel: uri to allow canonization. But, if this
> header is accidentally missed, we can still guess full E.164 number and if will
> match STIR signature we can be sure that all is ok, but if phone number we
> guessed don’t match signature we don’t know – is it a problem with
> signature or we just guessed wrong number.
> >
> > By the way, additional field can be helpful if we would like to have signed
> call from local numbers, like tel:112 (911) and other numbers that can’t be
> routed globally.
>
> But is there really a case where we need to sign these? We are talking about
> signing From, not To. I don't expect to get a call with one of these as From.
>
>       Thanks,
>       Paul
>
>
>
> [email-masked]<mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Feb 2014 10:45:11 -0500

We’re signing From and To, so we have the problem.

You can get a “call back” from an emergency call.  In most cases, today, that is a call that is placed on the PSTN from a local PSAP or responder, but we have some work in ecrit on a standardized marking for call-backs.  

While +1911 is not an e.164, it’s certainly unambiguous, simple to canonicalize, and straightforward to deal with as a To.  For a From, it would be a little harder, because multiple entities would need valid credentials, but it’s certainly feasible to give them such.

Brian

---

From: Michael Hammer <[email-masked]>
Date: Tue, 11 Feb 2014 15:55:16 +0000

How many PSAPS are their across the U.S.?

And how good have they been about conforming to a standard for operations?

That herd of cats might be a bridge too far.

But, I won't object if you can specify the logistics for that.

Michael Hammer

Principal Engineer

 <mailto:[email-masked]> [email-masked]

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2014 10:45 AM
To: Alex Bobotek
Cc: Michael Hammer; Paul Kyzivat; [email-masked]
Subject: Re: [stir] Comment on draft-jennings-stir-rfc4474bis-00

We're signing From and To, so we have the problem.

You can get a "call back" from an emergency call.  In most cases, today,
that is a call that is placed on the PSTN from a local PSAP or responder,
but we have some work in ecrit on a standardized marking for call-backs.  

While +1911 is not an e.164, it's certainly unambiguous, simple to
canonicalize, and straightforward to deal with as a To.  For a From, it
would be a little harder, because multiple entities would need valid
credentials, but it's certainly feasible to give them such.

Brian

+1

With the assumption that local numbering needs to be supported (an
assumption which I support), there are two non-exclusive enforcement
choices:

* provide an endpoint (or its proxy) with sufficient information with which
to enforce policy -- specifically:

        - its own context and

* rely on networks to block unauthorized calling contexts (e.g., local
numbering schemes) from reaching a called endpoint

Currently the latter is in place; it's reasonable to assume that it will
remain so.  

----

Another comment in reaction to a cert issued by a 3rd party
non-telephony-SP:

I don't believe a secure calling environment interoperable with the PSTN can
be established without a mechanism in which an originating service provider
takes responsibility for (i.e., signs) an originating call.  Is this a topic
for discussion or generally agreed?

Regards,

Alex

> I think that this is opening Pandora's box.  They are essentially service
codes

> that are localized.

> There could be literally thousands of termination points that those codes
go

> to.

> We should stick to the current scope of worrying about E.164 telephone

> numbers.

> guessed don't match signature we don't know - is it a problem with

> call from local numbers, like tel:112 (911) and other numbers that can't
be

> But is there really a case where we need to sign these? We are talking
about

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Feb 2014 11:00:41 -0500

Over 6000.

They had sloppy standards conformance before this, but we’re testing conformance with the Next Generation 9-1-1 standards and getting pretty good results.  Good enough that it’s helping IETF efforts like siprec.

I think it can be done.

There is a PKI that I believe will get set up for credentials.  Since stir needs the ability to delegate “authorized spoofing” for call centers and doctors, we already have the problem of multiple credentials for the same number.  I think it’s possible to have lots of such credentials if the database is organized reasonably.  An organization like, say, American Express may have dozens or even hundreds of outlets making calls on their behalf, but a single advertised number.  We need to be able to handle that.

Brian

On Feb 11, 2014, at 10:55 AM, Michael Hammer <[email-masked]> wrote:

> But, I won’t object if you can specify the logistics for that.
>  
> Michael Hammer
> Principal Engineer

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Feb 2014 11:01:45 -0500

Nope, we think that by canonicalizing the numbers, it works.  The SBCs munge the representation, but don’t actually change the number.

Brian

---

From: Anton Baskov <[email-masked]>
Date: Thu, 20 Feb 2014 11:26:13 +0200

On Mon, 10 Feb 2014 09:23:36 -0500

> I think we’re proposing to describe an algorithm in our document that turns the From/PAI into a canonical e.164.  We need some rules for what happens when the algorithm fails.  The origination side…

Agree. In case we have an e.164 number based on our algorithm and address from From/PAI without any additional informational header we should check “sip uri + tel uri + signature” set and, if it fails, “sip uri + signature” set, because sip address can only looks similar to tel uri for our algorithm.

---

From: Anton Baskov <[email-masked]>
Date: Thu, 20 Feb 2014 12:37:37 +0200

Paul, thank you, I missed it. 
It’s unlikely scenario, but here, gas service “04” can call you to schedule regular inspection of gas equipment in your home. So, we can decide, should calls from local number covered by STIR or not. I think that we can leave it out of scope.

On Mon, 10 Feb 2014 10:05:37 -0500