Re: [pcp] Stephen Farrell's Discuss on draft-ietf-pcp-third-party-id-option-04: (with DISCUSS and COMMENT)

[Rolf Winter <[e-mail]>]

Hi Stephen,

please see inline:

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> Stephen Farrell has entered the following ballot position for
> draft-ietf-pcp-third-party-id-option-04: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> 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?

Because you'll need a tunnel technology specific ID. The PCP-controlled device needs to know to which tunnel this requested mapping (IP in the third party option) belongs.

We added some text to the document which hopefully makes this clearer:

The THIRD_PARTY option carries a value of an internal IP address of a
NAT map entry.  The THIRD_PARTY_ID carries a value of an internal
realm of a NAT map entry.

Upon receiving a valid request with a legal THIRD_PARTY_ID option
identifier, the message is processed as specified in [RFC6887],
except that the identifier contained in the THIRD_PARTY_ID is used in
addition when accessing a mapping table.  Instead of just using the
value contained in the THIRD_PARTY option when accessing the internal
Internet address of a mapping table, now the combination of the two
values contained in the THIRD_PARTY option and in the THIRD_PARTY_ID
option is used to access the combination of internal Internet address
and internal realm of a NAT map entry.



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

I am not sure how that would solve the overall problem. Say someone uses L2TPv3 or GRE (or any other protocol really) as the tunneling protocol, then you're bound to use IDs from those protocols. They are not linked to the PCP sessions (indeed the scenario in the draft shows that PCP messages are not even delivered over the tunnel).

Regarding authentication, we added text to the security considerations section and used normative language to mandate authenticated access to the PCP client function.

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

We added text to the security considerations section (incl. normative language).

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

We now restrict the usage of the option as defined in this document to the exact use case as described. In particular, the document now clearly states:

However, the
use of the THIRD_PARTY_ID option as specified in this document is
restricted to scenarios where the option is needed for the purpose of
uniquely identifying an internal host in addition to the information
found in the THIRD_PARTY option.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> I share the concerns relating to possible use of long term identifiers
> here and thus support the DISCUSSes from Alissa and Joel.

We have text that discusses this now in the security considerations section.

Best,

Rolf


> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp