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

[Nabil Benamar <[e-mail]>]

Hi Roman,

I would like to ask you if you are convinced by my answers, or I need to do
more?

Thank you.

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?
>
> ** Why mention SeND if it is “complex and not deployed”?
>
> (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]?
>
> (3) Section 5.2.  Per “An Interface ID SHOULD be of length specified in
> other
> documents”, what other documents?
>
> (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