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

From: "Jesske, R" <[email-masked]>
Date: Fri, 13 Jan 2006 10:02:08 +0100

John,
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 

> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Freitag, 13. Januar 2006 09:04
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [Sipping] Re: Question on 
> draft-rosenberg-sipping-acr-code-00
> 
> 
> 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 
> 
> > -----Original Message-----
> > From: Jesske, R [mailto:[email-masked]] 
> > Sent: 13 January 2006 05:56
> > To: Elwell, John; [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: AW: [Sipping] Re: Question on 
> > draft-rosenberg-sipping-acr-code-00
> > 
> > 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
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Elwell, John [mailto:[email-masked]] 
> > > Gesendet: Donnerstag, 12. Januar 2006 21:31
> > > An: Jesske, Roland; [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Betreff: RE: [Sipping] Re: Question on 
> > > draft-rosenberg-sipping-acr-code-00
> > > 
> > > 
> > > 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
> > > 
> > > > -----Original Message-----
> > > > 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 
> > > > draft-rosenberg-sipping-acr-code-00
> > > > 
> > > > 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jan 2006 08:44:12 -0500

> So from my understanding the privacy header can be sent to the UA so that there is a indication that privacy was required.

That is not how I read 3323. It says that as a token in the Privacy 
header is acted upon the token should be removed from the privacy 
header, and when all are removed the Privacy header should also be 
removed. So in the case of Privacy:id, when a proxy acts upon this by 
removing the P-Asserted-Identity header, it is also to remove the 
Privacy header. The only exception I see to this is Privacy:none, which 
must remain. But that isn't relevant here.

	Paul

---

From: "Nataraju A B" <[email-masked]>
Date: Sun, 15 Jan 2006 12:57:59 +0530

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.

-----Original Message-----
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]
Subject: AW: [Sipping] Re: Question on
draft-rosenberg-sipping-acr-code-00

John,
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Jan 2006 14:36:19 -0500

I'll use this opportunity to shamelessly again plug:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-privacy-00.txt

which provides a much better solution to the privacy problem than 
rfc3323. Note in particular that RFC 3323 really doesn't work in 
conjunction with draft-ietf-sip-identity, and something else is needed.

As it relates to the acr-code draft, as I mentioned in my note to Paul, 
the general problem of malicious callers, aka spammers, is a big one and 
a simple response code is not going to fix the problem. I've beefed up 
the security considerations section to discuss this, and mostly point to 
sipping-spam for a more thorough discussion:

<section title="Security Considerations">

<t>
The fact that an request was rejected because it was anonymous does
reveal information about the called party - that they do not accept
anonymous calls. This information may or may not be sensitive. If it
is, a UAS SHOULD reject the request with a 403 instead.
</t>

<t> In the Public Switched Telephone Network (PSTN), the Anonymous
Call Rejection (ACR) feature is commonly used to prevent unwanted
calls from telemarketers (also known as spammers). Since telemarketers
frequently withhold their identity, this has the desired effect in
many (but not all) cases. It is important to note that the response
code described here is likely to be ineffective in blocking SIP-based
spam. The reason is that a malicious caller can include a From header
field and display name that is not anonymous, but is meaningless and
invalid. Without a Privacy header field, such a request will not
appear anonymous and thus not be blocked by an anonymity screening
service. Dealing with SIP-based spam is not a simple problem. The
reader is referred to <xref target="I-D.ietf-sipping-spam"/> for a
discussion of the problem.
</t>

-Jonathan R.

Paul Kyzivat wrote:

>> 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).
>>
>>> Von: Elwell, John [mailto:[email-masked]] Gesendet: Freitag, 
>>> 13. Januar 2006 09:04
>>> The problem is, I thought the sipping-acr-code draft was intended to be
>>> 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
>>> 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
>>>
>>>> From: Jesske, R [mailto:[email-masked]] 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
>>>>
>>>>
>>>>> Von: Elwell, John [mailto:[email-masked]] Gesendet: 
>>>>> Donnerstag, 12. Januar 2006 21:31
>>>>> 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
>>>>>> From: Jesske, R [mailto:[email-masked]] Sent: 12 January 2006 
>>>>>> 12:51
>>>>>> 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
>>>>>>
>>>>>>> Von: Elwell, John [mailto:[email-masked]] Gesendet: 
>>>>>>> Donnerstag, 12. Januar 2006 08:49
>>>>>>> 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
>>>>>>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: 11 January 
>>>>>>>> 2006 22:45
>>>>>>>> To: Jonathan Rosenberg
>>>>>>>> The problem is that there is no good way to tell the difference 
>>>>>>>> between blocked and unavailable. When using Privacy, the Privacy 
>>>>>>
>>>>>>
>>>>>> header is
>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>>>> 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
>>>>
>>>>>>>> the call through.
>>>>>>>> callees are linked to a single trust domain.
>>>>>>>>
>>>>>>>>     Paul
>>>>>>>>
>>>>>>>>
>>>>>>>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com