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

["Pascal Thubert (pthubert)" <[e-mail]>]

Yes, that 's just to say OK with me.

All the best,

Pascal

> -----Original Message-----
> From: Alexandre Petrescu <[e-mail]>
> Sent: lundi 8 avril 2019 21:14
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-ipwave-ipv6-over-
> [e-mail]
> 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 <[e-mail]>
> >> Sent: lundi 8 avril 2019 18:15
> >> To: Pascal Thubert (pthubert) <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; [e-mail];
> >> draft-ietf-ipwave-ipv6-over- [e-mail]
> >> 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
> >>>
> >>>
> >>>