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

Hi Med,

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Sent: Mittwoch, 9. Dezember 2015 13:59
> To: Juergen Quittek; pcp@ietf.org
> Cc: pcp-ads@ietf.org
> 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

> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : pcp [mailto:pcp-bounces@ietf.org] De la part de Juergen Quittek
> > Envoyé : mercredi 9 décembre 2015 12:55
> > À : pcp@ietf.org
> > Cc : pcp-ads@ietf.org
> > 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.
> >
> > 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
> >
> > _______________________________________________
> > pcp mailing list
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp