idnits 2.17.1 draft-sbeiti-karp-paser-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2012) is 4181 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Online' on line 1545 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-23 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Keying and Authentication for Routing Protocols M. Sbeiti 2 Internet-Draft C. Wietfeld 3 Intended status: Standards Track Communication Networks Institute, 4 Expires: May 2013 Dortmund University of Technology 5 November 8, 2012 7 PASER: Position Aware Secure and Efficient Mesh Routing Protocol 8 draft-sbeiti-karp-paser-00 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on May 8, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 The Position Aware Secure and Efficient Mesh Routing Protocol 51 (PASER) aims to efficiently establish accurate routes in terms of 52 metric and legitimated mesh nodes in wireless mesh networks in 53 presence of external attackers. For this end, it achieves the 54 following goals: Node authentication, message freshness and 55 integrity, and neighbor transmissions authentication. The novelty of 56 PASER lies essentially in combining asymmetric cryptography with 57 Merkle tree (a lightweight cryptographic primitive) and a keyed-hash 58 function to secure the routing messages. Another key feature of 59 PASER is integrating (virtual) geographical positions of nodes in 60 its hierarchical reactive routing process to enable an advanced 61 network management while mitigating the wormhole attack. Apart from 62 that, to address the problem of node compromise, PASER endorses a 63 key revocation scheme to efficiently exclude those nodes. 65 Table of Contents 67 1. Introduction ................................................ 3 68 2. Conventions used in this document ........................... 4 69 2.1. Terminology ............................................ 4 70 2.2. Abbreviations .......................................... 7 71 3. Applicability Statement ..................................... 8 72 4. Protocol Overview ........................................... 9 73 4.1. Routing ................................................ 9 74 4.1.1. Route Discovery ................................... 9 75 4.1.2. Route Maintenance ................................. 10 76 4.2. Security ............................................... 11 77 4.2.1. Digital Signature Scheme .......................... 12 78 4.2.2. Symmetric Authentication Scheme ................... 12 79 4.2.3. Keyed-Hash Function ............................... 13 80 4.2.4. Key Management Scheme and RSA ..................... 13 81 5. Messages Format ............................................. 14 82 6. Tables Structure ............................................ 22 83 7. Timers ...................................................... 24 84 8. PASER Operations ............................................ 26 85 8.1. Registration at the Key Distribution Center (KDC) ...... 26 86 8.2. Tables Management ...................................... 27 87 8.3. Message Generation ..................................... 28 88 8.3.1. Untrusted Broadcast Route Request (UB-RREQ) ....... 28 89 8.3.2. Trusted Unicast Route Request (TU-RREQ) ........... 29 90 8.3.3. Trusted Unicast Route Reply (TU-RREP) ............. 29 91 8.3.4. Untrusted Unicast Route Reply (UU-RREP) ........... 29 92 8.3.5. Trusted Unicast Route Reply Acknowledge (TU-RREP-ACK)29 93 8.3.6. Trusted Broadcast Hello (TB-Hello) ................ 29 94 8.3.7. Trusted Broadcast Route Error (TB-RERR) ........... 29 95 8.3.8. Untrusted Broadcast Root Refresh (UB-Root-Refresh) 29 96 8.3.9. Untrusted Broadcast Key Refresh (UB-Key-Refresh) .. 29 97 8.4. Handling Sequence numbers .............................. 30 98 8.4.1. Route Reply Messages .............................. 30 99 8.4.2. Remaining PASER messages .......................... 30 100 8.5. Message Processing ..................................... 31 101 8.5.1. Untrusted Messages ................................ 31 102 8.5.2. Trusted Messages .................................. 32 103 8.6. Local Repair ........................................... 33 104 8.7. Buffering of Packets to unknown destination ............ 33 105 9. Security Considerations ..................................... 33 106 10. IANA Considerations ........................................ 34 107 11. Conclusions ................................................ 35 108 12. References ................................................. 35 109 12.1. Normative References .................................. 35 110 12.2. Informative References ................................ 35 111 13. Acknowledgments ............................................ 36 113 1. Introduction 115 Wireless mesh networks (WMNs) have recently become a promising 116 technology to establish a high-performance and low-cost network 117 anywhere anytime without the need for an existing infrastructure. 118 To establish WMNs, routing protocols are necessary to discover and 119 maintain routes on the fly between all network nodes. The latter 120 makes WMNs prone to a new type of attacks [4], e.g., the wormhole 121 attack. For instance, a pair of malicious nodes linked via a fast 122 transmission path (e.g., Ethernet) forward route discovery messages 123 faster than legitimated nodes. This causes victim nodes to always 124 use the tunneled route to transmit their data packets, which are 125 then dropped by the attacker. Even if the network is protected via 126 conventional cryptosystems e.g., IEE802.11i in pre-shared key mode 127 [5], this attack still succeeds. The main reason for this is that 128 routing messages are simply forwarded, without any changes, from one 129 end to the other end of the tunnel. 130 Thus, without a satisfactory level of security, end-users or 131 organizations lack motivation to utilize this communication system. 132 Otherwise, malicious users, terrorists or benefiting organizations 133 might easily disrupt the communication channel. To address this 134 issue, many approaches to secure routing in WMNs have been recently 135 proposed [6]. However, none of these protocols has been adopted in 136 the practice. The high overhead of the security mechanisms of these 137 protocols or the hard assumptions taken by their design burdened 138 their deployment in real life applications. For this end, PASER [2] 139 has been designed, to achieve a reasonable trade-off between 140 security and performance as demonstrated in [3]. 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC-2119 [1]. 148 In this document, these words will appear with that interpretation 149 only when in ALL CAPS. Lower case uses of these words are not to be 150 interpreted as carrying RFC-2119 significance. 152 In this document, parameters enclosed by "<>" should be replaced 153 with the appropriate value. The "/" symbol denotes a disjunction. 154 The "^" symbol indicates the power function 156 This document defines the following terminology: 158 2.1. Terminology 160 Reactive 161 A protocol operation is considered "reactive" if it is performed 162 on-demand, in reaction to specific events. This terminology is 163 adopted from [7]. 165 Hierarchical 166 Protocol architecture is called "hierarchical" if nodes have 167 different role and thereby different behavior. 169 Node 170 It is either a mesh router or a mesh access point or a mesh 171 gateway. 173 Mesh Router (MR) 174 MR is an entity that runs a routing protocol in order to offer 175 routing services for other nodes / stations. 177 Mesh Access Point (MAP) 178 MAP is an entity that has mesh router functionality and provides 179 network access to associated stations. 181 Mesh Gateway (MG) 182 MG is an entity that has mesh router functionality and provides 183 access to the Internet. Besides, a mesh gateway MUST have a secure 184 connection to the key distribution center. 186 Station 187 A station is an entity that is a singly addressable instance of a 188 medium access control (MAC) and physical layer (PHY) interface to 189 the wireless medium. This terminology is adopted from [8]. 191 Originator / Originating Node 192 The originating node is the data source node; it is the node that 193 initiates a PASER route discovery process, i.e., it the node that 194 creates a UB-RREQ message. This terminology is adopted from [7, 195 9]. 197 Destination / Destination Node 198 It is the final target of a message. It is the node to which data 199 packets are to be transmitted. This terminology is adopted from 200 [9]. 202 Forwarder / Forwarding Node / Intermediate Node 203 A forwarder is a node that should forward packets / messages 204 destined for another node, by retransmitting / rebroadcasting 205 them. This terminology is adopted from [9]. 207 Sending Node / Sender 208 It is either an originator or a destination node or a forwarder. 209 It is the node that sends the message. 211 Next Hop / Neighbor Node 212 A node X is a neighbor node of node Y if node X is in the 213 transmission range of Y and the latter can hear node 214 X, i.e., X is one hop far from Y. This terminology is adopted from 215 [10]. 217 Broadcasting 218 Broadcasting means transmitting to the network broadcast address. 219 A broadcast message may not be blindly forwarded, but broadcasting 220 is useful to enable dissemination of PASER messages throughout the 221 ad-hoc network. This terminology is adopted from [9]. 223 Flooding 224 In this document, flooding a message refers to the process of 225 blindly broadcasting the message to every PASER node in the 226 network. This terminology is adopted from [7]. 228 PASER Interface 229 It is an interface the PASER protocol uses to exchange messages 230 with other nodes. 232 Sub-network / Sub-network address 233 A PASER node may comprise several interfaces configured with 234 different IP addresses. For instance, in case of a mesh access 235 point, stations which require the services of the mesh access 236 point are typically attached to another interface than the PASER 237 interfaces and assigned IP addresses according to the class less 238 inter-domain routing. Sub-network address is the network address 239 of the IP address of all node interfaces but the PASER interfaces. 241 Distance 242 It is an unsigned integer which measures the distance between two 243 nodes in meters. 245 Sequence Number 246 A Sequence Number is an unsigned integer (a monotonically 247 increasing number) maintained by each PASER node. This sequence 248 number guarantees the temporal order of routing information to 249 avoid route-loops. The value zero indicates that the sequence 250 number for a destination address is unknown. This terminology is 251 adopted from [7]. 253 Invalid route 254 An invalid route is a route that has expired, denoted by a state 255 of invalid in the routing table entry. An invalid route is used to 256 store previously valid route information for an extended period of 257 time. An invalid route cannot be used to forward data packets, 258 but it can provide information useful for route repairs, and also 259 for future route request messages. This terminology is adopted 260 from [9]. 262 Valid / active route 263 A valid route is a route towards a destination that has a routing 264 table entry marked as valid. Only valid or active routes can be 265 used to forward data packets. This terminology is adopted from 266 [9]. 268 Key Distribution Center (KDC) 269 It is a logical unit responsible for the key management in PASER. 271 Group Transient Key (GTK) 272 GTK is a temporal key that is used among a group of nodes as basis 273 for identifying a group member. 275 Client Transient Key (CTK) 276 CTK is a temporal key that is used between mesh access points and 277 stations as basis for identifying one another. 279 Packet 280 It is a formatted unit of data exchanged between applications. 282 Message 283 It is a formatted unit of information exchanged between routing 284 protocols such as PASER. 286 Trusted Neighbor 287 It is a neighbor that finished a trust establishment three-way 288 handshake. 290 Trusted Broadcast (TB) / Trusted Unicast (TU)- 291 These are messages exchanged between trusted neighbors. They are 292 secured with the PASER symmetric authentication scheme and the 293 keyed-hash function. 295 Untrusted Broadcast (UB) / Untrusted Unicast (UU)- 296 These are messages exchanged between new neighbors. They are 297 secured using digital signature. 299 External Attacker 300 It is an attacker that does not possess a valid PASER certificate. 302 2.2. Abbreviations 304 CRL - Certificate Revocation List 306 CTK - Client Transient Key 308 GTK - Group Transient Key 310 KDC - Key Distribution Center 312 MAP - Mesh Access Point 313 MG - Mesh Gateway 315 MR - Mesh Router 317 TB-Hello - Trusted Broadcast Hello 319 TB-RERR - Trusted Broadcast Route Error 321 TU-RREQ - Trusted Unicast Route Request 323 TU-RREP - Trusted Unicast Route Reply 325 TU-RREP-ACK - Trusted Unicast Route Reply Acknowledge 327 UB-Key-Refresh - Untrusted Broadcast Key Refresh 329 UB-Root-Refresh - Untrusted Broadcast Root Refresh 331 UB-RREQ - Untrusted Broadcast Route Request 333 UU-RREP - Untrusted Unicast Root Reply 335 WMNs - Wireless Mesh Networks 337 3. Applicability Statement 339 PASER is a suitable solution for wireless mesh networks (WMNs) with 340 specific security requirements. It is mainly tailored for rescue 341 organizations in emergency operations. In such environments, public 342 (cellular) networks are typically either destroyed or overloaded and 343 dedicated emergency services / networks such as TETRA suffer from 344 insufficient data rates. WMNs, however, provide robust and reliable 345 self-organizing, self-configuring and self-healing wireless 346 broadband service access. 347 Nonetheless, PASER is not restricted to emergency scenarios; it is 348 generally applicable as it does not make restrictive assumptions on 349 the network nodes. Besides, it provides generic metrics for the 350 constituent links of the discovered routes, allowing the 351 implementation of any route selection algorithm. 353 PASER handles a wide variety of mobility patterns by dynamically 354 determining routes on-demand. PASER also handles a wide variety of 355 traffic patterns with the focus lying on traffic destined to the 356 mesh gateway, i.e., to the Internet. 358 PASER supports nodes with multiple interfaces. In addition to 359 routing for their local processes, PASER nodes can also route on 360 behalf of other stations reachable via those interfaces. Any such 361 station MUST NOT be served by more than one PASER node. 363 PASER only utilizes bidirectional links. 365 The routing algorithm in PASER operates at the network layer. 366 Nonetheless, it may be operated at layers other than the network 367 layer, using layer-appropriate addresses. 369 PASER REQUIRES a key distribution center that MUST be installed in a 370 secure place and MUST have secure connection to mesh gateways. 372 PASER REQUIRES that legitimated nodes stick to the protocol 373 behavior. It combats external nodes from attacking the network 374 especially the routing functionality of WMNs. It is robust against 375 impersonation attack, man-in-the-middle attack, replay attack, 376 tempering attack and thus to the blackhole attack. The definition of 377 these attacks is provided in [6]. 379 To mitigate wormhole attack, PASER uses geographical leashes as 380 proposed in [11]. Nevertheless, PASER nodes must not be placed 381 outdoor in order to be aware of their geographical positions. They 382 might be placed indoor und assigned virtual geographical positions 383 by using the method described in [12]. 385 PASER has been designed to achieve a reasonable trade-off between 386 security and performance in order to gain acceptance in the practice 387 and in order to develop a scalable secure routing protocol. 389 4. Protocol Overview 391 Using a hierarchical reactive routing approach and a concise 392 combination of security mechanisms, PASER aims to efficiently 393 establish accurate routes in terms of metric and legitimated mesh 394 nodes in WMNs in presence of external attackers. An overview of the 395 PASER operations is given in the next subsections. 397 4.1. Routing 399 4.1.1. Route Discovery 401 PASER is a hierarchical reactive routing protocol, which differs 402 between mesh gateways, mesh routers and mesh access points. Before 403 joining the network, all nodes are responsible to register 404 themselves at the key distribution center (KDC). For this end, mesh 405 routers / access points must always discover a route to a mesh 406 gateway in order to contact the KDC. Figure 1 below illustrates this 407 process. It gives an overview of how a new mesh router / access 408 point S, wanting to register itself at a KDC, performs the route 409 discovery to a mesh gateway G to request, among others, the network 410 keys from the KDC. Hereby, in addition to the information a mesh 411 router receives from the KDC, a mesh access point receives the 412 client transient key (CTK). 414 Routing Table of S (After Registration) 415 Destination: G X W Y Z 416 Next Hop : W W W Z Z 418 +-----------+ TU-RREQ TU-RREQ 419 +-----------+UB-RREQ +-----> +----> +---------+ 420 | +-------+UU-RREP +-----+ MR/MAP W <----+ MR/MAP X <-----+ | 421 | | +---+TU-RREP-ACK+---------^ | | 422 |1 |2 |3 +-----------+ 2|1| 423 | | | | | 424 + v + + v 425 New MR/MAP S Key Distribution+--+Mesh Gateway G 426 + ^ + Center ^ + 427 | | | +-----------+ | | 428 | | +---+UB-RREQ +-----> +----> +-------+ | 429 | +-------+UU-RREP +-----+ MR/MAP Z <----+ MR/MAP Y <-------+ 430 +-----------+TU-RREP-ACK+--------^ TU-RREP TU-RREP 431 +-----------+ 432 Trust Establishment 433 Three-way Handshake 435 Figure 1: Route discovery of PASER during the registration of a new 436 mesh router / access point. 438 As this figure shows, PASER adopts the path accumulation approach 439 (forwarding nodes append their own address to each route discovery 440 message). Furthermore, destination nodes reply to all received 441 requests. The figure also depicts that in PASER, new neighbors 442 establish a trust relationship between each other. Afterwards, they 443 mainly communicate via unicast messages. 445 4.1.2. Route Maintenance 447 Apart from specific timeouts defined for an existing route (see 448 section 7), to detect and react on broken links, a node deletes a 449 broken route in two cases. First, if it has not received a 450 predefined number (e.g., 2) of trusted broadcast Hello messages from 451 a neighbor. Hello messages are periodically exchanged between 452 neighbors. Second, it did not get a link layer acknowledge for a 453 unicast packet sent to that neighbor, even after several 454 retransmissions, e.g. 7 times, which is the default number of a 455 frame retransmission according to IEEE802.11 [8]. While the link 456 layer feedback enables the fast reaction of PASER on route breaks in 457 case of active data transfer, Hello messages allow the detection of 458 route changes also in case of no data transfer. Besides, Hello 459 messages enable a proactive detection of nodes that are tow-hop far 460 since they incorporate a neighbor list. In addition, Hello messages 461 endorse the geographical position of the sending node, enabling a 462 permanent update of neighbor's position, which is relevant for 463 advanced network management, and which is necessary for protection 464 against wormhole attack. 466 Upon receiving a packet for a destination the entry of which has 467 been deleted or the next hop on the route to that destination is not 468 available anymore, a forwarding node broadcasts a route error (TB- 469 RERR) message in the network. This message comprises the last known 470 sequence number and the IP-address of the unreachable next hop as 471 well as all the nodes for which the unreachable node was the next 472 hop, if available. When a node receives a TB-RERR message, it checks 473 whether the sequence number of the unreachable node is fresh, and if 474 the sender of the TB-RERR is the next hop to the unreachable node. 475 Only if both requirements are met, the route is marked as invalid 476 and the node rebroadcasts the route error message. This TB-RERR 477 propagation mechanism enables more efficient network topology 478 awareness in comparison to a simple flooding. 480 4.2. Security 482 PASER combines digital signature with lightweight authentication 483 tree and keyed-hash function to secure the routing messages. 484 Besides, to address the problem of node compromise, PASER endorses a 485 key revocation scheme to exclude those nodes in a fast and efficient 486 way. For this purpose, it supports a dynamic distribution of network 487 keys. The main building blocks of PASER's security are depicted in 488 the Figure 1 below. They are applied as follows. 490 +-------------+ PASER +--------------+ 491 | | 492 | Security Systems | 493 +------------v---------------+ +----------------v---------------+ 494 |Asymmetric-Key Cryptography | |Symmetric-Key Cryptography | 495 |(Certificates with | |(Group/Client Transient Key) | 496 | Integrated Roles) | | | 497 +------------+---------------+ +----------------+---------------+ 498 | Security Mechanisms | 499 +------------v---------------+ +----------------v---------------+ 500 |Key Management RSA | |Merkle Tree Keyed-Hash Function| 501 |Digital Signature | | | 502 +------------+---------------+ +----------------+---------------+ 503 | Security Primitives | 504 +------------v---------------+ +----------------v---------------+ 505 |Certificates with | |Tree Leafs (Secrets) | 506 |Integrated Roles | |Group/Client Transient Key | 507 +------------+---------------+ +----------------+---------------+ 508 | Secure Messages | 509 +------------v---------------+ +----------------v---------------+ 510 |UB-RREQ UB-Root-Refresh | |TU-RREQ TU-RREP | 511 |UU-RREP UB-Key-Refresh | |TU-RREP-ACK TB-RRER TB-HELLO | 512 +----------------------------+ +--------------------------------+ 514 Figure 2: Security mechanisms endorsed in PASER. 516 4.2.1. Digital Signature Scheme 518 It is used for the authentication of broadcast-messages; to 519 establish trust between new neighbors. Hereby, a node uses the key 520 pair bound to its certificate. Certificates SHOULD have integrated 521 roles e.g., mesh gateway, router or access point. These roles are 522 for instance included in the extension area of an X.509 certificate. 523 They reflect predefined responsibilities of a node in the network 524 and, thus, they map the hierarchy of a mesh network. Apart from 525 that, digital signature is used by the KDC to sign the information 526 it sends to the nodes. Recommendations listed in [14] should be 527 considered when selecting a digital signature scheme. 529 4.2.2. Symmetric Authentication Scheme 531 It is based on the Merkle tree [13] to authenticate unicast-messages 532 between trusted neighbors. Each mesh node generates 2^n random 533 secrets, where n is a configuration parameter that depends on the 534 use case scenario. The generated secrets are the leaf pre-images of 535 the authentication tree. These are used to compute the tree root 536 element as described in [2, 3, 13]. After computing the root 537 element, a node broadcasts it to its neighbors. As a next step, any 538 mesh node e.g., S, wanting to send a routing message to a neighbor 539 W, discloses a secret (e.g., secret1) and sends it along with the 540 corresponding tree path and the routing message to that neighbor W. 541 Fourth, the neighbor W, already knowing the root element of the mesh 542 node S, computes the root of the secret it has received and 543 verifies, if it matches the root of the mesh node S. If true, the 544 neighbor W can trust that the message has been sent by the mesh node 545 S. 547 PASER tree's secrets are l bits long, where l is a configuration 548 parameter and l > n. A secret SHALL be constructed as follows: The 549 least significant (l - n) bits are generated randomly for each 550 secret. The most significant n bits constitute an initialization 551 vector (counter), the value of which is 0 for the first secret. The 552 initialization vector is incremented by one for each subsequent 553 secret. 555 Upon disclosing (2^n - 1) secrets during the network lifetime, a 556 node must generate a new root element. The latter guarantees the 557 freshness of a secret. That is, a secret value can never be used 558 twice for a given root. This technique is used to prevent replay 559 attacks. 561 4.2.3. Keyed-Hash Function 563 It is applied to guarantee the integrity of unicast-messages based 564 on a group transient key. This function is always used in 565 combination with the lightweight symmetric scheme to secure PASER 566 messages between trusted neighbors. Recommendations listed in [14] 567 should be considered when selecting a keyed-hash function. 569 4.2.4. Key Management Scheme and RSA 571 The dynamic distribution of the group transient key and the mesh 572 access client first occurs at network setup, when a node registers 573 itself for the first time at the KDC. The mesh gateway forwards a 574 MR/MAP request or sends itself a request to a key distribution 575 center (KDC) over a secure channel. The KDC responds to that request 576 by sending the network keys encrypted with the node's public key 577 using the RSA algorithm. Hereby, a nonce is used to guarantee the 578 freshness of the messages. Besides, a Key-To-Use mark is also sent 579 to that node. Key-To-Use mark is the number of the key in use signed 580 by the KDC. Nodes always include the number of the key in use in 581 each PASER unicast message. This number is increased by one for each 582 new generated key. The key is regenerated in case a node gets 583 compromised. In that case, a new Key-To-Use mark, initialized by the 584 KDC, is flooded in the network, and the certificate of the 585 compromised node is blacklisted. Upon receiving the new mark, each 586 node resets its PASER tables and re-registers itself at the KDC. If 587 a legitimated node was meanwhile unreachable, the node detects from 588 the higher key number in use that key refreshment has occurred. 589 Neighbors of that node even prove the latter using the new Key-To- 590 Use mark. As a result, that node goes in a reset state. Due to the 591 Key-To-Use mark, an attacker, who compromised a node, cannot denial 592 the service of neighbor nodes by just increasing the key number of 593 its message. 595 Recommendations listed in [14] should be considered when selecting 596 the RSA parameters. Note that any other algorithm than RSA could be 597 used to encrypt the keys sent from KDC to a node if it fulfills the 598 confidentiality goal. 600 5. Messages Format 602 PASER comprises four untrusted messages: UB-RREQ, UU-RREP, UB-Root- 603 Refresh and UB-Key-Refresh and five trusted messages TU-RREQ, TU- 604 RREP, TU-RREP-ACK, TB-RERR and TB-Hello. The format of these 605 messages is illustrated in Table 1 and Table 2, respectively. These 606 messages are composed of some of the following fields: 608 Basic Fields 610 o Type 611 1. UB-RREQ 612 2. UU-RREP 613 3. TU-RREP-ACK 614 4. TU-RREQ 615 5. TU-RREP 616 6. TB-Hello 617 7. TB-RERR 618 8. UB-Root-Refresh 619 9. UB-Key-Refresh 621 o Timestamp 622 It reflects the creating time of the message. It is used to 623 combat replay attacks. 625 o Registration Flag (R) 626 It is set if a node wants to register itself at the key 627 distribution center in order to join the network. 629 o Mesh Gateway Flag (G) 630 It is set if the route discovery destination is a mesh gateway. 632 o Originator IP Address 633 It is the IP address of the node that started the route 634 discovery. 636 o Destination IP Address 637 It is the IP address of the route discovery destination. 639 o Originator Sequence Number 640 It is the sequence number of the node that initiated the route 641 discovery. 643 o Destination Sequence Number 644 Sequence number of the route discovery destination. 646 o Forwarder Sequence Number 647 It is the sequence number of the node that forwarded the 648 message. 650 o Metric Originator <-> Sender 651 It is the metric between the node that started the route 652 discovery and a sender node. 654 o Metric Destination <-> Sender 655 It is the metric between the route discovery destination and a 656 sender. 658 o Route Address Range List 659 List of IP addresses of the PASER interfaces and all sub- 660 networks of interfaces other than the PASER interfaces which a 661 node comprises. Each node that forwards a message appends this 662 information to the list. 664 o Neighbors Address Range List 665 List of neighbors IP addresses and the sub-networks for which 666 neighbors are responsible. 668 o Unreachable Destinations IP Addresses List 669 It is a list of IP addresses and sequence numbers of nodes that 670 are not reachable anymore. 672 Neighbor Identification Fields 674 o Originator Nonce 675 Random number created and sent during the registration of a 676 node. This nonce protects against man-in-the-middle or replay 677 attacks during the registration. 679 o Originator Certificate 680 It is the certificate of the node that started the route 681 discovery. 683 o Destination / Forwarder Certificate 684 It is the certificate of the node that forwarded a message or 685 of the destination when sending a reply to neighbors. 687 o Sender Root 688 Root element of the sender node. 690 o Sender Initialization Vector 691 It is the current value of the initialization vector of the 692 sender node. 694 o Originator Position 695 It is the current position of the node that started the route 696 discovery. 698 o Forwarder Position 699 It is the current position of the node that forwarded the 700 message. 702 o Destination Position 703 It is the current position of the destination of the route 704 discovery. 706 o Group Transient Key Number 707 Current number of the group transient key in use. 709 o Key Distribution Center (KDC) Block 710 o Encrypted Group Transient Key 711 Group transient key encrypted with the public key of the 712 originator. 714 o Encrypted Client Transient Key 715 Client transient key encrypted with the public key of the 716 originator. 718 o Originator Nonce 719 Random number created and sent by the originator during the 720 registration process. 722 o Certificate Revocation List 723 It is a list of all revoked certificates. 725 o Group Transient Key Number 726 Number of the group key currently in use. 728 o KDC Certificate 729 It is the certificate of the KDC. 731 o KDC Signature 732 Signature (using the KDC private key) of all elements of 733 the KDC block. 735 o Key Distribution Center Certificate 736 It is the certificate of the key distribution center. 738 o Key Refresh Signature 739 Signature (using the KDC private key) of all the elements of an 740 UB_Key_Refresh message. 742 o Sender Signature 743 It is the signature using the private key of the node that sent 744 the message. The sender signs all elements of a message. 746 Neighbor Authentication Fields 748 o Sender Secret 749 It is the current secret of the node that sent the message. 751 o Secret Authentication Path 752 It is the authentication path of the enclosed secret. 754 o Keyed-Hash 755 It is a the keyed-hash value of all elements of a message. The 756 hash value is calculated using the group transient key (GTK). 758 Notations in Table 1 and Table 2: 760 x: indicates that a message comprises a field. 762 *: indicates that a message comprises a field if the Registration flag 763 is set. 765 var.: means that a field has a variable length. Fields having variable 766 lengths are typically preceded by 4 Bytes in which the current length 767 of the field is stated. 769 c.: is an estimation of the length of a field. The estimations apply in 770 case RSA with modulo size of 1024 bits is used for encryption and 771 signature, and SHA 256 is used for hashing. These estimations comprise 772 the 4 Bytes preamble for each field having a variable length. 774 m(): means that the length is a multiple of value. 776 .#: means that the length equals value times the 777 number of parameter 779 |: means flag1 is the least significant bit and flag2 is 780 the next bit. 782 Table 1: Format of Untrusted Messages 783 +-----------+-------+-------+-------+-------+-------+ 784 |Field | Size |UB-RREQ|UU-RREP|UB-Root|UB-Key | 785 | |[Byte] | | |Refresh|Refresh| 786 +-----------+-------+-------+-------+-------+-------+ 787 Basic Fields 788 +-----------+-------+-------+-------+-------+-------+ 789 |Type | 1 | x | x | x | x | 790 +-----------+-------+-------+-------+-------+-------+ 791 |Timestamp | 4 | x | x | x | x | 792 +-----------+-------+-------+-------+-------+-------+ 793 |Registra./ | 1 | | | | | 794 |MG | F|R | x | x | | | 795 |Flags | | | | | | 796 +-----------+-------+-------+-------+-------+-------+ 797 |Originator | 16 | x | | x | x | 798 |IP Address | | | | | | 799 +-----------+-------+-------+-------+-------+-------+ 800 |Destination| 16 | x | x | | | 801 |IP Address | | | | | | 802 +-----------+-------+-------+-------+-------+-------+ 803 |Originator | 4 | x | x | x | | 804 |Sequence | | | | | | 805 |Number | | | | | | 806 +-----------+-------+-------+-------+-------+-------+ 807 |Destination| 4 | | x | | | 808 |Sequence | | | | | | 809 |Number | | | | | | 810 +-----------+-------+-------+-------+-------+-------+ 811 |Forwarder | 4 | x | | | | 812 |Sequence | | | | | | 813 |Number | | | | | | 814 +-----------+-------+-------+-------+-------+-------+ 815 |Metric | 1 | x | x | | | 816 |Originator | | | | | | 817 |Sender | | | | | | 818 +-----------+-------+-------+-------+-------+-------+ 819 |Metric | 1 | | x | | | 820 |Destination| | | | | | 821 |Sender | | | | | | 822 +-----------+-------+-------+-------+-------+-------+ 823 |Address | var. | x | x | | | 824 |Range List | m(16) | | | | | 825 +-----------+-------+-------+-------+-------+-------+ 826 Neighbor Identification Fields 827 +-----------+-------+-------+-------+-------+-------+ 828 |Originator | 4 | * | | | | 829 |Nonce | | | | | | 830 +-----------+-------+-------+-------+-------+-------+ 831 |Originator | var. | * | | | | 832 |Certificate| c.701 | | | | | 833 +-----------+-------+-------+-------+-------+-------+ 834 |Forwarder /| var. | x | x | x | | 835 |Destination| | | | | | 836 |Certificate| c.701 | | | | | 837 +-----------+-------+-------+-------+-------+-------+ 838 |Sender | 32 | x | x | x | | 839 |Root | | | | | | 840 +-----------+-------+-------+-------+-------+-------+ 841 |Sender | var. | x | x | x | | 842 |Initializa-| c.4 | | | | | 843 |tion Vector| | | | | | 844 +-----------+-------+-------+-------+-------+-------+ 845 |Originator | 8 | x | | x | | 846 |Position | | | | | | 847 +-----------+-------+-------+-------+-------+-------+ 848 |Forwarder | 8 | x | x | | | 849 |Position | | | | | | 850 +-----------+-------+-------+-------+-------+-------+ 851 |Destination| 8 | | x | | | 852 |Poistion | | | | | | 853 +-----------+-------+-------+-------+-------+-------+ 854 |Group | 4 | x | x | | x | 855 |Key | | | | | | 856 |Number | | | | | | 857 +-----------+-------+-------+-------+-------+-------+ 858 |KDC Block | var. | | * | | | 859 | |c.1604 | | | | | 860 +-----------+-------+-------+-------+-------+-------+ 861 |KDC | var. | | | | x | 862 |Certificate| c.744 | | | | | 863 +-----------+-------+-------+-------+-------+-------+ 864 |Key | var. | | | | x | 865 |Refresh | c.132 | | | | | 866 |Signature | | | | | | 867 +-----------+-------+-------+-------+-------+-------+ 868 |Sender | var. | x | x | x | | 869 |Signature | c.132 | | | | | 870 +-----------+-------+-------+-------+-------+-------+ 871 Table 2: Format of Trusted Messages 872 +------------+-------+-------+-------+-----------+-------+--------+ 873 |Field |Size[B]|TU-RREQ|TU-RREP|TU-RREP-ACK|TB-RERR|TB-Hello| 874 +------------+-------+-------+-------+-----------+-------+--------+ 875 Basic Fields 876 +------------+-------+-------+-------+-----------+-------+--------+ 877 |Type | 1 | x | x | x | x | x | 878 +------------+-------+-------+-------+-----------+-------+--------+ 879 |Registra./ | 1 | | | | | | 880 |MG | F|R | x | x | | | | 881 |Flags | | | | | | | 882 +------------+-------+-------+-------+-----------+-------+--------+ 883 |Originator | 16 | x | x | x | x | x | 884 |IP Address | | | | | | | 885 +------------+-------+-------+-------+-----------+-------+--------+ 886 |Destination | 16 | x | x | x | | | 887 |IP Address | | | | | | | 888 +------------+-------+-------+-------+-----------+-------+--------+ 889 |Originator | 4 | x | | x | x | x | 890 |Sequence | | | | | | | 891 |Number | | | | | | | 892 +------------+-------+-------+-------+-----------+-------+--------+ 893 |Destination | 4 | | x | | | | 894 |Sequence | | | | | | | 895 |Number | | | | | | | 896 +------------+-------+-------+-------+-----------+-------+--------+ 897 |Forwarder | 4 | x | | | | | 898 |Sequence | | | | | | | 899 |Number | | | | | | | 900 +------------+-------+-------+-------+-----------+-------+--------+ 901 |Metric | 1 | x | x | | | | 902 |Originator | | | | | | | 903 |Sender | | | | | | | 904 +------------+-------+-------+-------+-----------+-------+--------+ 905 |Metric | 1 | | x | | | | 906 |Destination | | | | | | | 907 |Sender | | | | | | | 908 +------------+-------+-------+-------+-----------+-------+--------+ 909 |Route | var. | x | x | | | | 910 |Address | . | | | | | | 911 |Range List | m(16) | | | | | | 912 +------------+-------+-------+-------+-----------+-------+--------+ 913 |Neighbors | var. | | | | | x | 914 |Address | | | | | | | 915 |Range List | | | | | | | 916 +------------+-------+-------+-------+-----------+-------+--------+ 917 |Unreachable | 20.# | | | | x | | 918 |Destinations|Unreac.| | | | | | 919 |IP Addresses|Destin.| | | | | | 920 |List | | | | | | | 921 +------------+-------+-------+-------+-----------+-------+--------+ 922 Neighbor Identification Fields 923 +------------+-------+-------+-------+-----------+-------+--------+ 924 |Originator | 4 | * | | | | | 925 |Nonce | | | | | | | 926 +------------+-------+-------+-------+-----------+-------+--------+ 927 |Originator | var. | * | | | | | 928 |Certificate | c.701 | | | | | | 929 +------------+-------+-------+-------+-----------+-------+--------+ 930 |Originator | 8 | x | | | | x | 931 |Position | | | | | | | 932 +------------+-------+-------+-------+-----------+-------+--------+ 933 |Forwarder | 8 | x | x | | x | | 934 |Position | | | | | | | 935 +------------+-------+-------+-------+-----------+-------+--------+ 936 |Destination | 8 | | x | | | | 937 |Poistion | | | | | | | 938 +------------+-------+-------+-------+-----------+-------+--------+ 939 |Group | 4 | x | x | x | | | 940 |Key | | | | | | | 941 |Number | | | | | | | 942 +------------+-------+-------+-------+-----------+-------+--------+ 943 |KDC Block | var. | | * | | | | 944 | |c.1604 | | | | | | 945 +------------+-------+-------+-------+-----------+-------+--------+ 947 Neighbor Authentication Fields 948 +------------+-------+-------+-------+-----------+-------+--------+ 949 |Sender | 32 | x | x | x | x | x | 950 |Secret | | | | | | | 951 +------------+-------+-------+-------+-----------+-------+--------+ 952 |Secret | 32.# | x | x | x | x | x | 953 |Authentica- |Secrets| | | | | | 954 |tion Path | | | | | | | 955 +------------+-------+-------+-------+-----------+-------+--------+ 956 |Keyed-Hash | 32 | x | x | x | x | x | 957 +------------+-------+-------+-------+-----------+-------+--------+ 959 6. Tables Structure 961 Nodes running PASER maintain two tables namely, a routing table and 962 a neighbor table. These tables are defined as follows. 964 Routing Table 966 o Destination IP Address 967 It is the IP address of the route destination. 969 o Neighbor IP Address 970 It is the IP address of the next hop towards the route 971 destination. 973 o Route Delete Timer 974 Route will be deleted when this timer expires. 976 o Route Invalidate Timer 977 Route will be invalidated when this time expires. An invalid 978 route cannot be used but it can be restored faster than a route 979 discovery. 981 o Destination Sequence Number 982 It is the current sequence number of the route destination. 984 o Metric 985 It is the metric between this node and the route destination. 987 o Destination-is-Mesh-Gateway Flag 988 Flag is set if the route destination is a mesh gateway. 990 o Route-is-Valid Flag 991 Flag is set if the route is still valid. 993 o Destination Sub-Networks List 994 All sub-networks of the route destination. 996 o Destination Certificate 997 It is the certificate of the route destination. 999 Neighbor Table 1001 o IP Address 1002 It is the IP address of the neighbor. 1004 o Delete Timer 1005 When this timer expires the neighbor will be deleted from this 1006 table and all route entries for which this neighbor is next hop 1007 will be deleted from the routing table. 1009 o Invalidate Timer 1010 When this timer expires the neighbor is set as invalid and all 1011 route entries for which this neighbor is next hop will be set 1012 as invalid. 1014 o Trust Flag 1015 This Flag is typically set during / after the trust 1016 establishment three-way handshake between neighbors. It 1017 reflects the current trust relation between them. 1019 o Neighbor-is-Valid Flag 1020 This flag is set if the neighbor is considered valid. 1022 o Root 1023 Root element of the neighbor. 1025 o Initialization Vector 1026 It is the current value of the neighbor initialization vector. 1028 o Position 1029 It is the current position of the neighbor. 1031 o Certificate 1032 It is the certificate of the neighbor. 1034 o Interface Index 1035 It is the index of the interface over which the neighbor is 1036 reachable. 1038 7. Timers 1040 PASER comprises the following timers: 1042 o Route_Discovery_Timeout 1043 It is the maximum time an originator node waits for a route 1044 reply. When this timer expires, the route discovery will be 1045 restarted and the timer will be refreshed until a maximum 1046 number of repetitions are reached. In that case, saved packets 1047 for that destination are dropped. 1049 o Route_Entry_Delete_Timeout 1050 When this timeout is triggered, the corresponding route entry 1051 is deleted from the routing table. In case the route is valid, 1052 this timer is refreshed every time a node receives or sends a 1053 PASER message or a data packet over the route. In case the 1054 route is invalid, this timer is refreshed only if the node 1055 receives a PASER message over the route. In that case, the 1056 route is set as valid again. 1058 o Route_Entry_Invalidate_Timeout 1059 When this timeout is triggered, the corresponding route entry 1060 is set as invalid in the routing table. This timer is refreshed 1061 every time a node receives or sends a PASER message or a data 1062 packet over the route. An invalid route gets valid again in 1063 case a node receives a PASER message over the route before 1064 deleting it. In that case, this timer is reset. 1066 o Neighbor_Entry_Delete_Timeout 1067 When this timeout is triggered, the corresponding entry is 1068 deleted from the neighbor table. The corresponding entries in 1069 the routing table SHOULD be also deleted. This timer is 1070 refreshed upon receiving a PASER message form this neighbor. 1072 o Neighbor_Entry_Invalidate_Timeout 1073 When this timeout is triggered, the corresponding entry is set 1074 as invalid in the neighbor table. The corresponding entries in 1075 the routing table SHOULD be also set as invalid. This timer is 1076 refreshed upon receiving a PASER message form the neighbor. An 1077 invalid neighbor is set to valid again if trusted message is 1078 received from that neighbor. Else, a route discovery is 1079 required if data packets need to be send to this neighbor. 1081 o Root_Resend_Timeout 1082 It is the time a node waits before resending its new root 1083 element. A new root element is typically broadcasted three 1084 times. 1086 o Hello_Periodic_Broadcast_Timeout 1087 It corresponds to the Hello interval between two successive 1088 Hello messages. This timer is refreshed after sending a hello 1089 message. 1091 o KDC_Request_Timeout 1092 It is the maximum time a mesh gateway node waits for a KDC 1093 reply. When the timer expires, the gateway resends the request. 1094 There is no upper limit for the number of retransmissions of 1095 this request. 1097 o TU_RREP_ACK_Timeout 1098 It is the maximum time a node waits for a TU-RREP-ACK in order 1099 to finish the trust establishment three-way handshake. When 1100 this timeout is triggered, a node resends the UU-RREP message. 1101 The maximum number of UU-RREP retransmissions SHOULD be set to 1102 three. 1104 o Key_Refresh_Timeout 1105 It is the maximum time a KDC waits before refreshing the 1106 network group transient key, i.e., before sending a UB-Key- 1107 Refresh message. 1109 8. PASER Operations 1111 8.1. Registration at the Key Distribution Center (KDC) 1113 At power-up and before any communication can take place, a node 1114 undergoes the following steps in order to join the network: 1116 1. It generates empty routing and neighbor tables according to 1117 section 6. 1119 2. It sets its sequence number to 1. 1121 3. It generates the Merkle tree secrets and computes the root element 1122 as described in [2, 3]. 1124 4. It executes the following depending on its type or the role it is 1125 assigned in its certificate: 1127 1. Mesh Gateway: It requests group and client transient keys 1128 as well as a certificate revocation list and the number of 1129 the current key in use from the key distribution center. 1130 Upon receiving the reply, the mesh gateway enters the 1131 registered state. To prevent replay attacks, the mesh 1132 gateway includes in the request a nonce, which gets signed 1133 by the KDC in the reply. We do neither restrict the choice 1134 of the protocol used to request this information nor the 1135 location of the KDC. We assume however that the 1136 communication between a mesh gateway and the KDC is 1137 secure. Apart from that, we assume that the KDC is placed 1138 in a safe location. Since the KDC is a logical unit, it 1139 can be installed anywhere. For instance, in emergency and 1140 rescue operations, it is reasonable to install the key 1141 distribution center on the main mesh gateway, which is 1142 placed on top of the fire-fighting command and control 1143 vehicle. 1145 2. Router/Access Point: It starts a route discovery towards a 1146 mesh gateway as part of the registration process. Hereby, 1147 the node also (like the mesh gateway) sends a nonce to 1148 prevent replay attacks. When the request arrives at a mesh 1149 gateway and the Registration flag is set, the mesh gateway 1150 forwards the registration request to the KDC and it 1151 replies the KDC reply to the node. Upon receiving the KDC 1152 block, a node enters the registered state. It possesses 1153 the keys required to join the network. 1155 5. It sends a Hello message and initializes the 1156 Hello_Periodic_Broadcast_Timeout. 1158 8.2. Tables Management 1160 Upon receiving a PASER message that passed all verification checks 1161 (see section 8.5), a node undergoes the following steps with respect 1162 to PASER tables: 1164 1. Neighbor Table 1166 o Receiving of Untrusted Broadcast Route Request (UB-RREQ): 1167 The node verifies if the sender of the message has an entry 1168 in the neighbor table. If not, create a new entry with the 1169 corresponding information and timers and set the Neighbor- 1170 is-Valid flag to 1 and unset the Trust flag to 0. If the 1171 sender already has an entry in the neighbor table, verify 1172 if the neighbor is valid. If it is not, set Neighbor-is- 1173 Valid flag to 1 and unset the Trust flag to 0. Refresh 1174 timers and the corresponding entry information. 1176 o Receiving of Untrusted Unicast Route Reply (UU-RREP): 1177 The node verifies if the sender of the message has an entry 1178 in the neighbor table. If not, create a new entry with the 1179 corresponding information and timers and set the Neighbor- 1180 is-Valid flag and the Trust flag to 1, respectively. If the 1181 sender already has an entry in the neighbor table, refresh 1182 timers and the corresponding entry information. Set the 1183 Neighbor-is-Valid flag and the Trust flag to 1. 1185 o Receiving of Untrusted Broadcast Root Refresh (UB-Root- 1186 Refresh): 1187 The node verifies if the sender of the message has an entry 1188 in the neighbor table. If not, discard the message. Else, 1189 refresh the root element and the relevant fields of the 1190 corresponding neighbor entry. 1192 o Receiving of Trusted Unicast Route Reply Acknowledge (TU- 1193 RREP-ACK): 1194 The node verifies if the sender of the message has an entry 1195 in the neighbor table and if the Neighbor-is-Valid is set 1196 to 1. If not, discard the message. Else, refresh all the 1197 relevant fields of the corresponding neighbor entry and set 1198 the Trust flag to 1. 1200 o Receiving of the remaining trusted messages: 1201 The node verifies if the sender of the message has an entry 1202 in the neighbor table and if the Trust flag is set to 1. If 1203 not, discard the message. Else, refresh all the relevant 1204 fields of the corresponding neighbor entry and set the 1205 Neighbor-is-Valid flag to 1. 1207 2. Routing Table 1208 In case the sending node has a route entry in the routing 1209 table, all its information including timers, metric and 1210 sequence number will be updated and the Route-is-Valid flag is 1211 set to 1. Otherwise, a new route entry for the sending node 1212 will be created. Afterwards, a node verifies if it has a route 1213 entry for the creator of the message and undergoes the same 1214 steps as for the sending node. Finally, the node repeats this 1215 process with respect to all intermediate nodes and IP addresses 1216 included in the route address range list field of the message 1217 and the neighbors address range list, if available. 1219 8.3. Message Generation 1221 8.3.1. Untrusted Broadcast Route Request (UB-RREQ) 1223 This message is generated if a node does not have a route to a 1224 desired destination. The node generates a UB-RREQ message according 1225 to Table 1. Hereby, it sets the Destination-is-Mesh-Gateway flag to 1226 1 if the desired destination is a mesh gateway. Besides, it sets the 1227 Registration flag to 1 if the route request is part of the 1228 registration process as described in sub-section 8.1. After 1229 generating the message, the node broadcasts it and it initializes 1230 the Route_Discovery_Timeout. 1232 8.3.2. Trusted Unicast Route Request (TU-RREQ) 1234 After receiving a UB-RREQ message, an intermediate node, that has a 1235 route to the destination, generates this message and sends it to the 1236 next hop of that route. 1238 8.3.3. Trusted Unicast Route Reply (TU-RREP) 1240 Upon receiving a TU-RREQ, a destination node generates a TU-RREP. If 1241 the Mesh Gateway and the Registration flags of the TU-RREQ were set, 1242 the mesh gateway first requests the KDC-block from the key 1243 distribution center and then its replies the TU-RREP message. 1245 8.3.4. Untrusted Unicast Route Reply (UU-RREP) 1247 As a final response to a UB-RREQ message, an intermediate or a 1248 destination node generates a UU-RREP message. It sends this message 1249 and initializes the TU_RREP_ACK_Timeout. 1251 8.3.5. Trusted Unicast Route Reply Acknowledge (TU-RREP-ACK) 1253 This message is generated by an originator node when it receives a 1254 UU-RREP. This message is the last message in the trust establishment 1255 three-way handshake after which neighbors mainly communicate using 1256 trusted messages. 1258 8.3.6. Trusted Broadcast Hello (TB-Hello) 1260 This message is generated each time the 1261 Hello_Periodic_Broadcast_Timeout is triggered. 1263 8.3.7. Trusted Broadcast Route Error (TB-RERR) 1265 Upon receiving a packet for a destination the entry of which has 1266 been deleted or in case the next hop for that destination is not 1267 reachable anymore, an intermediate node generates and broadcasts a 1268 route error (TB-RERR) message. 1270 8.3.8. Untrusted Broadcast Root Refresh (UB-Root-Refresh) 1272 After revealing all secrets, a node generates new secrets. It then 1273 computes a new root element. Afterwards, it generates the UB-Root- 1274 Refresh message to inform neighbors about its new root element. 1276 8.3.9. Untrusted Broadcast Key Refresh (UB-Key-Refresh) 1278 In case a node gets compromised, the group/client transient keys are 1279 regenerated and the certificate of the compromised node is 1280 blacklisted. In that case, the KDC informs mesh gateway nodes about 1281 the new keys by sending them a new Key-To-Use mark. A mesh gateway 1282 node generates the UB-Key-Refresh message, which is then flooded in 1283 the network. 1285 8.4. Handling Sequence numbers 1287 Every route table entry at every node MUST include the latest 1288 information available about the sequence number for the IP address 1289 of the destination node for which the route table entry is 1290 maintained. 1292 At power-up every node is assigned the sequence number 1. This 1293 sequence number is increased by one every time a node sends or 1294 forwards a message. When the maximum number is reached the sequence 1295 number is reset to 1. Note that an attacker cannot misuse an old 1296 sequence number due to the security mechanisms endorsed in PASER. 1297 Sequence number is rather used to prevent message flooding and 1298 routing loops between legitimated nodes. 1300 8.4.1. Route Reply Messages 1302 Upon receiving a PASER route reply message (UU-RREP or TU-RREP), a 1303 node verifies if the sequence of the destination is already known 1304 and if the sequence number of the message is higher. In that case, 1305 the message is considered fresh and it will be further processed. In 1306 case the sequence number of the message is smaller than the one in 1307 the route entry, the node verifies if the difference between both 1308 numbers is higher than (2^31-1), where a sequence number has a 32 1309 bits length. In case the difference is higher, the message is 1310 considered fresh, else the message is discarded. 1312 8.4.2. Remaining PASER messages 1314 Upon receiving a PASER message other than a route reply message, a 1315 node verifies if the sequence of the originator is already known and 1316 if the sequence number of the message is higher. In that case, the 1317 message is considered fresh and will be further processed. In case 1318 the sequence number of the message is smaller than the one in the 1319 route entry. The node verifies if the difference between both 1320 numbers is higher than (2^31-1) where a sequence number has a 32 1321 bits length. In case the difference is higher, the message is 1322 considered fresh, else the message is discarded. 1324 In case the sequence number of the originator is not known, the 1325 message is considered fresh. 1327 In case the sequence number of the originator equals the number 1328 stored in the corresponding route entry, the node verifies the 1329 sequence number of the sender. If the sender itself is the 1330 originator, the message is discarded, else the message is considered 1331 fresh if and only if the sequence number of the sender is higher 1332 than the sequence number in the corresponding neighbor entry. In 1333 case the sequence number of the sender is not known, the message is 1334 considered fresh. This mechanism is not necessary in route reply 1335 messages, since these messages are sent over a selected route. The 1336 latter is discovered in the route request phase. 1338 8.5. Message Processing 1340 8.5.1. Untrusted Messages 1342 After receiving an untrusted message, a node undergoes the following 1343 steps in the given order. 1345 1. Verify from the timestamp and the sequence number(s) (see 1346 section 8.4) that the message is fresh. If not, discard the 1347 message. 1349 2. Verify using geographical leashes if the neighbor / sender of 1350 the message is in the transmission range. If not, discard the 1351 message. 1353 3. Verify if the key number equals the one the node is using. If 1354 not, send UB-Key-Refresh and discard the message. 1356 4. Verify the authenticity of the message by verifying its digital 1357 signature. If the signature is not valid, discard the message. 1359 5. Update routing and neighbor tables according to 1360 sub-section 8.2. 1362 6. Depending on the message type, execute the following: 1364 o UB-RREQ: Verify if the node itself is the desired 1365 destination. In that case, reply with UU-RREP and 1366 initialize TU_RREP_ACK_Timeout. If the node itself is not 1367 the destination but it has a valid route to the 1368 destination, generate and send TU-RREQ to the next hop. If 1369 the node does not have a route to the destination, update 1370 and forward the UB-RREQ. 1372 o UU-RREP: Reply with TU-RREP-ACK. Verify if the node itself 1373 is the destination. In that case, delete 1374 Route_Discovery_Timeout. Else, verify if the next hop 1375 towards the originator node is trusted. If not, update and 1376 forward UU-RREP, else generate and send a TU_RREP. 1378 o UB-Key-Refresh: verify if the key number in the key refresh 1379 message is higher than the one the node is currently 1380 using. If not, discard the message. Else, forward the 1381 message, delete PASER tables and start a registration 1382 process again. 1384 8.5.2. Trusted Messages 1386 1. Verify from the sequence number(s) (see section 8.4) that the 1387 message is fresh. If not, discard the message. 1389 2. Verify using geographical leashes if the neighbor / sender of 1390 the message is in the transmission range. If not, discard the 1391 message. 1393 3. Verify if the key number equals the one the node using. If not, 1394 send UB-Key-Refresh and discard the message. 1396 4. Verify if the sender is a trusted neighbor. Else, discard the 1397 message. 1399 5. In case of a TB-HELLO message, verify if the node itself is 1400 listed in the neighbor address range list field of the message, 1401 if not, discard the message. 1403 6. Verify if the initialization vector part of the secret is 1404 higher than the one stored in the neighbor table. If not, 1405 discard the message. 1407 7. Verify the integrity of the message by verifying the hash value 1408 using GTK. If the value is not valid, discard the message. 1410 8. Compute from the authentication path and the secret the root 1411 element and compare it with the root of the sender in the 1412 neighbor table. If these are not equal, discard the message. 1414 9. Update neighbor and routing tables as described in section 8.2. 1416 10. Save the value of the initialization vector part of the secret 1417 in the corresponding field of the neighbor table. 1419 11. Depending on the message type, execute the following: 1421 o TU RREQ: verify if the node itself is the destination. In 1422 that case, reply with TU-RREP. If not and if the route to 1423 the destination is known and the next hop is trusted and 1424 valid, then update and send the TU-RREQ to the next hop. 1425 Else, generates and send TB-RERR or undergo the local 1426 repair functionality, if activated. 1428 o TU-RREP: verify if the node itself is the destination. In 1429 that case, delete Route_Discovery_Timeout. Else, verify if 1430 there is a route entry to the destination and if the next 1431 hop is a trusted and valid neighbor. In that case, update 1432 and forward TU-RREP. Else, if the next hop is untrusted 1433 and valid, send UU-RREP. Else, generate and send TB-RERR 1434 or undergo the local repair functionality, if activated. 1436 o TU-RREP-ACK: delete TU_RREP_ACK_Timeout. 1438 o TB-RERR: verify whether the sequence number of each 1439 unreachable node included in the unreachable destination 1440 list field is fresh, i.e., it is higher or equal the 1441 sequence number stored in the routing table entry, if 1442 already known. If the sequence number is not known it is 1443 considered fresh. Disregard nodes with outdated sequence 1444 number. Verify if the sender of the message is the next 1445 hop to the remaining unreachable nodes. Invalidate the 1446 routing entries of those nodes for which this requirement 1447 is met. Create a new unreachable destination list 1448 comprising these nodes. Update and rebroadcast the TB-RERR 1449 message. 1451 8.6. Local Repair 1453 The local repair mechanism described in [9] is adopted in PASER. 1455 8.7. Buffering of Packets to unknown destination 1457 Data packets waiting for a route to be established (i.e., waiting 1458 for a route reply) SHOULD be buffered. The buffering SHOULD be 1459 managed according to the FIFO principle (first-in, first-out). If a 1460 route discovery has been attempted the maximum times of retries and 1461 the Route_Discovery_Timeout is triggered before receiving any route 1462 reply, all data packets destined for the corresponding destination 1463 SHOULD be dropped from the buffer. This approach is adopted from 1464 [9]. 1466 9. Security Considerations 1468 PASER promises to achieve the following goals: 1470 o Node authentication: This goal is guaranteed by the digital 1471 signature in untrusted messages (including revocation list 1472 messages) and by the symmetric authentication mechanism in 1473 trusted messages - PASER is robust against impersonation and 1474 man-in-the-middle attacks. 1476 o Message freshness and integrity: The freshness goal is provided 1477 by the sequence number included in each message, the nonce 1478 parameter during the registration process, the timestamp in 1479 untrusted messages and the secrets in trusted messages. The 1480 integrity is achieved by the digital signature in untrusted 1481 messages and by the keyed-hash value in trusted messages - 1482 PASER is robust against replay and tempering attacks. 1484 o Neighbor transmission authentication: Provided position 1485 information is not falsified, PASER guarantees to a large 1486 extent that node's neighbors are always in that node 1487 transmission range. This goal is provided by the fault tolerant 1488 distance awareness between new neighbors (geographical leashes) 1489 combined with the achievement of the node authentication goal. 1490 - PASER is robust against the wormhole attack. 1492 PASER does not fulfill the data confidentiality goal. This goal 1493 should be guaranteed by another protocol, if necessary. Only vital 1494 goals necessary to secure the routing process against external 1495 attackers are addressed by PASER. Otherwise, running other security 1496 protocols in parallel with PASER will cause an accumulation of 1497 security technologies and redundant goals resulting in huge 1498 consumption of resources. 1500 PASER does not protect against internal malicious nodes, i.e., nodes 1501 that do not stick to the protocol behavior. PASER rather offers 1502 proactive security against none-authorized nodes and excludes 1503 compromised nodes from the network. Protecting the network against 1504 internal malicious nodes is more a reactive security concern. 1506 10. IANA Considerations 1508 PASER defines a "Type" field for its messages. This document 1509 requires IANA to assign the following numbers for this Type field: 1511 Message Type Value 1512 ----------------------------------------------------- ----- 1513 Untrusted Broadcast Route Request (UB-RREQ) 1 1514 Untrusted Unicast Route Reply (UU-RREP) 2 1515 Trusted Unicast Route Reply Acknowledge (TU-RREP-ACK) 3 1516 Trusted Unicast Route Request (TU-RREQ) 4 1517 Trusted Unicast Route Reply (TU-RREP) 5 1518 Trusted Broadcast Hello (TB-Hello) 6 1519 Trusted Broadcast Route Error (TU-RERR) 7 1520 Untrusted Broadcast Route Refresh (UB-Root-Refresh) 8 1521 Untrusted Broadcast Key Refresh (UB-Key-Refresh) 9 1523 11. Conclusions 1525 PASER is a secure and efficient position aware hierarchical routing 1526 protocol for wireless mesh networks. From a security perspective, 1527 PASER features a hybrid scheme to secure the routing process. A 1528 concise combination of digital signature, hash tree authentication 1529 scheme and keyed-hash function characterizes this protocol. Another 1530 key feature of PASER is the integration of nodes' positions in the 1531 route discovery, allowing an advanced network management while 1532 mitigating a wider range of attacks. Apart from that, to address the 1533 problem of node compromise, PASER endorses a key revocation scheme 1534 to efficiently exclude those nodes. Summing up, PASER aims to 1535 achieve a reasonable trade-off between security and performance. 1537 12. References 1539 12.1. Normative References 1541 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1542 Levels", BCP 14, RFC 2119, March 1997. 1544 [2] PASER: Position Aware Secure and Efficient Mesh Routing 1545 Protocol. [Online]. Available: www.paser.info 1547 [3] M. Sbeiti, J. Pojda, and C. Wietfeld, "Performance Evaluation 1548 of PASER - an Efficient Secure Route Discovery Approach for 1549 Wireless Mesh Networks", in IEEE PIMRC, Sydney, Australia, 1550 Sep. 2012. 1552 12.2. Informative References 1554 [4] B. Kannhavong, H. Nakayama, Y. Nemoto, N. Kato, and A. 1555 Jamalipour, "A survey of routing attacks in mobile ad hoc 1556 networks", IEEE Wireless Communications, vol. 14, no. 5, pp. 1557 85-91, Oct. 2007. 1559 [5] IEEE Standard 802.11i, "Wireless Medium Access Control (MAC) 1560 and Physical Layer (PHY) Specifications: Medium Access Control 1561 (MAC) Security Enhancements", Jul. 2004. 1563 [6] L. Abusalah, A. Khokhar, and M. Guizani, "A Survey of Secure 1564 Mobile Ad hoc Routing Protocols", IEEE Communications Surveys 1565 and Tutorials, vol. 10, no. 4, pp. 78-93, Fourth Quarter 2008. 1567 [7] I. Chakeres and C. Perkins, "Dynamic MANET On-Demand (AODVv2) 1568 Routing", draft-ietf-manet-dymo-23, Oct. 2012. 1570 [8] IEEE Standard 802.11 - 2012, "Wireless LAN Medium Access 1571 Control (MAC) and Physical Layer (PHY) Specifications", Mar. 1572 2012. 1574 [9] C. Perkins, E. Belding-Royer, and S. Das, "Ad hoc On-Demand 1575 Distance Vector (AODV) routing", RFC 3561, Jul. 2003. 1577 [10] T. Clausen and P. Jacquet, "Optimized Link State Routing 1578 (OLSR) Protocol", RFC 3626, Oct. 2003 1580 [11] Y.-C. Hu, A. Perrig, and D. Johnson, "Packet leashes: a 1581 defense against wormhole attacks in wireless networks", in 1582 IEEE INFOCOM, San Francisco, CA, USA, Mar. 2003. 1584 [12] M. Sbeiti, J. Hinker, and C. Wietfeld, "VLX: A Novel Virtual 1585 Localization Extension for Geographical Leash-based Secure 1586 Routing in Indoor Wireless Mesh Scenarios", in IEEE WiMob, 1587 Barcelona, Spain, Oct. 2012. 1589 [13] A. Menezes, P. van Oorschot, and S. Vanstone, "Handbook of 1590 Applied Cryptography", CRC Press, 1996, ch. 13, p. 556. 1592 [14] E. Barker and A. Roginsky, "Transitions: Recommendation for 1593 Transitioning the Use of Cryptographic, Algorithms and Key 1594 Lengths", NIST Special Publication 800-131A, Jan. 2011. 1596 13. Acknowledgments 1598 The authors would like to thank Eugen Paul, Andreas Wolff, 1599 Carsten Vogel, Jonas Hinker, Jan Schroder, Sebastian Rohde and 1600 Niklas Goddemeier for their assistance by the design, development 1601 and evaluation of the PASER protocol. We also acknowledge the 1602 support of the SPIDER and AVIGLE projects. SPIDER is part of 1603 the nationwide security research program funded by the German 1604 Federal Ministry of Education and Research (BMBF) (13N10238). 1605 AVIGLE is co-funded by the German Federal State North Rhine 1606 Westphalia (MIWF) and the European Union (European Regional 1607 Development Fund: Investing In Your Future). 1609 This document was prepared using 2-Word-v2.0.template.dot. 1611 Authors' Addresses 1613 Mohamad Sbeiti 1614 Communication Networks Institute 1615 Dortmund University of Technology 1616 Otto-Hahn-Str. 6, 1617 44227 Dortmund, Germany 1619 Phone: +49-231-755-6128 1620 Email: Mohamad.sbeiti@tu-dortmund.de 1622 Christian Wietfeld 1623 Communication Networks Institute 1624 Dortmund University of Technology 1625 Otto-Hahn-Str. 6, 1626 44227 Dortmund, Germany 1628 Phone: +49-231-755-4515 1629 Email: Christian.wietfeld@tu-dortmund.de