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

From: "Mark Watson"<[email-masked]>
Date: Mon, 18 Feb 2002 20:23:05 -0000

Dean,

Your example below needs only a small extension to illustrate Mike's point
and show why something like Remote-Party-ID as defined in the privacy draft
is needed, and how it works despite the lack of a signature.

Suppose I too run an IP telephony service and want to offer my subscribers
the ability to call to the PSTN. I don't have a PSTN gateway of my own, so I
make an agreement with you to allow my subscribers to use your gateway.

You will need some way of authorising calls from my subscribers to be sure
that you'll get revenue for the call. Let's assume you have some way of
authenticating messages from my outgoing proxy, which all my subscribers use
- you can't authenticate my subscribers directly as you don't know who they
are.

You will bill me for calls made by my subscribers, but you will need some
kind of identity or token to tell me which subscriber it was, so that I can
bill them.

If the user has a PSTN number it would be desireable to to send it out to
the PSTN (this would make the regulators happy from a Malicious Call
perspective), but only if you can be sure it is valid for that user.

Some PSTN networks support a second, user-chosen, CLI. For example Call
Centers might provide their Freephone number. If the user wants such an
identity, it would be good to know that too.

This information could be carried in a Remote-Party-ID - there is no need to
sign it because you are already sure that the message came from me, and we
have a written agreement which can specify that the Remote-Party-ID values
will be accurate for the subscriber who is calling - my proxy makes sure of
that because it does authenticate the actual caller, and knows their PSTN
number(s).

Because I have to live up to my agreement with you, I ensure that my
outgoing proxy does not route such messages via other entities which could
modify them - I send them straight to you or via other Service Providers
with whom I have similar agreements.

Personally, I have trouble understanding how any system for a PSTN break-out
service such as this could operate without such written agreements.

If we pass this information between us, we do need to carry an indication of
the subscribers privacy preference with respect to that.

Regards...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]

<snip>
> 
> 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
>

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Feb 2002 17:11:37 -0600

> is needed, and how it works despite the lack of a signature.

Yep. And what happens when my misconfigured proxy forwards the call without
paying attention to the Privacy header, because for some reason it's
forwarding to the outside world instead of a PSTN gateway under my control?
We get a privacy leak.

But other than that, I'd say you've precisely described a "sunny day" use
case for RPID.

It still has a lot of security issues based on transitive trust, which make
it a lot more palatable in a two-party case than in three or more party
transitivity.

I believe we're approaching a general consensus that the Privacy draft
provides a reasonable approach to solving a specific class of problem
wherein interoperator-transitive trust is couple to transport-layer message
protection. That's not a general privacy mechanism, but it does seem to have
enough constituency to justify publication as long as it has a REALLY
serious applicability statement explaining the particular requirements and
environments for which it is useful.

How does that sound?

--
Dean

_______________________________________________
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: Matt Holdrege <[email-masked]>
Date: Tue, 19 Feb 2002 02:52:07 -0800

>environments for which it is useful.

Good compromise! That's why we pay you the big bucks to be a chair.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 19 Feb 2002 11:25:22 -0500

I agree - sounds like a good and timely way forward.

-- Flemming

--
Flemming Andreasen
Cisco Systems