Internet S. Rass Internet-Draft Universitaet Klagenfurt Intended status: Informational Y. Qu Expires: September 12, 2019 L. Han Huawei March 11, 2019 Multipath Use Case and Requirement for Security draft-rass-panrg-mpath-usecase-00 Abstract This document describes a use case of multipath to achieve full CIA+ by using symmetric cryptography and point-to-point shared secrets. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 September 12, 2019. Copyright Notice Copyright (c) 2019 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rass, et al. Expires September 12, 2019 [Page 1]

Internet-Draft Mpath security use case March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multipath Routing . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Multi-path Service and User-Network Interface . . . . . . 4 3.2. Path and Routing Reliability . . . . . . . . . . . . . . 4 3.3. Cross Domain Path Reliability . . . . . . . . . . . . . . 5 3.4. Cross Domain Network Connections . . . . . . . . . . . . 5 3.5. Updates upon Changing Network Topologies . . . . . . . . 5 3.6. Enforced Device Pairing and De-Pairing . . . . . . . . . 6 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Cryptographic and Graph-Theoretic Basics . . . . . . 9 A.1. Secret Sharing . . . . . . . . . . . . . . . . . . . . . 9 A.2. Network Connectivity . . . . . . . . . . . . . . . . . . 9 Appendix B. Multipath Transmission and Game-Theoretic Security . 10 B.1. End-to-end Confidentiality - Parallel Version . . . . . . 10 B.2. End-to-end Confidentiality - Sequential-Parallel Version 10 B.3. Randomized Routing to Maximize Security against Node (Failures) . . . . . . . . . . . . . . . . . . . . . . . 11 B.4. Availability . . . . . . . . . . . . . . . . . . . . . . 12 B.5. End-to-End Authenticity . . . . . . . . . . . . . . . . . 12 B.5.1. Non-Repudiation . . . . . . . . . . . . . . . . . . . 13 B.6. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Public-key cryptography is a convenient tool for end-to-end security, but in practice can be cumbersome or complicated for non-expert users to apply. Certificate- and key management rely on complex infrastructures and to a significant extent impose monetary cost and human effort. This document describes a method of using symmetric cryptography and point-to-point shared secrets to establish full CIA+ (confidentiality, integrity, availability and authenticity) end-to- end security. The respective schemes rely on multipath transmission and threshold cryptography, and are intended to work transparently for the users, i.e., entirely below the application layer. The only involvement of human action is for the key establishment, which is in Rass, et al. Expires September 12, 2019 [Page 2]

Internet-Draft Mpath security use case March 2019 our setting equivalent to a pairing of devices, as is familiar from other contexts, such as Bluetooth. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Assumptions We assume a network of bidirectional links, represented as an undirected graph G=(V,E). An edge e=(v_1, v_2) in the set E represents a point-to-point connection between the nodes v_1 and v_2 in the network. We assume that every such pair (v_i, v_j) in E shares an individual secret k_ij, which is individually distinct for all edges (i.e., no two pairs have, other than by coincidence, the same secret). The secret exchange or establishment is left to arbitrary means, e.g., any device pairing scheme [I-D.ietf-dnssd-pairing] or cryptographic methods like Diffie-Hellman key exchange [RFC2631] would be admissible, up to quantum key distribution [BB84]. Indeed, end-to-end security in quantum networks is the most natural application area of multipath transmission as we discuss here. We further assume that keys between adjacent nodes in the network have been exchanged in an authentic manner; say, by sufficient proximity during the device pairing (e.g., near field communication). 3. Multipath Routing Multipath routing offers the remarking ability of establishing public-key like security without computational intractability. This means that periodic updates of keys or server certificates are no longer required in such systems; updates to keys for symmetric crypto are much easier by device re-pairing or refreshing keys from existing key material, such as is done in quantum key distribution (QKD). Multipath transmission, requiring no quantum technology per se, offers nonetheless the same level of security QKD [BB84] and can resist attacks by quantum computers (like post-quantum cryptography [BD08]). The key element to this end is using multiple paths to send a message, which in the simplest instance is just like humble symmetric encryption: consider two nodes A and B that have no direct connection between them (i.e., A and B are several hops apart). Let us assume that two paths connect A to B, where those paths intersect only at A and B (we call such paths node-disjoint). If so, then A can choose a Rass, et al. Expires September 12, 2019 [Page 3]

