C Dearlove

T Clausen

BAE Systems Updates: 7188, 7631

This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.

Introduction

The Optimized Link State Routing Protocol version 2 [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] (OLSRv2) is a proactive link state routing protocol designed for use in Mobile Ad Hoc Networks (MANETs) [RFC2501]. One of the significant improvements of OLSRv2 over its Experimental precursor [START_REF] Clausen | Optimized Link State Routing Protocol (OLSR)[END_REF] is the ability of OLSRv2 to use link metrics to select routes other than minimum hop routes.

A limitation that remains in OLSRv2 is that it uses a single link metric type for all routes. However, in some MANETs it would be desirable to be able to route packets using more than one link metric type. This specification describes an extension to OLSRv2 that is designed to permit this, while maintaining maximal interoperability with OLSRv2 routers not implementing this extension.

The purpose of OLSRv2 can be described as to create and maintain a Routing Set, which contains all the necessary information to populate an IP routing table. In a similar way, the role of this extension can be described as to create and maintain multiple Routing Sets, one for each link metric type supported by the router maintaining the sets.

Motivation and Experimentation

Multi-topology routing is a natural extension to a link state routing protocol, such as OSPF (see [START_REF] Psenak | Multi-Topology (MT) Routing in OSPF[END_REF]). However multi-topology routing for OLSRv2 does not yet benefit from extensive operational, or even experimental, experience. This specification is published to facilitate collecting such experience, with the intent that once suitable experimental evidence has been collected, an OLSRv2 Multi-Topology Routing Extension will be proposed for advancement onto the Standards Track.

Any experiments using this protocol extension are encouraged. Reports from such experiments planned with pre-specified objectives and scenarios (including link, position, and mobility information) are particularly encouraged. Results from such experiments, documenting the following, are of particular importance: o Operation in networks that contain both routers implementing this extension and routers implementing only [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]. In particular, are there any unexpected interactions that can break the network?

o Operation in networks with dynamic topologies, both due to mobility and due to link metric changes for reasons other than mobility.

Dearlove & Clausen Experimental [Page 4]

o Operation in realistic deployments, and details thereof, including how many concurrent topologies were required.

o Behavior of Routing Sets, including measures of successful route establishment.

In addition, reports from experiments covering the following are also of value:

o Which link metric types were useful, and how the metrics to associate with a given link were established.

o How packet types were associated with link metric types (whether using Diffserv or an alternative mechanism).

o Any data link-layer issues, and any cross-layer issues, including whether and how Neighborhood Discovery Protocol (NHDP) link quality was used.

o Transport-and higher-layer issues observed, if any.

o Resource requirements observed from running the protocol, including processing, storage, and bandwidth.

o Network performance, including packet delivery results.

o Any other implementation issues.

The first bullet in the list directly above applies to unextended OLSRv2 [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] as well as with this extension, and potentially to other MANET routing protocols. This specification also allows experimentation with link metric types that are not compromises for handling multiple traffic types.

Terminology and Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This specification uses the terminology of [START_REF] Clausen | Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format[END_REF], [START_REF] Clausen | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)[END_REF], and [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], which is to be interpreted as described in those specifications.

Additionally, this specification uses the following terminology:

Router -A MANET router that implements [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

Applicability Statement

The protocol described in this specification is applicable to a MANET for which OLSRv2 is otherwise applicable (see [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], Section 3), but in which multiple topologies are maintained, each characterized by a different choice of link metric type. It is assumed, but outside the scope of this specification, that the network layer is able to choose which topology to use for each packet, for example, using the Diffserv Code Point (DSCP) defined in [RFC2474]. This selection of topology MUST be consistent; that is, each router receiving a packet must make the same choice of link metric type, in order that each packet uses a single topology. This is necessary to avoid the possibility of a packet "looping" in the network.

Protocol Overview and Functioning

The purpose of this specification is to extend OLSRv2 [RFC7181] so as to enable a router to establish and maintain multiple routing topologies in a MANET, each topology associated with a link metric type. Routers in the MANET may each form part of some or all of these topologies, and each router will maintain a Routing Set for each topology that it forms part of, allowing separate routing of packets for each topology.

MT-OLSRv2 is designed to interoperate with OLSRv2; a MANET can be created containing both routers that implement MT-OLSRv2 (MT-OLSRv2 routers) and routers that do not implement MT-OLSRv2 and may be unaware of its existence (non-MT-OLSRv2 routers). MANETs may also be

Dearlove & Clausen Experimental [Page 6]
created that are known to contain only MT-OLSRv2 routers. In both cases, but especially where a MANET contains both MT-OLSRv2 routers and non-MT-OLSRv2 routers, management may be required to ensure that the MANET will function as required, and will not, for example, unnecessarily fragment. (Such issues already arise in an OLSRv2-based MANET using multiple interfaces.)

OLSRv2 is an extension of NHDP [START_REF] Clausen | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)[END_REF]. However, the extension in this specification does not modify NHDP, it only modifies Protocol Sets that are specific to OLSRv2, or elements in Protocol Tuples that were added by OLSRv2 and that are neither included in nor used by NHDP. In addition it does not use or modify the link quality mechanism in [START_REF] Clausen | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)[END_REF].

Each router implementing this specification selects a set of link metric types for each of its OLSRv2 interfaces. If all routers in the MANET implement MT-OLSRv2, then there are no restrictions within this specification on how these sets of link metrics are selected. (However, the issues described in the preceding paragraph still apply.) On the other hand, in MANETs containing non-MT-OLSRv2 routers, the single link metric used by these non-MT-OLSRv2 routers must be included in the set of link metrics for each OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANET.

