Modeling Guidelines DRAFT

Overview

This document establishes guidelines for making decisions about how and what to model. The ZipTie Network Resource Model is focused on capturing all network configuration and all network operational data that informs the configuration of the network.

Importance of Use Cases and Answering Specific Questions

Value of Model Axiom: A model's only as valueable as the questions it can answer.

Step 1: Identify the types of questions you hope to solve with proposed new model elements or set of of elements. What is the use case for asking for this modeled information. If you cannot answer either of these questions, you should strongly consider whether these proposed elements should be modeled. The use cases and the questions provide a bounding box of expecations for a set of modeled elements.

Syntax vs. Semantics

Syntax is what a language looks like; semantics is what a language means. It's basically the distinction between numerals (syntax) and numbers (semantics).

Step 2: (Tough Step). Identify the meaning of what is attempting to be modeled. Unfortunately in the network management world, syntax and meaning are very hard to separate. RFC's are examples of meaning specification. RFC's outlince concepts and entities, which will be implemented in some vendor specific way. A general purpose model distills out the syntax and captures the meaning of configuration data.

For an example see the case study section later in this document.

Convenient Representation

Step 3: Design a convenient representation. Reviewing the questions/use cases in Step 1 and desing a model that allows these questions to be easily answered. Applications and models have intertwined requirements.

Default Configurations (Configuration Dark Matter)

Most network devices hide default settings in the view of the configuration. For example, in IOS "show running-configuration" will only show the MTU for an interface if it is the non-default value for the interface type, whereas "show interfaces" will show a MTU value for each interface whether it is the default or not. The model should contain information on these default values. The defaults for the same element may change across platforms or OS versions of the same platform. The user of the model should not be required to remember all the defaults. Default values are typically booleans, ints, enumerated types, or short strings, therefore dropping the default value in-line in the model makes sense, as opposed to storing each default value once in a dictionary and referencing them.

Case study: IP/ICMP Access Control Lists (ACLs)

USE CASE: ACL Debugging

Overview

ACL Model for Packet Filter Analysis: The complexity required to understand and organize ACL's is extremely daunting for the network engineers. For networks of any size, ACL management and debugging are extremely difficult to accomplish and generally require in production testing in order identify problems in ACL's. The goal of an ACL model is to provide the ability to capture ACL's that their effect on the network to be computed outside the network.

Johny is about to make a change to ACL's on an IOS router and wants to check whether the ACL change will block traffic HTTP traffic on an outbound interface XXX. Unfortunately, Johnny looks at the current ACL's configured and notices that there are many ACL terms that have been added onto the router and it is hard for him to tell, which terms do something and which terms do not do anything. Johhny uses ZipTie's ACL organizer model to figure out what terms are working and what traffic is allowed on his router's outbound interface and he adds the new ACL to the outbound interface XXX and checks the ACL model to make sure that HTTP traffic is blocked on interface XXX with the ACL Model. Now that he is happy with the set of ACL's he converts the model back to the router's IOS syntax.

Common Features of All ACL Implementations

Ordered list. Elements contain an IP address, network mask, and action. Actions are permit or deny. In order to have an effect on the device's operation, an ACL definition must be referenced by name or number in other parts of the configuration.

Extensions on Different Platforms

Platform: IOS

• Standard ACLs: least common denominator
• Extended ACLs: layer 3/4 protocol, icmp, address/mask pair, precedence/tos, log
• More: cisco.com

Platform: PIX

• object groups

PIX object groups are important because they consolidate an access list. The operational command "show access-list" on a PIX expands all of the host and port groups into distinct elements, increasing the size of the list considerably. All platforms ACLs should be modeled using this functionality (storing enough data to recreate the original configuration).

Platform: JUNOS

In IOS ACLs may be applied to interfaces to filter packets or applied to route maps to influence routing policy. On the other hand, JUNOS differentiates the two functions with different configuration frameworks. juniper.net

• Routing Policies: control the size and content of the routing tables, which routes are advertised, and which routes are considered the best to reach various destinations.
• Firewall Filters: protect your router and network from excessive incoming traffic or hostile attacks that can disrupt network service, and to control which packets are forwarded from which router interfaces.

Two Contradicting Goals of Modeling

Goal #1: The model must allow the application to compare two ACLs that were configured in different ways. One possible application of this capability is identifying IOS extended ACLs that can be converted to standard ACLs. A common model also promotes code reuse, for example application code that finds dead ACL elements could be used against ACLs from different platforms.

Goal #2: Preserve information on how the device was originally configured. A view must be able to reconstruct an ACL in a format that agrees with how it was originally configured. For example, an IOS standard ACL contains a subset of the functionality of PIX ACL with object groups. Furthermore, the standard access list could be consolidated in the model by identifying host groups. If this scheme is used, then additional information must be stored so the original configuration of the standard ACL can be produced from the model.

Outstanding Concerns

• IP ACLs share traits with other types of ACLs, for example MAC ACLs. There should be a common model for both.
• Making decisions about how to model involves knowing all of the commonalities and differences in how each version of each platform implements the same or similar concepts. It is unavoidable that we start with some subset of the universe of networking devices, and will not have complete information. When a new device is modeled for existing functionality, changes to the model of existing devices will be necessary if new pivot points are identified. The adapter and model framework must be understandable and nimble enough to support this work inexpensively.

Please add further questions about the current model to the ModelQuestions page.

-- RogerCastillo - 23 Feb 2007

-- BrianEdwards - 26 Feb 2007