[SIPForum-techwg] Question re Application Server

[Chris Sibley]

Hi Paul,

Comments in-line..

Thanks,

--Chris

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Monday, September 11, 2006 4:14 PM
> To: Chris Sibley
> Cc: Hadriel Kaplan; SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Question re Application Server
> 
> 
> 
> Chris Sibley wrote:
> 
> >> Chris, I think this highlights a real problem regarding callerid
> >> processing. What algorithm *should* the PBX use to decide what to
> >> display as the calling identity?
> >>
> >> As things stand, it must base this on From. But is the From value to
> >> be trusted?
> >>
> >
> > Not any more or less so than the caller-ID information delivered from
> > the PSTN (over a TDM connection) today...
> 
> >> I guess if the PBX has a contract with the SP, then the contract could
> >> state that the SP warrants that the From value is valid, and then the
> >> PBX could trust it for purpose of generating a callerid display. That
> >> would work for the gateway case that is covered.
> >>
> >
> > Since the SP can't 100% verify the CID information received from the
> > PSTN then I don't think that it could warrant to an enterprise that the
> > contents of the 'From:' field will be valid in any case.
> 
> I think that is not so clear.
> 
> Please correct me if I am wrong, but I think the SPs have a contractual
> transitive trust relationship with one another. And they have a way to
> indicate that a number they are reporting is not trusted. When
> connecting a PBX, I think the SP is obligated to either:
> - have a contractual transitive trust relation with the PBX operator
> - check that the number reported by the PBX is one it is authorized
>    to use
> - mark the number provided by the PBX as untrusted.
> 
> If the above is true, then either the received number is marked
> untrusted, or else it is trusted based on a chain of transitive trust
> backed up with legally enforceable contracts.
> 
> That is stronger than taking a SIP From header on blind faith.
>

I am going to have to dig out my trusty SS7 protocol book and double-check
things, but I do not believe this to be the case at all. Take a look at the
following news article:

http://www.usatoday.com/tech/news/2006-03-01-caller-id_x.htm

Apparently, spoofing caller ID on the PSTN today is "legal" and some
companies are even making a business out of it.

Please note that I am NOT endorsing this practice; I'm just pointing out
that this is the reality of the PSTN today. 
 
> (I should check my Vonage subscriber agreement to see if I am legally
> prevented from causing my UA to lie about its identity.)
> 

That would be interesting...

> It would be interesting to see some lawsuits over forged caller id.
> 
> >> But then what about the inter-enterprise case where the SP is acting
> > as
> >> a proxy? Does the SP warrant the From value in that case? It *could*,
> > to
> >> some extent, by rejecting any incoming calls from a PBX where the From
> >> domain is not consistent with the authentication of the source PBX. I
> >> guess that is out of scope of this document, and could be added later
> > as
> >> a compatible upgrade. But is it consistent with the expectations of
> > the
> >> authors?
> >>
> >
> > Well, I guess the SP could verify that the domain in the 'From:' field
> > is valid for the originating enterprise but this would still not prevent
> > the enterprise from asserting an E.164 address in the user portion of
> > the URI that didn't belong to it (on the PSTN).
> 
> Technically there is nothing wrong with this because the user part of a
> URI is only interpreted within the scope of the domain name. So
> 
> - sip:+19785551234 at atlanta.com;user=phone
> - sip:+19785551234 at biloxi.com;user=phone
> 
> are both valid URIs belonging to their respective domains. However only
> one of them is equivalent to:
> 
> - tel:+19785551234
> 
> and there is no way to tell which by inspection. This is why it is
> dangerous in general to take a sip uri and display only the numeric
> portion. Doing so assumes it is equivalent to the tel form.
> 

It is true that it is impossible to determine which of the above two URIs is
equivalent to the tel: URI. However, until we have a globally available
mechanism (e.g. ENUM) to associate an E.164 address with a specific domain
then I don't see how to solve that problem. 

I suppose we could say that the PBX shouldn't display the contents of the
'From:' field as CID if the domain is not the SP's domain (i.e. not display
CID for enterprise<->enterprise calls). That seems a bit strong, however,
particularly for a SP with a lot of customers.

> IMO the preferred approach is to only use the P-Asserted-ID header as
> the source for callerid info, and to use tel in that when a phone number
> is to be displayed. Or at worst, use the number from a sip uri in P-A-ID
> only when the the contractual arrangement says it is ok to do that.
> 

Hmm, well that changes the spec a bit in that now the enterprise would be
required to be part of the SP's trust domain. Also, per my earlier comments,
I would be reticent (as a SP) to assert an identity to the enterprise that I
can't 100% verify.

