Re: [sipcore] Understanding Privacy: history invoked by UAS

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 11 November 2010 07:58 UTC

Return-Path: <dworley@avaya.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 AADBF3A6920 for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 23:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.372
X-Spam-Level:
X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, 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 dP+Uv2GdlzTD for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 23:58:59 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D142D3A691E for <sipcore@ietf.org>; Wed, 10 Nov 2010 23:58:58 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANgw20yHCzI1/2dsb2JhbACiP3GmPwKZJIJyglgEhFqJIw
X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="249539551"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Nov 2010 02:59:27 -0500
X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="536709267"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Nov 2010 02:59:27 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 11 Nov 2010 02:59:27 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 11 Nov 2010 02:57:03 -0500
Thread-Topic: Understanding Privacy: history invoked by UAS
Thread-Index: Act/tmX64nFBhz6FSZe0YJ2Va+pn3QBv6FJK
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288A04@DC-US1MBEX4.global.avaya.com>
References: <A444A0F8084434499206E78C106220CA02357ADA69@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA02357ADA69@MCHP058A.global-ad.net>
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
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: Thu, 11 Nov 2010 07:58:59 -0000

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Elwell, John [john.elwell@siemens-enterprise.com]

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

Actually, D isn't really the center of this.  If D's user wants to prevent his AOR (C) from being disclosed, he will have to make an arrangement with the home proxy for C.  The home proxy can add "Privacy: history" to any 4xx response it generates for requests to C.  Indeed, it will probably add "Privacy: history" to requests or responses to C even when D is registered.

Dale