Re: [ipwave] Alissa Cooper's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Nabil Benamar <[e-mail]>]

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."

On Thu, Jul 11, 2019 at 2:52 PM Alissa Cooper <[e-mail]> wrote:

> Hi Nabil,
>
> On Jul 10, 2019, at 4:57 PM, Nabil Benamar <[e-mail]>
> 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 <
> [e-mail]> 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