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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jan 2006 16:26:19 -0500

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.

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

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

_______________________________________________
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: Wed, 11 Jan 2006 17:45:29 -0500

> 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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jan 2006 18:13:26 -0500

It occurs to me that there is a similar issue even when there identity 
*is* present. Suppose sip identity was used, but the recipient doesn't 
trust the authentication service that provided the identity?

The UAS doesn't want to *challenge* because it has no authentication 
capability of its own. It can return 403 Forbidden, but that isn't very 
clear about what is wrong. The new 433 code isn't right for the reasons 
Jonathan spells out. Yet it may still want to reject the call.

Maybe there is need for yet another code: Untrusted Identity.

	Paul

Paul Kyzivat wrote:
>> 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 
>> 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.
> 
> 
>>> basically anonymous. Is the new response code intended for use in 
>>> this situation?
>>>
>>> John
>>>
>>>
>>>
>>
>

---

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

inline.

> carried out by a proxy acting on behalf of the callee.

Ah, good point. The behavior there can actually be performed by any 
server. So, I'll change from UAS to server.

> the Privacy header.

Well, even if the caller and called party are in different domains, a 
proxy in the called domain may see a Privacy: id header, since those are 
stripped on the egress point of the trust domain (which can span both 
networks).

> So some blocked cases are distinguishable from 

Whether this will work, in turn depends on whether the originating 
domain is prohibiting users from including invalid From header fields. 
The acr-code mechanism really works much, much better in concert with 
sip-identity for this and other reasons.

> linked to a single trust domain.

The real issue you are raising, I think, is cases where the caller is 
explicitly trying to bypass ACR. If you are dealing with cooperating 
users, you can always disambiguate blocked and unavailable by setting 
the From field correctly (From: anonymous means its blocked). You are 
correct that, in the case of a malicious caller, you stand the risk of 
allowing these users through unless you also apply some kind of 
black/white list functions that block calls for other reasons. But, 
thats an application/service issue. The problem we are trying to solve 
HERE is to indicate that a request was rejected because it was 
anonymous. Building a useful way to block telemarketers/spammers is a 
bigger, harder problem.

Thanks,
Jonathan R.