Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt

"Laganier, Julien" <julienl@qualcomm.com> Fri, 16 October 2009 15:02 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC473A6974; Fri, 16 Oct 2009 08:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.932
X-Spam-Level:
X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH3U20fDtrn1; Fri, 16 Oct 2009 08:02:07 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 347EB3A6817; Fri, 16 Oct 2009 08:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255705331; x=1287241331; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"Pasi.Eronen@nokia.com"=20<Pasi.Eronen@nokia.com>, =0D=0A=20=20=20=20=20=20=20=20"dave.cridland@isode.com" =0D=0A=09<dave.cridland@isode.com>,=0D=0A=20=20=20=20=20 =20=20=20"secdir@ietf.org"=20<secdir@ietf.org>,=20"iesg@i etf.org"=20<iesg@ietf.org>,=0D=0A=20=20=20=20=20=20=20=20 "cmadson@cisco.com"=20<cmadson@cisco.com>|Date:=20Fri,=20 16=20Oct=202009=2008:02:05=20-0700|Subject:=20RE:=20secdi r=20review=20of=20draft-ietf-ipsecme-ikev2-ipv6-config-02 .txt|Thread-Topic:=20secdir=20review=20of=20draft-ietf-ip secme-ikev2-ipv6-config-02.txt|Thread-Index:=20AcpGglvNPw IUeRb/QYqgl0FsfKOUywHzw7PgAAd6zLA=3D|Message-ID:=20<BF345 F63074F8040B58C00A186FCA57F1C2A67DF4F@NALASEXMB04.na.qual comm.com>|References:=20<15898.1254832898.040887@puncture >=0D=0A=20<808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK -EUMSG-01.mgdnok.nokia.com>|In-Reply-To:=20<808FD6E27AD48 84E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.c om>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5772"=3B=20a=3D"25402044"; bh=IadwjP7iKt+BCd5IU9rQJH87u+A0PzqVbpTXleIQ7Lo=; b=jVxLUm9beECvNhvElnhLPzMfn0hxuAALCi3o6bVX7iFCFzaJ+4ZdkMqq 3utZ9Vl0Sii9d0qjk0crAvUFM6Hbhc8fRc0KRVX9C6D+kuyr5O2iWZeN5 8q2nz/yj4s+j8RTTCXiF+yigNBYQf/BGo6odO5C6S70dqgVmGU08tvrF/ Q=;
X-IronPort-AV: E=McAfee;i="5300,2777,5772"; a="25402044"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2009 08:02:11 -0700
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GF2AWr007878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 08:02:11 -0700
Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GF289U006091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Oct 2009 08:02:08 -0700 (PDT)
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Oct 2009 08:02:07 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 16 Oct 2009 08:02:07 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>, "dave.cridland@isode.com" <dave.cridland@isode.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "cmadson@cisco.com" <cmadson@cisco.com>
Date: Fri, 16 Oct 2009 08:02:05 -0700
Thread-Topic: secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt
Thread-Index: AcpGglvNPwIUeRb/QYqgl0FsfKOUywHzw7PgAAd6zLA=
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C2A67DF4F@NALASEXMB04.na.qualcomm.com>
References: <15898.1254832898.040887@puncture> <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 16 Oct 2009 15:02:08 -0000

Pasi.Eronen wrote:
> 
> (replying as document author, not AD)
> 
> Thanks for your review, Dave!

Ditto!

> > The Security Considerations section is actually quite unclear to me -
> > at first glance, the opening phrase suggests that the solution does
> > indeed do the thing it warns against, that is, assigning each client
> > a unique, and therefore identifiable, prefix.
> 
> It indeed does this, and the paragraph should be clearer about it.
> Perhaps something like this?
> 
>    The mechanism described in this document assigns each client a
>    unique prefix, which makes using randomized interface identifiers
>    [RFC4941] ineffective from privacy point of view: the client is
>    still uniquely identified by the prefix.  [...]

Hmm. How about being more explicit about the implications, something along these lines: 

The mechanism described in this document assigns each client a unique prefix. Doing so might make the use of randomized interface identifiers [RFC4941] ineffective from privacy point of view because the client would still be uniquely identified by the prefix. However, to be able to track a client based on its prefix, one has to be aware of the fact that the client configures all of its addresses within the same prefix. [...]

Thoughts?

--julien