[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