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

[Ballot comment]
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?

[Ballot comment]

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.

[Ballot discuss]

(Emailed authors on Jan 22nd, 2nd issue may be solved, not clear
about 1st)

(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.)

(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.

[Ballot 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

[Ballot discuss]
Suresh Krishnan raised an issue in his Gen-ART review about the lack of specification for the format of identifiers. And I agree that is an issue that should be fixed. Based on recent e-mail, the authors seem to agree as well, so hopefully we can fix this.

I would also like to add that the issue is not one of mere comparison. It is a basic issue of building equipment that can interoperate, involving clients and servers and so on from multiple vendors. I have no specific suggestion for a fix, but further standardisation of the formats for typical values while leaving some room for opaque identifiers would perhaps be one avenue.

[Ballot comment]
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

[Ballot discuss]

(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.)

(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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I have a couple of questions and observations I'd like to discuss.

(1)
From Section 3:

"The scenarios serve as examples.  This document does not restrict the
  applicability of the THIRD_PARTY_ID to certain scenarios.  The
  THIRD_PARTY_ID can include any Layer-2 identifier like a MAC address
  or other subscriber identifiers as, for example, mentioned in section
  6 of [I-D.boucadair-pcp-sfc-classifier-control].  The THIRD_PARTY_ID
  can also be used for the firewall control, including the case of a
  virtual CPE, see section 3 of [I-D.lee-vhs-usecases]."

I think the document makes a reasonable case for why carrying a tunnel ID in a THIRD_PARTY_ID option is useful. I don't think it makes a reasonable case for any other use of the option, though, given the potential security and privacy issues associated with sending a potentially unique and permanent subscriber identifier. The drafts mentioned above envision much broader uses for both the option and PCP than the use case in this document, and suggest some uses of the option that seem like a mismatch for what the identifiers embedded within it were originally intended for (e.g., using an IMSI for traffic classification/policing).

Conflating these cases also makes it difficult to understand how the THIRD_PARTY_ID relates back to NAT. Presumably, a PCP-controlled NAT needs traffic on the incoming side to always include the THIRD_PARTY_ID -- otherwise, the fact that the mapping table contains the additional ID is only useful in one direction. This seems workable when the THIRD_PARTY_ID is a tunnel ID, but not for any identifier that anyone might stick in there. Again coming back to the traffic policing scenario, it seems unlikely that every time I as the subscriber send traffic through the NAT, my IMSI will be included to differentiate my traffic from another subscriber who has the same internal address as I do. So by allowing this field to contain any identifier, it becomes less obvious why PCP should be used to communicate it in the first place.

In short, I think this draft needs to either more narrowly specify a means to communicate a tunnel ID, or provide both a more thorough security and privacy analysis of the implications of sending any identifier and an explanation of the implications on the availability of those identifiers in traffic sent to a PCP-controlled NAT.

(2)
Section 5.2 seems underspecified. RFC 6887 has a lot logic riding on the
question of whether two requests are meant to identify the same host
or not (in sec 11.3 and sec 12.3) based on the combination of internal address, protocol, and port, but this draft leaves unspecified what the comparison logic is supposed to be or the error conditions that result from adding another field to the determination of whether
two hosts are the same or not. For example, is every instance of "internal address, protocol, and port" in those sections meant to be replaced with "internal address, protocol, port, and THIRD_PARTY_ID"? If a device that already has a mapping for a particular internal address, port, protocol and THIRD_PARTY_ID receives a new request for the same internal address, port, and protocol but has no THIRD_PARTY_ID, what steps is it supposed to follow? Saying that the THIRD_PARTY_ID should be "used in addition when accessing a mapping table" doesn't seem like enough detail to go implement this.

[Ballot 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pcp-third-party-id-option-04. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions that IANA must complete.

NOTE: we are assuming that these assignments should come from the "Standards Action" sections of their respective registries rather than the "Expert Review" ranges. If this is incorrect, please let us know, and we'll initiate the expert reviews.

First, in the PCP Options subregistry of the Port Control Protocol (PCP) Parameters registry located at:

http://www.iana.org/assignments/pcp-parameters/

a single new option code will be registered as follows:

Value: [ TBD-at-registration ]
Name: THIRD_PARTY_ID
Purpose: Identifies a third party for which a request for an external IP address and port is made.
Valid for Opcodes: MAP, PEER
Length: Variable, maximum 1016 octets.
May appear in: request. May appear in response only if it appeared in the associated request.
Maximum occurrences: 1
Reference: [ RFC-to-be ]

The value will be selected from the mandatory-to-process range of values of the registry.

Second, in the PCP Result Codes subregistry of the Port Control Protocol (PCP) Parameters registry located at:

http://www.iana.org/assignments/pcp-parameters/

three new result codes will be registered as follows:

Value: [ TBD-at-registration ]
Name: THIRD_PARTY_ID_UNKNOWN
Description: The provided identifier in a THIRD_PARTY_ID option is unknown/unavailable to the PCP server. This is a long lifetime error.
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Name: THIRD_PARTY_MISSING_OPTION
Description: This error occurs if both THIRD_PARTY and THIRD_PARTY_ID options are expected in a request but one option is missing. This is a long lifetime error.
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Name: UNSUPP_THIRD_PARTY_ID_LENGTH
Description: The received option length is not supported. This is a long lifetime error.
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: repenno@cisco.com, brian@innovationslab.net, pcp@ietf.org, draft-ietf-pcp-third-party-id-option@ietf.org, pcp-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PCP Third Party ID Option) to Proposed Standard


The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'PCP Third Party ID Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-11-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a new Port Control Protocol (PCP) option
  called THIRD_PARTY_ID.  It is designed to be used in combination with
  the THIRD_PARTY option specified in RFC 6887 but can also be used
  without it.  The THIRD_PARTY_ID serves to identify a Third Party in
  situations where a third party's IP address contained in the
  THIRD_PARTY option does not provide sufficient information to create
  requested mappings in a PCP-controlled device.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pcp-third-party-id-option/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pcp-third-party-id-option/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Standards Track 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  This document describes a new Port Control Protocol (PCP) option
  called THIRD_PARTY_ID.  It is designed to be used in combination with
  the THIRD_PARTY option specified in RFC 6887 but can also be used
  without it.  The THIRD_PARTY_ID serves to identify a Third Party in
  situations where a third party's IP address contained in the
  THIRD_PARTY option does not provide sufficient information to create
  requested mappings in a PCP-controlled device.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

No

Document Quality

  Are there existing implementations of the protocol?

Yes, one implementation

Have a
  significant number of vendors indicated their plan to
  implement the specification?

None besides the one implementation notes above.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Dave Thaler

If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

N/A

Personnel

  Who is the Document Shepherd?

Reinaldo Penno

Who is the Responsible Area
  Director?

Brian Haberman

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document was reviewed by the shepherd (me) and I feel it is
ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No issues

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, no IPRs

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPRs

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Broad consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No ID nits

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pcp-port-set-09.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Confirmed

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Checked ID nits, MIB and BNF are N/A