Internet-Draft Mpath security use case March 2019 session key k that it sends to B over the first path, and deliver the encrypted payload over the second path. If the encryption is chosen properly (e.g., Vernam cipher [Ver55]) and the adversary does not intercept both paths, the connection remains secure. The scheme straightforwardly generalizes to more than two paths, where the payload is (always) split into shares and transmitted over separate paths in parallel or sequentially. Security comes from the proper encoding/creation of the pieces so that an attacker needs to intercept a certain number of paths in order to breach confidentiality, insert a forged message, or cause a denial of service. The fundamental circumstance implying security here is the existence of k (>= 2) node and link disjoint paths, so that an adversary needs to conquer at least k nodes in the network to breach security (by mounting a person-in-the-middle attack). Security (up to QKD without trusted relays) thus hinges on the following network-related assumptions: 3.1. Multi-path Service and User-Network Interface There are at least two disjoint paths between node A and node B, so A can send packets to node B via different paths efficiently and reliably. New User-Network Interface (UNI) should be defined to exchange information between end device/application and network. The information may include but not limited to: o User expectation: such as number of paths, bandwidth required etc. o Path aware info: the network should dynamically provide end-device information such as number of paths available, each path's attributes: path reliability, routing quality, bandwidth, path elements etc. 3.2. Path and Routing Reliability The sender A can deliberately choose any among the existing paths to its receiver B to transmit a message. The routing is reliable in the sense that there is at least a probabilistic guarantee for the packet to travel over exactly the chosen route with a likelihood p that A can quantify (not necessarily control). In other words, the chances for the path to be blocked, or for the packet to take a detour for any reason (e.g., load balancing, temporary congestions, or similar) is at most 1-p, with the value of p being known to A. The ideal case p = 1 expresses that the chosen route has a perfect reliability (i.e., no deviations and guaranteed delivery). Rass, et al. Expires September 12, 2019 [Page 4]

Internet-Draft Mpath security use case March 2019 It is admissible to express the path reliability in terms of several such probabilities, referring to different dimensions for the quality of service. That is, we may define a probability p_1 for the packet to stay on the chosen route, another probability p_2 for the packet to be delivered at all (i.e., not being blocked), or similar. There are per se no stringent constraints regarding latencies or for several packets to arrive in the order of transmission, since the outer (cryptographic) transmission protocols can handle this. However, the aforementioned probabilities quantifying the quality of routing need to be accurately known to the sender A. Suitable protocols to handle path deviations (temporary detours) and to optimize quality-of-service tradeoffs based on such knowledge are found in the literature [Ras13], [RK12]. 3.3. Cross Domain Path Reliability If two distinct network domains are joined together, the topologies of both networks are reliably made known to the nodes in the respective other network. Chosen routes from one network into the other must remain quantifiably reliable in the sense of section 3.2 above, i.e., a node A in one network must still be able to determine a probability p for a packet to stay on its route and to arrive at the designated destination across all network domains that it traverses. 3.4. Cross Domain Network Connections Whenever a node A has an outside connection to a node in another network domain N_2, A should not have a second connection to another node in the same network domain N_2. That is, if two network domains N_1 and N_2 are joined together via k links, those links should pairwise connect k distinct nodes in N_1 to another k distinct nodes in N_2. This assures that the so-constructed larger network retains the necessary number of (at least) k node disjoint paths across the domains (by avoiding bottle-neck connections between networks N_1 and N_2). 3.5. Updates upon Changing Network Topologies The information described under the preceding sections needs to remain up-to-date whenever A wishes to send a packet somewhere. Changing topologies such as in ad hoc networks call for a proper and reliable updating scheme to A's local information about the network topology. This includes also changes in topologies of remote network domains (that the sender does not itself belong to). Rass, et al. Expires September 12, 2019 [Page 5]

Internet-Draft Mpath security use case March 2019 3.6. Enforced Device Pairing and De-Pairing Whenever a node X joins a network, it must establish shared secrets (for cryptography) with any neighbor with whom it has a direct point- to-point connection. Whenever a node X leaves the network, nodes losing the connection to X need to abandon their cryptographic key formerly assigned to the connection with X. The key exchange protocols can be arbitrary (cf. section 2), but the device pairing must in any case be authenticated. 4. Summary The ability to route messages along chosen paths in a network, together with sufficient vertex connectivity and unique neighborhoods for each node opens up the possibility to achieve end-to-end security: o without public-key cryptography. o using only light-weight symmetric cryptographic primitives (encryption and hashing). o and with the most trivial key-management consisting of only the exchange of keys between directly connected devices (along device pairing). 5. Security Considerations TBD. 6. Acknowledgements TBD. 7. References 7.1. Normative References [I-D.ietf-dnssd-pairing] Huitema, C. and D. Kaiser, "Device Pairing Using Short Authentication Strings", draft-ietf-dnssd-pairing-05 (work in progress), October 2018. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>. Rass, et al. Expires September 12, 2019 [Page 6]

Internet-Draft Mpath security use case March 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, <https://www.rfc-editor.org/info/rfc2631>. [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, DOI 10.17487/RFC5510, April 2009, <https://www.rfc-editor.org/info/rfc5510>. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>. 7.2. Informative References [FFGV07] Matthias Fitzi, Matthew K. Franklin, Juan Garay, and S. Harsha Vardhan, TCC, LNCS, vol. 4392, Springer, 2007, pp. 311--322., "Towards Optimal and Efficient Perfectly Secure Message Transmission". [MS81] R. J. McElice and D. V. Sarwate, Commun. ACM 24 (1981), no. 9, 583--584., "On Sharing Secrets and Reed-Solomon Codes". [Ras13] Stefan Rass, Springer Journal of Network and Systems Management 21 (2013), no. 1, 47--64., "On Game-Theoretic Network Security Provisioning". [Ras14] Stefan Rass, International Journal of Advanced Computer Science and Applications 5 (2014), no. 2, 148--157., "Complexity of Network Design for Private Communication and the P-vs-NP question". [Ras18] Stefan Rass, CoRR abs/1810.05602 (2018)., "Perfectly secure communication, based on graph- topological addressing in unique-neighborhood networks". [RS10] Stefan Rass and Peter Schartner, Proceedings of the International Conference on Security and Management (SAM), vol. 1, CSREA Press, 2010, pp. 111--115., "Multipath Authentication without shared Secrets and with Applications in Quantum Networks". Rass, et al. Expires September 12, 2019 [Page 7]

Internet-Draft Mpath security use case March 2019 [Sha49] C. E. Shannon, Bell System Technical Journal 28 (1949), 656--715., "Communication Theory of Secrecy Systems". [Sha79] Adi Shamir, ACM 22 (1979), no. 11, 612--613., "How to share a secret". Rass, et al. Expires September 12, 2019 [Page 8]

Internet-Draft Mpath security use case March 2019 Appendix A. Cryptographic and Graph-Theoretic Basics A.1. Secret Sharing We assume a message m to come as a binary string of length L. A simple k-out-of-k secret sharing is by picking a set of k-1 random strings s_1, s_2, ..., s_(k-1) of the same length as m and computes s_k := m XOR s_1 XOR s_2 XOR ... XOR s_(k-1). Information- theoretically, one can prove [Sha49] that the recovery of m is impossible from any set of less than k of the strings s_1, ..., s_k (since the missing string effectively acts as a one-time pad concealing m). The sharing as just described is replaceable by more sophisticated schemes, such as Shamir's polynomial sharing [Sha79], which adds error correction capabilities [MS81] via using an isomorphy to Reed- Solomon encoding. We shall, however, hereafter not further relate to standardized versions of Reed-Solomon forward error correcting codes [LRPP09], but rather work with the above simple scheme instead. Abstractly, we shall introduce a sharing function SPLIT(m, k) that decomposes an input message m into a set of k shares according to any scheme of choice (for the description in this document, the above XOR-based scheme will suffice). The inverse of SPLIT will be the function COMBINE(s_1, ..., s_k), taking k (out of a potentially larger set) of shares to reconstruct the message m from it. Note that COMBINE internally may invoke error correction algorithms [LRPP09], which we do not further expand here. A.2. Network Connectivity If a node A wants to transmit a message m to a node B, we assume that A can choose a path, or a set of paths through the network along a physical connection (over multiple hops) to the end-node B. Further, we assume that the network's node connectivity is such that more than one route from A to B exists, and that at least two routes exist that do not intersect other than at A and B (node-disjoint paths). It is known that the existence of k node-disjoint paths is equivalent to the graph admitting a k-vertex cut; equivalently, we call such a graph k-vertex-connected. The smallest graph with that property is the complete graph with k+1 nodes. Furthermore, if two k-vertex- connected graphs are given, we can combine them into one (big) k- vertex connected graph G as follows: we pick k distinct nodes u_1, ..., u_k in G_1 and another k distinct nodes v_1, ..., v_k in G_2, and connect the two graphs by adding edges (u_i, v_i) for all i=1,2,...,k. The resulting graph contains all nodes and edges from G_1 and G_2, plus the connecting edges between the two graphs. It is provably a k-vertex-connected graph, admitting at least k node- Rass, et al. Expires September 12, 2019 [Page 9]

