Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt
Adam Roach <adam@nostrum.com> Tue, 11 January 2011 00:43 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552003A67ED; Mon, 10 Jan 2011 16:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.457
X-Spam-Level:
X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001, 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 rxHCiWBqyk8K; Mon, 10 Jan 2011 16:43:45 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 084B63A6825; Mon, 10 Jan 2011 16:43:44 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0B0jvW9019554 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 18:45:57 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D2BA844.1070801@nostrum.com>
Date: Mon, 10 Jan 2011 18:45:56 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <AANLkTi=pF9d0z3vQYAq+mPrpSiDK9OZzVPkE84W+-qGp@mail.gmail.com>
In-Reply-To: <AANLkTi=pF9d0z3vQYAq+mPrpSiDK9OZzVPkE84W+-qGp@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Tue, 11 Jan 2011 08:09:42 -0800
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, Spencer Dawkins <spencer@wonderhamster.org>, Apps Discuss <discuss@ietf.org>, IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2011 00:43:46 -0000
Ted: Thank you for your detailed review. I have applied your comments to version -11 of the document (now available in the repository), except as noted below. On 11/30/10 4:11 PM, Ted Hardie wrote: > Section 7.4 contains two elements which it may be appropriate to consider > for inclusion in the Security Considerations. The first of these is that > proxies will not be able to apply policy decisions on as granular a basis as > before: > > Proxies will be unable to make policy decisions on a > contact-by-contact basis regarding whether to include themselves in > the path. Second, and similarly, all AORs on the SIP-PBX that are > registered with a common REGISTER request will be forced to share a > common Service-Route. I tried to reiterate this issue in the security section with the following paragraph: As noted in Section 7.4, intermediaries need to take care if they use a policy token in the Path and Service-Route mechanisms, as doing so will cause them to apply the same policy to all users serviced by the same SIP-PBX. This may frequently be the correct behavior, but circumstances can arise in which differentiation of user policy is required. This text was in the version you reviewed. Do you think it needs to be amended in some way to capture the issue you highlight above, or does this text address your concern? > Would this extend to proxies including themselves for the purposes of > CALEA? If so, this might be a privacy issue. Proxies can't use Path to insert themselves for LI purposes, as doing so would be inherently visible to user agents (which could potentially alert users to the condition). In my experience, LI in SIP is performed via mechanisms that are unrelated to any of the mechanisms described in this document. /a