Yes, that 's just to say OK with me. All the best, Pascal > -----Original Message----- > From: Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> > Sent: lundi 8 avril 2019 21:14 > 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 > > 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 <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 > >>> > >>> > >>>
