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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 November 2015 11:04 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 438371A9071; Tue, 17 Nov 2015 03:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.286
X-Spam-Level:
X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-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 8SXXp9Qfcvh2; Tue, 17 Nov 2015 03:04:13 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A89C1A8871; Tue, 17 Nov 2015 03:04:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DA8F0BE58; Tue, 17 Nov 2015 11:04:10 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zd_VsdfS78o; Tue, 17 Nov 2015 11:04:10 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3A3BDBE4D; Tue, 17 Nov 2015 11:04:08 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447758248; bh=iiylr7TYe/ltY2cKUOUFyy7lkH7VmsSIkOz2bY4glaQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JjnuqXPYdZp+M8ImLdo9WvYhdyRem/NN0KaQ+jp0Lgl9t11dCJNxa+BBGm4aefZdy zF/6R/GZDYUCILAJsX697b6K40NCq2mxPS2kq3XMHYKsGR7JaqvKyftalR5fTTqxvF k2ye8ZEATrNkUbxWo413Q7kaWepRAhpDWGTVnsKQ=
To: Juergen Quittek <Quittek@neclab.eu>, 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> <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F2C31@PALLENE.office.hd>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <564B09A7.50904@cs.tcd.ie>
Date: Tue, 17 Nov 2015 11:04:07 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F2C31@PALLENE.office.hd>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/lYbie7mlDiets2Urb5y5K7_atc4>
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 11:04:16 -0000

Hi Juergen,

(Caveat: I've yet to read this, but I have a question nonetheless:-)

On 17/11/15 10:58, Juergen Quittek wrote:
> Dear Tina,
> Thank you very much for your thorough review.
> Please find replies inline.
> 
>> -----Original Message-----
>> From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
>> Sent: Mittwoch, 11. November 2015 05:14
>> To: The IESG; secdir@ietf.org; draft-ietf-pcp-third-party-id-option.all@ietf.org
>> Subject: Secdir Review of draft-ietf-pcp-third-party-id-option-04
>>
>> 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.
> 
> Here is a proposal for improving this section:
> OLD
>    As this option is related to the use of the THIRD_PARTY option the
>    corresponding security considerations in Section 18.1.1 of RFC 6887
>    [RFC6887] apply.  Especially, the network on which the PCP messages
>    are sent must be fully trusted.  The THIRD_PARTY_ID option might
>    carry privacy information like location or profile information.
>    Means to protect unauthorized access to this information should be
>    put in place.
> NEW
>    As this option is related to the use of the THIRD_PARTY option the
>    corresponding security considerations in Section 18.1.1 of RFC 6887
>    [RFC6887] apply.  Especially, the network on which the PCP messages
>    are sent must be fully trusted.  The THIRD_PARTY_ID option might
>    carry privacy sensitive information like location or profile information. 
>    Where possible, randomly assigned numbers should be preferred to 
>    privacy sensitive information to be carried as values by the 
>    THIRD_PARTY_ID option. Random numbers should be assigned such 
>    That an attacker cannot guess which number is assigned to which 
>    third party. Anyway, means to protect unauthorized access to 
>    values carried by the THIRD_PARTY_ID option should be put in place.
> END
> Would this address your concerns?

Can you say why the value ever needs to be a long lived identifier
and why a random number that changes periodically isn't always good
enough?

Ta,
S.


> 
>>
>> ** 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.
> 
> In the past, the RFC Editor used to remove occurrences of "and/or" in RFCs. 
> What about the following alternative, which is semantically equivalent to and/or: 
> "such as a network address translator (NAT), a firewall, or a combination of both"?
> 
>>
>> * 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/
> 
> Agreed.
> 
>>
>> (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."
> 
> Agreed.
> 
>>
>> * Section 1, page 3:
>>> CGN deployments
>>
>> Please expand the acronym on first usage.
> 
> Agreed.
> 
>>
>> * 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).
> 
> Agreed.
> 
>>
>> * 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?
> 
> Here is a proposal that addresses your issue:
> OLD
>    This applies to some of the PCP deployment scenarios that are listed 
>    in Section 2.1 of RFC 6887 [RFC6887], 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]. 
> NEW
>    This applies to some of the PCP deployment scenarios that are listed
>    in Section 2.1 of [RFC6887], in particular to a Layer-2 aware NAT
>    which is described in more detail in Section 3, as well as in other
>    scenarios where overlapping address spaces occur like in [RFC6674] or
>    [RFC6619].
> END
> Would this solve your issue?
> 
>>
>> * 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)
> 
> Agreed.
> 
>>
>> * Section 3, page 4:
>>> The THIRD_PARTY_ID
>>>    can also be used for the firewall control
>>
>> Please remove the "the".
> 
> Agreed.
> 
>>
>> * Section 3.2, page 7:
>>> tunnel ID of tunnel(BRAS, CGN)
>>
>> (two instances of this). Please rephrase as "ID of the tunnel (BRAS, CGN)".
> 
> Agreed.
> 
>>
>> * Section 4, page 9:
>> Why use "TBD" and "TBD-1" if there's a single value to be assigned?
> 
> There was no space for "-1" in the figure. All other TBDs are numbered as "TBD-X". We will make sure that the RFC Editor gets the right message.
> 
>>
>> * Section 4, page 9:
>>> are to be set As
>>
>> s/As/as/
> 
> Agreed.
> 
> Thanks and best regards,
>     Juergen
> 
> 
>>
>> Thank you,
>>
>> Tina
>>
>>
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>