Each router then determines an incoming link metric for each link metric type selected for each of its OLSRv2 interfaces. These link metrics are distributed using link metric TLVs contained in all HELLO messages sent on OLSRv2 interfaces and in all TC messages. Unless using only the single metric type used by non-MT-OLSRv2 routers, both HELLO and TC messages generated by an MT-OLSRv2 router include an MPR_TYPES Message TLV that indicates that this is an MT-OLSRv2 router and which metric types it supports (on the sending OLSRv2 interface for a HELLO message).

An MT-OLSRv2 router maintains, for each supported neighbour metric type and for each symmetric 1-hop neighbor, the following: Each router may choose a different willingness to be a routing MPR for each link metric type that it supports.

Dearlove & Clausen Experimental [Page 7]

A network using MT-OLSRv2 will usually require greater management than one using unmodified OLSRv2. In particular, the use of multiple metric types across the MANET must be managed, by administrative configuration or otherwise. As also for other decisions that may be made when using OLSRv2, a bad collective choice of metric type use will make the MANET anywhere from inefficient to nonfunctional, so care will be needed in selecting supported link metric types across the MANET.

The meanings of link metric types are at the discretion of the MANET operator. They could be used, for example, to represent packets of different types, packets in streams of different rates, or packets with different trust requirements. Note that packets will generally not be delivered to routers that do not support that link metric type, and the MANET, and the packets sent in it, will need to be managed accordingly (especially if the MANET contains any non-MT-OLSRv2 routers).

Parameters

The parameters used in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], and in its normative references, are used in this specification with the following changes.

Each OLSRv2 interface will support a number of link metric types, corresponding to Type Extensions of the LINK_METRIC TLV defined in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]. The router parameter LINK_METRIC_TYPE, used by routers that do not implement MT-OLSRv2, and used with that definition in this specification, is replaced in routers implementing MT-OLSRv2 by an interface parameter array IFACE_METRIC_TYPES and a router parameter array ROUTER_METRIC_TYPES. Each element in these arrays is a link metric type (i.e., a type extension used by the LINK_METRIC TLV [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]).

The interface parameter array IFACE_METRIC_TYPES contains the link metric types supported on that OLSRv2 interface. The router parameter array ROUTER_METRIC_TYPES is the union of all of the IFACE_METRIC_TYPES. Both arrays MUST be without repetitions.

If in a given deployment there might be routers that do not implement MT-OLSRv2, then IFACE_METRIC_TYPES MUST include LINK_METRIC_TYPE as its first element, so that the OLSRv2 interface can communicate with those routers. In that case, ROUTER_METRIC_TYPES MUST also include LINK_METRIC_TYPE as its first element.

In addition, the router parameter WILL_ROUTING is extended to an array of values, one each for each link metric type in the router parameter list ROUTER_METRIC_TYPES.

Dearlove & Clausen Experimental [Page 8]

Information Bases

The Information Bases specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], which extend those specified in [START_REF] Clausen | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)[END_REF], are further extended in this specification.

With the exception of the Routing Set, the extensions in this specification are the replacement of single values (boolean, willingness, number of hops, or link metric) from [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] with elements representing multiple values (associative mappings from a set of metric types to their corresponding values). The following subsections detail these extensions.

Note that, as in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], an implementation is free to organize its internal data in any manner it chooses; it needs only to behave as if it were organized as described in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] and this specification. Note that some values of TR_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Router Topology Tuples whose corresponding value from TR_metric is UNKNOWN_METRIC are ignored.

Routable Address Topology Set

Each element TA_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].

Note that some values of TA_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Routable Address Topology Tuples whose corresponding value from TA_metric is UNKNOWN_METRIC are ignored. Network Tuples whose corresponding value from AN_metric is UNKNOWN_METRIC are ignored.

Routing Sets

There is a separate Routing Set for each link metric type in ROUTER_METRIC_TYPES.

TLVs

This specification makes the following additions and extensions to the TLVs defined in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

Message TLVs

One new Message TLV is defined in this specification, and one existing Message TLV is extended by this specification.

MPR_TYPES TLV

The MPR_TYPES TLV is used in both HELLO messages sent over OLSRv2 interfaces and TC messages. A message MUST NOT contain more than one MPR_TYPES TLV.

The presence of this TLV in a message is used to indicate that the router supports MT-OLSRv2, in the same way that the presence of the MPR_WILLING TLV is used to indicate that the router supports OLSRv2, as specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]. For this reason, the MPR_TYPES TLV has been defined with the same Type as the MPR_WILLING TLV, but with Type Extension = 1.

This TLV may take a Value field of any size. Each octet in its Value field will contain a link metric type that is supported, either on any OLSRv2 interface, when included in a TC message, or on the OLSRv2 interface on which a HELLO message including this TLV is sent. These octets MAY be in any order, but if there might be routers in the MANET that do not implement MT-OLSRv2, then the first octet MUST be LINK_METRIC_TYPE.

MPR_WILLING TLV

The MPR_WILLING TLV, which is used in HELLO messages, is specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], and extended in this specification as enabled by [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF].

The interpretation of this TLV, which is specified by [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] and uses all of its single-octet Value field, is unchanged. That interpretation uses bits 0-3 of its Value field to specify its

Dearlove & Clausen Experimental [Page 11]
willingness to be a flooding TLV, and bits 4-7 of its Value field to be a routing TLV. Those latter bits are, when using this specification, interpreted as its willingness to be a routing TLV using the link metric type LINK_METRIC_TYPE.

The extended use of this message TLV, as defined by this specification, defines additional 4-bit sub-fields of the Value field, starting with bits 4-7 of the first octet and continuing with bits 0-3 of the second octet, to represent willingness to be a routing MPR using the link metric types specified in this OLSRv2 interface's IFACE_METRIC_TYPES parameter, ordered as reported in the included MPR_TYPES Message TLV. Note that this means that, if there might be any non-MT-OLSRv2 routers, then the link metric type LINK_METRIC_TYPE will continue to occupy bits 4-7 of the first octet.

