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

<mohamed.boucadair@orange.com> Wed, 09 December 2015 12:59 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076D61A90AB; Wed, 9 Dec 2015 04:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-mAmgiKSLRQ; Wed, 9 Dec 2015 04:59:28 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373E51A90A8; Wed, 9 Dec 2015 04:59:28 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id E26833B48A2; Wed, 9 Dec 2015 13:59:26 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm05.si.francetelecom.fr (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: <mohamed.boucadair@orange.com>
To: Juergen Quittek <Quittek@neclab.eu>, "pcp@ietf.org" <pcp@ietf.org>
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: <9AB93E4127C26F4BA7829DEFDCE5A6E8A9A641F7@PALLENE.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8A9A641F7@PALLENE.office.hd>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.12.9.104515
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/txKM-4lPMA7Vb-FkHovsDW6hPLY>
Cc: "pcp-ads@ietf.org" <pcp-ads@ietf.org>
Subject: Re: [pcp] IESG review of draft-ietf-pcp-third-party-id-option-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=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.

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