Nodes bearing grudges
•
1 recomendación•233 vistas
Towards Routing Security, Fairness, and Robustness in Mobile Ad Hoc Networks From Birds to Network Nodes Components in Each Node Information Flow in Each Node Information Flow Between Nodes
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Destacado
Destacado (14)
Similar a Nodes bearing grudges
Similar a Nodes bearing grudges (20)
Más de Paul Yang
Más de Paul Yang (20)
Último
Último (20)
Nodes bearing grudges
- 1. 1 Nodes Bearing Grudges: Towards Routing Security, Fairness, and Robustness in Mobile Ad Hoc Networks Sonja Buchegger, Jean-Yves Le Boudec IBM Zurich Research Laboratory 報告者 : 楊曜年 指導教授 : 劉如生 博士
- 2. 2 Outline Introduction Bearing Grudges: The Selfish Gene Application and Improvements: The Grudger Protocol From Birds to Network Nodes Components in Each Node Information Flow in Each Node Information Flow Between Nodes Extension to DSR Future Work - Next Steps and Conclusions
- 3. 3 Introduction MANET do not rely on any fixed infrastructure but communicate in a self-organized way MANET is particularly vulnerable due to its fundamental characteristics, such as open medium, dynamic topology, distributed cooperation, and constrained capability. Each mobile node operates not only as a host but also as a router.
- 4. 4 Special Security Issues for Mobile Ad Hoc Networks Cooperation and fairness: There is a trade-off between good citizenship message interception, copying, or forging; incorrect forwarding; and bogus routing advertisement Confidentiality of location:
- 5. 5 Special Security Issues for Mobile Ad Hoc Networks Motivation for Attacks Better service than cooperating nodes, monetary benefits by exploiting incentive measures or trading confidential information… Thwarting Attacks: Objectives Prevention, detection and reaction: A prevention-only strategy only works if the prevention mechanisms are perfect
- 6. 6 Bearing Grudges: The Selfish Gene Richard Dawkins’ ‘The Selfish Gene’[5] Reciprocal altruism is beneficial for every biological system when favors are granted simultaneously, so there is an intrinsic motivation for cooperation due to instant gratification. A biological example the survival chances of birds grooming parasites off each other’s head, which they cannot clean themselves.
- 7. 7 Bearing Grudges: The Selfish Gene (cont) Suckers Cheats In this system, clearly the cheats have an advantage over the suckers, but both are driven to extinction over time. Grudger Starts out being helpful to every bird, but bears a grudge Simulation: Grudger is the winner of gene reselection over time
- 8. 9 Application and Improvements: The Grudger Protocol Components in Each Node
- 9. 10 Components in Each Node The Monitor can detect deviances by the next node on the source route no forwarding, unusual traffic attraction , route salvaging, lack of error messages, unusually frequent route updates, silent route change
- 10. 11 Components in Each Node The Trust System Deals with incoming and outgoing ALARM messages. Similar to the trust management in Pretty Good Privacy (PGP) Unknown, None, Marginal and Complete It consists of following component: Alarm table containing info about received alarms Trust table managing trust level for nodes Friends list containing all friends a node sends alarms to
- 11. 12 Components in Each Node The Reputation System (Node rating) Used in some online auctioning systems Provides a means of obtaining a quality rating Local rating lists and black list Different weights to the type of behavior detection: Own experience: greatest weight Observations: smaller weight Reported experience: weight function according to PGP trust.
- 12. 13 Components in Each Node The Path Manager Path re-ranking Deletion of paths containing malicious nodes, Action on receiving a request for a route from a malicious node (e.g. ignore, do not send any reply) , Action on receiving request for a route containing a malicious node in the source route (e.g. also ignore, alert the source).
- 13. 14 Application and Improvements: The Grudger Protocol Information Flow in Each Node Monitor Reputation system Trust Manager Path Manager Monitor Monitor Node A E D B CMonitor Monitor
- 14. 15 Application and Improvements: The Grudger Protocol Information Flow Between Nodes Reputation system Trust Manager Path Manager Node A Node B Monitor Reputation system Trust Manager Path Manager Monitor ALARM ALARM ALARM
- 15. 16 Application and Improvements: The Grudger Protocol Information Flow Between Nodes 1. The type of protocol violation 2. The number of occurrences observed 3. The address of the reporting node 4. The address of the observed node The content of Alarm Message 5. The destination address
- 16. 17 Application and Improvements: The Grudger Protocol Information Flow Between Nodes Reputation system Trust Manager Path Manager MonitorALARM from outside node If the source is at least partially trusted If there is enough evidence that the node reported in the ALARM is malicious If that occurrence threshold is exceeded and the rating subsequently turns out to be intolerable
- 17. 18 Application and Improvements: The Grudger Protocol the source is fully or partially trusted the ALRAM table is updated the node reported in the ALARM is malicious Monitoring and receiving Receive Alarms Alarm is sent to the reputation system No No
- 18. 20 Extension to DSR Route Discovery:Route Discovery: Example of a route request a. Node S sends out a ROUTE REQUEST packet to find a path to node D
- 19. 21 b. The ROUTE REQUEST is forwarded throughout the network, each node adding its address to the packet Route Discovery:Route Discovery: Example of a route request Extension to DSR
- 20. 22 c. D sends back a ROUTE REPLY to S using the path contained in one of the ROUTE REQUEST packet that reached it Route Discovery:Route Discovery: Example of a route request Extension to DSR
- 21. 23 •Forwarding: this can be detected by passive acknowledgement, •Bogus routing: a strong indication would be when an intermediate node sees itself advertised on a route it does not have •Metrics of bogus routes too good: detectable by comparing metrics to actual quality. •Route updates too frequent: detectable by keeping timestamp of last update to compare Attacking DSR and Detection of attacks in DSR Extension to DSR
- 22. 24 Route request: A wants to send to E. Grudging Nodes in DSR Extension to DSR
- 23. 25 Route reply: both D and E know a path to E. Grudging Nodes in DSR Extension to DSR
- 24. 26 Data flow and alarm: A sends data and receives an ALARM from C that D does not forward. Grudging Nodes in DSR Extension to DSR
- 25. 27 Act on alarm: reroute: A uses an alternate path to E. Grudging Nodes in DSR Extension to DSR
- 26. 28 The next steps will consist of implementing more of the approaches discussed so far in simulations for evaluation and performance analysis. The focus is on finding a sustainable relationship between the total number of nodes in the network, the number of malicious nodes that can be tolerated and the number of friends per node needed to achieve that. Future Work - Next Steps and Conclusions
Notas del editor
- Each node participates in an ad hoc routing protocol that allows it to discover multihop paths through the network to any other node. The idea of MANET is also called infrastructureless networking, since the mobile nodes in the network dynamically establish routing among themselves to form their own network on the fly. It is formed instantaneously, and uses multihop routing to transmit information.
- Cooperation and fairness: There is a trade-off between good citizenship, i.e. cooperation, and resource consumption, so nodes have to economize on their resources. At the same time, however, if they do not forward messages, others might not forward either, thereby denying them service. Total non-cooperation with other nodes and only exploiting their readiness to cooperate is one of several boycotting behavior patterns. Therefore, there has to be an incentive for a node to forward messages that are not destined to itself. Attacks include incentive mechanism exploitation by message interception, copying, or forging; incorrect forwarding; and bogus routing advertisement. Confidentiality of location: In some scenarios, for instance in a military application, routing information can be equally or even more important than the message content itself [6]. No traffic diversion: Routes should be advertised and set up adhering to the chosen routing protocol and should truthfully reflect the knowledge of the topology of the network. By diverting the traffic in the following ways, nodes can work against that requirement: Routing: To get information necessary for successful malicious behavior, nodes can attract traffic to themselves or their colluding nodes by means of false routing advertisements. Although only suitable for devices that have enough power, a lot of information can be gathered this way by malicious nodes for later use to enable more sophisticated attacks. Denial-of-service attacks can be achieved by bogus routing information (injecting of incorrect routing information or replay of old routing information or ‘black hole routes’ ) or by distorting routing information to partition the network or to load the network excessively, thus causing retransmissions. Dear .... that is a boring but so-miss you night again, you know right now is 04:06.. And I’m making that such shit report and browsing our pictures of Japan trip Raining outside as well as last night …and just to ask are u get up and ready to go to school?? I don’t want to lie you , it’s really tough time that I can’t see you and what my mind I’m thinking right now is that it’s always your image and what we ever did fun before. Ting, my wife…I really miss……you … and hope I can see you soon. Hope you everything well in school and don’t forget to see doctor for cold and ur tooth. Your N-ien.
- Objectives If, however, a node was wrongly accused of being malicious or turns out to be a repenting criminal equivalent who is no longer malicious and has behaved normally for a certain amount of time, some sort of ‘re-socialization’ and re-integration into the network communications should be possible. Prevention, detection and reaction: According to Schneier [14], a prevention-only strategy only works if the prevention mechanisms are perfect; otherwise, someone will find out how to get around them. Most of the attacks and vulnerabilities have been the result of bypassing prevention mechanisms. Given this reality, detection and response are essential
- 1. 當某一個mobile node發送的packet在routing table 找不到適合的路徑可以到達它所要傳送的destination node，它就廣播Route Requests (RREQs) 去找尋到達destination node的新路徑。 2. 當RREQs的訊息到達它所指定的destination node，便會傳回Route Replies (RREPs)給原本發送RREQs的mobile node。 3. 處理封包在轉送的途中發生找不到路徑的情況時，即Route Errors (RERRs)之處理。 4. Hello Message所扮演的角色及功能 Route Requests(RREQs)的發送與處理 當某一mobile node欲傳送packet給某一個destination node，packet在IP header建立時，便會去檢查它的routing table，若找不到可到達destination node 的route entry，此mobile node便會去廣播Route Requests (RREQs)去尋找新路徑。然後，當收到RREQs的mobile nodes先去檢查看看此packet的destination address是否為自己，如果不是，則再看看此intermediate node是否有一條 “fresh enough”的路徑可以到達destination node，如果沒有，先依據packet已有的address sequence資訊修改routing table，再把它廣播出去。 每一個RREQs都配有一個ID，當某一個mobile node收到一個RREQs之後，先去給它檢查看看之前是否也有收過，假如收過了，就將此packet丟棄，如此可以防止RREQs的無限制充斥在這個無線的Ad hoc網路中，而且避免各個mobile node中routing table的路徑形成迴圈的情況。 何謂 “fresh enough” route？ 一個 “fresh enough” route 針對目的端來說，它是一個未到期的route entry，而且它結合了sequence number來判斷它到底是不是一個 “ fresh enough” route，只有當目前的sequence number至少大於包含在RREQ裡面的sequence number，才是一個 “ fresh enough” route。 Route Replies (RREPs) 之發送與處理 當intermediate node 收到RREQ的訊息後，發現RREQ中所記載的destination address是自己，則先依據RREQ中所記載的address sequence去更改routing table，而且由於每一個mobile node接收了這個RREQ的要求後，它們就會去cache住一個route去返回到當初發出RREQ要求的來源端，然後利用unicast的方法送出Route Reply (RREP)從destination node到這個source node，或者從能夠滿足這個要求的任何一個intermediate node 返回到這個來源端，途中的mobile node根據RREP中所記載的address sequence 去更改routing table，最後source node的routing table就含有到達destination node的entry，接下來就是真正的data packet開始傳送了。 Route Errors (RERRs)之確認與處理 一個mobile node會在下列的兩種情況下，開使去發出一個RRER的訊息。 1. 假如有一個mobile node偵測到在它自己的routing table裡的一個active route，而它無法與此active route的下一個hop做溝通，也就是有一個link break的情況發生。 2. 假如有一個mobile node獲的得一個data packet，它要去傳送到某一個mobile node，但它並沒有一個active route，可以讓它去做這樣的傳送。
- 1. 當某一個mobile node發送的packet在routing table 找不到適合的路徑可以到達它所要傳送的destination node，它就廣播Route Requests (RREQs) 去找尋到達destination node的新路徑。 2. 當RREQs的訊息到達它所指定的destination node，便會傳回Route Replies (RREPs)給原本發送RREQs的mobile node。 3. 處理封包在轉送的途中發生找不到路徑的情況時，即Route Errors (RERRs)之處理。 4. Hello Message所扮演的角色及功能 Route Requests(RREQs)的發送與處理 當某一mobile node欲傳送packet給某一個destination node，packet在IP header建立時，便會去檢查它的routing table，若找不到可到達destination node 的route entry，此mobile node便會去廣播Route Requests (RREQs)去尋找新路徑。然後，當收到RREQs的mobile nodes先去檢查看看此packet的destination address是否為自己，如果不是，則再看看此intermediate node是否有一條 “fresh enough”的路徑可以到達destination node，如果沒有，先依據packet已有的address sequence資訊修改routing table，再把它廣播出去。 每一個RREQs都配有一個ID，當某一個mobile node收到一個RREQs之後，先去給它檢查看看之前是否也有收過，假如收過了，就將此packet丟棄，如此可以防止RREQs的無限制充斥在這個無線的Ad hoc網路中，而且避免各個mobile node中routing table的路徑形成迴圈的情況。 何謂 “fresh enough” route？ 一個 “fresh enough” route 針對目的端來說，它是一個未到期的route entry，而且它結合了sequence number來判斷它到底是不是一個 “ fresh enough” route，只有當目前的sequence number至少大於包含在RREQ裡面的sequence number，才是一個 “ fresh enough” route。 Route Replies (RREPs) 之發送與處理 當intermediate node 收到RREQ的訊息後，發現RREQ中所記載的destination address是自己，則先依據RREQ中所記載的address sequence去更改routing table，而且由於每一個mobile node接收了這個RREQ的要求後，它們就會去cache住一個route去返回到當初發出RREQ要求的來源端，然後利用unicast的方法送出Route Reply (RREP)從destination node到這個source node，或者從能夠滿足這個要求的任何一個intermediate node 返回到這個來源端，途中的mobile node根據RREP中所記載的address sequence 去更改routing table，最後source node的routing table就含有到達destination node的entry，接下來就是真正的data packet開始傳送了。 Route Errors (RERRs)之確認與處理 一個mobile node會在下列的兩種情況下，開使去發出一個RRER的訊息。 1. 假如有一個mobile node偵測到在它自己的routing table裡的一個active route，而它無法與此active route的下一個hop做溝通，也就是有一個link break的情況發生。 2. 假如有一個mobile node獲的得一個data packet，它要去傳送到某一個mobile node，但它並沒有一個active route，可以讓它去做這樣的傳送。
- learn from observed behavior: employ ‘neighborhood watch’ to be warned by watching what happens to other nodes in the neighborhood, before nodes have to make a bad experience themselves learn from reported behavior: share information of experienced malicious behavior with friends and learn from them.
- The Monitor : The neighbors of the neighborhood watch can detect deviances by the next node on the source route by either listening to the transmission of the next node or by observing route protocol behavior. By keeping a copy of a packet while listening to the transmission of the next node, any content change can also be detected no forwarding (of control messages nor data), unusual traffic attraction (advertises many very good routes or advertises routes very fast, so they aredeemed good routes), route salvaging (i.e. rerouting to avoid a broken link), although no error has been observed, lack of error messages, although an error has been observed, unusually frequent route updates, silent route change (tampering with the message header of either control or data packets). As a component within each node, the monitor registers these deviations of normal behavior. As soon as a given bad behavior occurs, the reputation system is called.
- The Monitor : The neighbors of the neighborhood watch can detect deviances by the next node on the source route by either listening to the transmission of the next node or by observing route protocol behavior. By keeping a copy of a packet while listening to the transmission of the next node, any content change can also be detected As a component within each node, the monitor registers these deviations of normal behavior. As soon as a given bad behavior occurs, the reputation system is called.
- The Reputation System: Trust function to calculate trust levels, Trust table entries management for trust level administration, Forwarding of ALARM messages, Filtering of incoming ALARM messages according to the trust level of the reporting node. A mechanism similar to the trust management in Pretty Good Privacy (PGP) for key validation and certification is used here for mobile ad hoc networks for trust management for routing and forwarding. When PGP is calculating the validity of a public key, it examines the trust level of all the attached certifying signatures. It computes a weighted score of validity. For example, two marginally trusted signatures might be deemed credible as one completely trusted signature. The weighting scheme is adjustable to require a different number of marginally trusted signatures to judge a key as valid. The trust manager consists of the following ZZXZZZZZXXXZZZZ XCCCCCCCCCC XXXZZX CCX CCCCCCCCCCCCCCCXcomponents: Alarm table containing information about received alarms, Trust table managing trust levels for nodes, Friends list containing all friends a node sends alarms to. The trust manager administers a table of friends, i.e. nodes that are candidates to receive ALARM messages from a given node, and how much they are trusted. Trust is important when making a decision about the following issues: o providing or accepting routing information, o accepting a node as part of a route, o taking part in a route originated by some other node.
- The Reputation System: Reputation systems are used in some online auctioning systems. They provide a means of obtaining a quality rating of participants of transactions by having both the buyer and the seller give each other feedback on how their activities were perceived and evaluated. For a detailed explanation of reputation systems see Resnick et al. [13]. In order to avoid centralized rating, local rating lists and/or black lists are maintained at each node and potentially exchanged with friends. The nodes can include black sheep in the route request to be avoided for routing, which also alarms nodes on the way. Nodes can look up senders in the black list containing the nodes with bad rating before forwarding anything for them. The problem of how to distinguish alleged from proven malicious nodes and thus how to avoid false accusations can be lessened by timeout and subsequent recovery or revocation lists of nodes that have behaved well for a specified period of time. Another problem is scalability and how to avoid blown-up lists, which can also be addressed by timeouts. The reputation system in this protocol manages a table consisting of entries for nodes and their rating. The rating is changed only when there is enough evidence for malicious behavior that is significant for a node and that has occurred a number of times exceeding a threshold to rule out coincidences. The rating is then changed according to a rate function that assigns different weights to the type of behavior detection: The reputation system in this protocol manages a table consisting of entries for nodes and their rating. The rating is changed only when there is enough evidence for malicious behavior that is significant for a node and that has occurred a number of times exceeding a threshold to rule out coincidences. The rating is then changed according to a rate function that assigns different weights to the type of behavior detection: o Own experience: greatest weight, o Observations: smaller weight, o Reported experience: weight function according to PGP trust. Once the weight has been determined, the entry of the node that misbehaved is changed accordingly. If the rating of a node in the table has deteriorated so much as to fall out of a tolerable range, the path manager is called for action. Bearing in mind that malicious behavior will hopefully be the exception and not the rule, the reputation system is built on negative experience rather than positive impressions. The questions of positive change and timeout are still to be addressed in detail.
- Path re-ranking according to security metric, o Deletion of paths containing malicious nodes, o Action on receiving a request for a route from a malicious node (e.g. ignore, do not send any reply) , o Action on receiving request for a route containing a malicious node in the source route (e.g. also ignore, alert the source).
- As shown in Figure1 1, each node monitors the behavior of its next hop neighbors. 2. If a suspicious event is detected, the information is given to the reputation system. 3. If the event is significant for the node, as defined initially for the type of node, for different nodes can have different security requirements, it is checked whether the event has occurred more often than a predefined threshold high enough to distinguish deliberate malicious behavior from simple coincidences such as collisions. 4. If that occurrence threshold is exceeded, the reputation system updates the rating of the node that caused that event. 5. If the rating subsequently turns out to be intolerable, the information is passed on to the path manager that proceeds to delete all routes containing the intolerable node from the path cache. 6.The node continues to monitor the neighborhood and an ALARM message is sent as described in the next subsection.
- In order to convey warning information, an ALARM message is sent by the trust manager component. This message contains the type of protocol violation, the number of occurrences observed, whether the message was self originated by the sender, the address of the reporting node, the address of the observed node and the destination address (either the source of the route or the address of a friend that might be interested). When the monitor component of a node receives such an ALARM message, it passes it on to the trust manager, where the source of the message is evaluated. If the source is at least partially trusted, the table containing the ALARMs is updated. If there is enough evidence that the node reported in the ALARM is malicious, the information is sent to the reputation system where it is again evaluated for significance, number of occurrences and accumulated reputation of the node as explained in Section 4.3. Enough evidence means that either the source of the ALARM is fully trusted or that several partially trusted nodes have reported the same and their respective assigned trust adds up to a value of one entirely trusted node or more.
- In order to convey warning information, an ALARM message is sent by the trust manager component. This message contains the type of protocol violation, the number of occurrences observed, whether the message was self originated by the sender, the address of the reporting node, the address of the observed node and the destination address (either the source of the route or the address of a friend that might be interested). When the monitor component of a node receives such an ALARM message, it passes it on to the trust manager, where the source of the message is evaluated. If the source is at least partially trusted, the table containing the ALARMs is updated. If there is enough evidence that the node reported in the ALARM is malicious, the information is sent to the reputation system where it is again evaluated for significance, number of occurrences and accumulated reputation of the node as explained in Section 4.3. Enough evidence means that either the source of the ALARM is fully trusted or that several partially trusted nodes have reported the same and their respective assigned trust adds up to a value of one entirely trusted node or more.
- In order to convey warning information, an ALARM message is sent by the trust manager component. This message contains the type of protocol violation, the number of occurrences observed, whether the message was self originated by the sender, the address of the reporting node, the address of the observed node and the destination address (either the source of the route or the address of a friend that might be interested). When the monitor component of a node receives such an ALARM message, it passes it on to the trust manager, where the source of the message is evaluated. If the source is at least partially trusted, the table containing the ALARMs is updated. If there is enough evidence that the node reported in the ALARM is malicious, the information is sent to the reputation system where it is again evaluated for significance, number of occurrences and accumulated reputation of the node as explained in Section 4.3. Enough evidence means that either the source of the ALARM is fully trusted or that several partially trusted nodes have reported the same and their respective assigned trust adds up to a value of one entirely trusted node or more.
- In order to convey warning information, an ALARM message is sent by the trust manager component. This message contains the type of protocol violation, the number of occurrences observed, whether the message was self originated by the sender, the address of the reporting node, the address of the observed node and the destination address (either the source of the route or the address of a friend that might be interested). When the monitor component of a node receives such an ALARM message, it passes it on to the trust manager, where the source of the message is evaluated. If the source is at least partially trusted, the table containing the ALARMs is updated. If there is enough evidence that the node reported in the ALARM is malicious, the information is sent to the reputation system where it is again evaluated for significance, number of occurrences and accumulated reputation of the node as explained in Section 4.3. Enough evidence means that either the source of the ALARM is fully trusted or that several partially trusted nodes have reported the same and their respective assigned trust adds up to a value of one entirely trusted node or more.
- In order to convey warning information, an ALARM message is sent by the trust manager component. This message contains the type of protocol violation, the number of occurrences observed, whether the message was self originated by the sender, the address of the reporting node, the address of the observed node and the destination address (either the source of the route or the address of a friend that might be interested). When the monitor component of a node receives such an ALARM message, it passes it on to the trust manager, where the source of the message is evaluated. If the source is at least partially trusted, the table containing the ALARMs is updated. If there is enough evidence that the node reported in the ALARM is malicious, the information is sent to the reputation system where it is again evaluated for significance, number of occurrences and accumulated reputation of the node as explained in Section 4.3. Enough evidence means that either the source of the ALARM is fully trusted or that several partially trusted nodes have reported the same and their respective assigned trust adds up to a value of one entirely trusted node or more.
- In order to convey warning information, an ALARM message is sent by the trust manager component. This message contains the type of protocol violation, the number of occurrences observed, whether the message was self originated by the sender, the address of the reporting node, the address of the observed node and the destination address (either the source of the route or the address of a friend that might be interested). When the monitor component of a node receives such an ALARM message, it passes it on to the trust manager, where the source of the message is evaluated. If the source is at least partially trusted, the table containing the ALARMs is updated. If there is enough evidence that the node reported in the ALARM is malicious, the information is sent to the reputation system where it is again evaluated for significance, number of occurrences and accumulated reputation of the node as explained in Section 4.3. Enough evidence means that either the source of the ALARM is fully trusted or that several partially trusted nodes have reported the same and their respective assigned trust adds up to a value of one entirely trusted node or more.
- *Source Route **Route Cache ***Route Discovery ****Target and Initiator *****Route Reply ******( Initiator Address and Request ID ) Source wanna send packet to Destination a.