Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - shortening the opaque IID text

[Alexandre Petrescu <[e-mail]>]

I think 'WFM' means 'Works For Me', so I am happy if it works for you.

Alex

Le 08/04/2019 à 15:05, Pascal Thubert (pthubert) a écrit :
> WFM
> 
> All the best,
> 
> Pascal
> 
>> -----Original Message-----
>> From: Alexandre Petrescu <[e-mail]>
>> Sent: lundi 8 avril 2019 18:15
>> To: Pascal Thubert (pthubert) <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-ipwave-ipv6-over-
>> [e-mail]
>> Subject: Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 -
>> shortening the opaque IID text
>>
>>
>> Le 04/03/2019 à 12:24, Pascal Thubert a écrit :
>>> Reviewer: Pascal Thubert
>>> Review result: Not Ready
>> [...]
>>> "
>>> If semantically
>>>      opaque Interface Identifiers are needed, a potential method for
>>>      generating semantically opaque Interface Identifiers with IPv6
>>>      Stateless Address Autoconfiguration is given in [RFC7217].
>>>
>>>      Semantically opaque Interface Identifiers, instead of meaningful
>>>      Interface Identifiers derived from a valid and meaningful MAC address
>>>      ([RFC2464], section 4), MAY be needed in order to avoid certain
>>>      privacy risks.
>>>
>>> ...
>>>
>>>      In order to avoid these risks, opaque Interface Identifiers MAY be
>>>      formed according to rules described in [RFC7217].  These opaque
>>>      Interface Identifiers are formed starting from identifiers different
>>>      than the MAC addresses, and from cryptographically strong material.
>>>      Thus, privacy sensitive information is absent from Interface IDs, and
>>>      it is impossible to calculate the initial value from which the
>>>      Interface ID was calculated.
>>>
>>> "
>>> Duplicate and mis ordered text, isn't it?
>>
>> Indeed.  The duplication comes from multiple discussions and expresses
>> support of many people to the use of opaque identifiers.
>>
>> To my defense, there is however a notion of going from generic to particular.
>> In first occurences of opaque IIDs we just refer to the RFC, then tell how, and
>> so on.
>>
>> But of course it is a bit long, and worse, it refers twice to the RFC7217, which
>> may disturb.
>>
>> If you dont mind, I shorten it like this:
>>
>> NEW:
>>>     Semantically opaque Interface Identifiers, instead of meaningful
>>>     Interface Identifiers derived from a valid and meaningful MAC address
>>>     ([RFC2464], section 4), help avoid certain privacy risks (see the
>>>     paragraph below).  If semantically opaque Interface Identifiers are
>>>     needed, they MAY be generated using the method for generating
>>>     semantically opaque Interface Identifiers with IPv6 Stateless Address
>>>     Autoconfiguration given in [RFC7217].  Typically, an opaque Interface
>>>     Identifier is formed starting from identifiers different than the MAC
>>>     addresses, and from cryptographically strong material.  Thus, privacy
>>>     sensitive information is absent from Interface IDs, because it is
>>>     impossible to calculate back the initial value from which the
>>>     Interface ID was first generated (intuitively, it is as hard as
>>>     mentally finding the square root of a number, and as impossible as
>>>     trying to use computers to identify quickly whether a large number is
>>>     prime).
>>>
>>>     The privacy risks of using MAC addresses displayed in Interface
>>>     Identifiers are important.  The IPv6 packets can be captured easily
>>>     in the Internet and on-link in public roads.  For this reason, an
>>>     attacker may realize many attacks on privacy.  One such attack on
>>>     802.11-OCB is to capture, store and correlate Company ID information
>>>     present in MAC addresses of many cars (e.g. listen for Router
>>>     Advertisements, or other IPv6 application data packets, and record
>>>     the value of the source address in these packets).  Further
>>>     correlation of this information with other data captured by other
>>>     means, or other visual information (car color, others) MAY constitute
>>>     privacy risks.
>>
>> Alex
>>
>>
>>>
>>> " For this reason, an attacker may realize many
>>>      attacks on privacy.
>>> "
>>> Do we attack privacy? Maybe say that privacy is a real concern, and
>>> maybe move that text to security section?
>>>
>>> "
>>>      The way Interface Identifiers are used MAY involve risks to privacy,
>>>      as described in Section 5.1.
>>> "
>>> Also duplicate
>>>
>>> Nits
>>> ------
>>>
>>> "
>>>      IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>>>      frames whose format is specified in IEEE Std 802.11.
>>> "
>>> Please add link to the reference
>>>
>>> " the 802.11 hidden node"
>>> Do not use 802.11 standalone (multiple occurrences).
>>> => "the IEEE Std. 802.11 [ ref ] hidden node", or just "the hidden terminal".
>>>
>>> BCP 14 text:
>>>
>>> Suggest to use this text:
>>> “
>>>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>> NOT",
>>>      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>> "MAY", and
>>>      "OPTIONAL" in this document are to be interpreted as described in
>>>      https://tools.ietf.org/html/bcp14 https://tools.ietf.org/html/bcp14
>>>      [https://tools.ietf.org/html/rfc2119][RFC8174] when, and only when, they
>>>      appear in all capitals, as shown here.
>>>
>>> “
>>>
>>> All the best
>>>
>>> Pascal
>>>
>>>
>>>