[asterisk-dev] [Code Review]: P-Asserted-Identity Privacy - fixed behaviour

[jamicque]

> On March 7, 2012, 1:01 a.m., wdoekes wrote:
> > Thanks for posting the patch here. For those who have not read the bugreport, I'll summarize my problems with this patch:
> > 
> > When dealing with peers, some should be allowed to see private/prohibited CLI's (CLIR) and some shouldn't -- sip2pstn links usually should and endusers usually shouldn't. I call these trusted and untrusted, but someone may have a better term form them.
> > 
> > Current behaviour in Asterisk is as follows:
> >  - sendrpid=no => the peer does *not* get CLIR
> >  - sendrpid=yes/rpid => the peer *does* get CLIR (with privacy=full tag)
> >  - sendrpid=pai => the peer does *not* get CLIR (but Anonymous at ...)
> > 
> > Yes, that is inconsistent, but that is the current situation.
> > 
> > 
> > What is good about this patch:
> > 
> > - The Privacy header is sent properly. However, IMO, this is only useful for these so-called 'trusted' peers.
> > 
> > - There is now a difference between trust levels.
> > 
> > 
> > My problems with this patch:
> > 
> > - It breaks backwards compatibility: sendrpid=pai will show CLIR to anyone.
> > 
> > - There is no way to disable sending of CLIR. When we don't trust the peer, the PAI should not get sent.
> >   Now, all it does is set From to Anonymous, but still send the CLIR.
> >    http://tools.ietf.org/html/rfc3325#section-10.2 
> >    """The next proxy removes the P-Asserted-Identity
> >    header field and the request for Privacy before forwarding this
> >    request onward to the biloxi.com proxy server which it does not
> >    trust."""
> > 
> > - The same goes for RPID, but there CLIR to untrusted peers should probably behave as PAI does now: set Anonymous@ in the header.
> > 
> > 
> > I like this fix, but it needs some tweaking IMO.

Hi,
my comments now :)
"...Current behaviour in Asterisk is as follows:
 - sendrpid=no => the peer does *not* get CLIR
 - sendrpid=yes/rpid => the peer *does* get CLIR (with privacy=full tag)
 - sendrpid=pai => the peer does *not* get CLIR (but Anonymous at ...)
...

- It breaks backwards compatibility: sendrpid=pai will show CLIR to anyone."

the current behaviour of PAI is buggy, there is no such possibility to send anonymous at anonymous.invalid in PAI header - according to RFC, and this is a bug in current version. My patch fixes it. Now there is no way to send in PAI: anonymous at anonymous.invalid only the true number (as in RFC). The anonymous at anonymous.invalid is put to FROM header accordingly if you not trust the peer. If you trust, then there will go the true presentation. When you are sending CLIR in PAI Privacy header is changed to "id", and that's the right behaviour according to RFC.

"- There is no way to disable sending of CLIR. When we don't trust the peer, the PAI should not get sent.
  Now, all it does is set From to Anonymous, but still send the CLIR.
   http://tools.ietf.org/html/rfc3325#section-10.2 
   """The next proxy removes the P-Asserted-Identity
   header field and the request for Privacy before forwarding this
   request onward to the biloxi.com proxy server which it does not
   trust."""

Simply set "no" for sendrpid for this peer. I do not understand your problem with that. If you do not like to send PAI header to peer, than sendrpid should be send to no.

"- The same goes for RPID, but there CLIR to untrusted peers should probably behave as PAI does now: set Anonymous@ in the header."

It works as in RFC now. Anonymous at anonymous.invalid is send only in FROM header in "rpid,untrusted", if trusted in FROM we have CPN.
In RPID header always go CPN and if CLIR privacy is set to full.


- jamicque


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1803/#review5751
-----------------------------------------------------------


On March 6, 2012, 5:16 p.m., jamicque wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1803/
> -----------------------------------------------------------
> 
> (Updated March 6, 2012, 5:16 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> It seams that in Asterisk privacy with PAI is not implemented correctly.
> 
> According to RFC 3325 when using privacy, FROM header should be set to anonymous at anonymous.invalid and PAI header should be set to caller num and name. The privacy is implemented by adding privacy: id header.
> Now when we use pai and callpres=prohib in P-Asserted-Identity header we have something which is not correct to any rfc.
> P-Asserted-Identity: "Anonymous" <sip:anonymous at anonymous.invalid>
> 
> 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 chenged to anonymous at 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 at anonymous.invalid - as in RFC 3325
> 
> 
> This addresses bug ASTERISK-19465.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 358434 
>   /trunk/channels/sip/include/sip.h 358434 
>   /trunk/configs/sip.conf.sample 358434 
> 
> Diff: https://reviewboard.asterisk.org/r/1803/diff
> 
> 
> Testing
> -------
> 
> I've done some basing test with outgoing calls and everything seems to wroks fine.
> 
> 
> Thanks,
> 
> jamicque
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120307/6a07db35/attachment-0001.htm>