Subject: AW: AW: [Sipping] Re: Question on draft-rosenberg-sipping-acr-cod e-00

From: "Jesske, R" <[email-masked]>
Date: Fri, 13 Jan 2006 07:30:35 +0100

Paul,
I know that interconnecting different networks opens holes. With regard to an regulated environment the networks have to provide a originating identity. And the operator/service provider has the ability not to interconnect to untrusted networks that are not providing a PAI.
Within networks not providing a PAI the From header is the hint for the identity of User A. 
The From header is a user provided header so I can never trust the identity within the From header. So to block such anonymous calls we can use a incoming barring service that we have also specified where at least ACR is a special case.
So the user can define a rules to block calls based on the information given in the From header.  
The general barring service is not regulated but ACR is.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Donnerstag, 12. Januar 2006 18:51
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: AW: [Sipping] Re: Question on 
> draft-rosenberg-sipping-acr-code-00
> 
> 
> Jesske,
> 
> ACR is an impediment to some whose goal is to call you without their 
> identity being divulged. Some of those (e.g. telemarketers) have a 
> strong incentive to get around the ACR.
> 
> If they can get around it be calling from a different 
> network, then that 
> is what they will do. So while what you describe may be 
> consistent with 
> the requirements you have adopted, it may not be considered 
> sufficient 
> by users.
> 
> OTOH, I don't think this is a solvable problem with the current 
> communications infrastructure. The concept of an ACR feature that can 
> distinguish between blocked and unavailable may just be 
> fatally flawed.
> 
> 	Paul
> 
> Jesske, R wrote:
> > That what we specified within ETSI is based on the PAI and 
> the privacy header. When the user expresses his wish to 
> anonymise it's public ID the ACR service will be invoked.
> > With regard to the from header there is no triggering for 
> the ACR service.
> > 
> > That is the same behaviour as for the equivalent PSTN/ISDN 
> service and the regarding requirements from regulation.
> > 
> > It is not the requirement to block calls where a PAI is 
> absent due to network reasons like interworking with analogue 
> networks.
> > 
> > The idea of an other response code for an untrusted 
> identity could be the basis for a new service that is not 
> defined yet. But thinkable.
> > 
> > Best Regards
> > 
> > Roland
> > 
> >>-----Ursprüngliche Nachricht-----
> >>Von: Elwell, John [mailto:[email-masked]] 
> >>Gesendet: Donnerstag, 12. Januar 2006 08:49
> >>An: Paul Kyzivat; Jonathan Rosenberg
> >>Cc: sipping
> >>Betreff: RE: [Sipping] Re: Question on 
> >>draft-rosenberg-sipping-acr-code-00
> >>
> >>
> >>The point that Paul makes about putting a fictitious or 
> >>meaningless caller
> >>ID in the From header was what I had in mind when I asked 
> my original
> >>question. If I get an ACR response I just substitute a caller 
> >>ID at will,
> >>and if this gets through my own domain then it will also 
> >>avoid ACR. Without
> >>PAI, Identity or AIB, the called domain or UAS has no way of 
> >>detecting this.
> >>
> >>John
> >>
> >>
> >>>-----Original Message-----
> >>>From: Paul Kyzivat [mailto:[email-masked]] 
> >>>Sent: 11 January 2006 22:45
> >>>To: Jonathan Rosenberg
> >>>Cc: Elwell, John; sipping
> >>>Subject: Re: [Sipping] Re: Question on 
> >>>draft-rosenberg-sipping-acr-code-00
> >>>
> >>>
> >>>
> >>>Jonathan Rosenberg wrote:
> >>>
> >>>>This is an old mail, my apologies for the really long time 
> >>>
> >>>to respond. 
> >>>
> >>>>This draft has started to get some attention again recently.
> >>>>
> >>>>John raises an interesting point. This basic question has 
> >>>
> >>>been discussed 
> >>>
> >>>>almost endlessly in the SIMPLE/GEOPRIV groups as well. The 
> >>>
> >>>issue there 
> >>>
> >>>>was that the common policy/presence policy specs have had 
> >>>
> >>>fields that 
> >>>
> >>>>define an "anonymous" condition, and we've debated whether 
> >>>>unauthenticated counts as anonymous.
> >>>>
> >>>>Unfortunately this never really concluded; we just got rid of the 
> >>>>anonymous condition :(
> >>>>
> >>>>In this particular case, I don't think it helps to count 
> >>>
> >>>unauthenticated 
> >>>
> >>>>as anonymous. The reason is, the whole point of the 
> >>>
> >>>resposne code is 
> >>>
> >>>>that the caller can do something different in an attemtp to 
> >>>
> >>>get the call 
> >>>
> >>>>through. In this case, the caller has not actually TRIED to be 
> >>>>anonymous; its just that their service provider didn't do PAID or 
> >>>>sip-identity. So, if the call is rejected as anonymous, the 
> >>>
> >>>caller will 
> >>>
> >>>>be surprised, since it wasn't anonymous as far as they were 
> >>>
> >>>concerned, 
> >>>
> >>>>and there is nothing they can do about it to make it not 
> >>
> >>anonymous.
> >>
> >>>The problem is that there is no good way to tell the 
> >>>difference between 
> >>>blocked and unavailable. When using Privacy, the Privacy header is 
> >>>removed before the request gets to the UAS.
> >>>
> >>>While responding to this I noticed something missing from 
> >>>draft-rosenberg-sipping-acr-code-00: it does not specify 
> >>>proxy behavior. 
> >>>This is significant because it is possible for the ACR 
> >>
> >>feature to be 
> >>
> >>>carried out by a proxy acting on behalf of the callee.
> >>>
> >>>If that is happening, and the proxy is in the same trust 
> >>>domain with the 
> >>>caller, then the situation is a *little* different, because 
> >>>it can see 
> >>>the Privacy header. So some blocked cases are distinguishable from 
> >>>unavailable cases. But that is still only a limited set, 
> >>
> >>because the 
> >>
> >>>caller could be in a different trust domain. So again, it becomes 
> >>>necessary to fall back to reading the tea leaves to decide between 
> >>>blocked and unavailable. (Looking for Anonymous in the 
> From header.)
> >>>
> >>>Note that looking at From isn't reliable either. If I don't 
> >>>want to be 
> >>>blocked by ACR, I can just set my Privacy:id and set my From to 
> >>>something like: From: nobody <sip:[email-masked]>. 
> Then the 
> >>>callee will treat me as having an unavailable address and let 
> >>>the call 
> >>>through.
> >>>
> >>>I think the fundamental problem here is that 
> distinguishing between 
> >>>unavailable and blocked can only work when all callers and 
> >>>callees are 
> >>>linked to a single trust domain.
> >>>
> >>>	Paul
> >>>
> >>>
> >>>
> >>>>So, I'd suggest that we not include unauthenticated in the 
> >>>
> >>>list of cases.
> >>>
> >>>>-Jonathan R.
> >>>>
> >>>>Elwell, John wrote:
> >>>>
> >>>>
> >>>>>What if a UAS receives a request containing an unauthenticated 
> >>>>>identity in the From header? If the UAS or user is not 
> >>
> >>prepared to 
> >>
> >>>>>trust the unauthenticated identity, the source of the request is 
> >>>>>basically anonymous. Is the new response code intended for 
> >>>
> >>>use in this 
> >>>
> >>>>>situation?
> >>>>>
> >>>>>John
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>_______________________________________________
> >>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
> >>
> > 
> > 
> 

_______________________________________________
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