WFM All the best, Pascal > -----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 > > > > > >
