[Home]

Summary:ASTERISK-19465: P-Asserted-Identity Privacy
Reporter:Krzysztof Chmielewski (kristoff)Labels:
Date Opened:2012-03-02 09:25:58.000-0600Date Closed:2014-04-22 09:54:01
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.9.3 Frequency of
Occurrence
Related
Issues:
is related toASTERISK-25791 res_pjsip_caller_id: Lack of support for Anonymous
Environment:Attachments:( 0) bugASTERISK-19465_v4.patch
( 1) pai_rpid_fromname.diff
( 2) pai_rpid_fromnamev2.diff
( 3) pai_rpid_fromnamev3.diff
( 4) pai_rpid_fromnamev5.patch
Description:It seams that in Asterisk 1.8 (1.8.9.3) privacy with PAI is not implemented correctly.

According to RFC 3325 when using privacy, FROM header should be set to anonymous@anonymous.invalid and PAI header should be set to caller num and name. The privacy is implemented by adding privacy: id header.

From RFC:
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id


It seams that Asterisk sets the headers the other way round (more or less) and does not include the "privacy: id" header.

Dial Plan:
exten => 111,1,Set(CALLERID(num-pres)=prohib)
exten => 111,n,Set(CALLERID(all)=aaaa <222222>)
exten => 111,n,Dial(SIP/+48111111111@fffff)

SIP Debug:
INVITE sip:+48111111111@sip.freeconet.pl:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.4.52:5060;branch=z9hG4bK32a20f99;rport
Max-Forwards: 70
From: "TEST" <sip:TEST@sip.freeconet.pl>;tag=as6df1f4ca
To: <sip:+481111111119@sip.freeconet.pl:5060>
Contact: <sip:TEST@10.0.4.52:5060>
Call-ID: 709d2bdf61388bf80679b9e348338123@sip.freeconet.pl
CSeq: 102 INVITE
User-Agent: UA_TEST
Date: Fri, 02 Mar 2012 15:11:19 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
P-Asserted-Identity: "Anonymous" <sip:anonymous@anonymous.invalid>
Content-Type: application/sdp
Content-Length: 278


TEST is default CallerID
Peers are from DB.

Or perhaps I'm doing something wrong here :(

Comments:By: Walter Doekes (wdoekes) 2012-03-02 10:08:54.759-0600

I believe you're running into the problem that you cannot specify whether you trust your peer or not. (Unless this is changed in newer versions.)

The sendrpid=yes (using Remote-Party-Id) puts trust in the recipient;
the pai option here looks like it doesn't.

Where I am, legislations forbids us to send this info to end users, so I can't use sendrpid=yes. The pai behaviour you're describing would work for those peers, but wouldn't for my sip2pstn links.
By: Maciej Krajewski (jamicque) 2012-03-02 18:52:30.730-0600

The PAI behaviour when CLIR is wrong according to RFC - as Krzysztof has written - there is missing "privacy" header + ""Anonymous" <sip:anonymous@anonymous.invalid>" Shouldn't be placed in PAI - but the name, number and real domain.
By: Walter Doekes (wdoekes) 2012-03-05 03:17:59.243-0600

jamicque: you fail to address the problem of trust.

But, you're right that it doesn't comply with RFC in either case.

http://tools.ietf.org/html/rfc3325#section-10.2
says that the PAI should be stripped when CLIR and untrusted nexthop.
By: Maciej Krajewski (jamicque) 2012-03-06 07:24:29.691-0600

I've attached patch to fix this problem.
What this patch does:
- add Privacy header in P-Asserted-Identinty (which was missing), according to privacy options it's filled with value "none" or "id"
- added to options to "sendrpid" varible: "pai_anonymous" and "rpid_anonymous", setting those variables changes From header to anonymous@anonymous.invalid accodring to rfc. When "pai" or "rpid" is set FROM header is passed normaly.
By: Walter Doekes (wdoekes) 2012-03-06 07:55:41.815-0600

That patch is not going to work for several reasons:

(1) We don't want Anonymous in the From always, we want it ONLY when PRES=prohib.
(2) You fail to address the problem I mentioned two times already: you cannot send PAI to untrusted peers. You don't trust them enough to send them privacy-sensitive info.
(3) This is not backwards compatible, and users will complain.