(If there is no such TLV included, then the router does not support MT-OLSRv2, and only the first octet of the Value field will be used.)

If the number of link metric types in this OLSRv2 interface's IFACE_METRIC_TYPES parameter is even, then there will be an unused 4-bit sub-field in bits 4-7 of the last octet of a full-sized Value field. These bits will not be used; they SHOULD all be cleared ('0') on transmission and MUST be ignored on receipt.

If the Value field in an MPR_WILLING TLV is shorter than its full length, then, as specified in [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF], missing Value octets, i.e., missing willingness values, are considered as zero (WILL_NEVER). This is the correct behavior. (In particular, it means that an OLSRv2 router that is not implementing MT-OLSRv2 will not act as a routing MPR for any link metric that it does not recognize.)

Address Block TLVs

New Type Extensions are defined for the LINK_METRIC TLV defined in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], and the Value fields of the MPR TLV and the GATEWAY TLV, both defined in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], are extended, as enabled by [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF].

LINK_METRIC TLV

The LINK_METRIC TLV is used in HELLO messages and TC messages. This TLV is unchanged from the definition in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

Only a single Type Extension was specified by [RFC7181] --0 for "Link metric meaning as assigned by administrative action". This specification extends it to the range 0-7. This specification will work with any combination of Type Extensions both within and outside that range (assuming that the latter are defined as specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]).

Dearlove & Clausen Experimental [Page 12]

MPR TLV

The MPR TLV is used in HELLO messages and indicates that an address with which it is associated is of a symmetric 1-hop neighbor that has been selected as an MPR.

The Value field of this address block TLV is, in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], defined to be one octet long, with the values 1, 2, and 3 defined. [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF] redefines this Value field to be a bitfield where bit 7 (the least significant bit) denotes flooding status, bit 6 denotes routing MPR status, and bits 5-0 are unallocated (respecting the semantics of the bits/values 1, 2, and 3 from [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]).

This specification, as enabled by [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF], extends the MPR TLV to have a variable-length Value field. Bits are allocated in increasing significance within as many octets as are required. These bits specify, in order, that:

o The neighbor with that network address has been selected as flooding MPR (1 bit).

o The neighbor with that network address has been selected as routing MPR for each link metric type (1 bit each), in the same order as indicated in the Value field of an MPR_TYPES Message TLV.

For interoperability with a router not implementing MT-OLSRv2, the two least significant bits of the first octet in the Value field of this TLV is as the TLV Value of an MPR TLV generated according to [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], as updated by [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF].

GATEWAY TLV

The GATEWAY TLV is used in TC messages to indicate that a network address is of an attached network.

The Value field of this address block TLV is defined by [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] to be one octet long, containing the number of hops to that attached network.

This specification, as enabled by [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF], allows the extension of the GATEWAY TLV to have a variable-length Value field when the number of hops to each attached network is different for different link metric types. For interoperability with a router not implementing MT-OLSRv2, the first octet in the Value field of this TLV MUST be the TLV Value of the GATEWAY TLV generated according to [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]. --------+--------------------------------------------------------- --------+---------------------------------------------------------+ Table 1: GATEWAY TLV Definition

+---------+------------------------------------------------------

---+ | Type | Value | +-

HELLO Messages

The following changes are made to the generation and processing of HELLO messages compared to the description in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] for routers that implement MT-OLSRv2.

HELLO Message Generation

A generated HELLO message to be sent on an OLSRv2 interface (whose IFACE_METRIC_TYPES parameter will be that used) is extended by: o Adding an MPR_TYPES Message TLV. The Value octets will be the link metric types in IFACE_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE.

o Extending the MPR_WILLING Message TLV Value field to report the willingness values from the WILL_ROUTING parameter list that correspond to the link metric types in IFACE_METRIC_LIST, in the same order as reported in the MPR_TYPES TLV, each value (also including one representing WILL_FLOODING) occupying 4 bits.

o Including LINK_METRIC Address Block TLVs that report all values in L_in_metric, L_out_metric, N_in_metric, and N_out_metric elements that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

o Including MPR Address Block TLVs such that for each link metric type in IFACE_METRIC_TYPES, and for the choice of flooding MPRs, the indicated addresses MUST be of the MPRs in an MPR set as specified for a single link metric type in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

Dearlove & Clausen Experimental [Page 14]

HELLO Message Processing

On receipt of a HELLO message on an OLSRv2 interface, a router implementing MT-OLSRv2 MUST do the following, in addition to the processing described in [RFC7181]:

1. If in this deployment there might be routers that do not implement MT-OLSRv2, the HELLO message contains an MPR_TYPES Message TLV, and the first link metric type that it reports is not LINK_METRIC_TYPE, then the HELLO message MUST be silently discarded.

2. Determine the list of link metric types supported by the sending router on its corresponding OLSRv2 interface, either from an MPR_TYPES Message TLV (if present) or from the single link metric type LINK_METRIC_TYPE.

3. For all link metric types reported and supported by the receiving router, set the appropriate L_out_metric, N_in_metric, N_out_metric, N_will_routing, N_mpr_selector, N_advertised, N2_in_metric, and N2_out_metric elements using the rules for setting the single elements of those types specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

4. For any other metric types supported by the receiving router only (i.e. in IFACE_METRIC for the receiving OLSRv2 interface), set the elements listed in the previous point to their default values, i.e., UNKNOWN_METRIC, WILL_NEVER (not WILL_DEFAULT), or false.

TC Messages

The following changes are made to the generation and processing of TC messages compared to that described in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] by routers that implement MT-OLSRv2.

TC Message Generation

