[pcp] Joel Jaeggli's No Objection on draft-ietf-pcp-third-party-id-option-04: (with COMMENT)
"Joel Jaeggli" <joelja@bogus.com> Sun, 22 November 2015 21:13 UTC
Return-Path: <joelja@bogus.com>
X-Original-To: pcp@ietf.org
Delivered-To: pcp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 546721B3541; Sun, 22 Nov 2015 13:13:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Joel Jaeggli <joelja@bogus.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151122211301.12476.85911.idtracker@ietfa.amsl.com>
Date: Sun, 22 Nov 2015 13:13:01 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/dLloSJVX9wgCJKaaFHlHMm3qN1Q>
Cc: pcp@ietf.org, draft-ietf-pcp-third-party-id-option@ietf.org, pcp-chairs@ietf.org
Subject: [pcp] Joel Jaeggli's No Objection on draft-ietf-pcp-third-party-id-option-04: (with COMMENT)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Nov 2015 21:13:01 -0000
Joel Jaeggli has entered the following ballot position for draft-ietf-pcp-third-party-id-option-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pcp-third-party-id-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am satisfied that the proposed way forward will resolve my discuss. thanks Brian and Juergen. former discuss I see the secdir reviewer has raised this issue as well, but from my vantage point the issue of is slightly different. the use of the mac address or alternatively a different third party identifier is underspecified. What's the purpose of using a stable identifier except to facilitate tracking? if that's the case then it should be a spelled out, a pcp interworking function could use basically anything to distinguish between two hosts when requesting a mapping, e.g. the mapping is bound to ip addresses. Extending the the option to applications outside of the L2 domain (as described in section 3) proposes to extended the use of this mac based identifier still further, which seems like an opportunity for information leakage outside the scope of the L2 domain, when ephemeral or session based identifiers might be more appropriate. the ops dir review was done by tim chown Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The draft introduces a new Port Control Protocol (PCP) option, THIRD_PARTY_ID, which is designed to allow identification of a Third Party where that party’s IP address alone does not provide sufficient information to create required mappings in a PCP-controlled device. A scenario for this would be where a CGN is in use, and private IP address ranges used at different subscribers may overlap. My overall view is that this draft is Not Ready. The main concern I have with the draft is the somewhat obvious potential for privacy-related information to be exposed/leak, especially given the draft hints that the approach may be used more broadly. The need for a way to disambiguate between devices with the same IP address information is, however, well made. If the draft moves forward, I would personally like to see it nail down a very specific use of this option, using a differentiator that minimises privacy implications, which might mean a (non persistent?) tunnel ID (which is available in both scenarios presented in the draft). Using MAC addresses, even with the prospect of these changing over time in the future (due to existing privacy concerns over them), seems inappropriate and unnecessary. Is there a specific justification here? Indeed, if/when they do start changing over time more frequently, any differentiation based on them may then break anyway. I suspect this has been discussed (perhaps at length!) in the WG, but if the authors wish to progress broader usage, this should be very carefully justified in the text. The option as defined has no field defining the property on which the ID is generated. That may be intentional, in that any agreed property could be used. But on the scenarios presented in the draft, a tunnel ID seems commonly available. Regardless, the Security Considerations section is insufficient - it also mentions location or profile information (what type of location information?), but not issues with MAC addresses. Finally, I would assume this draft would not be needed in an IPv6 deployment, as hosts would then have unique IP addresses within the THIRD_PARTY option. Should the draft specifically say this is IPv4-only work (which is quite rare now in the IETF), or is there any scenario in which this would be used with IPv6? Best wishes, Tim
- [pcp] Joel Jaeggli's No Objection on draft-ietf-p… Joel Jaeggli