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

[Alexandre Petrescu <[e-mail]>]

Le 10/07/2019 à 13:36, Nabil Benamar a écrit :
> 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. ____
> 
>     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.

We worked a few months to get SeND working with IPv6 on OCB.  We were 
not successful.  We reported the open source tools tried here on the list.

At this time our IPv6-over-OCB trial is unsecured.

Alex

> 
> 
>     (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.
> 
> 
>     (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.
> 
> 
>     (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
> 
> 
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>