Last Call Review of draft-ietf-pcp-third-party-id-option-03
review-ietf-pcp-third-party-id-option-03-opsdir-lc-chown-2015-11-19-00

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