Re: [sipcore] privacy handling

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 31 August 2010 23:42 UTC

Return-Path: <HKaplan@acmepacket.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 DD0AA3A6870 for <sipcore@core3.amsl.com>; Tue, 31 Aug 2010 16:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599]
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 kw+OhAyROyUs for <sipcore@core3.amsl.com>; Tue, 31 Aug 2010 16:42:05 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7D6B63A67EF for <sipcore@ietf.org>; Tue, 31 Aug 2010 16:42:05 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 31 Aug 2010 19:42:35 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 31 Aug 2010 19:42:35 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Date: Tue, 31 Aug 2010 19:42:32 -0400
Thread-Topic: [sipcore] privacy handling
Thread-Index: ActJZi7wsgkaGYA2StuUGrKI/Wmd5A==
Message-ID: <311D1F6C-0EC5-43CB-9107-ED88DD022963@acmepacket.com>
References: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C01@DC-US1MBEX4.global.avaya.com> <4C7D3990.5010205@cisco.com> <AANLkTimiDwgpgJbDT0c_sVov_76YAcPoz4Or21acVHkD@mail.gmail.com> <4C7D730F.3060202@cisco.com> <AANLkTimUrGA6AM=p8azr=KmxVTgAG=_CvHq3dcaH9RPk@mail.gmail.com> <4C7D83CC.5000908@cisco.com>
In-Reply-To: <4C7D83CC.5000908@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Worley, Dale R (Dale)" <dworley@avaya.com>, "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
Subject: Re: [sipcore] privacy handling
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: Tue, 31 Aug 2010 23:42:07 -0000

On Aug 31, 2010, at 6:35 PM, Paul Kyzivat wrote:

> Another point I just realized while reviewing 3323: when a privacy
> service acts on a privacy value, such as "Privacy:header", or
> "Privacy:history", it also removes that value from the Privacy header.
> So those actions are only performed *once*. If "Privacy:history" is
> included by the UAC, and is processed by the first proxy encountered,
> subsequently added H-I information will not be anonymized. (Unless
> "Privacy:history" is added *again* by a proxy after that.)

But isn't that the right thing, and what we really want?  I mean if you make a call to me, you may want to anonymize your H-I so I don't find out the call is coming from you/Cisco, but that is really only possible and practical for the H-I entries generated by Cisco or some privacy service under your control - once the request reaches Acme you can't expect my servers to anonymize who it's from.  And I need and should expect H-I entries generated by my local servers to reach me, regardless of whether you put a Privacy header in or not.
If I divert the request to Dale at Avaya, then I can add my own Privacy header and my servers/service will anonymize before sending it to Avaya.

> Regarding responses, ISTM that often servers along the way want their
> identity exposed to those further downstream (e.g. the proxy for the AOR
> wanting the AOR exposed to the VM server), but may not want that stuff
> visible to the caller. That would call for anonymization of the response
> by something upstream of those things that want their identity hidden.
> To accomplish this, the UAS will have to had a Privacy header to the
> response, and there will have to be a privacy service on the path that
> will act on it.

Right, but that's what rfc3323 does/says for privacy of responses.

> I think perhaps Dale had it right, that much of this can be resolved by
> abandoning passive voice for active voice, thus forcing the
> identification of the agent for each action.

What email message was that in?  I missed it.

-hadriel