Re: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

From: Nabil Benamar [mailto:[e-mail]]
Sent: Wednesday, July 10, 2019 7:37 AM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; Carlos Bernardos <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Roman Danyliw's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

Hi Roman,

Thank you for your detailed review. Let me start with the 'DISCUSS' comments.

Please see my answers below.

On Tue, Jul 9, 2019 at 9:03 PM Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Roman Danyliw 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 few items per the text in the Security Considerations (Section 5):

(1) Section 5.  Per “A previous work at SAVI WG identifies some threats
[RFC6959], while SeND presented in [RFC3971] and [RFC3972] is a solution
against address theft but it is complex and not deployed.”, a few questions:

** What specific threats from RFC6959 are of concern?  Which mitigations for
them are being proposed?


Since there is no Layer 2 security in OCB, anyone can join the same subnet and impersonate any only else, to source traffic and get the traffic back.



[Roman] In this case, perhaps something more precise could be said:



OLD:

   The potential attack vectors are: MAC address spoofing, IP address

    and session hijacking, and privacy violation Section 5.1.  A previous

    work at SAVI WG identifies some threats [RFC6959], while SeND

    presented in [RFC3971] and [RFC3972] is a solution against address

   theft but it is complex and not deployed.



NEW:

When using OCB, no layer 2 security is provided.  Therefore, any node can join a subnet, directly communicate with any nodes on the subset to include potentially impersonating another node.  This design allows for a number of threats outlined in Section 3 of [RFC6959].  While not widely deployed, SeND [RFC3971] [RFC3972] is a solution that can address <insert qualifying statements on which subset of the threats in Section 3>”

END



There is no mitigation in this specification because it is limited to RFC 4861 and 4862 and SeND is not available in the current stacks.

** Why mention SeND if it is “complex and not deployed”?

This was informational because it may be the only pertinent remediation.


(2) Section 5.  Per “More IETF protocols are available in the toolbox of the IP
security protocol designer.  Some ETSI protocols related to security protocols
in ITS are described in [ETSI-sec-archi].”:

** Are there specific protocols to mention here?  Would they be
different/OCB-specific than what was already noted in the beginning of the
section -- “Any security mechanism as the IP layer or above that may be carried
out …”?

** What specific ETSI protocols are being recommended from [ETSI-sec-archi]?

This sentence is just informational. I propose to remove the whole sentence.

[Roman] That works for me.


(3) Section 5.2.  Per “An Interface ID SHOULD be of length specified in other
documents”, what other documents?
I'm afraid no other documents as mentioned by Alex in its reply. To be removed.

[Roman] Removing the text works for me.

Thanks,
Roman


(4) Section 5.3  I’m having trouble following this section – is this a
discussion of a threat or mitigation?  The references to Section 4.4 and 5.0
didn’t clarity this for me.

** What is meant by the drivers’ identity in this case?  What is the pseudonym
scheme is being used to protect it or what requirements are being set for it?

** What are the specific challenges of concern around pseudo-anonymization
approaches to which an allusion is made?

** Who is the trusted third parted needed?


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

(5) Section 1.  Per “The resulting stack inherits from IPv6 over Ethernet
[RFC2462], but operates over …”, what exactly is being inherited?  What does
“inherited” mean in this case?

(6) Section 4.3.  Per “Among these types of addresses only the IPv6 link-local
addresses can be formed using an EUI-64 identifier, in particular during
transition time”, the meaning of the “in particular during transition time
isn’t clear to me.

(7) Section 5.  Per “The OCB operation is stripped off of …”, is this sentence
saying that OCB operations doesn’t use 802.11 link layer security mechanisms,
or does the OCB operation actively remove (i.e., strips) 802.11 link layer
security mechanisms?  I’m getting caught up in the use of “stripped off”.

(8) Section 5, Per “Any attacker can therefore just sit in the near range of
vehicles ... and performs attacks without needing to physically break any
wall”, I’d recommend revising this sentence to reflect that it isn’t just
vehicles and that active attacks are possible:

NEW:
Therefore, an attacker can sniff or inject traffic while within range of a
vehicle or IP-RSU (by setting an interface card’s frequency to the proper
range).

(9) Section 5.  What is “protected 802.11” mentioned in “Such a link is less
protected …”?

(10) Section 5.2.  SHA256 needs a reference.

(11) Editorial Nits
** Table of Contents.  There is odd spacing in the title of Appendix C

** Section 1.  Typo.  s/Appendicies/Appendices/

** Section 1.  Typo.  s/Concretly/Concretely/

** Section 1.  Editorial.  s/[RFC1042], [RFC2464] ./[RFC1042 and [RFC2464]./

** Multiple sections. Editorial, to make an RFC citation a reference.
s/RFC2464/[RFC2464]/ and s/RFC 7217/[RFC7217]/

** Section 4.5.  Typo.  s/.A  A future/.  A future/

** Section 4.6. Typo.  s/links; The/links.  The/

** Section 5.1.  Typo.  s/Futhermore/Furthermore/

** Section 5.1.  Typo.  s/pricavy/privacy/

** Section 5.2. Typo.  s/admninistered/ administered/

** Appendix B.  s/Ammendment/Amendment/

** Appendix H.  Duplicate word. s/section Section 2/Section 2/

** Appendix I.  Typo.  s/specificed/specified/

** Appendix I. Typo.  s/Moreoever/Moreover/



--

Best Regards

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