A generated TC message is extended by: o Adding an MPR_TYPES TLV. The Value octets will be the link metric types in ROUTER_METRIC_TYPES. This TLV MAY be omitted if the only link metric type included would be LINK_METRIC_TYPE.

o Including LINK_METRIC TLVs that report all values of N_out_metric that are not equal to UNKNOWN_METRIC, with the TLV Type Extension being the link metric type, and otherwise following the rules for such inclusions specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

Dearlove & Clausen Experimental [Page 15]
o Including a number of hops per reported (in an MPR_TYPES Message TLV) link metric type in the Value field of each GATEWAY TLV included, in the same order as reported in the MPR_TYPES TLV.

TC Message Processing

On receipt of a TC message, a router implementing this extension MUST do the following, in addition to the processing specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]:

o If in this deployment there might be routers that do not implement MT-OLSRv2, the TC message contains an MPR_TYPES Message TLV, and the first link metric type that it reports is not LINK_METRIC_TYPE, then the TC message MUST be silently discarded.

o For all link metric types reported and supported by the receiving router, set the appropriate TR_metric, TA_metric, AN_dist, and AN_metric elements using the rules for setting the single elements of those types specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF].

o For any other metric types supported by the receiving router that do not have an advertised outgoing neighbor metric of that type, set the corresponding elements of TR_metric, TA_metric, and AN_metric to UNKNOWN_METRIC. (The corresponding element of AN_dist may be set to any value.)

MPR Calculation

Routing MPRs are calculated for each link metric type in ROUTER_METRIC_TYPES. Links to symmetric 1-hop neighbors via OLSRv2 interfaces that do not support that link metric type are not considered. The determined status (routing MPR or not routing MPR) for each link metric type is recorded in the relevant element of N_routing_mpr.

Each router may make its own decision as to whether or not to use a link metric, or link metrics, for flooding MPR calculation. If using link metric(s), each router decides which one(s) and how they are used. These decisions MUST be made in a manner that ensures that flooded messages will reach the same symmetric 2-hop neighbors as would be the case for a router not supporting MT-OLSRv2.

Note that it is possible that a 2-Hop Tuple in the Information Base for a given OLSRv2 interface does not support any of the link metric types that are in the router's corresponding IFACE_METRIC_TYPES; nevertheless, that 2-Hop Tuple MUST be considered when determining flooding MPRs.

Dearlove & Clausen Experimental [Page 16]

Routing Set Calculation

A Routing Set is calculated for each link metric type in ROUTER_METRIC_TYPES. The calculation may be as for [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], except that where an element is now represented by a map, the value from the map for the selected link metric type is used. Where this is a link metric of value UNKNOWN_METRIC, that protocol Tuple is ignored for the calculation.

12. Management Considerations MT-OLSRv2 may require greater management than unextended OLSRv2. In particular, a MANET using MT-OLSRv2 requires the following management considerations:

o Deciding which link metric, and hence which Routing Set to use, for received packets, hence how to use the Routing Sets to configure the network layer (IP). All routers MUST make the same decision for the same packet. An obvious approach is to map each DSCP [RFC2474] to a single link metric. (This may be a many-toone mapping.)

o Selecting which link metrics to support on each OLSRv2 interface and implementing that decision. (Different interfaces may have different physical and data link-layer properties, and this may inform the selection of link metrics to support, and their values.) If the MANET might contain non-MT-OLSRv2 routers, which are also subject to management, then the rules in this specification for link metric assignment to OLSRv2 interfaces for that case MUST be followed.

o Ensuring that the MANET is sufficiently connected, by ensuring that, for example, sufficiently many routers implement each metric type required. (This is easier in, for example, a denser network.) Note that if there is any possibility that there are routers not implementing MT-OLSRv2, then the MANET will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE, but this will only serve to deliver packets that use that link metric type.

o Non-MT-OLSRv2 routers SHOULD be managed so as not produce packets that will be routed by a topology that they are not part of. However, if that were to happen, then such packets will be routed until either they reach their destination or they reach an MT-OLSRv2 router. In the latter case, the packet then either will be dropped (if that MT-OLSRv2 router is not part of that topology,

Dearlove & Clausen Experimental [Page 17]
or is not aware of the destination within that topology) or will be routed by that topology to the destination. Such a packet will not loop.

o If a packet is created for a destination that is not part of the corresponding topology, then it may or may not be delivered (if the originating router is a non-MT-OLSRv2 router) or will not be sent (if the originating router is an MT-OLSRv2 router). Routers SHOULD be managed so that topologies are as complete as possible and that packets are not sent if they may not be delivered. In particular, non-MT-OLSRv2 routers SHOULD only send packets that will be routed using the topology using the link metric type LINK_METRIC_TYPE.

IANA Considerations

This specification adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV, using a new name. It also modifies the Value field of an existing Message TLV and that of an existing Address Block TLV. Finally, this specification makes additional allocations from the LINK_METRIC Address Block TLV Type registry.

Expert Review: Evaluation Guidelines

For the registry where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [START_REF] Clausen | Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format[END_REF] and [START_REF] Dearlove | TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format[END_REF].

Message TLV Types

This specification modifies the Message TLV Type 7, replacing HELLO and TC message processing is then extended simply to record, for each supported type, all of the received link metric values for each link. Protocol-internal processing (specifically, MPR set and shortest path calculations) then operates as specified in [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] for each link metric type that the router supports.

Consequently, the security considerations, including the security architecture and the mandatory security mechanisms, from [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] are directly applicable to MT-OLSRv2.

Furthermore, this extension does not introduce any additional vulnerabilities beyond those of [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF], because each link metric type is used independently, and each one could have been the single link metric type supported by an implementation of [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] receiving the same information, as received information of an unsupported type is ignored by all routers.

o

  link and neighbour metric values, o routing MPR status, o routing MPR selector status, and o advertised neighbour status.

