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

["GARCIN Sebastien RD-CORE-ISS" <[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de Jesske, R
Envoyé : lundi 16 janvier 2006 08:12
À : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc : [e-mail]
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


> -----Ursprüngliche Nachricht-----
> Von: Nataraju A B [mailto:[e-mail]]
> Gesendet: Sonntag, 15. Januar 2006 08:28
> An: Jesske, Roland; [e-mail]; [e-mail]; 
> [e-mail]
> Cc: [e-mail]
> Betreff: RE: [Sipping] Re: Question on 
> draft-rosenberg-sipping-acr-code-00
> 
> 
> 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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Jesske, R
> Sent: Friday, January 13, 2006 2:32 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> 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
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Elwell, John [mailto:[e-mail]]
> > Gesendet: Freitag, 13. Januar 2006 09:04
> > An: Jesske, Roland; [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > > Sent: 13 January 2006 05:56
> > > To: Elwell, John; [e-mail]; [e-mail]
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > > > Gesendet: Donnerstag, 12. Januar 2006 21:31
> > > > An: Jesske, Roland; [e-mail]; [e-mail]
> > > > Cc: [e-mail]
> > > > 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:[e-mail]]
> > > > > Sent: 12 January 2006 12:51
> > > > > To: Elwell, John; [e-mail]; [e-mail]
> > > > > Cc: [e-mail]
> > > > > 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:[e-mail]]
> > > > > > 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:[e-mail]]
> > > > > > > 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:[e-mail]>. 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 [e-mail] for questions on
> > > current sip
> > > > > > Use [e-mail] 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 
> [e-mail] for questions on current sip Use 
> [e-mail] 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 [e-mail] for questions on current sip Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP