Keying and Authentication for Routing Protocols M. Sbeiti Internet-Draft C. Wietfeld Intended status: Standards Track Communication Networks Institute, Expires: May 2013 Dortmund University of Technology November 8, 2012 PASER: Position Aware Secure and Efficient Mesh Routing Protocol draft-sbeiti-karp-paser-00 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 8, 2013. Copyright Notice Copyright (c) 2012 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 (http://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 Sbeiti & Wietfeld Expires May 8, 2013 [Page 1] Internet-Draft PASER November 8, 2012 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. Abstract The Position Aware Secure and Efficient Mesh Routing Protocol (PASER) aims to efficiently establish accurate routes in terms of metric and legitimated mesh nodes in wireless mesh networks in presence of external attackers. For this end, it achieves the following goals: Node authentication, message freshness and integrity, and neighbor transmissions authentication. The novelty of PASER lies essentially in combining asymmetric cryptography with Merkle tree (a lightweight cryptographic primitive) and a keyed-hash function to secure the routing messages. Another key feature of PASER is integrating (virtual) geographical positions of nodes in its hierarchical reactive routing process to enable an advanced network management while mitigating the wormhole attack. Apart from that, to address the problem of node compromise, PASER endorses a key revocation scheme to efficiently exclude those nodes. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document ........................... 4 2.1. Terminology ............................................ 4 2.2. Abbreviations .......................................... 7 3. Applicability Statement ..................................... 8 4. Protocol Overview ........................................... 9 4.1. Routing ................................................ 9 4.1.1. Route Discovery ................................... 9 4.1.2. Route Maintenance ................................. 10 4.2. Security ............................................... 11 4.2.1. Digital Signature Scheme .......................... 12 4.2.2. Symmetric Authentication Scheme ................... 12 4.2.3. Keyed-Hash Function ............................... 13 4.2.4. Key Management Scheme and RSA ..................... 13 5. Messages Format ............................................. 14 6. Tables Structure ............................................ 22 7. Timers ...................................................... 24 8. PASER Operations ............................................ 26 8.1. Registration at the Key Distribution Center (KDC) ...... 26 8.2. Tables Management ...................................... 27 8.3. Message Generation ..................................... 28 8.3.1. Untrusted Broadcast Route Request (UB-RREQ) ....... 28 8.3.2. Trusted Unicast Route Request (TU-RREQ) ........... 29 8.3.3. Trusted Unicast Route Reply (TU-RREP) ............. 29 8.3.4. Untrusted Unicast Route Reply (UU-RREP) ........... 29 Sbeiti & Wietfeld Expires May 8, 2013 [Page 2] Internet-Draft PASER November 8, 2012 8.3.5. Trusted Unicast Route Reply Acknowledge (TU-RREP-ACK)29 8.3.6. Trusted Broadcast Hello (TB-Hello) ................ 29 8.3.7. Trusted Broadcast Route Error (TB-RERR) ........... 29 8.3.8. Untrusted Broadcast Root Refresh (UB-Root-Refresh) 29 8.3.9. Untrusted Broadcast Key Refresh (UB-Key-Refresh) .. 29 8.4. Handling Sequence numbers .............................. 30 8.4.1. Route Reply Messages .............................. 30 8.4.2. Remaining PASER messages .......................... 30 8.5. Message Processing ..................................... 31 8.5.1. Untrusted Messages ................................ 31 8.5.2. Trusted Messages .................................. 32 8.6. Local Repair ........................................... 33 8.7. Buffering of Packets to unknown destination ............ 33 9. Security Considerations ..................................... 33 10. IANA Considerations ........................................ 34 11. Conclusions ................................................ 35 12. References ................................................. 35 12.1. Normative References .................................. 35 12.2. Informative References ................................ 35 13. Acknowledgments ............................................ 36 1. Introduction Wireless mesh networks (WMNs) have recently become a promising technology to establish a high-performance and low-cost network anywhere anytime without the need for an existing infrastructure. To establish WMNs, routing protocols are necessary to discover and maintain routes on the fly between all network nodes. The latter makes WMNs prone to a new type of attacks [4], e.g., the wormhole attack. For instance, a pair of malicious nodes linked via a fast transmission path (e.g., Ethernet) forward route discovery messages faster than legitimated nodes. This causes victim nodes to always use the tunneled route to transmit their data packets, which are then dropped by the attacker. Even if the network is protected via conventional cryptosystems e.g., IEE802.11i in pre-shared key mode [5], this attack still succeeds. The main reason for this is that routing messages are simply forwarded, without any changes, from one end to the other end of the tunnel. Thus, without a satisfactory level of security, end-users or organizations lack motivation to utilize this communication system. Otherwise, malicious users, terrorists or benefiting organizations might easily disrupt the communication channel. To address this issue, many approaches to secure routing in WMNs have been recently proposed [6]. However, none of these protocols has been adopted in the practice. The high overhead of the security mechanisms of these protocols or the hard assumptions taken by their design burdened their deployment in real life applications. For this end, PASER [2] Sbeiti & Wietfeld Expires May 8, 2013 [Page 3] Internet-Draft PASER November 8, 2012 has been designed, to achieve a reasonable trade-off between security and performance as demonstrated in [3]. 2. Conventions used in this document 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 RFC-2119 [1]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, parameters enclosed by "<>" should be replaced with the appropriate value. The "/" symbol denotes a disjunction. The "^" symbol indicates the power function This document defines the following terminology: 2.1. Terminology Reactive A protocol operation is considered "reactive" if it is performed on-demand, in reaction to specific events. This terminology is adopted from [7]. Hierarchical Protocol architecture is called "hierarchical" if nodes have different role and thereby different behavior. Node It is either a mesh router or a mesh access point or a mesh gateway. Mesh Router (MR) MR is an entity that runs a routing protocol in order to offer routing services for other nodes / stations. Mesh Access Point (MAP) MAP is an entity that has mesh router functionality and provides network access to associated stations. Mesh Gateway (MG) Sbeiti & Wietfeld Expires May 8, 2013 [Page 4] Internet-Draft PASER November 8, 2012 MG is an entity that has mesh router functionality and provides access to the Internet. Besides, a mesh gateway MUST have a secure connection to the key distribution center. Station A station is an entity that is a singly addressable instance of a medium access control (MAC) and physical layer (PHY) interface to the wireless medium. This terminology is adopted from [8]. Originator / Originating Node The originating node is the data source node; it is the node that initiates a PASER route discovery process, i.e., it the node that creates a UB-RREQ message. This terminology is adopted from [7, 9]. Destination / Destination Node It is the final target of a message. It is the node to which data packets are to be transmitted. This terminology is adopted from [9]. Forwarder / Forwarding Node / Intermediate Node A forwarder is a node that should forward packets / messages destined for another node, by retransmitting / rebroadcasting them. This terminology is adopted from [9]. Sending Node / Sender It is either an originator or a destination node or a forwarder. It is the node that sends the message. Next Hop / Neighbor Node A node X is a neighbor node of node Y if node X is in the transmission range of Y and the latter can hear node X, i.e., X is one hop far from Y. This terminology is adopted from [10]. Broadcasting Broadcasting means transmitting to the network broadcast address. A broadcast message may not be blindly forwarded, but broadcasting is useful to enable dissemination of PASER messages throughout the ad-hoc network. This terminology is adopted from [9]. Flooding Sbeiti & Wietfeld Expires May 8, 2013 [Page 5] Internet-Draft PASER November 8, 2012 In this document, flooding a message refers to the process of blindly broadcasting the message to every PASER node in the network. This terminology is adopted from [7]. PASER Interface It is an interface the PASER protocol uses to exchange messages with other nodes. Sub-network / Sub-network address A PASER node may comprise several interfaces configured with different IP addresses. For instance, in case of a mesh access point, stations which require the services of the mesh access point are typically attached to another interface than the PASER interfaces and assigned IP addresses according to the class less inter-domain routing. Sub-network address is the network address of the IP address of all node interfaces but the PASER interfaces. Distance It is an unsigned integer which measures the distance between two nodes in meters. Sequence Number A Sequence Number is an unsigned integer (a monotonically increasing number) maintained by each PASER node. This sequence number guarantees the temporal order of routing information to avoid route-loops. The value zero indicates that the sequence number for a destination address is unknown. This terminology is adopted from [7]. Invalid route An invalid route is a route that has expired, denoted by a state of invalid in the routing table entry. An invalid route is used to store previously valid route information for an extended period of time. An invalid route cannot be used to forward data packets, but it can provide information useful for route repairs, and also for future route request messages. This terminology is adopted from [9]. Valid / active route A valid route is a route towards a destination that has a routing table entry marked as valid. Only valid or active routes can be used to forward data packets. This terminology is adopted from [9]. Key Distribution Center (KDC) Sbeiti & Wietfeld Expires May 8, 2013 [Page 6] Internet-Draft PASER November 8, 2012 It is a logical unit responsible for the key management in PASER. Group Transient Key (GTK) GTK is a temporal key that is used among a group of nodes as basis for identifying a group member. Client Transient Key (CTK) CTK is a temporal key that is used between mesh access points and stations as basis for identifying one another. Packet It is a formatted unit of data exchanged between applications. Message It is a formatted unit of information exchanged between routing protocols such as PASER. Trusted Neighbor It is a neighbor that finished a trust establishment three-way handshake. Trusted Broadcast (TB) / Trusted Unicast (TU)- These are messages exchanged between trusted neighbors. They are secured with the PASER symmetric authentication scheme and the keyed-hash function. Untrusted Broadcast (UB) / Untrusted Unicast (UU)- These are messages exchanged between new neighbors. They are secured using digital signature. External Attacker It is an attacker that does not possess a valid PASER certificate. 2.2. Abbreviations CRL - Certificate Revocation List CTK - Client Transient Key GTK - Group Transient Key KDC - Key Distribution Center MAP - Mesh Access Point Sbeiti & Wietfeld Expires May 8, 2013 [Page 7] Internet-Draft PASER November 8, 2012 MG - Mesh Gateway MR - Mesh Router TB-Hello - Trusted Broadcast Hello TB-RERR - Trusted Broadcast Route Error TU-RREQ - Trusted Unicast Route Request TU-RREP - Trusted Unicast Route Reply TU-RREP-ACK - Trusted Unicast Route Reply Acknowledge UB-Key-Refresh - Untrusted Broadcast Key Refresh UB-Root-Refresh - Untrusted Broadcast Root Refresh UB-RREQ - Untrusted Broadcast Route Request UU-RREP - Untrusted Unicast Root Reply WMNs - Wireless Mesh Networks 3. Applicability Statement PASER is a suitable solution for wireless mesh networks (WMNs) with specific security requirements. It is mainly tailored for rescue organizations in emergency operations. In such environments, public (cellular) networks are typically either destroyed or overloaded and dedicated emergency services / networks such as TETRA suffer from insufficient data rates. WMNs, however, provide robust and reliable self-organizing, self-configuring and self-healing wireless broadband service access. Nonetheless, PASER is not restricted to emergency scenarios; it is generally applicable as it does not make restrictive assumptions on the network nodes. Besides, it provides generic metrics for the constituent links of the discovered routes, allowing the implementation of any route selection algorithm. PASER handles a wide variety of mobility patterns by dynamically determining routes on-demand. PASER also handles a wide variety of traffic patterns with the focus lying on traffic destined to the mesh gateway, i.e., to the Internet. Sbeiti & Wietfeld Expires May 8, 2013 [Page 8] Internet-Draft PASER November 8, 2012 PASER supports nodes with multiple interfaces. In addition to routing for their local processes, PASER nodes can also route on behalf of other stations reachable via those interfaces. Any such station MUST NOT be served by more than one PASER node. PASER only utilizes bidirectional links. The routing algorithm in PASER operates at the network layer. Nonetheless, it may be operated at layers other than the network layer, using layer-appropriate addresses. PASER REQUIRES a key distribution center that MUST be installed in a secure place and MUST have secure connection to mesh gateways. PASER REQUIRES that legitimated nodes stick to the protocol behavior. It combats external nodes from attacking the network especially the routing functionality of WMNs. It is robust against impersonation attack, man-in-the-middle attack, replay attack, tempering attack and thus to the blackhole attack. The definition of these attacks is provided in [6]. To mitigate wormhole attack, PASER uses geographical leashes as proposed in [11]. Nevertheless, PASER nodes must not be placed outdoor in order to be aware of their geographical positions. They might be placed indoor und assigned virtual geographical positions by using the method described in [12]. PASER has been designed to achieve a reasonable trade-off between security and performance in order to gain acceptance in the practice and in order to develop a scalable secure routing protocol. 4. Protocol Overview Using a hierarchical reactive routing approach and a concise combination of security mechanisms, PASER aims to efficiently establish accurate routes in terms of metric and legitimated mesh nodes in WMNs in presence of external attackers. An overview of the PASER operations is given in the next subsections. 4.1. Routing 4.1.1. Route Discovery PASER is a hierarchical reactive routing protocol, which differs between mesh gateways, mesh routers and mesh access points. Before joining the network, all nodes are responsible to register themselves at the key distribution center (KDC). For this end, mesh routers / access points must always discover a route to a mesh Sbeiti & Wietfeld Expires May 8, 2013 [Page 9] Internet-Draft PASER November 8, 2012 gateway in order to contact the KDC. Figure 1 below illustrates this process. It gives an overview of how a new mesh router / access point S, wanting to register itself at a KDC, performs the route discovery to a mesh gateway G to request, among others, the network keys from the KDC. Hereby, in addition to the information a mesh router receives from the KDC, a mesh access point receives the client transient key (CTK). Routing Table of S (After Registration) Destination: G X W Y Z Next Hop : W W W Z Z +-----------+ TU-RREQ TU-RREQ +-----------+UB-RREQ +-----> +----> +---------+ | +-------+UU-RREP +-----+ MR/MAP W <----+ MR/MAP X <-----+ | | | +---+TU-RREP-ACK+---------^ | | |1 |2 |3 +-----------+ 2|1| | | | | | + v + + v New MR/MAP S Key Distribution+--+Mesh Gateway G + ^ + Center ^ + | | | +-----------+ | | | | +---+UB-RREQ +-----> +----> +-------+ | | +-------+UU-RREP +-----+ MR/MAP Z <----+ MR/MAP Y <-------+ +-----------+TU-RREP-ACK+--------^ TU-RREP TU-RREP +-----------+ Trust Establishment Three-way Handshake Figure 1: Route discovery of PASER during the registration of a new mesh router / access point. As this figure shows, PASER adopts the path accumulation approach (forwarding nodes append their own address to each route discovery message). Furthermore, destination nodes reply to all received requests. The figure also depicts that in PASER, new neighbors establish a trust relationship between each other. Afterwards, they mainly communicate via unicast messages. 4.1.2. Route Maintenance Apart from specific timeouts defined for an existing route (see section 7), to detect and react on broken links, a node deletes a broken route in two cases. First, if it has not received a predefined number (e.g., 2) of trusted broadcast Hello messages from a neighbor. Hello messages are periodically exchanged between neighbors. Second, it did not get a link layer acknowledge for a Sbeiti & Wietfeld Expires May 8, 2013 [Page 10] Internet-Draft PASER November 8, 2012 unicast packet sent to that neighbor, even after several retransmissions, e.g. 7 times, which is the default number of a frame retransmission according to IEEE802.11 [8]. While the link layer feedback enables the fast reaction of PASER on route breaks in case of active data transfer, Hello messages allow the detection of route changes also in case of no data transfer. Besides, Hello messages enable a proactive detection of nodes that are tow-hop far since they incorporate a neighbor list. In addition, Hello messages endorse the geographical position of the sending node, enabling a permanent update of neighbor's position, which is relevant for advanced network management, and which is necessary for protection against wormhole attack. Upon receiving a packet for a destination the entry of which has been deleted or the next hop on the route to that destination is not available anymore, a forwarding node broadcasts a route error (TB- RERR) message in the network. This message comprises the last known sequence number and the IP-address of the unreachable next hop as well as all the nodes for which the unreachable node was the next hop, if available. When a node receives a TB-RERR message, it checks whether the sequence number of the unreachable node is fresh, and if the sender of the TB-RERR is the next hop to the unreachable node. Only if both requirements are met, the route is marked as invalid and the node rebroadcasts the route error message. This TB-RERR propagation mechanism enables more efficient network topology awareness in comparison to a simple flooding. 4.2. Security PASER combines digital signature with lightweight authentication tree and keyed-hash function to secure the routing messages. Besides, to address the problem of node compromise, PASER endorses a key revocation scheme to exclude those nodes in a fast and efficient way. For this purpose, it supports a dynamic distribution of network keys. The main building blocks of PASER's security are depicted in the Figure 1 below. They are applied as follows. Sbeiti & Wietfeld Expires May 8, 2013 [Page 11] Internet-Draft PASER November 8, 2012 +-------------+ PASER +--------------+ | | | Security Systems | +------------v---------------+ +----------------v---------------+ |Asymmetric-Key Cryptography | |Symmetric-Key Cryptography | |(Certificates with | |(Group/Client Transient Key) | | Integrated Roles) | | | +------------+---------------+ +----------------+---------------+ | Security Mechanisms | +------------v---------------+ +----------------v---------------+ |Key Management RSA | |Merkle Tree Keyed-Hash Function| |Digital Signature | | | +------------+---------------+ +----------------+---------------+ | Security Primitives | +------------v---------------+ +----------------v---------------+ |Certificates with | |Tree Leafs (Secrets) | |Integrated Roles | |Group/Client Transient Key | +------------+---------------+ +----------------+---------------+ | Secure Messages | +------------v---------------+ +----------------v---------------+ |UB-RREQ UB-Root-Refresh | |TU-RREQ TU-RREP | |UU-RREP UB-Key-Refresh | |TU-RREP-ACK TB-RRER TB-HELLO | +----------------------------+ +--------------------------------+ Figure 2: Security mechanisms endorsed in PASER. 4.2.1. Digital Signature Scheme It is used for the authentication of broadcast-messages; to establish trust between new neighbors. Hereby, a node uses the key pair bound to its certificate. Certificates SHOULD have integrated roles e.g., mesh gateway, router or access point. These roles are for instance included in the extension area of an X.509 certificate. They reflect predefined responsibilities of a node in the network and, thus, they map the hierarchy of a mesh network. Apart from that, digital signature is used by the KDC to sign the information it sends to the nodes. Recommendations listed in [14] should be considered when selecting a digital signature scheme. 4.2.2. Symmetric Authentication Scheme It is based on the Merkle tree [13] to authenticate unicast-messages between trusted neighbors. Each mesh node generates 2^n random secrets, where n is a configuration parameter that depends on the use case scenario. The generated secrets are the leaf pre-images of the authentication tree. These are used to compute the tree root element as described in [2, 3, 13]. After computing the root Sbeiti & Wietfeld Expires May 8, 2013 [Page 12] Internet-Draft PASER November 8, 2012 element, a node broadcasts it to its neighbors. As a next step, any mesh node e.g., S, wanting to send a routing message to a neighbor W, discloses a secret (e.g., secret1) and sends it along with the corresponding tree path and the routing message to that neighbor W. Fourth, the neighbor W, already knowing the root element of the mesh node S, computes the root of the secret it has received and verifies, if it matches the root of the mesh node S. If true, the neighbor W can trust that the message has been sent by the mesh node S. PASER tree's secrets are l bits long, where l is a configuration parameter and l > n. A secret SHALL be constructed as follows: The least significant (l - n) bits are generated randomly for each secret. The most significant n bits constitute an initialization vector (counter), the value of which is 0 for the first secret. The initialization vector is incremented by one for each subsequent secret. Upon disclosing (2^n - 1) secrets during the network lifetime, a node must generate a new root element. The latter guarantees the freshness of a secret. That is, a secret value can never be used twice for a given root. This technique is used to prevent replay attacks. 4.2.3. Keyed-Hash Function It is applied to guarantee the integrity of unicast-messages based on a group transient key. This function is always used in combination with the lightweight symmetric scheme to secure PASER messages between trusted neighbors. Recommendations listed in [14] should be considered when selecting a keyed-hash function. 4.2.4. Key Management Scheme and RSA The dynamic distribution of the group transient key and the mesh access client first occurs at network setup, when a node registers itself for the first time at the KDC. The mesh gateway forwards a MR/MAP request or sends itself a request to a key distribution center (KDC) over a secure channel. The KDC responds to that request by sending the network keys encrypted with the node's public key using the RSA algorithm. Hereby, a nonce is used to guarantee the freshness of the messages. Besides, a Key-To-Use mark is also sent to that node. Key-To-Use mark is the number of the key in use signed by the KDC. Nodes always include the number of the key in use in each PASER unicast message. This number is increased by one for each new generated key. The key is regenerated in case a node gets compromised. In that case, a new Key-To-Use mark, initialized by the KDC, is flooded in the network, and the certificate of the Sbeiti & Wietfeld Expires May 8, 2013 [Page 13] Internet-Draft PASER November 8, 2012 compromised node is blacklisted. Upon receiving the new mark, each node resets its PASER tables and re-registers itself at the KDC. If a legitimated node was meanwhile unreachable, the node detects from the higher key number in use that key refreshment has occurred. Neighbors of that node even prove the latter using the new Key-To- Use mark. As a result, that node goes in a reset state. Due to the Key-To-Use mark, an attacker, who compromised a node, cannot denial the service of neighbor nodes by just increasing the key number of its message. Recommendations listed in [14] should be considered when selecting the RSA parameters. Note that any other algorithm than RSA could be used to encrypt the keys sent from KDC to a node if it fulfills the confidentiality goal. 5. Messages Format PASER comprises four untrusted messages: UB-RREQ, UU-RREP, UB-Root- Refresh and UB-Key-Refresh and five trusted messages TU-RREQ, TU- RREP, TU-RREP-ACK, TB-RERR and TB-Hello. The format of these messages is illustrated in Table 1 and Table 2, respectively. These messages are composed of some of the following fields: Basic Fields o Type 1. UB-RREQ 2. UU-RREP 3. TU-RREP-ACK 4. TU-RREQ 5. TU-RREP 6. TB-Hello 7. TB-RERR 8. UB-Root-Refresh 9. UB-Key-Refresh o Timestamp It reflects the creating time of the message. It is used to combat replay attacks. o Registration Flag (R) It is set if a node wants to register itself at the key distribution center in order to join the network. Sbeiti & Wietfeld Expires May 8, 2013 [Page 14] Internet-Draft PASER November 8, 2012 o Mesh Gateway Flag (G) It is set if the route discovery destination is a mesh gateway. o Originator IP Address It is the IP address of the node that started the route discovery. o Destination IP Address It is the IP address of the route discovery destination. o Originator Sequence Number It is the sequence number of the node that initiated the route discovery. o Destination Sequence Number Sequence number of the route discovery destination. o Forwarder Sequence Number It is the sequence number of the node that forwarded the message. o Metric Originator <-> Sender It is the metric between the node that started the route discovery and a sender node. o Metric Destination <-> Sender It is the metric between the route discovery destination and a sender. o Route Address Range List List of IP addresses of the PASER interfaces and all sub- networks of interfaces other than the PASER interfaces which a node comprises. Each node that forwards a message appends this information to the list. o Neighbors Address Range List List of neighbors IP addresses and the sub-networks for which neighbors are responsible. o Unreachable Destinations IP Addresses List It is a list of IP addresses and sequence numbers of nodes that are not reachable anymore. Sbeiti & Wietfeld Expires May 8, 2013 [Page 15] Internet-Draft PASER November 8, 2012 Neighbor Identification Fields o Originator Nonce Random number created and sent during the registration of a node. This nonce protects against man-in-the-middle or replay attacks during the registration. o Originator Certificate It is the certificate of the node that started the route discovery. o Destination / Forwarder Certificate It is the certificate of the node that forwarded a message or of the destination when sending a reply to neighbors. o Sender Root Root element of the sender node. o Sender Initialization Vector It is the current value of the initialization vector of the sender node. o Originator Position It is the current position of the node that started the route discovery. o Forwarder Position It is the current position of the node that forwarded the message. o Destination Position It is the current position of the destination of the route discovery. o Group Transient Key Number Current number of the group transient key in use. o Key Distribution Center (KDC) Block o Encrypted Group Transient Key Group transient key encrypted with the public key of the originator. Sbeiti & Wietfeld Expires May 8, 2013 [Page 16] Internet-Draft PASER November 8, 2012 o Encrypted Client Transient Key Client transient key encrypted with the public key of the originator. o Originator Nonce Random number created and sent by the originator during the registration process. o Certificate Revocation List It is a list of all revoked certificates. o Group Transient Key Number Number of the group key currently in use. o KDC Certificate It is the certificate of the KDC. o KDC Signature Signature (using the KDC private key) of all elements of the KDC block. o Key Distribution Center Certificate It is the certificate of the key distribution center. o Key Refresh Signature Signature (using the KDC private key) of all the elements of an UB_Key_Refresh message. o Sender Signature It is the signature using the private key of the node that sent the message. The sender signs all elements of a message. Neighbor Authentication Fields o Sender Secret It is the current secret of the node that sent the message. o Secret Authentication Path It is the authentication path of the enclosed secret. o Keyed-Hash Sbeiti & Wietfeld Expires May 8, 2013 [Page 17] Internet-Draft PASER November 8, 2012 It is a the keyed-hash value of all elements of a message. The hash value is calculated using the group transient key (GTK). Notations in Table 1 and Table 2: x: indicates that a message comprises a field. *: indicates that a message comprises a field if the Registration flag is set. var.: means that a field has a variable length. Fields having variable lengths are typically preceded by 4 Bytes in which the current length of the field is stated. c.: is an estimation of the length of a field. The estimations apply in case RSA with modulo size of 1024 bits is used for encryption and signature, and SHA 256 is used for hashing. These estimations comprise the 4 Bytes preamble for each field having a variable length. m(): means that the length is a multiple of value. .#: means that the length equals value times the number of parameter |: means flag1 is the least significant bit and flag2 is the next bit. Sbeiti & Wietfeld Expires May 8, 2013 [Page 18] Internet-Draft PASER November 8, 2012 Table 1: Format of Untrusted Messages +-----------+-------+-------+-------+-------+-------+ |Field | Size |UB-RREQ|UU-RREP|UB-Root|UB-Key | | |[Byte] | | |Refresh|Refresh| +-----------+-------+-------+-------+-------+-------+ Basic Fields +-----------+-------+-------+-------+-------+-------+ |Type | 1 | x | x | x | x | +-----------+-------+-------+-------+-------+-------+ |Timestamp | 4 | x | x | x | x | +-----------+-------+-------+-------+-------+-------+ |Registra./ | 1 | | | | | |MG | F|R | x | x | | | |Flags | | | | | | +-----------+-------+-------+-------+-------+-------+ |Originator | 16 | x | | x | x | |IP Address | | | | | | +-----------+-------+-------+-------+-------+-------+ |Destination| 16 | x | x | | | |IP Address | | | | | | +-----------+-------+-------+-------+-------+-------+ |Originator | 4 | x | x | x | | |Sequence | | | | | | |Number | | | | | | +-----------+-------+-------+-------+-------+-------+ |Destination| 4 | | x | | | |Sequence | | | | | | |Number | | | | | | +-----------+-------+-------+-------+-------+-------+ |Forwarder | 4 | x | | | | |Sequence | | | | | | |Number | | | | | | +-----------+-------+-------+-------+-------+-------+ |Metric | 1 | x | x | | | |Originator | | | | | | |Sender | | | | | | +-----------+-------+-------+-------+-------+-------+ |Metric | 1 | | x | | | |Destination| | | | | | |Sender | | | | | | +-----------+-------+-------+-------+-------+-------+ |Address | var. | x | x | | | |Range List | m(16) | | | | | +-----------+-------+-------+-------+-------+-------+ Neighbor Identification Fields +-----------+-------+-------+-------+-------+-------+ |Originator | 4 | * | | | | |Nonce | | | | | | Sbeiti & Wietfeld Expires May 8, 2013 [Page 19] Internet-Draft PASER November 8, 2012 +-----------+-------+-------+-------+-------+-------+ |Originator | var. | * | | | | |Certificate| c.701 | | | | | +-----------+-------+-------+-------+-------+-------+ |Forwarder /| var. | x | x | x | | |Destination| | | | | | |Certificate| c.701 | | | | | +-----------+-------+-------+-------+-------+-------+ |Sender | 32 | x | x | x | | |Root | | | | | | +-----------+-------+-------+-------+-------+-------+ |Sender | var. | x | x | x | | |Initializa-| c.4 | | | | | |tion Vector| | | | | | +-----------+-------+-------+-------+-------+-------+ |Originator | 8 | x | | x | | |Position | | | | | | +-----------+-------+-------+-------+-------+-------+ |Forwarder | 8 | x | x | | | |Position | | | | | | +-----------+-------+-------+-------+-------+-------+ |Destination| 8 | | x | | | |Poistion | | | | | | +-----------+-------+-------+-------+-------+-------+ |Group | 4 | x | x | | x | |Key | | | | | | |Number | | | | | | +-----------+-------+-------+-------+-------+-------+ |KDC Block | var. | | * | | | | |c.1604 | | | | | +-----------+-------+-------+-------+-------+-------+ |KDC | var. | | | | x | |Certificate| c.744 | | | | | +-----------+-------+-------+-------+-------+-------+ |Key | var. | | | | x | |Refresh | c.132 | | | | | |Signature | | | | | | +-----------+-------+-------+-------+-------+-------+ |Sender | var. | x | x | x | | |Signature | c.132 | | | | | +-----------+-------+-------+-------+-------+-------+ Sbeiti & Wietfeld Expires May 8, 2013 [Page 20] Internet-Draft PASER November 8, 2012 Table 2: Format of Trusted Messages +------------+-------+-------+-------+-----------+-------+--------+ |Field |Size[B]|TU-RREQ|TU-RREP|TU-RREP-ACK|TB-RERR|TB-Hello| +------------+-------+-------+-------+-----------+-------+--------+ Basic Fields +------------+-------+-------+-------+-----------+-------+--------+ |Type | 1 | x | x | x | x | x | +------------+-------+-------+-------+-----------+-------+--------+ |Registra./ | 1 | | | | | | |MG | F|R | x | x | | | | |Flags | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Originator | 16 | x | x | x | x | x | |IP Address | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Destination | 16 | x | x | x | | | |IP Address | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Originator | 4 | x | | x | x | x | |Sequence | | | | | | | |Number | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Destination | 4 | | x | | | | |Sequence | | | | | | | |Number | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Forwarder | 4 | x | | | | | |Sequence | | | | | | | |Number | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Metric | 1 | x | x | | | | |Originator | | | | | | | |Sender | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Metric | 1 | | x | | | | |Destination | | | | | | | |Sender | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Route | var. | x | x | | | | |Address | . | | | | | | |Range List | m(16) | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Neighbors | var. | | | | | x | |Address | | | | | | | |Range List | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Unreachable | 20.# | | | | x | | |Destinations|Unreac.| | | | | | Sbeiti & Wietfeld Expires May 8, 2013 [Page 21] Internet-Draft PASER November 8, 2012 |IP Addresses|Destin.| | | | | | |List | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ Neighbor Identification Fields +------------+-------+-------+-------+-----------+-------+--------+ |Originator | 4 | * | | | | | |Nonce | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Originator | var. | * | | | | | |Certificate | c.701 | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Originator | 8 | x | | | | x | |Position | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Forwarder | 8 | x | x | | x | | |Position | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Destination | 8 | | x | | | | |Poistion | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Group | 4 | x | x | x | | | |Key | | | | | | | |Number | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |KDC Block | var. | | * | | | | | |c.1604 | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ Neighbor Authentication Fields +------------+-------+-------+-------+-----------+-------+--------+ |Sender | 32 | x | x | x | x | x | |Secret | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Secret | 32.# | x | x | x | x | x | |Authentica- |Secrets| | | | | | |tion Path | | | | | | | +------------+-------+-------+-------+-----------+-------+--------+ |Keyed-Hash | 32 | x | x | x | x | x | +------------+-------+-------+-------+-----------+-------+--------+ 6. Tables Structure Nodes running PASER maintain two tables namely, a routing table and a neighbor table. These tables are defined as follows. Sbeiti & Wietfeld Expires May 8, 2013 [Page 22] Internet-Draft PASER November 8, 2012 Routing Table o Destination IP Address It is the IP address of the route destination. o Neighbor IP Address It is the IP address of the next hop towards the route destination. o Route Delete Timer Route will be deleted when this timer expires. o Route Invalidate Timer Route will be invalidated when this time expires. An invalid route cannot be used but it can be restored faster than a route discovery. o Destination Sequence Number It is the current sequence number of the route destination. o Metric It is the metric between this node and the route destination. o Destination-is-Mesh-Gateway Flag Flag is set if the route destination is a mesh gateway. o Route-is-Valid Flag Flag is set if the route is still valid. o Destination Sub-Networks List All sub-networks of the route destination. o Destination Certificate It is the certificate of the route destination. Neighbor Table o IP Address It is the IP address of the neighbor. o Delete Timer When this timer expires the neighbor will be deleted from this Sbeiti & Wietfeld Expires May 8, 2013 [Page 23] Internet-Draft PASER November 8, 2012 table and all route entries for which this neighbor is next hop will be deleted from the routing table. o Invalidate Timer When this timer expires the neighbor is set as invalid and all route entries for which this neighbor is next hop will be set as invalid. o Trust Flag This Flag is typically set during / after the trust establishment three-way handshake between neighbors. It reflects the current trust relation between them. o Neighbor-is-Valid Flag This flag is set if the neighbor is considered valid. o Root Root element of the neighbor. o Initialization Vector It is the current value of the neighbor initialization vector. o Position It is the current position of the neighbor. o Certificate It is the certificate of the neighbor. o Interface Index It is the index of the interface over which the neighbor is reachable. 7. Timers PASER comprises the following timers: o Route_Discovery_Timeout It is the maximum time an originator node waits for a route reply. When this timer expires, the route discovery will be restarted and the timer will be refreshed until a maximum number of repetitions are reached. In that case, saved packets for that destination are dropped. Sbeiti & Wietfeld Expires May 8, 2013 [Page 24] Internet-Draft PASER November 8, 2012 o Route_Entry_Delete_Timeout When this timeout is triggered, the corresponding route entry is deleted from the routing table. In case the route is valid, this timer is refreshed every time a node receives or sends a PASER message or a data packet over the route. In case the route is invalid, this timer is refreshed only if the node receives a PASER message over the route. In that case, the route is set as valid again. o Route_Entry_Invalidate_Timeout When this timeout is triggered, the corresponding route entry is set as invalid in the routing table. This timer is refreshed every time a node receives or sends a PASER message or a data packet over the route. An invalid route gets valid again in case a node receives a PASER message over the route before deleting it. In that case, this timer is reset. o Neighbor_Entry_Delete_Timeout When this timeout is triggered, the corresponding entry is deleted from the neighbor table. The corresponding entries in the routing table SHOULD be also deleted. This timer is refreshed upon receiving a PASER message form this neighbor. o Neighbor_Entry_Invalidate_Timeout When this timeout is triggered, the corresponding entry is set as invalid in the neighbor table. The corresponding entries in the routing table SHOULD be also set as invalid. This timer is refreshed upon receiving a PASER message form the neighbor. An invalid neighbor is set to valid again if trusted message is received from that neighbor. Else, a route discovery is required if data packets need to be send to this neighbor. o Root_Resend_Timeout It is the time a node waits before resending its new root element. A new root element is typically broadcasted three times. o Hello_Periodic_Broadcast_Timeout It corresponds to the Hello interval between two successive Hello messages. This timer is refreshed after sending a hello message. o KDC_Request_Timeout Sbeiti & Wietfeld Expires May 8, 2013 [Page 25] Internet-Draft PASER November 8, 2012 It is the maximum time a mesh gateway node waits for a KDC reply. When the timer expires, the gateway resends the request. There is no upper limit for the number of retransmissions of this request. o TU_RREP_ACK_Timeout It is the maximum time a node waits for a TU-RREP-ACK in order to finish the trust establishment three-way handshake. When this timeout is triggered, a node resends the UU-RREP message. The maximum number of UU-RREP retransmissions SHOULD be set to three. o Key_Refresh_Timeout It is the maximum time a KDC waits before refreshing the network group transient key, i.e., before sending a UB-Key- Refresh message. 8. PASER Operations 8.1. Registration at the Key Distribution Center (KDC) At power-up and before any communication can take place, a node undergoes the following steps in order to join the network: 1. It generates empty routing and neighbor tables according to section 6. 2. It sets its sequence number to 1. 3. It generates the Merkle tree secrets and computes the root element as described in [2, 3]. 4. It executes the following depending on its type or the role it is assigned in its certificate: 1. Mesh Gateway: It requests group and client transient keys as well as a certificate revocation list and the number of the current key in use from the key distribution center. Upon receiving the reply, the mesh gateway enters the registered state. To prevent replay attacks, the mesh gateway includes in the request a nonce, which gets signed by the KDC in the reply. We do neither restrict the choice of the protocol used to request this information nor the location of the KDC. We assume however that the communication between a mesh gateway and the KDC is secure. Apart from that, we assume that the KDC is placed in a safe location. Since the KDC is a logical unit, it Sbeiti & Wietfeld Expires May 8, 2013 [Page 26] Internet-Draft PASER November 8, 2012 can be installed anywhere. For instance, in emergency and rescue operations, it is reasonable to install the key distribution center on the main mesh gateway, which is placed on top of the fire-fighting command and control vehicle. 2. Router/Access Point: It starts a route discovery towards a mesh gateway as part of the registration process. Hereby, the node also (like the mesh gateway) sends a nonce to prevent replay attacks. When the request arrives at a mesh gateway and the Registration flag is set, the mesh gateway forwards the registration request to the KDC and it replies the KDC reply to the node. Upon receiving the KDC block, a node enters the registered state. It possesses the keys required to join the network. 5. It sends a Hello message and initializes the Hello_Periodic_Broadcast_Timeout. 8.2. Tables Management Upon receiving a PASER message that passed all verification checks (see section 8.5), a node undergoes the following steps with respect to PASER tables: 1. Neighbor Table o Receiving of Untrusted Broadcast Route Request (UB-RREQ): The node verifies if the sender of the message has an entry in the neighbor table. If not, create a new entry with the corresponding information and timers and set the Neighbor- is-Valid flag to 1 and unset the Trust flag to 0. If the sender already has an entry in the neighbor table, verify if the neighbor is valid. If it is not, set Neighbor-is- Valid flag to 1 and unset the Trust flag to 0. Refresh timers and the corresponding entry information. o Receiving of Untrusted Unicast Route Reply (UU-RREP): The node verifies if the sender of the message has an entry in the neighbor table. If not, create a new entry with the corresponding information and timers and set the Neighbor- is-Valid flag and the Trust flag to 1, respectively. If the sender already has an entry in the neighbor table, refresh timers and the corresponding entry information. Set the Neighbor-is-Valid flag and the Trust flag to 1. Sbeiti & Wietfeld Expires May 8, 2013 [Page 27] Internet-Draft PASER November 8, 2012 o Receiving of Untrusted Broadcast Root Refresh (UB-Root- Refresh): The node verifies if the sender of the message has an entry in the neighbor table. If not, discard the message. Else, refresh the root element and the relevant fields of the corresponding neighbor entry. o Receiving of Trusted Unicast Route Reply Acknowledge (TU- RREP-ACK): The node verifies if the sender of the message has an entry in the neighbor table and if the Neighbor-is-Valid is set to 1. If not, discard the message. Else, refresh all the relevant fields of the corresponding neighbor entry and set the Trust flag to 1. o Receiving of the remaining trusted messages: The node verifies if the sender of the message has an entry in the neighbor table and if the Trust flag is set to 1. If not, discard the message. Else, refresh all the relevant fields of the corresponding neighbor entry and set the Neighbor-is-Valid flag to 1. 2. Routing Table In case the sending node has a route entry in the routing table, all its information including timers, metric and sequence number will be updated and the Route-is-Valid flag is set to 1. Otherwise, a new route entry for the sending node will be created. Afterwards, a node verifies if it has a route entry for the creator of the message and undergoes the same steps as for the sending node. Finally, the node repeats this process with respect to all intermediate nodes and IP addresses included in the route address range list field of the message and the neighbors address range list, if available. 8.3. Message Generation 8.3.1. Untrusted Broadcast Route Request (UB-RREQ) This message is generated if a node does not have a route to a desired destination. The node generates a UB-RREQ message according to Table 1. Hereby, it sets the Destination-is-Mesh-Gateway flag to 1 if the desired destination is a mesh gateway. Besides, it sets the Registration flag to 1 if the route request is part of the registration process as described in sub-section 8.1. After generating the message, the node broadcasts it and it initializes the Route_Discovery_Timeout. Sbeiti & Wietfeld Expires May 8, 2013 [Page 28] Internet-Draft PASER November 8, 2012 8.3.2. Trusted Unicast Route Request (TU-RREQ) After receiving a UB-RREQ message, an intermediate node, that has a route to the destination, generates this message and sends it to the next hop of that route. 8.3.3. Trusted Unicast Route Reply (TU-RREP) Upon receiving a TU-RREQ, a destination node generates a TU-RREP. If the Mesh Gateway and the Registration flags of the TU-RREQ were set, the mesh gateway first requests the KDC-block from the key distribution center and then its replies the TU-RREP message. 8.3.4. Untrusted Unicast Route Reply (UU-RREP) As a final response to a UB-RREQ message, an intermediate or a destination node generates a UU-RREP message. It sends this message and initializes the TU_RREP_ACK_Timeout. 8.3.5. Trusted Unicast Route Reply Acknowledge (TU-RREP-ACK) This message is generated by an originator node when it receives a UU-RREP. This message is the last message in the trust establishment three-way handshake after which neighbors mainly communicate using trusted messages. 8.3.6. Trusted Broadcast Hello (TB-Hello) This message is generated each time the Hello_Periodic_Broadcast_Timeout is triggered. 8.3.7. Trusted Broadcast Route Error (TB-RERR) Upon receiving a packet for a destination the entry of which has been deleted or in case the next hop for that destination is not reachable anymore, an intermediate node generates and broadcasts a route error (TB-RERR) message. 8.3.8. Untrusted Broadcast Root Refresh (UB-Root-Refresh) After revealing all secrets, a node generates new secrets. It then computes a new root element. Afterwards, it generates the UB-Root- Refresh message to inform neighbors about its new root element. 8.3.9. Untrusted Broadcast Key Refresh (UB-Key-Refresh) In case a node gets compromised, the group/client transient keys are regenerated and the certificate of the compromised node is Sbeiti & Wietfeld Expires May 8, 2013 [Page 29] Internet-Draft PASER November 8, 2012 blacklisted. In that case, the KDC informs mesh gateway nodes about the new keys by sending them a new Key-To-Use mark. A mesh gateway node generates the UB-Key-Refresh message, which is then flooded in the network. 8.4. Handling Sequence numbers Every route table entry at every node MUST include the latest information available about the sequence number for the IP address of the destination node for which the route table entry is maintained. At power-up every node is assigned the sequence number 1. This sequence number is increased by one every time a node sends or forwards a message. When the maximum number is reached the sequence number is reset to 1. Note that an attacker cannot misuse an old sequence number due to the security mechanisms endorsed in PASER. Sequence number is rather used to prevent message flooding and routing loops between legitimated nodes. 8.4.1. Route Reply Messages Upon receiving a PASER route reply message (UU-RREP or TU-RREP), a node verifies if the sequence of the destination is already known and if the sequence number of the message is higher. In that case, the message is considered fresh and it will be further processed. In case the sequence number of the message is smaller than the one in the route entry, the node verifies if the difference between both numbers is higher than (2^31-1), where a sequence number has a 32 bits length. In case the difference is higher, the message is considered fresh, else the message is discarded. 8.4.2. Remaining PASER messages Upon receiving a PASER message other than a route reply message, a node verifies if the sequence of the originator is already known and if the sequence number of the message is higher. In that case, the message is considered fresh and will be further processed. In case the sequence number of the message is smaller than the one in the route entry. The node verifies if the difference between both numbers is higher than (2^31-1) where a sequence number has a 32 bits length. In case the difference is higher, the message is considered fresh, else the message is discarded. In case the sequence number of the originator is not known, the message is considered fresh. Sbeiti & Wietfeld Expires May 8, 2013 [Page 30] Internet-Draft PASER November 8, 2012 In case the sequence number of the originator equals the number stored in the corresponding route entry, the node verifies the sequence number of the sender. If the sender itself is the originator, the message is discarded, else the message is considered fresh if and only if the sequence number of the sender is higher than the sequence number in the corresponding neighbor entry. In case the sequence number of the sender is not known, the message is considered fresh. This mechanism is not necessary in route reply messages, since these messages are sent over a selected route. The latter is discovered in the route request phase. 8.5. Message Processing 8.5.1. Untrusted Messages After receiving an untrusted message, a node undergoes the following steps in the given order. 1. Verify from the timestamp and the sequence number(s) (see section 8.4) that the message is fresh. If not, discard the message. 2. Verify using geographical leashes if the neighbor / sender of the message is in the transmission range. If not, discard the message. 3. Verify if the key number equals the one the node is using. If not, send UB-Key-Refresh and discard the message. 4. Verify the authenticity of the message by verifying its digital signature. If the signature is not valid, discard the message. 5. Update routing and neighbor tables according to sub-section 8.2. 6. Depending on the message type, execute the following: o UB-RREQ: Verify if the node itself is the desired destination. In that case, reply with UU-RREP and initialize TU_RREP_ACK_Timeout. If the node itself is not the destination but it has a valid route to the destination, generate and send TU-RREQ to the next hop. If the node does not have a route to the destination, update and forward the UB-RREQ. o UU-RREP: Reply with TU-RREP-ACK. Verify if the node itself is the destination. In that case, delete Route_Discovery_Timeout. Else, verify if the next hop Sbeiti & Wietfeld Expires May 8, 2013 [Page 31] Internet-Draft PASER November 8, 2012 towards the originator node is trusted. If not, update and forward UU-RREP, else generate and send a TU_RREP. o UB-Key-Refresh: verify if the key number in the key refresh message is higher than the one the node is currently using. If not, discard the message. Else, forward the message, delete PASER tables and start a registration process again. 8.5.2. Trusted Messages 1. Verify from the sequence number(s) (see section 8.4) that the message is fresh. If not, discard the message. 2. Verify using geographical leashes if the neighbor / sender of the message is in the transmission range. If not, discard the message. 3. Verify if the key number equals the one the node using. If not, send UB-Key-Refresh and discard the message. 4. Verify if the sender is a trusted neighbor. Else, discard the message. 5. In case of a TB-HELLO message, verify if the node itself is listed in the neighbor address range list field of the message, if not, discard the message. 6. Verify if the initialization vector part of the secret is higher than the one stored in the neighbor table. If not, discard the message. 7. Verify the integrity of the message by verifying the hash value using GTK. If the value is not valid, discard the message. 8. Compute from the authentication path and the secret the root element and compare it with the root of the sender in the neighbor table. If these are not equal, discard the message. 9. Update neighbor and routing tables as described in section 8.2. 10. Save the value of the initialization vector part of the secret in the corresponding field of the neighbor table. 11. Depending on the message type, execute the following: o TU RREQ: verify if the node itself is the destination. In that case, reply with TU-RREP. If not and if the route to Sbeiti & Wietfeld Expires May 8, 2013 [Page 32] Internet-Draft PASER November 8, 2012 the destination is known and the next hop is trusted and valid, then update and send the TU-RREQ to the next hop. Else, generates and send TB-RERR or undergo the local repair functionality, if activated. o TU-RREP: verify if the node itself is the destination. In that case, delete Route_Discovery_Timeout. Else, verify if there is a route entry to the destination and if the next hop is a trusted and valid neighbor. In that case, update and forward TU-RREP. Else, if the next hop is untrusted and valid, send UU-RREP. Else, generate and send TB-RERR or undergo the local repair functionality, if activated. o TU-RREP-ACK: delete TU_RREP_ACK_Timeout. o TB-RERR: verify whether the sequence number of each unreachable node included in the unreachable destination list field is fresh, i.e., it is higher or equal the sequence number stored in the routing table entry, if already known. If the sequence number is not known it is considered fresh. Disregard nodes with outdated sequence number. Verify if the sender of the message is the next hop to the remaining unreachable nodes. Invalidate the routing entries of those nodes for which this requirement is met. Create a new unreachable destination list comprising these nodes. Update and rebroadcast the TB-RERR message. 8.6. Local Repair The local repair mechanism described in [9] is adopted in PASER. 8.7. Buffering of Packets to unknown destination Data packets waiting for a route to be established (i.e., waiting for a route reply) SHOULD be buffered. The buffering SHOULD be managed according to the FIFO principle (first-in, first-out). If a route discovery has been attempted the maximum times of retries and the Route_Discovery_Timeout is triggered before receiving any route reply, all data packets destined for the corresponding destination SHOULD be dropped from the buffer. This approach is adopted from [9]. 9. Security Considerations PASER promises to achieve the following goals: Sbeiti & Wietfeld Expires May 8, 2013 [Page 33] Internet-Draft PASER November 8, 2012 o Node authentication: This goal is guaranteed by the digital signature in untrusted messages (including revocation list messages) and by the symmetric authentication mechanism in trusted messages - PASER is robust against impersonation and man-in-the-middle attacks. o Message freshness and integrity: The freshness goal is provided by the sequence number included in each message, the nonce parameter during the registration process, the timestamp in untrusted messages and the secrets in trusted messages. The integrity is achieved by the digital signature in untrusted messages and by the keyed-hash value in trusted messages - PASER is robust against replay and tempering attacks. o Neighbor transmission authentication: Provided position information is not falsified, PASER guarantees to a large extent that node's neighbors are always in that node transmission range. This goal is provided by the fault tolerant distance awareness between new neighbors (geographical leashes) combined with the achievement of the node authentication goal. - PASER is robust against the wormhole attack. PASER does not fulfill the data confidentiality goal. This goal should be guaranteed by another protocol, if necessary. Only vital goals necessary to secure the routing process against external attackers are addressed by PASER. Otherwise, running other security protocols in parallel with PASER will cause an accumulation of security technologies and redundant goals resulting in huge consumption of resources. PASER does not protect against internal malicious nodes, i.e., nodes that do not stick to the protocol behavior. PASER rather offers proactive security against none-authorized nodes and excludes compromised nodes from the network. Protecting the network against internal malicious nodes is more a reactive security concern. 10. IANA Considerations PASER defines a "Type" field for its messages. This document requires IANA to assign the following numbers for this Type field: Message Type Value ----------------------------------------------------- ----- Untrusted Broadcast Route Request (UB-RREQ) 1 Untrusted Unicast Route Reply (UU-RREP) 2 Trusted Unicast Route Reply Acknowledge (TU-RREP-ACK) 3 Sbeiti & Wietfeld Expires May 8, 2013 [Page 34] Internet-Draft PASER November 8, 2012 Trusted Unicast Route Request (TU-RREQ) 4 Trusted Unicast Route Reply (TU-RREP) 5 Trusted Broadcast Hello (TB-Hello) 6 Trusted Broadcast Route Error (TU-RERR) 7 Untrusted Broadcast Route Refresh (UB-Root-Refresh) 8 Untrusted Broadcast Key Refresh (UB-Key-Refresh) 9 11. Conclusions PASER is a secure and efficient position aware hierarchical routing protocol for wireless mesh networks. From a security perspective, PASER features a hybrid scheme to secure the routing process. A concise combination of digital signature, hash tree authentication scheme and keyed-hash function characterizes this protocol. Another key feature of PASER is the integration of nodes' positions in the route discovery, allowing an advanced network management while mitigating a wider range of attacks. Apart from that, to address the problem of node compromise, PASER endorses a key revocation scheme to efficiently exclude those nodes. Summing up, PASER aims to achieve a reasonable trade-off between security and performance. 12. References 12.1. Normative References [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] PASER: Position Aware Secure and Efficient Mesh Routing Protocol. [Online]. Available: www.paser.info [3] M. Sbeiti, J. Pojda, and C. Wietfeld, "Performance Evaluation of PASER - an Efficient Secure Route Discovery Approach for Wireless Mesh Networks", in IEEE PIMRC, Sydney, Australia, Sep. 2012. 12.2. Informative References [4] B. Kannhavong, H. Nakayama, Y. Nemoto, N. Kato, and A. Jamalipour, "A survey of routing attacks in mobile ad hoc networks", IEEE Wireless Communications, vol. 14, no. 5, pp. 85-91, Oct. 2007. [5] IEEE Standard 802.11i, "Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Security Enhancements", Jul. 2004. Sbeiti & Wietfeld Expires May 8, 2013 [Page 35] Internet-Draft PASER November 8, 2012 [6] L. Abusalah, A. Khokhar, and M. Guizani, "A Survey of Secure Mobile Ad hoc Routing Protocols", IEEE Communications Surveys and Tutorials, vol. 10, no. 4, pp. 78-93, Fourth Quarter 2008. [7] I. Chakeres and C. Perkins, "Dynamic MANET On-Demand (AODVv2) Routing", draft-ietf-manet-dymo-23, Oct. 2012. [8] IEEE Standard 802.11 - 2012, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", Mar. 2012. [9] C. Perkins, E. Belding-Royer, and S. Das, "Ad hoc On-Demand Distance Vector (AODV) routing", RFC 3561, Jul. 2003. [10] T. Clausen and P. Jacquet, "Optimized Link State Routing (OLSR) Protocol", RFC 3626, Oct. 2003 [11] Y.-C. Hu, A. Perrig, and D. Johnson, "Packet leashes: a defense against wormhole attacks in wireless networks", in IEEE INFOCOM, San Francisco, CA, USA, Mar. 2003. [12] M. Sbeiti, J. Hinker, and C. Wietfeld, "VLX: A Novel Virtual Localization Extension for Geographical Leash-based Secure Routing in Indoor Wireless Mesh Scenarios", in IEEE WiMob, Barcelona, Spain, Oct. 2012. [13] A. Menezes, P. van Oorschot, and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1996, ch. 13, p. 556. [14] E. Barker and A. Roginsky, "Transitions: Recommendation for Transitioning the Use of Cryptographic, Algorithms and Key Lengths", NIST Special Publication 800-131A, Jan. 2011. 13. Acknowledgments The authors would like to thank Eugen Paul, Andreas Wolff, Carsten Vogel, Jonas Hinker, Jan Schroder, Sebastian Rohde and Niklas Goddemeier for their assistance by the design, development and evaluation of the PASER protocol. We also acknowledge the support of the SPIDER and AVIGLE projects. SPIDER is part of the nationwide security research program funded by the German Federal Ministry of Education and Research (BMBF) (13N10238). AVIGLE is co-funded by the German Federal State North Rhine Westphalia (MIWF) and the European Union (European Regional Development Fund: Investing In Your Future). This document was prepared using 2-Word-v2.0.template.dot. Sbeiti & Wietfeld Expires May 8, 2013 [Page 36] Internet-Draft PASER November 8, 2012 Authors' Addresses Mohamad Sbeiti Communication Networks Institute Dortmund University of Technology Otto-Hahn-Str. 6, 44227 Dortmund, Germany Phone: +49-231-755-6128 Email: Mohamad.sbeiti@tu-dortmund.de Christian Wietfeld Communication Networks Institute Dortmund University of Technology Otto-Hahn-Str. 6, 44227 Dortmund, Germany Phone: +49-231-755-4515 Email: Christian.wietfeld@tu-dortmund.de Sbeiti & Wietfeld Expires May 8, 2013 [Page 37]