[secdir] Secdir Review of draft-ietf-pcp-third-party-id-option-04

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Wed, 11 November 2015 04:14 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 389231B47D3; Tue, 10 Nov 2015 20:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 fP5y_pA1mcjH; Tue, 10 Nov 2015 20:14:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893481B47CF; Tue, 10 Nov 2015 20:14:36 -0800 (PST)
Received: from (EHLO lhreml404-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAE28694; Wed, 11 Nov 2015 04:14:34 +0000 (GMT)
Received: from SZXEML429-HUB.china.huawei.com ( by lhreml404-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 11 Nov 2015 04:14:34 +0000
Received: from szxeml557-mbs.china.huawei.com ([]) by SZXEML429-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Wed, 11 Nov 2015 12:14:03 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pcp-third-party-id-option.all@ietf.org" <draft-ietf-pcp-third-party-id-option.all@ietf.org>
Thread-Topic: Secdir Review of draft-ietf-pcp-third-party-id-option-04
Thread-Index: AdEcN2Zzfw6PDcwVTluSTfgPI5/0vw==
Date: Wed, 11 Nov 2015 04:14:03 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A818F2C586@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A818F2C586szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5642C0AA.00F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 684fa502a8131d3a1b5552d9e1301a5e
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/NklyZn_e_XytkpZZxBDk9iX3GHA>
Subject: [secdir] Secdir Review of draft-ietf-pcp-third-party-id-option-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 04:14:40 -0000

Dear all,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

** Technical **

* Section 7, page 11:

I think you should make comments regarding the (privacy) implications of employing identifiers such as MAC addresses when essentially any other value -- e.g. a long-enough random number would do.

Besides, you should comment on how the ID can be somehow validated, and what could happen if a client were able to predict the ID employed by other clients.

** Editorial **

* Section 1, page 2:

>    The IETF has specified the Port Control Protocol (PCP) [RFC6887] to

>    control how packets are translated and forwarded by a PCP-controlled

>    device such as a network address translator (NAT) or firewall.

Please replace "and" with "and/or", since a firewall will not translate packets.

* Section 1, page 2:

>    This document focuses on the scenarios where the PCP client sends

>    requests that concern internal addresses other than the address of

>    the PCP client itself.

s/the scenarios/scenarios/

(since at least at this point in the text you have not yet mentioned what those scenarios are about)

* Section 1, page 2:

>    There is already an option defined for this purpose in the RFC 6887

>    [RFC6887] called the THIRD_PARTY option.

Please rephrase as:

"There is already an option defined for this purpose in [RFC6887], called the THIRD_PARTY option."

* Section 1, page 3:

> CGN deployments

Please expand the acronym on first usage.

* Section 1, page 3:

>    This applies to some of the PCP deployment scenarios that are listed

>    in Section 2.1 of RFC 6887 [RFC6887],

Just remove "RFC 6887" (the rfc number is already included by the ref).

* Section 1, page 3:

>    in particular to a Layer-2

>    aware NAT which is described in more detail in Section 3, or GI-DS-

>    Lite [RFC6674] and ds-extra-lite [RFC6619].

You refer to RFC6619 as "ds-extra-lite", but such RFC does not even

include that term. Thoughts?

* Section 3, page 4:

>   The scenarios serve as examples.  This document does not restrict the

>    applicability of the THIRD_PARTY_ID to certain scenarios.

Please replace "THIRD_PARTY_ID" with "THIRD_PARTY_ID option" (here, and

in other places)

* Section 3, page 4:


>    can also be used for the firewall control

Please remove the "the".

* Section 3.2, page 7:

> tunnel ID of tunnel(BRAS, CGN)

(two instances of this). Please rephrase as "ID of the tunnel (BRAS, CGN)".

* Section 4, page 9:

Why use "TBD" and "TBD-1" if there's a single value to be assigned?

* Section 4, page 9:

> are to be set As


Thank you,