Re: [sipcore] Understanding Privacy: history invoked by UAS
Shida Schubert <shida@ntt-at.com> Wed, 10 November 2010 05:46 UTC
Return-Path: <shida@ntt-at.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B913A68AF for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 21:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.672
X-Spam-Level:
X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3clehivc2QN4 for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 21:46:34 -0800 (PST)
Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.243.11]) by core3.amsl.com (Postfix) with SMTP id D25BA3A68A3 for <sipcore@ietf.org>; Tue, 9 Nov 2010 21:46:33 -0800 (PST)
Received: (qmail 29797 invoked from network); 10 Nov 2010 05:46:26 -0000
Received: from gator465.hostgator.com (69.56.174.130) by gateway05.websitewelcome.com with SMTP; 10 Nov 2010 05:46:26 -0000
Received: from [130.129.128.223] (port=60503 helo=dhcp-80df.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1PG3WG-0002rP-M3; Tue, 09 Nov 2010 23:46:54 -0600
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com>
Date: Wed, 10 Nov 2010 14:46:53 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B516382-FED2-4AE0-A17D-81C04B04E843@ntt-at.com>
References: <A444A0F8084434499206E78C106220CA02357ADA69@MCHP058A.global-ad.net> <A78B9020-EB78-477E-8B2A-22F8F27B1032@ntt-at.com> <A444A0F8084434499206E78C106220CA023587F123@MCHP058A.global-ad.net> <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 05:46:35 -0000
If you remove an entry or entries, I guess you may end up with a gap in index and depending on when and how much is removed, the index can deliver a false representation of request path (if 1.1 and 1.1.1 was removed entity receiving the request will add hi-entry probably with an index of 1.1, missing 2 hops) and may provide an erroneous "forwarding count" etc. But this is something that would happen already with RFC4244. RFC4244bis enforces privacy service to anonymize the hi-entry by changing the hi-target-to-uri into anonymized URI and tries to prohibit (at least on the specification) privacy service from removing the hi-entry. RFC4244 on the other hand, was pretty flexible with how privacy service would conduct anonymization, it didn't prohibit privacy service from removing the hi-entry. So I don't think anything would break as things are working now without this enforcement added in RFC4244bis. I think in most deployment where this is important, how hi-entry is anonymized is probably enforced and consistent within the environment where it matters. Regards Shida On Nov 10, 2010, at 1:52 PM, Hadriel Kaplan wrote: > > Out of curiosity, will anything "break" if the anonymized H-I entries are simply removed? I'm not suggesting we document doing that in the draft, just asking if any apps/use-cases/whatever will break if it happens. Because my guess is some of us will just remove them, and I'd like to know if there's any real reason I shouldn't. > > -hadriel > > On Nov 9, 2010, at 10:50 PM, Shida Schubert wrote: > >> >> I think RFC4244 was quite vague about how privacy is >> requested and due to that, both privacy header outside >> H-I header or part of hi-entry are used without any clear >> distinction. >> >> Thus for backward compatibility, I don't think we can >> eliminate the use of Privacy:history, I think we can definitely >> clarify the use of them by saying proxy SHOULD or MUST >> use privacy=header and UAC uses Privacy:history. >> >> I do think we should clarify the procedure of how history-info >> is anonymized, may be something along the line as follows. >> >> 1. Setting privacy indication. >> >> UAC sets privacy by setting privacy:header or privacy:history >> Proxy/UAS sets privacy by setting privacy=history in hi-entry >> >> 2. Applying privacy to request. >> >> Privacy service at the boundary of domain checks if privacy:header >> or privacy:history exists. >> >> If privacy:history or privacy:header exists then it anonymize all the >> hi-entry from its responsible domain by changing the hi-target-to-uri >> to URI with anonymous.invalid. >> >> If the hi-entry that is a target of anonymization and has privacy=history, >> it will remove the privacy=history after anonymizing the hi-entry. >> >> If the hi-entry is already anonymized (URI with anonymous.invalid) it >> will leave the entry as is. >> >> After anonymizing all the hi-entry from its responsible domain it will >> remove the priv-value of "history" from Privacy header (real header). >> >> If there are no priv-value remaining in the Privacy header then it will >> remove the Privacy header itself following the procedure in RFC3323. >> >> If there is no priv-value of "history" or "header", privacy service >> looks through hi-entries and see if there are URI from its domain >> with privacy=history. >> >> For each hi-entry with privacy=history, privacy service will anonymize >> the hi-target-to-uri and remove the privacy=history after anonymizing >> the hi-entry. >> >> 3. Privacy:none >> >> With regards to privacy:none, it's tad tricky because >> as Ian said, how it's honored depends on the regulation etc. >> >> Regards >> Shida >> >> On Nov 10, 2010, at 10:30 AM, Elwell, John wrote: >> >>> In which case we don't need Privacy: history in the response, since it is only a partial solution? >>> >>> John >>> >>>> -----Original Message----- >>>> From: Shida Schubert [mailto:shida@ntt-at.com] >>>> Sent: 09 November 2010 06:24 >>>> To: Elwell, John >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS >>>> >>>> >>>> Hi John; >>>> >>>> In practice, if C cares about its privacy, there should be >>>> a priori arrangement with the service provider or >>>> configuration in proxy to withhold its identity. >>>> >>>> This will allow the proxy sending the 4xx which sets the hi-entry >>>> to ensure privacy is applied by setting escaped privacy header >>>> or Privacy:header. >>>> >>>> Regards >>>> Shida >>>> >>>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: >>>> >>>>> Suppose a request from A is targeted initially at B, this >>>> is mapped to C, and then to registered contact D. The UAS (D) >>>> puts Privacy: history in the response, and therefore prevents >>>> A learning about C and D. Fine. >>>>> >>>>> Now, supposing D is not registered at the time, i.e., there >>>> is no registered contact for C. This results in a 4xx >>>> response to A. How do we ensure that the identity of C is not >>>> disclosed to A, in line with what is achieved when D is registered? >>>>> >>>>> John >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >
- [sipcore] Understanding Privacy: history invoked … Elwell, John
- Re: [sipcore] Understanding Privacy: history invo… Shida Schubert
- Re: [sipcore] Understanding Privacy: history invo… Elwell, John
- Re: [sipcore] Understanding Privacy: history invo… Shida Schubert
- Re: [sipcore] Understanding Privacy: history invo… Hadriel Kaplan
- Re: [sipcore] Understanding Privacy: history invo… Shida Schubert
- Re: [sipcore] Understanding Privacy: history invo… Paul Kyzivat
- Re: [sipcore] Understanding Privacy: history invo… Worley, Dale R (Dale)
- Re: [sipcore] Understanding Privacy: history invo… Worley, Dale R (Dale)
- Re: [sipcore] Understanding Privacy: history invo… R.Jesske
- Re: [sipcore] Understanding Privacy: history invo… Mary Barnes