The only good thing is the addition of the Privacy header.


If you changed things to account for this, you'd stand a bigger chance of getting it committed:

(1) Do change the From to Anonymous@..., but only when CLIR + untrusted-peer.
(2) And in those circumstances (CLIR + untrusted-peer) do *NOT* send the PAI and set RPID to Anonymous@...
(3) Discern trust for the peer by adding an optional parameter to sendrpid: rpid,trusted | rpid,untrusted | pai,trusted | pai,untrusted
   (where only "rpid" means "rpid,trusted" and only "pai" means "pai,untrusted" (with the modifications mentioned above))

By: Maciej Krajewski (jamicque) 2012-03-06 08:09:44.909-0600

Walter could be please explain me the thing with trusted and untrusted peer, coz I don't understand this.
thanks
By: Walter Doekes (wdoekes) 2012-03-06 08:21:38.380-0600

It's quite simple:

let's assume I have SIP2PSTN and USER1 on my system.

Legislation forces me to put the CLI of USER1 on the network when he is calling to SIP2PSTN. If USER1 wants privacy, I'll add the privacy bit, but SIP2PSTN still gets the full CLI. I want "pai,trusted" or "rpid,trusted" for my SIP2PSTN peer. I trust them to not send the actual CLI to the enduser, because that would break CLIR for USER1.

However, legislation also forces me to preserve the privacy of callers from SIP2PSTN. So when a remote caller coming in through SIP2PSTN wants privacy, I get a PAI/RPID header with a privacy bit. I store the CLI from the caller in my CDRs, but I strip it from the message before sending it to USER1 -- which is an enduser to me. USER1 is not allowed to see the actual caller. Not in the From header and not in any PAI or RPID header either. I want the "untrusted" versions for the USER1 peer.

By: Maciej Krajewski (jamicque) 2012-03-06 08:35:45.645-0600

According to the rfc despite the fact that the proxy is trusted or not you should send anynomus@anynous.invalid in from - the patch does that with option "pai_anonymous"
If the peer is untrusted you should not send the P-asserted-identity header at all!

The reason why I left sending something else in FROM when CLIR and using PAI is the situation when the telco peer oblige you to do so - some of telco operators on Broadsoft softswitch need to have username and domain in from - as in your case Walter.

What my patch does it modifies the sending invite packet, not the way that received invite packets are served.
That's why in my opinion you won't have any problem with that.

In your described situation what you sipmply have to do is set pai or rpid in sendrpid option - that all.

It is backward compatible, there is no change in behaviour of rpid and pai headers.

So the only optional thing that can be changed is the naming.

Please let me know if I'm getting something wrong.
By: Maciej Krajewski (jamicque) 2012-03-06 16:08:35.967-0600

I've attached the second version of the patch,
all of the Walters remarks if weren't fixed before have been fixed in this patch.
what it does:
"sendrpid" configuration option have been expanded:
now it can have those values:
* no - nothing changed
* yes - rpid header is added, when call PRES=prohi, FROM header is not changed
* rpid - the same as yes
* pai - pai header is added, when call PRES=prohi, FROM header is not changed

NEW VALUES:
* rpid,trusted (NEW) - the same as yes
* rpid,untrusted (NEW) - rpid header is added, when call PRES=prohi, FROM header is chenged to anonymous@anonymous.invalid
* pai,trusted (NEW) - the same as pai
* pai,untrusted (NEW) - pai header is added, when call PRES=prohi, FROM header is chenged to anonymous@anonymous.invalid - as in RFC 3325




By: Maciej Krajewski (jamicque) 2012-03-06 16:15:09.761-0600

I've updated the config file sip.conf
By: Jamuel Starkey (jamuel) 2012-03-06 16:17:01.267-0600

Looking at your NEW VALUES in your comments I'm guessing the last value should be pai,untrusted (NEW) instead of rpid,untrusted(NEW) since that would be a repeat of your 2nd new value.

Please update the comments and/or sip.conf if that is the case.
By: Maciej Krajewski (jamicque) 2012-03-06 16:20:37.470-0600

