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

[Alexandre Petrescu <[e-mail]>]

Le 11/07/2019 à 16:25, Nabil Benamar a écrit :
> 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."

Expressing the need of change of Link-local Address of an OCB interface
of an automobile in order to ensure privacy should be accompanied with
expressing the need of keeping Link-local Address stable next-hop of
routing table entry in nearby automobile.

The routing works like this: an Automobile holds a routing table entry
whose next-hop field contains the link-local address of the nearby
Automobile.  If that link-local address changes, then the two
Automobiles can no longer talk to each other.

So yes, change the LL address to ensure privacy and dodge the attackers,
but no, do not change it - i.e. keep it stable - otherwise the
legitimate users will be disconnected.

Alex

> 
> 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 
>> tohttps://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
> 
> 
> 
> _______________________________________________ its mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/its
>