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]