> > I think this would also be the case even if the identity headers are
> > used. When identity is used, I believe that the responsibility for
> > inserting the 'Identity:' and 'Indentity-Info:' headers would be on the
> > originating enterprise's proxy server, not the SP's.
> 
> It doesn't matter who inserts the identity header. It is the cert
> authority for the identity that matters.
> 
> But yes, unless some special kind of cert is defined for this, you could
> get an identity cert for both the atlanta.com and biloxy.com URIs with
> the same number in them. Jon Peterson has avoided having SIP Identity
> treat tel URIs, because it is hard. So we won't find a solution there.
> 
> So if this is to be solved at all (in order to give *any* validity to
> sip callerid of phone numbers), then I think it must for now be a
> transitive trust solution, probably with the SP with the responsibility
> for either preventing improper usage of numbers, or else refusing to
> assert identity for them.
>

I agree that the only way to really "solve" the problem would be via a
transitive trust solution. Unfortunately, I believe that the reality is that
this isn't the case on the PSTN (for CID, anyway) today so the SP can't make
any contractual guarantee that the CID information will be correct.

I'm OK with the SP verifying the contents of the 'From:' field for
enterprise<->enterprise calls since that *should* be doable. However, I
don't think we can honestly make the same statement about PSTN-originated
calls.

> >> A related issue is if the UAS is only capable of displaying callerid
> > as
> >> a number, rather than as a URI. Is it expected to extract the number
> >> from the From URI whenenver that looks like a number, and/or has
> >> user=phone, *regardless* of the domain of the URI? In general you are
> >> not supposed to "interpret" the user part unless it is your own
> > domain,
> >> even if it has user=phone. I think that can be stretched to allow
> >> interpreting the user part when one has specific knowledge of the
> >> conventions used by the domain, which could be assumed when it is the
> > SP
> >> domain. But I don't think it can be stretched to allow interpretation
> > of
> >> random other domains, unless part of SIPConnect is a requirement that
> >> all players have this convention.
> >>
> >
> > Since this is just a profile of SIP, I don't think it is unreasonable to
> > say that all players must be using the conventions as defined. That
> > said, the PBX needs some way of determining when to apply the
> > rules/conventions associated with the profile. Perhaps we should add
> > some guidelines around checking the 'Via:' header to make sure the
> > request came from the SP's proxy vs. some other proxy (that doesn't
> > implement the profile.)
> 
> The solution I prefer is to base it on P-Asserted-ID. The SP should not
> assert an identity unless it can verify that it is valid. Unfortunately,
> you guys have chosen to preempt P-A-ID for a different purpose.
> 
> My alternative is for the SP to verify the From, and reject requests
> where it cannot be verified. However that has a serious downside - I
> think it means that all calls from the PSTN must be rejected if the
> caller's identity cannot be verified.
> 

I like the alternative, but rejecting all calls from the PSTN kind of makes
the spec a "lame duck". :)

> >> I know there is currently no general concensus on exactly how callerid
> >> should be handled. But I find it very suspect to ever trust using From
> >> for this unless it is supported by SIP Identity. It would be better if
> >>  From was always a TEL URI when it is a phone number, and the SP
> > refused
> >> requests when the From wasn't a phone number assigned to the source.
> > It
> >> would also be better if P-Asserted-ID was passed to the target PBX,
> > and
> >> was considered the only trustworthy source of caller identity.
> >>
> >
> > I'm not sure that using a tel: URI in the 'From:' field is a good idea
> > if we want to start using the identity headers in the future.
> 
> Well, there is that.
> 
> Better I guess to rely on P-Asserted-ID, which can be used in
> conjunction with SIP Identity. Using a TEL in a P-A-ID isn't a problem.
> Using a sip with a clear understanding that the number in it will be
> valid is also not too much of a problem.
> 

Would using a SIP URI in the 'From:' field, with the clear understanding
that a number will be in it, along with a check of the 'Via:' header (to
verify the call came from the SP's proxy) be sufficient?

> 	Paul
> 
> > <snip from RFC 4474>
> >
> > .
> > Implementations that intend to send their requests through an
> > authentication service SHOULD put telephone numbers in the From header
> > field into SIP or SIPS URIs whenever possible.
> > .
> >
> > </snip>
> >
> >> 	Paul
> >
> >
> > **********************************************************************
> > This email may contain confidential information. If you are not
> > the intended recipient, please advise by return email and delete
> > immediately without reading or forwarding to others.
> >  -- Cbeyond
> > **********************************************************************
> >