6. 1 .

 1 Local Attached Network Set Each element AL_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops]. Each element AL_metric becomes a map[ROUTER_METRIC_TYPES -> link metric]. 6.2. Link Sets Each element L_in_metric becomes a map[IFACE_METRIC_TYPES -> link metric]. Each element L_out_metric becomes a map[IFACE_METRIC_TYPES -> link metric]. The elements of L_in_metric MUST be set following the same rules that apply to the setting of the single element L_in_metric in [RFC7181]. 6.3. 2-Hop Sets Each element N2_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric]. Each element N2_out_metric becomes a map[ROUTER_METRIC_TYPES -> link metric]. 6.4. Neighbor Set Each element N_in_metric becomes a map[ROUTER_METRIC_TYPES -> link metric]becomes a map[ROUTER_METRIC_TYPES -> link metric]. Each element N_will_routing becomes a map[ROUTER_METRIC_TYPES -> willingness]. Each element N_routing_mpr becomes a map[ROUTER_METRIC_TYPES -> boolean]. Each element N_mpr_selector becomes a map[ROUTER_METRIC_TYPES -> boolean]. Each element N_advertised becomes a map[ROUTER_METRIC_TYPES -> boolean]. 6.5. Router Topology Set Each element TR_metric becomes a map[ROUTER_METRIC_TYPES -> link metric].

6. 7 .

 7 Attached Network Set Each element AN_dist becomes a map[ROUTER_METRIC_TYPES -> number of hops]. Each element AN_metric becomes a map[ROUTER_METRIC_TYPES -> link metric]. Note that some values of AN_metric may now take the value UNKNOWN_METRIC. When used to construct a Routing Set, where just the corresponding link metric value from this mapping is used, Attached Dearlove & Clausen Experimental [Page 10]

  in the TLV Value field indicate the number of hops to the attached network for each other link metric type. Link metric types (including the first) are ordered as indicated in the Value field of an MPR_TYPES Message TLV.

  + | GATEWAY | Number of hops to attached network for each link metric | | | type. | +-

Table 2 :

 2 Table 4 of [RFC7631] by Table 2, changing the description of the Type Extension MPR_WILLING, and adding the Type Extension TLV_TYPES. Each of these TLVs MUST NOT be included more than once in a Message TLV Block. Type 7 Message TLV Type Extensions

	Dearlove & Clausen	Experimental	[Page 18]

Table 4 :

 4 Type 10 Address Block TLV Type Extensions

	Dearlove & Clausen	Experimental	[Page 20]

Table 13

 13 of[START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF] is replaced by Table5. The only change is that 8 Type Extensions are allocated as assigned by administrative action, in order to support administratively determined multitopologies.

Table 5 :

 5 Address Block TLV Type assignment: LINK_METRIC14. Security ConsiderationsThis extension to OLSRv2 allows a router to support more than one link metric type for each link advertised in HELLO and TC messages, and for routers to support different sets of types. Link metric values of additional types are reported by the inclusion of additional TLVs in the messages sent by a router, which will report known values of all supported types.

Multi-Topology OLSRv2December 2015

December 2015

Acknowledgments

The authors would like to thank (in alphabetical order): Juliusz Chroboczek (University of Paris Diderot), Alan Cullen (BAE Systems), Susan Hares (Huawei), and Henning Rogge (FGAN) for discussions and suggestions.

December 2015 13.3. Address Block TLV Types Table 7 of [START_REF] Dearlove | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs[END_REF] is replaced by Table 3. ------+-------+----------+---------------------------------------- ------+-------+----------+---------------------------------------- ----------+---------+-----------------------------+---------------

+-


T Clausen

Security Threats to Simplified Multicast Forwarding (SMF)

This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.

In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).

Introduction

This document analyzes security threats to Simplified Multicast Forwarding (SMF) [START_REF] Macker | Simplified Multicast Forwarding[END_REF]. SMF aims at providing basic Internet Protocol (IP) multicast forwarding in a way that is suitable for wireless mesh and Mobile Ad Hoc Networks (MANET). SMF consists of two major functional components: duplicate packet detection (DPD) and relay set selection (RSS).

SMF is typically used in decentralized wireless environments and is potentially exposed to various attacks and misconfigurations. In a wireless environment, some of these attacks and misconfigurations represent threats of particular significance as compared to what they would do in wired networks. [START_REF] Macker | Simplified Multicast Forwarding[END_REF] briefly discusses several of these, but does not define any explicit security measures for protecting the integrity of the protocol. This document is based on the assumption that no additional security mechanism, such as IPsec, is used in the IP layer, as not all MANET deployments may be able to support deployment of such common IP protection mechanisms (e.g., because MANET routers may have limited resources for supporting the IPsec stack). It also assumes that there is no lower-layer protection. The document analyzes possible attacks on, and misconfigurations of, SMF and outlines the consequences of such attacks/misconfigurations to the state maintained by SMF in each router.

In the Security Considerations section of [START_REF] Macker | Simplified Multicast Forwarding[END_REF], denial-ofservice-attack scenarios are briefly discussed. This document further analyzes and describes the potential vulnerabilities of, and attack vectors for, SMF. While completeness in such analysis is always a goal, no claims of being complete are made. The goal of this document is to be helpful when deploying SMF in a network and for understanding the risks incurred, as well as for providing a reference to and documented experience with SMF as input for possible future developments of SMF. This document is not intended to propose solutions to the threats described. [START_REF] Herberg | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)[END_REF] provides a framework that can be used with SMF, and depending on how it is used, may offer some degree of protection against the threats related to identity spoofing described in this document.

