566 CHAPTER 22 Managing and Securing Critical Infrastructure general architecture work to drive the BGP deci- sion process. More details on the architecture itself are available in [31, 32]. The Network Ontology (NetOnto) is the OWL ontology that we define to mark up the routes being exchanged. By using OWL rather than simple XML, the language is semantically richer and highly extensible which is very impor- tant especially when we have interdomain inter- actions (such as peering arrangements, SLAs etc). Policies are written using the concepts defined in NetOnto using SWRL as the rule language. OWL has axiomatic and model-theoretic seman- tics, which allows for verification of knowledge expressed in OWL constructs. OWL + SWRL can be used to define ontologies, using which one can declaratively define facts, policies, and rules in terms of what needs to be true or false for a policy to hold. The route descriptions are carried in the BGP updates as optional transi- tive attributes either as directly embedded in a bit efficient format, or contain a URL to the description, or use UUIDs that imply a certain well-known description. A Policy Enforcement Point (PEP) extracts this description and adds to it any extra contextual information including aspects such as peer identity, network state (con- gestion, link failures, etc.), and network technol- ogy (wired, hybrid, MANET, cellular, etc.). This information is then sent to the Policy Decision Point (PDP) for reasoning. The response back from the PDP will cause specific configurations to be installed by the PEP on the device (in this work, as we are dealing with import/export poli- cies, the PDP filters appropriately the routes that are exchanged). Securing BGP Through Route Filtering ­ A Use Case. We describe how our framework can be used to secure BGP route exchange through appropriate import and export policies. To apply the above framework to provide BGP route dis- semination that takes into account the security credentials and external relationships, we needed to make two modifications to the protocol. The first modification is aimed at establishing the identity of the BGP peers in a secure and veri- fiable manner. For this purpose, we assume the multiple routers and ASs. Furthermore, these approaches are not scalable considering the large number of prefixes (131,000) and ASs (around 16,500), the variety of emerging applications, and the dynamically changing network condi- tions in terms of network traffic and link usage. Furthermore, BGP misconfigurations have often been cited as a major cause for the Internet rout- ing architecture going down [30]. Clearly, there is a need for a mechanism that can automatically map high-level policies to appropriate network level services without much human intervention. In this work, we propose a semantics-driven policy-based network that can aid in building such a mechanism. Semantics-Driven Policy-Based Networks. Policy-based networks use mechanisms that allow network operators to specify at a high level rules defining how packet flows are handled within a network, how network resources are allocated, access control restrictions, and levels of service. All these policies are then enforced by configuring the network devices with the requi- site primitives, so that the desired actions are per- formed on the data streams. For example, BGP allows specifying policies that decide whether a router can accept a route from a neighboring router or not. In previous work [31, 32], we have proposed an architecture for policy-based net- works that involve semantically tagging packets (in OWL/RDF) to convey higher level metadata about the content being carried in the packets. This semantic information can then be reasoned over at the network elements to provide special- ized services in the network. Our policy-based network is a multi-tier system with hierarchical policy enforcement with the highest level of the hierarchy being the central NOC for an ISP and the lowest level being an adaptation layer that is responsible for translating the high-level policies into low-level protocol specific configuration rou- tines that can be applied to the various network elements being managed. In this work, we have adapted the above framework to handle BGP interactions and use it to specify routing policies. We limit our dis- cussion to how the various components of our