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