Subject: [ipwave] Barry Leiba's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 21:01:06 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A very simple point to fix:

I think that IEEE-802.11-2016 should be normative because it is the reference
for 802.11-OCB and is the subject of a MUST in Section 4.2.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

These are all editorial comments:

— Section 4.4 —

   For Interface Identifiers for
   IPv6 address of type 'Link-Local' are discussed in Section 4.3.
 There’s something wrong with that sentence.  Maybe it’s just that the first
 word needs to be struck?

   Regardless of how
   to form the IID, its length is 64 bits, as is the case of the IPv6
   over Ethernet [RFC2464].

There’s something wrong with this sentence too, but I don’t know what the fix
is: I don’t know what the “as is the case...” part is meant to say.  Can you
try rephrasing?

   If
   semantically opaque IIDs are needed, they MAY be generated using the
   method for generating semantically opaque IIDs

This isn’t wrong with the “MAY”, but I think it really is just a non-keyword
“may”.

— Section 4.5.2 —

   The meaning of the value "3333"
   mentioned in that section 7 of [RFC2464]

As you’ve just given the section reference in the previous sentence, I think it
reads better to use the context and just say, “The meaning of the value "3333"
mentioned there”.

— Section 4.6 —

   A subnet may be formed over 802.11-OCB interfaces of vehicles that
   are in close range (not by their in-vehicle interfaces).

At first I tried to understand what the in-vehicle interfaces had to do with
the close range.  I think it’s clearer with this word order:

NEW
   When vehicles are in close range, a subnet may be formed over
   802.11-OCB interfaces (not by their in-vehicle interfaces).
END

   An IPv6 subnet on which Neighbor Discovery protocol (ND) can be
   mapped on an OCB network if all nodes share a single broadcast
   Domain, which is generally the case for P2P OCB links;

This isn’t a complete sentence: it has a subject, but no verb.  What is it
trying to say?  Also, the semicolon should be a period, as it’s not useful to
chain it onto the following sentence.

   strict (e.g. fast drive through IP-RSU coverage)

The “e.g.” needs a comma after it (or change it to “such as with”), and
“fast-drive-through” needs to be hyphenated, as a compound modifier.

— Section 5 —

   application-layer mechanisms are out-of-
   scope of this document.

Here, “out of scope” should not be hyphenated (it’s not a modifier).

   and performs attacks
   without needing to physically break any wall.

“and performs attacks” shoud be “and perform attacks”.
The “physically break any wall” part seems kind of odd, as there are clearly no
physical walls involved at all.  What are you really trying to say?

   The potential attack vectors are: MAC address spoofing, IP address
   and session hijacking, and privacy violation Section 5.1.

What is “Section 5.1” about?  Is that meant to be a citation, like “[Section
5.1]” ?

— Section 5.1 —

   A vehicle embarking an IP-
   OBU whose egress interface is 802.11-OCB may expose itself to
   eavesdropping and subsequent correlation of data; this may reveal
   data considered private by the vehicle owner; there is a risk of
   being tracked.

It’s awkward to chain three sentences with semicolons.  I would separate the
first one: change the first semicolon into a period.

   as dynamically changing MAC addresses Section 5.2, semantically
   opaque Interface Identifiers and stable Interface Identifiers
   Section 4.4.

The two section references should be bracketed, as “[Section 5.2]”.

   Futhermore, for
   pricavy concerns ([RFC8065]) recommends

Make it, “Futhermore, for privacy concerns, [RFC8065] recommends“.

— Section 5.1.1 —

   means, or other visual information (car color, others) MAY constitute
   privacy risks.

This “MAY” should definitely be “may”: it’s just a statement of fact.

— Section 5.2 —

   In 802.11-OCB networks, the MAC addresses MAY change during well
   defined renumbering events.

Also a statement of fact, so “may”.

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 11 Jul 2019 09:38:40 +0100

Hi Barry,

Thank you for your review.

I'll update this reference in the next version.
Thank you for proofreading the paper and for your comments, which will be
reflected in the next version.

Much appreciated.

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jul 2019 09:36:27 -0400

Thanks for the quick reply, Nabil, and I will clear my DISCUSS now in
anticipation of the reference change.

Barry

On Thu, Jul 11, 2019 at 4:39 AM Nabil Benamar <[email-masked]> wrote:
> Thank you for proofreading the paper and for your comments, which will be reflected in the next version.
>
> Much appreciated.
>
> On Thu, Jul 11, 2019 at 5:01 AM Barry Leiba via Datatracker <[email-masked]> wrote:
>>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 11 Jul 2019 14:42:12 +0100

Much much appreciated, Barry!

Thanks to everybody reviewing, commenting and proofreading this draft.

Yours.

On Thu, Jul 11, 2019 at 2:36 PM Barry Leiba <[email-masked]> wrote:

> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Jul 2019 12:10:44 +0200

I would like to reply to a few points.

Le 11/07/2019 à 15:36, Barry Leiba a écrit :
[...]
>>> There’s something wrong with that sentence.  Maybe it’s just that the first

You suggest to remove 'IPv6' from 'IPv6 address' and so become 'address 
of type LL ...'.

I tend to agree with you, because all there is to be is IP.  IPv4 is 
dying out and so we are left only with IPv6, which so becomes IP, and so 
becomes the only assumed kind of 'address'.

But this is a matter of stance.  Such a stance could have been taken 
throughout the document.  It was however difficult to write it so 
everywhere.  For example, as much as LL addresses can be both IPv4 and 
IPv6, ULA addresses are only IPv6.  The approximate equivalent of ULA in 
IPv4 is publicly unroutable addresses (also called 'private', or 'NAT') 
and the 'shared address space' (also called CGN NAT, like 
100.64.0.0/10).  Neither NAT nor shared address space are the equivalent 
of ULA.  And so it is difficult to think that an address type is present 
in both versions of IP, and so just say 'IP', and so just assume that 
'address' is an 'IPv6 address'.

As such it was difficult to take this stance throughout the document.

The title contents was even a more difficult situation: 'IPv6 over OCB' 
vs 'IP over OCB' was considered, but there is much IPv4 over OCB try, so 
it would be difficult to assume only IPv6 is there.

But, of course, if there is another direction that needs to be taken 
about striking out this IP word (make it disappear from that place), 
then I agree.

>>> is: I don’t know what the “as is the case...” part is meant to say.  Can you

It is meant to say that RFC2464 defines the prefix length on Ethernet to 
be 64, and as such one would assume the IID length on Ethernet to be 64.

But a reformulation would help, I agree.

[...]
>>>     802.11-OCB interfaces (not by their in-vehicle interfaces).

I agree.

[...]
>>> physical walls involved at all.  What are you really trying to say?

This is an old view first appearing with Hiperlan and WiFi.  At the 
time, it was often said that WiFi and Internet is a big risk, because 
one could attack without needing to force and come in server rooms; a 
brick-and-mortar enterprise is more difficult to attack than an 
enterprise on the web, because attacker would need to break walls made 
of brick and mortar, which is a difficult operation.

>>> What is “Section 5.1” about?  Is that meant to be a citation, like “[Section

Or rather between parenthesis, like this:

NEW:
>>>>     and session hijacking, and privacy violation (see Section 5.1.)

[...]

Alex