thanks for remark, comment has been already updated, the patch is all right (copy pate bug).
Patch works fine both in 1.8 and 10.
By: Walter Doekes (wdoekes) 2012-03-06 16:24:00.310-0600

I don't think I'm getting my point across:

- old situation: users have sendrpid=pai and caller had CLIR: callee is *not* getting caller CLI but Anonymous@invalid
- new situation: users have sendrpid=pai and caller had CLIR: callee is suddenly getting caller CLI, not cool

Even with your latest patch there is no way to get the old behaviour of hiding the CLI from the recipient.

I'm giving up.

Please do post your patch to the reviewboard ( https://reviewboard.asterisk.org/ ). You should be able to get some more input from there.


By: Maciej Krajewski (jamicque) 2012-03-06 16:28:28.467-0600

Walter - the old situation was buggy!
It was not right according to RFC!!
Should the patch be compatible with a bug? I do not think so.
Thanks for help - I'm posting this patch right now. Thanks.
By: Walter Doekes (wdoekes) 2012-03-07 04:38:51.475-0600

23:37 <jamicque> I have a question regarding your last comment, becouse or I'm not awere of something in RFC or maybe some specific configuration of some vendors
23:38 <jamicque> I can't find te situation when in PAI should be sent anonymous@anonymous.invalid Accroding to me it's a buggy behaviour

You go offline too quickly ;)

I'm not saying I want Anonymous@anonymous.invalid in the PAI.
I *am* saying I want the PAI stripped if the peer is untrusted and privacy was requested.

You say I can just set sendrpid=no, but then I lose the option of using RPID and/or PAI. And certain devices (can) depend on those. Even for asterisk there are certain use cases: using From to to select which user is calling and using RPID/PAI to choose what CLI he/she wants.
By: Maciej Krajewski (jamicque) 2012-03-07 05:20:20.749-0600

Ok, but the senderpid is peer based (not global), and if the peer is untrusted you do not send him PAI header at all - neither the case he wants his call-pres allow or prohib.
So simply turn off the sendpid on untrusted peer's (devices) and turn them on on ones needing PAI header.

If I'm still getting it wrong please write me the scenarios and what should be send in FROM PAI in those situations.
By: Maciej Krajewski (jamicque) 2012-03-07 10:18:21.462-0600

What my patch does:
1) it adds Privacy header when PAI is used (values "none" or "id" depending on callpres)
2)
3) "sendrpid" configuration option have been expanded:
now it can have those values:

   no - nothing changed
   yes - rpid header is added, when call PRES=prohi, FROM header is not changed
   rpid - the same as yes
   pai - pai header is added, when call PRES=prohi, FROM header is not changed

NEW VALUES:

   rpid,trusted (NEW) - the same as yes
   rpid,untrusted (NEW) - rpid header is added, when call PRES=prohi, FROM header is changed to anonymous@anonymous.invalid and rpid header is srtiped.
   pai,trusted (NEW) - the same as pai
   pai,untrusted (NEW) - pai header is added, when call PRES=prohi, FROM header is chenged to anonymous@anonymous.invalid and pai header is srtiped. - as in RFC 3325

When we are using PAI or RPID ,fromname is defined and CLIR, we do not set anonymous@anonymous.invalid - coz this from in this situation is usually used for authentication.
By: Maciej Krajewski (jamicque) 2012-03-09 01:46:07.394-0600

the newest version of the patch
What my patch does:
1) adds new configurable parameter for peer - trustpeer (whether we should send privacy information to peer or not)
2) it adds Privacy header to trusted peer when PAI and CLIR is used (values "id")
3) When PAI or RPID with CLIR is used and fromuser is set it is often used for authentication/recognition of the peer on the other side so we set the proper domain (not anonymous.invalid)
By: Maciej Krajewski (jamicque) 2012-03-25 16:07:23.376-0500

does anyone has any remarks to the patch?
By: Maciej Krajewski (jamicque) 2012-05-18 08:46:08.237-0500

ping?
By: Deniz (deniz) 2012-06-15 04:34:34.153-0500

In case of transfer to another trusted peer the new generated INVITE will have 2 PAI-Header. There should be a check for an existing PAI-Header before adding a new one.
By: Maciej Krajewski (jamicque) 2012-06-15 05:05:20.093-0500

