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

[Alissa Cooper <[e-mail]>]

Hi Nabil,

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