Subject: [pcp] IESG review of draft-ietf-pcp-third-party-id-option-04

From: Juergen Quittek <[email-masked]>
Date: Wed, 9 Dec 2015 11:54:35 +0000

Dear all,

At the IESG telechat on Nov 19 the IESG discussed draft-ietf-pcp-third-party-id-option-04. The ISG raised two main concerns:

1. The draft elaborates use cases where the proposed THIRD_PARTY_ID option is used for carrying an identifier of a tunnel and where it is used in addition to the THIRD_PARTY option that contains the IP address of a third party host. Beyond these use cases, the draft also refers to other protential use cases without elaborating them. The IESG has concerns about opening the THIRD_PARTY_ID option to unspecified use cases, because the implications cannot be foreseen. Particularly security concerns are difficult to address if it is not clear how sensitive information carried by THIRD_PARTY_ID option could be.

2. In light of point one, the IESG request further elaboration of the security considerations.

As potential solution of the issue it was discussed at the IESG telechat to 
- restrict the use of the THIRD_PARTY_ID option in the draft to carrying tunnel IDs only
- add a statement that for using the THIRS_PARTY_ID option for other use cases, a standards document would be needed that specifies this usage.

The authors would be fine with updating the draft following these recommendations. A restriction to tunnel IDs only would also be a good starting point for addressing the security concerns raised by the IESG.

Would people on this list have any concerns about implementing this solution in the next update o the draft?

Best regards,
    Juergen

---

From: <[email-masked]>
Date: Wed, 9 Dec 2015 12:59:25 +0000

Hi Juergen, 

What are the security implications of a PCP client that inserts an information that is required to the PCP server to enforce its policies (e.g., per-subscriber quota) while both the PCP client and the PCP server belong to the same administrative entity and the network in-between is trusted? 

I see THIRD_PARTY_ID as an extra information that can be communicated to the PCP server in cases where the source IP address and the content of THIRD_PARTY are not sufficient to demux connections or to select which policy to enforce when receiving a PCP request. The actual ID to be carried in a THIRD_PARTY_ID is really deployment-specific (e.g., it ca be a MAC@ for L2-aware NAT, an interface ID, Context ID for RFC6674, etc.). If you define a tunnel-ID as such then I'm in full agreement.

Cheers,
Med

> -----Message d'origine-----
> De : pcp [mailto:[email-masked]] De la part de Juergen Quittek
> Envoyé : mercredi 9 décembre 2015 12:55
> À : [email-masked]
> Cc : [email-masked]
> Objet : [pcp] IESG review of draft-ietf-pcp-third-party-id-option-04
> 
> Dear all,
> 
> At the IESG telechat on Nov 19 the IESG discussed draft-ietf-pcp-third-
> party-id-option-04. The ISG raised two main concerns:
> 
> 1. The draft elaborates use cases where the proposed THIRD_PARTY_ID option
> is used for carrying an identifier of a tunnel and where it is used in
> addition to the THIRD_PARTY option that contains the IP address of a third
> party host. Beyond these use cases, the draft also refers to other
> protential use cases without elaborating them. The IESG has concerns about
> opening the THIRD_PARTY_ID option to unspecified use cases, because the
> implications cannot be foreseen. Particularly security concerns are
> difficult to address if it is not clear how sensitive information carried
> by THIRD_PARTY_ID option could be.
> 
> - add a statement that for using the THIRS_PARTY_ID option for other use
> cases, a standards document would be needed that specifies this usage.
> 
> The authors would be fine with updating the draft following these
> recommendations. A restriction to tunnel IDs only would also be a good
> starting point for addressing the security concerns raised by the IESG.
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 11 Dec 2015 17:58:14 +0000

Hi Med,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Mittwoch, 9. Dezember 2015 13:59
> To: Juergen Quittek; [email-masked]
> Cc: [email-masked]
> Subject: RE: IESG review of draft-ietf-pcp-third-party-id-option-04
> 
> Hi Juergen,
> 
> What are the security implications of a PCP client that inserts an information
> that is required to the PCP server to enforce its policies (e.g., per-subscriber
> quota) while both the PCP client and the PCP server belong to the same
> administrative entity and the network in-between is trusted?

What I understand from the security ADs is that any potential risk 
introduced by the option needs to be discussed. It is not enough to say: 
please use it only if sufficiently protected. We also need to state 
what the risks would be if protection was less than optimal.
 
> I see THIRD_PARTY_ID as an extra information that can be communicated to
> the PCP server in cases where the source IP address and the content of
> THIRD_PARTY are not sufficient to demux connections or to select which policy
> to enforce when receiving a PCP request. The actual ID to be carried in a
> THIRD_PARTY_ID is really deployment-specific (e.g., it ca be a MAC@ for L2-
> aware NAT, an interface ID, Context ID for RFC6674, etc.). If you define a
> tunnel-ID as such then I'm in full agreement.

I am afraid that we have to be more specific than this. We also need to specify 
the encoding of tunnel IDs as payload of the THIRD_PARTY_ID option.

Cheers,
    Juergen