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

<> Wed, 09 December 2015 12:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 076D61A90AB; Wed, 9 Dec 2015 04:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-mAmgiKSLRQ; Wed, 9 Dec 2015 04:59:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 373E51A90A8; Wed, 9 Dec 2015 04:59:28 -0800 (PST)
Received: from (unknown [xx.xx.xx.1]) by (ESMTP service) with ESMTP id E26833B48A2; Wed, 9 Dec 2015 13:59:26 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id A90CF35C061; Wed, 9 Dec 2015 13:59:26 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0248.002; Wed, 9 Dec 2015 13:59:26 +0100
From: <>
To: Juergen Quittek <>, "" <>
Thread-Topic: IESG review of draft-ietf-pcp-third-party-id-option-04
Thread-Index: AdEyeF/Duv+0xp9hSnSAQjm0WTV0owABw9Hw
Date: Wed, 9 Dec 2015 12:59:25 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008CB2CC6@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.12.9.104515
Archived-At: <>
Cc: "" <>
Subject: Re: [pcp] IESG review of draft-ietf-pcp-third-party-id-option-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2015 12:59:30 -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.


> -----Message d'origine-----
> De : pcp [] De la part de Juergen Quittek
> Envoyé : mercredi 9 décembre 2015 12:55
> À :
> Cc :
> 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