Subject: RE: [Sipping] Re: Question on draft-rosenberg-sipping-acr-code-00

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Jan 2006 07:49:00 +0000

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Jan 2006 20:30:36 +0000

Roland,

Thanks for the clarification. So in TISPAN networks ACR would apply when PAI
is missing due to privacy reasons. If a UAS receives a request without PAI,
how does it know whether it is for privacy reasons or not? Is the Privacy
header forwarded to the UAS?

John

> From: Jesske, R [mailto:[email-masked]] 
> Sent: 12 January 2006 12:51
> To: Elwell, John; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: AW: [Sipping] Re: Question on 
> 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

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 13 Jan 2006 06:55:33 +0100

John,
We have only specified the network based/application server service. In Europe we have to provide this service within our networks.

For a end device service this would be the best way to forward the privacy header, so that a UA based ACR can reject the communication. 

Best Regards

Roland

> Gesendet: Donnerstag, 12. Januar 2006 21:31
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: [email-masked]
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Jan 2006 08:04:16 +0000

Roland,

The problem is, I thought the sipping-acr-code draft was intended to be
general purpose, not something that was restricted to use in TISPAN
networks. Adding something to the main SIP response code repertoire means
that anyone can use it, and we should have procedures that explain how it
should be used in reasonable situations. I think a reasonable situation is
where a UAS receives a request without an identity it can trust and where
that identity has been withheld for privacy reasons. I fail to see how I can
do this at present.

If we want a TISPAN specific solution, let's document it as such - I would
have no problem with that. Otherwise let's make sure we have a solution that
works elsewhere.

John 

> Sent: 13 January 2006 05:56
> We have only specified the network based/application server 
> service. In Europe we have to provide this service within our 
> networks.
> 
> For a end device service this would be the best way to 
> forward the privacy header, so that a UA based ACR can reject 
> the communication. 
> 
> Best Regards
> 
> Roland
>

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Mon, 16 Jan 2006 10:16:19 +0100

Hi,

>From reading the thread, there seems to be some misunderstanding about how the service is documented by TISPAN. 

The ACR service is invoked only when the PAID is present and when a Privacy header value indicates that anonymity is requested. 

sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jesske, R
Envoyé : lundi 16 janvier 2006 08:12
À : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : AW: [Sipping] Re: Question on draft-rosenberg-sipping-acr-code-00

Why should we change it?
If a user set the display name to anonymous, he would like to say the identity given in From header is not my real identity.

Roland

> Von: Nataraju A B [mailto:[email-masked]]
> Gesendet: Sonntag, 15. Januar 2006 08:28
> An: Jesske, Roland; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> The draft draft-rosenberg-sipping-acr-code-00 specifies that 433 
> response would be sent in case the from header carries display name - 
> anonymous "OR" URI within the domain anonymous.invalid.
> 
> This Does mean it would be rejected with 433 if display name is 
> anonymous or URI domain anonymous.invalid.
> 
> Sending 433 in case display name is anonymous whereas some different 
> URI (other than anonymous.invalid) is not a GOOD idea...
> 
> Probably we can delete the mention the anonymity about display name...
> ???
> 
> Thanks & Regards,
> Nataraju A.B.
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jesske, R
> Sent: Friday, January 13, 2006 2:32 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> I showed only how TISPAN handle the ACR service, of course other 
> solutions are possible at least also for the UA.
> So I think that there is no problem also to use it as a generic 
> solution.
> The RFC3323 gives guideline how to anonymise the identity of the 
> caller.
> So you can use the privacy header and the From header to do that.
> So from my understanding the privacy header can be sent to the UA so 
> that there is a indication that privacy was required.
> An other possibility is that the URI in the From header is set to 
> Anonymous. In both cases the call can be rejected with the new 
> response code.
> Of course as Paul said there are enough holes to bypass such a 
> mechanism using other names within the From header. Fore these cases I 
> only see the possibility to use a barring mechanism (black/white 
> list).
> 
> I think how it is described within draft-rosenberg-sipping-acr-code-00
> fits to the generic approach you are asking for.
> 
> Best Regards
> 
> Roland
> 
> > Gesendet: Freitag, 13. Januar 2006 09:04
> > The problem is, I thought the sipping-acr-code draft was intended to 
> > be general purpose, not something that was restricted to use in 
> > TISPAN networks. Adding something to the main SIP response code 
> > repertoire means that anyone can use it, and we should have 
> > procedures that explain how it should be used in reasonable 
> > situations. I think a reasonable situation is where a UAS receives a 
> > request without an identity it can trust and where that identity has 
> > been withheld for privacy reasons. I fail to see how I can do this 
> > at present.
> > 
> > If we want a TISPAN specific solution, let's document it as such - I 
> > would have no problem with that. Otherwise let's make sure we have a 
> > solution that works elsewhere.
> > 
> > John
> > 
> > > For a end device service this would be the best way to forward the 
> > > privacy header, so that a UA based ACR can reject the 
> > > communication.
> > > 
> > > Best Regards
> > > 
> > > Roland
> > > 
> > > > Thanks for the clarification. So in TISPAN networks ACR would 
> > > > apply when PAI is missing due to privacy reasons. If a UAS 
> > > > receives a request without PAI, how does it know whether it is 
> > > > for privacy reasons or not? Is the Privacy header forwarded to 
> > > > the UAS?
> > > > 
> > > > John
> > > > 
> > > > > 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.
> > > > > It is not the requirement to block calls where a PAI is absent 
> > > > > due to network reasons like interworking with analogue 
> > > > > networks.
> > > > > 
> > > > > > 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
> > > > > > 
> > > > > > > > and there is nothing they can do about it to
> make it not
> > > > > > anonymous.
> > > > > > > 
> > > > > > > difference between blocked and unavailable. When using 
> > > > > > > Privacy, the Privacy
> > > > > header is
> > > > > > > domain with the caller, then the situation is a *little*
> different, because
> > > > > > > it can see
> 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