draft-ietf-ipwave-ipv6-over-80211ocb-51.txt   draft-ietf-ipwave-ipv6-over-80211ocb-52.txt 
IPWAVE Working Group N. Benamar IPWAVE Working Group N. Benamar
Internet-Draft Moulay Ismail University of Meknes Internet-Draft Moulay Ismail University of Meknes
Intended status: Standards Track J. Haerri Intended status: Standards Track J. Haerri
Expires: January 25, 2020 Eurecom Expires: February 10, 2020 Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
July 24, 2019 August 9, 2019
Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside
the Context of a Basic Service Set the Context of a Basic Service Set
draft-ietf-ipwave-ipv6-over-80211ocb-51 draft-ietf-ipwave-ipv6-over-80211ocb-52
Abstract Abstract
This document provides methods and settings, for using IPv6 to This document provides methods and settings, for using IPv6 to
communicate among nodes within range of one another over a single communicate among nodes within range of one another over a single
IEEE 802.11-OCB link. Support for these methods and settings require IEEE 802.11-OCB link. Support for these methods and settings require
minimal changes to existing stacks. This document also describes minimal changes to existing stacks. This document also describes
limitations associated with using these methods. Optimizations and limitations associated with using these methods. Optimizations and
usage of IPv6 over more complex scenarios is not covered in this usage of IPv6 over more complex scenarios is not covered in this
specification and is subject of future work. specification and is subject of future work.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 25, 2020. This Internet-Draft will expire on February 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction 1. Introduction
This document provides a baseline for using IPv6 to communicate among This document provides a baseline for using IPv6 to communicate among
nodes in range of one another over a single IEEE 802.11-OCB link nodes in range of one another over a single IEEE 802.11-OCB link
[IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and
Appendix C) with minimal changes to existing stacks. Moreover, the Appendix C) with minimal changes to existing stacks. Moreover, the
document identifies limitations of such usage. Concretely, the document identifies limitations of such usage. Concretely, the
document describes the layering of IPv6 networking on top of the IEEE document describes the layering of IPv6 networking on top of the IEEE
Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame
translation underneath. The resulting stack inherits from IPv6 over translation underneath. The resulting stack is derived from IPv6
Ethernet [RFC2464], but operates over 802.11-OCB to provide at least over Ethernet [RFC2464], but operates over 802.11-OCB to provide at
P2P (Point to Point) connectivity using IPv6 ND and link-local least P2P (Point to Point) connectivity using IPv6 ND and link-local
addresses. addresses.
The IPv6 network layer operates on 802.11-OCB in the same manner as The IPv6 network layer operates on 802.11-OCB in the same manner as
operating on Ethernet with the following exceptions: operating on Ethernet with the following exceptions:
o Exceptions due to different operation of IPv6 network layer on o Exceptions due to different operation of IPv6 network layer on
802.11 than on Ethernet. The operation of IP on Ethernet is 802.11 than on Ethernet. The operation of IP on Ethernet is
described in [RFC1042] and [RFC2464]. described in [RFC1042] and [RFC2464].
o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
operating system and the 802.11-OCB media, device drivers MAY operating system and the 802.11-OCB media, device drivers MAY
implement IPv6-over-Ethernet as per [RFC2464] and then a frame implement IPv6-over-Ethernet as per [RFC2464] and then a frame
translation from 802.3 to 802.11 in order to minimize the code translation from 802.3 to 802.11 in order to minimize the code
changes. changes.
4.3. Link-Local Addresses 4.3. Link-Local Addresses
There are several types of IPv6 addresses [RFC4291], [RFC4193], that There are several types of IPv6 addresses [RFC4291], [RFC4193], that
may be assigned to an 802.11-OCB interface. Among these types of may be assigned to an 802.11-OCB interface. Among these types of
addresses only the IPv6 link-local addresses can be formed using an addresses only the IPv6 link-local addresses can be formed using an
EUI-64 identifier, in particular during transition time. EUI-64 identifier, in particular during transition time, (the time
spent before an interface starts using a different address than the
LL one).
If the IPv6 link-local address is formed using an EUI-64 identifier, If the IPv6 link-local address is formed using an EUI-64 identifier,
then the mechanism of forming that address is the same mechanism as then the mechanism of forming that address is the same mechanism as
used to form an IPv6 link-local address on Ethernet links. Moreover, used to form an IPv6 link-local address on Ethernet links. Moreover,
whether or not the interface identifier is derived from the EUI-64 whether or not the interface identifier is derived from the EUI-64
identifier, its length is 64 bits as is the case for Ethernet identifier, its length is 64 bits as is the case for Ethernet
[RFC2464]. [RFC2464].
4.4. Stateless Autoconfiguration 4.4. Stateless Autoconfiguration
skipping to change at page 7, line 4 skipping to change at page 7, line 7
Address Detection (DAD) per [RFC4862]. Address Detection (DAD) per [RFC4862].
4.5.2. Address Mapping -- Multicast 4.5.2. Address Mapping -- Multicast
The multicast address mapping is performed according to the method The multicast address mapping is performed according to the method
specified in section 7 of [RFC2464]. The meaning of the value "3333" specified in section 7 of [RFC2464]. The meaning of the value "3333"
mentioned there is defined in section 2.3.1 of [RFC7042]. mentioned there is defined in section 2.3.1 of [RFC7042].
Transmitting IPv6 packets to multicast destinations over 802.11 links Transmitting IPv6 packets to multicast destinations over 802.11 links
proved to have some performance issues proved to have some performance issues
[I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be
exacerbated in OCB mode.A A future improvement to this specification exacerbated in OCB mode. A future improvement to this specification
should consider solutions for these problems. should consider solutions for these problems.
4.6. Subnet Structure 4.6. Subnet Structure
When vehicles are in close range, a subnet may be formed over When vehicles are in close range, a subnet may be formed over
802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix
List conceptual data structure ([RFC4861] Section 5.1) is maintained List conceptual data structure ([RFC4861] Section 5.1) is maintained
for each 802.11-OCB interface. for each 802.11-OCB interface.
IPv6 Neighbor Discovery protocol (ND) requires reflexive properties IPv6 Neighbor Discovery protocol (ND) requires reflexive properties
skipping to change at page 8, line 36 skipping to change at page 8, line 38
802.11-OCB does not provide any cryptographic protection, because it 802.11-OCB does not provide any cryptographic protection, because it
operates outside the context of a BSS (no Association Request/ operates outside the context of a BSS (no Association Request/
Response, no Challenge messages). Therefore, an attacker can sniff Response, no Challenge messages). Therefore, an attacker can sniff
or inject traffic while within range of a vehicle or IP-RSU (by or inject traffic while within range of a vehicle or IP-RSU (by
setting an interface card's frequency to the proper range). Also, an setting an interface card's frequency to the proper range). Also, an
attacker may not heed to legal limits for radio power and can use a attacker may not heed to legal limits for radio power and can use a
very sensitive directional antenna; if attackers wishe to attack a very sensitive directional antenna; if attackers wishe to attack a
given exchange they do not necessarily need to be in close physical given exchange they do not necessarily need to be in close physical
proximity. Hence, such a link is less protected than commonly used proximity. Hence, such a link is less protected than commonly used
links (wired link or protected 802.11). links (wired link or aforementioned 802.11 links with link-layer
security).
Therefore, any node can join a subnet, directly communicate with any Therefore, any node can join a subnet, directly communicate with any
nodes on the subset to include potentially impersonating another nodes on the subset to include potentially impersonating another
node. This design allows for a number of threats outlined in node. This design allows for a number of threats outlined in
Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971], Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971],
[RFC3972] is a solution that can address Spoof-Based Attack Vectors. [RFC3972] is a solution that can address Spoof-Based Attack Vectors.
5.1. Privacy Considerations 5.1. Privacy Considerations
As with all Ethernet and 802.11 interface identifiers ([RFC7721]), As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
skipping to change at page 9, line 14 skipping to change at page 9, line 17
being tracked. In outdoors public environments, where vehicles being tracked. In outdoors public environments, where vehicles
typically circulate, the privacy risks are more important than in typically circulate, the privacy risks are more important than in
indoors settings. It is highly likely that attacker sniffers are indoors settings. It is highly likely that attacker sniffers are
deployed along routes which listen for IEEE frames, including IP deployed along routes which listen for IEEE frames, including IP
packets, of vehicles passing by. For this reason, in the 802.11-OCB packets, of vehicles passing by. For this reason, in the 802.11-OCB
deployments, there is a strong necessity to use protection tools such deployments, there is a strong necessity to use protection tools such
as dynamically changing MAC addresses Section 5.2, semantically as dynamically changing MAC addresses Section 5.2, semantically
opaque Interface Identifiers and stable Interface Identifiers opaque Interface Identifiers and stable Interface Identifiers
Section 4.4. An example of change policy is to change the MAC Section 4.4. An example of change policy is to change the MAC
address of the OCB interface each time the system boots up. This may address of the OCB interface each time the system boots up. This may
help mitigate privacy risks to a certain level. Futhermore, for help mitigate privacy risks to a certain level. Furthermore, for
pricavy concerns, ([RFC8065]) recommends using an address generation privacy concerns, ([RFC8065]) recommends using an address generation
scheme rather than addresses generated from a fixed link-layer scheme rather than addresses generated from a fixed link-layer
address. However, there are some specificities related to vehicles. address. However, there are some specificities related to vehicles.
Since roaming is an important characteristic of moving vehicles, the Since roaming is an important characteristic of moving vehicles, the
use of the same Link-Local Address over time can indicate the use of the same Link-Local Address over time can indicate the
presence of the same vehicle in different places and thus leads to presence of the same vehicle in different places and thus leads to
location tracking. Hence, a vehicle should get hints about a change location tracking. Hence, a vehicle should get hints about a change
of environment (e.g. , engine running, GPS, etc..) and renew the IID of environment (e.g. , engine running, GPS, etc..) and renew the IID
in its LLAs. in its LLAs.
5.1.1. Privacy Risks of Meaningful info in Interface IDs 5.1.1. Privacy Risks of Meaningful info in Interface IDs
skipping to change at page 10, line 5 skipping to change at page 10, line 9
on an 802.11-OCB interface all the Interface Identifiers of IPv6 on an 802.11-OCB interface all the Interface Identifiers of IPv6
addresses assigned to that interface MUST change. addresses assigned to that interface MUST change.
Implementations should use a policy dictating when the MAC address is Implementations should use a policy dictating when the MAC address is
changed on the 802.11-OCB interface. For more information on the changed on the 802.11-OCB interface. For more information on the
motivation of this policy please refer to the privacy discussion in motivation of this policy please refer to the privacy discussion in
Appendix B. Appendix B.
A 'randomized' MAC address has the following characteristics: A 'randomized' MAC address has the following characteristics:
o Bit "Local/Global" set to "locally admninistered". o Bit "Local/Global" set to "locally administered".
o Bit "Unicast/Multicast" set to "Unicast". o Bit "Unicast/Multicast" set to "Unicast".
o The 46 remaining bits are set to a random value, using a random o The 46 remaining bits are set to a random value, using a random
number generator that meets the requirements of [RFC4086]. number generator that meets the requirements of [RFC4086].
To meet the randomization requirements for the 46 remaining bits, a To meet the randomization requirements for the 46 remaining bits, a
hash function may be used. For example, the SHA256 hash function may hash function may be used. For example, the [SHA256] hash function
be used with input a 256 bit local secret, the 'nominal' MAC Address may be used with input a 256 bit local secret, the 'nominal' MAC
of the interface, and a representation of the date and time of the Address of the interface, and a representation of the date and time
renumbering event. of the renumbering event.
A randomized Interface ID has the same characteristics of a A randomized Interface ID has the same characteristics of a
randomized MAC address, except the length in bits. randomized MAC address, except the length in bits.
5.3. Pseudonymization impact on confidentiality and trust 5.3. Pseudonymization impact on confidentiality and trust
Vehicles 'and drivers' privacy relies on pseudonymization mechanisms Vehicles 'and drivers' privacy relies on pseudonymization mechanisms
such as the ones described in Section 5.2. This pseudonymization such as the ones described in Section 5.2. This pseudonymization
means that upper-layer protocols and applications SHOULD NOT rely on means that upper-layer protocols and applications SHOULD NOT rely on
layer-2 or layer-3 addresses to assume that the other participant can layer-2 or layer-3 addresses to assume that the other participant can
skipping to change at page 14, line 35 skipping to change at page 14, line 35
[I-D.ietf-ipwave-vehicular-networking] [I-D.ietf-ipwave-vehicular-networking]
Jeong, J., "IP Wireless Access in Vehicular Environments Jeong, J., "IP Wireless Access in Vehicular Environments
(IPWAVE): Problem Statement and Use Cases", draft-ietf- (IPWAVE): Problem Statement and Use Cases", draft-ietf-
ipwave-vehicular-networking-11 (work in progress), July ipwave-vehicular-networking-11 (work in progress), July
2019. 2019.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-06 (work Media", draft-ietf-mboned-ieee802-mcast-problems-07 (work
in progress), July 2019. in progress), July 2019.
[IEEE-1609.2] [IEEE-1609.2]
"IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Security Services for in Vehicular Environments (WAVE) -- Security Services for
Applications and Management Messages. Example URL Applications and Management Messages. Example URL
http://ieeexplore.ieee.org/document/7426684/ accessed on http://ieeexplore.ieee.org/document/7426684/ accessed on
August 17th, 2017.". August 17th, 2017.".
[IEEE-1609.3] [IEEE-1609.3]
skipping to change at page 16, line 14 skipping to change at page 16, line 14
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[SHA256] "Secure Hash Standard (SHS), National Institute of
Standards and Technology.
https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/
archive/2002-08-01/documents/fips180-2.pdf".
Appendix A. 802.11p Appendix A. 802.11p
The term "802.11p" is an earlier definition. The behaviour of The term "802.11p" is an earlier definition. The behaviour of
"802.11p" networks is rolled in the document IEEE Std 802.11-2016. "802.11p" networks is rolled in the document IEEE Std 802.11-2016.
In that document the term 802.11p disappears. Instead, each 802.11p In that document the term 802.11p disappears. Instead, each 802.11p
feature is conditioned by the IEEE Management Information Base (MIB) feature is conditioned by the IEEE Management Information Base (MIB)
attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated
is set to true the IEEE Std 802.11-OCB state is activated. For is set to true the IEEE Std 802.11-OCB state is activated. For
example, an 802.11 STAtion operating outside the context of a basic example, an 802.11 STAtion operating outside the context of a basic
service set has the OCBActivated flag set. Such a station, when it service set has the OCBActivated flag set. Such a station, when it
skipping to change at page 28, line 35 skipping to change at page 28, line 35
to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II
headers. In further detail, this adaptation consists in the headers. In further detail, this adaptation consists in the
elimination of the Radiotap, 802.11 and LLC headers, and in the elimination of the Radiotap, 802.11 and LLC headers, and in the
insertion of the Ethernet II header. In this way, IPv6 runs straight insertion of the Ethernet II header. In this way, IPv6 runs straight
over LLC over the 802.11-OCB MAC layer; this is further confirmed by over LLC over the 802.11-OCB MAC layer; this is further confirmed by
the use of the unique Type 0x86DD. the use of the unique Type 0x86DD.
Appendix H. Extra Terminology Appendix H. Extra Terminology
The following terms are defined outside the IETF. They are used to The following terms are defined outside the IETF. They are used to
define the main terms in the main terminology section Section 2. define the main terms in the main terminology Section 2.
DSRC (Dedicated Short Range Communication): a term defined outside DSRC (Dedicated Short Range Communication): a term defined outside
the IETF. The US Federal Communications Commission (FCC) Dedicated the IETF. The US Federal Communications Commission (FCC) Dedicated
Short Range Communication (DSRC) is defined in the Code of Federal Short Range Communication (DSRC) is defined in the Code of Federal
Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the
definitions below. At the time of the writing of this Internet definitions below. At the time of the writing of this Internet
Draft, the last update of this Code was dated October 1st, 2010. Draft, the last update of this Code was dated October 1st, 2010.
DSRCS (Dedicated Short-Range Communications Services): a term defined DSRCS (Dedicated Short-Range Communications Services): a term defined
outside the IETF. The use of radio techniques to transfer data over outside the IETF. The use of radio techniques to transfer data over
 End of changes. 15 change blocks. 
20 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/