Subject: [Sipping] RE: calling number blocking at sip/isup gateway

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 29 Jan 2002 15:56:07 -0500

[Moved to SIPPING]
This one raises a couple of issues.  Let's assume your gateway gets an
authenticated subscriber ID.  That takes care of billing requirements, one
way or another.  I'm a little concerned for the well-being of your
subscribers, though: it seems to me anyone on the net could get free
connections to the PSTN at their expense.  More to the point from a
regulatory point of view, it doesn't look like malicious call trace or
similar features would work in this scenario.  The best they could do is
trace the call back to your subscriber and hope the subscriber can provide
them further leads.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 11:57 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] calling number blocking at sip/isup gateway

On Tuesday 29 January 2002 07:27 am, [email-masked] wrote:
> However, because of other security concerns, a real IP telephone
> service provider would require that it knows the identity of the
> calling party and the model for this service must be based on a
> presumption that the calling party can trust the service provider.
> Therefore, in this case, the From must contain a correct number, and
> the gateway may remove it (after verifying it).
>
> The case of the calling party leaving out the From can not be used in
> a "tariffed" (if I can use that term) telephone service. While the
> SIP protocol may allow it to be left out, the service provider may
> require it before allowing call setup.

I run a real IP telephone service. Unknown parties may place calls over 
the Internet to my subscribers. My subscribers's profiles may result in 
forwarding those calls to a PSTN gateway. PSTN charges originating from 
this operation are charged back to the subscriber (the called party), 
not the calling party with whom I have no relationship outside the SIP 
used to set up the call.

It really doesn't matter what the calling party put in their From: 
field, I still need to complete the call. Now, if they were kind enough 
to put in a phone number, I can map that into the IAM. But if they 
didn't, I just can't. Now, there's an interesting question on 
"authenticating" the phone number that they might have included., but 
that's a different problem.

Even more interesting, I'm going to include any referenceable number 
from the INVITE in the IAM, regardless of any privacy indicator 
suggested by the SIP signaling, because that referencable number would 
have been included in the SIP signal delivered to my subscriber anyhow 
(The caller DID send it to him), and my job as a gateway oeprator is to 
get as much of the SIP experience as possible into the call being 
forwarded to the PSTN.

So, here we have a real phone service which conflicts with the 
behavioral requirements suggested by mpierce's  post, as well as a 
whole can of privacy and transitive trust worms.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 17:00:51 -0600

On Tuesday 29 January 2002 02:56 pm, Tom-PT Taylor wrote:
> [Moved to SIPPING]
> This one raises a couple of issues.  Let's assume your gateway gets
> an authenticated subscriber ID.  That takes care of billing
> requirements, one way or another.  I'm a little concerned for the
> well-being of your subscribers, though: it seems to me anyone on the
> net could get free connections to the PSTN at their expense.  More to
> the point from a regulatory point of view, it doesn't look like
> malicious call trace or similar features would work in this scenario.
>  The best they could do is trace the call back to your subscriber and
> hope the subscriber can provide them further leads.

Well, it allows anyone on the net to call the subscriber at the 
subscriber's expense. Same concept as call-forwarding on the PSTN today.

The only proposal I've seen to provide the tracing support is to 
REQUIRE every SIP node to get a PSTN number, and RPID that into every 
call setup. Then to make this work, we need a PKI associating 
credentials for the PSTN number, so that one can't falsely attribute 
one's RPID. This also seems a little unworkable. I suppose one could do 
it without an PSTN number by mapping a "PSTN distinguised name" to a 
local number, but one still has the PKI problem.

--
dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 30 Jan 2002 09:36:05 +0200

Dean Willis writes:

 > Then to make this work, we need a PKI associating 
 > one's RPID.

why is that?  if i allocate a user a phone number, we use digest
authentication of the invite, and there is secure transport, such as
hip, between the ua and the proxy, then i don't see any need for pki
anywhere.  the proxy, of course, checks that the from number is among
the ones that i have allocated for that user.

-- juha