[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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)-<Message>
     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)-<Message>
     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(<value>): means that the length is a multiple of value.

<value>.#<parameter>: means that the length equals value times the
number of parameter

<flag2>|<flag1>: 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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/