--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-25.txt 2018-09-07 03:13:08.023517279 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-26.txt 2018-09-07 03:13:08.103519217 -0700 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: December 21, 2018 Moulay Ismail University +Expires: March 11, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - June 19, 2018 + September 7, 2018 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) - draft-ietf-ipwave-ipv6-over-80211ocb-25 + draft-ietf-ipwave-ipv6-over-80211ocb-26 Abstract In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 21, 2018. + This Internet-Draft will expire on March 11, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,40 +68,40 @@ 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 9 + 5.2. MAC Address Generation . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15 - Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 23 - Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23 + Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 24 + Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 24 Appendix D. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver . . . 28 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 29 Appendix F. Design Considerations . . . . . . . . . . . . . . . 30 F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 30 - F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 + F.2. Reliability Requirements . . . . . . . . . . . . . . . . 31 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31 - F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 32 - Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 - Appendix H. Implementation Status . . . . . . . . . . . . . . . 32 + Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 32 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 36 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document describes the transmission of IPv6 packets on IEEE Std 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix B, Appendix C and Appendix D). This involves the layering @@ -273,28 +273,29 @@ | 802.11 PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Ethernet Adaptation Layer stacked with other layers (in the above figure, a 802.11 profile is represented; this is used also for 802.11-OCB profile.) 4.3. Link-Local Addresses - The link-local address of an 802.11-OCB interface is formed in the - same manner as on an Ethernet interface. This manner is described in - section 5 of [RFC2464]. Additionally, if stable identifiers are - needed, it is RECOMMENDED to follow the Recommendation on Stable IPv6 - Interface Identifiers [RFC8064]. Additionally, if semantically - opaque Interface Identifiers are needed, a potential method for - generating semantically opaque Interface Identifiers with IPv6 - Stateless Address Autoconfiguration is given in [RFC7217]. + There are several types of IPv6 addresses [RFC4291], [RFC4193], that + MAY be assigned to an 802.11-OCB interface. Among these types of + addresses only the IPv6 link-local addresses MAY be 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 + used to form an IPv6 link-local address on Ethernet links. This + mechanism is described in section 5 of [RFC2464]. 4.4. Address Mapping Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. 4.4.1. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [RFC4861]. @@ -307,67 +308,67 @@ of [RFC7042]. Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues [I-D.perkins-intarea-multicast-ieee802]. These issues may be exacerbated in OCB mode. Solutions for these problems should consider the OCB mode of operation. 4.5. Stateless Autoconfiguration + There are several types of IPv6 addresses [RFC4291], [RFC4193], that + MAY be assigned to an 802.11-OCB interface. This section describes + the formation of Interface Identifiers for IPv6 addresses of type + 'Global' or 'Unique Local'. For Interface Identifiers for IPv6 + address of type 'Link-Local' see Section 4.3. + The Interface Identifier for an 802.11-OCB interface is formed using the same rules as the Interface Identifier for an Ethernet interface; the RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in [RFC8064]. The method of forming IIDs described in section 4 of [RFC2464] MAY be used during transition time. - The bits in the interface identifier have no generic meaning and the + The bits in the Interface Identifier have no generic meaning and the identifier should be treated as an opaque value. The bits 'Universal' and 'Group' in the identifier of an 802.11-OCB interface are significant, as this is an IEEE link-layer address. The details - of this significance are described in [RFC7136]. - - As with all Ethernet and 802.11 interface identifiers ([RFC7721]), - the identifier of an 802.11-OCB interface may involve privacy, MAC - address spoofing and IP address hijacking risks. A vehicle embarking - an OBU or an IP-OBU whose egress interface is 802.11-OCB may expose - itself to eavesdropping and subsequent correlation of data; this may - reveal data considered private by the vehicle owner; there is a risk - of being tracked; see the privacy considerations described in - Appendix F. + of this significance are described in [RFC7136]. If semantically + opaque Interface Identifiers are needed, a potential method for + generating semantically opaque Interface Identifiers with IPv6 + Stateless Address Autoconfiguration is given in [RFC7217]. - If stable Interface Identifiers are needed in order to form IPv6 - addresses on 802.11-OCB links, it is recommended to follow the - recommendation in [RFC8064]. Additionally, if semantically opaque - Interface Identifiers are needed, a potential method for generating - semantically opaque Interface Identifiers with IPv6 Stateless Address - Autoconfiguration is given in [RFC7217]. + The way Interface Identifiers are used MAY involve risks to privacy, + as described in Section 5.1. 4.6. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles - that are in close range (not their on-board interfaces). This - ephemeral subnet structure is strongly influenced by the mobility of - vehicles: the 802.11 hidden node effects appear. On another hand, - the structure of the internal subnets in each car is relatively - stable. + that are in close range (not by their in-vehicle interfaces). This + subnet MUST use at least the link-local prefix fe80::/10 and the + interfaces MUST be assigned IPv6 addresses of type link-local. This + subnet MAY NOT have any other prefix than the link-local prefix. - The 802.11 networks in OCB mode may be considered as 'ad-hoc' - networks. The addressing model for such networks is described in - [RFC5889]. + The structure of this subnet is ephemeral, in that it is strongly + influenced by the mobility of vehicles: the 802.11 hidden node + effects appear; the 802.11 networks in OCB mode may be considered as + 'ad-hoc' networks with an addressing model as described in [RFC5889]. + On another hand, the structure of the internal subnets in each car is + relatively stable. - The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB - links is different than over 802.11 links. In OCB, the link layer - does not ensure that all associated members receive all messages, - because there is no association operation. Neighbor Discovery (ND) - is used over 802.11-OCB. + As recommended in [RFC5889], when the timing requirements are very + strict (e.g. fast drive through IP-RSU coverage), no on-link subnet + prefix should be configured on an 802.11-OCB interface. In such + cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. + + The Neighbor Discovery protocol (ND) [RFC4861] is used over + 802.11-OCB links. The operation of the Mobile IPv6 protocol over 802.11-OCB links is different than on other links. The Movement Detection operation (section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability Detection operation of the Neighbor Discovery protocol, for the reason mentioned in the previous paragraph. Also, the 802.11-OCB link layer is not a lower layer that can provide an indication that a link layer handover has occured. The operation of the Mobile IPv6 protocol over 802.11-OCB is not specified in this document. @@ -400,33 +401,63 @@ Within the IPsec Security Architecture [RFC4301], the IPsec AH and ESP headers [RFC4302] and [RFC4303] respectively, its multicast extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols can be used to protect communications. Further, the assistance of proper Public Key Infrastructure (PKI) protocols [RFC4210] is necessary to establish credentials. More IETF protocols are available in the toolbox of the IP security protocol designer. Certain ETSI protocols related to security protocols in Intelligent Transportation Systems are described in [ETSI-sec-archi]. - As with all Ethernet and 802.11 interface identifiers, there may - exist privacy risks in the use of 802.11-OCB interface identifiers. - Moreover, in outdoors vehicular settings, the privacy risks are more - important than in indoors settings. New risks are induced by the - possibility of attacker sniffers deployed along routes which listen - for IP packets of vehicles passing by. For this reason, in the - 802.11-OCB deployments, there is a strong necessity to use protection - tools such as dynamically changing MAC addresses. This may help - mitigate privacy risks to a certain level. On another hand, it may - have an impact in the way typical IPv6 address auto-configuration is - performed for vehicles (SLAAC would rely on MAC addresses and would - hence dynamically change the affected IP address), in the way the - IPv6 Privacy addresses were used, and other effects. +5.1. Privacy Considerations + + As with all Ethernet and 802.11 interface identifiers ([RFC7721]), + the identifier of an 802.11-OCB interface may involve privacy, MAC + address spoofing and IP address hijacking risks. A vehicle embarking + an IP-OBU whose egress interface is 802.11-OCB may expose itself to + eavesdropping and subsequent correlation of data; this may reveal + data considered private by the vehicle owner; there is a risk of + being tracked. In outdoors public environments, where vehicles + typically circulate, the privacy risks are more important than in + indoors settings. It is highly likely that attacker sniffers are + deployed along routes which listen for IEEE frames, including IP + packets, of vehicles passing by. For this reason, in the 802.11-OCB + deployments, there is a strong necessity to use protection tools such + as dynamically changing MAC addresses. This may help mitigate + privacy risks to a certain level. + +5.2. MAC Address Generation + + In 802.11-OCB networks, the MAC addresses MAY change during well + defined renumbering events. In the moment the MAC address is changed + on an 802.11-OCB interface all the Interface Identifiers of IPv6 + addresses assigned to that interface MUST change. + + The policy dictating when the MAC address is changed on the + 802.11-OCB interface is to-be-determined. For more information on + the motivation of this policy please refer to the privacy discussion + in Appendix C. + + A 'randomized' MAC address has the following characteristics: + + o Bit "Local/Global" set to "locally admninistered". + + o Bit "Unicast/Multicast" set to "Unicast". + + o The 46 remaining bits are set to a random value, using a random + number generator that meets the requirements of [RFC4086]. + + To meet the randomization requirements for the 46 remaining bits, a + 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 + of the interface, and a representation of the date and time of the + renumbering event. 6. IANA Considerations No request to IANA. 7. Contributors Christian Huitema, Tony Li. Romain Kuntz contributed extensively about IPv6 handovers between @@ -499,26 +530,34 @@ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, + . + [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, . + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, @@ -649,20 +688,29 @@ document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". Appendix A. ChangeLog The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. + -26: moved text from SLAAC section and from Design Considerations + appendix about privacy into a new Privacy Condiderations subsection + of the Security section; reformulated the SLAAC and IID sections to + stress only LLs can use EUI-64; removed the "GeoIP" wireshark + explanation; reformulated SLAAC and LL sections; added brief mention + of need of use LLs; clarified text about MAC address changes; dropped + pseudonym discussion; changed title of section describing examples of + packet formats. + -25: added a reference to 'IEEE Management Information Base', instead of just 'Management Information Base'; added ref to further appendices in the introductory phrases; improved text for IID formation for SLAAC, inserting recommendation for RFC8064 before RFC2464. From draft-ietf-ipwave-ipv6-over-80211ocb-23 to draft-ietf-ipwave- ipv6-over-80211ocb-24 o Nit: wrote "IPWAVE Working Group" on the front page, instead of @@ -1244,25 +1289,20 @@ strong privacy requirements with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses, in these settings there exists a strong need for dynamic change of these addresses (as opposed to the non- vehicular settings - real wall protection - where fixed MAC addresses do not currently pose some privacy risks). This is further described in Section 5. A relevant function is described in IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE 1609.4-2016 [IEEE-1609.4], clause 6.7. - Other aspects particular to 802.11-OCB, which are also particular to - 802.11 (e.g. the 'hidden node' operation), may have an influence on - the use of transmission of IPv6 packets on 802.11-OCB networks. The - OCB subnet structure is described in Section 4.6. - Appendix D. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver The 802.11p amendment modifies both the 802.11 stack's physical and MAC layers but all the induced modifications can be quite easily obtained by modifying an existing 802.11a ad-hoc stack. Conditions for a 802.11a hardware to be 802.11-OCB compliant: o The PHY entity shall be an orthogonal frequency division @@ -1434,59 +1474,36 @@ single packet. Treating each wireless interface as a separate network interface pushes such issues to the application layer. Certain privacy requirements imply that if these multiple interfaces are represented by many network interface, a single renumbering event shall cause renumbering of all these interfaces. If one MAC changed and another stayed constant, external observers would be able to correlate old and new values, and the privacy benefits of randomization would be lost. - The privacy requirements of Non IP safety-critical communications - imply that if a change of pseudonyme occurs, renumbering of all other - interfaces shall also occur. - -F.4. MAC Address Generation - - In 802.11-OCB networks, the MAC addresses may change during well - defined renumbering events. A 'randomized' MAC address has the - following characteristics: - - o Bit "Local/Global" set to "locally admninistered". - - o Bit "Unicast/Multicast" set to "Unicast". - - o The 46 remaining bits are set to a random value, using a random - number generator that meets the requirements of [RFC4086]. - - To meet the randomization requirements for the 46 remaining bits, a - 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 - of the interface, and a representation of the date and time of the - renumbering event. - Appendix G. IEEE 802.11 Messages Transmitted in OCB mode For information, at the time of writing, this is the list of IEEE 802.11 messages that may be transmitted in OCB mode, i.e. when dot11OCBActivated is true in a STA: o The STA may send management frames of subtype Action and, if the STA maintains a TSF Timer, subtype Timing Advertisement; o The STA may send control frames, except those of subtype PS-Poll, CF-End, and CF-End plus CFAck; o The STA may send data frames of subtype Data, Null, QoS Data, and QoS Null. -Appendix H. Implementation Status +Appendix H. Examples of Packet Formats This section describes an example of an IPv6 Packet captured over a IEEE 802.11-OCB link. By way of example we show that there is no modification in the headers when transmitted over 802.11-OCB networks - they are transmitted like any other 802.11 and Ethernet packets. We describe an experiment of capturing an IPv6 packet on an 802.11-OCB link. In topology depicted in Figure 5, the packet is an @@ -1619,29 +1636,21 @@ value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise #86DD), recognized as "IPv6". A Router Advertisement is periodically sent by the router to multicast group address ff02::1. It is an icmp packet type 134. The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags, as described in [RFC4861]. The IPv6 header contains the link local address of the router (source) configured via EUI-64 algorithm, and destination address set - to ff02::1. Recent versions of network protocol analyzers (e.g. - - Wireshark) provide additional informations for an IP address, if a - geolocalization database is present. In this example, the - geolocalization database is absent, and the "GeoIP" information is - set to unknown for both source and destination addresses (although - the IPv6 source and destination addresses are set to useful values). - This "GeoIP" can be a useful information to look up the city, - country, AS number, and other information for an IP address. + to ff02::1. The Ethernet Type field in the logical-link control header is set to 0x86dd which indicates that the frame transports an IPv6 packet. In the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 which is the corresponding multicast MAC address. The BSS id is a broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link duration between vehicles and the roadside infrastructure, there is no need in IEEE 802.11-OCB to wait for the completion of association and authentication procedures before exchanging data. IEEE 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s)