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

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

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
> >
> >
> >