Internet-Draft Mpath security use case March 2019 disjoint paths between any two nodes in either graph and from any node in G_1 to any node in G_2 and vice versa. While it may not be too optimistic to hope for a large k in the existing internet topology, matters of resilience against failure of single nodes in the network call for a least k=2, so that the network remains connected if one node (and hence the adjacent edge) fails. Let A's available routes to B be enumerated as R_1, ..., R_k, which A picks with likelihoods p_1, ..., p_k, say, p_i := 1/i for an equiprobable choice of a single route. Moreover, we let each transmission use their point-to-point shared secrets to encrypt a message along the network edge (v_i, v_j) under the key k_ij (e.g., by means of the Advanced Encryption Standard or others). Appendix B. Multipath Transmission and Game-Theoretic Security B.1. End-to-end Confidentiality - Parallel Version To confidentially transmit the message m, A proceeds as follows: 1. Decompose m into shares {s_1, ..., s_k} := SPLIT(m) 2. Send each share s_i over the route R_i (for i = 1, ..., k) in parallel to B. 3. B, upon receiving all shares recovers the message as m := COMBINE(r_1, ..., r_k). By construction, the attacker needs to gather all k shares to recover m, so that if the attacker can intercept only less than k paths, the message m remains perfectly concealed (by the aforementioned arguments). A picture of the scheme is found at https://www.syssec.at/user/themes/syssec-theme/images/publikationen/ MPTrans.png B.2. End-to-end Confidentiality - Sequential-Parallel Version The above scheme can be further strengthened by a two-stage sharing as follows: as before, let m the message that A wishes to send to B in perfect privacy. It proceeds as follows: 1. Decompose m into n shares {s_1, ..., s_n} := SPLIT(m) 2. For i = 1, 2, ..., n: send each share s_i by the parallel scheme described above; resulting in the transmission of shares r_i1, ..., r_ik for the share s_i Rass, et al. Expires September 12, 2019 [Page 10]

Internet-Draft Mpath security use case March 2019 3. The receiver B then needs to (i) reconstruct every share s_i := COMBINE(r_i1, ..., r_ik) (as in the parallel version above), and (ii) reconstruct the overall message as m := COMBINE(s_1, ..., s_n). An attacker needs to intercept the entirety of shares for each individual transmission, as well as for all the sequential transmissions. Unless the attacker can mount a full person-in-the- middle attack, the message m remains perfectly concealed. Even if the attacker has a positive probability q < 0 to catch all shares for a single transmission in step 2, the probability to catch the entirety of n sequential shares (created in step 1) equals (1-q)^n (the path choices are made stochastically independent). In choosing n large enough, A can make the adversary's success chances exponentially small. B.3. Randomized Routing to Maximize Security against Node (Failures) Suppose that the attacker can intercept a fixed maximum number t < k of nodes, where k is the network's vertex connectivity. If the network is such that certain routes are more or less reliable than others (e.g., some routes may be easier to intercept for the adversary or temporarily be unavailable), there is no obligation in the above scheme to use the full set of paths per parallel transmission. Instead, to transmit a share (whether in the parallel or sequential-parallel version of the transmission), the sender may randomly pick the route R_i with likelihood p_i, and transmit the share over the chosen route. Knowing the choice rules p_1, ..., p_k for the k routes that A can choose from, the attacker may seek to compute an optimal strategy for intercepting, resulting in probabilities q_1, ..., q_|V| for nodes to attack (excluding the nodes for A and B here, since our security goal is confidentiality, disregarding impersonation attacks for the moment). The optimal computation of probabilities to choose routes, and individual likelihoods to intercept nodes amounts to a simple two- person matrix game [Ras13], whose saddle-point value (computable by means of linear optimization) systematically quantifies (bounds) the likelihood for the attacker to succeed. For a simplified example, assuming that all nodes are equally "easy" for the attacker to conquer, yet with a bound to no more than 1 node to be under the adversary's control at a time, the optimal choice for the sender A would be an equiprobable pick among the routes, i.e., p_i := 1/k for all i, and an equiprobable choice of victim nodes for the attacker (here, we assumed that the sender uses only a single path at a time). Rass, et al. Expires September 12, 2019 [Page 11]

