Re: [ipwave] Alissa Cooper's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
Nabil Benamar <n.benamar@est.umi.ac.ma> Wed, 17 July 2019 20:43 UTC
Return-Path: <n.benamar@est.umi.ac.ma>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D1120154 for <its@ietfa.amsl.com>; Wed, 17 Jul 2019 13:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=est-umi-ac-ma.20150623.gappssmtp.com
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 EcRo3PsBnaz2 for <its@ietfa.amsl.com>; Wed, 17 Jul 2019 13:43:14 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3204A12010F for <its@ietf.org>; Wed, 17 Jul 2019 13:43:10 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id h6so47911901iom.7 for <its@ietf.org>; Wed, 17 Jul 2019 13:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=73lBR03rB7JlDvZVWJ9tcm+CisFxqfN4SEekWQQjfN4=; b=ZxoGPzNrPDWEt+LJKCOxG5QtgfAAppT5fXezsjGlpRFH92SnyCf9zJ4zYaFneTYXKu ThjMmqTpqE/NbTGCUnloG215c0CXxqZCJJG1bzdBd1dMPjGbOK893O7nk8uNnvP0jrVo 6xqcn/xEwhWroSlPHLYrG+IyK4obeGYxJkR9sxNRASROE75vkEfHBEV3Z77H4T42Jso9 3U4uLArKakNULcWQg8DRgX2AjFbbZ95xYXafUFeHoneQr28lT1MTxlhuBfHOvPnxF6eo Dv87xc6N/eflq7+ZbXYU9cVZMB2ni5JlVLag8WqH2mwzmXB1gMWYu1I9hYuTx40ONkEP SUgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=73lBR03rB7JlDvZVWJ9tcm+CisFxqfN4SEekWQQjfN4=; b=endwm6p00iSnM2vlwSCsZjt+Z2baoN/Mnlz2MhlyJrLDhXcmQ9k2H7Dk66MpOw6vMl etMN6Oyb1Lj879X0iGLFKEerl8WCrIBHQP7CK9UmcnNj+wxpObss0c/HYGLUoMjqC/u1 Lov7c2OLslv8QaUBan2h31hLWgTTRQNpW+AZSc6O4b9CxjzzyO4zZKCYNGgQdvuKTjs/ I5ivxZYs7q08vSvVbTbF7NEN+w1HSkLeBSfCJ2mf9CA6MfL5dTh1AReVSHriItSOqePQ Yz9WBNePGmlRiaj6adNeD8GV4S+z5UavFniJ2iTORroIWOCJA8YPcQ8f9lqSe4gI0ijE uX4Q==
X-Gm-Message-State: APjAAAW195yJguXdDayLLqSZFTjVVvJCNRUxqmTjMzsxm71QoBzaogD6 GFiSpe0WoHrk99l518LO3iswEwTqC+Lqga5JhXaOkA==
X-Google-Smtp-Source: APXvYqw5Pwr7N2rb4QoTvpAiRvRJXptWu2EM8OnhtI8AC9i/tfqs8p6MUpfQpKpfhRBePGwuFum03Cz2WvlIdaJ+oDY=
X-Received: by 2002:a02:bb05:: with SMTP id y5mr42358899jan.93.1563396188538; Wed, 17 Jul 2019 13:43:08 -0700 (PDT)
MIME-Version: 1.0
References: <156278324219.15531.9469512400534766331.idtracker@ietfa.amsl.com> <CAD8vqFf5nQk+BWfoOnR9p5JHMfWf1fj1FCtAkJzgiDnFrz+Mqg@mail.gmail.com> <2CFE579C-7625-4875-AD4A-D5C26814287D@cooperw.in> <CAD8vqFf2XUuLbjszGZG8zcmMsv13iamKMiDQwgQXs4BvxL7D2A@mail.gmail.com> <E6EB1138-D8D0-4E20-A800-2AEAF42BEAB8@cooperw.in>
In-Reply-To: <E6EB1138-D8D0-4E20-A800-2AEAF42BEAB8@cooperw.in>
From: Nabil Benamar <n.benamar@est.umi.ac.ma>
Date: Wed, 17 Jul 2019 21:42:57 +0100
Message-ID: <CAD8vqFc-5_q-_bR7Zt8WhdDae9_s58-K_kTiTXiZrTtyajXa0w@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Carlos Bernardos <cjbc@it.uc3m.es>, ipwave-chairs@ietf.org, its <its@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000764053058de68a1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/YnwNh6kmI9Te0qu-Psu2UcK2_E8>
Subject: Re: [ipwave] Alissa Cooper's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2019 20:43:17 -0000
Hi Alissa, Thank you for your reply. What do you think of adding the following paragraph: However, there are some specificities related to vehicles. Since roaming is an important characteristic of vehicles, the use of the same Link-Local Address over time can indicate the presence of the same vehicle in different places and thus leads to location tracking. Hence, a vehicle should get hints about a change of environment (e.g. , engine running, GPS, etc..) and renew the IID in its LLAs. On Wed, Jul 17, 2019 at 7:20 PM Alissa Cooper <alissa@cooperw.in> wrote: > Hi Nabil, > > On Jul 11, 2019, at 10:25 AM, Nabil Benamar <n.benamar@est.umi.ac.ma> > wrote: > > Hi Alissa, > > Are you referring to this text that may be added to the document? > > > "However, there are some specificities related to vehicles. Since they > roam a lot, the use of the same Link-Local Address over time can leak the > presence of the same vehicle in multiple places. Location tracking, if > the same interface identifier is used with different prefixes as a > device/vehicle moves between different networks.” > > > That was part of it. I think this was the full text: > > "However, there are some specificities related to vehicles. Since they > roam a lot, the use of a same Link Local Address over time can leak the > presence of the same vehicle in multiple places. Location tracking, if > the same interface identifier is used with different prefixes as a > device/vehicle moves between different networks. > > > Hence, a vehicle should get hints about a change of environment (e.g. , > engine running, GPS, whatever) and renew the IID in LLAs. > > > > I can make these proposed changes in a separate sub-section to emphasize > the concern and fix the privacy issue." > I think to the extent there are hints the vehicle would use to trigger a > refresh of the IID, that idea is worth mentioning. > > Thanks, > Alissa > > > On Thu, Jul 11, 2019 at 2:52 PM Alissa Cooper <alissa@cooperw.in> wrote: > >> Hi Nabil, >> >> On Jul 10, 2019, at 4:57 PM, Nabil Benamar <n.benamar@est.umi.ac.ma> >> wrote: >> >> Hi Alissa, >> >> Thanks again for your review. Please see my answers below >> >> >> On Wed, Jul 10, 2019 at 7:27 PM Alissa Cooper via Datatracker < >> noreply@ietf.org> wrote: >> >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I support Roman's DISCUSS. >>> >>> Overall I am unclear on the privacy properties of what this document >>> specifies. >>> I think it would help to have a clear statement about the circumstances >>> under >>> which each kind of address generation scheme is recommended. Were RFC >>> 4941 >>> addresses not considered because addresses generated according to RFC >>> 8064 have >>> functionally equivalent properties given how often moving vehicle change >>> subnets? For link-local addresses, is it possible to give >>> recommendations for >>> when IIDs should be re-generated? >>> >>> Here is the new text in -49 >> >> An example of change policy is to change the MAC >> address of the OCB interface each time the system boots up. This may >> help mitigate privacy risks to a certain level. Futhermore, for >> pricavy concerns ([RFC8065 <https://tools.ietf.org/html/rfc8065>]) recommends using an address generation >> scheme rather than addresses generated from a fixed link-layer >> >> address. >> >> >> I saw this when I read the document but it doesn’t address my questions >> above. Also in your email to Roni you mentioned other environmental factors >> that might trigger a change in link-local address, so I was hoping to see >> that in the document text. >> >> Thanks, >> Alissa >> >> >> >>> = Section 5.2 = >>> >>> "An Interface ID SHOULD be of length specified in other documents." >>> >>> Isn't the length specified for each of the two IID generation mechanisms >>> discussed in Section 4.3 and 4.4? >>> >> >> We decided to remove this sentence from the text since ther is no other >> document. >> >>> >>> = Section 5.3 = >>> >>> "The demand for privacy protection of vehicles' and drivers' >>> identities, which could be granted by using a pseudonym or alias >>> identity at the same time, may hamper the required confidentiality of >>> messages and trust between participants" >>> >>> Pseudonymity and confidentiality are not mutually exclusive, so I think >>> this is >>> incorrect. >>> >> >> I agree. >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Please expand OCB and STA on first use. >>> >>> = Section 2 = >>> >>> "Note: compliance with >>> standards and regulations set in different countries when using the >>> 5.9GHz frequency band is required." >>> >>> I'm not familiar with the standards and regulations being referenced >>> here, but >>> is there any specific reason why this needs to be said here? Presumably >>> users >>> of regulated spectrum bands the world over must comply with associated >>> regulations governing their use. It's not clear to me that it makes >>> sense to >>> note this here. >>> >>> = Section 5.1.1 = >>> >>> "Further >>> correlation of this information with other data captured by other >>> means, or other visual information (car color, others) MAY constitute >>> privacy risks." >>> >>> The normative MAY is not appropriate here. >>> >>> = Section 5.2 = >>> >>> "In 802.11-OCB networks, the MAC addresses MAY change during well >>> defined renumbering events." >>> >>> The normative MAY is not appropriate here (since this is not the >>> 802.11-OCB >>> spec). >>> >>> >>> >> >> -- >> >> Best Regards >> >> Nabil Benamar >> Associate Professor >> Department of Computer Sciences >> School of Technology >> Moulay Ismail University >> Meknes. Morocco >> >> >> > > -- > > Best Regards > > Nabil Benamar > Associate Professor > Department of Computer Sciences > School of Technology > Moulay Ismail University > Meknes. Morocco > > > > -- Best Regards Nabil Benamar Associate Professor Department of Computer Sciences School of Technology Moulay Ismail University Meknes. Morocco
- [ipwave] Alissa Cooper's Discuss on draft-ietf-ip… Alissa Cooper via Datatracker
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Nabil Benamar
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Alissa Cooper
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Nabil Benamar
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Alexandre Petrescu
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Alexandre Petrescu
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Alexandre Petrescu
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Alissa Cooper
- Re: [ipwave] Alissa Cooper's Discuss on draft-iet… Nabil Benamar