Deniz could you please give a complete SIP scenario of such situation?
By: Deniz (deniz) 2012-06-18 07:53:29.300-0500

example:
trusted peer A (920) is calling trusted peer B(900) (P-Asserted-Identity: <sip:0049xxxxxxxxx920@domain;user=phone>)
peer A put B on hold and is doing an unattended transfer to peer C (910)

The REFER looks like:


REFER sip:900@5.6.7.8:5060 SIP/2.0
Record-Route: <sip:1.2.3.4;lr;ftag=locbeezss9>
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa15d.f01f9a44.0
Via: SIP/2.0/UDP 1.3.5.7:5060;branch=z9hG4bKc006c924de01eace4d265816cb087d03
Via: SIP/2.0/TLS 192.168.49.113:2060;branch=z9hG4bK-f87yl367dlqi;rport
From: "920" <xxxxxxx@1.2.3.4:5060>;tag=locbeezss9
To: <sip:900@1.2.3.4:5060>;tag=as53730d0e
Contact: <sip:xxxxx@1.3.5.7:5060;transport=UDP>
Cseq: 4 REFER
Call-ID: 3c26a620497e-xc3ve48dm2zz
Max-Forwards: 68
Refer-To: sip:910@1.2.3.4:5060
Referred-By: sip:xxxxxxxxxx@1.2.3.4:5060
User-Agent: snom360/8.4.35
Content-Length: 0
P-hint: rr-enforced

the asterisk (1.8.10) is generating this INVITE for peer C:

U 2012/06/18 14:23:37.708421 5.6.7.8:5060 -> 1.2.3.4:5060
INVITE 910@1.2.3.4 SIP/2.0
Via: SIP/2.0/UDP 5.6.7.8:5060;branch=z9hG4bK0aa47d53;rport
Max-Forwards: 70
From: "900" <sip:900@1.2.3.4>;tag=as59727eb8
To: <910@1.2.3.4>
Contact: <sip:900@5.6.7d.8:5060>
Call-ID: 178c7cca1a0a2e476639325a08ebd012@1.2.3.4
CSeq: 102 INVITE
User-Agent: pbx
Date: Mon, 18 Jun 2012 12:23:37 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
P-Asserted-Identity: <sip:0049xxxxxxxxx920@domain;user=phone>
P-Asserted-Identity: "900" <sip:900@1.2.3.4>
Content-Type: application/sdp
Content-Length: 27

[...]


In this case 2 PAI-Header are sent to peer C. In my case an Aastra which is rejecting with "400 Too many or erroneous P-Asserted-Identity header(s)"
By: Maciej Krajewski (jamicque) 2012-06-22 13:05:49.991-0500

Deniz could you please confirm that my patch does not create this problem, without my patch problem also exist.
By: Deniz (deniz) 2012-06-25 08:19:56.031-0500

your patch is not creating this issue.

I think the easiest solution is to check if the header is already present:

if (ast_strlen_zero(get_header(req, "P-Asserted-Identity"))) {
  add_header(req, "P-Asserted-Identity", ast_str_buffer(tmp));
}

By: Maciej Krajewski (jamicque) 2012-06-25 08:43:56.112-0500

IMHO it should be dealt another way.
Nor rpid nor P-asserted-identinty header from original connection should be passed.
There should be another ticket for this.

In your scenario peer C would always get PAI/RPID header from the first call - even if rpid for the C peer is set to no.

However, I think  that someone with bigger experience should take the floor here. I can't find where to put thus condition in source code.

By: dadjul (djul) 2013-06-28 08:23:30.132-0500

Hello

I need this patch but I am running 1.8.20.0 which failed to apply.
Is the feature implemented somewhere or is there a way I can get this patch for my version?

My provider wants me to send normal FROM (not anonymous.invalid) but RPID privacy=full in order to show anonymous

Thanks.
By: Matt Jordan (mjordan) 2014-04-22 09:54:01.589-0500

This got closed via review https://reviewboard.asterisk.org/r/3447/.

This patch adds a new configuration option that provides better privacy control for RPID and P-Asserted-Identity. See the CHANGES file for more information.