-----Original Message-----
From: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx>
Sent: lundi 8 avril 2019 18:15
To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>
Cc: int-dir@xxxxxxxx; ietf@xxxxxxxx; its@xxxxxxxx; draft-ietf-ipwave-ipv6-over-
80211ocb.all@xxxxxxxx
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
