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

Juergen Quittek <Quittek@neclab.eu> Wed, 09 December 2015 11:55 UTC

Return-Path: <Quittek@neclab.eu>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1B6451A89B4; Wed, 9 Dec 2015 03:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CkbpVovV8WRD; Wed, 9 Dec 2015 03:55:07 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394371A878C; Wed, 9 Dec 2015 03:55:03 -0800 (PST)
Received: from localhost (localhost []) by mailer1.neclab.eu (Postfix) with ESMTP id E6D5C10B354; Wed, 9 Dec 2015 12:55:01 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([]) by localhost (atlas-a.office.hd []) (amavisd-new, port 10024) with ESMTP id 51hJZjAVsQHq; Wed, 9 Dec 2015 12:55:01 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id CC5FD10B353; Wed, 9 Dec 2015 12:54:57 +0100 (CET)
Received: from PALLENE.office.hd ([]) by ENCELADUS.office.hd ([]) with mapi id 14.03.0210.002; Wed, 9 Dec 2015 12:54:36 +0100
From: Juergen Quittek <Quittek@neclab.eu>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: IESG review of draft-ietf-pcp-third-party-id-option-04
Thread-Index: AdEyeF/Duv+0xp9hSnSAQjm0WTV0ow==
Date: Wed, 9 Dec 2015 11:54:35 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E8A9A641F7@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/iR4kpllGYTgWNkv2MXYFF1wSJ7o>
Cc: "pcp-ads@ietf.org" <pcp-ads@ietf.org>
Subject: [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 11:55:09 -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,