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

[Nabil Benamar <[e-mail]>]

Hi Roman,


Thank you for your review.

I agree on the text you added, and the parts that should be removed.

I will update the draft as soon as the window is opened. I guess during
Montreal meeting.


Thanks again.



Yours.

On Fri, Jul 12, 2019, 02:50 Roman Danyliw <[e-mail]> wrote:

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