Port Control Protocol (PCP) Third-Party ID Option
draft-ietf-pcp-third-party-id-option-08

Thank you for addressing my DISCUSS points.

Major Issues:
===========
- I concur with Alissa and Joel's DISCUSS positions. I am balloting NO OBJECTION to avoid duplication; I will follow the conversations that result from those positions.

Minor Issues:
===========
- The use cases seem to require the reader to make a leap of logic to figure out how the THIRD_PARTY_ID actually gets used in the routing/mapping of user packets. (This is related to Alissa's DISCUSS comment about the mapping being under specified.)

- Figure 2: is there an assumption that the L2 tunnel to the CGN NAT is the same as or correlated with that to the UPnP IGD?

- 3.2: Is there an assumption the web application authenticates users? I assume so, since the web app needs to get the ID from somewhere.

- 4:
Putting THIRD_PARTY_ID in the "mandatory-to-process" range seems to prevent use cases where the client sends the parameter "just in case". It might be worth having some text to say it should not be included unless the client knows for a fact the NAT cannot create a mapping without it.

- 5.1:
I don't think it makes sense to allow THIRD_PARTY_ID to be used independently of THIRD_PARTY, unless you define what it means to do so. 

Editorial:
========
- Please expand "BRAS" on first mention.

The advantage of a late review is that all my points are already covered by other IESG members with their DISCUSS.

In section 5.3, prefer if more precise on the "To where to report an error is implementation dependent." Suggest "based on policy".

I have re-read Section 3 and I think I now understand better the architecture.

In Section 3.1, a tunnel ID is established, and the BRAS stores the ID in AAA. The IWF later retrieves that ID, and can then use it in any PCP requests that it makes. The same with Section 3.2, except that it is the web portal and not the IWF. 

To me this seems like the information comes from the same source: ultimately, BRAS/CGN decides tunnel IDs, data gets copied to AAA, and various entities can fetch the information from AAA and pass it along without really understanding it.

I think the level of standardisation for the format is therefore sufficient.

I do have two remaining question marks or possible concerns but I’ll leave them for your consideration. The first one is an editorial comment, that explaining how the same ID data gets passed around and used without the client having to “understand” what the contents are would be useful for Section 4.

The second one is a more technical concern. The option format as defined has just raw data. Are there deployments where *multiple* different formats might be used, and do we know if those formats might accidentally collide such that an ID that uniquely identifies a, say, L2TP tunnel, bitwise matches another ID that uniquely identifies a, say, an MPLS tunnel?

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

Thank you for addressing the SecDir reviewers comments and adding them into the next version of the draft.  

Privacy and security are definitely a concern, but the major points have been hit in Alissa and Joel's discusses, and I support their discusses and will follow the conversation.

I had a discuss ballot on this, now clearing, as per below...

(1) The THIRD_PARTY stuff in PCP was always a bit concerning
from a security point of view. RFC 6887 says that you MUST NOT
implement or use that except in some specific environments. At
the time we would have liked to say that you MUST use PCP
authentication when using that but RFC 7652 wasn't done until
some time later. My DISCUSS question though is: why can't you
distinguish based on a Key ID used with PCP authentication?
Wouldn't that help with the privacy concerns (one can manage
Key IDs well if one wants) and also with the secrity concerns,
and I would guess it should solve the tunnel issues that this
is intended to address as well? (There may be good reasons why
that doesn't work of course, but I'd like to understand them.)

Jan 27:
It turns out that using PCP authentication to do this is
not a good idea - the use-cases in question have the same
PCP client and server acting for many third parties, so it'd
not be a good plan to try handle the third party id via PCP
authentication keying.

However, the document probably still should at least say
when to use PCP authentication, at present it doesn't
refer to that RFC at all.

(2) Section 7: The "must be fully trusted" phrase is not a good
one to use - iirc that was a compromise figured out to allow
PCP to proceed ahead of the PCP auth spec.  And of course, it's
really a nonsense. I think you should properly characterise the
issues or else delete the unfortunate phrase. I also think you
should not encourage the use of this for carrying location or
profile information.  What "Means" exist that could be used to
really protect this? And why do you want to "protect
unauthorized access"? that's oddly phrased at best. All in all
I think you need better text for section 7, and I'm happy to
try help find that.

Jan 27:
The authors have changed the wording. I'm still not keen
that there are so many SHOULD statements, and would
argue that it'd be better saying that this option MUST NOT
be sent outside one operator network. I hope that'll be
resolved via Alissa's discuss point and others though.

I (still) share the concerns relating to possible use of long
term identifiers here and thus support the DISCUSSes from
Alissa and Joel.