Networking Working Group Th. Zahariadis Internet Draft H. C. Leligou Intended status: Informational P. Karkazis Expires: November 2009 TEI of Chalkida P. Trakadas S. Maniatis ADAE May 21, 2009 A Trust Framework for Low Power and Lossy Networks draft-zahariad-roll-trust-framework-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 November 21, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Zahariadis Expires November 21, 2009 [Page 1] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document presents a trust framework, which may improve the security and reliability of routing over Low Power and Lossy Networks (LLN), against an increased set of attacks. The development of the framework builds upon previous work on trust and secure routing, adapting the trust assessments to the issues and constraints specific to LLNs. The proposed trust management scheme is based on direct and indirect interactions with neighboring nodes, to compute their trust value and thus select the most trusted path or forwarding node. To reduce the overhead of nodes' communication during the indirect trust value retrieval procedure, indirect trust information is requested from a limited number of neighbors, which respond only when they have highly reliable trust information Zahariadis Expires November 21, 2009 [Page 2] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 Table of Contents 1. Terminology.................................................4 2. Conventions used in this document............................4 3. Introduction................................................5 4. Trust Framework Principles...................................6 5. Direct Trust Metrics.........................................9 5.1. Direct Trust calculation...............................10 6. Indirect Trust Metrics......................................10 6.1. Indirect Trust calculation.............................12 7. Total Trust Evaluation......................................12 8. Trust-aware Routing Considerations..........................12 9. IANA Considerations........................................14 10. Conclusions...............................................14 11. References................................................15 11.1. Normative References..................................15 11.2. Informative References................................16 12. Acknowledgments...........................................16 Zahariadis Expires November 21, 2009 [Page 3] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 1. Terminology This document conforms to the terminology defined in [RFC2119], [RFC5548] and [1], with the following additions: Neighboring Node: A node B is neighboring node to node A, if it is within the radio range of node A and node A can reach directly node B (it is only one hop away). Malicious Node: A node that introduces any type of attack in a LLN, including exchange of false or incorrect messages at networking layer. Reliable Node: A node that realizes the applied routing protocol and does not introduce any attacks in a LLN. Trust: shows the level of certainty of node A that node B is a reliable node. We denote as T(A, B) the trust of entity A to node B. Trust metric: A value indicating the trust that node A maintains for node B with respect to a specific behaviour aspect or event. Reputation: of node B with respect to neighboring node C is the trust that nodes C publishes about node B. Also it is referred to as recommendation of node B according to node C. Direct Trust: a value indicating the trust that node A builds progressively for node B, utilizing its own routing experience (direct interactions). We denote as DT(A,B) the direct trust value that A has built for node B based on a set of events. Indirect Trust: a value indicating the trust that node A builds for node B based on the reputations provided by neighboring nodes. We denote as IT(A,B) the indirect trust value that A calculates for neighboring node B. Confidence Level: a value indicating the certainty of node A that its direct trust concerning node B is correct. 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 [RFC2119]. Zahariadis Expires November 21, 2009 [Page 4] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 3. Introduction Wireless Sensor and Low power and Lossy Networks (LLNs) offer efficient low-cost solutions for a great variety of application domains, including commercial buildings control home control and automation applications [4], as well as industrial and urban environments control [5]. Due to their deployment requirements, the mass volume of nodes and the limited transmission range, LLNs are required to operate in an open, cooperative, ad-hoc manner, which implies that they should be capable of self-organizing and rely on the cooperation among nodes for the execution of networking tasks, such as hop-by-hop routing towards the destination. The necessary cooperativeness and openness of the LLNs' networking tasks combined with the very limited nodes' resources introduces important intricacies which dictate the design of new protocols. On one hand, security issues are inherently introduced due to the wireless operation. Eavesdropping can be easily performed in this environment, which makes the network vulnerable not only to privacy, but also to traffic analysis attacks, which threaten the whole network operation. On the other hand, the limited node resources in terms of memory space, processing power, and energy do not allow sophisticated security mechanisms (such as complex cryptography and authentication mechanisms) to be implemented. To this end, although vital for most application cases, security in LLNs is seriously threatened, while the routing procedure is at the focus of adversaries, due to its importance for the proper network operation and its vulnerability introduced by its cooperative nature in this environment. Attacks targeting the disruption of the routing procedure have been identified in the literature ([Karlof2003], [Kannhavog2007], [Giruka2008]). The routing attacks affect among others confidentiality, integrity and availability [7]. To handle malicious behaviors, an approach borrowed from human societies has been proposed in the literature; a trust management system is implemented, where entities (nodes) monitor the behavior of their neighbors in order to establish trust relations amongst them and base their routing decisions not only on pure routing information, but also on their expectation (trust) that their neighbors will sincerely cooperate. In other words, the notion of trust, in the realm of network security, can be translated as a set of relations among entities (nodes) that cooperatively execute a Zahariadis Expires November 21, 2009 [Page 5] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 protocol. These relations are based on the evidence generated by the previous interactions of the entities with respect to the employed protocol. Consequently, the evaluation of trust is based on several metrics that lead to trust establishment between the nodes. The detection of an unexpected behavior based only on direct evidence (i.e. measurements) and in a reliable way may take some time since an important number of interactions are required. Newly activated or just arrived nodes can benefit from their neighbors' experience: they become aware of the trustworthiness of each neighbor based on indirect trust information (also called recommendation) provided by other neighbors. However, specific attacks targeting the reputation protocol have also been described in the literature ([Sun2008]). The trust T(A, B) can be considered as a routing metric related to security allowing for trust-wise routing decisions to protect the LLN from a set of routing attacks. The implementation of any trust management system consumes node and network resources and should thus be carefully designed. This document describes a distributed trust framework, which may improve the security and robustness of routing over LLNs, against an increased set of attacks, including combined attacks. The trust framework is orthogonal to the routing protocol. However, the combination of a trust framework with a relative location routing algorithm (such as [Watteyne2008] may work in synergy to further enhance security, while efficiently supporting scalability and network dynamicity at the same time. 4. Trust Framework Principles The described trust framework aims to: 1. Cope with security concerns described in [7], 2. Fulfill the requirements mentioned in [3], [4] and [5] from an operational point of view, 3. Stand as a valuable metric in the route discovery process, as described in [RFC5548] and [2]. Additionally, the Trust Framework Model takes into consideration the following two properties that trust assessment holds, due to the dynamic, random, multi-hop nature of LLNs: Zahariadis Expires November 21, 2009 [Page 6] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 o LLNs trust relations are uncertain and time-varying, since they are based on ephemeral relations; they lack a long-term trust process, as opposed to traditional wired networks, where trust evidence is generated via potentially lengthy assurance processes. Thus, trust relations in such networks will be short-termed and need to be updated more frequently. o LLNs trust relations are incomplete, in the sense that malicious nodes may take control of a part of the network, preventing the node to communicate with friendly nodes. Based on the aforementioned remarks, the Trust Framework Model for ROLL MUST hold the following properties: 1. It SHOULD follow a fully decentralized trust management approach, i.e. the trust management functionality will be distributed over the LLN nodes. Centralized approaches SHOULD NOT be considered. Assuming homogeneous nodes, storing the necessary trust information for all the nodes of the LLN on a single node is not possible. Moreover, building such a trust framework is prone to attacks, as the trust information should be collected centrally to a node. Semi-distributed (cluster based) trust frameworks MAY also be considered. In this case, trust information of specific nodes MAY be stored only on selected nodes of the LLN. Yet, the nodes that handle the trust information would be prone to attacks, especially to Sybil attacks. A fully distributed trust framework is RECOMMENDED, as it better fits in the large, self-organized, homogeneous LLNs nature. Following the decentralized approach, each node is responsible for computing its own trust value per relation in the network, either by collecting evidence from direct interactions, or recommendations from other nodes in the network. 2. The trust framework SHOULD be based on the Total Trust (TT) value. The TT value SHOULD be a combination of both Direct and Indirect Trust values. Each node in the LLN builds progressively the Direct Trust (DT) value that corresponds to each one of its neighboring nodes, utilizing its own routing experience and network overhearing. Moreover, it builds its Indirect Trust (IT) value for each one of its neighboring nodes, utilizing trust information that it receives from selected neighboring nodes. The DT value is important as it is based on the node's own experience, while the IT value is important mainly for newly initialized nodes or recently arrived nodes (in case of mobility). Zahariadis Expires November 21, 2009 [Page 7] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 3. It SHALL use a confidence factor for the indirect trust value exchange process, which will reduce the possibility of bad-mouth attack. In this way, the indirect trust values can be checked by the requestor, leading to conclusions about the sincerity of neighbouring nodes. 4. It WILL NOT use a trust value threshold level during route discovery process. That means that all neighbouring nodes are considered potential routing candidates, based upon their trust value. In other words, trust decision is not a binary decision on who to trust and who not to. The advantage of the selected technique is that bad-mouthing attack is not sufficient to isolate a node from the whole network. 5. The reputation information MAY be requested in a reactive or proactive way, since both techniques have advantages. In reactive computing, the node computes the trust value of a hop or of the entire path, only when explicitly needed, preserving energy. On the other hand, in proactive computing, the node maintains a table containing already computed trust routes and thus the trust decision can be made without delay. The decision regarding the reputation information exchange process can be made in conjunction with the ROLL routing rules. 6. Symmetric or asymmetric information spreading MAY be used, i.e. all nodes do (or do not) have access to the same amount of trust information in the network. Adopting the principles discussed above, the trust framework model allows for the calculation of the trust which can be used as a routing metric by the routing protocol (LLN Tree Discovery) in order to locate the nearest and most trusted exit and form trusted Directed Graphs towards that exit, composed of a best path tree and alternate forwarding options, following the rules stated in [I-D.ietf-roll- fundamentals]. Moreover, dealing with security issues, the Trust Framework approach is hybrid, in the sense that well-known security measures are adopted ([7]) and combined with the trust framework, able to mitigate several attacks identified in LLN deployments. The trust model can take advantage of the traditional security measures in place, as their absence or misuse will be used as input for the establishment of trust relations and consequently feed the trust evaluation model. For example, the absence of encryption or the misinterpretation of an authentication mechanism may lead to the conclusion that a node behaves maliciously. Zahariadis Expires November 21, 2009 [Page 8] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 It must be clearly stated that it is not required to use all the metrics specified in this document. A particular implementation MAY use a subset or all of the metrics defined in this document. Also, the value update process of each trust metric MAY be evaluated in different time periods, according to the accuracy needs of the specific application. 5. Direct Trust Metrics One of the most important issues in the trust model design is to define the set of behavior aspects/metrics against which each node is evaluated. On each sensor node, a trust repository MAY be used to store trust information per neighbor and trust metric. The monitored direct trust metrics MAY include: 1. Packet forwarding: To detect nodes that deny or selectively forward packets, each time a source node transmits a packet that has to be forwarded it MAY enter the promiscuous mode and overhear the wireless medium to check whether the packet was actually forwarded by the selected neighbor. If positive, this is accounted as a successful interaction; otherwise, it is counted as a failure. 2. Network-layer Acknowledgements (ACK): To detect nodes that collude with other adversaries (which possibly drop packets) disrupting the network operation, each source node MAY wait for a network- layer ACK to check whether its message has successfully reached an LLN Border Router. 3. Message Integrity: Each time a source node transmits a message for forwarding and overhears the wireless medium to ensure that the message was forwarded, it additionally MAY process it to check the message's integrity i.e. that no unexpected modification has occurred. It thus detects modification attacks. 4. Node Authentication: In case there is an option for a node to select between a neighbor supporting authentication and another which doesn't, this metric allows for this discrimination. (If the node supports authentication, the respective value is equal to 1; 0, otherwise.) 5. Node Message Encryption: Similar to node authentication, if a node supports message encryption, the respective value is equal to 1; 0, otherwise. Zahariadis Expires November 21, 2009 [Page 9] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 5.1. Direct Trust calculation Coming to the calculation of the direct trust value, each node i stores for each neighboring node j and for each trust metric m associated with successful/failed interactions, two counters: the S(i,j,m), which denotes the successful interactions of type m and the F(i,j,m), which denotes the failed interactions. Based on them, node i calculates the trust value T(i,j,m) of each trust event m regarding each neighboring node j by using the following equation: S(i,j,m) T(i, j, m) = -------------------------- (1) S(i,j,m) + F (i,j,m) The trust values are then combined in a weighted sum to produce the total direct trust value: DT(i,j) = W(1)*T(i,j,1) + W(2)*T(i,j,2) + ... + W(5)*T(i,j,5) (2) Where W(m) stands for the weighting factor of trust metric m. All weights sum up to 1 so that the total direct trust value ranges from 0 to 1. 6. Indirect Trust Metrics Two indirect trust metrics are used in the Trust Framework: 1. Reputation Response: To check the sincere execution of the reputation protocol, each time a node transmits a reputation request message to a neighbor, the reputation request number MAY be stored in the trust table for this neighbor while the reputation response number MAY increase only if the neighbor replies (i.e. the reputation response message is received). In this way, nodes that do not cooperate in the execution of the reputation protocol are assigned lower trust values. 2. Reputation Validation: To protect against bad-mouthing attacks and wrong reputations being spread around, each time a node A receives a reputation response message from node C regarding node B, it compares the received value with its own direct trust on node B, under the condition that node A is in a certain degree confident about the direct trust value, it has calculated for node B. If the difference exceeds a predefined threshold, then the provided reputation is considered as "wrong reputation"; otherwise it is a Zahariadis Expires November 21, 2009 [Page 10] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 "correct reputation". Node A is confident for the trust value it has calculated for node B only if it has performed an adequate Number Of direct Interactions (noi). For this reason, the noi information is also kept in the trust table. The IT value is important mainly for the early stage of LLN deployment or recently arrived nodes (in case of mobility). We denote as IT(A,B) the indirect trust value that A calculates for neighboring node B. To trigger the indirect trust exchange process, each node SHOULD periodically issue a reputation request message, unless a reactive trust establishment system is decided. In such a case, it is the routing protocol that triggers the exchange of the indirect trust. Respecting the requirement for low overhead and for low resource consumption, following the proposed trust framework model a limited number (e.g. four) of neighbors MAY be queried. (If instead all N neighboring nodes were queried, they would generate N reputation response messages, resulting in significant network load burden (increasing collision probability) and exhaustion of node resources (memory space, processing power and consumed energy).) The source node MAY randomly select one node per quadrant, so that only four unicast reputation request and four unicast reputation response messages are generated (instead of N, in case all neighbors were requested). The selection of the four nodes MAY be performed based on direct trust information (i.e. the most trusted nodes are queried) or on remaining energy information. Yet, these selections would reveal to an adversary (performing traffic analysis) certain attributes of the selected (requested) nodes. Moreover, the source node needs to obtain indirect trust information for all its neighbors and this can be achieved only by asking uniformly geographically distributed nodes. Since the reputation exchange is mainly implemented to assist nodes with no or limited (direct) trust knowledge to reach a more reliable conclusion for the trustworthiness of nodes they are interested in, a requested node MAY provide its opinion for its neighbors only if it is confident about the direct trust value it has calculated. This is decided upon the so-called confidence factor C(i,j) which is calculated based on the following equation: C(i,j) = noi/( noi + 1 ) (3) where noi stands for the Number Of direct Interactions (noi) between node i and j. Zahariadis Expires November 21, 2009 [Page 11] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 The requested node scans its trust table and includes in its reputation response message the direct trust value it has calculated for all neighbors corresponding to confidence factor exceeding a predefined threshold (e.g. above 0.8). To avoid the disadvantages of reporting only positive/negative trust information, we have chosen to report only confident trust information, limiting this way the amount of communicated data (overhead) and economizing resources. 6.1. Indirect Trust calculation Once the node i that transmitted the reputation request message receives the reputation responses from k nodes (N1, N2,...,Nk), containing their trust info DT(Nx,j) for each neighboring node j, node i MAY calculate the indirect trust value for node j using the following equation: DT(i,N1)*DT(N1,j) + ... + DT(i,Nk)*DT(Nk,j) IT(i,j) = ---------------------------------------------- (4) DT(i,N1) + ... + DT(i,Nk) The received values are summed up adopting the relevant direct trust as weight factors, so that a reputation provided by a highly trusted node counts more. 7. Total Trust Evaluation Finally, the total Trust (T) value for a neighbor j MAY be produced combining direct and indirect trust values in the following formula: T(i,j) = C(i,j)*DT(i,j) + [1- C(i,j)]*IT(i,j) (5) where C(i,j) is the confidence factor defined previously. It is obvious that as the number of interactions (and thus the confidence factor, C) increases, direct trust value becomes more significant than the reputation information. 8. Trust-aware Routing Considerations The described fully distributed trust framework MAY be combined with any routing scheme (including the distance vector approach described in [2]) to offer an enhanced secure Routing over Low Power and Lossy Networks (ROLL) framework. Zahariadis Expires November 21, 2009 [Page 12] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 In more details, the trust metrics that have been proposed MAY increase security and provide countermeasures as follows: 1. Forwarding: MAY protect against all types of packet dropping attacks (black hole, grey hole, selective forwarding, etc.) 2. Network-ACK: MAY protect against all types of dropping for the whole path route and colluding nodes 3. Packet Integrity: MAY protect against all types of modification attacks 4. Authentication: MAY protect against authentication-related attacks 5. Confidentiality: MAY prefer nodes that offer cryptography 6. Reputation Responses: MAY add sincerity in reputation protocol execution 7. Reputation Validation: May protect against bad - mouthing and rumor spreading attacks. The Routing Metric (RM) MAY be calculated using the following formula: RM(i,j) = W(l)*LC(i,j) + W(t)*T(i,j) (7) Where the W(l) and W(t) are the weighting factors of the routing link cost and the total trust, LC(i,j) is the link cost between nodes i and j decided on the routing metrics included in [I-D.ietf-roll- routing-metrics] and TT(i,j) the total trust value. Moreover, W(l) + W(t) = 1. By changing the W(l) and W(t) weight factors, emphasis MAY be given either on the routing attributes or on the trust value. For example, in case of location based routing, the LC(i,j) MAY be calculated by the following equation: LC(i,j) = D(i,j) = 1 - D(j)/d (8) Where D(j) is the Euclidean distance of neighbouring node j to the LLN Border Router and d stands for the sum of the distance of all its N neighbors to the LLN Border Router, which can be calculated based on their coordinates and the coordinates of the base station. Zahariadis Expires November 21, 2009 [Page 13] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 Following equation (8), the shortest distance to the destination maximizes the D(i,j) value. 9. IANA Considerations This document includes no request for IANA actions. 10. Security Considerations The framework presented in this document provides trust analysis and design guidelines with a scope limited to ROLL. The investigation is at a high-level and not specific to a particular protocol. 11. Conclusions This document presents a trust framework based on which a routing metric related to security can be derived to improve the security and reliability of routing over LLN, and defend against an increased set of attacks related to integrity and availability. The goal of this document is to describe a trust framework in conformance with the requirements set in the following ROLL documents: [3], [4] and [5]. Also, this document can be considered as a complementary document to [6] and [7], focusing on security aspects faced on LLNs. In this context, a well-suited trust management scheme can help as a routing metric towards the best neighbor selection (amongst parents and siblings in LLN Tree Discovery) to the LLN Border Router. It is worth mentioning that the proposed framework keeps algorithmic complexity and memory allocation needs as low as possible (without jeopardizing the reliability of sensor communications), to achieve an efficient deployment of the trust model to sensor nodes available in the market. Zahariadis Expires November 21, 2009 [Page 14] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5548] Dohler, M., Watteyne, T., Winter, T., Barthel, D., Jacquenet, C., Madhusudan, G., and G. Chegaray, "Urban WSNs Routing Requirements in Low Power and Lossy Networks", RFC5548, May 2009 [1] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-01 (work in progress), October 2008. [2] P. Thubert, T. Watteyne, Z. Shelby, D. Barthel, "LLN Routing Fundamentals", draft-thubert-roll-fundamentals-01 (work in progress), April 2009. [3] J. Martocci, N. Riou, P. Mil, and W. Vermeylen, "Building Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-building-routing-reqs-05 (work in progress), February 2009. [4] Porcu, G., "Home Automation Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-home-routing-reqs-06 (work in progress), November 2008. [5] P. Thubert, S. Dwars, and T. Phinney, "Industrial Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll- indus-routing-reqs-05 (work in progress), January 2009. [6] M. Kim, JP. Vasseur, K. Pister, H. Chong, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft- ietf-roll-routing-metrics-00 (work in progress), March 2009. [7] T. Tsao, R. Alexander, M. Dohler, V. Daza, and A. Lozano "A Security Framework for Routing over Low Power and Lossy Networks", draft-tsao-roll-security-framework-00 (work in progress), February 2009. Zahariadis Expires November 21, 2009 [Page 15] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 12.2. Informative References [Giruka2008] V. C. Giruka, M. Singhal, J. Royalty, S. Varanasi, "Security in wireless sensor networks", Wireless Communications Mob. Comput. 2008; 8:1-24. [Kannhavog2007] Bounpadith Kannhavong, Hidehisa Nakayama, Yoshiaki Nemoto, And Nei Kato, Abbas Jamalipour, "A survey of routing attacks in mobile ad hoc networks", IEEE Wireless Communications, October 2007, pp. 85-91. [Karlof2003] Chris Karlof, David Wagner, "Secure Routing in Wireless Sensor Networks: Attacks and Countermeasures", Ad Hoc Networks Elsevier ed. Vol. 1 (2003) pp. 293-315. [Sun2008] Yan (Lindsay) Sun, Zhu Han, K. J. Ray Liu, "Defense of Trust Management Vulnerabilities in Distributed Networks", IEEE Communications Magazine, Vol. 25, No.2, February 2008, pp. 112-119 [Watteyne2008] T. Watteyne, I. Auge-Blum, M. Dohler, S. Ubeda, D. Barthel, "Centroid Virtual Coordinates - A Novel Near- Shortest Path Routing Paradigm", Elsevier Computer Networks Journal, Special Issue on Autonomic and Self-Organising Systems, October 2008 Acknowledgments The authors would like to thank the Internet Community for valuable comments. Work presented in this paper was partially supported by the EU-funded FP7 211998 project "AWISSENET" (Ad-hoc PAN and Wireless Secure Sensor Networks". Authors' Addresses Theodore Zahariadis TEI of Chalkida Psachna, Evia, 34400, Greece Phone: +30 22280 99550 Email: zahariad@teihal.gr Zahariadis Expires November 21, 2009 [Page 16] Internet-Draft draft-zahariad-roll-trust-framework-00 May 2009 Helen Leligou TEI of Chalkida Psachna, Evia, 34400, Greece Phone: +30 22280 99550 Email: leligou@teihal.gr Panagiotis Karkazis TEI of Chalkida Psachna, Evia, 34400, Greece Phone: +30 22280 99550 Email: karpa@teihal.gr Panagiotis Trakadas Hellenic Authority for the Information and Communication Security and Privacy (ADAE) Ierou Lohou 3, Marousi 151 24, Athens, Greece Phone: +30-2106387619 Email: trakadasp@adae.gr Sotiris Maniatis Hellenic Authority for the Information and Communication Security and Privacy (ADAE) Ierou Lohou 3, Marousi 151 24, Athens, Greece Phone: +30-2106387619 Email: smaniatis@adae.gr Zahariadis Expires November 21, 2009 [Page 17]