This document also updates [START_REF] Yi | Security Threats for the Neighborhood Discovery Protocol (NHDP)[END_REF], specifically with respect to threats to relay set selection (RSS) mechanisms that are using MANET NHDP [START_REF] Clausen | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)[END_REF]. Additionally, this document introduces the following terminology: SMF router: A MANET router, running SMF as specified in [START_REF] Macker | Simplified Multicast Forwarding[END_REF].

Attacker: A device that is present in the network and intentionally seeks to compromise the information bases in SMF routers. It may generate syntactically correct SMF control messages.

Legitimate SMF router: An SMF router that is correctly configured and not compromised by an attacker.

SMF Threat Overview

An SMF router requires an external dynamic neighborhood discovery mechanism in order to maintain suitable topological information describing its immediate neighborhood, and thereby allowing it to select reduced relay sets for forwarding multicast data traffic. Such an external dynamic neighborhood discovery mechanism may be provided by lower-layer interface information, by a concurrently operating MANET routing protocol that already maintains such information (e.g., [START_REF] Clausen | The Optimized Link State Routing Protocol Version 2[END_REF]) or by explicitly using the MANET Neighborhood Discovery Protocol (NHDP) [START_REF] Clausen | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)[END_REF]. If NHDP is used for both 1-hop and 2-hop neighborhood discovery by SMF, SMF implicitly inherits the vulnerabilities of NHDP discussed in [START_REF] Yi | Security Threats for the Neighborhood Discovery Protocol (NHDP)[END_REF]. As SMF relies on NHDP to assist in network (1) packets may be retransmitted via the same physical interface as the one over which they were received, and (2) a router may receive multiple copies of the same packet (on the same or on different interfaces) from different neighbors. DPD is thus used to check whether or not an incoming packet has been previously received.

DPD is achieved by maintaining a record of recently processed multicast packets, and comparing later received multicast packets herewith. A duplicate packet detected is silently dropped and is not inserted into the forwarding path of that router, nor is it delivered to an application. DPD, as proposed by SMF, supports both IPv4 and IPv6 and suggests two duplicate packet detection mechanisms for each: 1) IP packet header content identification-based DPD (I-DPD), in combination with flow state, to estimate temporal uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing hashing of selected IP packet header fields and payload for the same effect.

Yi, et al.

Informational [Page 5]

RFC 7985

Security Threats for SMF November 2016

In the Security Considerations section of [START_REF] Macker | Simplified Multicast Forwarding[END_REF], a selection of threats to DPD are briefly introduced. This section expands on that discussion and describes how to effectively launch the attacks on DPD --for example, by way of manipulating jitter and/or the Hash-Assistant Value. In the remainder of this section, common threats to packet detection mechanisms are discussed first; then, the threats to I-DPD and H-DPD are introduced separately. The threats described in this section are applicable to general SMF implementations, regardless of whether NHDP is used.

Attack on the Hop Limit Field

One immediate Denial-of-Service (DoS) attack is based on manipulating the Time-to-Live (TTL, for IPv4) or Hop Limit (for IPv6) field. As routers only forward packets with TTL > 1, an attacker can forward an otherwise valid packet while drastically reducing the TTL hereof. This will inhibit recipient routers from later forwarding the same multicast packet, even if received with a different TTL -essentially, an attacker can thus instruct its neighbors to block the forwarding of valid multicast packets.

For example, in Figure 1, router A forwards a multicast packet with a TTL of 64 to the network. A, B, and C are legitimate SMF routers, and X is an attacker. In a wireless environment, jitter is commonly used to avoid systematic collisions in Media Access Control (MAC) protocols [START_REF] Clausen | Jitter Considerations in Mobile Ad Hoc Networks (MANETs)[END_REF]. An attacker can thus increase the probability that its invalid packets arrive first by retransmitting them without applying jitter. In this example, router X forwards the packet without applying jitter and reduces the TTL to 1. Router C thus records the duplicate detection value (hash value for H-DPD or the header content of the packets for I-DPD) but does not forward the packet (due to TTL == 1). When a second copy of the same packet, with a non-maliciously manipulated TTL value (63 in this case), arrives from router B, it will be discarded as a duplicate packet.

.

---. | X | --'---' __ packet with TTL=64 / \ packet with TTL=1 / \ .---. .---. | A | | C | '---' '---' packet with TTL=64 \ .---. / \--| B |__/ packet with TTL=63 '---' Figure 1 Yi, et al. Informational [Page 6] RFC 7985
Security Threats for SMF November 2016

As the TTL of a packet is intended to be manipulated by intermediaries forwarding it, classic methods such as integrity check values (e.g., digital signatures) are typically calculated by setting TTL fields to some predetermined value (e.g., 0) --for example, the case for IPsec Authentication Headers --rendering such an attack more difficult to both detect and counter.

If the attacker has access to a "wormhole" through the network (a directional antenna, a tunnel to a collaborator, or a wired connection, allowing it to bridge parts of a network otherwise distant), it can make sure that the packets with such an artificially reduced TTL arrive before their unmodified counterparts.

Threats to

As SMF does not currently have any timestamp mechanisms to protect data packets, there is no viable way to detect such pre-play attacks by way of timestamps. Especially, if the attack is based on manipulation of jitter, the validation of the timestamp would not be helpful because the timing is still valid (but, much less valuable).

De-activation Attacks (Sequence Number Wrangling)

An attacker can also seek to de-activate DPD by modifying the sequence number in packets that it forwards. Thus, routers will not be able to detect an actual duplicate packet as a duplicate -rather, they will treat them as new packets, i.e., process and forward them. This is similar to DoS attacks, as each packet that is considered unique will be multicasted: for a network with n routers, there will be n-1 retransmissions. This can easily cause the "broadcast storm" problem discussed in [START_REF] Ni | The broadcast storm problem in a mobile ad hoc network[END_REF]. The consequence of this attack is an increased channel load, the origin of which appears to be a router other than the attacker.

