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

[Alexandre Petrescu <[e-mail]>]

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