Network Working Group Y. Ohara Internet-Draft JAIST Expires: January 12, 2012 A. Kato Keio Univ. Jul 11, 2011 Consideration on OSPF LSDB Monitoring draft-ohara-ospf-lsdb-monitoring-consideration-01 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 January 12, 2012. 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 January 12, 2012 [Page 1] Internet-Draft OSPF LSDB Mon. Jul 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 5. Conservative Deployment . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 12 B.1. Changes from -00 . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Ohara & Kato Expires January 12, 2012 [Page 2] Internet-Draft OSPF LSDB Mon. Jul 2011 1. Introduction All systems should be monitored to confirm that it is not executing any undesirable activities. OSPF [RFC2328], 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 is very difficult.) Hence, in general, 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 a single monitoring point. 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. A detailed example is described in Section 2. "The Insecure LSDB Monitoring: a failure to capture the malicious LSA." As a first step to make the OSPF LSDB monitoring more secure, this document focuses on the last bullet (bullet 3), assuming that if all OSPF activities are guaranteed to be monitored, bullets 1 and 2 (the Ohara & Kato Expires January 12, 2012 [Page 3] Internet-Draft OSPF LSDB Mon. Jul 2011 problems of finding the true LSA origin and unusual LSA contents) both become easier to solve. Many OSPF operators tend to think that "all OSPF routers in the area see all the LSAs flooded in the area". This is not correct, 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. We denote that the LSDB monitoring at one point in the area is "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 some 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 provision of the secure LSDB monitoring). To achieve this, this document proposes two modifications. First, 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. Second, this document proposes to add two additional conditions on updating LSA instances. They are 1) that the LSA instance is not listed on any retransmission-list, and 2) that the increment of LS Sequence Number is just 1. Those are to guarantee that all LSA contents are flooded in the area before being overridden with newer contents. The former condition strictly mandates that the LSDB is completely synchronized on all routers in the area in each step. The latter prevents the skipping (hence, dropping) of any LSA instance on any router. 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 January 12, 2012 [Page 4] Internet-Draft OSPF LSDB Mon. Jul 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 instances are 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 January 12, 2012 [Page 5] Internet-Draft OSPF LSDB Mon. Jul 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 (from the router F to E). 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 January 12, 2012 [Page 6] Internet-Draft OSPF LSDB Mon. Jul 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. The LSA "p" (i.e., a premature-aged version of "x" with empty contents) is rejected by the routers B and D, and the LSA "x" is flooded further to the router G. 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 using 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. For the case of updating using the same LS Sequence Number, the current OSPF specification does not allow overwrite. 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 January 12, 2012 [Page 7] Internet-Draft OSPF LSDB Mon. Jul 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. These conditions are added either in 13-(5)-(a) or in between 13-(5)-(a) and 13-(5)-(b), of [RFC2328]. If these conditions fail on a LSA, the LSA is silently discarded (i.e. without acknowledging it), just the same as the LSA arrived within MinLSArrival (13-(5)-(a)). This modifications make 13-(5)-(c) (replacing the instances on retrans-lists) never occur. Ohara & Kato Expires January 12, 2012 [Page 8] Internet-Draft OSPF LSDB Mon. Jul 2011 5. Conservative Deployment Even just logging the occurrences of the failures of these new conditions, and acting the unmodified protocol behavior, will help network operators to find errorneous or illegal incidents on their OSPF network. Ohara & Kato Expires January 12, 2012 [Page 9] Internet-Draft OSPF LSDB Mon. Jul 2011 6. References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. Ohara & Kato Expires January 12, 2012 [Page 10] Internet-Draft OSPF LSDB Mon. Jul 2011 Appendix A. Acknowledgements This document is supported by a commissioned research named "Research and Development on Evaluating Security of Communication Protocols and its Implementations" (2011) of National Institute of Information and Communications Technology (NICT), Japan. Ohara & Kato Expires January 12, 2012 [Page 11] Internet-Draft OSPF LSDB Mon. Jul 2011 Appendix B. Changes B.1. Changes from -00 Described the modifications specifically in 1. "Introduction." Added the specific part and the consequences of the modifications in 4. "Suggested Modifications to the OSPF Specification." Added 5. "Conservative Deployment" as a moderate proposal. Minor fixes of texts. Added References, Acknowledgements, and Changes sections. Ohara & Kato Expires January 12, 2012 [Page 12] Internet-Draft OSPF LSDB Mon. Jul 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 January 12, 2012 [Page 13]