Given the topology shown in Figure 2, on receiving a packet with seq=n, the attacker X can forward the packet with a modified sequence number n+i. This has two consequences: firstly, router C will not be able to detect that the packet forwarded by X is a duplicate packet; secondly, the consequent packet with seq=n+i generated by router A will probably be treated as a duplicate packet and will be dropped by router C. When explicit sequence numbers in packet headers is undesired, hashbased DPD can be used. A hash of the non-mutable fields in the header of the data payload can be generated and recorded at the intermediate routers. A packet can thus be uniquely identified by the source IP address of the packet and its hash-value.

The hash algorithm used by SMF is being applied only to provide a reduced probability of collision and is not being used for cryptographic or authentication purposes. Consequently, a digest collision is still possible. In case the source router or gateway identifies that it has recently generated or injected a packet with the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 header option into the packet, such that also calculating the hash over this HAV will render the resulting value unique.

Attack on the Hash-Assistant Value

The HAV header is helpful when a digest collision happens. However, it also introduces a potential vulnerability. As the HAV option is only added when the source or the ingress SMF router detects that the incoming packet has digest collision with previously generated packets, it can actually be regarded as a "flag" of potential digest collision. An attacker can discover the HAV header and be able to conclude that a hash collision is possible if the HAV header is removed. By doing so, the modified packet received by other SMF routers will be treated as duplicate packets and will be dropped because they have the same hash value as previously received packets.

In the example shown in Figure 3, routers A and B are legitimate SMF routers; X is an attacker. Router A generates two packets, P1 and P2, with the same hash value h(P1)=h(P2)=x. Based on the SMF specification, a HAV is added to the latter packet P2, so that h(P2+HAV)=x' avoids digest collision. When the attacker X detects the HAV of P2, it is able to conclude that a collision is possible by removing the HAV header. By doing so, packet P2 will be treated as a duplicate packet by router B and will be dropped. --------------------------> | X | ----------------------> | B | '---' '---' '---'

P2 P1 P2 P1 .---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---. | A |-
Yi, et al.

Informational [Page 9]

RFC 7985

Security Threats for SMF November 2016

Threats to Relay Set Selection

A framework for an RSS mechanism, rather than a specific RSS algorithm, is provided by SMF. Relay Set Selection is normally achieved by distributed algorithms that can dynamically generate a topological Connected Dominating Set based on 1-hop and 2-hop neighborhood information. In this section, common threats to the RSS framework are first discussed. Then specific threats to the three algorithms (Essential Connection Dominating Set (E-CDS), Source-Based Multipoint Relay (S-MPR), and Multipoint Relay Connected Dominating Set (MPR-CDS)) explicitly enumerated by [START_REF] Macker | Simplified Multicast Forwarding[END_REF] are analyzed. As the relay set selection is based on 1-hop and 2-hop neighborhood information, which rely on NHDP, the threats described in this section are NHDP specific.

Common Threats to Relay Set Selection

Non-algorithm-specific threats to RSS algorithms, including DoS attacks, eavesdropping, message timing attacks, and broadcast storm, are discussed in [START_REF] Yi | Security Threats for the Neighborhood Discovery Protocol (NHDP)[END_REF].

Threats to the E-CDS Algorithm

The "Essential Connected Dominating Set" (E-CDS) algorithm [START_REF] Ogier | Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding[END_REF] forms a single CDS mesh for an SMF operating region. This algorithm requires 2-hop neighborhood information (the identity of the neighbors, the link to the neighbors, and the neighbors' priority information), as collected through NHDP or another process.

An SMF router will select itself as a relay, if:

o The SMF router has a higher priority than all of its symmetric neighbors, or o A path from the neighbor with the largest priority to any other neighbor via neighbors with greater priority than the current router does not exist.

An attacker can disrupt the E-CDS algorithm by link spoofing or identity spoofing. Link spoofing implies that an attacker advertises non-existing links to another router (which may or may not be present in the network).

An attacker can declare itself to have high route priority and spoof the links to as many legitimate SMF routers as possible to declare high connectivity. By doing so, it can prevent legitimate SMF routers from selecting themselves as relays. As the "super" relay in the network, the attacker can manipulate the traffic it relays.

Identity Spoofing

Identity spoofing implies that an attacker determines and makes use of the identity of other legitimate routers, without being authorized to do so. The identity of other routers can be obtained by eavesdropping the control messages or the source/destination address from datagrams. The attacker can then generate control or datagram traffic by pretending to be a legitimate router.

Because E-CDS self-selection is based on the router priority value, an attacker can spoof the identity of other legitimate routers and declare a different router priority value. If it declares that a spoofed router has a higher priority, it can prevent other routers from selecting themselves as relays. On the other hand, if the attacker declares that a spoofed router has a lower priority, it can force other routers to select themselves as relays to degrade the multicast forwarding to classical flooding.

Threats to S-MPR Algorithm

The S-MPR set selection algorithm enables individual routers, using 2-hop topology information, to select relays from among their set of neighboring routers. MPRs are selected by each router such that a message generated by it, and relayed only by its MPRs, will reach all of its 2-hop neighbors.

An SMF router forwards a multicast packet if and only if: o the packet has not been received before, and o the neighbor from which the packet was received has selected the router as MPR.

Because MPR calculation is based on the willingness declared by the SMF routers and the connectivity of the routers, it can be disrupted by both link spoofing and identity spoofing. These threats and their impacts have been illustrated in Section 5.1 of [START_REF] Yi | Security Threats for the Neighborhood Discovery Protocol (NHDP)[END_REF]. As MPR-CDS combines E-CDS and S-MPR and the simple combination of the two algorithms does not address the weaknesses; the vulnerabilities of E-CDS and S-MPR that are discussed in Sections 5.2 and 5.3 apply to MPR-CDS also.

Security Considerations

This document does not specify a protocol or a procedure. The whole document, however, reflects on security considerations for SMF regarding packet dissemination in MANETs. Possible attacks to the two main functional components of SMF, duplicate packet detection, and relay set selection are analyzed and documented.

Although neither [START_REF] Macker | Simplified Multicast Forwarding[END_REF] nor this document propose mechanisms to secure the SMF protocol, there are several possibilities to secure the protocol in the future and drive new work by suggesting which threats discussed in the previous sections could be addressed.

For the I-DPD mechanism, employing randomized packet sequence numbers can avoid some pre-activation attacks based on sequence number prediction. If predicable sequence numbers have to be used, applying timestamps can mitigate pre-activation attacks.

For the H-DPD mechanism, applying cryptographically strong hashes can make the digest collisions effectively impossible, and it can avoid the use of a HAV.

[RFC7182] specifies a framework for representing cryptographic Integrity Check Values (ICVs) and timestamps in MANETs. Based on [START_REF] Herberg | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)[END_REF], [START_REF] Herberg | Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)[END_REF] specifies integrity and replay protection for NHDP using shared keys as a mandatory-to-implement security mechanism. If SMF is using NHDP as the neighborhood discovery protocol, implementing [START_REF] Herberg | Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)[END_REF] remains advisable so as to enable integrity protection for NHDP control messages. This can help mitigate threats related to identity spoofing through the exchange of HELLO messages and provide some general protection against identity spoofing by admitting only trusted routers to the network using ICVs in HELLO messages. Using ICVs does not, of course, address the problem of attackers able to also generate valid ICVs. Detection and exclusion of such attackers is, in general, a challenge that is not unrelated to how [START_REF] Herberg | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)[END_REF] is used. If, for example, it is used with a shared key (as per [START_REF] Herberg | Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)[END_REF]), excluding single attackers generally is not aided by the use of ICVs. However, if routers have sufficient capabilities to support the use of asymmetric keys (as per [START_REF] Dearlove | Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols[END_REF]), part of addressing this challenge becomes one of providing key revocation in a way that does not in itself introduce additional vulnerabilities.

