Network Working Group Y. Ohara Internet-Draft JAIST Expires: December 31, 2011 A. Kato Keio Univ. Jun 29, 2011 Consideration on OSPF LSDB Monitoring draft-ohara-ospf-lsdb-monitoring-consideration-00 Abstract Many people believe that any LSA once flooded throughout the OSPF area can be monitored on all OSPF routers in the area. This is not always true, and a malicious OSPF router that pretends to be legal may want to, and be able to, hide malicious LSAs. This document proposes the modifications to OSPF specification to prevent hiding the malicious LSAs, and to make LSDB monitoring more successful (hence, secure). 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 31, 2011. Copyright Notice Copyright (c) 2011 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 document must Ohara & Kato Expires December 31, 2011 [Page 1] Internet-Draft OSPF LSDB Mon. Jun 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Insecure LSDB Monitoring: a failure to capture the malicious LSA . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Secure LSDB Monitoring . . . . . . . . . . . . . . . . . . 7 4. Suggested Modifications to the OSPF Specification . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Ohara & Kato Expires December 31, 2011 [Page 2] Internet-Draft OSPF LSDB Mon. Jun 2011 1. Introduction All systems should (if not must) be monitored to confirm that it is not executing any undesirable activities. OSPF, a core protocol for IP network, is also such a system. In OSPF, it is believed that one can monitor the whole area by monitoring LSDB change in any router in the area. This is due to the OSPF's link state principle; all information is flooded to all routers in the area, so that all routers can compute their routes autonomously and independently (distributed computation). If a network operator is watching LSA changes in the area at one point, it is almost equivalent to monitoring OSPF activities at all routers in the area, due to the nature of the link state protocol. However, the LSDB monitoring technique (watching LSDB exchanges of a router at one point in the area) has a few problems. 1. The origin of an LSA can easily be spoofed. There is no way to make it sure where an LSA is originated, other than to monitor OSPF traffic of all the link in the OSPF area. (Monitoring OSPF traffic of all the link is very expensive in terms of operational cost, and usually very difficult if not impossible.) Moreover, an LSA can be easily overridden or removed by another router when the source origin ID of the LSA (i.e., Advertising Router) is spoofed. 2. Monitoring all the contents of many LSAs and detecting incorrect contents (either erroneous or malicious) are sometimes tough task. The large number of types of LSAs and their data fields are making it hard to detect an unusual information, unless the LSDB monitor parses all LSA formats and their contents (usually not done). An example of this consequence is the problem of Covert Channel using OSPF, where malicious communication channel using OSPF is open, while the existence of the channel is not obvious. 3. It is possible that some of the OSPF activities in the area cannot be monitored by monitoring at one point in the area. In a very rare case depending on the timing of the LSA flooding and the topology, some LSA instances may not reach to all OSPF routers in the area, and hence not to the monitoring point. An detailed example is described in Section 2. The Insecure LSDB Monitoring: a failure to capture the malicious LSA. This document focuses on the last bullet 3, because if all OSPF activities are guaranteed to be monitored, bullets 1 and 2 (the problems of finding the true LSA origin and unusual LSA contents) Ohara & Kato Expires December 31, 2011 [Page 3] Internet-Draft OSPF LSDB Mon. Jun 2011 both may become easier to solve. Many OSPF operators tend to think that "all OSPF router in the area see all the LSAs flooded in the area". This is wrong, to be precise. The fact that "an OSPF LSA might not entirely be flooded throughout the OSPF area" and "Some contents in the LSAs might not be captured by some of the other OSPF routers in the area" are not so commonly understood. Let us denote that the LSDB monitoring at one point in the area be "insecure" because it may fail to capture all LSAs. The goal of this document is to provide a way to achieve "secure" LSDB monitoring without excessive operational burden, where LSDB monitoring always capture all LSA instances. The secure LSDB monitoring surely contributes to the problem of finding the unusual LSA contents such as malicious activities. This document proposes the modifications to the OSPF specification, to guarantee that "every LSA content flooded in the area is always delivered to all OSPF routers" (i.e. the achievement of the secure LSDB monitoring). Specifically, this document proposes to add a check on reception of a premature-aging (MaxAged) LSA. The check is to see if the contents is the same between the local LSA copy being removed and the received LSA being removing. This additional check prevents all LSA contents from being removed without being flooded in the area at least once. Next, this document proposes to add two additional conditions on updating LSA instances. Those are to guarantee that all LSA contents are flooded in the area before being overridden with newer contents. With these modifications, all LSA contents are guaranteed to be flooded throughout the area. Hence, the secure LSDB monitoring works on any router as expected. Details of the proposal is explained in Section 3. The Secure LSDB Monitoring. Ohara & Kato Expires December 31, 2011 [Page 4] Internet-Draft OSPF LSDB Mon. Jun 2011 2. The Insecure LSDB Monitoring: a failure to capture the malicious LSA The malicious OSPF routers might try to withdraw the malicious LSA (say, immediately after the malicious contents accomplished its purpose), trying best to hide its malicious activity, from all other routers in the area. As a consequence of the withdraw, some of OSPF routers in the OSPF area may not see the malicious LSA, depending on the timing of LSA flooding and the topology. An example is explained in this section. Receiver +--+ Sender /-----------+B +-----------\ +-++ +--+ ++-+ |A | |C | +-++ +--+ +--+ +--+ ++-+ \----+D +---+E +---+F +----/ ++-+ +--+ +--+ | ++-+ |G | +--+ LSDB Monitor Figure 1: Example Topology Suppose that the two malicious OSPF routers (the router A and C in Figure 1) are trying to communicate with each other. The router C floods a malicious LSA to convey a malicious contents to be received by the router A. Suppose that when the malicious LSA reached to the router A, the malicious LSA is held in the LSDBs of the routers marked with "x" (Figure 2). Receiver +--+ Sender /-----------+Bx+-----------\ +-++ +--+ ++-+ |Ax| |Cx| +-++ +--+ +--+ +--+ ++-+ \----+D +---+E +---+Fx+----/ ++-+ +--+ +--+ | ++-+ |G | +--+ LSDB Monitor Figure 2: Flooding of the Malicious LSA Ohara & Kato Expires December 31, 2011 [Page 5] Internet-Draft OSPF LSDB Mon. Jun 2011 When the router A receives the malicious LSA, it immediately execute the procedure of premature aging for the malicious LSA, trying to hide the malicious LSA from all other routers. In doing so, the router A advertises the Max-Aged, empty contents, instance of the malicious LSA, spoofing the Advertising Router field. Let us illustrate the Max-Aged LSA "p". The LSA "p" is flooded from the router A, while the original malicious LSA instance "x" is also kept flooding (to the router E from F). The status becomes now as in Figure 3. Receiver +--+ Sender /-----------+Bp+-----------\ +-++ +--+ ++-+ |Ap| |Cx| +-++ +--+ +--+ +--+ ++-+ \----+Dp+---+Ex+---+Fx+----/ ++-+ +--+ +--+ | ++-+ |G | +--+ LSDB Monitor Figure 3: Premature Aging Note that the LSDB Monitoring router G does not receive the malicious LSA "x", because "p" is recognized more recent than "x" and the LSA "x" is rejected in the router D. Hence, the LSDB monitor fails to capture the malicious contents of "x" because the only LSA flooded to the router G, "p", does not contain the malicious contents. Ohara & Kato Expires December 31, 2011 [Page 6] Internet-Draft OSPF LSDB Mon. Jun 2011 3. The Secure LSDB Monitoring The source of the problem in Section 2 lies in the acceptance check in premature aging procedure. The current OSPF specification allows to receive the Max-Aged instance of the previous LSA, with the different contents (possibly empty). We propose to modify the OSPF specification to mandate additional identity check of the contents in premature aging procedure. By doing so, the malicious LSA (the router A in Section 2) cannot hide the malicious contents from the LSDB monitor (the router G) using premature aging procedure. However, the router A still be able to hide the malicious contents, using ordinal LSA update procedure. Suppose if the router A overrides the LSA "x" with the newer LSA with contents that seems to be valid. This case does not fall into the premature aging procedure, so the above change does not take effect. To prevent hiding with ordinal LSA update, we propose to modify OSPF specification further, to mandate that every LSAs are updated only when all the retrans-lists do not contain the LSA instance and the newer LSA is advanced just one LS Sequence Number. This modification mandates that all the LSA instance is flooded throughout the area, and restricts that the reject of the stale update does not happen. When the router A tries to override the LSA "x" with the same LS Sequence Number, no routers will receive the LSA because it is recognized that the LSA is the same instance with "x", and that receiving it again is not needed. Hence, the attempt to hide by overriding the LSA does not succeed. The most important disadvantages of this modification is that the LSA update is totally sequentialized among the entire network. The LSA update goes as LS SeqNum 1, 2, 3, and so on, with advance of just 1. This may make the efficacy and the speed of LSA flooding to degrade. This is the cost of achieving the secure LSDB monitoring. Ohara & Kato Expires December 31, 2011 [Page 7] Internet-Draft OSPF LSDB Mon. Jun 2011 4. Suggested Modifications to the OSPF Specification We propose the following modifications to the OSPF specification. 1. The premature aging can happen only when the LSA contents are identical between old and new (i.e., removed and removing) LSAs. 2. All LSA are updated only when 1) none of its instance is on any retrans-list, and 2) the LS Sequence Number is incremented by 1. Ohara & Kato Expires December 31, 2011 [Page 8] Internet-Draft OSPF LSDB Mon. Jun 2011 Authors' Addresses Yasuhiro Ohara Japan Advanced Institute of Science and Technology Asahidai 1-1 Nomi, Ishikawa 923-1292 Japan Email: yasu@jaist.ac.jp URI: http://www.jaist.ac.jp/~yasu/ Akira Kato Keio University, Graduate School of Media Design Hiyoshi 4-1-1, Kohoku Yokohama, Kanagawa 223-8526 Japan Email: kato@wide.ad.jp Ohara & Kato Expires December 31, 2011 [Page 9]