Internet-Draft Mpath security use case March 2019 B.4. Availability The XOR sharing used in Section 2.1 is vulnerable against packet loss (whether this happens by coincidence or due the attacker's actions; DoS attacks). Making the scheme resilient against packet loss or damage calls for error correction capabilities within the COMBINE function, e.g., using the methods described in [LRPP09]. A full- fledged scheme using Reed-Solomon error correction towards optimized availability and confidentiality is described by [FFGV07]. B.5. End-to-End Authenticity Using a similar idea [RS10], authenticity of messages is accomplishable by message authentication codes. Since the sender A shares secrets only with her/his direct neighbors, it can only use their secrets to attach a message authentication code. The receiver B, being several hops away from A, does not know the secrets to verify the MAC, but, thanks to its ability of chosen path routing, can ask A's neighbors to verify the MACs on B's behalf. Putting this to practice, A authenticates a message m for B as follows, using the keys {k_1, ..., k_n} that A shares with its direct neighbors in the network. We write MAC(m,k) to denote a message authentication code (MAC) for a message m computed under the (secret) key k. Moreover, let H be a cryptographically strong hash function (e.g., SHA-3 or likewise). 1. A computes hash-MACs, e.g., using the HMAC scheme in [RFC2104], and attaches the MACs {a_i := MAC(H(m), k_i) | i=1,2,...,n} to the message. 2. B receives the message m' (say, over a multipath transmission scheme with chosen routes as described above). To verify that m' is authentic, B computes the hash h' = H(m') and asks A's neighbors to verify the respective MACs. To this end, B contacts the i-th neighbor of A on a chosen route, and sends the data {h', a_i'} to A's neighbor with whom A shares the secret k_i. Here, the value a_i' is the MAC that B received (which could equally well have been corrupted). 3. A's neighbor no. i uses its secret k_i to verify if MAC(h',k_i) =?= a_i'. It replies the result ("yes" or "no") back over the same route as how the query came in. This process happens concurrently at all of A's neighbors (for i = 1, ..., n). 4. B collects all replies and takes either a majority decision or (in the most stringent setting) rejects if any of the replies comes back negative. Rass, et al. Expires September 12, 2019 [Page 12]

Internet-Draft Mpath security use case March 2019 A picture of the scheme is found at https://www.syssec.at/user/themes/syssec-theme/images/publikationen/ MPAuth.png The condition upon which B accepts A's message as authentic may depend on how resilient one needs to be about an adversary potentially manipulating the verification query to B. If B rejects upon a single negative verification, then even an attacker that can conquer only a single node on any of the chosen paths can mount a denial-of-service. On the contrary, if B accepts the majority vote, then the attacker needs to intercept (and manipulate) more than half of the routes chosen. The security of this scheme follows by similar arguments as in the case for confidentiality: the scheme is secure as long as the adversary cannot mount a full person-in-the-middle attack, conditional on the attacker's inability to find hash-collisions (in that sense, the scheme is, unlike the multipath transmission for confidentiality), only computationally secure. Note that confidentiality of the message against the verifying neighbors is not directly addressed here beyond the point of sending a hash of m for verification instead of the full message. Heuristically, the message thus remains concealed to the extent of the neighbor's inability to find a meaningful pre-image for the received value h'. We assumed the neighbors to be honest, unless being under the attacker's control, so that a denial-of-service or intentionally incorrect response is in any case possible, and cannot be ruled out by this protocol. B.5.1. Non-Repudiation Under proper graph topological properties, the above authentication scheme, though based on symmetric cryptography only, shares the non- repudiation feature of public-key digital signatures. In fact, if the set of secrets shared between a node and its direct neighbors (or a subset thereof) is unique, i.e., distinct, for each node, then no other node than A can create the MAC-set attached to the message m. Networks with that property are easy to recognize based on their adjacency matrix [Ras18]; moreover, the "unique-neighborhood property" is preserved upon the same network merging operations as described above for k-vertex-connectivity. B.6. Integrity From the construction of Section 3.4, integrity is directly implied by the use of hashes that additionally act as checksums. That is, any distortion on the transmission line will with overwhelming Rass, et al. Expires September 12, 2019 [Page 13]

Internet-Draft Mpath security use case March 2019 probability invalidate the MAC or inner hash, thus causing the protocol to indicate this error. Conversely, if B accepts A's message as authentic, integrity verification is accomplished in the same blow, unless the attacker managed to forge the message as a whole (in which case, integrity is also unhedgeable). Authors' Addresses Stafan Rass Universitaet Klagenfurt EMail: stefan.rass@aau.at Yingzhen Qu Huawei 2330 Central Expressway Santa Clara, CA 95050 USA EMail: yingzhen.qu@huawei.com Lin Han Huawei 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +10 408 330 4613 EMail: lin.han@huawei.com Rass, et al. Expires September 12, 2019 [Page 14]