As [START_REF] Herberg | Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)[END_REF] does not protect the integrity of the multicast user datagram, and as no mechanism is specified by SMF for doing so, duplicate packet detection remains vulnerable to the threats introduced in Section 4.

If pre-activation/de-activation attacks and attacks on the HAV of the multicast datagrams are to be mitigated, a datagram-level integrity protection mechanism is desired, by taking consideration of the identity field or HAV. However, this would not be helpful for the attacks on the TTL (or Hop Limit for IPv6) field, because the mutable fields are generally not considered when ICV is calculated.

Yi

  Identification-Based Duplicate Packet Detection I-DPD uses a specific DPD identifier in the packet header to identify a packet. By default, such packet identification is not provided by the IP packet header (for both IPv4 and IPv6). Therefore, additional identification headers, such as the fragment header, a hop-by-hop header option, or IPsec sequencing, must be employed in order to support I-DPD. The uniqueness of a packet can then be identified by the source IP address of the packet originator and the sequence number (from the fragment header, hop-by-hop header option, or IPsec). By doing so, each intermediate router can keep a record of recently received packets and determine whether or not the incoming packet has been received. Figure2gives an example of a pre-activation attack. A, B, and C are legitimate SMF routers, and X is the attacker. The line between the routers presents the packet forwarding. Router A is the source and originates a multicast packet with sequence number n. When router X receives the packet, it generates an invalid packet with the source address of A and sequence number n. If the invalid packet arrives at router C before the forwarding of router B, the valid dropped by C as a duplicate packet. An attacker can manipulate jitter to make sure that the invalid packets arrive first. Router X can even generate packets with future sequence numbers (if they are predictable), so that the future legitimate packets with the same sequence numbers will be dropped as duplicate ones.

	RFC 7985	Security Threats for SMF	November 2016
	packet will be .---.
				| X |
			--'---' __
	packet with seq=n	/	\ invalid packet with seq=n
			/		\
		.---.		.---.
		| A |		| C |
		'---'		'---'
	packet with seq=n	\	.---.	/
			\--| B |__/ valid packet with seq=n
				'---'
	Yi, et al.		Informational	[Page 7]

4.2.1. Pre-Activation Attacks (Pre-Play)

In a wireless environment, or across any other shared channel, an attacker can perceive the identification tuple (source IP address, sequence number) of a packet. It is possible to generate a packet with the same (source IP address, sequence number) pair with invalid content. If the sequence number progression is predictable, then it is trivial to generate and inject invalid packets with "future" identification information into the network. If these invalid packets arrive before the legitimate packets that they are spoofing, the latter will be treated as a duplicate and will be discarded. This can prevent multicast packets from reaching parts of the network.

  Threats to the MPR-CDS Algorithm MPR-CDS is a derivative from S-MPR. The main difference between S-MPR and MPR-CDS is that while S-MPR forms a different broadcast tree for each source in the network, MPR-CDS forms a unique broadcast tree for all sources in the network.

	RFC 7985	Security Threats for SMF	November 2016
	5.4.
	Yi, et al.	Informational	[Page 11]

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Yi, et al. Informational [Page 2] Acknowledgments The authors would like to thank Christopher Dearlove (BAE Systems ATC) who provided detailed review and valuable comments. Authors' Addresses Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex France Phone: +33 1 77 57 80 85 Email: jiazi@jiaziyi.com URI: http://www.jiaziyi.com/ Thomas Heide Clausen Ecole Polytechnique 91128 Palaiseau Cedex France Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.thomasclausen.org/ Ulrich Herberg Email: ulrich@herberg.name URI: http://www.herberg.name/