draft-ietf-ipwave-ipv6-over-80211ocb-50.txt   draft-ietf-ipwave-ipv6-over-80211ocb-51.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 21, 2020 Eurecom Expires: January 25, 2020 Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
July 20, 2019 July 24, 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 (IPv6-over-80211-OCB) the Context of a Basic Service Set
draft-ietf-ipwave-ipv6-over-80211ocb-50 draft-ietf-ipwave-ipv6-over-80211ocb-51
Abstract Abstract
This document provides methods and settings, and describes This document provides methods and settings, for using IPv6 to
limitations, for using IPv6 to communicate among nodes in range of communicate among nodes within range of one another over a single
one another over a single IEEE 802.11-OCB link. This support does IEEE 802.11-OCB link. Support for these methods and settings require
only require minimal changes to existing stacks. Optimizations and minimal changes to existing stacks. This document also describes
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 21, 2020. This Internet-Draft will expire on January 25, 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 2, line 30 skipping to change at page 2, line 33
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5
4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5
4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6
4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6
4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8
5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9
5.2. MAC Address and Interface ID Generation . . . . . . . . . 9 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9
5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10 5.3. Pseudonymization impact on confidentiality and trust . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16
Appendix C. Changes Needed on a software driver 802.11a to Appendix C. Changes Needed on a software driver 802.11a to
become a 802.11-OCB driver . . . . . . . . . . . . . 21 become a 802.11-OCB driver . . . . . . . . . . . . . 20
Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22 Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 21
Appendix E. Design Considerations . . . . . . . . . . . . . . . 23 Appendix E. Design Considerations . . . . . . . . . . . . . . . 22
Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 22
Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23
G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24
G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 26
Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 28
Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless
Links . . . . . . . . . . . . . . . . . . . . . . . 30 Links . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document provides a baseline with limitations for using IPv6 to This document provides a baseline for using IPv6 to communicate among
communicate among nodes in range of one another over a single IEEE nodes in range of one another over a single IEEE 802.11-OCB link
802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and
Appendix B and Appendix C) with minimal changes to existing stacks. Appendix C) with minimal changes to existing stacks. Moreover, the
Moreover, the document identifies limitations of such usage. document identifies limitations of such usage. Concretely, the
Concretely, the document describes the layering of IPv6 networking on document describes the layering of IPv6 networking on top of the IEEE
top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame
with a frame translation underneath. The resulting stack inherits translation underneath. The resulting stack inherits from IPv6 over
from IPv6 over Ethernet [RFC2464], but operates over 802.11-OCB to Ethernet [RFC2464], but operates over 802.11-OCB to provide at least
provide at least P2P (Point to Point) connectivity using IPv6 ND and P2P (Point to Point) connectivity using IPv6 ND and link-local
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.
This has impacts on security, privacy, subnet structure and This has impacts on security, privacy, subnet structure and
skipping to change at page 4, line 44 skipping to change at page 4, line 45
are assumed to be P2P and multiple links can be on one radio are assumed to be P2P and multiple links can be on one radio
interface. While 802.11-OCB is clearly specified, and a legacy IPv6 interface. While 802.11-OCB is clearly specified, and a legacy IPv6
stack can operate on such links, the use of the operating environment stack can operate on such links, the use of the operating environment
(vehicular networks) brings in new perspectives. (vehicular networks) brings in new perspectives.
4. IPv6 over 802.11-OCB 4. IPv6 over 802.11-OCB
4.1. Maximum Transmission Unit (MTU) 4.1. Maximum Transmission Unit (MTU)
The default MTU for IP packets on 802.11-OCB is inherited from The default MTU for IP packets on 802.11-OCB is inherited from
[RFC2464] and is, as such, 1500 octets. This value of the MTU [RFC2464] and is, as such, 1500 octets. As noted in [RFC8200], every
respects the recommendation that every link on the Internet must have link on the Internet must have a minimum MTU of 1280 octets, as well
a minimum MTU of 1280 octets (stated in [RFC8200], and the as follow the other recommendations, especially with regard to
recommendations therein, especially with respect to fragmentation). fragmentation.
4.2. Frame Format 4.2. Frame Format
IP packets MUST be transmitted over 802.11-OCB media as QoS Data IP packets MUST be transmitted over 802.11-OCB media as QoS Data
frames whose format is specified in IEEE 802.11 spec frames whose format is specified in IEEE 802.11 spec
[IEEE-802.11-2016]. [IEEE-802.11-2016].
The IPv6 packet transmitted on 802.11-OCB are immediately preceded by The IPv6 packet transmitted on 802.11-OCB are immediately preceded by
a Logical Link Control (LLC) header and an 802.11 header. In the LLC a Logical Link Control (LLC) header and an 802.11 header. In the LLC
header, and in accordance with the EtherType Protocol Discrimination header, and in accordance with the EtherType Protocol Discrimination
skipping to change at page 5, line 36 skipping to change at page 5, line 36
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.
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 A 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
The steps a host takes in deciding how to autoconfigure its The steps a host takes in deciding how to autoconfigure its
interfaces in IPv6 are described in [RFC4862]. This section interfaces in IPv6 are described in [RFC4862]. This section
describes the formation of Interface Identifiers for IPv6 addresses describes the formation of Interface Identifiers for IPv6 addresses
of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6 of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6
address of type 'Link-Local' are discussed in Section 4.3. address of type 'Link-Local' are discussed in Section 4.3.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
document [IEEE-1609.2] provides security services for certain document [IEEE-1609.2] provides security services for certain
applications to use; application-layer mechanisms are out of scope of applications to use; application-layer mechanisms are out of scope of
this document. On another hand, a security mechanism provided at this document. On another hand, a security mechanism provided at
networking layer, such as IPsec [RFC4301], may provide data security networking layer, such as IPsec [RFC4301], may provide data security
protection to a wider range of applications. protection to a wider range of applications.
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 carda€™s frequency to the proper setting an interface card's frequency to the proper range). Also, an
range). Also, an attacker may not heed to legal limits for radio attacker may not heed to legal limits for radio power and can use a
power and can use a very sensitive directional antenna; if attackers very sensitive directional antenna; if attackers wishe to attack a
wishe to attack a given exchange they do not necessarily need to be given exchange they do not necessarily need to be in close physical
in close physical proximity. Hence, such a link is less protected proximity. Hence, such a link is less protected than commonly used
than commonly used links (wired link or protected 802.11). links (wired link or protected 802.11).
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.A 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]),
the identifier of an 802.11-OCB interface may involve privacy, MAC the identifier of an 802.11-OCB interface may involve privacy, MAC
address spoofing and IP hijacking risks. A vehicle embarking an IP- address spoofing and IP hijacking risks. A vehicle embarking an IP-
OBU whose egress interface is 802.11-OCB may expose itself to OBU whose egress interface is 802.11-OCB may expose itself to
eavesdropping and subsequent correlation of data. This may reveal eavesdropping and subsequent correlation of data. This may reveal
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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 may
be used with input a 256 bit local secret, the 'nominal' MAC Address be used with input a 256 bit local secret, the 'nominal' MAC Address
of the interface, and a representation of the date and time of the of the interface, and a representation of the date and time of the
renumbering event. 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. Pseudonym Handling 5.3. Pseudonymization impact on confidentiality and trust
The demand for privacy protection of vehicles' and drivers'
identities, which could be granted by using a pseudonym or alias
identity at the same time, may hamper the required confidentiality of
messages and trust between participants - especially in safety
critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism
used relies on (randomized) re-addressing.
o A proper pseudonymization tool operated by a trusted third party
may be needed to ensure both aspects simultaneously (privacy
protection on one hand and trust between participants on another
hand).
o This is discussed in Section 4.4 and Section 5 of this document.
o Pseudonymity is also discussed in Vehicles 'and drivers' privacy relies on pseudonymization mechanisms
[I-D.ietf-ipwave-vehicular-networking] in its sections 4.2.4 and such as the ones described in Section 5.2. This pseudonymization
5.1.2. means that upper-layer protocols and applications SHOULD NOT rely on
layer-2 or layer-3 addresses to assume that the other participant can
be trusted.
6. IANA Considerations 6. IANA Considerations
No request to IANA. No request to IANA.
7. Contributors 7. Contributors
Christian Huitema, Tony Li. Christian Huitema, Tony Li.
Romain Kuntz contributed extensively about IPv6 handovers between Romain Kuntz contributed extensively about IPv6 handovers between
skipping to change at page 11, line 28 skipping to change at page 11, line 17
The authors would like to thank Alexandre Petrescu for initiating The authors would like to thank Alexandre Petrescu for initiating
this work and for being the lead author until the version 43 of this this work and for being the lead author until the version 43 of this
draft. draft.
The authors would like to thank Pascal Thubert for reviewing, The authors would like to thank Pascal Thubert for reviewing,
proofreading and suggesting modifications of this document. proofreading and suggesting modifications of this document.
The authors would like to thank Mohamed Boucadair for proofreading The authors would like to thank Mohamed Boucadair for proofreading
and suggesting modifications of this document. and suggesting modifications of this document.
The authors would like to thank Eric Vyncke for reviewing suggesting
modifications of this document.
The authors would like to thank Witold Klaudel, Ryuji Wakikawa, The authors would like to thank Witold Klaudel, Ryuji Wakikawa,
Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray
Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,
Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,
Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,
Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra
Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun,
Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in
't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,
 End of changes. 17 change blocks. 
61 lines changed or deleted 52 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/