Subject: Re: [ipwave] Comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Sep 2017 16:00:30 +0200

Le 21/08/2017 à 17:14, Sandra Céspedes U. a écrit :
[...]
> 3. In page 4, there seems to be a contradiction. In the first
> paragraph is mentioned that "while there is no encryption applied
> below the network  layer using 802.11p, 1609.2 [ieee1609.2] does
> provide security services for applications to use so that there can
> easily be data security over the air without invoking IPsec."
> However, in the fifth paragraph is mentioned that "the IP security
> mechanisms are necessary, since OCB means that 802.11 is stripped of
> all 802.11 link-layer security;".  I understood that IPSec wasn't
> necessary but the last phrase seems to say the opposite. Am I wrong?

No.

I removed "so that there can easily be data security over the air
without invoking IPsec".

> 5. In page 7, suggest to change "This band is "5.9GHz" which is 
> different from the bands "2.4GHz" or "5GHz" used by Wireless LAN" to 
> "The 5.9GHz band is different from the 2.4GHz and 5GHz bands used by 
> Wireless LAN".

Done.

> Same suggestion to other appearances in the same paragraph.

I dont see where.

> 6. In page 7 you mention " In the list below, the only 802.11 OCB 
> fundamental points which influence IPv6 are the OCB operation and the
> 12Mbit/s maximum which may be afforded by the IPv6 applications."  I
> found the description for OCB operation but none for the 12Mbit/s
> maximum (not sure if you are referring to a maximum data rate? I
> thought it was actually 27 Mbps), so it is not clear how the second
> "fundamental point" influences the operation of IPv6.

I reformulated.

> 7. In Appendix C.1, perhaps it should be mentioned that relaying on
> an identifier obtained from the MAC address might not be possible
> not only in the presence of multiple 802.11-OCB NICs, but also if
> there is randomization of MAC addresses.

But if there is randomisation of the MAC address (a single MAC address),
it is still possible to identify one vehicle by that MAC address, even
if it is a number that is randomised.   I suppose it is randomised only
once in a lifetime, not every time the machine boots.  I suppose it is
randomised such that an privacy attacker is prevented from correlating
the OUI of a MAC address to the true organisation (obfuscation).

Or maybe you assumed frequent MAC randomisation.  In that case, I
reformulated.

> 8. Appendix C.2 defines several MUSTs for authentication, time 
> synchronization, etc. Why is this defined as an appendix and not in 
> the main document?

It looks like these requirements should be outside the document
altogether.

Thank you.

Alex

---

From: Sandra Céspedes <[email-masked]>
Date: Wed, 13 Sep 2017 13:28:13 -0300

Dear Alexandre

Thanks for addressing my comments. The new version has improved
significantly.

Regards,

Sandra L. Céspedes, Ph.D. | Profesora Asistente
Departamento de Ingeniería Eléctrica
Universidad de Chile
Av. Tupper 2007, Santiago, Chile. 8370451
Tel.* +56 (2) 29784093 <%2B56%20%282%29%2029784093>* | Of. 504
URL:http://www.cec.uchile.cl/~scespedes

On Sun, Sep 10, 2017 at 11:00 AM, Alexandre Petrescu <
[email-masked]> wrote:

> 5. In page 7, suggest to change "This band is "5.9GHz" which is different
>> from the bands "2.4GHz" or "5GHz" used by Wireless LAN" to "The 5.9GHz band
>> is different from the 2.4GHz and 5GHz bands used by Wireless LAN".
>>
>
> Done.
>
>> synchronization, etc. Why is this defined as an appendix and not in the
>> main document?
>>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>