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

joel jaeggli <joelja@bogus.com> Tue, 17 November 2015 05:41 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C221B29E4; Mon, 16 Nov 2015 21:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.585] 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 j3XOf95YesKW; Mon, 16 Nov 2015 21:41:17 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856F61B29E3; Mon, 16 Nov 2015 21:41:14 -0800 (PST)
Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tAH5f7TY099757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2015 05:41:08 GMT (envelope-from joelja@bogus.com)
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>, 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>
References: <C0E0A32284495243BDE0AC8A066631A818F2C586@szxeml557-mbs.china.huawei.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <564ABDF3.3010107@bogus.com>
Date: Mon, 16 Nov 2015 21:41:07 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A818F2C586@szxeml557-mbs.china.huawei.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FskXA9ieGpMS9JOVuD4F9DiStoK7P26Op"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/cbp2vHfQLYB5bHOibMahsrEOJQQ>
Subject: Re: [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: Tue, 17 Nov 2015 05:41:19 -0000

On 11/10/15 8:14 PM, Tina TSOU wrote:
> 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.
> 

Thank you Tina, thank is quite useful review.

joel

> 
> 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:
> 
>> The THIRD_PARTY_ID
> 
>>    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
> 
>  
> 
> s/As/as/
> 
>  
> 
>  
> 
> Thank you,
> 
> Tina
> 
>  
>