Re: [ipwave] rereview of draft-ietf-ipwave-ipv6-over-80211ocb-45

[Nabil Benamar <[e-mail]>]

Here is a final point in the security section:

OLD:


The potential attack vectors are: MAC address spoofing, IP address and
session hijacking, and privacy violation Section 5.1
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-5.1>
.



NEW:


The potential attack vectors are: MAC address spoofing, IP address and
session hijacking, and privacy violation Section 5.1
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-5.1>.
A previous work at SAVI WG presents some threats [RFC 6959], and a
beginning of a solution is given in
https://datatracker.ietf.org/doc/draft-bi-savi-wlan/.   Also, SeND
presented in RFC 3971 and RFC 3972 is is a solution against address theft
but it is complex and not deployed. In the context of WiND, the
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd provides a complete
solution


Best regards
Nabil Benamar
-------------------
نبيل بنعمرو







On Tue, May 28, 2019 at 12:46 PM Nabil Benamar <[e-mail]> wrote:

> Hi Pascal,
>
> Thank you for your comments. Please see ALL the changes that will be
> reflected in version -46. Let me know what is missing?
>
>
>
> Abstract
>
>
> OLD:
>
>
> 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 how IPv6 (including addressing and
>
>    basic ND) can be used to communicate among nodes in range of one
>
>    another over IEEE 802.11-OCB.  Optimizations and usage of IPv6 over
>
>    more complex scenarios is not covered and is subject of future work.
>
>
>
>
> NEW:
>
>
>
> 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
>
>         provides methods and settings, and describes limitations,
>
>         for using IPv6 to communicate among nodes in range of one another
>
>         over a single IEEE 802.11-OCB link with minimal change to
> existing stacks.
>
>         Optimizations and usage of IPv6 over more complex scenarios
>
>         is not covered and is subject of future work.
>
>
>
>
> Introduction
>
>
>
> OLD:
>
>
> The IPv6 network layer operates on 802.11-OCB in the same manner as
>
>    operating on Ethernet, but there are two kinds of exceptions:
>
>
>    o  Exceptions due to different operation of IPv6 network layer on
>
>       802.11 than on Ethernet.  To satisfy these exceptions, this
>
>       document describes an Ethernet Adaptation Layer between Ethernet
>
>       headers and 802.11 headers.  The Ethernet Adaptation Layer is
>
>       described Section 4.2.1
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4.2.1>
> .  The operation of IP on Ethernet is
>
>       described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [
> RFC2464 <https://tools.ietf.org/html/rfc2464>] .
>
>
>
>
>
> NEW:
>
>
> The IPv6 network layer operates on 802.11-OCB in the same manner as
>
>    operating on Ethernet, but there are two kinds of exceptions:
>
>
>    o  Exceptions due to different operation of IPv6 network layer on
>
>       802.11 than on Ethernet. The operation of IP on Ethernet is
>
>       described in [RFC1042 <https://tools.ietf.org/html/rfc1042>], [
> RFC2464 <https://tools.ietf.org/html/rfc2464>] .
>
>
>
> 3.  Communication Scenarios where IEEE 802.11-OCB Links are Used
>
>
>
>
> OLD:
>
>
>
>    The IEEE 802.11-OCB Networks are used for vehicular communications,
>
>    as 'Wireless Access in Vehicular Environments'.  The IP communication
>
>    scenarios for these environments have been described in several
>
>    documents;
>
>
>
>
> NEW:
>
>
> The IEEE 802.11-OCB Networks are used for vehicular communications,
>
> as 'Wireless Access in Vehicular Environments’. In particular, we refer
> the reader to [I-D.ietf-ipwave-vehicular-networking], that lists some
> scenarios and  requirements for IP in Intelligent Transportation Systems.
>
>
>
> OLD:
>
>
> The link model is the following: STA --- 802.11-OCB --- STA.  In
>
>    vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.  While
>
>    802.11-OCB is clearly specified, and the use of IPv6 over such link
>
>    is not radically new, the operating environment (vehicular networks)
>
>    brings in new perspectives.
>
>
>
> NEW:
>
>
>
> The link model is the following: STA --- 802.11-OCB --- STA.
>
> In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs.
>
>     All links are assumed to be P2P and multiple
>
>     links can be on one radio interface. While 802.11-OCB is clearly  specified,
> and the use of IPv6 over such link is not radically new, the operating
> environment (vehicular networks) brings in new perspectives.
>
>
>
> *4*
> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#section-4>*.
> IPv6 over 802.11-OCB*
>
>
>
> OLD:
>
>
>
> The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.  It
>
>    is the same value as IPv6 packets on Ethernet links, as specified in
>
>    [RFC2464 <https://tools.ietf.org/html/rfc2464>].  This value of the
> MTU respects the recommendation that
>
>    every link on the Internet must have a minimum MTU of 1280 octets.
>
>
>
>
> NEW:
>
>
>
> The default MTU for IP packets on 802.11-OCB is inherited
>
>           from RFC2464 and is 1500 octets. This value
>
>           of the MTU respects the recommendation that every link on
>
>           the Internet must have a minimum MTU of 1280 octets (stated
>
>           in <xref target="RFC8200"/>, and the recommendations
>
>           therein, especially with respect to fragmentation).
>
>
>
>
> 4.2.  Frame Format
>
>
>
>
> OLD:
>
>
>
>    IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>
>    frames whose format is specified in IEEE 802.11(TM) -2016
>
>    [IEEE-802.11-2016].
>
>
>
> NEW:
>
>
>    IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>
>    frames whose format is specified in IEEE 802.11 spec.
>
>
>
> OLD:
>
>
> The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>
> preceded by a Logical Link Control (LLC) header and an 802.11 header.
>
>
>
> NEW:
>
>
> IPv6 packet transmitted on 802.11-OCB are immediately preceded
>
> by a Logical Link Control (LLC) header and an 802.11 header
>
>
>
> OLD:
>
>
> In the 802.11 header, the value of the
>
>    Subtype sub-field in the Frame Control field MUST be set to 8 (i.e.
>
>    'QoS Data'); the value of the Traffic Identifier (TID) sub-field of
>
>    the QoS Control field of the 802.11 header MUST be set to binary 001
>
>    (i.e.  User Priority 'Background', QoS Access Category 'AC_BK').
>
>
> NEW:
>
>
>  The mapping to the 802.11 data service MUST
>
>  use a ‘priority’ value of 1, which specifies the use of QoS
>
>  with a “Background” user priority.
>
>
>
> OLD:
>
>
> To simplify the Application Programming Interface (API) between the
>
>    operating system and the 802.11-OCB media, device drivers MAY
>
>    implement an Ethernet Adaptation Layer that translates Ethernet II
>
>    frames to the 802.11 format and vice versa.  An Ethernet Adaptation
>
>    Layer is described in
>
>
> NEW:
>
>
>
> To simplify the Application Programming Interface (API)
>
>   between the operating system and the 802.11-OCB media,
>
>   device drivers MAY implement IPv6 over Ethernet per RFC 2464
>
>       and then a frame translation from 802.3 to 802.11 in order
>
>       to  minimize the code changes.
>
>
>
> OLD:
>
>
> 4.4.  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.
>
>
>
> NEW:
>
>
> The steps a host takes in deciding how to
>
>       autoconfigure its interfaces in IP version 6 are described in <xref
>
>   target='RFC4862'/>. 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 <xref
>
>   target='ll'/>.
>
>
>
> OLD:
>
>
> The Interface Identifier for an 802.11-OCB interface is formed using
>
>    the same rules as the Interface Identifier for an Ethernet interface;
>
>
>
> NEW:
>
>
> The RECOMMENDED method for forming
>
>           stable Interface Identifiers (IIDs) is described in <xref
>
>           target='RFC8064'/>.  The method of forming IIDs described in
>
>           section 4 of <xref target='RFC2464'/> MAY be used during
>
>           transition time, in particular for IPv6 link-local
>
>           addresses.
>
>
>
> OLD:
>
>
> 4.5.1.  Address Mapping -- Unicast
>
>
>
>    The procedure for mapping IPv6 unicast addresses into Ethernet link-
>
>    layer addresses is described in [RFC4861].
>
>
>
> NEW:
>
>
>
> 4.5.1.  Address Mapping -- Unicast
>
>
>
>    This draft is scoped for AR and DAD per RFC 4861.
>
>
>
>
> OLD:
>
>
>
> 4.5.2.  Address Mapping -- Multicast
>
>
>
> <Snap>
>
>                                              These issues may be
>
>    exacerbated in OCB mode.  Solutions for these problems SHOULD
>
>    consider the OCB mode of operation.
>
>
>
> NEW:
>
>
>
> These issues may be exacerbated in OCB mode.  Future improvement to this
> specification SHOULD consider solutions for these problems.
>
>
>
> OLD:
>
>
> The subnet structure on which the Neighbor Discovery
>
>   protocol (ND) on OCB works ok is a single-link subnet; the
>
>   status of ND operation on a subnet that covers multiple OCB
>
>   links that repeat the signal at PHY layer, or the messages
>
>   at MAC layer, is unknown.
>
>
>
> NEW:
>
>
>
> An IPv6 subnet on which Neighbor Discovery protocol (ND) can be used
>
> can be mapped on an OCB network iff all nodes share a single broadcast
>
> Domain, which is generally the case for P2P OCB links;
>
> the status of ND operation on a subnet that covers multiple OCB links
>
> That are not fully overlapping (NBMA) is not in scope.
>
> OLD:
>
> The baseline Neighbor Discovery protocol (ND) [RFC4861
> <https://tools.ietf.org/html/rfc4861>] MUST be used over 802.11-OCB links.
>
>
> NEW:
>
> The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be supported
> over 802.11-OCB links.
>
>
>  OLD:
>
>
> Transmitting ND packets may prove to have
>
>    some performance issues.  These issues may be exacerbated in OCB
>
>    mode.  Solutions for these problems SHOULD consider the OCB mode of
>
>    operation.  The best of current knowledge indicates the kinds of
>
>    issues that may arise with ND in OCB mode; they are described in
>
>    Appendix J.
>
>
> NEW:
>
>
> Transmitting ND packets may prove to have some performance issues.  These
> issues may be exacerbated in OCB
>
>    mode.  Future solutions to OCB should consider solutions for avoiding
> broadcast.  The best of current knowledge indicates the kinds of issues
> that may arise with ND in OCB mode; they are described in Appendix J.
>
>
> OLD:
>
>
> 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.  $
>
>
> NEW:
>
>
> Removed
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
>
>
>
>
>
>
>
> On Tue, May 28, 2019 at 8:49 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
>> Hello Nabil:
>>
>>
>>
>> In the next rev I expect to see text in the intro that states the scope
>> of reusing legacy stacks with minimal changes.
>>
>>
>>
>> Expressed that way, the discussion on legacy ND only and using the
>> Ethernet distribution system and then a frame translation to 802.11, all
>> makes full sense.
>>
>> Also, this prepares for the work that the group has already started,
>> which involves new stack elements better suited for OCB.
>>
>>
>>
>> This should also be in the title. Suggestion for the new title:
>>
>>
>>
>>
>>
>> Minimal support for IPv6 over IEEE Std 802.11 Networks operating Outside
>> the Context of a Basic Service Set
>>
>>
>>
>>
>>
>> The ‘minimal’ avoids the risk that the reader thinks that this draft has
>> it all and that IPWAVE can close after that.
>>
>>
>>
>> All the best,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Nabil Benamar <[e-mail]>
>> *Sent:* lundi 27 mai 2019 17:12
>> *To:* Pascal Thubert (pthubert) <[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* Re: [ipwave] rereview of
>> draft-ietf-ipwave-ipv6-over-80211ocb-45
>>
>>
>>
>> Hi Pascal,
>>
>>
>>
>> We are converging :)
>>
>>
>>
>> See below
>>
>>
>>
>>
>>
>> Best regards
>>
>> Nabil Benamar
>>
>> -------------------
>>
>> نبيل بنعمرو
>>
>>
>>
>>
>>
>>
>>
>> On Mon, May 27, 2019 at 2:47 PM Pascal Thubert (pthubert) <
>> [e-mail]> wrote:
>>
>> Hello Nabil:
>>
>>
>>
>> I removed the places where we already agree. Please see below for the
>> remaining details
>>
>>
>>
>> Ø  This should be out of scope and inherited from IPv6 over WiFi. If the
>> draft does not exist then let us do one, at 6MAN.
>>
>> Yes, I support this idea to initiate a new draft in 6MAN. I'm in!
>>
>> Ø  The introduction should clatify the scope, which appears to be do
>> with what existing stacks can do and (sometimes) see what’s missing.
>>
>> Here is the new introduction (first paragraph), are we missing something
>> else?
>>
>>
>>
>> "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
>>
>> of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC
>>
>> layer. Compared to running IPv6 over the Ethernet MAC layer, there
>>
>> is no modification expected to IEEE Std 802.11 MAC and Logical Link
>>
>> sublayers: IPv6 works normally over a single IEEE 802.11-OCB link,
>>
>> with an LLC layer. Multi-link scenarios are out of scope for the
>>
>> present document."
>>
>>
>>
>>
>>
>> Pascal, I have just received a detailed review from some IEEE-802.11
>> members, thanks to Dorothy! One of the recommendation is to remove section
>> 4.2.1 completely.
>>
>>
>>
>> Ø    Good, we are converging.
>>
>>
>>
>>
>>
>>
>>
>> I agree. It seems that by describing specific values, the text is
>> redundant with what’s already in IEEE Std 802.11-2016
>>
>>
>>    - In the <reference> tag to the IEEE spec just use <date/> . This
>>    actually removes the date. Also please remove -2016 from the spec name,
>>    just leave generic 802.11 dateless.
>>
>> Ok.
>>
>>
>>    -
>>    - Placing a date is misguided since we do not have a dependency on
>>    one particular version of 802.11. Indeed we want your spec to apply to all
>>    versions starting current, which is what is implied by dateless.
>>
>> That's perfect.
>>
>>
>>    -
>>
>>
>>
>>
>>
>>
>>
>> Ø  Are we sure of that, don’t we map QoS from ToS bits as usual with 11e?
>>
>>
>>
>> Here is the new text to replace that paragraph:
>>
>>
>>
>> " “The IPv6 packet transmitted on 802.11-OCB MUST be immediately
>> preceded by a Logical Link Control (LLC) header and an 802.11 header. In
>> the LLC header, and in accordance with the EtherType Protocol
>> Discrimination (EPD, see Appendix E
>> <https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-45#appendix-E>),
>> the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to
>> the 802.11 data service MUST use a ‘priority’ value of 1, which specifies
>> the use of QoS with a “Background” user priority."
>>
>>
>>
>> Ø    Can’t we use different QoS values like we can on WiFi?
>>
>> That was the recommendation of IEEE 802.11 members, and I updated the
>> draft based on your review and their recommendations. Please feel free to
>> suggest other text here.
>>
>>
>>
>>
>>
>>
>>
>>    To simplify the Application Programming Interface (API) between the
>>
>>    operating system and the 802.11-OCB media, device drivers MAY
>>
>>    implement an Ethernet Adaptation Layer that translates Ethernet II
>>
>>    frames to the 802.11 format and vice versa.  An Ethernet Adaptation
>>
>>    Layer is described in Section 4.2.1.
>>
>>
>>
>> Ø  Do not call that an adaptation layer. The may refers to using an
>> Ethernet stack and then a translation from Ethernet Frames to 802.11 frames
>> as specified by IEEE.
>>
>> What do you suggest instead?
>>
>>
>>
>>
>>
>> Ø    Maybe that “an implementation may IPv6 over Ethernet per RFC 2464
>> and then a frame translation from 802.3 to 802.11 in order to  minimize the
>> code changes”.
>>
>> Ø    If minimal impact on the stack is the actual goal of this draft,
>> which I think it is. This is what justifies publish this hastily and then
>> do the real work that implies larger changes.
>>
>> Ø
>>
>> Sounds good for me!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 4.4.  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.
>>
>>
>>
>> Ø  Not really interesting. More important is to say that autoconf is
>> defined in RFC 4862 and that is missing.
>>
>> Didn't get your point! What is missing?
>>
>>
>>
>>
>>
>>
>>
>> Ø    IPv6 autoconf is described in RFC 4862. This section does not refer
>> to it, but rather duplicates the previous about address types, which is far
>> from interesting.
>>
>> Ø    I suggest you remove the text above and add a sentence that roughly
>> introduce RFC 4862. Note that RFC 8505 does not change the
>> autoconfiguration though it changes the way DAD is achieved.
>>
>>
>>
>>
>>
>> Ok. I will include it in -46
>>
>>
>>
>>
>>
>> Ø  MUST +> MAY. Say the scope of this doc only considers ND but neither
>> RFC 8505 nor IPWAVE drafts.
>>
>>
>>
>> Here is the new text as agreed last time with Brian:
>>
>>
>>
>> "The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be
>>
>> supported over 802.11-OCB links."
>>
>>
>>
>>
>>
>>
>>
>> Ø   Yes, that works.
>>
>>
>>
>>
>>
>> Ø  Remove or turn it the other way around like future solutions to OCB
>> should consider solutions for avoiding broadcast.
>>
>> I will reformulate in the following manner:
>>
>>
>>
>> Transmitting ND packets may prove to have some performance issues.
>> These issues may be exacerbated in OCB
>>
>>    mode.  Future solutions to OCB should consider solutions for avoiding
>> broadcast.  The best of current knowledge indicates the kinds of issues
>> that may arise with ND in OCB mode; they are described in Appendix J.
>>
>>
>>
>>
>>
>> Ø    Good
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> All the best,
>>
>>
>>
>> Pascal
>>
>>
>>
>>
>>
>> Thank you once again.
>>
>>
>>
>> I will publish version 46 soon.
>>
>>
>>
>>
>>
>>
>>
>> Ø    Please ping me when done; do not forget to scope the document so
>> that it is minimizing changes to existing stack and leveraging Ethernet
>> implementation, with IPv6 ND and so on, and a focus on P2P over link local.
>>
>>
>>
>> All the best,
>>
>>
>>
>> Pascal
>>
>>
>>
>> Thank you, Pascal for your time.
>>
>