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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux