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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 09 Jul 2019 13:03:43 -0700

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/

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Jul 2019 08:44:14 +0200

Le 09/07/2019 à 22:03, Roman Danyliw via Datatracker a écrit :
[...]
> documents”, what other documents?

The idea was to get tract for a variable length IID document in 6MAN WG. 
  One indiviual submission is draft-petrescu-6man-ll-prefix-len-21.

However, the 6MAN WG tells that topic is closed and I am indicated to 
refrain from new discussions on that topic in that WG.

As such, there is presumably no other document to refer to.

I will not say anything related to 64.  It is not up to me to say 
something I do not believe in, and which is a barrier to deployment.

[...]

> “inherited” mean in this case?

For example, the resulting stack uses Ethernet II headers.  The use of 
Ethernet II headers on 802.11 media is inherited from RFC2464 (not RFC2462).

It is not the 'inheritance' of OO programming.  It is inheritance like 
in legacy.

> transition time”, the meaning of the “in particular during transition time

The implemenntations of IPv6-over-OCB run on linux only, in particular 
in earlier versions of kernel because they are embedded platforms; 
embedded platforms are not up to date with kernel versions, like desktop 
linuces are.

The more privacy respecting IIDs RFCs are present and implemented in 
more recent linux dekstop versions, and in BSD.  BSD does not implemenet 
IP-over-OCB.

I suspect gradually these privacy IIDs will move to linux and embedded, 
but it will take time.  That transition time I estimate at 5 years 
before we see privacy IIDs in common embedded systems in cars.  Until 
then they use oui.txt MAC-based LL addresses with the usual privacy 
issues. (I am saying oui.txt because that's the public registry which 
makes them vulnerable; there are also MAC addresses that are less 
vulnerable because more randomized, like in Windows).

> security mechanisms?  I’m getting caught up in the use of “stripped off”.

The 802.11 security features are absent in OCB mode.  Maybe 'stripped' 
and 'off' combination is not the right term.

Alex

[...]

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 10 Jul 2019 12:36:45 +0100

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 <
[email-masked]> wrote:

> 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.

> ** What specific ETSI protocols are being recommended from

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

> documents”, what other documents?
I'm afraid no other documents as mentioned by Alex in its reply. To be
removed.

-- 

Best Regards

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Jul 2019 15:05:30 +0200

Le 10/07/2019 à 13:36, Nabil Benamar a écrit :
> On Tue, Jul 9, 2019 at 9:03 PM Roman Danyliw via Datatracker 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     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.
> 

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

> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 11 Jul 2019 14:49:59 +0100

Hi Roman,

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

Thank you.

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 12 Jul 2019 01:50:50 +0000

From: Nabil Benamar [mailto:[email-masked]]
Sent: Wednesday, July 10, 2019 7:37 AM
To: Roman Danyliw <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; Carlos Bernardos <[email-masked]>; [email-masked]; [email-masked]
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.

On Tue, Jul 9, 2019 at 9:03 PM Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss

[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

[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

NEW:

(11) Editorial Nits

--

Best Regards

Nabil Benamar
Associate Professor

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 12 Jul 2019 06:00:58 +0100

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 <[email-masked]> wrote:

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

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 21 Jul 2019 20:34:02 +0000

Hi Nabil!

Thanks for the -50 update.  See below for the details.  The quick summary is that discuss items #1-3 are addressed in -50.  I haven’t seen an response on discuss #4.

Roman

From: Nabil Benamar [mailto:[email-masked]]
Sent: Friday, July 12, 2019 1:01 AM
To: Roman Danyliw <[email-masked]>
Cc: IESG <[email-masked]>; [email-masked]; Carlos Bernardos <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Roman Danyliw's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

Hi Roman,

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 <[email-masked]<mailto:[email-masked]>> wrote:

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

Hi Roman,

OLD:

NEW:

END

Thanks,
Roman
[Roman] The changes in -50 address the DISCUSS #1 – 3 above.  I’d recommend making a quick check for editorial nits introduced:
s/setting an interface carda&#128;&#153;s/setting an interface card’s/
s/node.A  This/node.  This/

[Roman] I didn’t see a response to this point.
Roman

NEW:

(11) Editorial Nits

--

Best Regards

Nabil Benamar
Associate Professor

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Jul 2019 10:31:09 +0200

Le 21/07/2019 à 22:34, Roman Danyliw a écrit :
> Hi Nabil!
> 
> Thanks for the -50 update.  See below for the details.  The quick 
> summary is that discuss items #1-3 are addressed in -50.  I haven’t seen 
> an response on discuss #4.

 > ** What specific ETSI protocols are being recommended from

I do not know for sure myself.  One would ask Jérôme Härri.

I looked myself at the public document referred (ETSI TS 102 940 V1.2.1
(2016-11)).  I could find a recommendation to generate MAC address:
"shall be derived from the identifier provided by the Security Entity in
the ID change notification".  (the "ID Change Notification" seems to be
an application layer message).

 From my side, I do not agree with this method to generate more
obfuscated MAC addresses.

I have some ideas how to generate more obfuscated MAC addresses, but
certainly not in the ETSI way.

 > ** What is meant by the drivers’ identity in this case?

There is activity at Gemalto now Thales about e-Driver's License.
Supposedly that is an electronic format of a driver's license that is
more accessible.  I think that driver's license in some countries have
no electronic equivalent at this time.

The trials of electronic Driver's License happened mostly in America,
and were probably totally absent in Europe.

That is all I know.

 > What is the pseudonym scheme is being used to protect it or what
 > requirements are being set for it?

I do not know myself.

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

There is no trusted third party in the automotive networks.  There are a
few efforts to build national Certificate Authorities, European
automotive PKIs, and similar.  Most are backed by trials.  But there is
no universally agreed CA (like is e.g. Verisign in the Internet world).
  They are all expensive to access, and some times even impossible.

What is needed is that the automotive networks use the CAs from Internet.

What is needed is that the automotive networks use the CAs from Internet.

Alex