Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt

Adam Roach <> Tue, 11 January 2011 00:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 552003A67ED; Mon, 10 Jan 2011 16:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.457
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rxHCiWBqyk8K; Mon, 10 Jan 2011 16:43:45 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 084B63A6825; Mon, 10 Jan 2011 16:43:44 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (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
Message-ID: <>
Date: Mon, 10 Jan 2011 18:45:56 -0600
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Ted Hardie <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Tue, 11 Jan 2011 08:09:42 -0800
Cc: Bernard Aboba <>, Spencer Dawkins <>, Apps Discuss <>, IESG <>
Subject: Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jan 2011 00:43:46 -0000


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

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.